FAST TCP (también escrito FastTCP ) es un algoritmo de prevención de congestión de TCP especialmente dirigido a enlaces de larga distancia y alta latencia, desarrollado en Netlab, California Institute of Technology y ahora comercializado por FastSoft. FastSoft fue adquirida por Akamai Technologies en 2012. [1]
FastTCP es compatible con los algoritmos TCP existentes y solo requiere modificaciones en la computadora que envía los datos .
Nombre
El nombre de FAST es un acrónimo recursivo para F AST A QM S calable T CP, donde AQM significa A ctive Q ueue M GESTIÓN, y TCP significa T ransmission C ontrol P ROTOCOLO.
Principios de Operación
La función del control de la congestión es moderar la velocidad a la que se transmiten los datos, de acuerdo con 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 retardo de la 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 disminuyen la velocidad cuando descubren que se están cayendo paquetes, por lo que la tasa de envío promedio depende de la probabilidad de pérdida. Esto tiene dos inconvenientes. Primero, se requieren bajas probabilidades de pérdida para mantener altas velocidades de datos; en el caso de TCP Reno, se requieren probabilidades de pérdida muy bajas, pero incluso los nuevos algoritmos para evitar la congestión como H-TCP , BIC TCP y HSTCP requieren tasas de pérdida más bajas que las proporcionadas por la mayoría de las redes inalámbricas de área amplia . Además, la pérdida de paquetes solo proporciona un 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 de FAST TCP busca mantener un número constante de paquetes en colas en toda la red. El número de paquetes en las colas se estima midiendo la diferencia entre el tiempo de ida y vuelta observado (RTT) 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 la cola, la velocidad de envío aumenta, mientras que si hay demasiados en la cola, la velocidad 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 grande. TCP Vegas realiza ajustes de tamaño fijo a la tasa, independientemente de qué tan lejos esté la tasa actual de la tasa objetivo. FAST TCP da pasos más grandes cuando el sistema está más lejos del equilibrio y pasos más pequeños cerca del equilibrio. Esto mejora la velocidad de convergencia y la estabilidad.
Fortalezas y debilidades
Los algoritmos basados en retardos pueden, en principio, mantener un tamaño de ventana constante, evitando las oscilaciones inherentes a los algoritmos basados en pérdidas. Sin embargo, también detectan la congestión antes que los algoritmos basados en pérdidas, ya que la demora corresponde a búferes parcialmente llenos , mientras que la pérdida resulta de búferes totalmente llenos. Esto puede ser una fortaleza o una debilidad. Si el único protocolo utilizado en una red está basado en retardos, entonces se puede evitar la ineficiencia de la pérdida; sin embargo, si los protocolos basados en pérdidas y en demoras comparten la red, [4] entonces los algoritmos basados en demoras tienden a ser menos agresivos. Esto puede superarse mediante la elección adecuada de parámetros, lo que conduce 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 la contención del bus .
No está claro si prevalecen las fortalezas o debilidades, y depende en gran parte 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 el retardo de propagación por nuevos flujos que se unen 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 nuevos flujos sobre los existentes. El método para eliminar este error se sugiere en. [5]
FAST TCP generalizado
Se ha demostrado que FAST TCP es prometedor en términos de estabilidad, rendimiento y equidad del sistema. Sin embargo, requiere almacenamiento en búfer que aumenta linealmente con el número de flujos atascados en un enlace. El artículo [6] propone un nuevo algoritmo de TCP que extiende FAST TCP para lograr una equidad proporcional ( α , n ) en estado estacionario, produciendo requisitos de búfer que crecen solo como la enésima potencia del número de flujos. Los autores denominan al nuevo algoritmo Generalized FAST TCP. Demuestran estabilidad para el caso de un único enlace de cuello de botella con fuentes homogéneas en ausencia de retraso 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 para escalar significativamente mejor que el estándar FAST TCP.
Propiedad intelectual
A diferencia de la mayoría de los algoritmos de prevención de congestión de TCP, FAST TCP está protegido por varias patentes. [7] [8] En lugar de buscar la estandarización por parte del 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.
Ver también
Referencias
- ^ Young, Jeff (13 de septiembre de 2012). "Akamai adquiere FastSoft" . PR Newswire . Consultado el 13 de septiembre de 2012 .
- ^ Nick, Barone; Jin, Cheng; Low, Steven H. y Hegde, Sanjay (2006). "FAST TCP: motivación, arquitectura, algoritmos, rendimiento" (PDF) . Transacciones IEEE / ACM sobre redes . 14 (6): 1246-1259. doi : 10.1109 / TNET.2006.886335 . Archivado desde el original (PDF) el 6 de septiembre de 2006.
- ^ Jin, Cheng; Wei, D .; Bajo, SH; Bunn, J .; Choe, HD; Doyle, JC; Newman, H .; Ravot, S .; Singh, S .; Paganini, F .; Buhrmaster, G .; Cottrell, L .; Martin, O .; Wu-Chun Feng (2005). "FAST TCP: de la teoría a los experimentos" (PDF) . Red IEEE . 19 (1): 4–11. doi : 10.1109 / MNET.2005.1383434 . Archivado desde el original (PDF) el 12 de mayo de 2006.
- ^ Tang, Ao; Wang, Jiantao; Low, Steven H. y Chiang, Mung (marzo de 2005). "Equilibrio de red de protocolos de control de congestión heterogéneos" (PDF) . IEEE INFOCOM . Miami, Florida.
- ^ a b L. Tan, C. Yuan y M. Zukerman, "FAST TCP: Equidad y problemas de colas", IEEE Commun. Lett., Vol. 9, no. 8, págs. 762–764, agosto de 2005.
- ^ Yuan, Cao; Tan, Liansheng; Andrew, Lachlan LH; Zhang, Wei; Zukerman, Moshe (2008). "Un esquema FAST TCP generalizado". Comunicaciones informáticas . 31 (14): 3242–3249. doi : 10.1016 / j.comcom.2008.05.028 . hdl : 1959,3 / 44051 .
- ^ Jin, Cheng; Bajo, Steven H .; Wei, Xiaoliang (27 de enero de 2005). "Método y aparato para el control de la congestión de la red" . Oficina de Patentes y Marcas de Estados Unidos . Archivado desde el original el 14 de diciembre de 2012 . Consultado el 5 de noviembre de 2006 .
- ^ Jin, Cheng; Bajo, Steven H .; Wei, David X .; Wydrowski, Bartek; Tang, Ao; Choe, Hyojeong (9 de marzo de 2006). "Método y aparato para el control de la congestión de la red mediante control de colas y medidas de retardo unidireccional" . Oficina de Patentes y Marcas de Estados Unidos . Archivado desde el original el 14 de diciembre de 2012 . Consultado el 5 de noviembre de 2006 .
enlaces externos
- Página de inicio FAST .
- Desafío de ancho de banda de supercomputación 2005
- Página de inicio de FastSoft