¿Control de congestión TCP para redes de baja latencia de 10 GbE -> 1 GbE?

Tengo un servidor con una conexión de 10 GbE a un conmutador y 10 clientes cada uno con una conexión de 1 GbE al mismo conmutador.

Al ejecutar nuttcp en paralelo en cada uno de los clientes, puedo enviar 10 flujos de datos TCP al servidor simultáneamente a una velocidad cercana al cable (es decir, apenas 100 megabytes por segundo de los 10 clientes simultáneamente).

Sin embargo, cuando invierto la dirección y envío datos desde el servidor a los clientes, es decir, 10 flujos TCP, uno a cada cliente, las retransmisiones TCP se disparan y el rendimiento cae a 30, 20 o incluso 10 megabytes por segundo. por cliente Quiero obtener estos números, porque este patrón de tráfico es representativo de ciertas aplicaciones que me interesan.

Verifiqué que mi servidor es capaz de saturar un enlace de 10 GbE realizando el mismo experimento a través de una conexión de 10 GbE a un servidor similar. He verificado que no hay errores en ninguno de mis puertos.

Finalmente, cuando aprieto (limito) por la fuerza el tamaño de la ventana TCP del receptor, puedo aumentar el ancho de banda (30-40 megabytes / seg); y si lo aprieto extremadamente bajo, puedo llevar las retransmisiones a cero (con el ancho de banda ridículamente bajo).

Por lo tanto, estoy razonablemente seguro de que estoy desbordando los búferes en mi conmutador, lo que resulta en la pérdida de paquetes debido a la congestión. Sin embargo, pensé que se suponía que el control de congestión de TCP se ocuparía de esto muy bien, eventualmente estabilizándose a algo por encima del 50% de la velocidad del cable.

Entonces, mi primera pregunta es muy simple: ¿qué algoritmo de control de congestión TCP sería el mejor para mi situación? Hay un montón de ellos disponibles, pero en su mayoría parecen estar dirigidos a redes con pérdidas o redes de alta latencia de alto ancho de banda o redes inalámbricas ... Ninguno de los cuales se aplica a mi situación.

Segunda pregunta: ¿Hay algo más que pueda probar?

linux networking tcp

— Nemo
fuente

Sería útil saber qué modelo de interruptor. Los diferentes conmutadores manejan las colas de diferentes maneras y ayudarían a reducir una solución.

— scottm32768

Además, los diferentes conmutadores tienen diferentes tamaños de búfer, por lo que conocer el modelo del conmutador ayudaría a eliminar los problemas de hardware de su problema.

— cpt_fink

Además, los modelos de NIC, los controladores, la versión de Linux, el kernel, la distribución, etc. Mis respuestas para una NIC Myricom o Solarflare con un Cisco 4900M serían diferentes a un conmutador Dell Powerconnect e Intel NIC.

— ewwhite

Desearía un algoritmo en el que el tamaño de la ventana no se reduzca drásticamente cuando hay una caída de paquetes. Es la caída drástica en el tamaño de la ventana lo que resulta en la caída repentina en el rendimiento con el tráfico TCP.
Si su conmutador y su servidor admiten el control de flujo, intente habilitar el control de flujo. Lo bien que esto funcione depende casi por completo del silicio y firmware del Switch. Básicamente, el conmutador detectará congestión de salida en el puerto que está conectado a un cliente, determinará de dónde provienen los paquetes y enviará tramas de control de flujo por el puerto de entrada (es decir, de vuelta al servidor). Si el servidor comprende las tramas de control de flujo, reducirá la velocidad de transmisión. Si todo funciona bien, obtendrá un rendimiento óptimo con prácticamente cero caídas de paquetes en el búfer de salida del conmutador.

— wookie919
fuente