Edición de «Apunte de Clase del 30/10/2007 (Teoría de las Comunicaciones)»

<div style="border: 1px solid #CECEFF; padding: 5px; background-color: #EEEEFF; margin: 0px 0px 15px 0px;">[[Image:Back.png|14px|]] [[Teoría de las Comunicaciones|Volver a la página de la materia]]</div>

Clase del 30/10/2007

Tema de hoy: Control de congestión TCP (TCP CC)

Leer RFC 2581. Acá está la serie de algoritmos que utiliza el TCP CC. Hernán es el tercer profesor distinto que recomienda FUERTEMENTE leerlo. Yo lo haría.

Link: www.ietf.org/rfc/rfc2581.txt

Este control va a ser de lazo cerrado, i.e. va a tener algún mecanismo de retroalimentación. 

Cuál es el criterio para detectar cuando estamos por congestionarnos?

Si se pierde un paquete, debe ser porque no llegó a tiempo, o alguien lo tuvo que descartar (ya que tomamos como hipótesis una red que es bastante confiable).

El TCP CC es una implementación que hace el emisor.

Existe una variable llamada Congestion Window (CWND) que dice cuántos bytes podemos transmitir en determinado momento. 

El control de flujo también limita esta cantidad, pero se regula por el Receiver Window (RWND) o Advertise Window.

La ventana en la práctica queda dada por: 

min(RWND, CWND) - "datos en vuelo"   (N.deR.: el - es un menos, un operador aritmético)

Existen 4 fases que regulan el TCP CC.

IW (Initial Window): setea inicialmente CWND y también para resetearlo. No debiera ser más de 2 SMSS (Sender Maximum Segment Size, se negocia al principio de la conexión, y si no hay acuerdo el default es 576 bytes). Si el ancho de banda es muy grande se puede llegar a considerar un IW más alto. 

SSTHRESH

Primera fase:

SlowStart: 

 CWND <- IW
 por cada ACK
     CWND += SMSS bytes
     hasta CWND >= SSTHRESH
	
Se viene un gráfico que a esta altura deberían saber que no voy a dibujar. Caso normal: vienen los ACK correspondientes a los mensajes. Luego, voy creciendo exponencialmente como 2^n en cuanto al tamaño de CWND (en ordenada tenemos CWND y en abscisa tiempo). Llega un punto en que se pasa el nivel de SSTHRESH, y pasamos a la siguiente fase, en que se ejecuta otro algoritmo:

Congestion Avoidance:
	
 por cada ACK
     CWND += SMSS * SMSS / CWND   (Idea detrás de esta fórmula: por cada RTT quiero que CWND += SMSS)
	
La idea es que a partir de ese punto el crecimiento de CWND es lineal con respecto al tiempo.

En algún momento un paquete da timeout, entonces se va a modificar el CWND y el SSTHRESH. Y el CWND se resetea al valor original (IW). 	
	
 SSTHRESH = max("datos en vuelo" / 2, 2 * SMSS)
 CWND = IW 
 
Lo del RFC 2581 NO ESTÁ SUFICIENTEMENTE BIEN EXPLICADO en el Peterson. Repetimos: leer el RFC 2581.

Cuando un segmento de pierde, van a empezar a llegar ACKs duplicados, porque segmentos posteriores siguen llegando y el receptor le trata de recordar al emisor el que se perdió. 

El emisor podría asumir que si llegan ACKs duplicados es porque algo se perdió.

El emisor hace entonces Fast Retransmit: Espera 3 ACK duplicados para asumir que el segmento se perdió. En ese momento va a hacer de cuenta como que el segmento se perdió, retransmite y actualiza las variables de TCP CC acorde a esa situación (ejecuta lo mismo que en la tercera fase, ver arriba).

Cuarta fase:

Fast-Recovery: idea: no penalizamos volviendo a hacer Slow-Start. Mientras arreglo la retransmisión, voy a permitir que el receptor siga enviando ACKs. Cuando me recupero no empiezo desde IW.

Esto se ejecuta si se detecta una pérdida por 3 ACKs correspondientes al mismo segmento.

 SSTHRESH = max("datos en vuelo" / 2, 2 * SMSS)
 CWND = SSTHRESH + (3 * SMSS) 
 por cada ACK duplicado
     CWND += SMSS
     hasta que aparezca un ACK no duplicado
	
 cuando llega un ACK no duplicado
     CWND = SSTHRESH
	
Repetimos: esto es mientras no haya timeout. Cuando haya timeout la que se aplica es la tercera fase, no la cuarta. 

El receptor puede tener la posibilidad de demorar ACK. TCP soporta piggybacking. Mientras no tiene bytes para enviar en sentido contrario, puede esperar a tenerlos para meter el ACK en ese momento y aprovechar la volada.

Ventajas: menor tráfico, por hacer piggybacking.
Desventajas: va a producir un retraso en todas las fases del control de congestión (porque el avance de estas se da a partir de la llegada de ACKs).

No me hago cargo de la incompletitud de este apunte. Échenle la culpa a Sergio, que me hizo ponerme a instalar boludeces en vez de seguir apuntando.