[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
La información contenida en esta web debe ser considerada como información general, de carácter formativo, educativo o divulgativo, y no puede ser utilizada o interpretada como consejo o diagnótico médico, psicológico o de ningún otro tipo. Es posible que algunos datos mostrados no esten actualizados. Por ello, en caso de duda lo recomentable es consultar a un experto cualificado.
- Detalles
- Categoría: 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: 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: 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. 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. 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. 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. 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. 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á. 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.
w?inf Medida del difiero de propagaciónEditar
Medida del difiero por espera en colaEditar
a sintonizadaEditar
Protocolos heterogéneosEditar
Enlaces externosEditar
