Zeta-TCP [1] se refiere a un conjunto de algoritmos patentados de Protocolo de control de transmisión (TCP) destinados a mejorar el rendimiento de extremo a extremo de TCP, independientemente de si el par es Zeta-TCP o cualquier otra pila de protocolos TCP, en otros palabras, para que sea compatible con los algoritmos TCP existentes. Fue diseñado e implementado por AppEx Networks Corporation.
Zeta-TCP ofrece las siguientes mejoras principalmente:
- Evitación de la congestión basada en medidas de latencia y pérdida.
- Algoritmo de detección de pérdidas mejorado.
- Control inverso.
Evitación de la congestión
La mayoría de las implementaciones de pila de TCP actuales utilizan TCP New Reno o sus variaciones (como TCP SACK RFC3517 ) como algoritmo para evitar la congestión. Los algoritmos basados en New Reno se basan en pérdidas. Los algoritmos basados en pérdidas tratan las pérdidas de paquetes como la única indicación de las congestiones en la red. Como Internet ha evolucionado desde entonces, esta suposición es a menudo una exageración en la actualidad. La pérdida por congestión desciende constantemente con el avance de las tecnologías, mientras que la pérdida relativamente aleatoria se debe a las propiedades de los medios (p. Ej., Canales inalámbricos / desvanecidos ), ruidos / diafonía de líneas fijas, fallas de conectividad, errores de software, etc. , esta incrementando. Una vez que se detecta una "congestión" (o se produce una falsa alarma), New Reno reduce drásticamente la Ventana de congestión (CWND), provocando una caída en la tasa de envío. Esta es una de las principales razones por las que las aplicaciones basadas en TCP a menudo apenas pueden utilizar una fracción del ancho de banda suscrito en la actualidad, especialmente cuando el RTT es grande.
TCP Vegas y sus variaciones, sobre todo FAST TCP , basan sus predicciones de congestión únicamente en la medición RTT. Estos algoritmos basados en latencia superan los problemas de los basados en pérdidas y suelen ser un reflejo más realista de las congestiones en la red. Pero los algoritmos basados en latencia también tienen sus propias limitaciones .
Zeta-TCP intenta abordar el problema combinando la fuerza de los algoritmos basados en latencia y basados en pérdidas. Mide constantemente la variación de RTT y la variación de la tasa de pérdida, y calcula la probabilidad de congestión. Se aplican diferentes esquemas de retroceso de CWND en función del nivel de probabilidad. Con el nivel más alto, aplica el esquema de retroceso de New Reno, que ya ha demostrado ser efectivo y estable con muchos años de despliegue masivo.
Detección de pérdidas
Las pérdidas de paquetes en el entorno de red real rara vez se distribuyen de manera uniforme. Más bien tienden a suceder cerca unos de otros. Los RFC relacionados con TCP (New Reno y SACK, etc.) definieron explícitamente cómo se puede detectar la primera pérdida con alta confianza. Sin embargo, la detección de las pérdidas después de que TCP ingresa al modo de recuperación rápida con SACK permitido no es muy eficiente en RFC3517 . Y algunos sistemas operativos populares tienen sus propias implementaciones que son igualmente subóptimas.
Zeta-TCP ha introducido un algoritmo simple pero efectivo para calcular la probabilidad de pérdida en cada paquete no APAGADO / APAGADO. Un paquete se retransmite solo cuando su probabilidad de pérdida ha superado un cierto umbral. La misma regla se aplica a la decisión de retransmisión de cada paquete. Por lo tanto, Zeta-TCP puede minimizar el número de paquetes retransmitidos, mejorando aún más la utilización del ancho de banda. Las pruebas de laboratorio también confirmaron que Zeta-TCP retransmitió muchos menos paquetes que las otras implementaciones de TCP con la misma tasa de pérdida.
Zeta-TCP también ha desarrollado un mecanismo para detectar con precisión la pérdida de paquetes lo antes posible una vez que sospecha que es probable que ocurra una pérdida. La detección temprana generalmente puede ahorrar uno o dos RTT en la retransmisión.
Control inverso
Mientras que los otros algoritmos se enfocan en acelerar el tráfico saliente, Reverse Control intenta abordar los problemas entrantes. Reverse Control supervisa la calidad de las conexiones con datos entrantes y ejecuta el algoritmo para indicarle al par que transmita lo más rápido posible cuando la calidad de la conexión sea buena. El algoritmo también hace un buen esfuerzo para identificar con mayor precisión las pérdidas reales de paquetes de otras situaciones anormales para evitar la activación de recuperaciones rápidas innecesarias.
La aceleración de entrada con control inverso es heurística en el sentido de que la velocidad de entrada es realmente controlada por el remitente, es decir, el par. Solo puede sugerirle al par que envíe más rápido. Algunas pilas de TCP captan la indirecta y otras no. Además, con bastante frecuencia, el lado del remitente (servidor de contenido, por ejemplo) tiene un mecanismo de limitación de velocidad para limitar el efecto de aceleración.
Además de la aceleración, Reverse Control también puede limitar la velocidad de entrada. A diferencia de la aceleración, frenar el tráfico entrante es muy efectivo y preciso con el mecanismo de control de flujo de TCP. La limitación de la velocidad de entrada de Zeta-TCP sienta las bases del control de flujo de entrada de AppEx IPEQ. [2]
Implementación
En el momento de redactar este documento, Zeta-TCP se ha implementado como módulos de software para Linux ( módulo de kernel de Netfilter ), Microsoft Windows 10 hasta XP y versiones de Windows Server relacionadas ( NDIS IM Filter / NDIS LWF) y WinCE. AppEx eligió no modificar la pila de protocolos, sino interceptar los flujos de TCP y aplicar sus algoritmos sobre la marcha. Esta es la forma no intrusiva de implementar los algoritmos destinados a una aceptación más amplia. El inconveniente es la sobrecarga adicional de procesamiento. Pero, en realidad, los gastos generales son insignificantes en comparación con las ganancias de rendimiento.