0% encontró este documento útil (0 votos)
124 vistas6 páginas

TCP Reno: Control de Congestión

Este documento describe el protocolo TCP Reno, incluyendo sus fases (slow start, congestion avoidance y fast recovery), cómo controla la congestión modificando el tamaño de la ventana de congestión, y cómo reacciona ante pérdidas de paquetes.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
124 vistas6 páginas

TCP Reno: Control de Congestión

Este documento describe el protocolo TCP Reno, incluyendo sus fases (slow start, congestion avoidance y fast recovery), cómo controla la congestión modificando el tamaño de la ventana de congestión, y cómo reacciona ante pérdidas de paquetes.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

DESCRIPCIÓN DEL PROTOCOLO: TCP RENO

Grupo de trabajo:

- Alba Carmona Vez


- Óscar Gómez Palomares
- Francisco Ruiz González

1. Entorno

TCP es un protocolo de la capa de transporte cuya función principal es la de


proporcionar fiabilidad al envío de paquetes por la red, ya que el protocolo IP (capa de
red) no proporciona ningún mecanismo de fiabilidad.

Muchas veces las aplicaciones necesitan que la comunicación a través de la red sea
fiable. Para ello se implementa el protocolo TCP que asegura que los datos que envía
el emisor sean recibidos por el destino sin errores y en el mismo orden que fueron
emitidos, a pesar de trabajar con los servicios de la capa IP, la cual no es confiable.

TCP (que incluye el algoritmo TCP Reno) se sitúa entre la capa de aplicación y la capa
de red (concretamente IP) de la pila TCP/IP.
2. Servicio

TCP es un protocolo fiable, es decir, garantiza que los mensajes lleguen al


destino y lo hagan en orden. Es un protocolo ARQ, es decir, un protocolo que se
basa en la retransmisión de paquetes si éstos se pierden.

TCP Reno es un algoritmo reactivo que permite el control de la congestión en el


protocolo TCP. Los algoritmos reactivos modifican el tamaño de la ventana de
congestión (CWND) tras detectar pérdidas de paquetes.

La congestión ocurre cuando un router tiene una tasa de entrada mayor que la que
puede dar a la salida y cuando su buffer de entrada se llena. En este momento se
empezarían a descartar los nuevos paquetes recibidos, se avisaría al emisor y se
produciría la retransmisión de éstos, colapsando aún más al router.

3. Vocabulario (mensajes)

Los tipos de mensajes que nos podemos encontrar en TCP Reno son los mismos que
en TCP (que contienen, entre otros campos, los flags SYN, SYN-ACK, ACK, FIN, RST,
URG, ECE, CWR), pero los que nos interesan en TCP Reno son los mensajes que
contienen el flag ACK, ya que es el mecanismo en que se basa este protocolo.
Este mensaje se envía para confirmar al otro extremo que hemos recibido su paquete.
En TCP, se considera que un paquete se ha perdido si se reciben 3 DUPACK (ACK
duplicado) o si expira el temporizador RTO. Un DUPACK se envía cuando recibimos un
mensaje del otro extremo con número de secuencia mayor del que estamos esperando,
y este DUPACK llevaría como número de ACK el que estamos esperando, para así
avisar al otro extremo de que aún no se ha recibido el paquete con ese número de
secuencia.

El otro tipo de “mensaje” que vamos a considerar es la expiración del RTO (es decir,
una señal de tipo timer en SDL). Este mensaje servirá para informar al algoritmo de que
un paquete se ha perdido y que actúe de cierta forma, cambiando de estado y
restableciendo a 1*MSS el tamaño de la ventana de congestión, además de cambiar
otros parámetros (ver “Reglas”).
El RTO es un temporizador que utiliza TCP que se activa cada vez que realiza el envío
de un nuevo mensaje. Si llega el ACK correspondiente a ese mensaje, el RTO se para
pero, si no llega y expira el RTO, se considera que el paquete se ha perdido y se
produce la retransmisión de éste, además de entrar en estado de recuperación (no
considerado en este modelo). Existen varios métodos de implementación del RTO
(clásico, estándar y linux), aunque por simplificación en nuestro modelo, vamos a
considerarlo como un timer más con un número de segundos asignado. Además, este
timer tiene un valor diferente para cada conexión, pero vamos a considerarlo igual para
todas por simplificación del modelo.

4. Reglas

El funcionamiento de TCP Reno se divide en 3 fases y es el siguiente:

1) Slow start

Siempre comenzamos en la fase de Slow Start.

Al inicio, ninguno de los extremos sabe cual es el máximo volumen de datos que puede
transmitir la red. Si ésta se satura comenzará a descartar paquetes, que tendrán que
ser retransmitidos, lo cual incrementará aún más la saturación de la red.

El objetivo de esta fase es sondear la capacidad que ofrece la red, utilizando un valor
umbral. La tasa de envío inicial viene dada por CWND = 1*MSS, donde MSS es el
Maximum Segment Size (tamaño máximo del segmento que puede recibir).

La tasa de envío crece exponencialmente (dobla su valor) en cada RTT (Round-Trip


Time) (tiempo de ida y vuelta de un mensaje) hasta una pérdida o el alcance del umbral
(sstresh: estimación del tamaño de la ventana del emisor a partir del cual existe riesgo
de congestión), en cuyo caso se pasaría a la fase de Congestion Avoidance.

En TCP Reno se considera que un timeout (RTO) es más preocupante que una pérdida
porque al menos llegan algunos segmentos (si llegan DUPACK significa que el otro
extremo está recibiendo segmentos nuevos aunque no sean el esperado, mientras que
si salta un RTO significa que el otro extremo no ha recibido nuestro mensaje).

Cuando expira el RTO, seguimos en el estado Slow Start y las variables se actualizan
de la siguiente manera: ssthresh = CWND/2; CWND = 1*MSS.

Por otro lado, si llegan 3 DUPACK (Fast Retransmit), las variables se actualizan a:
ssthresh = CWND/2; CWND = ssthresh + 3*MSS y pasamos al estado Fast Recovery.
2) Congestion Avoidance

Una vez se alcanza sshtresh, la tasa de envío pasa a tener un crecimiento lineal en
cada RTT: CWND+=1*MSS. Este proceso continúa hasta que se detectan indicios de
una posible pérdida.

Cuando expira el RTO, volvemos al estado Slow Start y las variables se actualizan de
la siguiente manera: ssthresh = CWND/2; CWND = 1*MSS.

Por otro lado, si llegan 3 DUPACK, las variables se actualizan a: ssthresh = CWND/2;
CWND = ssthresh + 3*MSS y pasamos al estado Fast Recovery.

3) Fast Recovery

Entra en este estado cuando llegan 3 DUPACK. Cuando es el caso, retransmite el


segmento y se queda en Fast Recovery hasta que dejen de llegar DUPACK y llegue un
ACK de un nuevo segmento (mayor al anterior), o hasta que expire el RTO.

Cuando expira el RTO, volvemos al estado Slow Start y las variables se actualizan de
la siguiente manera: ssthresh = CWND/2; CWND = 1*MSS.

Por otro lado, si llega el ACK de un nuevo segmento, las variables se actualizan a:
CWND = ssthresh, y volvemos al estado Congestion Avoidance.

Todas estas fases y estados pueden ser vistas como diagrama de máquina de estados
en la figura siguiente:
5. Codificación

La representación a nivel de bit de TCP Reno es la misma que la de los segmentos TCP. Es
decir, consta de una cabecera de 20B (sin opciones) y un campo de datos de longitud variable,
dependiendo del MSS.

Como observamos en la imagen, el segmento TCP está compuesto de los siguientes campos:

● Puertos origen y destino: identifican a la aplicación origen y destino de la comunicación.

● Número de secuencia: identifica el siguiente byte del flujo de datos que el emisor tiene
para enviar.

● Número de ACK: identifica el byte que el receptor espera recibir a continuación (último
recibido + 1)

● HLEN (offset) : Longitud de la cabecera en palabras de 4 bytes (5 ≤ HLEN ≤ 15)


(obviado en este modelo).

● Flags : existen diversos. En nuestro caso, nos interesan los segmentos que tienen
activo el flag ACK, ya que son los únicos que utilizaremos con TCP Reno.

● Tamaño ventana: número de bytes que está dispuesto a aceptar a partir del número de
ACK (obviado en este modelo).

● Checksum: control errores (obviado en este modelo).

● Puntero urgente: no usado normalmente.


● Opciones: existen varias, por ejemplo, WSOPT para aumentar el tamaño de la ventana,
SACK-Perm para usar en la comunicación Selective-ACK, etc. En nuestro modelo no
vamos a utilizar opciones por simplificación.

También podría gustarte