Está en la página 1de 14

Re-arquitectura de centros de datos y redes de pilas de baja

latencia y alto rendimiento


mark Handley Costin Raiciu Andrew W. Moore
University College de Londres Alexandru Agache Gianni Antichi
Londres, Reino Unido
Andrei Voinescu Marcin Wójcik
m.handley@cs.ucl.ac.uk
Universidad Politécnica de Bucarest Universidad de Cambridge
Bucarest, Rumania Cambridge, Reino Unido
firstname.lastname@cs.pub.ro firstname.lastname@cl.cam.ac.uk

RESUMEN y más recientemente con soluciones tales como RDMA sobre Converged Ethernet v2 [25] que el

control de flujo de uso Ethernet en interruptores de [23] a la pérdida de paquetes evitar causada por la
redes de centros de datos modernos proporcionan una capacidad muy alta a través de topologías
congestión.
redundantes Clos y baja latencia interruptor, pero los protocolos de transporte rara vez ofrecen un
En una red de ligeramente cargado, Ethernet de control puede dar un rendimiento muy bueno
rendimiento de juego. Presentamos NDP, una novela arquitectura de transporte de centros de datos
de bajo retardo [20] para la petición de flujo / respuesta flujos que las cargas de trabajo del centro de
que alcanza casi óptimas tiempos de finalización para las transferencias cortos y flujo alto rendimiento
datos dominan. Los paquetes se ponen en cola en lugar de perderse, si es necesario producir
en una amplia gama de escenarios, incluyendo incast. NDP búfer alternativo son muy poco profundas y
contrapresión, deteniéndose reenvío a través de varios interruptores, y así no se pierde tiempo en
cuando se llenan los conmutadores de paquetes de equipamiento a los encabezados y prioridad hacia
ser demasiado conservador en el arranque o en espera de tiempos de espera de retransmisión. Sin
adelante las cabeceras. Esto le da a los receptores de una vista completa de la demanda instantánea
embargo, sobre la base de experiencia en el despliegue RoCEv2 en Microsoft [20], Gau et al. Tenga
de todos los remitentes, y es la base de nuestra novela, de alto rendimiento, protocolo de transporte
en cuenta que una red sin pérdidas no garantiza una baja latencia. Cuando se produce la
por trayectos múltiples consciente de que puede hacer frente con gracia con eventos masivos incast y
congestión, las colas se acumulan y se generan tramas de pausa PFC. Colas y tramas de pausa
el tráfico de priorizar diferentes remitentes en escalas de tiempo de RTT. Implementamos NDP en
PFC aumentan la latencia de red. concluyen “Cómo conseguir una baja latencia de red y de alto
huéspedes Linux con DPDK, en un interruptor de software, en un interruptor de hardware basado en

NetFPGA, y en P4. Evaluamos el rendimiento del PND en nuestras implementaciones y en


rendimiento de la red al mismo tiempo para RDMA es aún un problema abierto.”

simulaciones a gran escala, demostrando al mismo tiempo el apoyo a muy baja latencia y alto

rendimiento.
En este trabajo se presenta una nueva arquitectura de protocolo centro de datos,
NDP, que adopta un enfoque diferente para lograr simultáneamente tanto bajo retardo y
alto rendimiento. NDP no tiene conexión configuración apretón de manos, y permite que

CONCEPTOS CCS los flujos para empezar a enviar al instante a plena velocidad. Utilizamos el equilibrio de
carga de trayectos múltiples por paquete, lo que evita la congestión de red núcleo a
• redes → Los protocolos de red; Las redes de centros de datos;
expensas de reordenación, y en interruptores usamos un enfoque similar al Cut Payload
(CP) [9], que recorta las cargas útiles de paquetes Cuando una cola conmutador
PALABRAS CLAVE
completa. Esto le da a una red que no tiene pérdidas para los metadatos, pero no para
Centros de datos; Las pilas de red; Protocolos de Transporte
cargas de tráfico. A pesar de la reordenación, sin pérdida de metadatos da el receptor de
Formato ACM Referencia: una imagen completa sobre el tráfico entrante y que se aproveche de ella para construir
Mark Handley, Costin Raiciu, Alexandru Agache, Andrei Voinescu, Andreww. Moore, Gianni un nuevo protocolo de transporte radical que alcanza una latencia muy baja para los
Antichi, y Marcin Wójcik. 2017. Re-arquitectura de centros de datos y redes de pilas de baja flujos cortos,
latencia y alto rendimiento. En
Actas de SIGCOMM '17, Los Ángeles, CA, EE.UU., 21-25 de agosto de, 2017,
14 páginas. https://doi.org/10.1145/3098822.3098825
Hemos puesto en marcha en NDP hosts Linux, en un interruptor de software, en un
interruptor de hardware basado en NetFPGA ASUMIR [41], en P4 [29], y en la simulación.
1. INTRODUCCIÓN Vamos a demostrar que logra PND:

Los centros de datos han evolucionado rápidamente en los últimos años, con Clos [1, 17] • Mejor rendimiento que DCTCP o DCQCN corto fluir.

topologías común devenir, y un nuevo énfasis en baja latencia, primero con los protocolos de • Mayor que 95% de la capacidad máxima de la red en una red muy cargado con

transporte mejoradas, tales como DCTCP [4] colas de conmutación de sólo ocho paquetes.
• retraso de casi perfecto y la equidad en incast [18] escenarios.
Se permite hacer copias digitales o en papel de la totalidad o parte de este trabajo para uso personal o en el aula se
• mínima interferencia entre los flujos a diferentes hosts.
concede sin siempre que las copias no se hacen o se distribuyen con fines de lucro o de ventajas comerciales y que las
copias soportar esta notificación y la cita completa en la primera página . Derechos de autor para los componentes de
• priorización eficaz del tráfico rezagado durante incasts.
este trabajo no sean propiedad de los autor (s) deben ser respetados. Se permite abstraer con el crédito. Para copiar de
otro modo, o volver a publicar, para publicar en servidores o redistribuir en las listas, se requiere una autorización previa y
/ o una tasa. Solicitar permisos de permissions@acm.org. 2 DISEÑO DEL ESPACIO

tráfico de la red intra-centro de datos se compone principalmente de petición / respuesta RPC-como


SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU.
© 2017 derechos de autor pertenecen al propietario / autor (s). Los derechos de publicación licencia para Association for Computing protocolos. utilización de la red media rara vez es muy alto, pero las aplicaciones puede ser muy ráfagas. El
Machinery.
gran problema hoy en día es la latencia, especialmente por sus siglas en RPC-como las cargas de trabajo.
ACM ISBN 978-1-4503-4653-5 / 17/08. . . $ 15.00
https://doi.org/10.1145/3098822.3098825
A costa de cabeza de línea

29
SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU. Handley et al.

bloqueo, las aplicaciones de hoy en día a menudo la reutilización de las conexiones TCP a través de múltiples ambientes, porque las velocidades de enlace y los retardos de red (excepto para poner en cola los retrasos)

peticiones para amortizar el coste de latencia del protocolo de enlace TCP. pueden principalmente ser conocidos de antemano.

¿Es posible mejorar la somuch pila de protocolos que cada petición podría utilizar una nueva Por paquete ECMP. Un problema con topologías Clos es que perflow ECMP hashing de los flujos a

conexión y, al mismo tiempo esperar para acercarse a la latencia y ancho de banda en bruto de caminos puede causar colisiones de flujo no deseados; un despliegue [20] encontró este rendimiento

la red subyacente, incluso bajo carga pesada? Vamos a demostrar que estos objetivos son reducido en un 40%. Para las transferencias grandes, protocolos de trayectoria múltiple como

alcanzables, pero para ello implica cambios en la forma se encamina el tráfico, cómo hacer frente MPTCP pueden establecer suficientes subflujos para encontrar caminos no utilizados [31], pero poco

a los interruptores de sobrecarga, y lo más importante, requiere un protocolo de transporte pueden hacer para ayudar con la latencia de las transferencias muy cortos. La única solución en

completamente diferentes de los utilizados en la actualidad. Antes de describir nuestra solución este caso es la raya en varias rutas en función de cada paquete. Esto complica el diseño de

en el § 3, en primer lugar destacamos los puntos arquitectónicos clave que deben ser protocolo de transporte.

considerados.
Reordenar tolerantes apretón de manos. Si realizamos una transferencia cero-RTT con el
reenvío de trayectos múltiples por paquete en una red Clos, incluso la primera ventana de

2.1 de extremo a extremo demandas de servicio paquetes pueden llegar en un orden aleatorio. Este efecto tiene implicaciones para establecer
la conexión: el primer paquete que llegue no será el primer paquete de la conexión. Tal
¿Qué aplicaciones quieren de una red de centros de datos?
protocolo de transporte debe ser capaz de establecer el estado de conexión no importa qué
Ubicación de la Independencia. No debería importar qué máquina en un centro de datos los
paquete desde la ventana inicial es primero en llegar.
elementos de una aplicación distribuida se ejecutan. Esto se logra comúnmente usando alta
capacidad paralelas topologías Clos [1, 17]. Tales topologías tienen suficiente ancho de banda
Optimizado para Incast. Aunque las redes Clos están bien aprovisionada para el núcleo de la capacidad, el
en sección transversal que el núcleo de red no debería ser un cuello de botella.
tráfico incast puede hacer la vida difícil para cualquier protocolo de transporte cuando las aplicaciones se

abren en abanico peticiones a muchos trabajadores simultáneamente. Tales patrones de tráfico pueden
Baja latencia. Clos redes pueden proporcionar ancho de banda, módulo problemas con el equilibrio de carga
causar tasas de pérdida de paquetes de alto, sobre todo si el protocolo de transporte es agresivo en el
entre los caminos, pero a menudo están a la altura en la prestación de servicio de baja latencia. comportamiento
primer RTT. Para manejar esto con gracia requiere un poco de ayuda de los interruptores.
predecible muy baja latencia de solicitud / respuesta es la demanda clave de la aplicación, y es el más difícil de

satisfacer. Esto es más importante que el rendimiento de transferencia de archivos grandes, aunque de alto

rendimiento sigue siendo un requisito, especialmente para los servidores de almacenamiento. La estrategia debe

ser optimizar para una baja latencia en primer lugar. 2.3 Interruptor de Servicio Modelo

Requisitos de la aplicación, el protocolo de transporte y el modelo de servicio en los conmutadores de red


En fundición. Datacenter cargas de trabajo a menudo requieren el envío de peticiones a un gran
están estrechamente acoplados, y necesidad de ser optimizadas de manera integral. De particular
número de trabajadores y el manejo de sus respuestas casi simultáneos, causando un problema
relevancia es lo que sucede cuando se congestiona un puerto del switch. El modelo de servicio interruptor
llamado incast. Una buena pila de red debe proteger a las solicitudes de los efectos secundarios de
influye mucho en el espacio de diseño de ambos algoritmos de control de protocolo y de congestión, y las
los patrones de tráfico incast con gracia mientras que proporciona una baja latencia.
parejas estrechamente con el comportamiento de reenvío: por cada paquete de equilibrio de carga de

trayectos múltiples es ideal, ya que reduce al mínimo puntos de acceso, pero complica la capacidad de los
Prioridad. También es común para un receptor para manejar muchos flujos de entrada
sistemas de extremo a congestión de la red inferir y aumenta la importancia del comportamiento de
correspondientes a diferente solicita simultáneamente. Por ejemplo, puede haber desplegaron
sobrecarga elegante.
dos solicitudes diferentes a los trabajadores, y las respuestas a esas peticiones están llegando
con las últimas respuestas a la primera solicitud se superponen las primeras respuestas a la
Pérdida como un mecanismo de retroalimentación congestión tiene la ventaja de
segunda solicitud. Muchas aplicaciones necesitan todas las respuestas a una solicitud antes de
que los paquetes cerrados no usar el ancho de banda de cuello de botella, y la pérdida
que puedan proceder. Una propiedad muy deseable es que el receptor sea capaz de priorizar el
de solamente influye en los flujos de atravesar la congestionada enlace no todos los
tránsito de llegada de los rezagados. El receptor es la única entidad que puede priorizar
esquemas tienen estas propiedades. La desventaja es que conduce a la incertidumbre
dinámicamente su tráfico de entrada, y este diseño protocolo de impactos.
en cuanto al resultado de un paquete. Duplicar o selectiva A CK s a retransmisiones de
activación sólo funcionan bien para los flujos vivido largo. Con flujos cortos, pérdida de
la cola es común, y entonces usted tiene que recurrir a los tiempos de espera de
retransmisión (RTO). Breve RTO sólo son seguros si se puede limitar el retraso en la
2.2 Protocolo de transporte red, por lo que necesita para mantener las colas cortas [4], que a su vez Restringir los

protocolos de transporte de los centros de datos actuales satisfacen algunos de estos requisitos de la esquemas de control de congestión que puede utilizar. parejas también la pérdida mal

aplicación, pero que satisface todos los coloca algunas demandas extraordinarias de los centros de datos con por paquete de trayectos múltiples de reenvío; debido a que los paquetes de un

protocolos de transporte. flujo llegan fuera de orden,

Zero-RTT configuración de la conexión. Para minimizar la latencia, muchas aplicaciones les gustaría entrega

cero-RTT para las pequeñas transferencias de salida (o un RTT de petición / respuesta).


Necesitamos un protocolo que no requiere un apretón de manos al completo antes de enviar datos, ECN ayuda significativamente. DCTCP utiliza ECN [32] con un umbral aguda para el marcado de

pero esta seguridad posturas y problemas de corrección. paquetes, y un esquema de control de congestión que pretende impulsar dentro y fuera del régimen

marcado. Esto reduce enormemente la pérdida para los flujos de vivido largo, y permite el uso de

pequeños tampones, reducir el retardo de puesta en cola. Por sus siglas fluye sin embargo, ECN tiene
Comienzo rápido. Otra implicación de la prestación de RTT cero es que un protocolo de transporte no puede Investigacion

para el ancho de banda disponible, para minimizar la latencia, que debe asumir el ancho de banda menos beneficios debido a que el flujo no tiene tiempo de reaccionar a la retroalimentación ECN. En la

disponible, con optimismo enviar una ventana inicial completa, y luego reaccionar adecuadamente cuando práctica interruptores utilizan grandes buffers compartidos en conjunción con ECN y esto reduce las

no lo es. A diferencia de la Internet, las soluciones más simples son posibles en los centros de datos pérdidas incast, pero temporizadores de retransmisión deben ser menos

30
redes de centros de datos de baja latencia y alto rendimiento. SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU.

Clos Por paquete Flujo rápido pequeñas


100
Red Mul <ruta comienzo colas
80

Justo por ciento de


núcleo NDP interruptor, interruptor de
uncongested baja 60 media PND, el peor 10%

goodput logra
latencia Recorte de
CP interruptor, interruptor
paquetes 40
de media CP, peor 10%
Incast y
reordenamiento, pero el 20
Nuevo
receptor tiene plena
Receptor 0
Informa <en
Protocolo 0 20 40 60 80 100 120 140 160 180 200
Driven
Número de flujos

Figura 2: Colapso y problemas de fase con parálisis cerebral


Ctrl paquete de La Fast Cero RTT de
prioridad estimulación del receptorRTX conexión

balanceo de carga, si van a enviar a velocidad de línea provoca la congestión, se debe a varios remitentes
Figura 1: Los componentes clave de NDP
están enviando al mismo receptor. Incluso entonces, el enlace del receptor está totalmente ocupado, así

agresivo. ECN tiene la ventaja sin embargo que interactúa bastante bien con el reenvío de que esto no es, por sí mismo, un problema.

trayectos múltiples por paquete, dado un diseño de protocolo de transporte que puede tolerar Para garantizar una baja latencia, las colas del interruptor deben ser pequeñas. Este medio de

la reordenación. colisión flujos se desbordarán la cola. La pérdida de paquetes, combinado con la reordenación de

Ethernet sin pérdidas usando 802.3x tramas de pausa [23] o 802,1 QBB de control de trayectos múltiples, hacen imposible inferir lo que pasó y retransmitir la suficiente rapidez para evitar el

flujo basado en la prioridad (PFC) [24] se puede evitar la pérdida, evitando la necesidad impacto en la latencia; esto viola el objetivo de baja latencia. Por completo la prevención de la pérdida

de agresivo RTO en los protocolos. En utilizaciones bajas, esto puede ser eficaz en el de paquetes añade demora de espera; si esto se hace haciendo una pausa en el tráfico de entrada, al

logro de bajo retardo de una explosión llegará a la velocidad máxima que el enlace puede igual que con Ethernet sin pérdidas, esto afecta el resto del tráfico no relacionado, violar su baja latencia

reenviar, sin necesidad de esperar a que las retransmisiones. El problema se produce en y alto rendimiento predecible objetivos. Buscamos un término medio entre la pérdida de paquetes y sin

las utilizaciones más altos en las topologías de niveles, donde los flujos que pasan a hash pérdidas.

al mismo puerto de salida, y utilizan la misma prioridad en el caso de 802.1Qbb, pueden


causar que los puertos de entrada se ponga en pausa. Esto provoca daños colaterales a Paquete de recorte, similar al realizado por el CP, es un caldo de tal medio. Interruptor de colas

otras corrientes que atraviesan el mismo puerto entrante destinado a diferentes puertos de pueden ser pequeñas, y las descubre fijas receptor que los paquetes se envíen mediante el examen

salida. Con grandes incasts, haciendo una pausa en cascada puede volver hacia de las cabeceras recortadas que recibe. Sin embargo, para minimizar la latencia de retransmisión,

conmutadores de núcleo. Lossless Ethernet también interactúa mal con el reenvío de encabezados recortadas y paquetes de control tienen que ser priorizados. Que llegan encabezados

trayectos múltiples por paquete, recortadas indicarle al receptor exactamente cuál es la demanda, por lo que mediante el uso de un

protocolo receptor-tirado, el receptor puede controlar con precisión el tráfico entrante. Esto evita la

sobrecarga persistente y permite que los paquetes más importantes a ser tirados en primer lugar, a

Cut Payload (CP) [ 9] trata de obtener los beneficios de sin pérdidas sin ser absolutamente sin pérdidas. discreción del receptor.

Cae cargas útiles de paquetes, pero no las cabeceras de los paquetes, aliviando la sobrecarga evitando al

mismo tiempo la incertidumbre en cuanto a los resultados de paquetes. Se muestra una gran promesa, pero

hay dos problemas. En primer lugar, en la sobrecarga severa, es susceptible al colapso de congestión, 3.1 NDP Service Switch Modelo
donde sólo los encabezados desvíe. En segundo lugar, debido a que las cabeceras están en la cola de una Con CP, cuando la cola en un conmutador llena más allá de un umbral fijo, en lugar de descartar un
manera FIFO, cola costos "pérdida" al menos un RTT. Además, CP, usos propuestos inicialmente el reenvío paquete, los embellecedores de desconectar la carga útil del paquete, haciendo cola sólo la
de una sola ruta de acceso para cada flujo. cabecera. La razón es que los paquetes no se pierdan en silencio, lo que permite la retransmisión

rápida sin esperar a un tiempo de espera. Con las cortas distancias en una red de centros de datos,

tales retransmisiones pueden llegar muy rápidamente.


3 DISEÑO
Nuestros principales objetivos son baja latencia finalización para flujos cortos, y Junto a los cambios de conmutador, PP propone cambios menores en TCP para mejorar el

predecible de alto rendimiento para flujos más largos. Para satisfacer plenamente estos objetivos, rendimiento incast. Deseamos que ir mucho más allá de CP, y el uso de paquetes de recorte como

impactos NDP toda la pila, incluyendo el comportamiento de conmutación, enrutamiento, y un nuevo la base de una arquitectura de red extremadamente agresivo, centrado en el servicio de retardo

protocolo de transporte. Somos líderes con una breve pero simplificado razón de diseño para mostrar muy bajo. Sin embargo, hay varios problemas que pueden surgir si se utiliza la vainilla CP.

cómo las piezas en la Figura 1 encajan entre sí, a continuación, rellenar los datos en el resto de esta

sección. En primer lugar, CP puede sufrir de una forma de colapso de congestión. La Figura 2 muestra lo

A Clos topología tiene suficiente ancho de banda en el núcleo para satisfacer toda la demanda, siempre que sucede cuando los paquetes llegan a un interruptor a una velocidad significativamente más alta

y cuando que está perfectamente de carga equilibrada. Para colisiones de flujo de evitar en las enlaces que puede ser soportado por el enlace de salida. Muchos flujos que no responden convergen en un 10

centrales, que impacto tanto la latencia y rendimiento, de equilibrio de carga cada flujo a través de muchos Gb / s de enlace que admite sólo una de ellas, como en escenarios incast servidor extremas. La figura

caminos es esencial. Equilibrio de flujos cortos requiere multitrayecto por paquete de equilibrio de carga, muestra el porcentaje de la distribución equitativa de la goodput ideal que se logra. El goodput media

pero inevitablemente paquetes conseguirá reordenado. de la CP fluye disminuye, como una fracción creciente del enlace está ocupada por cabeceras de los

paquetes recortados. Esta figura muestra el mejor caso para CP, con jumbogramas 9 KB. Con

Para lograr una mínima latencia corto fluyen, los remitentes no pueden sondear antes de enviar: paquetes de 1500 bytes de la caída es mucho más rápido.

deben enviar el primer RTT a velocidad de línea. Esto funciona bien la mayor parte del tiempo.

Cuando remitentes realizan por paquete multipath

31
SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU. Handley et al.

En segundo lugar, los centros de datos redes son muy regulares, por lo que los efectos de fase [14] remitentes. Tal equilibrio de carga es importante para lograr un muy bajo retardo. Si utilizamos
pueden ocurrir, resultando en rendimiento injusta. Las curvas de trazos en la Figura 2 muestran la muy pequeñas colas de paquetes de datos (sólo ocho paquetes), nuestros experimentos
goodput media de la peor rendimiento 10% de los flujos. efectos de fase CP pueden hacer muy injusto, muestran que este simple esquema puede aumentar la capacidad máxima de la red hasta en un
aunque se nota que esta figura muestra resultados de la simulación; efectos de fase de la vida real a 10% a través de una selección de pasos aleatoria perpacket.
veces se pueden reducir la variabilidad en el tiempo de las transmisiones de paquetes debido a la

programación del sistema operativo. Dependiendo de si la red es L2 o conmutada-L3, o bien rutas de etiquetas conmutadas o
direcciones de destino se puede utilizar para elegir un camino. En una red L2 FatTree por
Por último, los objetivos del PP para proporcionar retroalimentación bajo retardo de que los paquetes se ejemplo, un camino de etiquetas conmutadas sólo necesita ser establecido en lo que cada
han perdido. Sin embargo, debido CP utiliza una cola FIFO, la retroalimentación sólo puede ser enviado interruptor de la base, con direcciones L2 destino tomando el relevo de allí, como un FatTree sólo
después de que se hayan recibido todos los paquetes anteriores, resultando en un retraso antes de que se tiene una ruta a partir de un interruptor de la base a cada host. En una L3 FatTree, cada host
provoca una retransmisión. Nos gustaría correr muy pequeñas memorias intermedias en los interruptores, recibe varias direcciones IP, una para cada interruptor de la base. Al elegir la dirección de
tener uno de esos colas de desbordamiento, y para la retransmisión para llegar antes de que la cola haya destino, el remitente elige el interruptor de la base unas traviesas de paquetes.
tenido una oportunidad para drenar. Esto no es posible con FIFO de colas.

interruptores NDP hacen tres cambios principales a CP. En primer lugar, un interruptor de NDP

mantiene dos colas: una cola de prioridad más baja para paquetes de datos y una cola de prioridad más
3.2 Protocolo de transporte
alta para las cabeceras recortadas, A CK s y N ACK s 1. Esto puede parecer contrario a la intuición, pero
NDP utiliza un protocolo activado por el receptor de transporte diseñado específicamente para tomar ventaja de
proporciona a la retroalimentación temprana posible que un paquete no lo hacen, por lo general lo que
reenvío de trayectos múltiples, paquete de recorte, y las colas de conmutación cortos. El objetivo en cada paso es
permite una retransmisión a llegar antes de la cola de ofender siquiera había tenido tiempo de asentarse.
primero para minimizar el retardo para las transferencias cortas, a continuación, para maximizar el rendimiento
Esto puede proporcionar al menos tan buen comportamiento de retardo bajo como Ethernet sin pérdidas,
para las transferencias más grandes.
sin el daño colateral causado por la pausa.
Al poner en marcha una conexión, un protocolo de transporte podría ser

En segundo lugar, los interruptores realiza el turno rotativo ponderado entre la “cola de cabecera
pesimistas, como TCP, y asumir que no hay capacidad de red repuesto mínima. TCP

de” alta prioridad y la prioridad más baja “cola de paquetes de datos”. Con una relación de 10: 1 de las
comienza a enviar datos después de que se complete el enlace de tres vías,

cabeceras de los paquetes, esto permite retroalimentación temprana sin ser susceptible a colapso de
inicialmente con una pequeña ventana de congestión [11], y se duplica cada RTT

congestión.
hasta que llene el tubo. Comenzar despacio es apropiado en Internet, donde RTT y

Finalmente, cuando un paquete de datos llega y la cola de prioridad baja está llena, el
anchos de banda de enlace difieren en varios órdenes de magnitud, y donde las

interruptor decide con 50% de probabilidad si para recortar el paquete recién llegado, o el
consecuencias de ser más agresivo son graves. En un centro de datos, sin embargo,

paquete de datos a la cola de la cola de prioridad baja. Esto rompe los efectos de fase. La figura
las velocidades de enlace y RTT basales son mucho más homogénea, y pueden ser

2 muestra cómo un conmutador de NDP evita el colapso de CP, y también evita fuertes efectos
conocidas de antemano. También, utilización de la red es a menudo relativamente

de fase.
baja [7]. En una red de este tipo, para minimizar el retardo hay que ser optimista y
suponer que habrá suficiente capacidad de enviar una ventana llena de datos en el
3.1.1 enrutamiento primer RTT de una conexión sin sondeo. Si el búfer alternativo son pequeñas,

Queremos PND cambia para realizar el reenvío de múltiples saltos por paquete, con el fin de

distribuir uniformemente ráfagas de tráfico a través de todos los caminos paralelos que están

disponibles entre origen y destino. Esto podría hacerse en al menos cuatro formas:
Sin embargo, si resulta outs que no hay suficiente capacidad, se perderán los paquetes.
Con un protocolo de transporte normal, la combinación de desvío de trayectoria múltiple por
• Realizar por paquete ECMP; interruptores de elegir aleatoriamente el siguiente salto para cada
paquete y ser agresivo en la primera RTT es una receta para la confusión. Algunos paquetes
paquete;
llegan, pero en un orden aleatorio, y algunos no lo hacen. Es imposible saber rápidamente lo
• Explícitamente fuente-ruta del tráfico;
que realmente ocurrió, por lo que el remitente debe recaer en los tiempos de espera de
• Utilizar rutas de etiquetas conmutadas; el remitente elige la etiqueta;
retransmisión conservadores para remediar la situación.
• direcciones de destino indica el camino a seguir; el remitente elige entre las
direcciones de destino.
El aumento de amortiguación interruptor podría mitigar esta situación un tanto, a expensas de
Para los propósitos de equilibrio de carga que los tres últimos son equivalentes-remitente elige un
aumentar la demora, pero no puede prevenir la pérdida de grandes incasts. ECN tampoco puede
camino-difieren en cómo los rápidos del remitente ese camino. Nuestros experimentos muestran que si
evitar la pérdida de los flujos cortos agresivos. tramas de pausa pueden evitar la pérdida, y podría
los remitentes eligen los caminos, que pueden hacer un mejor trabajo de equilibrio de carga que si los
ayudar significativamente aquí, pero vamos a mostrar en el § 6.1 que esto trae sus propios problemas
interruptores al azar eligen caminos. Esto permite el uso de búfer alternativo ligeramente más
significativos en términos de retardo a los flujos no relacionados.
pequeñas.

Al contrario que en Internet, en un centro de datos, los remitentes pueden conocer la topología,
Aquí es donde paquete de recorte en el PND cambia realmente entra en su propia. Cabeceras de
por lo que saber cuántos caminos están disponibles para un destino. Cada emisor PND toma la lista
los paquetes recortadas que llegan al receptor consumen poco ancho de banda de cuello de botella,
de rutas a un destino, al azar permuta, entonces envía paquetes de caminos en este orden. Después
pero informan al receptor, precisamente, la que se envían los paquetes. El orden de llegada de
de que se ha enviado un paquete en cada trayectoria, se permuta aleatoriamente la lista de rutas de
paquetes no es importante cuando se trata de inferir lo que pasó. asegura la cola de prioridad que
nuevo, y el proceso se repite. Esto propaga paquetes igualmente a través de todos los caminos
estas cabeceras llegan rápidamente, y que los paquetes de control tales como N ACK s devuelto al
evitando al mismo tiempo la sincronización inadvertido entre dos
remitente llegar rápidamente; de hecho lo suficientemente rápido como para provocar una

retransmisión que llega antes de que la cola de desbordamiento

1 También P ULL paquetes, que daremos a conocer en breve.

32
redes de centros de datos de baja latencia y alto rendimiento. SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU.

src Colina agg Núcleo agg Colina dst


• Cuando un P ULL paquete llega en el remitente, el remitente enviar tantos paquetes de datos como los

t podar incrementos del contador de tracción por. Cualquier paquete en cola para su retransmisión se envían en
1 !
t encabezamiento
primer lugar, seguido por los nuevos datos.
t RTX
RTX 9 23 • Cuando el remitente se queda sin datos para enviar, marca el último paquete. Cuando llega el
! 9 1 a 9!
9 4 !!!
último paquete, el receptor elimina cualquier paquete de tracción para que el remitente de su cola de
9 ! 5 !!!
9 !
6 entrada para evitar el envío de paquetes de tracción innecesarios. Cualquier dato posteriores al
!
t enqueue 7 remitente más adelante quiere enviar serán empujados más que sacaron. Debido al paquete de
89
recorte, es muy raro que un paquete que se perdió realmente; por lo general esto se debe a la
!!
t llegar corrupción. Como un CK s y N ACK s se envían de inmediato, se le de prioridad de reenvío, y todas

las colas de conmutación son pequeñas, el remitente puede saber rápidamente si un paquete se

haya perdido. Con ocho colas de paquetes de conmutación, 9 KB jumbogramas y


Figura 3: Paquete de recorte permite la retransmisión de bajo retardo
almacenar-andforward cambia la topología FatTree un 10 Gb / s, cada paquete lleva
ha tenido tiempo de drenaje, por lo que el enlace no va inactivo. Esto se ilustra en la Figura 3.
A la hora t podar paquetes de nueve fuentes diferentes llegan casi simultáneamente en el
interruptor TdR. La cola de ocho paquete al enlace de destino se llena, y el paquete de la 7.2 mu s Para serializar. Teniendo en cuenta la cola de prioridad del Plan Nacional de Desarrollo, la red

fuente 9 se recorta. Después de paquetes acabados 1 se reenvían, cabecera del paquete de 9 peor de los casos RTT es de aproximadamente 400 mu s, con RTT típicos son mucho más corto. Esto

recibe un tratamiento prioritario. A t encabezamiento que llega al receptor, que genera un N ACK paquetepermite un muy corto tiempo de retransmisión que se utiliza para proporcionar la fiabilidad de dichos
2. 9 paquetes se retransmite en t r TX y llega a la cola del interruptor mientras TdR de paquetes paquetes corruptos.

7 todavía se está remitiendo. El vínculo con el destino nunca pasa inactivo, y el paquete llega HALAR paquetes realizan un papel similar al del reloj A CK- de TCP, pero son por lo general
al 9 t llegar , 4 separado de un CK S para permitir que se paseaban sin afectar el mecanismo de retransmisión
de tiempo de espera. Por ejemplo, en un gran escenario incast, P ULL s puede pasar un tiempo
Al mismo tiempo, habría llegado si PFC había impedido su pérdida pausando el interruptor relativamente largo en la cola de entrada del receptor antes del marcapasos permite que sean
aguas arriba. enviados, pero no queremos retrasar también A CK s porque hacerlo requiere estar mucho más
En una topología de Clos empleo de trayectoria múltiple por paquete, los puntos calientes única que se conservador, con tiempos de espera de retransmisión.
acumulan son cuando las fuentes de tráfico frommany converge en un receptor. Con NDP, cabeceras

recortadas indican la demanda precisa al receptor; se sabe exactamente lo que los remitentes que quieren El comportamiento emergente es que la primera RTT de datos en una conexión se empuja, y RTT
enviar datos a la misma, por lo que está en mejor posición para decidir qué hacer después de la primera posteriores de los datos se tira a fin de llegar a velocidad de línea del receptor. En un escenario
RTT de una conexión. Después de enviar una ventana completa de datos a velocidad de línea, NDP incast, si muchos remitentes envían al mismo tiempo, muchos de su primera ventana de paquetes
remitentes detener el envío. A partir de entonces, el protocolo se receiverdriven. Un PND solicitudes será recortado, pero asegura posteriormente receptor de tracción que la tasa de llegada agregada de
receptor paquetes desde los remitentes, el ritmo al envío de dichas solicitudes de manera que los paquetes todos los remitentes coincide con la velocidad del enlace del receptor, con pocas o ninguna paquetes
de datos que provocan llegan a una velocidad que coincide con la velocidad del enlace del receptor. Los que están siendo recortados.
datos solicitados pueden ser retransmisiones de paquetes recortadas, o pueden ser nuevos datos del resto

de la transferencia. Así pues, el protocolo funciona de la siguiente manera:


3.2.1 Hacer frente a la Reordenamiento

Debido a reenvío de trayectos múltiples por paquete, es normal que los dos paquetes de datos y la
• El emisor envía una ventana completa de los datos sin esperar una respuesta. Los paquetes de inversa de la ruta A CK s, N ACK s y P ULL s a ser reordenadas. El diseño básico del protocolo es
datos llevan los números de secuencia de paquetes. robusto a reordenamiento, ya que no tiene que hacer inferencias acerca de la pérdida de números de
• Para cada encabezado 3 que llega, el receptor envía inmediatamente una N ACK para secuencia de otros paquetes. Sin embargo, la reordenación todavía tiene que ser tenido en cuenta.
informar al remitente para preparar el paquete para la retransmisión (pero aún no enviarlo).

Aunque P ULL paquetes son prioridad-en cola, lo hacen los paquetes de datos no adelantarse, así P
• Para cada paquete de datos que llega, el receptor envía inmediatamente una A CK para ULL los paquetes enviados por caminos diferentes llegan a menudo fuera de orden, el aumento de la
informar al remitente que el paquete llegó, por lo que el tampón puede ser liberado. explosividad de retransmisiones. Para reducir esto, P ULL s llevan un número de secuencia de extracción. El

receptor tiene un espacio de secuencia de tracción separada para cada conexión, incrementándolo en uno
• Por cada encabezado o paquete que llega, el receptor añade una PAG ULL por cada enviado pull. A la recepción de un P ULL, el emisor transmite tantos paquetes como el número de
paquete a su cola de entrada que, a su debido tiempo, se enviará al remitente secuencia de tracción aumenta en. Por ejemplo, si un P ULL se retrasa, el siguiente P ULL enviado de forma
correspondiente. Un receptor sólo tiene una cola de entrada, compartido por todas las puede llegar primero a través de un camino diferente, y tirará de dos paquetes en lugar de uno. Esto reduce
conexiones de las que es el receptor. explosividad 'un poco.
• UN TIRÓN paquete contiene el ID de conexión y un per-remitente contador de tirón que
incrementos en cada P ULL paquete enviado a ese remitente.

• El receptor envía P ULL paquetes de la cola de entrada por interfaz, de ritmo de manera que los 3.2.2 El primer RTT
paquetes de datos que provocan desde el emisor a continuación llegan a velocidad de enlace del A diferencia de TCP, en el que el apretón de manos SYN / SYN-ACK pasa por delante de intercambio de
receptor. Tire de paquetes de diferentes conexiones están comunicadas bastante por defecto, o datos, deseamos datos del PND para ser enviados en el primer RTT. Esto añade tres nuevos requisitos:
con estricta priorización cuando un flujo tiene mayor prioridad.

• Ser robusto a las solicitudes que las direcciones IP de origen de la parodia.

2 Este N ACK tiene la P ULL conjunto de bits, solicitando la retransmisión. 3 Cuando nos referimos a los encabezados en este contexto,

nos estamos refiriendo a las cabeceras de los paquetes cuya carga útil fue recortado por un interruptor 4 Si sólo hay un remitente, P ULL paquetes no necesitan estimulación extra porque los paquetes de datos llegan de ritmo

adecuadamente. En estos casos podemos enviar combinado P ULL A CK.

33
SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU. Handley et al.

• Asegurar ninguna conexión se procesa sin darse cuenta dos veces.


• Hacer frente a los trayectos múltiples reordenamiento dentro del primer RTT. T / TCP [8] y TCP
abierto rápido [10], tanto extender TCP para enviar datos en la primera RTT. previene TFO spoofing 0.8 1
mediante la presentación de una muestra dada por el servidor en una conexión anterior, pero no asegura 0.6

CDF
la semántica en situación de mostonce. T / TCP utiliza monótonamente creciente identificadores de Permulation
0.4
conexión que figuren al-más-una vez que la semántica, pero no es robusto a spoofing. Tampoco hace Aleatorio

0.2 Incast, 100 flujos de 135KB Incast,


frente bien si el SYN no es el primer paquete en llegar.
100 fluye de 1350KB
0
requisitos del PND son ligeramente diferentes. Spoofing se puede prevenir en el hipervisor o NIC, o 10 100 1000 10000 100000
el uso de VXLAN para centros de datos para múltiples usuarios, por lo que no es un gran problema. Latencia (us)
A-más-una vez que la semántica son aunque crucial, pero la solución de T / TCP no es robusto a
Figura 4: Entrega latencia con diversas matrices de tráfico.
reordenamiento de trayectos múltiples entre la espalda con espalda conexiones cortas. NDP resuelve

esto no por mantener el estado de tiempo de espera en el cliente y el servidor, por lo que cualquiera
3.2.4 Regreso al Remitente

puede rechazar conexiones duplicadas. Como el tiempo de vida máximo de segmento es menor de 1 ms, Paquete de recorte puede hacer frente a grandes incasts sin necesidad de soltar cualquiera de las

la cantidad de estado adicional es bastante pequeño. cabeceras. Sin embargo, extremadamente grandes incasts pueden desbordar la cola de cabecera,

causando la pérdida. Los paquetes faltantes se resienten rápidamente, cuando RTO del remitente

Finalmente, varios paquetes pueden ser enviados en la primera RTT, pero el primero en llegar a expira. Con pequeñas colas de garantizar un 400 mu s máximo RTT, la máximo RTO podría ser con

menudo no es el primero enviado. Para ser robusto, cada paquete en el primer RTT lleva la bandera seguridad un precio tan bajo como 1 ms. Durante incast, una cola interruptor superior del rack puede

SYN, junto con el desplazamiento de su número de secuencia desde el primer paquete en la contener ocho 9KB paquetes y (en la misma cantidad de memoria) 1125 cabeceras de 64 bytes antes

conexión. Esto permite que el estado de conexión que se establecerá por lo que paquete llega en de que se desborda. El receptor retransmisiones P ULL de estos 1125 paquetes, el ritmo de su llegada

primer lugar. para mantener su enlace saturado. A 10 Gb / s, 1125 paquetes de 9KB ocuparán el enlace del receptor

para 8 ms por lo que cualquier paquetes resienten debido a la RTO todavía podía llegar a la cola que se

desbordó antes de que el enlace va inactivo.

3.2.3 Robustez optimizaciones

Si la red se comporta adecuadamente, el protocolo anterior funciona muy bien. Sin embargo, a veces enlaces
Sin embargo, a veces una transferencia todo cabe en un solo paquete, y que la
o interruptores fallan. Esto se detecta normalmente mediante un protocolo de encaminamiento, y el fracaso se
transferencia puede ser de alta prioridad-puede ser, por ejemplo, ser el rezagado de una
encamina entonces alrededor. NDP paquetes son encaminado por la fuente, por lo que los ejércitos del PND
solicitud anterior. Si se pierde un paquete tal, confiando en el RTO añade una demora
también necesitan recibir estas actualizaciones de enrutamiento saber qué rutas para evitar. Sin embargo,
innecesaria. Como una optimización, cuando la cola de cabecera se desborda, el interruptor
antes de que el protocolo de enrutamiento ha informado a todo el mundo, se perderán los paquetes que
puede cambiar el emisor y el receptor de direcciones, y devolver la cabecera al remitente. El
lleguen a un enlace fallido. Otros fallos más sutiles son también posibles, tal como una de 10 Gb / s enlace de
emisor podría entonces volver a enviar el paquete infractor. Sin embargo, siempre reenvío podría
decidir a negociar a 1 Gb / s, lo que resulta en un punto caliente que no se detecta inmediatamente por
provocar un eco de la incast originales. NDP sólo se vuelve a enviar si no espera más P ULL s-es
enrutamiento. El trabajo previo ha demostrado que el uso de control de congestión de un solo camino (por
decir, no hay paquetes A CK DE o N ACK ed pero todavía no sacaron, o si también se
ejemplo, TCP) y dentro de la red de paquetes de pulverización de resultados en el rendimiento en gran medida
devolvieron todos los demás paquetes de la primera ventana. Esto evita incast eco, pero
reducido en estos escenarios, debido a que el protocolo de transporte no es consciente de que sólo uno de sus
mantiene el tirón del reloj en marcha. NDP también vuelve a enviar si la mayoría de los
trayectorias se está portando mal [12,
paquetes recientemente se A CK ed lugar de N ACK ed-esto indica una red asimétrica, donde
volver a enviar en un camino de trabajo diferente tiene sentido.

PND incorpora optimizaciones que mejoran enormemente el rendimiento en estos casos. Remitentes

mantienen un marcador para las rutas, y el remitente mantiene un seguimiento de qué camino cada
Devolver al remitente es una optimización; en nuestra experiencia que sólo entra en acción
poligonales de paquetes. Cuando una A CK o N ACK llega, el A CK o N ACK- contar para el camino que el
con grandes incasts. En una topología de Clos que, esencialmente, hace PND sin pérdida de
paquete de datos se envía a través de se incrementa. Normalmente, en una topología de Clos corriendo
metadatos; un RTO solamente se activa cuando se corrompen paquetes o hay un fallo.
NDP, todos los caminos debería tener una proporción muy similar de una CK s a N ACK s. Sin embargo, si

un fallo ha causado la asimetría, algunos enlaces tendrán excesiva N ACK número de reproducciones.
La figura 4 muestra los resultados de una simulación FatTree 432-nodo que demuestra estos
Cuando el remitente permuta la lista de rutas, que elimina temporalmente los valores extremos del conjunto
mecanismos en acción, dando un CDF de la latencia de cuando un paquete es enviado a primero
de ruta.
cuando se Acked en el remitente, incluyendo cualquier retardo debido a las retransmisiones. La
curva muestra de permutación cuando cada host envía y recibe de otro anfitrión y espectáculos al
La pérdida de paquetes casi nunca debe ocurrir. Un remitente NDP que retransmite un paquete perdido
azar cuando cada host envía a un host aleatorio - en ambos casos estos se cargan plenamente la
siempre lo reenvía en un camino diferente. Un contador de pérdida de trayecto también se incrementa cada
FatTree, pero los restos mediana de latencia alrededor de 100 mu s. Las curvas Incast muestran lo
vez que se pierde un paquete. Cualquier ruta que son valores atípicos con respecto a la pérdida de paquetes
que ocurre cuando 100 nodos envían simultáneamente a un único nodo; difieren en el tamaño de
también se retiran temporalmente de la conjunto camino.
la transferencia. Con 135KB, todos los nodos envían el archivo completo en el primer RTT; esto
no sólo se traduce en altas tasas de recorte, sino que también se desborda la cola de cabecera,
Estos mecanismos permiten PND sea robusto para redes donde los caminos ya no tienen un
con un 25% de los encabezados de ser devuelto al remitente. A pesar de esto, el último paquete
rendimiento similar, por cualquier razón, con una mínima pérdida en el rendimiento. protocolos
llega a 11.055 mu s, sólo el 2% más tarde que el mejor tiempo teórico llegada. Con 1350KB, la
tradicionales que se basan en perflow ECMP trayectoria múltiple reenvío tienen más dificultades con
primera ventana
este tipo de fallos, y se basan en el encaminamiento para detectar y evitar los malos caminos.

34
redes de centros de datos de baja latencia y alto rendimiento. SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU.

datos tiene la misma cantidad de tiempo que las transferencias 135KB, pero el resto de la
transferencia se produce más fácilmente sin recortar y una latencia media de 95 mu s. Biblioteca
Proceso Figura 5: NDP implementación de
NDP Core
NDP software arquitec- tura.

Applica / en
control de congestión DPDK

El lector astuto puede ahora estar preguntándose lo que hace PND para el control de la
El espacio de usuario

congestión. La respuesta es sencilla: NDP realiza ningún control de congestión en absoluto en NIC
una topología de Clos. Como se verá, el control de congestión es simplemente innecesario con
la combinación correcta de la red modelo de servicio y protocolo de transporte. En términos las asimetrías, y con independencia de los patrones de tráfico. Aquí hablamos de las
generales, el control de la congestión en Internet sirve para dos funciones: evita la congestión limitaciones del PND fuera de dichas redes.
del colapso, y se garantiza la equidad. NDP logra tanto sin tener un mecanismo de adaptación En las topologías asimétricos tales como Bcube [19] y medusas [36], NDP se comportará mal
ventana explícita. porque va a rociar paquetes en diferentes caminos de longitud que son costosos para usar cuando
la red está muy cargado. Para tales redes, el remitente-basa per-trayectoria de control de trayectos

Evitar el colapso de congestión. Como vimos en la Sección 2.3, PND cambia la congestión del colapso múltiples congestión se ha demostrado que funcionan bien [31]; sigue siendo una pregunta abierta

de evitar CP asegurando que la mayor parte de un enlace es utilizado por los paquetes de datos. cómo conciliar el control de congestión por-camino con nuestro protocolo receptor conducido a

Collapse también podría ocurrir si los paquetes fueron descartados en el receptor, al igual que con base de tirar.

pre-Jacobson tiempos de espera de retransmisión [26] o con la fragmentación [27, 33]. Debido al

paquete de recorte, los remitentes del PND rara vez tienen que confiar en la RTO, por lo colapsar debido El control de congestión También sería deseable en las redes fuertemente exceso de solicitudes

a las retransmisiones innecesarias no es posible. donde está congestionado persistentemente el núcleo, como el diseño agresivo de NDP dará lugar a

paquetes continua recorte incluso después de la primera RTT. Mostramos en nuestra evaluación de

Colapso podría ocurrir si una gran fracción de los paquetes se descartan cerca del que NDP todavía proporciona un mejor rendimiento que DCTCP en tales casos (véase el § 6.3), pero

receptor que tiene ya desplazadas otros paquetes anterior en su camino [15]. Sin alguna forma de control de la congestión sería útil para reducir la carga del servidor de

embargo, en una topología de Clos con de NDP multitrayecto por paquete de retransmisión.

encaminamiento, los paquetes casi nunca se recortan en los enlaces ascendentes al


núcleo interruptores porque no es posible el tráfico concentrado allí. Cuando se recortan Una última cuestión se refiere a la implementación: cuando los interruptores P4 están

sobre enlaces ascendentes, esto es debido al balanceo de carga imperfecta; esto es, ampliamente desplegados en centros de datos, correr PND es tan simple como el despliegue de

donde el equilibrio de carga basado en el origen de NDP proporciona una victoria sobre la aplicación de conmutación (§ 4) y la pila de sistema final. Sin embargo, PND puede excluir a

por paquete aleatorio ECMP realiza mediante conmutadores. Incluso bajo una carga alta, la competencia el tráfico TCP. Es, sin embargo, fácil de garantizar la convivencia con TCP

los paquetes recortadas aquí comprenden una pequeña fracción de la cantidad total de sirviendo NDP y TCP desde diferentes colas, justo-cola entre ellos. La cola TCP será más

tráfico, por ejemplo, en simulaciones de un FatTree 128-nodo que ejecuta una matriz de grandes (100s de paquetes) mientras NDP del será pequeño (8 paquetes), junto con una cola

tráfico de permutación completa, donde cada nodo recibe de un nodo y envía a otro nodo de encabezado de tamaño similar.

en su LINKSPEED de 10 Gb / s, vemos 0.

4 APLICACIÓN
Significativo recorte en realidad sólo ocurre durante incasts, con la mayoría de los paquetes que se
Hemos puesto en marcha PND en los sistemas finales de Linux, un interruptor de software basado en
recortan en los enlaces de la parte superior del rack cambia a los ejércitos, y unos pocos ser recortado
DPDK [13], un interruptor de hardware mediante NetFPGA ASUMIR [41] plataforma de la de 10 Gb /
entre la vaina superior de los interruptores y menor vaina. Por lo tanto los paquetes que se recortan por
s, y en P4 [29]. También implementamos en el NDP htsim simulador de red de alta velocidad, basada
los interruptores TdR sólo en raras ocasiones han desplazado a los paquetes anteriormente en la
en centros de datos implementaciones de red de [31]. Utilizamos las implementaciones de Linux y
topología.
NetFPGA para demostrar el rendimiento a pequeña escala en el hardware real, y las simulaciones
Justicia. NDP logra una excelente equidad sin necesidad de mecanismos adicionales. Todos los para demostrar propiedades de escalamiento de NDP. También hemos desarrollado una aplicación
flujos de la competencia comienzan con la misma ventana, así que no hay necesidad de P4 del conmutador PND como una prueba de concepto de que el procesamiento PND es lo
preocuparse por la convergencia. El punto principal cuando los flujos de competir es de capacidad suficientemente simple para ser desplegado fácilmente en interruptores programables.
para el receptor, y el receptor tiene una visión completa de lo que está sucediendo. equidad receptor

se logra mediante el uso de un esquema de encolamiento justo por paquetes en la cola de tracción

que pertenecen a diferentes conexiones. Por último, la injusticia deliberada es posible, ya que el
Implementación de Linux. El objetivo de nuestra implementación de Linux PND es investigar el
receptor conoce sus propias prioridades, y se puede tirar de tráfico de alta prioridad con más
rendimiento NDP y validar el diseño del protocolo NDP. Normalmente esperaríamos NDP a ser
frecuencia que el tráfico de baja prioridad.
implementado en el núcleo del sistema operativo para permitir un control preciso de la sincronización.

Para permitir la experimentación rápida, nuestro enfoque lugar implementa un PND en el espacio de
Un caso de injusticia que no puede ser manejado receptor es donde un flujo a uno
usuario, utilizando la biblioteca DPDK para lograr el acceso a la red de baja latencia, y el uso de un
compite con un receptor incast a otro receptor en el mismo interruptor TdR. mitiga NDP
núcleo especializado para asegurar la precisión de estimulación P ULL y retransmisiones de baja
tales injusticia en un RTT porque, después de eso, el receptor-estimulación de P ULL s
latencia. La arquitectura se muestra en la Figura 5. El NDP medie proceso núcleo acceso NIC y
elimina la sobrecarga.
mantiene la cola de entrada como todas las conexiones NDP deben compartir esto. El proceso de

núcleo también se encarga de retransmisiones rápidas causadas por N ACK s. Una biblioteca
Limitaciones de NDP proporciona la API NDP a las aplicaciones, e interactúa con el proceso de núcleo a través de
Nuestra evaluación experimental en § 5 y §6 PND muestra que está muy cerca de óptima en
topologías Clos cruzados provisionados totalmente, incluso

35
SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU. Handley et al.

Las colas interfaz de entrada

tabla Directprio

interfaz de colas Partido Ac.on


conmutación
árbitro de NDP Prioridad Prioridad salida de la
L2 * Prio = 1
entrada lógica Prioridad Prioridad

...
Lógica

Ingreso
tabla Setprio normal de
tabla Readregister
...

otro
cola
qs partidos Ac.on

Figura 6: arquitectura de conmutador NDP en NetFPGA-SUME Partido Ac.on


cola de
0 - 12KB Prio = 0 qs + =
* qs leídos prioridad
pkt.size

de
memoria compartida, pasando comandos como conectar y escucha a través de una memoria cíclica > 12KB Prio = 1, PND. Fl
registro AGS = HDR Truncar
comunicaciones, y los datos para cada socket activo a través de tres memorias cíclicas: RX, TX y RTX, y una datos

agrupación de almacenamiento intermedio compartido. La biblioteca también se encarga de retransmisiones de tabla de decremento

partido Prio Ac.on

Salida
paquetes debido a los tiempos de espera.

Salida
0 QS - = pkt.size• 
Los NDP centrales principales controles de bucle para nuevos registros de aplicación, ejecuta

comandos de instancias de la biblioteca, envía la primera RTT de paquetes desde el anillo TX de


Figura 7: NDP aplicación interruptor en P4.
nuevas conexiones, y trata los paquetes entrantes. datos que llegan, A CK y N ACK los paquetes se

colocan en el anillo RX de la toma de corriente adecuada. Al llegar P ULL paquetes s causa de datos a
para recortar el último paquete en la cola de paquetes o el paquete actual, para romper los efectos
ser enviados desde el anillo RTX o TX del zócalo, con RTX prioridad dada. Al llegar los paquetes de
de fase.
datos (o cabeceras) causa P ULL s que se añade a la cola de entrada.
El interruptor de NDP utiliza 63561 LUTs (utilizando 14,6% de la capacidad de la Virtex7),
77176 FlipFlops (8,9%) y 231 bloques de RAM (15,7%). En comparación, el interruptor de
Un hilo de tracción cola separada, que se ejecuta en su propio núcleo de la CPU, Retiros de
referencia L2 utiliza 11,4%, 8,1% y 13,2%, respectivamente, por lo que la complejidad añadida por
cola éstos P ULL s uno por uno en el momento apropiado y los envía; Actualmente este hilo
NDP es pequeño. De los recursos adicionales, el 80% se utiliza para las colas de salida de
hace girar para asegurar granularidad adecuada, pero en el futuro esta sobrecarga podría
prioridad.
evitarse con el apoyo NIC.
Los paquetes de datos también puede desencadenar la inicialización de un nuevo socket si el bit SYN está
Interruptor de puesta en práctica de NDP en P4. El diseño, que se muestra en la Fig. 7,

fijado y escuchar era conocida anteriormente. N ACK s se pasan a la biblioteca para evitar tiempos de espera no
supone la existencia de al menos dos colas entre las tuberías de entrada y salida, con el egress_priority

esenciales, pero el núcleo NDP también añade el índice de memoria intermedia correspondiente a anillo RTX de
metadatos de decidir qué paquete va en cada cola. Las modificaciones de NDP se

la toma de corriente, lo que permite la retransmisión muy rápido.


demuestran en el dispositivo simple interruptor suponiendo una interfaz de salida única,
pero podrían añadirse a cualquier conmutador P4 y fácilmente modificados para manejar

Desde NDP es un protocolo de cero-RTT, la conectar comando de la biblioteca sólo múltiples puertos de salida.

informa al núcleo NDP sobre un nuevo socket activo. Se establecerá la conexión cuando
se envían los datos. los escucha La aplicación necesita saber el tamaño de las dos colas por puerto para decidir si el paquete

informa de comando del núcleo NDP sobre un nuevo socket pasivo, sino que también se reserva un debe ser recortado. Con este fin, se podría aprovechar registros de tamaño actual de la cola para

número de enchufes para las conexiones entrantes porque la falta de un medio de apretón de manos tomar la decisión de si se debe enviar paquetes a la cola de prioridad o no; Sin embargo no todas

iniciales que debe estar preparado para aceptar los trenes de paquetes entrantes sobre la marcha. las plataformas P4 tendrán este registro, por lo que hemos decidido implementar un registro con
una funcionalidad similar contando todos los paquetes que entran en la memoria intermedia y los
paquetes que entran en la tubería de salida normal. Como tablas de ajuste / Acciones en P4
NDP habilitado para interruptores. Idealmente PND está el recorte y la cola de prioridad sería
único partido en paquetes de datos, utilizamos una tabla adicional ( Readregister) leer qs Del
implementado en ASIC de conmutación. Tenemos un prototipo de una solución de este tipo
registro y guardarlo como metadatos de paquetes. Si qs está por debajo del tamaño del búfer
utilizando la plataforma NetFPGA-ASUMIR [41], una plataforma de hardware reconfigurable
permitido, los paquetes se pasan en la cola normal. Una vez que llegamos a la puerta, se
con cuatro interfaces Ethernet de 10 Gb / s que incorporan una FPGA Xilinx Virtex-7 junto con
truncarán paquetes (usando una acción primitiva P4 llamada truncar) y se introduce en la cola de
QDRII + y recursos de memoria DDR3.
prioridad. NDP paquetes sin una carga útil de datos entran automáticamente en la cola de
prioridad, debido a la Directprio mesa. La tubería de salida sólo se ocupa de cola de tamaño de
Figura 6 muestra el diseño del interruptor NDP alto nivel. Los paquetes entran a través de una de
contabilidad: el qs
las interfaces de la de 10 Gb / s y se almacenan en una cola de entrada de interfaz de 36Kbit. El árbitro

de toma paquetes de las colas de entrada utilizando un déficit round-robin (DRR) política de

planificación, y las alimenta a la L2 lógica de conmutación a través de un bus de ancho de 200 MHz de
registro se reduce si el paquete procede de la cola normal.
256 bits, lo suficientemente rápido para soportar más de 40 Gb / s. Cuando muchos pequeños paquetes

llegan en una interfaz y muchos otros grandes llegan a los demás, asegura RRD que la cola de entrada

que recibe paquetes pequeños no se desborde.


5 EVALUACIÓN
Queremos entender cómo NDP llevará a cabo en grandes centros de datos con cargas de trabajo reales,

Después se toma una decisión de reenvío L2 convencional, el paquete llega a la lógica pero carecen de la capacidad de ejecutar este tipo de pruebas en este momento. En lugar perfilamos

NDP. Cada puerto de salida tiene una prioridad baja y una cola de salida de alta prioridad, nuestra implementación de Linux PND usando el interruptor NetFPGA NDP para comprender el

cada 12KByte larga. paquetes de control de NDP se envían a la cola de alta prioridad. Para desempeño de pequeña escala y cómo interactúa NDP con el sistema operativo anfitrión. A continuación,

los paquetes restantes, las comprobaciones lógicas NDP la longitud de la cola de baja se compara la implementación de Linux con nuestro simulador para determinar el grado en que los

prioridad, enqueuing el paquete si hay espacio. De lo contrario el paquete se recorta y se artefactos del mundo real impacto en la fidelidad de simulación. Finalmente evaluamos NDP en la

coloca en la cola de alta prioridad. Si esa cola está llena, el paquete se descarta. Nota que simulación para examinar la forma en que las escalas. Utilizamos una amplia gama de patrones de tráfico

la aplicación plena debe decidir si azar y escenarios, y comparar su comportamiento a

36
redes de centros de datos de baja latencia y alto rendimiento. SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU.

100 100

con el establecimiento de prioridades


90 90

TCP (sin dormir)


80
NDP TFO (sin 80
NDP Mediana
70 30 70
NDP 90%

tiempo de finalización Incast (ms)


60 60

TCP CDF

CDF (%)
óptimo teórico 200 220 240

sin priorización
TCP Mediana
dormir)
50 50

Ocioso
20

TFO
40 TCP 90% 40
(%)

30 30
20 10 20
10 10
0 0
0
0 50 100 150 200 250 300 350 400 0 200 400 600 800 1000
0 200 400 600 800 1000
Latencia (us) tamaño de la respuesta (KB) Flujo Tiempo de terminación (us)

Figura 8: El tiempo para realizar una 1KB RPC sobre Figura 9: incast-Siete-a uno con tamaños de archivos vary- ING en Figura 10: de prioridad a un corto flujo de más de seis flujos de
PND, Fast TCP abierto y TCP. nuestro banco de pruebas. largo para el mismo host.

MPTCP, DCTCP utilizando ECN en los interruptores, y DCQCN [40] utilizando sin pérdida en la simulación. Nuestro banco de pruebas es un 8-servidor de dos niveles topología FatTree

Ethernet. construido con seis cuatro puertos cambia NetFPGA PND.

También se realizaron pruebas con nuestro interruptor P4 PND usando el interruptor P4 de referencia Como nuestro primer experimento, nos encontramos con un incast 7 a 1: la aplicación
para verificar su corrección; omitimos resultados de estos ensayos debido a los malos resultados del frontend en un servidor hace peticiones simultáneas a los otros siete servidores, que respondió
interruptor de software P4 de referencia. de inmediato. El tráfico se concentrará en muchos interruptores en la topología, que puede
conducir a la falta de equidad para los servidores más remotas. Variamos el tamaño de las
respuestas incast, y medimos el tiempo de finalización de la última flujo. La Figura 9 muestra la
5.1 Linux Rendimiento NDP mediana y el percentil 90a tiempos de finalización para TCP y NDP para tamaños de respuesta
PND tiene como objetivo proporcionar un transporte de baja latencia. Para evaluar la latencia de entre 10 KB y 1 MB. NDP está dentro del 5% del tiempo óptima terminación teórica, y el
nuestra implementación de Linux, sin factores de confusión, conectamos dos servidores de percentil del 90% para NDP está dentro del 10% de la mediana; las dos líneas se superponen
back-to-back, y encontramos una aplicación que hace que repite las llamadas RPC, envío y en la figura.
recepción de 1 KB de datos para medir el retraso a nivel de aplicación. Comparamos nuestro
prototipo NDP a Linux kernel TCP y TCP Fast Open (TFO), una optimización TCP propuesto por el tiempo total de flujo medio de TCP también crece linealmente con el tamaño de la respuesta, pero

Google que permite el envío de datos sobre TCP SYN. Tenga en cuenta que TFO no garantiza PND es cuatro veces más rápido. flujos de medios de TCP no sufran los tiempos de espera,
que las conexiones se procesan sólo una vez, mientras que hace PND. recuperándose de la pérdida usando la retransmisión rápida. Hay varias otras razones por las que es

más lento TCP, incluyendo el enlace de tres vías, retrasos de interrupción, el procesamiento de pila,

copias adicionales de datos, planificación de procesos y respuestas subóptimas de congestión. Estos se


Como muestra la Figura 8 muestra, latencia mediana usando NDP es 62 μ s. TCP suman, perjudicando el tiempo de respuesta. TCP 90 percentil está dominado por los tiempos de espera
Abrir rápida toma cuatro veces más y TCP normal tarda cinco veces más. NDP RPC de retransmisión, como MinRTO es de 200 ms en Linux. Este impacto podría reducirse mediante la
latencia es comparable a RDMA latencia informó en trabajos recientes ([20], Fig. 6). reducción de MinRTO y deshabilitar retrasado un CK s evitarlos desencadenar retransmisiones espurias.

¿Cómo logra NDP tan baja latencia? Para entender, que también puso en práctica un sencillo silbido
aplicación sobre DPDK, y se midió la latencia con 1 KB pings. Se tarda sólo 22 mu s enviar un ping
Beneficios de la priorización. El diseño basado en la atracción de NDP le da un buen control sobre los
usando DPDK y obtener la respuesta. Esto implica que el procesamiento del protocolo NDP y
tiempos de finalización de flujo, especialmente en el caso común donde el enlace de destino es el cuello de
procesamiento de la solicitud (40 mu s) dominar el tiempo NDP RPC. NDP se basa en DPDK,
botella; esta conjuntos NDP, aparte de la mayoría de las soluciones existentes en el transporte está
dedicando un núcleo de procesamiento de paquetes, con tampones NIC asignan directamente al
construido alrededor de control de la congestión basados ​en el remitente.
espacio de usuario. Por el contrario, TCP utiliza interrupciones y también los datos de copias entre
núcleo y el espacio de usuario.
Examinamos el caso de que un host recibe un flujo corto de un emisor y de larga fluye de otros

seis remitentes; todos los flujos comienzan al mismo tiempo, así que hay una gran cantidad de
Para entender los beneficios conseguidos por PND, se analizó inicialmente el costo de interupts y
controversia sobre todo para el último salto en el primer tiempo de ida y vuelta. Por defecto, NDP
copias de paquetes, pero estos gastos eran, como máximo 50 mu s, por lo que no explican las grandes
estimulará a todos los remitentes 1 / 7 del enlace. En este caso, sin embargo, el receptor da prioridad a
diferencias que se observan, sobre todo en comparación con el TFO. Después de un examen más detenido,
corto flujo mediante el envío de sus tirones antes que los de los flujos de largo.
se encontró que los estados de sueño profundo CPU son los culpables de la mayor parte de la diferencia: ya

que tanto TFO y TCP dependen de las interrupciones, la CPU pasa al sueño profundo y se tarda más o
La figura 10 muestra los resultados para cuando el flujo de corto envía 200KB:. Medimos el
menos 160 mu s para despertar, gravemente inflar latencia. Nos desactivar los estados de sueño profundo
tiempo de finalización de flujo (FCT) cuando no hay tráfico compite (etiquetado como “inactivo”), y
que C1 y representamos gráficamente la latencia de TFO y TCP en la Fig. 8. TFO y TCP ahora lo hacen
comparar con el FCT la hora de competir con los otros seis emisores, tanto con y sin el
mejor, pero la latencia del PND sigue siendo un poco más de la mitad del de TFO y una tercera parte de la
establecimiento de prioridades. Priorización funciona muy bien: la FCT de los cortos aumenta el
TCP. En principio, TFO podría optimizarse adicionalmente para obtener un rendimiento similar al PND si se
flujo por sólo el 50 μ s la hora de competir con los largos flujos cuando se utiliza prioridad, en
dio la votación para los datos en lugar de utilizar las interrupciones.
comparación con 500 μ s cuando no lo es. Probamos tamaños de flujo que van de 10 KB a 1 MB:
en todos los casos, la diferencia entre la inactividad y la prioridad era menos de 50 μ s. Después de
la primera RTT, durante el cual también se entregan unas pocas decenas de paquetes desde los
En fundición. El patrón de tráfico difícil más de un protocolo de transporte de manejar con baja largos flujos, el flujo corto ocupa completamente el enlace del receptor hasta que termine.
latencia es incast. Vamos a evaluar pequeñas incasts usando nuestra pila Linux y
conmutadores NetFPGA y incasts más grandes

37
SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU. Handley et al.

10 25
100
Rendimiento (Gbps)

8 80 20

Incast FCT (us)


CDF (%)
6 60 15
CDF emisor 9000B
4 40
Experimental 10
2 20 Perfecto tira
perfecta 5
0 0 tirones experimentales
0
1 2 4 8 16 32 64 128 256 0,25 0,5 1 2 4 8 16 32 64 1500B
0 20 40 60 80 100 120
Ventana inicial (pkts) Latencia (us) Tamaño de flujo (KB)

Figura 11: Throughput como una función de IW Figura 12: Tire espaciamiento midieron en el emisor para Figura 13: El rendimiento Incast: perfecta frente a
en la simulación y la práctica diferentes tamaños de paquetes. separación de tracción medido.

6 SIMULACIÓN 10

Antes de pasar a experimentos a gran escala, examinamos cómo el comportamiento de nuestros 8 La Figura 14 por la

Rendimiento (Gbps)
diverge del simulador de la de nuestra implementación de Linux en el mismo escenario. Las principales corriente de
6 NDP
diferencias que hemos identificado son los retrasos de procesamiento principal, y el ritmo de P ULL s. Si rendimiento, matriz de
4 MPTCP
bien nuestro simulador de pasos perfectamente P ULL s, nuestra implementación no se puede. Para tráfico permutación,
DCTCP
comprender el efecto de los retardos de procesamiento, conectamos dos servidores de regreso a la 2 FatTree 432-nodo.
DCQCN
espalda y la medición de la conseguido el rendimiento como una función de la ventana inicial (IW). La 0

figura 11 muestra que para lograr similares throughput la ventana inicial del prototipo debe ser de 25 0 50 100 150 200 250 300 350 400

paquetes en lugar de 15 (es decir, 15KB mayor).; estos paquetes adicionales se almacenan en los
rango de flujo
sistemas de extremo, y se necesitan a los retrasos de procesamiento principal de cubierta no

modeladas por el simulador. Esto implica que la latencia del PND resultados de la simulación son un protocolo DCQCN propuesto que es, esencialmente, una forma de ejecución DCTCP a través
poco demasiado optimista. Sin embargo, no modeladas retrasos en el procesamiento de TCP son más de redes Ethernet sin pérdidas. NDP conmuta colas uso de salida 8 en paquetes que, para
altos, por lo que cualquier comparación de las simulaciones está ligeramente sesgada a favor de la asegurar un buen rendimiento, DCTCP y MPTCP utilizan 200 colas de salida de paquetes y
TCP. DCQCN utiliza 200 buffers por puerto, compartidos entre interfaces. DCTCP y DCQCN
umbrales de marcado son 30 y 20 paquetes, respectivamente, como se recomienda.

Fig. 12 muestra el espaciado real de P ULL s para ambos paquetes 1500B y 9000B, tal como se Fig. 14 muestra el rendimiento alcanzado por cada host en orden creciente. DCTCP y
mide por el remitente. Mientras que los valores de la mediana se ajustan a la separación de destino DCQCN utilizan un único camino y sufren de colisiones resultantes de ECMP: utilización
(1,2 mu s y 7.2 mu s respectivamente), hay algo de varianza con los paquetes 1500b. media es de alrededor de 40%, y hay algunos flujos que alcanzar menos de 1 Gb / s, a
pesar de ser la suficiente capacidad provisionados para ofrecer a cada flujo de 10 Gb / s.
Para observar el efecto de esta separación de tracción imperfecta, hemos añadido código para el Multipath TCP hace mucho mejor: la utilización es del 89%, y lo peor de flujo logra 6 Gb /
simulador que atrae a intervalos de extracción espaciado de la distribución medida experimentalmente. s. PND tiene una utilización del 92% y ofertas mucho mejor equidad a través de los flujos:
En primer lugar, nos re-encontramos con la transferencia de pares en la Figura 11 anterior.; el resultado incluso el flujo más lento se 9Gb / s.
marcado “Remitente CDF” se superpone a la curva “perfecto”: espaciado de tracción no afecta el

rendimiento debido a que la ventana es lo suficientemente grande para cubrir pequeñas “huecos” en P ¿Cuál es el efecto del tamaño de búfer en pequeños tiempos de finalización de flujo?
ULL s. A continuación, se corrió un experimento de permutación, donde cada nodo en una FatTree 432 Esperamos PND debe beneficiarse de buffers de red más pequeña, con DCTCP y DCQCN tener
nodo envía a un nodo y recibe desde otro nodo, cargando totalmente el centro de datos. Utilizamos 1500b tiempos de finalización de flujo más largos. Dos nodos intercambian varias veces 90KB
paquetes y se compararon tracción perfecta espaciado para tirar el espaciamiento de nuestros resultados transferencias a la latencia de la prueba, mientras que todos los demás nodos de cada fuente de
experimentales. La diferencia de rendimiento es 1,2%, lo que es insignificante. cuatro largos conexiones a un destino al azar en funcionamiento. Como no existe contención en el

origen o destino del 90KB flujos, esto pone a prueba el efecto de pie colas en la red en los flujos de

corto plazo por los anfitriones de otro modo de inactividad.


Por último, nos encontramos con un 200: Experimento 1 incast tamaño variable flujo incast y medir

el tiempo de finalización de la última flujo. Fig. 13 muestra, no hay diferencia discernible en los tiempos Un CDF de tiempos de terminación de flujo corto se muestra en la Fig. Peor latencia caso
de terminación de flujo cuando se utiliza espaciado imperfecto tirón. En conjunto, estos experimentos 15. del NDP es sólo dos veces el tiempo teórico de transferencia óptima en una red de reposo,
muestran que los artefactos del mundo real tienen un impacto mínimo sobre el PND y proporcionar y es tres veces más baja en la mediana y cuatro veces inferior en el 99% en comparación con
confianza en las predicciones basadas en los resultados de simulación a gran escala. DCTCP . La razón principal de esta diferencia es que los buffers del PND son mucho menores
que los alcanzados por DCTCP en una red de árboles grasa sobrecargado. DCQCN tiene un
poco peor rendimiento que DCTCP porque las tramas de pausa se activan de forma
6.1 Las comparaciones con las obras existentes esporádica. MPTCP logra el peor FCT de todas las soluciones, con una mediana y de la cola

Medimos la capacidad del PND a utilizar las redes de centros de datos Clos mediante la diez veces mayores que las de NDP, debido a su llenado codicioso de buffers de red. Durante

ejecución de una permutación: se trata de una matriz de tráfico del peor caso en que cada estos experimentos NDP andMPTCP logra 80% de utilización de la red, wheras DCTCP y

servidor abre una única conexión de larga duración a otro servidor aleatorio tal que cada DCQCN alcanzar ~ 75%.

servidor tiene exactamente una conexión entrante. Comparamos NDP con Multipath TCP [31], y
el recién DCTCP

38
redes de centros de datos de baja latencia y alto rendimiento. SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU.

100 300 100


90 90

tiempo de finalización Incast (ms)


250 MPTCP

Utilización de la red(%)
80 80
70 DCTCP
200 70
60 DCQCN
CDF (%)

NDP 150 60
50 NDP
40 DCTCP 50
100
30 DCQCN 40
20 MPTCP
50 30 MTU
10 0 20 9K MTU 8pkt Buffer, 1.5K
0 50 100 150 200 250 300 350 400 Número de servidores de
Buffer,
5 10 15 20 25 309K35MTU
40 10pkt Buffer,
0 0.5 1 1.5 2 2.5
6pkt buffer, 9K MTU 8pkt
tiempo de finalización de flujo (ms) fondo involucrado en incast Ventana iniciales (pkts)

Figura 15: FCT para 90KB fluye con dom ran- carga de Figura 16: El rendimiento Incast vs número de Figura 17: Efectos de la IW y tamaños de búfer interruptor en
fondo, 432 nodo FatTree. remitentes, FatTree 432-nodo. el rendimiento de permutación.
Larga flujo• 
15

Goodput (Gb
Totalización y el•  Incast tra FFI c• 
10
Cambiar• 
Flujo de largo DCTCP
5

/ s)
64 Flujos Incast
Figura 18: Montaje experimental 0
Interruptor
0,05 0,1 0,15 0,2 0,25 0,3 0,35 0,4
de Tor•  para medir el daño eral collat- de
incast en los flujos de cerca. 15

Goodput (Gb
Host 1•  Host 2•  10
Flujo de largo DCQCN
5

/ s)
A continuación, probar un patrón de tráfico incast donde un frontend aficionados a cabo el trabajo 64 Flujos Incast
0
a muchos servidores de back-end y luego recibe sus respuestas; estos casos de uso son comunes
0,06 0,08 0,1 0,12 0,14 0,16 0,18 0,2
en las aplicaciones web de búsqueda, entre otros. llegada simultánea de las respuestas provoca una
Goodput (Gb 15
enorme presión de amortiguamiento para el puerto del switch que conduce a la interfaz, lo que

resulta en pérdidas sincronizados. Variamos el número de servidores de back-end manteniendo 5 10 Flujo de largo NDP 64
/ s)

constante el tamaño de la respuesta (450KB) y medir los tiempos de finalización de flujo. En general, Flujos Incast
0
la última vez completado el flujo es la métrica de interés, pero en la Fig. 16 también muestra el
0,06 0,08 0,1 0,12 0,14 0,16 0,18 0,2
tiempo de finalización de los más rápidos de flujo para resaltar la “imparcialidad” de los diferentes
Tiempo (s)
esquemas.
Figura 19: El daño colateral causado por 64 fluya incast con DCTCP (arriba),
DCQCN (centro), NDP (abajo).
Incluso si usamos agresiva pequeños temporizadores de Vasudevan et al. [ 38], MPTCP (y cualquier

variante TCP-pérdida de la cola) se ve mermada por las pérdidas sincronizados que conducen a los AFC

grandes e impredecibles. DCTCP utiliza ECN para obtener retroalimentación temprana, así como la memoria

intermedia compartida interruptores grandes para absorber explosiones iniciales, por lo que lo hace mucho

mejor que TCP tradicional sobre los interruptores de eliminación de colas. DCTCP es, en promedio, sólo un métrica de interés aquí es la utilización total de la red: NDP alcanza el 92% y el 40% de

5% más lento que el óptimo teórico. DCQCN y NDP hacen aún mejor, con un plazo de ejecución sólo un 1% utilización DCTCP, lo mismo que la permutación que corre solo. Con DCQCN, sin

más lento de lo óptimo. embargo, la red sufre colapso de congestión: utilización cae a 17% como los disparadores
incast PFC, que afecta severamente el rendimiento de más fluye en el centro de datos.

A continuación, tenga en cuenta la extensión de los tiempos de finalización de flujo para los

diferentes protocolos. DCTCP tiene una amplia gama (tan alto como siete veces) entre su flujo más En nuestro segundo experimento, se muestra en la Fig. 18, se corre un flujo de larga vida para el

rápida y más lenta. NDP tiene una asignación muy equilibrado, con la toma de flujo más lento a lo host 1, a continuación, iniciar una vida corta patrón de tráfico de 64 a-1 incast al anfitrión 2, con cada

sumo 20% más de tiempo a fin del más rápido; esto es una consecuencia directa del interruptor de envío de flujo 900KB incast. Los anfitriones son en el mismo interruptor TdR. Los resultados se

PND. Por último, DCQCN tiene una asignación muy ajustado hasta el tamaño de la respuesta 350KB, muestran en la Fig. 19. Con DCTCP, la incast causa la pérdida tanto en el interruptor de TdR, y en el

cuando se opera en ECN-sistema de marcado (con un umbral menor que DCTCP). Más allá de eso, puerto switch de agregación que conduce a la TdR. Tanto el tiempo de flujo y los flujos incast tomar

las patadas de operación sin pérdidas y severamente en skews fluyen hora de entrega. algún tiempo para recuperarse. La ráfaga encima de 10 Gb / s a ​t = 0,17 aparece cuando

retransmisiones llegan, permitiendo que los datos ya recibidos para finalmente ser lanzado en el fin

de la aplicación.

También hemos habilitado el establecimiento de prioridades en el Plan Nacional de Desarrollo para un

único emisor incast: sus tirones serán colocados en la cabecera de la cola de entrada del receptor. La Con DCQCN, se evita la pérdida, y los flujos de incast terminar rápidamente (obsérvese la

priorización es muy eficaz: el tiempo de finalización del flujo preferido es sólo de 1 ms con 100 remitentes diferente eje x), pero PFC hace que los interruptores de aguas arriba que se detuvieron en

incast y 3.5ms con 432. repetidas ocasiones, impactando el flujo de largo. Este tipo de daño colateral debido a la pausa es
la desventaja principal de PFC.

6.1.1 Los efectos secundarios de Incast Tráfico Con PND, incast hace que el recorte en el primer RTT. El flujo a largo sufre una pequeña caída en

el rendimiento de menos de 1 ms debido a esta explosión inicial. Después de la primera RTT, el


¿Cómo afecta incast tráfico cercano? Llevamos a cabo dos experimentos separados, cada
receptor de pasos los restantes paquetes incast y se recupera el flujo de tiempo para conseguir el
uno relativo a un gran incast. En el primer experimento, el incast es vivió largo y corre junto a
rendimiento completo de nuevo.
una matriz de tráfico permutación. los

39
SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU. Handley et al.

5 Se realizó un experimento de permutación con topologías cada vez más grandes usando ocho
NDP, IW = 23 NDP,
4 IW = 10 NDP, IW = memorias intermedias de paquetes, 9KB MTU y IW de 30. Utilización de la red disminuye
1
suavemente desde 98% (128 nodo FatTree) a 90% en un FatTree 8192 nodo. NDP alcanza 5%
3
más de la utilización de MPTCP con ocho subflujos ([31], Fig. 2), mientras que el uso de menos de
sobrecarga ciento

2
una décima parte de sus buffers.
1

0 incast gran escala ¿Hay algún límite fundamental para el tamaño de un incast que NDP puede

1 10 100 1000 10000


hacer frente? Corrimos incasts que van de un flujo (sin incast) hasta 8000 los flujos simultáneos,

Tamaño de incast (flujos) cada uno de 270.000 bytes (30 paquetes) en un FatTree 8192-nodo y medimos el tiempo de

(A) Finalización overhead tiempo, más mejor posible terminación del flujo del último flujo. Fig 20A muestra la sobrecarga de tiempo como un porcentaje

. de la mejor tiempo de finalización de último flujo teórico.; esto supone el enlace para el receptor está
1.4 RTX (Bounces), IW = 23 completamente saturado hasta los últimos acabados de flujo, y cada paquete se recibe sólo una
RTX (Nacks), IW = 23 RTX
1.2 vez. Con un paquete de IW 23 (sugerido por la Fig. 11 como valor por defecto para el tráfico buena
(Bounces), IW = 10
Las retransmisiones por paquete

RTX (Nacks), IW = 10 RTX nonincast), pequeñas incasts ver los peores gastos generales, pero aún así terminan dentro del 2%
(Bounces), IW = 1
0.8 1
RTX (Nacks), IW = 1 de la óptima. Estos gastos se deben a las cabeceras enviadas en el primer RTT y debido a no
0.6
bastante abundante enlace del receptor en la final RTT. Para incasts más grandes, el tiempo de
0.4
sobrecarga es insignificante. Baja, aunque estos son los gastos generales, que pueden reducirse
0.2
aún más si la aplicación conoce un gran incast es probable. se muestran las curvas para las
0
1 10 100 1000 10000 ventanas iniciales de un diez paquetes y un paquete. Diez paquetes está cerca de la ventana más

Tamaño de incast (flujos) pequeña que puede llenar el tubo con una red sin carga y los interruptores de almacenamiento y

(b) los costes de retransmisión generales hacia adelante. Para incasts más pequeños de ocho flujos, la sobrecarga utilizando una sola

. paquete IW es alta, ya que hay necesidad de estar al menos ocho paquetes enviados por RTT para
Figura 20: Overhead vs tamaño de incast, FatTree 8192-nodo
llenar el enlace del receptor.

6.2 Análisis de sensibilidad


NDP utiliza muy pequeños tampones de conmutación y una ventana inicial fija (IW) en el
emisor; estos son los únicos dos parámetros en una red PND. El IW incorpora información
Aunque nos preocupamos más por el retraso, también es interesante examinar los remitentes
sobre la velocidad de cuello de botella y la latencia de la red, y será ajustado por los
pagan los costos para lograr este bajo retardo. Fig. 20B muestra el número medio de
administradores. Utilizamos la simulación para entender cómo estos parámetros de
retransmisiones por paquete, y el mecanismo (rebote de retorno al remitente o NACK) por el cual
rendimiento de impacto, y si un buen rendimiento necesita un ajuste cuidadoso.
el remitente fue informado de la necesidad de volver a enviar. Para incasts más pequeños, NACK
son el mecanismo principal. Por encima de 100 flujos, el retorno al remitente pasa a ser el
La métrica más importante aquí es el rendimiento de la matriz de tráfico peor de los casos, la
principal mecanismo. Por encima de 2000 los flujos, algunos paquetes sufren un segundo retorno
permutación. Variamos los valores para IW y medir el rendimiento medio conseguido por cada host
al remitente antes de conseguir a través. Incluso con las mayores incasts y un 23 IW-paquete, el
para una variedad de tamaños de búfer interruptor; representamos gráficamente los resultados en la
número medio de retransmisiones apenas supera uno. Sin embargo, lo que tendría sentido para
figura 17. En primer lugar, el aviso de que se necesita una IW de 20 paquetes para utilizar
aplicaciones que saben que van a crear una gran incast para reducir la ventana inicial.
plenamente la red; Además, cuando IW es menor que 15 el tamaño de las memorias intermedias del

conmutador no importa. Independientemente del valor de IW, utilizando ligeramente seis búferes de

paquetes subutiliza la red (90% de utilización). colas ligeramente más grande (8 paquetes) resultado
Remitente limitado tráfico. Considere el patrón de tráfico en la Fig. 21, donde host A envía a los
de la utilización de más de 95%; y este es el tamaño de la cola se ha utilizado en todo este
hosts B, C, D y E, y el anfitrión F también envía a anfitrión
documento. Por último, el aviso de cómo aumentar aún más el rendimiento disminuye ligeramente
E. Bajo incast normal, el tráfico a E se divide por igual entre las fuentes A y F, pero en este
IW: esto se debe a que se crea más presión búfer que resulta en más cabeceras. Al utilizar los
caso A no puede enviar suficiente para llenar la mitad del enlace de E. ¿Los tirones de E se
paquetes de 1,5 kb, un IW de treinta paquetes resultados en utilización de la red 95%. Los resultados
desperdicia?
son notables, dado el tamaño total de las memorias intermedias del conmutador en bytes es sólo
Hemos simulado este escenario; los rendimientos se indican en la Fig. 21. Tanto el enlace
12KB.
desde A y el enlace a E están saturados, y los cuatro flujos de origen por una división de la
capacidad casi perfectamente. ¿Cómo logra un buen resultado NDP tales? La razón es que realiza
E Fair Queuing en su cola de entrada. En E, siempre hay paquetes P ULL en cola para F. Sin
Para cargas de trabajo incast, un IW más pequeño es preferible como menos paquetes se recortan
embargo, como los paquetes de una llegan con menos frecuencia, los asegura cola justo que P
en la primera RTT. Hemos utilizado un IWof 30, tanto en la simulación y en el despliegue, salvo que se
ULL paquetes para A son enviados tan pronto como llegan los paquetes de datos pueden
indique lo contrario.
generarlos. Esto asegura E envía paquetes de extracción a una a la misma velocidad A envía
topologías más grandes. Aunque nuestro simulador a nivel de paquetes es rápido, todavía se
paquetes de datos a E. El resto de de E P ULL s ir a F, asegurando enlace de E permanece lleno.
necesitan decenas de minutos para simular una matriz de permutación en un nodo 432 FatTree,
B, C y D no pueden enviar P ULL S para un más rápido que los paquetes de datos de un llegan. Por
que es la topología se utilizó a lo largo de nuestra evaluación. El trabajo previo ha demostrado que
lo tanto P ULL s llegar a una más o menos por igual de B, C, D, y E, y esto asegura enlace de
la matriz de tráfico de permutación tiene comportamiento macroscópico similar para 128, 1024 y
salida de A es a la vez completa e igualmente compartido.
8192node árboles Fat [31] cuando 100 búferes de paquetes se utilizan en conjunción con Multipath
TCP. Son ocho topes de conmutación de paquetes suficientes para garantizar una alta utilización
con NDP en redes grandes también?

40
redes de centros de datos de baja latencia y alto rendimiento. SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU.

10 120
NDP, Med
100
8
DCTCP, Med
re F

Rendimiento (Gbps)
UN antes de Cristo mi 80
NDP, DCTCP
6

CDF (%)
NDP 60 alta, alta
UN → B 2,51 Gb / s A → C 2,50 Gb / s A → D 2,51 Gb / s A → E 4 MPTCP
40
2,38 Gb / s total de la A: 9.90Gb / s F → E 7,55 Gb / s NDP sin penalización en el trayecto
2
DCTCP 20

0 0
0 20 40 60 80 100 120 140 0.01 0.1 1 10 100
Total a E: 9.93Gb / s número de flujo
FCT (ms)

Figura 21: Topología limitada remitente y rendimientos Figura 22: Permutación rendimiento con fallos: un

obtenidos. interruptor de la base de enlace-pod superior se redujo a Figura 23: AFC para la web Facebook carga de trabajo en la
1 Gbps. topología de un exceso de solicitudes.

¿Quién necesita el recorte de paquetes? Una pregunta válida es si podemos obtener los beneficios de número de conexiones simultáneas por host y la carga medida mediante el examen de la
NDP sin cambiar los conmutadores de red. PHost [16] es un transporte activado por el receptor que se utilización del núcleo.
ejecuta muy pequeños almacenamientos intermedios de paquetes y por paquete ECMP, pero no lo Comparamos NDP con DCTCP y representar gráficamente la distribución tiempos de
utiliza paquete de recorte. Hemos implementado pHost cambiando TCP en htsim; remitentes pHost finalización de flujo de la figura 23. Corremos dos pruebas separadas:. Primero, corremos una red
ráfaga a velocidad de línea en el primer RTT para obtener el rendimiento del flujo de mejor corto. Para moderadamente cargado (cinco conexiones simultáneas por host) donde se recortan 40% de
entender los méritos de pHost y el valor añadido de recorte, nos encontramos en pHost gota de cola todos los paquetes enviados por hosts NDP por el interruptor TdR. En este caso, la mediana de
redes FatTree 432 nodos regulares con ocho búferes de paquetes. El incast 432-a-1 en la Fig. 16 toma FCT PND es la mitad de DCTCP de, y un tercero en el percentil 99.
1s pHost a 1,5 s para completar. Esto no sólo es diez veces peor que el NDP (140ms), también es 4-5

veces peor que MPTCP. También nos encontramos con una matriz de tráfico de permutación, A continuación, cargar la red aún más, con cada host abastecimiento de conexiones diez

encontrando que pHost sólo alcanza la utilización del 70% a pesar de su uso del paquete de simultáneamente a otras máquinas elegidas al azar. 70% de los paquetes se recortan en el primer

pulverización (NDP alcanza la utilización del 95%). conmutador TdR; esto es muy cerca de la peor de los casos, dada la red de núcleo es de 4: 1 un

exceso de solicitudes. A pesar de esto, lleva a cabo NDP firmeza, proporcionando un rendimiento

ligeramente mejor que DCTCP tanto en la mediana y la cola. NDP no sufre de la congestión del

Manejo de asimetría. Todas las redes que hemos probado hasta ahora son simétricas; En paquetes colapso; se observa que si un paquete lo hace más allá del interruptor de términos de referencia, es

por pozos de trabajo ECMP en tales escenarios. Es más difícil de hacer bien cuando las redes son probable que llegue a su destino, con una probabilidad de ser recortado de sólo el 2-5% es.

asimétricos, por ejemplo debido a fallos. Se realizó un experimento de permutación en una


topología de 128-nodo en el que la velocidad de un enlace entre un núcleo y el interruptor de vaina
superior se reduce a 1 Gbps. Los resultados en la Fig. 22 muestran que tanto NDP y MPTCP Para concluir, NDP es robusto incluso en esta red exceso de solicitudes, un mejor desempeño que

manejar el fracaso muy bien, ya que mantener información de congestión por cada ruta y el tráfico DCTCP. Esto no quiere decir que el PND debe ser utilizado como está en las redes congestionadas de

de tracción fuera de caminos congestionados. Los usos mecanismo de penalización en el trayecto forma masiva: el número de paquetes recortadas en estos casos es un desperdicio. Cuando se recortan

del PND (véase §3.2.3) es crucial en topologías asimétricas: sin ella no NDP bastante mal, con 15 la mayoría de los paquetes de un simple algoritmo de control de congestión podría reducir el ritmo de

flujos de llegar solo 3 Gbps de rendimiento. Unos flujos DCTCP también se ven afectados: el peor producción, evitando la sobrecarga persistente, pero no hay necesidad de ser tan conservadora NDP

golpe de conexión sólo alcanza 0.4Gbps. funciona bastante bien, sin control de la congestión.

Sobrecargar. En una topología Clos totalmente provisionado el comportamiento del PND es casi óptimo. Sin

embargo, no todos los centros de datos proporcionan un ancho de banda de la sección transversal completa; lo
7 RelatedWork
que sucede cuando se suscribe en exceso la red central, o cuando los tamaños de paquetes son más pequeños Hay un gran cuerpo de trabajo con el objetivo de abordar diversos aspectos de centro de datos de

que una MTU? En tales casos, esperamos NDP para recortar muchos paquetes, y también lograr una relación transporte: la mayoría se centra en cualquiera de baja latencia lograr [5,

de compresión más baja cuando se produce el recorte. 6, 16, 22, 28, 30] o de alto rendimiento [2, 12, 31]. Hemos discutido extensamente y en
comparación con los anteriores trabajos desplegados más relevantes, a saber DCTCP /
Utilizamos mediciones de la red de Facebook para configurar nuestro experimento [34]. La DCQCN de bajo retardo y MPTCP de alto rendimiento; Aquí repasamos el resto.
topología simulado es un FatTree de tres niveles que contiene 512 servidores conectados a través de

enlaces de 10 Gbps a interruptor TdR. La conectividad de enlace ascendente desde TdR a los pFabric [6] objetivos para más corto de flujo primera programación en el centro de datos escala por

conmutadores de agregación es cuatro veces menor que la conectividad de servidor, dando 4: 1 conmutación de paquetes en función de las prioridades estrictas. Mientras atraer en teoría, pFabric es

sobresuscripción. difícil de implementar, ya que confía anfitriones para priorizar correctamente su tráfico. Casco [5]

De los tres tipos de tráfico de red que se presentan en [34] (web, caché y Hadoop), reservas de capacidad para asegurar una baja latencia para los flujos y usos cortas colas fantasma para

podemos usar la menos favorable a NDP: el patrón de tráfico web tiene muy pequeños identificar el potencial de congestión; requiere paquete precisa la estimulación en los puntos finales.

paquetes, dando compresión deficiente, y casi sin bastidor-nivel de la localidad, significado que Fastpass [30] utiliza programación centralizada para lograr una baja latencia pero se scalelimited. Si uno

casi todo el tráfico debe atravesar el núcleo exceso de solicitudes. Los tamaños de flujo se han puede modificar las aplicaciones explícitamente plazos estatales, existe una amplia gama de propuestas

extraído de la distribución en [34] (Fig.6.a) y el flujo de llegadas son de circuito cerrado con un que ayudará incluyendo PDQ, Fecha tope consciente de centro de datos TCP (D 2 TCP) y D 3 [ 22, 37,

intersticio entre el flujo mediana de 1 ms. Variamos la carga aumentando la 39].

41
SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU. Handley et al.

PUNTUAL [28], un mecanismo de control de congestión alternativa a DCQCN para redes sin [8] R. Braden. RFC 1644: T / TCP - extensiones TCP para transacciones funcionales
especificación. Informe técnico, RFC Editor, julio de 1994. [9] P. Cheng, F. Ren, R. Shu, y C. Lin. Coger
pérdidas, se basa exclusivamente en RTT como un indicador de congestión. Al igual que con
todo el lote en una acción: Rapid
DCQCN, PUNTUAL no puede impedir por completo tramas de pausa y su impacto negativo en el notificación de pérdida de paquetes preciso en centros de datos. En Proc. Usenix INDE, 2014.

tráfico de red inocente. En general, las mayores limitaciones de todos estos trabajos es que sólo [10] Y. Cheng, J. Chu, S. Radhakrishnan, y A. Jain. RFC 7413: TCP abierto rápido.
Informe técnico, RFC Editor, diciembre de 2014. [11] J. Chu, N. Dukkipati, Y. Cheng, y M. Mathis. RFC
se centran en una latencia baja, haciendo caso omiso de utilización de la red o el rendimiento de
6928: El aumento de TCP
gran caudal. ventana inicial. Informe técnico, RFC Editor, abril de 2013. [12] A. Dixit, P. Prakash, Y. Hu, y R. Kompella.
En el impacto del paquete de pulverización en
Las redes de centros de datos. En Proc. IEEE INFOCOM 2013, 2013.
En el otro extremo del espectro, los investigadores han tenido mucho interés para hacer frente a
[13] Kit de desarrollo de Plano DPDK de datos. http://dpdk.org. Consultado el: 27/01/2017. [14] S. Floyd y V. Jacobson.
las colisiones debidas a por flujo ECMP con la programación centralizada en Hedera [2], a través de efectos de fase de tráfico en las puertas de enlace de paquetes conmutados.
SIGCOMM Comput. Commun. Rvdo., 21 (2): 26-42, abril 1991. [15] S. Floyd y J. Kempf. RFC 3714: IAB
cambios de protocolo en el paquete de Spraying [12] y Presto [21], o por medio de subflow- red
preocupaciones relacionadas con el control de congestión para
tratamiento en Conga [3] y el interruptor-rediseño de LocalFlow [35]. Estas obras no se dirigen a corto el tráfico de voz en internet. Informe técnico, RFC Editor, marzo de 2004. [16] PX Gao, A. Narayan, G.
fluyen los tiempos de finalización, y obtienen los AFC comparables a los de una red sin optimizar correr Kumar, R. Agarwal, S. Ratnasamy, y S. Shenker.
pHost: Distributed casi óptima Datacenter transporte a través de la red de Mercancías Tela. En Proc. ACM
grandes almacenamientos intermedios de paquetes.
conexto, 2015.
[17] A. Greenberg et al. VL2: una red de centros de datos escalable y flexible. En Proc.

PND destaca porque logra tanto de baja latencia y alto rendimiento en todas las ACM SIGCOMM, De agosto de 2009.
[18] R. Griffith, Y. Chen, J. Liu, A. Joseph, y R. Katz. Comprensión incast TCP
condiciones de tráfico. rendimiento colapso en centros de datos redes. En Proc. Wren taller, 2009.
[19] C. Guo, G. Lu, D. Li, H. Wu, X. Zhang, Y. Shi, C. Tian, ​Y. Zhang, y S. Lu.
Bcube: Un alto rendimiento, arquitectura de red centrada en el servidor para los centros de datos modulares. En Proc.
8 Conclusiones ACM SIGCOMM 2009.
[20] C. Guo, H. Wu, Z. Deng, G. Soni, J. Ye, J. Padhye, y M. Lipshteyn. rdma sobre
Presentamos NDP, una nueva arquitectura para centro de datos de red que incluye un
ethernet de materias primas de escala. En Proc. ACM SIGCOMM 2016, páginas 202-215. [21] K. Él, E.
algoritmo de interruptor de puesta en cola modificado, junto con el reenvío de trayectos Rozner, K. Agarwal, W. Felter, J. Carter, y A. Akella. Presto: Edge-
múltiples por paquete, y una novela protocolo de transporte que se aprovecha de estos de carga basado en el equilibrio de las redes de centros de datos rápidas. En Proc. ACM SIGCOMM 2015,

páginas 465-478.
mecanismos de la red. NDP exhibe excelente comportamiento de baja latencia, tanto en
[22] C.-Y. Hong, M. César, y PB Godfrey. Acabado fluye rápidamente con derecho preferente
nuestra aplicación, y en simulaciones a gran escala. Proporciona un mejor aislamiento entre Planificación. En Proc. ACM SIGCOMM 2012.

las diferentes cargas de trabajo que tales mecanismos DCQCN que se basan en Ethernet sin [23] IEEE DCB. 802.3bd - trama de control de MAC de control de flujo basado en la prioridad
Proyecto. http://www.ieee802.org/3/bd/, 2010. Reemplazando IEEE 802.3x Full Duplex y Flow Control. [24]
pérdidas para lograr un retardo bajo.
IEEE DCB.
802.1Qbb - basado en la prioridad de control de flujo.
http://www.ieee802.org/1/pages/802.1bb.html, 2011.
Nuestra implementación actual es moderadamente costoso en términos de recursos de CPU
[25] Infiniband Comercio Asociación. RoCEv2.
requeridos de los sistemas finales, debido a la necesidad de estimulación precisa de P ULL s y https://cw.infinibandta.org/document/dl/7781, Septiembre de 2014. [26] V. Jacobson y MJ Karels. evitación
retransmisiones de baja latencia. Ambas funciones serían muy simple para tarjetas de red Ethernet de la congestión y control. En Proc. ACM
SIGCOMM, Stanford, CA, agosto de 1988. [27] C. Kent y J. Mogul. La fragmentación considera perjudicial.
para poner en práctica; de hecho, tarjetas de red WiFi baratas ya se manejan las retransmisiones
En Proc. ACM SIG-
de paquetes y el tiempo cuidadoso. Se NDP a ser desplegado a escala, esperamos que la NIC COMM, De agosto 1.987.

inteligentes reduciría en gran medida la carga de la CPU del PND. [28] R. Mittal, VT Lam, N. Dukkipati, E. Blem, H. Wassel, M. Ghobadi, A. Vahdat,
Y. Wang, D. Wetherall, y D. Zats. Oportuna: Rkt basados ​control de congestión para el centro de datos.
En Proce. ACM SIGCOMM 2015, páginas 537-550. [29] El Consorcio Idioma P4. P4 dieciséis Versión del lenguaje
de especificación 1.0.0. 2016. [30] J. Perry, A. Ousterhout, H. Balakrishnan, D. Shah, y H. Fugal. Fastpass: Un

Agradecimientos centralizado "cero-cola" centro de datos de red. En Proc. ACM SIGCOMM 2014.
[31] C. Raiciu, S. Barre, C. Pluntke, A. Greenhalgh, D. Wischik, y M. Handley.
Este trabajo fue financiado en parte por el proyecto SSICLOPS H2020 (644866). Nos
La mejora de los centros de datos de rendimiento y robustez con Multipath TCP. En Proc. ACM SIGCOMM, De agosto
gustaría dar las gracias a Giuseppe Lettieri, los revisores anónimos y nuestro pastor Amin de 2011.
Vahdat por sus comentarios muy útiles que nos ayudó a mejorar la calidad de este trabajo. [32] K. Ramakrishnan, S. Floyd, y D. Negro. RFC 3168: la adición de explícita
notificación de congestión (ECN) a IP. Informe técnico, RFC Editor, septiembre de 2001. [33] A. Romanow y S. Floyd.
Dinámica de tráfico TCP a través de redes de cajeros automáticos. En Proc.
ACM SIGCOMM, Londres, 1994.
[34] A. Roy, H. Zeng, J. Bagga, G. Porter, y AC Snoeren. Dentro de lo social
Referencias
(Centro de datos) a la red de la red. En Proc. ACM SIGCOMM 2015, páginas 123-137. [35] S. Sen, D. Shue,
[1] M. Al-tarifas, A. LOUKISSAS, y A. Vahdat. A escalable, los datos de los productos básicos centro S. Ihm, y MJ Freedman. Escalable, óptimo flujo de encaminamiento en
red de arquitectura. En Proc. ACM SIGCOMM, Agosto de 2010. [2] M. Al-tarifas, S. Radhakrishnan, B. centros de datos a través de balanceo de enlace local. En Proc. ACM conexto 2013, páginas 151-162. [36] A.
Raghavan, N. Huang, y A. Vahdat. Hedera: Singla, C.-Y. Hong, L. Popa, y PB Godfrey. Medusas: redes de datos
la programación de flujo dinámico de redes de centros de datos. En Proc. Usenix INDE, 2010. centros de azar. En Proc. Usenix INDE 2012.
[3] M. Alizadeh, T. Edsall, S. Dharmapurikar, R. Vaidyanathan, K. Chu, A. Fingerhut, [37] B. Vamanan, J. Hasan, y T. Vijaykumar. tcp centro de datos fecha límite-conscientes (d2tcp).
VT Lam, F. Matus, R. Pan, N. Yadav, y G. Varghese. CONGA: Distributed congestión consciente de ACM SIGCOMM ordenador examen de la comunicación, 42 (4): 115-126, 2012. [38] V. Vasudevan, A.
equilibrio de carga para los centros de datos. En Proc. ACM SIGCOMM Phanishayee, H. Shah, E. Krevat, DG Andersen, GR Ganger,
2014, páginas 503-514. GA Gibson, y B. Mueller. Segura y retransmisiones TCP de grano fino eficaces para el centro de datos de
[4] M. Alizadeh, A. Greenberg, DA Maltz, J. Padhye, P. Patel, B. Prabhakar, S. Sen comunicación. En Proc.ACM SIGCOMM 2009, páginas 303-314. [39] C. Wilson, H. Ballani, T. Karagiannis, y A.
Gupta, y M. Sridharan. centro de datos TCP (DCTCP). En Proc. ACM SIGCOMM, Rowtron. Nunca mejor que tarde:
De agosto de 2010. cumplimiento de plazos en las redes de centros de datos. En Proc. SIGCOMM '11, 2011.
[5] M. Alizadeh, A. Kabbani, T. Edsall, B. Prabhakar, A. Vahdat, y M. Yasuda. [40] Y. Zhu, H. Eran, D. Firestone, C. Guo, M. Lipshteyn, Y. Liron, J. Padhye, S. de lluvia
Menos es más: el comercio de un poco de ancho de banda de ultra baja latencia en el centro de datos. En del, MH Yahia, y M. Zhang. El control de congestión para rdma a gran escala despliegues mentos. En Proc.
Proc. Usenix INDE, páginas 253-266, 2012. ACM SIGCOMM 2015, páginas 523-536. [41] N. Zilberman, Y. Audzevich, GA Covington, y AW Moore.
[6] M. Alizadeh, S. Yang, M. Sharif, S. Katti, N. McKeown, B. Prabhakar, y NetFPGA
S. Shenker. pFabric: el transporte del centro de datos casi óptima mínima. En Proc. ACM SIGCOMM 2013. ASUMIR: Hacia 100 Gbps de productos básicos como la investigación. Micro, 34 (5), 2014.

[7] T. Benson, A. Akella, y DA Maltz. las características del tráfico de red de datos
centros en el salvaje. En Actas de la conferencia SIGCOMM 10 de ACM en la medición de Internet, páginas
267-280. ACM, 2010.

42

También podría gustarte