¿Qué es Laminar?
Laminar es un framework nuevo para el control de la congestión de TCP que separa la programación de la transmisión, que determina con precisión cuándo se envían los datos, del control de congestión puro, que determina la cantidad total de datos enviados durante cada RTT.
El algoritmo predeterminado para la programación de transmisiones es una implementación estricta del principio de conservación de paquetes de Van Jacobson [Jacobson88]. Los datos que llegan al receptor generan ACK, que, a su vez, hacen que el remitente transmita una cantidad equivalente de datos a la red. La variable de estado principal está implícita en la cantidad de datos y ACK que circulan en la red. Este estado se observa a través de un estimador tcp_packets_in_flight() mejorado (también conocido como total_pipe). El total_pipe se basa en la canalización, como se describe en RFC 3517, pero también incluye la cantidad de datos informados por la ACK actual y las transmisiones pendientes que pasaron el control de congestión, pero están a la espera de otros eventos, como TSO.
Una variable nueva, CCwin, es la principal variable de estado de control de la congestión. Los algoritmos de control de la congestión ajustan CCwin para regular el nivel general de congestión a lo largo de la ruta. Si bien CCwin se parece a la realidad, cwnd está sobrecargado y varios algoritmos (como la supresión de ráfaga) lo usan con objetivos diferentes y, a veces, contradictorios.
Cada vez que total_pipe es diferente de CCwin, el algoritmo de programación de transmisiones ajusta ligeramente la cantidad de segmentos enviados en respuesta a cada ACK. El inicio lento y la reducción de frecuencia proporcional [PRR] (un reemplazo para la reducción a la mitad de la frecuencia) están incorporadas en el algoritmo de programación de transmisión.
La ventaja principal del framework de Laminar es que, cuando se particiona el control de congestión y la programación de la transmisión en subsistemas separados, cada uno está sujeto a restricciones de diseño mucho más simples, lo que facilita el desarrollo de muchos algoritmos nuevos que no son factibles con la organización anterior del código.
El framework de Laminar cambia la filosofía de diseño subyacente del control de la congestión de TCP y puede tener implicaciones amplias, más allá del parche. El objetivo de este parche es permitir que las personas experimenten con el código y comenten, y que ayuden a descubrir cualquier caso límite que se haya pasado por alto. Además, el parche está incompleto en el sentido de que todavía faltan varios algoritmos, en particular: algoritmos de control de congestión que no sean CUBIC y Reno, validación de proyectos, métricas de destino, etc. Sería muy bueno que las personas ayudaran a refactorizar algunos de estos otros algoritmos.
El framework Laminar y su motivación se describen con más detalle en un borrador de Internet, draft-mathis-tcpm-tcp-laminar.
Envía tus comentarios y sugerencias a mattmathis@google.com.
Este proyecto forma parte de las iniciativas de Google para Hacer que la Web sea más rápida a través de mejoras de protocolo.
Notas de implementación
Laminar se implementa principalmente en 3 funciones (tcp_input.c):
Tcp_cong_avoid() y tcp_mult_decr() realizan el control de congestión de AIMD mediante la variable de estado de CCwin. Excepto para deshacer, estas dos funciones son los únicos lugares en los que CCwin cambia. (Ambas funciones invocan controladores específicos del módulo de congestión).
Tcp_laminar_schedule() determina cuántos datos enviar en respuesta a cada ACK. Implementa la conservación de paquetes Van Jacobson, ajustada ligeramente hacia arriba o hacia abajo para que tcp_packets_in_flight() converja con CCwin.
Hay cambios importantes en el estimador tcp_packets_in_flight() para hacerlo invariante en la mayoría de los eventos de protocolo. La aplicación se detiene, los ajustes en tcp_laminar_schedule() y las pérdidas reales de paquetes cambian en tcp_packets_in_flight(), como deben ser. El procesamiento de ACK, el TSO y la mayoría de los demás eventos no lo hacen. Ten en cuenta que cuando hay pérdidas, la cantidad real de paquetes en tránsito cambia de inmediato, pero no se refleja en el estimador tcp_packets_in_flight() hasta que la maquinaria de retransmisión los marca como perdidos y los incrementa con pérdida.
Obtén el parche
Este parche va en contra de net-next de Dave Miller y se aplica sin problemas a 3.5-rc2.
Nota: Los módulos de control de congestión que no son Reno ni CUBIC no se actualizaron y no se compilarán. Si tu configuración compila otros módulos de control de congestión, como Vegas, escalable, de alta velocidad, etc., primero deben inhabilitarse.