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.
bloqueo, las aplicaciones de hoy en día a menudo la reutilización de las conexiones TCP a través de múltiples
peticiones para amortizar el coste de latencia del protocolo de enlace TCP.
¿Es posible mejorar la somuch pila de protocolos que cada petición podría utilizar una nueva
conexión y, al mismo tiempo esperar para acercarse a la latencia y ancho de banda en bruto de
la red subyacente, incluso bajo carga pesada? Vamos a demostrar que estos objetivos son
alcanzables, pero para ello implica cambios en la forma se encamina el tráfico, cómo hacer frente
a los interruptores de sobrecarga, y lo más importante, requiere un protocolo de transporte
completamente diferentes de los utilizados en la actualidad. Antes de describir nuestra solución
en el § 3, en primer lugar destacamos los puntos arquitectónicos clave que deben ser
considerados.
2.1 de extremo a extremo demandas de servicio
¿Qué aplicaciones quieren de una red de centros de datos?
Ubicación de la Independencia. No debería importar qué máquina en un centro de datos los
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
en sección transversal que el núcleo de red no debería ser un cuello de botella.
Baja latencia. Clos redes pueden proporcionar ancho de banda, módulo problemas con el equilibrio de carga
entre los caminos, pero a menudo están a la altura en la prestación de servicio de baja latencia. comportamiento
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.
En fundición. Datacenter cargas de trabajo a menudo requieren el envío de peticiones a un gran
número de trabajadores y el manejo de sus respuestas casi simultáneos, causando un problema
llamado incast. Una buena pila de red debe proteger a las solicitudes de los efectos secundarios de
los patrones de tráfico incast con gracia mientras que proporciona una baja latencia.
Prioridad. También es común para un receptor para manejar muchos flujos de entrada
correspondientes a diferente solicita simultáneamente. Por ejemplo, puede haber desplegaron
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
segunda solicitud. Muchas aplicaciones necesitan todas las respuestas a una solicitud antes de
que puedan proceder. Una propiedad muy deseable es que el receptor sea capaz de priorizar el
tránsito de llegada de los rezagados. El receptor es la única entidad que puede priorizar
dinámicamente su tráfico de entrada, y este diseño protocolo de impactos.
2.2 Protocolo de transporte
protocolos de transporte de los centros de datos actuales satisfacen algunos de estos requisitos de la
aplicación, pero que satisface todos los coloca algunas demandas extraordinarias de los centros de datos
protocolos de transporte.
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,
pero esta seguridad posturas y problemas de corrección.
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
disponible, con optimismo enviar una ventana inicial completa, y luego reaccionar adecuadamente cuando
no lo es. A diferencia de la Internet, las soluciones más simples son posibles en los centros de datos
30
Handley et al.
ambientes, porque las velocidades de enlace y los retardos de red (excepto para poner en cola los retrasos)
pueden principalmente ser conocidos de antemano.
Por paquete ECMP. Un problema con topologías Clos es que perflow ECMP hashing de los flujos a
caminos puede causar colisiones de flujo no deseados; un despliegue [20] encontró este rendimiento
reducido en un 40%. Para las transferencias grandes, protocolos de trayectoria múltiple como
MPTCP pueden establecer suficientes subflujos para encontrar caminos no utilizados [31], pero poco
pueden hacer para ayudar con la latencia de las transferencias muy cortos. La única solución en
este caso es la raya en varias rutas en función de cada paquete. Esto complica el diseño de
protocolo de transporte.
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
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
protocolo de transporte debe ser capaz de establecer el estado de conexión no importa qué
paquete desde la ventana inicial es primero en llegar.
Optimizado para Incast. Aunque las redes Clos están bien aprovisionada para el núcleo de la capacidad, el
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
causar tasas de pérdida de paquetes de alto, sobre todo si el protocolo de transporte es agresivo en el
primer RTT. Para manejar esto con gracia requiere un poco de ayuda de los interruptores.
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
están estrechamente acoplados, y necesidad de ser optimizadas de manera integral. De particular
relevancia es lo que sucede cuando se congestiona un puerto del switch. El modelo de servicio interruptor
influye mucho en el espacio de diseño de ambos algoritmos de control de protocolo y de congestión, y las
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
sistemas de extremo a congestión de la red inferir y aumenta la importancia del comportamiento de
sobrecarga elegante.
Pérdida como un mecanismo de retroalimentación congestión tiene la ventaja de
que los paquetes cerrados no usar el ancho de banda de cuello de botella, y la pérdida
de solamente influye en los flujos de atravesar la congestionada enlace no todos los
esquemas tienen estas propiedades. La desventaja es que conduce a la incertidumbre
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
red, por lo que necesita para mantener las colas cortas [4], que a su vez Restringir los
esquemas de control de congestión que puede utilizar. parejas también la pérdida mal
con por paquete de trayectos múltiples de reenvío; debido a que los paquetes de un
flujo llegan fuera de orden,
ECN ayuda significativamente. DCTCP utiliza ECN [32] con un umbral aguda para el marcado de
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
menos beneficios debido a que el flujo no tiene tiempo de reaccionar a la retroalimentación ECN. En la
práctica interruptores utilizan grandes buffers compartidos en conjunción con ECN y esto reduce las
pérdidas incast, pero temporizadores de retransmisión deben ser menos
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]
pueden ocurrir, resultando en rendimiento injusta. Las curvas de trazos en la Figura 2 muestran la
goodput media de la peor rendimiento 10% de los flujos. efectos de fase CP pueden hacer muy injusto,
aunque se nota que esta figura muestra resultados de la simulación; efectos de fase de la vida real a
veces se pueden reducir la variabilidad en el tiempo de las transmisiones de paquetes debido a la
remitentes. Tal equilibrio de carga es importante para lograr un muy bajo retardo. Si utilizamos
muy pequeñas colas de paquetes de datos (sólo ocho paquetes), nuestros experimentos
muestran que este simple esquema puede aumentar la capacidad máxima de la red hasta en un
10% a través de una selección de pasos aleatoria perpacket.

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

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.
src Colina agg Núcleo agg Colina
t podar
t encabezamiento
t RTX
RTX 9
! 9 1 a 9!
9 4
9 !
9 !
!
t enqueue
t llegar
Figura 3: Paquete de recorte permite la retransmisión de bajo retardo
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
fuente 9 se recorta. Después de paquetes acabados 1 se reenvían, cabecera del paquete de 9
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
7 todavía se está remitiendo. El vínculo con el destino nunca pasa inactivo, y el paquete llega
al 9 t llegar ,
Al mismo tiempo, habría llegado si PFC había impedido su pérdida pausando el interruptor
aguas arriba.
En una topología de Clos empleo de trayectoria múltiple por paquete, los puntos calientes única que se
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
enviar datos a la misma, por lo que está en mejor posición para decidir qué hacer después de la primera
RTT de una conexión. Después de enviar una ventana completa de datos a velocidad de línea, NDP
remitentes detener el envío. A partir de entonces, el protocolo se receiverdriven. Un PND solicitudes
receptor paquetes desde los remitentes, el ritmo al envío de dichas solicitudes de manera que los paquetes
de datos que provocan llegan a una velocidad que coincide con la velocidad del enlace del receptor. Los
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:
• El emisor envía una ventana completa de los datos sin esperar una respuesta. Los paquetes de
datos llevan los números de secuencia de paquetes.
• Para cada encabezado 3 que llega, el receptor envía inmediatamente una N ACK para
informar al remitente para preparar el paquete para la retransmisión (pero aún no enviarlo).
• Para cada paquete de datos que llega, el receptor envía inmediatamente una A CK para
informar al remitente que el paquete llegó, por lo que el tampón puede ser liberado.
• Por cada encabezado o paquete que llega, el receptor añade una PAG ULL
paquete a su cola de entrada que, a su debido tiempo, se enviará al remitente
correspondiente. Un receptor sólo tiene una cola de entrada, compartido por todas las
conexiones de las que es el receptor.
• 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
paquetes de datos que provocan desde el emisor a continuación llegan a velocidad de enlace del
receptor. Tire de paquetes de diferentes conexiones están comunicadas bastante por defecto, o
con estricta priorización cuando un flujo tiene mayor prioridad.
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
SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU.
dst
• Cuando un P ULL paquete llega en el remitente, el remitente enviar tantos paquetes de datos como los
incrementos del contador de tracción por. Cualquier paquete en cola para su retransmisión se envían en
1 !
primer lugar, seguido por los nuevos datos.
23 • Cuando el remitente se queda sin datos para enviar, marca el último paquete. Cuando llega el
!!!
último paquete, el receptor elimina cualquier paquete de tracción para que el remitente de su cola de
5 !!!
6 entrada para evitar el envío de paquetes de tracción innecesarios. Cualquier dato posteriores al
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
!!
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
almacenar-andforward cambia la topología FatTree un 10 Gb / s, cada paquete lleva
7.2 mu s Para serializar. Teniendo en cuenta la cola de prioridad del Plan Nacional de Desarrollo, la red
peor de los casos RTT es de aproximadamente 400 mu s, con RTT típicos son mucho más corto. Esto
paquetes corruptos.
HALAR paquetes realizan un papel similar al del reloj A CK- de TCP, pero son por lo general
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
relativamente largo en la cola de entrada del receptor antes del marcapasos permite que sean
enviados, pero no queremos retrasar también A CK s porque hacerlo requiere estar mucho más
conservador, con tiempos de espera de retransmisión.
El comportamiento emergente es que la primera RTT de datos en una conexión se empuja, y RTT
posteriores de los datos se tira a fin de llegar a velocidad de línea del receptor. En un escenario
incast, si muchos remitentes envían al mismo tiempo, muchos de su primera ventana de paquetes
será recortado, pero asegura posteriormente receptor de tracción que la tasa de llegada agregada de
todos los remitentes coincide con la velocidad del enlace del receptor, con pocas o ninguna paquetes
que están siendo recortados.
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
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
robusto a reordenamiento, ya que no tiene que hacer inferencias acerca de la pérdida de números de
secuencia de otros paquetes. Sin embargo, la reordenación todavía tiene que ser tenido en cuenta.
Aunque P ULL paquetes son prioridad-en cola, lo hacen los paquetes de datos no adelantarse, así P
ULL los paquetes enviados por caminos diferentes llegan a menudo fuera de orden, el aumento de la
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 enviado pull. A la recepción de un P ULL, el emisor transmite tantos paquetes como el número de
secuencia de tracción aumenta en. Por ejemplo, si un P ULL se retrasa, el siguiente P ULL enviado de forma
puede llegar primero a través de un camino diferente, y tirará de dos paquetes en lugar de uno. Esto reduce
explosividad 'un poco.
3.2.2 El primer RTT
A diferencia de TCP, en el que el apretón de manos SYN / SYN-ACK pasa por delante de intercambio de
datos, deseamos datos del PND para ser enviados en el primer RTT. Esto añade tres nuevos requisitos:
• Ser robusto a las solicitudes que las direcciones IP de origen de la parodia.
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.
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.
control de congestión
El lector astuto puede ahora estar preguntándose lo que hace PND para el control de la
congestión. La respuesta es sencilla: NDP realiza ningún control de congestión en absoluto en
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
generales, el control de la congestión en Internet sirve para dos funciones: evita la congestión
del colapso, y se garantiza la equidad. NDP logra tanto sin tener un mecanismo de adaptación
ventana explícita.
Evitar el colapso de congestión. Como vimos en la Sección 2.3, PND cambia la congestión del colapso
de evitar CP asegurando que la mayor parte de un enlace es utilizado por los paquetes de datos.
Collapse también podría ocurrir si los paquetes fueron descartados en el receptor, al igual que con
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
a las retransmisiones innecesarias no es posible.
Colapso podría ocurrir si una gran fracción de los paquetes se descartan cerca del
receptor que tiene ya desplazadas otros paquetes anterior en su camino [15]. Sin
embargo, en una topología de Clos con de NDP multitrayecto por paquete de
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
sobre enlaces ascendentes, esto es debido al balanceo de carga imperfecta; esto es,
donde el equilibrio de carga basado en el origen de NDP proporciona una victoria sobre
por paquete aleatorio ECMP realiza mediante conmutadores. Incluso bajo una carga alta,
los paquetes recortadas aquí comprenden una pequeña fracción de la cantidad total de
tráfico, por ejemplo, en simulaciones de un FatTree 128-nodo que ejecuta una matriz de
tráfico de permutación completa, donde cada nodo recibe de un nodo y envía a otro nodo
en su LINKSPEED de 10 Gb / s, vemos 0.
Significativo recorte en realidad sólo ocurre durante incasts, con la mayoría de los paquetes que se
recortan en los enlaces de la parte superior del rack cambia a los ejércitos, y unos pocos ser recortado
entre la vaina superior de los interruptores y menor vaina. Por lo tanto los paquetes que se recortan por
los interruptores TdR sólo en raras ocasiones han desplazado a los paquetes anteriormente en la
topología.
Justicia. NDP logra una excelente equidad sin necesidad de mecanismos adicionales. Todos los
flujos de la competencia comienzan con la misma ventana, así que no hay necesidad de
preocuparse por la convergencia. El punto principal cuando los flujos de competir es de capacidad
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
receptor conoce sus propias prioridades, y se puede tirar de tráfico de alta prioridad con más
frecuencia que el tráfico de baja prioridad.
Un caso de injusticia que no puede ser manejado receptor es donde un flujo a uno
compite con un receptor incast a otro receptor en el mismo interruptor TdR. mitiga NDP
tales injusticia en un RTT porque, después de eso, el receptor-estimulación de P ULL s
elimina la sobrecarga.
Limitaciones de NDP
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.
Biblioteca
Proceso Figura 5: NDP implementación de
NDP Core
NDP software arquitec- tura.
Applica / en
DPDK
El espacio de usuario
NIC
las asimetrías, y con independencia de los patrones de tráfico. Aquí hablamos de las
limitaciones del PND fuera de dichas redes.
En las topologías asimétricos tales como Bcube [19] y medusas [36], NDP se comportará mal
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
múltiples congestión se ha demostrado que funcionan bien [31]; sigue siendo una pregunta abierta
cómo conciliar el control de congestión por-camino con nuestro protocolo receptor conducido a
base de tirar.
El control de congestión También sería deseable en las redes fuertemente exceso de solicitudes
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
que NDP todavía proporciona un mejor rendimiento que DCTCP en tales casos (véase el § 6.3), pero
alguna forma de control de la congestión sería útil para reducir la carga del servidor de
retransmisión.
Una última cuestión se refiere a la implementación: cuando los interruptores P4 están
ampliamente desplegados en centros de datos, correr PND es tan simple como el despliegue de
la aplicación de conmutación (§ 4) y la pila de sistema final. Sin embargo, PND puede excluir a
la competencia el tráfico TCP. Es, sin embargo, fácil de garantizar la convivencia con TCP
sirviendo NDP y TCP desde diferentes colas, justo-cola entre ellos. La cola TCP será más
grandes (100s de paquetes) mientras NDP del será pequeño (8 paquetes), junto con una cola
de encabezado de tamaño similar.
4 APLICACIÓN
Hemos puesto en marcha PND en los sistemas finales de Linux, un interruptor de software basado en
DPDK [13], un interruptor de hardware mediante NetFPGA ASUMIR [41] plataforma de la de 10 Gb /
s, y en P4 [29]. También implementamos en el NDP htsim simulador de red de alta velocidad, basada
en centros de datos implementaciones de red de [31]. Utilizamos las implementaciones de Linux y
NetFPGA para demostrar el rendimiento a pequeña escala en el hardware real, y las simulaciones
para demostrar propiedades de escalamiento de NDP. También hemos desarrollado una aplicación
P4 del conmutador PND como una prueba de concepto de que el procesamiento PND es lo
suficientemente simple para ser desplegado fácilmente en interruptores programables.
Implementación de Linux. El objetivo de nuestra implementación de Linux PND es investigar el
rendimiento NDP y validar el diseño del protocolo NDP. Normalmente esperaríamos NDP a ser
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
usuario, utilizando la biblioteca DPDK para lograr el acceso a la red de baja latencia, y el uso de un
núcleo especializado para asegurar la precisión de estimulación P ULL y retransmisiones de baja
latencia. La arquitectura se muestra en la Figura 5. El NDP medie proceso núcleo acceso NIC y
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
proporciona la API NDP a las aplicaciones, e interactúa con el proceso de núcleo a través de
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
para verificar su corrección; omitimos resultados de estos ensayos debido a los malos resultados del
interruptor de software P4 de referencia.
5.1 Linux Rendimiento NDP
PND tiene como objetivo proporcionar un transporte de baja latencia. Para evaluar la latencia de
nuestra implementación de Linux, sin factores de confusión, conectamos dos servidores de
back-to-back, y encontramos una aplicación que hace que repite las llamadas RPC, envío y
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
Como nuestro primer experimento, nos encontramos con un incast 7 a 1: la aplicación
frontend en un servidor hace peticiones simultáneas a los otros siete servidores, que respondió
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
mediana y el percentil 90a tiempos de finalización para TCP y NDP para tamaños de respuesta
entre 10 KB y 1 MB. NDP está dentro del 5% del tiempo óptima terminación teórica, y el
percentil del 90% para NDP está dentro del 10% de la mediana; las dos líneas se superponen
en la figura.
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.
10
100
Rendimiento (Gbps)
8 80
CDF (%)
6 60
CDF emisor
4 40
Experimental
2 20
perfecta
0 0
1 2 4 8 16 32 64 128 256 0,25 0,5 1 2 4 8 16 32 64 1500B
Ventana inicial (pkts)
Figura 11: Throughput como una función de IW Figura 12: Tire espaciamiento midieron en el emisor para
en la simulación y la práctica diferentes tamaños de paquetes.
6 SIMULACIÓN
Antes de pasar a experimentos a gran escala, examinamos cómo el comportamiento de nuestros
diverge del simulador de la de nuestra implementación de Linux en el mismo escenario. Las principales
diferencias que hemos identificado son los retrasos de procesamiento principal, y el ritmo de P ULL s. Si
bien nuestro simulador de pasos perfectamente P ULL s, nuestra implementación no se puede. Para
comprender el efecto de los retardos de procesamiento, conectamos dos servidores de regreso a la
espalda y la medición de la conseguido el rendimiento como una función de la ventana inicial (IW). La
figura 11 muestra que para lograr similares throughput la ventana inicial del prototipo debe ser de 25
paquetes en lugar de 15 (es decir, 15KB mayor).; estos paquetes adicionales se almacenan en los
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
poco demasiado optimista. Sin embargo, no modeladas retrasos en el procesamiento de TCP son más
altos, por lo que cualquier comparación de las simulaciones está ligeramente sesgada a favor de la
TCP.
Fig. 12 muestra el espaciado real de P ULL s para ambos paquetes 1500B y 9000B, tal como se
mide por el remitente. Mientras que los valores de la mediana se ajustan a la separación de destino
(1,2 mu s y 7.2 mu s respectivamente), hay algo de varianza con los paquetes 1500b.
Para observar el efecto de esta separación de tracción imperfecta, hemos añadido código para el
simulador que atrae a intervalos de extracción espaciado de la distribución medida experimentalmente.
En primer lugar, nos re-encontramos con la transferencia de pares en la Figura 11 anterior.; el resultado
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
ULL s. A continuación, se corrió un experimento de permutación, donde cada nodo en una FatTree 432
nodo envía a un nodo y recibe desde otro nodo, cargando totalmente el centro de datos. Utilizamos 1500b
paquetes y se compararon tracción perfecta espaciado para tirar el espaciamiento de nuestros resultados
experimentales. La diferencia de rendimiento es 1,2%, lo que es insignificante.
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
de terminación de flujo cuando se utiliza espaciado imperfecto tirón. En conjunto, estos experimentos
muestran que los artefactos del mundo real tienen un impacto mínimo sobre el PND y proporcionar
confianza en las predicciones basadas en los resultados de simulación a gran escala.
6.1 Las comparaciones con las obras existentes
Medimos la capacidad del PND a utilizar las redes de centros de datos Clos mediante la
ejecución de una permutación: se trata de una matriz de tráfico del peor caso en que cada
servidor abre una única conexión de larga duración a otro servidor aleatorio tal que cada
servidor tiene exactamente una conexión entrante. Comparamos NDP con Multipath TCP [31], y
el recién DCTCP
Handley et al.
25
20
Incast FCT (us)
15
9000B
10
Perfecto tira
5
tirones experimentales
0
0 20 40 60 80 100 120
Latencia (us) Tamaño de flujo (KB)
Figura 13: El rendimiento Incast: perfecta frente a
separación de tracción medido.
10
8 La Figura 14 por la
Rendimiento (Gbps)
corriente de
6 NDP
rendimiento, matriz de
4 MPTCP
tráfico permutación,
DCTCP
2 FatTree 432-nodo.
DCQCN
0
0 50 100 150 200 250 300 350 400
rango de flujo
protocolo DCQCN propuesto que es, esencialmente, una forma de ejecución DCTCP a través
de redes Ethernet sin pérdidas. NDP conmuta colas uso de salida 8 en paquetes que, para
asegurar un buen rendimiento, DCTCP y MPTCP utilizan 200 colas de salida de paquetes y
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. 14 muestra el rendimiento alcanzado por cada host en orden creciente. DCTCP y
DCQCN utilizan un único camino y sufren de colisiones resultantes de ECMP: utilización
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.
Multipath TCP hace mucho mejor: la utilización es del 89%, y lo peor de flujo logra 6 Gb /
s. PND tiene una utilización del 92% y ofertas mucho mejor equidad a través de los flujos:
incluso el flujo más lento se 9Gb / s.
¿Cuál es el efecto del tamaño de búfer en pequeños tiempos de finalización de flujo?
Esperamos PND debe beneficiarse de buffers de red más pequeña, con DCTCP y DCQCN tener
tiempos de finalización de flujo más largos. Dos nodos intercambian varias veces 90KB
transferencias a la latencia de la prueba, mientras que todos los demás nodos de cada fuente de
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.
Un CDF de tiempos de terminación de flujo corto se muestra en la Fig. Peor latencia caso
15. del NDP es sólo dos veces el tiempo teórico de transferencia óptima en una red de reposo,
y es tres veces más baja en la mediana y cuatro veces inferior en el 99% en comparación con
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
esporádica. MPTCP logra el peor FCT de todas las soluciones, con una mediana y de la cola
diez veces mayores que las de NDP, debido a su llenado codicioso de buffers de red. Durante
estos experimentos NDP andMPTCP logra 80% de utilización de la red, wheras DCTCP y
DCQCN alcanzar ~ 75%.
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.
10
8
re F
Rendimiento (Gbps)
UN antes de Cristo mi
6
UN → B 2,51 Gb / s A → C 2,50 Gb / s A → D 2,51 Gb / s A → E 4 MPTCP
2,38 Gb / s total de la A: 9.90Gb / s F → E 7,55 Gb / s
2
0 0
0 20 40 60 80 100 120 140
Total a E: 9.93Gb / s
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
1 Gbps.
¿Quién necesita el recorte de paquetes? Una pregunta válida es si podemos obtener los beneficios de
NDP sin cambiar los conmutadores de red. PHost [16] es un transporte activado por el receptor que se
ejecuta muy pequeños almacenamientos intermedios de paquetes y por paquete ECMP, pero no lo
utiliza paquete de recorte. Hemos implementado pHost cambiando TCP en htsim; remitentes pHost
ráfaga a velocidad de línea en el primer RTT para obtener el rendimiento del flujo de mejor corto. Para
entender los méritos de pHost y el valor añadido de recorte, nos encontramos en pHost gota de cola
redes FatTree 432 nodos regulares con ocho búferes de paquetes. El incast 432-a-1 en la Fig. 16 toma
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,
encontrando que pHost sólo alcanza la utilización del 70% a pesar de su uso del paquete de
pulverización (NDP alcanza la utilización del 95%).
Manejo de asimetría. Todas las redes que hemos probado hasta ahora son simétricas; En paquetes
por pozos de trabajo ECMP en tales escenarios. Es más difícil de hacer bien cuando las redes son
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
manejar el fracaso muy bien, ya que mantener información de congestión por cada ruta y el tráfico
de tracción fuera de caminos congestionados. Los usos mecanismo de penalización en el trayecto
del PND (véase §3.2.3) es crucial en topologías asimétricas: sin ella no NDP bastante mal, con 15
flujos de llegar solo 3 Gbps de rendimiento. Unos flujos DCTCP también se ven afectados: el peor
golpe de conexión sólo alcanza 0.4Gbps.
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
que sucede cuando se suscribe en exceso la red central, o cuando los tamaños de paquetes son más pequeños
que una MTU? En tales casos, esperamos NDP para recortar muchos paquetes, y también lograr una relación
de compresión más baja cuando se produce el recorte.
Utilizamos mediciones de la red de Facebook para configurar nuestro experimento [34]. La
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
conmutadores de agregación es cuatro veces menor que la conectividad de servidor, dando 4: 1
sobresuscripción.
De los tres tipos de tráfico de red que se presentan en [34] (web, caché y Hadoop),
podemos usar la menos favorable a NDP: el patrón de tráfico web tiene muy pequeños
paquetes, dando compresión deficiente, y casi sin bastidor-nivel de la localidad, significado que
casi todo el tráfico debe atravesar el núcleo exceso de solicitudes. Los tamaños de flujo se han
extraído de la distribución en [34] (Fig.6.a) y el flujo de llegadas son de circuito cerrado con un
intersticio entre el flujo mediana de 1 ms. Variamos la carga aumentando la
SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU.
120
NDP, Med
100
DCTCP, Med
80
NDP, DCTCP
CDF (%)
NDP 60 alta, alta
40
NDP sin penalización en el trayecto
DCTCP 20
0.01 0.1 1 10 100
número de flujo
FCT (ms)
Figura 23: AFC para la web Facebook carga de trabajo en la
topología de un exceso de solicitudes.
número de conexiones simultáneas por host y la carga medida mediante el examen de la
utilización del núcleo.
Comparamos NDP con DCTCP y representar gráficamente la distribución tiempos de
finalización de flujo de la figura 23. Corremos dos pruebas separadas:. Primero, corremos una red
moderadamente cargado (cinco conexiones simultáneas por host) donde se recortan 40% de
todos los paquetes enviados por hosts NDP por el interruptor TdR. En este caso, la mediana de
FCT PND es la mitad de DCTCP de, y un tercero en el percentil 99.
A continuación, cargar la red aún más, con cada host abastecimiento de conexiones diez
simultáneamente a otras máquinas elegidas al azar. 70% de los paquetes se recortan en el primer
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
colapso; se observa que si un paquete lo hace más allá del interruptor de términos de referencia, es
probable que llegue a su destino, con una probabilidad de ser recortado de sólo el 2-5% es.
Para concluir, NDP es robusto incluso en esta red exceso de solicitudes, un mejor desempeño que
DCTCP. Esto no quiere decir que el PND debe ser utilizado como está en las redes congestionadas de
forma masiva: el número de paquetes recortadas en estos casos es un desperdicio. Cuando se recortan
la mayoría de los paquetes de un simple algoritmo de control de congestión podría reducir el ritmo de
producción, evitando la sobrecarga persistente, pero no hay necesidad de ser tan conservadora NDP
funciona bastante bien, sin control de la congestión.
7 RelatedWork
Hay un gran cuerpo de trabajo con el objetivo de abordar diversos aspectos de centro de datos de
transporte: la mayoría se centra en cualquiera de baja latencia lograr [5,
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 /
DCQCN de bajo retardo y MPTCP de alto rendimiento; Aquí repasamos el resto.
pFabric [6] objetivos para más corto de flujo primera programación en el centro de datos escala por
conmutación de paquetes en función de las prioridades estrictas. Mientras atraer en teoría, pFabric es
difícil de implementar, ya que confía anfitriones para priorizar correctamente su tráfico. Casco [5]
reservas de capacidad para asegurar una baja latencia para los flujos y usos cortas colas fantasma para
identificar el potencial de congestión; requiere paquete precisa la estimulación en los puntos finales.
Fastpass [30] utiliza programación centralizada para lograr una baja latencia pero se scalelimited. Si uno
puede modificar las aplicaciones explícitamente plazos estatales, existe una amplia gama de propuestas
que ayudará incluyendo PDQ, Fecha tope consciente de centro de datos TCP (D 2 TCP) y D 3 [ 22, 37,
39].
41
SIGCOMM '17, Agosto 21-25, 2017, Los Angeles, CA, EE.UU.
PUNTUAL [28], un mecanismo de control de congestión alternativa a DCQCN para redes sin
pérdidas, se basa exclusivamente en RTT como un indicador de congestión. Al igual que con
DCQCN, PUNTUAL no puede impedir por completo tramas de pausa y su impacto negativo en el
tráfico de red inocente. En general, las mayores limitaciones de todos estos trabajos es que sólo
se centran en una latencia baja, haciendo caso omiso de utilización de la red o el rendimiento de
gran caudal.
En el otro extremo del espectro, los investigadores han tenido mucho interés para hacer frente a
las colisiones debidas a por flujo ECMP con la programación centralizada en Hedera [2], a través de
cambios de protocolo en el paquete de Spraying [12] y Presto [21], o por medio de subflow- red
tratamiento en Conga [3] y el interruptor-rediseño de LocalFlow [35]. Estas obras no se dirigen a corto
fluyen los tiempos de finalización, y obtienen los AFC comparables a los de una red sin optimizar correr
grandes almacenamientos intermedios de paquetes.
PND destaca porque logra tanto de baja latencia y alto rendimiento en todas las
condiciones de tráfico.
8 Conclusiones
Presentamos NDP, una nueva arquitectura para centro de datos de red que incluye un
algoritmo de interruptor de puesta en cola modificado, junto con el reenvío de trayectos
múltiples por paquete, y una novela protocolo de transporte que se aprovecha de estos
mecanismos de la red. NDP exhibe excelente comportamiento de baja latencia, tanto en
nuestra aplicación, y en simulaciones a gran escala. Proporciona un mejor aislamiento entre
las diferentes cargas de trabajo que tales mecanismos DCQCN que se basan en Ethernet sin
pérdidas para lograr un retardo bajo.
Nuestra implementación actual es moderadamente costoso en términos de recursos de CPU
requeridos de los sistemas finales, debido a la necesidad de estimulación precisa de P ULL s y
retransmisiones de baja latencia. Ambas funciones serían muy simple para tarjetas de red Ethernet
para poner en práctica; de hecho, tarjetas de red WiFi baratas ya se manejan las retransmisiones
de paquetes y el tiempo cuidadoso. Se NDP a ser desplegado a escala, esperamos que la NIC
inteligentes reduciría en gran medida la carga de la CPU del PND.
Agradecimientos
Este trabajo fue financiado en parte por el proyecto SSICLOPS H2020 (644866). Nos
gustaría dar las gracias a Giuseppe Lettieri, los revisores anónimos y nuestro pastor Amin
Vahdat por sus comentarios muy útiles que nos ayudó a mejorar la calidad de este trabajo.
Referencias
[1] M. Al-tarifas, A. LOUKISSAS, y A. Vahdat. A escalable, los datos de los productos básicos centro
red de arquitectura. En Proc. ACM SIGCOMM, Agosto de 2010. [2] M. Al-tarifas, S. Radhakrishnan, B.
Raghavan, N. Huang, y A. Vahdat. Hedera:
la programación de flujo dinámico de redes de centros de datos. En Proc. Usenix INDE, 2010.
[3] M. Alizadeh, T. Edsall, S. Dharmapurikar, R. Vaidyanathan, K. Chu, A. Fingerhut,
VT Lam, F. Matus, R. Pan, N. Yadav, y G. Varghese. CONGA: Distributed congestión consciente de
equilibrio de carga para los centros de datos. En Proc. ACM SIGCOMM
2014, páginas 503-514.
[4] M. Alizadeh, A. Greenberg, DA Maltz, J. Padhye, P. Patel, B. Prabhakar, S. Sen
Gupta, y M. Sridharan. centro de datos TCP (DCTCP). En Proc. ACM SIGCOMM,
De agosto de 2010.
[5] M. Alizadeh, A. Kabbani, T. Edsall, B. Prabhakar, A. Vahdat, y M. Yasuda.
Menos es más: el comercio de un poco de ancho de banda de ultra baja latencia en el centro de datos. En
Proc. Usenix INDE, páginas 253-266, 2012.
[6] M. Alizadeh, S. Yang, M. Sharif, S. Katti, N. McKeown, B. Prabhakar, y
S. Shenker. pFabric: el transporte del centro de datos casi óptima mínima. En Proc. ACM SIGCOMM 2013.
[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
Handley et al.
[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
todo el lote en una acción: Rapid
notificación de pérdida de paquetes preciso en centros de datos. En Proc. Usenix INDE, 2014.
[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
6928: El aumento de TCP
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.
[13] Kit de desarrollo de Plano DPDK de datos. http://dpdk.org. Consultado el: 27/01/2017. [14] S. Floyd y V. Jacobson.
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
preocupaciones relacionadas con el control de congestión para
el tráfico de voz en internet. Informe técnico, RFC Editor, marzo de 2004. [16] PX Gao, A. Narayan, G.
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
conexto, 2015.
[17] A. Greenberg et al. VL2: una red de centros de datos escalable y flexible. En Proc.
ACM SIGCOMM, De agosto de 2009.
[18] R. Griffith, Y. Chen, J. Liu, A. Joseph, y R. Katz. Comprensión incast TCP
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.
ACM SIGCOMM 2009.
[20] C. Guo, H. Wu, Z. Deng, G. Soni, J. Ye, J. Padhye, y M. Lipshteyn. rdma sobre
ethernet de materias primas de escala. En Proc. ACM SIGCOMM 2016, páginas 202-215. [21] K. Él, E.
Rozner, K. Agarwal, W. Felter, J. Carter, y A. Akella. Presto: Edge-
de carga basado en el equilibrio de las redes de centros de datos rápidas. En Proc. ACM SIGCOMM 2015,
páginas 465-478.
[22] C.-Y. Hong, M. César, y PB Godfrey. Acabado fluye rápidamente con derecho preferente
Planificación. En Proc. ACM SIGCOMM 2012.
[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]
IEEE DCB.
802.1Qbb - basado en la prioridad de control de flujo.
http://www.ieee802.org/1/pages/802.1bb.html, 2011.
[25] Infiniband Comercio Asociación. RoCEv2.
https://cw.infinibandta.org/document/dl/7781, Septiembre de 2014. [26] V. Jacobson y MJ Karels. evitación
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.
En Proc. ACM SIG-
COMM, De agosto 1.987.
[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
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.
La mejora de los centros de datos de rendimiento y robustez con Multipath TCP. En Proc. ACM SIGCOMM, De agosto
de 2011.
[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
(Centro de datos) a la red de la red. En Proc. ACM SIGCOMM 2015, páginas 123-137. [35] S. Sen, D. Shue,
S. Ihm, y MJ Freedman. Escalable, óptimo flujo de encaminamiento en
centros de datos a través de balanceo de enlace local. En Proc. ACM conexto 2013, páginas 151-162. [36] A.
Singla, C.-Y. Hong, L. Popa, y PB Godfrey. Medusas: redes de datos
centros de azar. En Proc. Usenix INDE 2012.
[37] B. Vamanan, J. Hasan, y T. Vijaykumar. tcp centro de datos fecha límite-conscientes (d2tcp).
ACM SIGCOMM ordenador examen de la comunicación, 42 (4): 115-126, 2012. [38] V. Vasudevan, A.
Phanishayee, H. Shah, E. Krevat, DG Andersen, GR Ganger,
GA Gibson, y B. Mueller. Segura y retransmisiones TCP de grano fino eficaces para el centro de datos de
comunicación. En Proc.ACM SIGCOMM 2009, páginas 303-314. [39] C. Wilson, H. Ballani, T. Karagiannis, y A.
Rowtron. Nunca mejor que tarde:
cumplimiento de plazos en las redes de centros de datos. En Proc. SIGCOMM '11, 2011.
[40] Y. Zhu, H. Eran, D. Firestone, C. Guo, M. Lipshteyn, Y. Liron, J. Padhye, S. de lluvia
del, MH Yahia, y M. Zhang. El control de congestión para rdma a gran escala despliegues mentos. En Proc.
ACM SIGCOMM 2015, páginas 523-536. [41] N. Zilberman, Y. Audzevich, GA Covington, y AW Moore.
NetFPGA
ASUMIR: Hacia 100 Gbps de productos básicos como la investigación. Micro, 34 (5), 2014.