Control de la congestión explicada a futuros telemáticos

Estaba el otro día leyendo un libro sobre redaes TCP/IP de altas prestaciones y me encontré con una joya en forma de explicación acerca de cómo funciona el control de la congestión en TCP que ya me hubiera gustado haberla leído cuando estudiaba telemática en su día. Le dí un par de vueltas y tras ver una charla de SharkFest’19 más un paper, me dicidí a preparar esta entrada.

Érase una vez…

Ásí suelen empezar muchas historias y la del control de la congestión lo hizo un día cualquieras en octubre de 1986 cuando el flamante enlace entre el laboratorio Laurence y el campus de de la universidad de Berkeley separados por menos de 400 metros, dos IMP (enrutadores) y dotado con un nada despreciable ancho de banda de 32Kbps, veía reducida su capacidad de transmisión a unos exiguos 40bps.

El resultado de la investigación de este caso fué el germen de lo que ahora implementan todos los sistemas operativos en su pila TCP/IP y que evita saturar los enlaces que atraviesan millones y millones de paquetes IP por segundo.

Control de flujo

Empecemos por definir un par de conceptos imprescindibles para entender los que es el control de la congestión. Cuando un equipo quiere recibir datos tras establecer una conexión TCP, este reserva cierto espacio en su memoria para esa conexión, verifica que los datos recibidos no tengan errores, los ordena y los añade a la memoria mencionada para que la applicación los lea e, inmediatamente, libere ese espacio para nuevos datos provinentes de posteriores segmentos de la misma conexión.

El emisor ha de enviar los bytes de información al receptor. En caso que el emisor transmita datos más rápido que la aplicación en recepción los consuma, habrá que disponer de un mecanismo que prevenga al receptor de ser saturado por un emisor. A este mecanismo se le llama control de flujo.

Llamamos ventana de transmisión a la cantidad de datos de aplicación, en bytes, que el emisor ha de transmitir al receptor. Para regular el control de flujo en el emisor, se aplica a la ventana de transmisión dos técnicas denominadas ventana deslizante (sliding window) y ajuste del tamaño de ventana (window size adjustment).

El tamaño de la ventana deslizante controla el número total de bytes que pueden estar en tránsito; es decir: enviados pero sin que el receptor haya recibido notificación de recepción (ACK). Esta notificación se encuentra en el campo Receiver Window Size de la cabecera del segmento que el receptor envía al emisor. Tras recibir el reconocimiento, el emisor incrementará la ventana el número de bytes indicados en el campo mencionado. A este mecanismo se le denomina ajuste del tamaño de ventana.

El emisor mantiene una variable llamada AdvertisedWindow para llevar el seguimiento actualizado del tamaño de la ventana.

Control de la congestión

Hasta ahora se ha presentado un mecanismo para no saturar la memoria del receptor por parte del emisor y esto funciona muy bien en redes ideales en donde no existe saturación en las memorias de los equipos intermedios (los enrutadores) que conectan las redes entre emisor y receptor. Esta es la situación que se dió en Berkeley allá por el 86 donde el emisor no se dió cuenta de la sobracarga de red entre routers que había e inundó con tetransmisiones el ya saturado enlace.

Para prevenir, que no evitar, la congestión en los equipos intermedios, TCP implementa un conjunto de mecanismos agrupados en lo que se denomina control de la congestión cuyo principio es ajustar la ventana de transmisión en el emisor de modo que se prevenga la saturación no solo en la memoria del receptor sino también en la de los enrutadores intermedios. Para ello en el emisor se implementa una variable de control llamada ventana de congestión (CongestionWindow o cwnd) de modo que el tamaño de la ventana de transmisión vendrá definida como:

Tx\ Window = min(AdvertisedWindow, CongestionWindow)

Ahora queda la parte de la magia que es el como conocer la cantidad de memoria disponible en los routers para asignarle idealmente a la variable cwnd el tamaño de la memoria disponible en el erutador más saturado entre el emisor y receptor. Ello en esencia es coplejo dado que los enrutadores no analizan la capa de transporte y por tanto los mecanismos a aplicar solo pueden basarse en los datos disponibles hasta la capa de red o IP.

Para ello, la aproximación que se empleó inicialmente (y aún válida parcialmente) fué que el emisor asumiera que la red está saturada cuando el temporizador de retransmisiones expire y llegado ese caso reaccionar ajustando la cwnd empleando tres algoritmos denominados: slow-start, congestion avoidance y multiplicative decrease.

Desenlace: cómo se implementó

A continuación describiré someramente la implementación original de los algoritmos encargados del control de la congestión siendo los dsos últimos conocidos también como algoritmo AIDM por sus siglas additive increase, multiplicative decrease.

Slow-start

• cwnd(t+1)= 1\times SMSS
• SMSS es Sender Maximum Segment Size (en Ethernet suele tomar el valor de 1460 bytes).
• Cuando se recibe un ACK, cwnd(t+1)= cwnd(t)+SMSS

Congestion Avoidance

• Este fuerza un incremento lineal del cwnd cuando se alcanza un umbral denominado ssthresh (slow start threshold)
• ssthresh es dinámico y controlado por el multiplicative decrease
• Ahora cwnd(t+1)= cwnd(t) + \frac{SMSS}{cwnd(t)}

Multiplicative Decrease

• Cada vez que se vence un temporizador, ssthresh y cwnd se modifican
• ssthresh= max(2, \frac{cwnd(t)}{2})
• cwnd(t+1)= 1\times SMSS

Unas últimas palabras

De la forma más simple y clara que supe, he querido mostrar qué es y en qué se sustenta el control de la congestión de TCP en su implementación primigenia (acuñada como Tahoe). Este algoritmo ha sido evolucionado y mejorado añadiendo nuevas características que permite mejorar su rendimiento en muchos aspectos. No obstante para cualquiera que pretenda introducirse en este mundo, estos conceptos son esenciales.