FAST TCP (también escrito FastTCP ) es un algoritmo de prevención de congestión TCP especialmente diseñado para enlaces de larga distancia y alta latencia, desarrollado en el Netlab del Instituto Tecnológico de California y que ahora comercializa FastSoft. Akamai Technologies adquirió FastSoft en 2012. [1]
FastTCP es compatible con los algoritmos TCP existentes y sólo requiere modificaciones en la computadora que envía los datos .
El nombre FAST es un acrónimo recursivo de FAST A QM Scalable TCP , donde AQM significa Active Queue Management y TCP significa Transmission Control Protocol .
El papel del control de congestión es moderar la velocidad a la que se transmiten los datos, "congestión", según la capacidad de la red y la velocidad a la que otros usuarios están transmitiendo. Al igual que TCP Vegas , FAST TCP [2] [3] utiliza el retraso de cola en lugar de la probabilidad de pérdida como señal de congestión.
La mayoría de los algoritmos de control de congestión actuales detectan la congestión y reducen la velocidad cuando descubren que se están descartando paquetes, de modo que la tasa de envío promedio depende de la probabilidad de pérdida. Esto tiene dos inconvenientes. En primer lugar, se requieren bajas probabilidades de pérdida para mantener altas tasas de datos; en el caso de TCP Reno, se requieren probabilidades de pérdida muy bajas, pero incluso los nuevos algoritmos de prevención de congestión como H-TCP , BIC TCP y HSTCP requieren tasas de pérdida inferiores a las proporcionadas por la mayoría de las redes de área amplia inalámbricas . Además, la pérdida de paquetes solo proporciona un único bit de información sobre el nivel de congestión, mientras que el retraso es una cantidad continua y, en principio, proporciona más información sobre la red.
Un flujo TCP FAST busca mantener una cantidad constante de paquetes en colas a lo largo de la red. La cantidad de paquetes en colas se estima midiendo la diferencia entre el tiempo de ida y vuelta (RTT) observado y el RTT base , definido como el tiempo de ida y vuelta cuando no hay cola. El RTT base se estima como el RTT mínimo observado para la conexión. Si hay muy pocos paquetes en cola, la tasa de envío aumenta, mientras que si hay demasiados, la tasa disminuye. En este sentido, es un descendiente directo de TCP Vegas.
La diferencia entre TCP Vegas y FAST TCP radica en la forma en que se ajusta la velocidad cuando el número de paquetes almacenados es demasiado pequeño o demasiado grande. TCP Vegas realiza ajustes de tamaño fijo a la velocidad, independientemente de lo lejos que esté la velocidad actual de la velocidad objetivo. FAST TCP realiza pasos más grandes cuando el sistema está más alejado del equilibrio y pasos más pequeños cerca del equilibrio. Esto mejora la velocidad de convergencia y la estabilidad.
Los algoritmos basados en retardo pueden, en principio, mantener un tamaño de ventana constante, evitando las oscilaciones inherentes a los algoritmos basados en pérdida. Sin embargo, también detectan la congestión antes que los algoritmos basados en pérdida, ya que el retardo corresponde a buffers parcialmente llenos , mientras que la pérdida resulta de buffers totalmente llenos. Esto puede ser una fortaleza o una debilidad. Si el único protocolo utilizado en una red está basado en retardo, entonces se puede evitar la ineficiencia de la pérdida; sin embargo, si los protocolos basados en pérdida y retraso comparten la red, [4] entonces los algoritmos basados en retardo tienden a ser menos agresivos. Esto se puede superar con una elección adecuada de parámetros, lo que lleva a interacciones complejas estudiadas por Tang et al.
Las mediciones de retardo también están sujetas a fluctuaciones como resultado de la programación del sistema operativo o de la contención del bus .
No está claro si prevalecen las fortalezas o las debilidades y depende en gran medida del escenario particular.
El retardo de propagación se utiliza en el algoritmo de control de ventana FAST. En una red limpia, el retardo de cola mantenido por los flujos FAST existentes puede confundirse con parte del retardo de propagación por los nuevos flujos que se incorporan más tarde, como se muestra en las simulaciones ns-2 en [5] . El efecto de este error de estimación es equivalente a modificar las funciones de utilidad subyacentes para favorecer a los nuevos flujos sobre los flujos existentes. En [5] se sugiere un método para eliminar este error.
Se ha demostrado que FAST TCP es prometedor en términos de estabilidad del sistema, rendimiento y equidad. Sin embargo, requiere un almacenamiento en búfer que aumenta linealmente con el número de flujos en un enlace. El artículo [6] propone un nuevo algoritmo TCP que extiende FAST TCP para lograr una equidad ( α , n )-proporcional en estado estable, lo que produce requisitos de almacenamiento en búfer que crecen solo como la n-ésima potencia del número de flujos. Los autores llaman al nuevo algoritmo FAST TCP generalizado. Prueban la estabilidad para el caso de un solo enlace de cuello de botella con fuentes homogéneas en ausencia de retardo de retroalimentación. Los resultados de la simulación verifican que el nuevo esquema es estable en presencia de retardo de retroalimentación y que sus requisitos de almacenamiento en búfer se pueden hacer escalar significativamente mejor que el FAST TCP estándar.
A diferencia de la mayoría de los algoritmos de prevención de congestión TCP, FAST TCP está protegido por varias patentes. [7] [8] En lugar de buscar la estandarización por parte de la IETF , los inventores de FAST, en particular Steven H. Low y Cheng Jin, buscan comercializarlo a través de la empresa FastSoft. Actualmente, FastSoft vende un dispositivo de rack de 1 unidad que se puede implementar en el lado del remitente sin necesidad de otras modificaciones de software o hardware en ninguno de los extremos.