2011

Trafico TCP
El presente trabajo tiene como objetivo hacer una sntesis general del protocolos y algoritmos presente durante el transporte de diferentes tipos de trfico en una red de telecomunicaciones, tambin se vern las mejoras propuestas para optimizar el uso de los recursos los cuales son compartidos y limitados en una red tomando como base el protocolo TCP el cual soporta la mayora de aplicaciones que generan el trafico de una red de telecomunicaciones.

Optimizacin de Trfico
Docente Ing. Luis Marrone Ing. Luis Eduardo Romero Universidad de Buenos Aires 20/09/2011

Resumen En trminos generales podemos definir el trfico como la cantidad de informacin que se enva o recibe a travs de una red de rea Loca LAN, una Redes de rea Amplia WAN, o Redes de rea Metropolitana MAN. Debido a que la correcta gestin de los recursos en una red son mucha importancia para garantizar una comunicacin confiable y de calidad entre dos extremos de un red, diferentes modelos han sido propuestos para el transporte de este trfico; sin embargo, ha sido TCP junto a sus caractersticas el modelo que ms se ha ajustado para el transportar el trafico. Tomando como base el modelo TCP, se han realizado numerosos estudios que han contribuido a una mejor entendimiento del modelo TCP sus mecanismos para el control de flujo y control de congestin. A travs de un anlisis de trfico y propiedades podemos conocer y predecir el comportamiento de una red de telecomunicaciones, sus estados de congestin y rendimiento. Adicionalmente es muy utilizado para realizar estudios de planeamiento, capacidad y throughput en una red. [1] Existen diferentes modelos de trfico los cuales fueron pensados inicialmente para modelar trafico de voz, es decir el trafico telefnico que se caracterizaba por tener memoria nula (es decir que cada uno de sus sucesos son independientes y no dependen del anterior para generar un nuevo suceso). Sin embargo, con el crecimiento exponencial del trfico de datos, el desarrollo de nuevas tecnologas y convergencia de los servicios de datos, se han requerido hacer y replantear nuevos modelos que permita hacer un anlisis ms exacto del comportamiento del trfico de datos en las redes de telecomunicaciones [2]. Introduccin. Teniendo en cuenta que la base fundamental para el transporte de las diferentes clases de trfico en

una red de telecomunicaciones est basado en TCP, es importante hacer el anlisis de las caractersticas y funciones principales del protocolo, partiendo de su definicin en las norma RFC 793 [3] y [Jac88, RFC1323, RFC2581] [4], en las cuales se realizo la introduccin de nuevos mecanismos que permiten el mejoramiento en el rendimiento del protocolo. TCP es un protocolo de transporte orientado a conexin enormemente extendido en las aplicaciones de red ms populares (ftp, telnet, acceso Web), estas lo utilizan en sus comunicaciones. La funcin principal del protocolo a nivel de transporte dentro de la arquitectura de protocolos TCP/IP es la de permitir la comunicacin extremo a extremo entre dos aplicaciones de forma econmica y fiable. La unidad bsica de transferencia del protocolo se denomina segmento, su tamao mximo se denomina MSS (Maximum Segment Size) y es expresado en octetos, que como veremos ms adelante se negociar por los extremos de la comunicacin en el establecimiento de la misma. Por otro lado existe otro protocolo de transporte en la arquitectura TCP/IP muy diferente, UDP (User Datagram Protocol). ste es mucho ms sencillo que TCP. Se limita a enviar paquetes de datos, denominados datagramas, de un terminal a otro sin garantizar que stos sean recibidos correctamente. Si la aplicacin requiere fiabilidad en la comunicacin, deber ser ella misma la que se la proporcione o bien se tendr que recurrir al TCP.

CARACTERISTICAS DE TCP El principal propsito de TCP es proporcionar un servicio de conexin o circuito lgico confiable y seguro entre pares de procesos. Para poder proveer estos servicios el protocolo debe poseer caractersticas que le permitan proveer un servicio

confiable en redes menos confiable como lo es internet. El protocolo debe cubrir las siguientes areas [5]: Transferencia Bsica de Datos Fiabilidad Control de Flujo Multiplicacin Conexiones

ventana (WINDOWS), con cada confirmacin ACK que indica un rango de nmero de secuencia aceptable ms all del ltimo segmento recibido correctamente. La ventana bsicamente indica la cantidad de octetos permitidos que el emisor puede transmitir. Multiplexado. Para permitir que muchos proceso dentro de un mismo host utilicen simultneamente las posibilidades de comunicacin de TCP, el protocolo proporciona una serie de direcciones y puertos en cada host, estos parmetros junto a la direccin de host y red de la capa de comunicacin internet conforman una direccin de conector o socket que sirve como identificador nico para cada conexin. Conexiones. Cuando cada proceso se desea comunicar, los mdulos TCP, deben estableces primero una conexin. Cuando la comunicacin se completa, la comunicacin se termina o cierra con la intencin de liberar recursos para otros usos.

Aunque en la definicin de TCP no aparece ningn mecanismo especfico para el control de la congestin, Se han desarrollado varios son los algoritmos con este objetivo. Transferencia Bsica de Datos. TCP es capaz de transferir un flujo continuo de octetos en cada sentido entre sus usuarios empaquetando N nmero de octetos en segmentos para ser trasmitidos a travs de las redes de telecomunicaciones. Fiabilidad. TCP debe tener la capacidad de recuperar los datos daados, perdidos duplicados, o entregados fuera de orden por el sistema de comunicaciones. Esto es logrado asignando un nmero de secuencia a cada octeto transmitido y solicitando una confirmacin positiva ACK del destino con l con el destino con el cual se ha establecido la comunicacin TCP. Si la confirmacin ACK no es recibida dentro de un intervalo de tiempo determinado como retransmition Timeout (RTO), los datos son retransmitidos. En el receptor los nmeros de secuencia son usados para ordenar correctamente los segmentos que se puedan recibir fuera de orden y eliminar segmentos duplicados. Control de Flujo. TCP proporciona un medio para que el receptor regule la cantidad de datos enviados por la fuente. Esto se logra mediante la devolucin de una

MODELO TCP. Desde que diferentes tipos de aplicaciones como HTTP y TFP usan TCP como su protocolo de transporte, un modelo de trafico TCP es introducido para representar con mayor precisin la distribucin de paquetes para diferentes clases de trafico como HTTP y FTP. TCP es un protocolo que est orientado a conexin el cual establecer en cada transferencia de datos una conexin previa al inicio y un posterior cierre de conexin una vez finalizada la transmisin. Tambin proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma mquina a travs del concepto de puerto. De esta forma se podrn mantener al mismo tiempo distintas conexiones TCP.

Toda conexin TCP consta de tres fases: 3) 1. Establecimiento de conexin 2. Transferencia de datos 3. Cierre de conexin 1. Establecimiento de Conexin Par realizar iniciar el establecimiento de la conexin se lleva a cabo un mecanismo denominado negociacin en tres pasos (three-way handshake). Inicialmente el lado cliente realiza una apertura activa de un puerto enviando un segmento SYN inicial al servidor indicando su nmero inicial de secuencia (Flags = SYN, SequenceNum = x), como parte de la negociacin en tres pasos. El lado servidor respondera a la peticin SYN vlida con un paquete SYN/ACK, confirmando el numero de secuencia del cliente (Flags =ACK, Ack = x + 1) y indicando su propio numero de secuencia (Flags = SYN, SequenceNum = y). Finalmente, el cliente debera responderle al servidor con un ACK, confirmando el numero de secuencia del server (Flags = ACK, Ack = y + 1), completando as la negociacin en tres pasos (SYN, SYN/ACK y ACK) y la fase de establecimiento de conexin. En la Figura 1, se puede observar esta fase para el establecimiento de la conexin [6].

A <-- B SYN mi nmero de secuencia es Y A --> B ACK tu nmero de secuencia es Y+1

Figura 1. Fase de Establecimiento de una Conexin TCP [7]. 1.1 Cierre de Conexin. Para la fase de cierre de la conexin se realiza una negociacin en cuatro pasos (fourway handshake), de este modo se terminan la conexin desde cada extremo independientemente. Cuando uno de los dos extremos de la conexin desea parar su "mitad" de conexin transmite un paquete FIN, que el otro interlocutor asentir con un ACK. Por tanto, una desconexin tpica requiere un par de segmentos FIN y ACK desde cada lado de la conexin Figura 2.

1) 2) 3) 4)

A --> B FIN de Conexin A <-- B ACK A <-- B FIN de Conexin A --> B ACK Figura 2. Fase de Desconexin TCP.

1) A --> B SYN mi nmero de secuencia es X 2) A <-- B ACK tu nmero de secuencia es X+1

2. Transferencia de Datos. Durante la transferencia de datos el protocolo TCP dispone de una serie de mecanismos que dan fiabilidad y robustez al protocolo. Entre ellos est incluido el uso del nmero de secuencia para una transferencia ordenada de los segmentos TCP recibidos y detectar paquetes duplicados, retransmisiones de paquetes perdidos o fuera de secuencia, checksum para transferencia de Datos libre de errores, control de Flujo para limitar la

velocidad de transferencia de los datos y garantizar la entrega confiable, control de Congestin para optimizarle uso de la red y evitar una sobrecarga de trfico y temporizadores para detectar prdidas y retrasos. 2.1 Control de Flujo TCP proporciona al receptor un medio para controlar la cantidad de datos almacenados en el buffer del emisor y que pueden ser enviados. Esto se consigue devolviendo una ventana "Windows" con cada ACK, indicando el rango de nmeros de secuencia aceptables ms all del ltimo segmento recibido con xito. La ventana indica el nmero de octetos que se permite que el emisor transmita antes de que reciba el siguiente ACK.

Figura 4. Concepto de Ventana de Recepcin. En la figura 4 El receptor reporta al emisor el tamao disponible en el buffer en entrada (receivers window, rwnd) y el emisor enva una porcin (window,wnd) de paquetes de datos que no exceden la ventana de recepcin rwnd. Para realizar este control TCP utiliza un concepto llamado ventana deslizante, a travs del cual permite al emisor transmitir n segmentos de informacin sin validacin unacknowledge, n define el tamao de la ventana enviada (swnd), antes de que el receptor le confirme con un mensaje ACK la recepcin de los segmentos. Este ACK puede ser del siguiente segmento que espera recibir el receptor NextSegRcv o del ltimo segmento recibido con xito LastSegRcv, adicionalmente contiene el tamao de la ventana del receptor rwnd, de esta forma el emisor puede identificar el nmero de envos exitosos, perdidos o que se esperan recibir. Cada vez que el emisor recibe un ACK con la nueva cwnd, la ventana se desliza n segmento (swnd) segmentos. En la figura 5, se muestra un diagrama del funcionamiento de ventana deslizando con una ventada de de 3 segmentos [9]

Figura 3. Concepto de Ventana deslizante. En la Figura 3[7] la ventana se desliza slides a lo largo de la salida del buffer del emisor, tan pronto recibe un acknowledges entrega el resto al menos una paquete. En el caso de que el emisor produzca una tasa de datos mayor a la velocidad del proceso en el receptor, este ltimo enviar un mensaje control al emisor para que este reduzca su tasa de envi, de esta forma, el emisor reducir la tasa de envi y el receptor podr procesar el trfico que le enva el nodo.

fcilmente la capacidad mxima de la red. Hablando del control de flujo si la carga de trafico ofrecida en un sistema compartido sin control distribuido sobrepasa la capacidad total del sistema, la carga efectiva del sistema se ir a cero en decir colapsa a medida que aumenta el trafico. En la Figura 6 se observa un ejemplo del trfico cursado en funcin del trfico ofrecido. La curva (1) representa el comportamiento ideal de la red: hay linealidad hasta llegar a la capacidad nominal o mxima de la red, momento en el que el trfico cursado se satura. La curva (2) representa el comportamiento real tpico de una red. Como puede observarse, al llegar a la zona de saturacin, cuanto ms trfico se ofrece menos trfico se cursa hasta colapsar. Esto es debido, por ejemplo, a que los paquetes tardarn mucho tiempo en llegar a su destino, y mientras tanto sern retransmitidos por la fuente, pensando que se han perdido por el camino. Esto, a su vez, origina una explosin de trfico, ya que cada paquete es retransmitido varias veces, hasta que consigue llegar a tiempo al destino. Para evitar esa degradacin, se introduce el control de congestin que trata de aproximar el comportamiento de la red al dado por la curva (3), evitando as entrar en una zona de degradacin [10].

Figura 5. Ventana deslizante dentro de un flujo de bytes. 2.2 Control de Congestin. El control de congestin es un concepto ms amplio que el control de flujo. Comprende todo un conjunto de tcnicas para detectar y corregir los problemas que surgen cuando no todo el trfico ofrecido a una red puede ser cursado, cuando no se cumplen los requerimientos de retardo, u otros aspectos necesarios desde el punto de vista de la calidad del servicio. El control de congestin involucra a toda la red, y no slo a un remitente y un destinatario de informacin, como el control de flujo. Algunos de los factores que podran influir en la congestin de una red podra ser la insuficiencia de memoria, CPU de los diferentes dispositivos de red que intervienen en la comunicacin como routers o switches, y velocidad insuficiente de las lneas formando cuellos de botella que afectan significativamente la entrega correcta y a tiempo de los paquetes. El estndar inicial de TCP tiene serio problemas: Carece de los medios para ajustar la velocidad de transmisin al estado de la red. Cuando hay muchos usuarios y usuarios demando recursos compartidos en la red, la suma de las tasas de todos los usuarios compartiendo la misma red puede exceder

Figura 6. Trafico cursado en funcin del trfico ofrecido.

Para resolver este problema se ha propuesto varios algoritmos para el control de congestin como extensin al estndar TCP [RFC 793], estos algoritmos proporciona un buen nivel de precisin para detectar y prevenir la congestin y el colapso del trfico.

valor se aproxime lo mximo posible a la ventana ptima (Wopt). La ventana ptima es aquella que al enviar los datos aprovecha todo el canal y se define como el producto del retardo y el ancho de banda de la conexin.

Cuando la ventana sea menor que la Wopt habr ineficiencias (se desaprovechara ancho de banda). Y en el caso de que la ventana sea mayor no se podrn absorber todo el trfico y las colas intermedias se llenaran aumentando potencialmente la probabilidad de que se pierdan paquetes. TCP utilizar como ventana mxima (wmax) el mnimo entre la advertised window ( rwnd ) y la ventana de congestin cwnd para as evitar que se congestione la red como que se sature al receptor. As la ventana efectiva se define como: Figura 7. Evolucin de las variantes de TCP. Extrada de [8] Donde: Algunos de los algoritmos ms importantes que incorpora TCP para controlar la congestin son: Slow Start, Congestin Avoidance, Fast Retransmit y Fast Recovery. Estos se pueden clasificar en tres grupos los cuales discutiremos mas adelante. Antes de explicar con detalle en qu consisten estos mecanismos y para poder entenderlos definiremos el concepto de ventana de congestin (cwnd). La ventana de congestin nos indica la cantidad de datos que se pueden enviar sin que la red se congestione. La ventana de congestin est definida en trminos de bytes y su tamao no puede ser menor al Tamao mximo de segmento (MSS). Los mecanismos de control de congestin adaptaran el valor de esta ventana al trfico de la red y siempre intentarn, cuando no exista congestin, que ese LBS= Ultimo Byte Enviado LBR=Ultimo Byte Recibido. La idea del control de congestin es controlar la ventana efectiva mediante la ventana de congestin, incrementando la ventana de congestin si disminuye la congestin o bien disminuyndola cuando la congestin aumente.

Anteriormente habamos mencionado que algunos de los algoritmos ms importantes para el control de congestin se podan agrupar en tres grupos bsicamente.

El primer grupo aborda el problema de estimacin de retransmisin de timeout errnea (RTO). Si el valor es sobreestimado, el mecanismo de deteccin de prdida de paquetes TCP se vuelve conservativo y el performance de los de cada uno de los flujos de trfico se podra degradar significativamente. En el caso contrario cuando el valor de RTO es subestimado, el mecanismo de deteccin de error podra presentar retransmisiones innecesarias, desperdiciando recursos compartidos de la red y empeorando la congestin generar de la red.

El algoritmo round-trip variance stimation (rttvar), trata de mitigar el problema de sobreestimacin. En vez de un relacin lineal entre el tiempo de retransmisin (RTO) y el valor del tiempo de ida y vuelta (RTT), [*SRTT, donde es una constante en el rango de 1.3 a 2 [11] y SRTT es un valor promedio del valor de RTT], el algoritmo calcula una variacin de RTT estimados para establecer una lmite superior granular fino para de RTO [SRTT + 4*rttva ]

Claramente el mnimo tiempo requerido para detectar la perdida de paquetes es el tiempo de ida y vuelta RTT; es decir, si el receptor es capaz de de detectar instantneamente la perdida y reportar al emisor, el reporte llegara un RTT despus de haber enviado el paquete perdido. El RTO por definicin es mayor que RTT. Si se requiere que TCP reciba inmediatamente un reporte de todos los paquetes de datos fuera de orden con el reporte del ltimo paquete recibido en orden (un ACK duplicado)[12] , la perdida puede ser detectada por el algoritmo fast-retransmit [13], al menos dentro del intervalo RTT, es decir asumiendo la probabilidad de reordenamiento de paquetes y duplicaciones en la red sea despreciable, la duplicacin de ACK pueden ser considerados un indicador confiable de perdida. Con este nuevo indicador el emisor puede retransmitir los datos perdidos sin esperar por el correspondiente evento de RTO.

El algoritmo exponential retransmit timer Backoff resuelve problema de subestimacin duplicando el valor de RTO en cada evento de retransmisin, en trminos generales durante problemas severos de congestin la deteccin de prdida de paquetes da como resultado un incremento exponencial del RTO, lo que reduce significativamente el nmero total de retransmisiones y ayuda con la estabilizacin del estado de la red.

El segundo grupo de algoritmos mejora la deteccin de prdida de paquetes La norma original de TCP especfica RTO como el nico mecanismo de deteccin de paquetes. Aunque es suficientemente eficiente para detectar la perdida de paquetes, su deteccin no es lo suficientemente rpida.

Algoritmos Fast Retransmit y Fast Recovery En las primeras implementaciones de TCP y al realizar el control de congestin los investigadores se dieron cuenta que al producirse una prdida de paquetes se perda mucho tiempo hasta que se agotara el RTO lo que hacia el protocolo ineficiente. Debido a esto se introdujo a TCP un nuevo mecanismo llamado Retransmisin Rpida (Fast Retransmit). Cada vez que llega un paquete al receptor, ste responde con un ACK, an cuando el nmero de secuencia ha sido reconocido. Entonces, cuando un paquete llega fuera de orden, es decir, TCP no puede reconocer el dato que contiene el paquete porque datos anteriores an no han llegado, TCP reenva el mismo ACK que envi la ltima vez. Esta segunda transmisin del mismo ACK se denomina ACK duplicado. Cuando el lado emisor ve el ACK duplicado, sabe que el otro lado ha recibido un paquete fuera de orden, lo que le sugiere que un paquete enviado con anterioridad se perdi. Como es posible que el paquete no se haya

perdido sino que nicamente se haya retrasado en la prctica se considera que habr una prdida cuando se reciban hasta 3 ACKs duplicados, Figura 8.

Figura 9. Comportamiento de Ventana con Fast Recovery y Fast Retransmit. A su vez hasta que no se reconozca el paquete retransmitido, por cada ACK repetido que llegue aumentaremos en un MSS la cwnd y podremos mandar un nuevo paquete (si la ventana efectiva lo permite). De esta forma se seguir usando FastRetransmit hasta que el paquete perdido llegue a su destino. Caso contrario donde no se sigan enviando nuevos paquetes, vencera el timeout y durante ese momento se habra vaciado el canal creando ineficiencia. Al igual que en Slow Start y Congestion Avoidance cuando expire el RTO para algn paquete se inicializa cwnd, se inicia Slow Start y se divide por dos el threshold [14].

Figura 8. Algoritmo Fast Retransmit. Con este mtodo se podr detectar cuando se haya producido una prdida antes de que expire el RTO. Cuando un emisor reciba 3 ACKs duplicados responder con la inmediata retransmisin del paquete que se ha perdido. Finalmente es posible introducir una nueva mejora llamada Recuperacin Rpida (Fast Recovery). Si detectamos prdida por ACKs duplicados no volvemos a la fase de Slow Start, en su lugar la ventana de congestin pasa a ser la mitad de cuando se detect la prdida figura 9; y adems el threshold de Slow Start pasa a ser:

Donde: cwnd = amao de ventana actual de datos enviados pero an no reconocidos.

El tercer grupo es el ms importante e incluye los algoritmos low-start y congestion-avoidance. Estos proveen dos ligeras diferencias distribuidas en el mecanismo host to host, que permito a emisor detectar los recursos de red disponibles y ajustar la velocidad de transmisin del trafico TCP al lmite detectado. Asumiendo una probabilidad de paquetes corruptos aleatoriamente durante una trasmisin sea ligeramente (<<1%), el emisor puede tratar todas las perdidas detectadas como indicadores de congestin. Adicionalmente la recepcin de cualquier ACK es indicador de que la red puede aceptar y entregar al menos un nuevo paquete. As el emisor seguro de esto no causara congestin y podr enviar al menos la misma cantidad de datos que fueron confirmados a travs

del ACK. Esta entrada y salida de paquetes es conocida como el principio de conservacin de los paquetes y es un elemento principal junto con slow start y Congestion Avoidance. En el algoritmo slow start segn la norma original el crecimiento en el nmero de paquetes pendientes seria como un escaln como se ve en la figura 10.

Figura 11. Dinmica de la ventana de Congestin y la eficiencia de Slow-Start si el lmite es impuesto por el control de flujo norma original (izquierda) y la Red (derecha). En la figura 11, se muestran dos clases de ventana de congestin la grafica de la izquierda representa el caso cuando el receptor no puede procesar la tasa de llegada. La figura de la derecha muestra la dinmica de la ventana de congestin, cuando la red no puede entregar todo el trfico a la tasa de transmisin. El otro algoritmos del tercer grupo Congestion avoidance. Esta dirigido a mejorar la eficiencia del protocolo TCP en redes con recursos limitados, es decir donde la transmisin sobre la red resulta en un cuello de botella real. En comparacin con slow start, este algoritmo es ms conservador con la confirmacin de los ACK recibidos y la deteccin de prdida de paquetes. Cada vez que recibe un ACK incrementara la ventana de congestin en uno, es decir no doblara su valor, de esta forma el crecimiento ser lineal y permitir que todos los paquete sean entregados exitosamente durante el ltimo tiempo de ida y vuelta RRT.

Figura 10. Asignacin Dinmica de paquetes de salida definida en RFC793 Cuando una conexin TCP comienza, el algoritmo Slow-Start inicia la comunicacin probando la red, enviando un solo segmento, y fija el tamao mximo (MSS) de la ventana de congestin (cwnd) en un segmento durante el establecimiento de la conexin. Cuando recibe el acknowledge (ACK) la ventana (cwnd) aumenta un segmento, con lo que se envan dos segmentos, y as sucesivamente, resultando en un aumento exponencial de la ventana de congestin, como se puede observar en la Figura 11 de la parte izquierda. Este comportamiento se denomina slow start, y finaliza cuando la ventana de congestin alcanza un umbral denominado show start threshold (ssthresh).

Cuando una prdida de paquetes es detectada la ventana de congestin reinicia para volver a su valor inicial para asegurar la liberacin de los recursos de red como se observa en la figura 11 de la parte derecha

En contraste con el reinicio del protocolo despus de detectar una perdida, la ventana de congestin es divida a la mitad, este comportamiento el llamado disminucin multiplicativo.

La poltica de disminucin multiplicativa limita el comportamiento exponencial, cuando varios paquetes consecutivos se determinan como perdidos (por ejemplo, durante el persistente estado de congestin). Como se puede observar en la Figura 12, el algoritmo congestion avoidance es muy eficaz en el largo plazo. La compensacin es un lento descubrimiento de recursos disponibles en la red debido a la tasa conservadora de la fase de aditiva.

cuando el valor de la ventana de congestin sea menor que el parmetro de threshold, la fase de slow start es usada. Una vez la ventana de congestin es mayor que el parametro de threshold, el algoritmo de congestion avoidance es usado, esto es conocido como el cliclo slow start congestion avoidance. Este comportamiento se puede observar el la figura 13.

Figura 13. Dinmica de la Ventana de congestin combinando el algoritmo Slow-Start (SS) y Congestion Avoidance (CA) Figura 12. Dinmica de la Ventana de Congestin y eficiencia de algoritmo Congestin Avoidance. Extensiones del protocolo TCP como TCP Tahoe incluyen los algoritmos Slow start y Congestion avoidance en como distintas fases de operacin. Esto combina el rpido descubrimiento de los recursos de red y eficiencia a largo trmino. Esta combinacin de rpido descubrimiento de los recursos de red y eficiencia para propsitos de cambio de fases es introducido un parmetro de umbral (ssthresh), este parmetro determina el mximo (MSS) tamao de la ventana de congestin (cwnd), en la fase de slow start con cualquier prdida de trfico detectada,se ajusta el valor de threshold a la mitad del valor de la ventana de congestin (cwnd=cwnd/2), la ventana de congestin por s misma como en el algoritmo slow start, es siempre reiniciada a un valor mnimo con la deteccin de prdidas de trfico. Siempre y Extensiones del Protocolo TCP El comportamiento de TCP est especificado en las RFC (Request for Comments). Sin embargo, no hay un TCP estndar, sino que existen versiones de TCP que emplean los distintos algoritmos para el control de la congestin. En la Tabla 1 se muestra un resumen de las versiones de TCP ms conocidas y sus caractersticas principales[15].

Tabla 1. Algunas versiones de TCP y sus caractersticas.

TCP Tahoe La versin TCP Tahoe se incorpor al sistema operativo BSD en 1988. Fue la primera en incorporar los mecanismos de control de congestin y de estimacin de RTT. El primero de los mecanismos que fue introducido fue el de inicio lento (slow start), y el segundo el de la estimacin de RTT basado, adems de la media, en medidas de la varianza. Otro mecanismo incorporado fue el de prevencin de congestin (Congestion avoidance). Por ltimo, se introdujo el mecanismo de Retransmisin Rpida (Fast Retransmit). TCP Tahoe tiene por tanto los mecanismos bsicos de congestin y recuperacin de prdidas, y es el ms comn en las implementaciones actuales. No obstante, el principal inconveniente que presenta es el del Inicio Lento, concretamente en enlaces de retardo elevado, provocando el bajo rendimiento del protocolo. TCP Reno La versin TCP Reno se incorpor al sistema operativo BSD en 1990. ste incorpora todas las caractersticas de TCP Tahoe y aade el algoritmo de Recuperacin Rpida (Fast Recovery) que acta conjuntamente con el de Retransmisin Rpida (Fast Retransmit). De esta forma, tras la retransmisin no se invoca el algoritmo de Inicio lento, sino el de Prevencin de la Congestin (congestion avoidance), permitiendo una recuperacin ms rpida tras la retransmisin. El inconveniente ms destacado es que, en caso de tener mltiples prdidas por ventana, el protocolo de retransmisin rpida no puede recuperar de forma rpida ms que la primera prdida. TCP New-Reno La versin TCP New-Reno se propuso en [Hoe96]. Se propone una modificacin al algoritmo de Recuperacin Rpida (fast recovery) de forma que en caso de que existan varias prdidas por ventana solucione el problema de TCP Reno.

TCP Vegas En 1995 se propone [BrP95a, BrP95b] otra versin del protocolo denominada TCP Vegas. En ella se modifican algunos aspectos de los algoritmos de Retransmisin y Recuperacin Rpida, as y como del de Inicio Lento. Como aspecto ms relevante, no obstante, es la propuesta a actuar contra la congestin antes de que sta se detecte por la expiracin del temporizador de retransmisin. TCP Vegas introduce un algoritmo para la prediccin de la cantidad de datos que el enlace puede cursar sin congestin, e inyecta en el enlace dicha cantidad. Esta prediccin se basa en medidas de tasa de trfico.

Conclusin Con la elaboracin de este trabajo se ha querido dar a conocer la importancia que tiene el protocolo TCP en el transporte de de diferentes clases trfico en una red de telecomunicaciones. La implementacin del protocolo con sus diferentes mecanismos y algoritmos para control de flujo y control de trfico son la base fundamental para que se asignen y regulen de una manera ptima los recursos de una red, que en definitiva son compartidos y limitados. Si bien los mecanismos de control de flujo y congestin en la norma original [RFC793] del protocolo TCP cumplen con las caractersticas para el control de trfico, presenta problemas con la gestin de altas tasas de datos. Este problema se traduce en una indisponibilidad de los recursos de red y prdidas de trfico, lo que hace al protocolo en su definicin original poco eficiente. Para superar estos problemas se han propuesto mejoras a la norma originar como slow-start, congestionavoidance, fast-retransmit y fast recovery, que le dan una mayor robustez y eficiencia al protocolo TCP en la gestin del trfico y utilizacin de los recursos de red. Pero una con estos mecanismos, mejoras propuesta y nuevas versiones como TCP

Tahoe, TCP Reno, New Reno, Vegas, el protocolo TCP no puede garantizar al emisor como al receptor un ancho de banda o flujo de datos constante en el tiempo, los que no es un problemas cuando de dispone de recursos de red con un amplio BW. Contrario a esto, en una red con poca capacidad se convierte en un problema que se traduce en altos tiempos, bajo throughput y prdida de trfico al haber simultneas conexiones TCP sin que ninguna llegue a estar al 100% de las capacidades de la red, pero tampoco al 0 %. Este comportamiento lo sigue haciendo poco fiable para flujos de trafico como voz, video, por lo que se puede pensar en nuevos mecanismos de control de trfico como TCP friendly Rate Control (TFRC), pensado para entornos de redes best-effort como internet. Es razonablemente justo cuando la competencia de ancho de banda con flujos TCP, pero tiene una variacin mucho menor de rendimiento a travs del tiempo en comparacin con el TCP, por lo que es ms adecuado para aplicaciones como streaming media, donde una suave relativamente velocidad de envo es de suma importancia. Referencias. [1] http://www.slideshare.net/gpino86/informeevaluacion-trafico-2868264, Evaluacin de Redes [2]http://upcommons.upc.edu/pfc/bitstream/2099. 1/3764/1/54605-1.pdf, Universidad Politcnica de catalunya, Caractersticas de trafico TCP con propiedades fractales sobre redes WLAN. [3] http://www.rfc-es.org/rfc/rfc0793-es.txt [4] http://www.ietf.org/rfc/rfc1323.txt [5] http://www.rfc-es.org/rfc/rfc0793-es.txt [6] http://www.rfc-es.org/rfc/rfc0793-es.txt

[7]Computer Networks_ A Systems Approach, 3rd Edition-Petersen. [8]http://lasr.cs.ucla.edu/afanasyev/data/files/Afan asyev/Hosttohost%20congestion%20control%20for %20TCP.pdf [9] http://gtcc-it.net/billings/tcpudp.htm [10] Web de Redes y Servicios de Comunicaciones. Departamento de Ingeniera Telemtica, Universidad Carlos III (Madrid). Control de Congestin.http://www.it.uc3m.es/~prometeo/rsc/ apuntes/Conges/conges.html [11] J. Postel, RFC793transmission control protocol, RFC, 1981. [12] R. Braden, RFC1122Requirements for Internet Hosts Communication Layers, RFC, 1989. [13] W. Stevens, RFC2001TCP Slow Start, Congestion Avoidance, FastRetransmit, RFC, 1997. [14] http://tools.ietf.org/html/rfc2581#section-3.2 [15] http://es.scribd.com/doc/37451642/AlgoritmoFast-Recovery