[Enciclopedia Online Gratuita] Diccionario de Internet y Tecnologías de la Información y la Comunicación (TIC):

ıllı FAST TCP wiki: info, historia y vídeos

Detalles: Categoría: INTERNET

videos internet

FAST TCP

FAST TCP (Fast Active queue management Scalable Transmission Control Protocol) es un algoritmo de control de congestión para TCP, desarrollado por estudiosos del “Californian Institute of Technology” y que recientemente da de que charlar por la capacidad que tendría dicho algoritmo de acrecentar las velocidades de trasferencia en Internet, sin precisar alterar la infraestructura actual.

En pocas palabras, hoy en día Internet marcha bajo Reno TCP, desarrollado en mil novecientos ochenta y ocho y que transmite bultos de mil quinientos byte, aguardando confirmaciones del receptor. Si no hay contestación, se retransmite un bulto a menor velocidad hasta el momento en que llega adecuadamente. Al contrario, FAST TCP mide continuamente el tiempo que tardan en llegar los bultos trasmitidos, examinando retrasos y pronosticando la tasa de trasferencia que va a poder aguantar la conexión a fin de que no se generen perdidas. Con este sistema, se han llegado a lograr en la red velocidades de cien Gb/s en conexiones transatlánticas.

Las primordiales peculiaridades que distinguen a este algoritmo con respecto a Reno TCP son tres:

Es un algoritmo basado en ecuaciones y por lo tanto suprime las oscilaciones a nivel de paquete
Emplea difiero de cola como medida primaria de la congestión, lo que, como vamos a ver, es más fiable que medir la probabilidad de fallo.
Tiene un comportamiento de activa de flujo estable y alcanza un equilibrio ecuánime que no penaliza flujos largos, como hace el presente algoritmo de control. Es en consecuencia, asintóticamente estable.

Decimos que el empleo del retraso de cola es provechoso en comparación con de la probabilidad de pérdida de bulto por 2 primordiales razones:

Primero, pues la estimación de la primera es más precisa que en la segunda, en tanto que para sistemas de banda ancha, la pérdida de un bulto es un hecho parcialmente extraño, y por ende es complicado querer un valor adecuado. Y todavía si se hiciese, la medida o bien muestreo de las pérdidas de bulto es considerablemente más ruda, menos fina, que la de retrasos de cola, si bien las dos medidas sean igualmente estruendosas. Además de esto, cada medida de pérdida de bulto da un solo bit de información para el filtrado de estruendos, al paso que la medida del difiero ofrece información multi-bit.

Segundo, pues basándose en el modelo de TCP/AQM, la activa de colas es escalable con respecto a la capacidad de la red. La que cosa da estabilidad al algoritmo en frente de los futuros incrementos de capacidad en las conexiones.

Habría que decir que TCP Reno, desde su aparición, ha soportado un aumento de Internet de 6 órdenes de magnitud a nivel de tamaño, velocidad, carga y conectividad. Mas es sabido que conforme aumente el ancho de banda, TCP Reno se transformará por último en un cuello de botella para sí mismo.

Existen 2 formas de enfocar el diseño de un algoritmo de control de congestión: a nivel de flujo y a nivel de bulto. Reno TCP fue desarrollado enfocando el inconveniente a nivel de bulto, y los resultados que se consiguieron a nivel de flujo fueron una consecuencia, mas no una meta. En FAST TCP (de la misma manera que en HSTCP y STCP), basándonos en el diseño a nivel de flujo, conseguimos determinados resultados a nivel de bulto.

Este mecanismo de control de congestión tiene 4 componentes: data control, window control, burstiness control y estimatión. Todos son funcionalmente independientes, de manera que pueden ser diseñados separadamente e inclusive mejorados separadamente. En resumen, el componente de data control determina “qué” bultos trasmitir, window control determina “cuantos” y burstiness control determina “cuando”. Estas resoluciones se fundamentan en la información que contiene la estimación. El componente window control trabaja a niveles de tiempo del tamaño del RTT, al paso que el burstiness control trabaja a escalas más pequeñas.

A continuación se describe con más detalle cada componente:

Estimation: de la transmisión de cada bulto consigue información “feedback” de 2 componentes: una sobre el retraso de colas (multi bit) y otra que señala si se ha perdido o bien no el bulto (1 solo bit). Cuando se recibe un ACK positivo, FAST calcula el RTT para el pertinente bulto de datos, y también de manera inmediata calcula el mínimo RTT y una media exponencial del RTT, que van a ser utilizadas en el componente “window control”. Si se recebe un ACK negativo, produce una indicación de pérdida sobre este bulto de datos al “data control”

Window control: como hemos comentado ya, FAST TCP emplea el difiero de cola (como TCP Vegas) como factor primordial en el ajuste de la ventana. Bajo condiciones normales de la red, FAST actualiza periódicamente la ventana de congestión w conforme con:

w?inf

donde ? es una incesante entre 0 y 1, RTT es la media actual de round-trip time, baseRTT es el valor mínimo de RTT hasta el instante y es un factor que controla la ecuanimidad del protocolo.

Aunque los tamaños de ventana se ajustan de forma diferente en TCP Vegas y FAST, su activa de flujo es muy afín matemáticamente. En el caso de FAST, ajusta el tamaño de ventana de manera brusca, (aumentándolo o bien disminuyéndolo), cuando el número de bultos en el buffer es lejanísimo a su objetivo, y por otra parte, lo ajusta de forma fina, cuando el número de bultos en buffer y su objetivo no difiere mucho. En este sentido, FAST es una versión de gran velocidad de TCP Vegas.

El inconveniente que tiene este protocolo es en el caso de redes en las que hay retrasos en los datos de “feedback”. En una red sin dichos retrasos se espera que el protocolo sea de forma local estable. En el caso que haya retrasos, va a ser de forma local estable si hay poca pluralidad de retardos de flujo.

Data control: este componente elige cuál va a ser el próximo bulto a mandar, y lo hace de entre 3 conjuntos aspirantes posibles:

Los bultos nuevos
Paquetes que están claramente perdidos (se ha recibido un ACK negativo)
Paquetes de los que no se ha recibido confirmación.

En en caso de que no haya pérdida, los bultos nuevos son mandados secuencialmente conforme los bultos viejos van siendo confirmados. A esto se le llama “self-clocking” o bien “ack-clocking”. En el caso de pérdidas, se tiene que decidir entre retransmitir bultos, proseguir mandando nuevos o bien retransmitir bultos todavía más viejos que se han declarado como perdidos. El “data control” va a ser el responsable de decidir de qué forma entremezclar dichos bultos en el momento de trasmitirlos. Dicha resolución va a tomar todavía más relevancia conforme la relación ancho de banda – retardos aumente.

Burstiness control: este componente rastrea las transmisiones de bultos de forma fluida para descubrir como es el ancho de banda libre. Esto es singularmente esencial en redes de un enorme ancho de banda con presencia de difiero de bultos, donde el tráfico puede ser a rachas debido a acontecimientos tanto en internet como en los hosts. En ocasiones una CPU transmisora está ocupada a lo largo de un largo periodo atendiendo las interrupciones de los bultos entrantes, dejando a los bultos de salida acumularse en una cola de salida de forma que van a ser trasmitidos en una enorme racha cuando la CPU quede libre. Una transmisión de este estilo crea grandes colas y también acrecienta la posibilidad de pérdidas masivas (burstiness).

El pacing (dividir en pasos) es una forma común de solucionar el inconveniente de burstiness en el transmisor. Una implementación simple de pacing deja al transmisor TCP planear transmisiones de bultos en intervalos de tiempo incesantes, que se consigue dividiendo la ventana de congestión entre el RTT. En la práctica esto requeriría una alta resolución en el reloj y provocaría sobrecarga. Para reducir la sobrecarga, podemos hacer una planificación en pequeñas rachas de bultos en vez de bultos individuales. No obstante, la utilización del pacing no soluciona completamente el inconveniente de burstiness.

Se emplean 2 mecanismos de control de burstiness, uno para reemplazar el self-clocking y otro para acrecentar sensiblemente el tamaño de la ventana en pequeñas rachas.

Aquí se exponen ciertos inconvenientes de FAST TCP y sus soluciones potenciales, si bien se precisa de más experimentación para acabar la eficiencia de las soluciones propuestas en redes reales y sus aplicaciones.

Medida del difiero de propagaciónEditar

El difiero de propagación se emplea en el algoritmo de control de ventana. En redes en las que existan flujos FAST, el retraso de cola, impuesto por el protocolo, puede ser confundido como una parte del retraso de propagación de nuevos flujos que se incorporen después.Esta medida del difiero de propagación asimismo puede verse perjudicada por un cambio de senda desde un camino más corto hasta un camino más largo a lo largo del tiempo de vida de una conexión, por este motivo una solución propuesta es apreciar el difiero a través de el mínimo RTT observado a lo largo de un cierto periodo, no desde el principio de la conexión, en tanto que la senda puede mudar.

Medida del difiero por espera en colaEditar

Esta medida puede verse perjudicada por el burstiness de exactamente los mismos flujos FAST, llevando esta situación a reducir la no ecuanimidad entre los diferentes flujos con diferentes RTTs. Este fallo puede disminuirse de forma notable desplegando un algoritmo de control de burstiness en el transmisor.

a sintonizadaEditar

El factor a en la ecuación del window control controla el número de bultos que cada flujo tiene en el link de cuello de botella, si este número supera la capacidad del buffer, los flujos no van a poder lograr el equilibrio antes que puedan observar la pérdida de bultos y el algoritmo fluctuará.

Protocolos heterogéneosEditar

El inconveniente de la maximización de aplicaciones implica que solo hay un único punto de equilibrio para redes bajo condiciones leves. Mas resulta que una red con protocolos heterogéneos que reaccionan a diferentes señales de congestión pueden portarse de una forma considerablemente más compleja.

A diferencia de TCP Reno y sus variaciones, FAST TCP está basado en retrasos. Esto le deja lograr una alta utilización sin atestar el buffer, lo que provocaría un retraso notable de colas, como acostumbra a acontecer en los algoritmos basados en pérdidas. Esto da ecuanimidad y no penaliza flujos con grandes RTTs.