INTERCONEXIÓN DE REDES

CAPÍTULO 9
CONTROL DE LA CONGESTIÓN

Dr. Félix Alvarez Paliza

Dpto. Telecomunicaciones
UCLV
 223

Congestión en Redes
La tendencia actual es hacia redes de alta velocidades y su interconexión a fin de soportar nuevas y
variadas aplicaciones que incrementan el tráfico en las mismas, producto del incremento de los
sistemas finales o usuarios finales que solicitan dichas aplicaciones.
Sin embargo la interacción entre los protocolos en esos sistemas finales y los mecanismos de
administración del tráfico en las redes y los Routers puede dar con una sub-utilización de esas redes
heterogéneas.
Si se analiza qué ocurre cuando un Router no tiene suficiente capacidad para reenviar todo el tráfico,
veremos que si se transmite a alta velocidad algunos paquetes se perderán y el nivel de transporte los
retransmitirá lo que generará más tráfico y más probabilidad de que se pierdan.

Fig.9.1 Congestión en redes

Luego el problema es cuando la red está saturada por alta carga proveniente de muchas fuentes se
pierden paquetes, se cursa menos tráfico útil y aumenta el retardo de los paquetes que llegan
a su destino.
La Congestión ocurre cuando el número de paquetes transmitidos hacia la red por las fuentes
se aproxima o sobrepasa a la capacidad de la Red.

En este material se abordará un problema que se expande a todos los protocolos y que es como
asignar los recursos de forma efectiva y justa entre los usuarios que están compitiendo por los recursos
en esas redes. En especial el ancho de banda de los enlaces y los almacenes (Buffers) de los Routers
y Switch donde los paquetes esperan en las colas para su retransmisión.
La contienda de los paquetes en un Enrutador para utilizar un mismo enlace pueden provocar un
desborde y por tanto que algunos paquetes sean descartados. Luego ello provoca un desempeño
deficiente de la red y se dice que la misma está congestionada, tal como se muestra en la Figura.9.2.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 224

Fig.9.2 Congestión en las Redes

La asignación de recursos y el control de la congestión son dos caras de una misma moneda, ambos
son complejos y continúan aún siendo temas de investigación y continuo perfeccionamiento.
Lo mas complejo de ello es que no son entes aisladas en un nivel de la jerarquía de protocolos, sino
que están interrelacionadas en todos los niveles.

A fin de dar claridad acerca de estos dos conceptos es necesario dar una definición de los mismos:
Asignación de recursos: Es el proceso mediante el cuál los elementos de red tratan de encontrar
solución a las demandas de las aplicaciones que compiten por los recursos de la red, principalmente
ancho de banda de los enlaces y espacio en los almacenes (Buffers) de los Routers y Switch.

Control de la congestión: Es el proceso que describe los esfuerzos realizados por los nodos de la red
para evitar o responder a condiciones de sobrecarga. Muchos mecanismos de control de la congestión
tienen idea de la asignación de recursos de forma justa, tratando de compartir los efectos de la
congestión entre todos.

Por lo que es necesario disponer de redes que tengan un alto desempeño o rendimiento
(performance), para prever el tráfico futuro en cuanto a volumen y características del mismo.
Entre los parámetros de mayor importancia que caracterizan el tráfico de datos están:
- la razón de transferencia (throughput) o cantidad de datos que pueden ser transferidos
exitosamente a través de un canal en un período de tiempo
- el retardo o retraso (delay) que sufren los datos.

Para entender las características del tráfico de datos y los parámetros que los describen observe la
Figura 9.3. Donde hay tres situaciones diferentes de transferencia de datos.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 225

Fig.9.3 Transferencia de datos a diferentes razones

Lo que indica que para caracterizar la razón de transferencia (throughput) es necesario referirse a
ella como:
- Razón Promedio (Average rate): La razón promedio expresa el flujo que puede ser sostenido
por la fuente durante un período de tiempo. La carga media suministrada por una fuente es
importante para poder determinar la cantidad de recursos a destinar a esa fuente.
- Razón Máxima ( Peak Rate): Este parámetro le dice a la red que tipo de tráfico imprevisto tiene
que enfrentar, mediante una capacidad de razón de datos de reserva o mediante almacenes
de reserva atenúen ese pico.
- Variabilidad: La razón máxima es una medida de la variabilidad, pero una medición mas directa
es la variación de la razón de transferencia.

En cuanto a las características del Retado están:

- Retardo de Transferencia: El cuál mide el retardo impuesto por la red a la transferencia de

datos desde una fuente hasta un destino. El retardo de transferencia máximo puede ser uno de
los requisitos expresado por una aplicación.
- Variaciones del Retardo: El retardo impuesto por la red a una transferencia de datos no es la
misma para cada uno de ellos, por lo que hay variaciones. De ahí que muchas aplicaciones de
tiempo real tengan requisitos en cuanto a la cantidad de variación de ese retardo.

Para entender el fenómeno de la congestión en las redes es necesario tener presente los parámetros
anteriormente enunciados.

Efectos de la Congestión
En general la congestión ocurre cuando un número de paquetes, tramas, celdas o segmentos que
están siendo transmitidos a través de una red comienza aproximarse a la capacidad de manipulación
de la red.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 226

Dicho en otras palabras, el control de la congestión estriba en mantener el número de paquetes dentro
de la red por debajo del nivel en que el desempeño de la red cae dramáticamente.

Para entender los aspectos relacionados con el control de la congestión debemos tener presente que
las redes de conmutación de paquetes son redes de colas, pues en cada nodo de la red va a estar
presente una cola de paquetes esperando alcanzar el canal de salida.

Si la razón a la cuál los paquetes arriban y hacen la cola es mayor que la razón a la que los paquetes
son transmitidos, entonces el tamaño de la cola crecerá sin límite y el retardo experimentado por un
paquete tenderá hacia infinito.
Aún cuando la razón de arribo de los paquetes sea menor que la razón de transmisión, en la medida
que esta se acerque a la misma la cola crecerá dramáticamente.

Considere la situación de las colas en un Nodo, el cuál puede ser un Switch o un Router, tal como se
muestra en la Figura 9.4.

Cualquier nodo tiene un número de puertos de Entrada/Salida conectados a él: uno o más conectados
a otros nodos y cero o más conectados a usuarios o sistemas finales. A cada enlace arriban y parten
paquetes, por lo que es necesario considerar almacenes (buffers) en cada enlace, unos aceptando
paquetes que arriban y otros para paquetes que están esperando para partir. En la práctica podrán
ser dos almacenes de tamaño fijo asociados a cada enlace o podrá ser un conjunto (pool) de memorias
disponibles para todas las actividades. En este último caso se requerirían dos variables asociadas al
tamaño del almacén.

En cualquier caso el nodo examina el paquete que llega y ejecuta una decisión de encaminamiento
(ruta), por lo que mueve paquete hacia el almacén de salida apropiado. Si la razón de arribo de
paquetes es mayor que la de decisión o la de salida de paquetes, ello provocará que no se tenga
memoria disponible y se alcance el punto de saturación.

Fig. 9.4 Colas de E/S en un Switch o Router

Ante esta situación es necesario aplicar una de las dos estrategias generales siguientes:
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 227

- Descartar cualquier paquete para la cual no hay espacio disponible en el buffer. Pero la misma
es auto-destructiva, ya que paquetes descartados tendrán que ser de nuevo trasmitidos y
añadirán mayor congestión a la red.

- Restringir la razón a la cual nuevas paquetes son incorporados a la red. Lo que conllevará a
que cada nodo que experimente saturación en las colas tenga que ejercer de alguna forma un
control de flujo sobre sus vecinos, a fin de que el flujo de paquetes permanezca manejable.

Tal como se muestra en la Figura 9.5 en cada nodo vecino se está también administrando un número
de colas. Si el nodo 6 restringe el flujo de paquetes desde el nodo 5, ello provocará que se llene el
buffer de salida del nodo 5 hacia el nodo 6. La congestión en un punto de la red puede fácilmente
propagarse a una región o a toda la red.

Lo anterior conduce a un requerimiento de emplear una estrategia que controle el flujo de paquetes
dentro de la red, tanto global como regional, refiriéndose a esta acción como control de la
congestión.

Fig. 9.5 Interacción de Colas

Desempeño o Rendimiento de una Red

A continuación se realizará un análisis comparativo del desempeño ideal y del real en una red y su
relación con la congestión.
Tal como se había expresado con anterioridad los parámetros que permiten describir el desempeño
de una red son la razón de transferencia y el retardo.

En la Figura 9.6 se muestra el comportamiento ideal de una red, sin los efectos de la congestión en
términos generales, específicamente en el inciso a) se representa la razón de transferencia exitosa de
de datos en una red (throughput) contra la carga ofrecida (el número de paquetes trasmitidos por todos
los sistemas finales hacia la red).

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 228

Mientras que en el inciso b) se representa el retardo promedio contra la carga. Este retardo promedio
es el tiempo promedio desde la entrada de un paquete hasta su salida de la red.

Fig.9.6 Desempeño ideal de una Red

Para entender la figura anterior considere el ejemplo de una red un simple nodo con dos enlaces a 1
Mbps, por lo que la capacidad teórica de la red será de 2 Mbps, con un flujo de 1 Mbps en cada
dirección.
En el caso ideal la razón de transferencia (throughput) se incrementa para acomodar el incremento de
la carga hasta que la carga ofrecida es igual a la capacidad total de la red. Por lo que la razón de
transferencia normalizada permanecerá en 1.0 a cargas superiores.

Note sin embargo que sucede con el retardo de extremo a extremo experimentado por los paquetes
aún considerando un comportamiento ideal.
A medida que la carga en la red se incrementa, los retardos en las colas en cada nodo son añadidos
a los retardos fijos de transmisión. De ahí que cuando la carga excede la capacidad de la red el retardo
se hace infinito.

Es importante resaltar que en ocasiones también se hace referencia al parámetro potencia, para
describir el comportamiento de una red, y este no es más que la relación entre la razón de
transferencia y el retardo.

En la realidad, el desempeño de una red real tiene que tomar en consideración el tamaño finito de los
buffers de almacenamiento en los nodos.
Luego en la Figura 9.7 se puede apreciar que para cargas ligeras la razón de transferencia y la
utilización de la red se incrementan hasta el punto A.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 229

Detrás de este punto A ya la razón de transferencia se incrementa de forma mas lenta ante
incrementos de la carga. Esto es debido a que la red entra en un estado de congestión moderado.
El desvío del comportamiento ideal estriba en una diversidad de factores, como son que no es uniforme
la situación en cada nodo, pues a medida que la carga se incrementa la red tiende a balancear el
enrutamiento de paquetes hacia otras áreas de mas baja congestión, se incrementará el número de
mensajes de enrutamiento entre los nodos, etc.
Cuando los almacenes de un nodo se llenan, obliga a que este tenga que descartar paquetes y ello
provoca la retrasmisión y por tanto la exacerbación de la situación aspecto este que tiene que ser
evitado.
Luego el objetivo de las técnicas de control de la congestión es el de limitar la longitud de las colas en
los nodos y por tanto evitar que colapse la eficiencia de la red. Ese es el punto B, donde la razón de
transferencia cae drásticamente ante el incremento de la carga.

Fig. 9.7 Efectos de la Congestión.

Mecanismos para el control de la Congestión

Se han desarrollado diferentes técnicas para el control de la congestión y en este material se
describirán algunas de ellas, las cuáles son resumidas en la Fig.9.8 para una mejor comprensión.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 230

Fig.9.8 Mecanismos para el control de la congestión

Los mecanismos para el control de la congestión los podemos dividir en dos grandes grupos:
 Los asistidos por la red, donde los Enrutadores informan de la congestión a los extremos de
la comunicación, modificando un bit para indicar congestión caso de las redes:SNA, DECnet,
TCP/IP ECN (RFC2481), ATM, etc. O sino indicando la tasa máxima a la que puede enviar,
como en ATM ABR.
 Control de la congestión de extremo a extremo, caso de TCP.

Asistidos por la red

Presión hacia atrás
Esta técnica puede ser aplicada tanto a enlaces como a conexiones lógicas y sencillamente se basa
en que un nodo puede hacer más lenta o detener la salida del flujo de paquetes provenientes de otro
nodo, lo que hace que el nodo que le suministra o envía los paquetes también restringa los flujos que
le suministran a el .Este es el caso visto de la Figura 9.5, donde el nodo 6 puede detener o hacer mas
lento el flujo de paquetes provenientes del nodo 5 y a su vez el nodo 5 hacerlo del nodo 3 y así ir
transmitiendo la presión hacia atrás. Algunas redes tienen esta posibilidad y otras no, como es el caso
de las Redes IP, las cuáles no habían sido construidas para regular el flujo de datos de un Enrutador
al próximo a lo largo de una trayectoria.
Paquetes de Prevención
Un paquete de prevención es un paquete de control generado en un nodo congestionado y transmitido
hacía atrás, o sea hacía el nodo fuente para restringir el flujo de datos. Un ejemplo típico son los
paquetes del protocolo ICMP del tipo Source Quench, que pueden ser enviados por un Enrutador o un
sistema final hacia una fuente solicitándole esa situación. También este tipo de paquetes pueden ser
enviados cuando un Enrutador o un sistema final descartan los paquetes.
O sea que esta técnica de paquetes de prevención es una técnica relativamente cruda para evitar la
congestión.

Señalización Implícita de la Congestión.

Si la fuente es capaz de detectar el incremento de los retardos y de los paquetes descartados,
entonces esta tiene evidencia implícita de que hay congestión en la red. Si todas las fuentes son
capaces de detectar la congestión y reducen el flujo sobre esta base, entonces la congestión en la red
será aliviada poco a poco.
La señalización implícita es un técnica de control de la congestión en configuraciones sin conexión o
de tipo datagramas, tal como en las redes IP. Internamente en la red no hay conexiones lógicas, pero
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 231

si entre los sistemas finales se establecen conexiones lógicas a nivel de transporte, tal como lo hace
el protocolo TCP. Mas adelante se podrá apreciar como es que TCP incluye técnicas de control de la
congestión basadas en la habilidad de de detectar el incremento de los retardos y la pérdida de
segmentos.

Señalización Explícita de la Congestión

De esta forma la red alerta a los sistemas finales de que está creciendo la congestión dentro de la red
y los sistemas finales reducen la carga ofrecida a la misma. Típicamente esta técnica opera sobre
redes orientadas a la conexión y el control del flujo de paquetes es sobre conexiones individuales.

La técnica de señalización explícita trabaja en dos direcciones:

- Hacia atrás (Backward), donde se le notifica a la fuente que deben ser iniciados
procedimientos para evitar la congestión. Generalmente esto se realiza mediante Bits que se
cambian en los encabezados de los paquetes que le llegan a la fuente o paquetes de control.

- Hacia delante (Forward), donde el usuario notifica que se deben iniciar proceso de evitar la
congestión en la misma dirección en que se recibe el paquete. De la misma forma que indicamos
en el caso anterior, mediante Bits o Paquetes. Generalmente cuando una señal de este tipo es
recibida por un sistemas final, este hace eco hacia atrás después o lo informa a los niveles
superiores.

La señalización explícita se divide en tres categorías generales:

- Binaria, donde un Bit en el encabezado de un paquete es establecido como bandera.

- Basada en créditos, donde una fuente va a recibir una información de cuantos octetos o
paquetes de datos puede transmitir. Cuando el crédito se agota o cierra, la fuente tiene que
esperar a que aparezcan créditos adicionales para poder transmitir. Esta es la técnica de control
de flujo empleada por TCP, la cuál es también una técnica rudimentaria de control de la
congestión.

- Basada en tasas, donde se ofrece una razón de datos límite de forma explícita a la que la
fuente puede trabajar en una conexión lógica. O sea que la fuente no puede sobrepasar esa
razón acordada o comprometida.

Hay un conjunto de temas relacionados con el control de la congestión que podrían estar incluidos
bajo la categoría general de administración del tráfico. En su forma mas simple el control de la
congestión está relacionado con el uso eficiente de una red con carga alta. Los mecanismos analizados
con anterioridad pueden ser aplicados a medida que surgen las situaciones.

En la redes de conmutación de paquetes hay un número de mecanismos de control de la congestión

que han sido ensayados, como por ejemplo:
a) Enviar paquetes de control desde un nodo congestionado a algún otro o a todos los nodos
fuentes. Este paquete de prevención tendrá un efecto de detener o reducir la razón de
transmisión de las fuentes.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 232

b) Retransmisión de información de Rutas. Los algoritmos de enrutamiento ofrecen información

de los enlaces con retardos, lo cuál influye en las decisiones de las rutas y también influye en
la razón a la cuál los paquetes son enviados.
c) Hacer uso de paquetes de prueba de extremo a extremo, los que llevan marcas de tiempo y
permiten medir los retardos. Lo que tiene el inconveniente de añadir mas carga a la red.
d) Permitir nodos de conmutación de paquetes que le añadan información de la congestión a los
paquetes, principalmente a los que van en dirección contraria a la congestión.

Control de la Congestión de extremo a extremo en TCP

El control de la congestión en una Red IP, basada en el conjunto de protocolos TCP/IP es complejo y
difícil de abordar, lo que ha requerido numerosas investigaciones, experimentos y artículos durantes
décadas. La tarea ha sido difícil debido a los factores siguientes:

1. El protocolo IP es sin conexión y no ofrece formas para detectar y menos para controlar la
congestión.

2. TCP ofrece solamente control de flujo de extremo a extremo y solo puede deducir la presencia
de congestión dentro de la red por métodos indirectos.

3. No existencia de algoritmos distribuidos de cooperación entre entidades TCP.

La única herramienta en TCP antes de 1988, que se relacionaba con la congestión de la red eran los
mecanismos de control de flujo de ventanas deslizantes y los de control de error.
Por lo que es necesario primero profundizar en los mecanismos de control de flujo de TCP, partiendo
de la premisa de que la razón a la cuál una entidad TCP puede enviar datos está determinada por la
razón de la llegada de reconocimientos ACK de los segmentos previos con nuevos créditos. Sin
embargo en el caso de TCP la razón de arribo de los reconocimientos ACK están determinados por el
cuello de botella en la trayectoria de ida y vuelta entre fuente y destino o por el cuello de botella que
exista en el destino

En la Figura 9.9 se muestra un esquema que ilustra la situación del cuello de botella en Internet, siendo
esto una abstracción donde se considera una tubería con conductos anchos y estrechos
proporcionales a la razón de datos. Puede observarse como la fuente y el destino son redes de alta
capacidad y la porción central estrecha representa los enlaces de baja velocidad. Existiendo un
espacio de tiempo entre los segmentos.
En el estado estable después de un despliegue violento la razón de arribo de los segmentos se alcanza
una correspondencia entre la razón de emisión de segmentos y la razón de arribos de reconocimientos.
TCP detecta automáticamente el cuello de botella en la red y regula el flujo acorde al mismo, siendo
esto referido como el comportamiento de auto-reloj de TCP.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 233

Fig.9.9 Flujo determinado por la congestión en la red

De forma análoga este mecanismo funciona también si el cuello de botella es en el receptor, tal como
lo muestra la Figura 9.10, donde el conducto ahora es mas estrecho.

Fig.9.10 Flujo determinado por congestión en el destino.

El embotellamiento a lo largo de una trayectoria de ida y vuelta puede ocurrir en una variedad de
lugares y que tampoco la fuente tiene forma de identificar si la situación es provocada por congestión
en la interconexión o por control de flujo en el destino.
Lo anterior nos indica que aunque el mecanismo de ventanas deslizantes de TCP está diseñado para
el control de flujo de extremo a extremo, este fue utilizado para el control de la congestión.
TCP en sus orígenes utilizaba la técnica Go-back-N ARQ, detectaba las pérdidas a partir de los
eventos de tiempo de espera (timeout), retransmitía los paquetes perdidos.
Sin embargo en Octubre de 1986, Internet tuvo su primer colapso de congestión
Dado por las estaciones que enviaban sus paquetes hacia Internet tan rápido como la ventana de
anuncio W lo permitía. Por lo que la congestión ocurriría en algún Router (provocando el descarte de
paquetes) y las estaciones retransmitiendo de nuevo mas paquetes, resultando en un incremento de
la congestión.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 234

Desde la publicación de la RFC 793 un número apreciable de técnicas han sido introducidas para
mejorar las características de TCP en cuanto a control de la congestión.

El control de la congestión con TCP fue introducido en 1988 por Van Jacobson
aproximadamente ocho años después que el protocolo TCP/IP era funcional.

Se utiliza una nueva variable de estado llamada Ventana de Congestión (CongWin) , la cuál es
utilizada por la fuente para limitar la cantidad de datos que se pueden enviar a la red dependiendo de
la percepción que tiene TCP de la congestión

La idea de controlar la congestión en el emisor de TCP es para que cada fuente determine la capacidad
disponible en la red, tal que esta conozca la cantidad de paquetes que puede tener en tránsito de
forma segura.

Por lo que se introdujeron cambios en TCP para poder controlar la congestión tales como:
 El máximo número de Bytes de datos no reconocidos permitidos ahora es el mínimo entre la
ventana de anuncio W (del receptor) y de la nueva ventana de congestión CongWin (del
emisor).

MaxWin= Min (CongWin, W)

 Determinándose una ventana efectiva EffWin como la resta entre

EffWin= MaxWin- (LBSent-LBAck)

Una vez que una fuente tiene una cantidad de paquetes en tránsito, la misma utiliza los arribos de los
reconocimientos (ACK) como señal de que sus paquetes han dejado la red y que por lo tanto es seguro
insertar un nuevo paquete en la red sin que se incremente el nivel de congestión.
La utilización de los reconocimientos (ACK) para establecer el ritmo de transmisión de los paquetes es
lo que permite decir que TCP es auto-sincronizado.
La ventana de congestión se reduce ante la congestión limitando la tasa a
V = CongWin/ RTT
Determinar la capacidad disponible no es tarea fácil, el asunto se hace mas engorroso debido a que
otras conexiones se establecen y terminan, por lo que el ancho de banda disponible cambia con el
tiempo. Lo que significa que una determinada fuente tiene que ser capaz de ajustar el número de
paquetes en tránsito.
Por lo que es necesario profundizar en los diferentes algoritmos utilizados por TCP para poder percibir
la congestión mediante la pérdida de paquetes, lo que es detectado mediante dos formas principales:
Pérdida de paquetes => Congestión
A ) Ocurrencia de un Evento de TIEMPO DE ESPERA (timeout)
-B) Recepción de 3 reconocimientos (ACKs) duplicados .

Lo que debe llevar a los ajustes de la ventana de congestión por diferentes mecanismos o algoritmos:
 Mecanismo AIMD (Additive Increase/ Multiplicative Decrease), conocido como de
evitar la congestión.
 Mecanismo de arranque lento (Slow start)
 Mecanismo de retransmisión rápida y de recuperación rápida (Fast Retransmit y
Fast recovery)
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 235

Es importante señalar como es que TCP asigna o aprende un valor apropiado para la variable
CongWin:
 Aunque CongWin es definida en términos de Bytes, con la misma se va a trabajar en
términos de paquetes enteros.
 CongWin no va a ser permitida que caiga por debajo de un simple paquete que tiene un
MSS (MSS: maximun segment size).

Con los elementos anteriormente expuestos se analizarán a continuación algunos de los algoritmos o
mecanismos desarrollados para TCP en función de controlar la congestión:

INCERMENTO ADITIVO / DECREMENTO MULTIPLICATIVO (AIMD)

Cada vez que TCP detecta un evento de tiempo de espera lo interpreta como una pérdida de paquete
debido a la congestión. Por lo que reduce la razón a la cuál está transmitiendo y fija la CongWin a la
mitad de su valor previo.
Siendo esto un Decremento multiplicativo del mecanismo AIMD.
Si la ventana de congestión tiene un valor de N MSS, en función de evitar la congestión se abre 1 MSS
cada vez que el emisor envía con éxito toda la ventana. La ventana se incrementa linealmente,
buscando encontrar el punto de equilibrio sin aumentar demasiado la congestión, tal como se muestra
en la Fig.9.11.

Fig.9.11 Incremento aditivo de AIMD

A continuación en la Fig.9.12 se puede apreciar como varía la ventana de congestión con incrementos
aditivos (lineales) y decrementos multiplicativos ante percepción de congestión. Este mecanismo actúa
como una forma de evitar la congestión.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 236

Fig. 9.12. Variación de CongWin mediante AIMD.

ARRANQUE LENTO (SLOW START)

Crecer linealmente la ventana de congestión es demasiado precavido, no se tienen suficientes motivos
para pensar que hay congestión. Por lo que se utiliza un enfoque más agresivo, con el crecimiento
exponencial de CongWin.
De ahí que el mecanismo de arranque lento (Slow Start) sea exponencial y cada vez que el emisor
transmite una ventana con éxito la ventana se duplica, tal como se muestra en la Fig.9.13.

Fig. 9.13 Mecanismo de arranque lento

Es importante que este mecanismo se considere de arranque lento con respecto al mecanismo de
arranque existente antes de 1988 basado en W, con un valor de ventana muy grande.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 237

En la Fig.9.14 puede apreciarse como el arranque lento es de forma escalonada pero de siguiendo
una exponencial creciente.

Fig. 9.14 Mecanismo de arranque lento

Luego es necesario analizar cuando es que el mecanismo de arranque lento funciona:

 Al comienzo de cada conexión TCP
 Cuando una conexión espera que un evento de timeout ocurra.

El mismo es utilizado para rápidamente incrementar la razón de envío hasta un valor umbral fijado
para la CongWin que se llamará ssthresh (Slow Start Treshold) y a partir de ahí funcione el
incremento aditivo y entrar en la fase de evitar la congestión.
O sea que el proceso de evitar la congestión arranca cuando CongWin  ssthresh, teniendo que en
cada reconocimiento exitoso (ACK) se incrementa linealmente la ventana de congestión :

CongWin  CongWin + 1/ CongWin

O lo que es lo mismo un crecimiento Lineal con cada tiempo de ida y vuelta RTT:
CongWin  CongWin + 1

El valor umbral que adoptará la variable ssthresh será dado por:

 El valor que se almacenó que tenía la CongWin cuando se dejaron de recibir ACK y se produjo
un decremento multiplicativo (CongWin/2).

Lo anterior puede ser observado en la Fig.9.15, donde inicialmente se aprecia un arranque lento y ante
la ocurrencia de un timeout, cae la ventana de congestión, pero el valor de ssthresh se reduce a la
mitad, arrancando de nuevo de forma lenta hasta dicho umbral en que a partir de ahí se incrementa
linealmente la ventana de congestión (fase de evitar la congestión).

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 238

Fig. 9.15 Comportamiento de la ventana de congestión.

En la Fig. 9.16 puede ser apreciado con más detalles el proceso de arranque lento combinado con
AIMD, con el valor umbral.

Fig. 9.16 Establecimiento del valor umbral ssthresh.

RETRANSMISIÓN RÁPIDA
La retransmisión rápida toma ventaja de una regla de TCP, que dice que si una entidad recibe un
segmento fuera de orden este tiene que inmediatamente emitir un reconocimiento donde se reconozca
el último segmento en orden recibido.
Por lo que TCP continuará emitiendo este reconocimiento hasta que el segmento arribe a su hueco en
el buffer. A partir de esto, entonces TCP envía un reconocimiento donde incluye todos los segmentos
recibidos anteriormente en orden.
Luego cuando una fuente TCP recibe un reconocimiento duplicado, esto puede significar:
1) el segmento que le sigue al segmento reconocido está retrasado y que arribo fuera de orden.
2) el segmento está desaparecido

Luego en el primer caso 1 el segmento arriba y no debe ser retransmitido, pero en el caso 2 el arribo
de un reconocimiento duplicado puede funcionar como una advertencia a la fuente TCP de que se ha
perdido un segmento y que debe retransmitirlo.
Luego para estar seguro de esta situación Jacobson recomendó que una entidad TCP emisora tiene
que esperar hasta que reciba tres duplicados de reconocimiento del mismo segmento (en total 4 ACK).
De ahí que bajo esas circunstancias es mejor indicador de que hay que retransmitir el siguiente
segmento y no esperar por un tiempo de espera.
Por lo que se desarrolló un mecanismo en el que TCP esperaría hasta que se recibieran tres ACK
duplicados para volver a transmitir un paquete, tal como se muestra en la Fig.9.19.
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 239

Fig. 9.17 Situación de reconocimientos duplicados (3 ACK).

Se puede observar como el paquete 3 es retransmitido al recibir 3 reconocimientos duplicados, no
esperando por la ocurrencia del tiempo de espera y como se emite el reconocimiento acumulativo
ACK6. Lo anterior mejora la eficiencia de la transmisión de paquetes.
Los mecanismos anteriores fueron introducidos en la implementación de TCP denominada TCP
Tahoe, desarrollado por Jacobson en 1988. En la gráfica de la figura 9.18 se pueden observar la
combinación de los tres mecanismos.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 240

Fig.9.18 Mecanismos implementados por TCP Tahoe.

Recuperación rápida
Cuando una entidad TCP retransmite un segmento utilizando este mecanismo de retransmisión rápida,
es porque considera que ese segmento está perdido, aún cuando no se ha alcanzado el tiempo de
espera del mismo. Por lo que la entidad TCP debe tomar medidas con vistas a evitar la congestión.
Una estrategia es la de combinar el arranque lento combinado con el procedimiento de evitar la
congestión utilizado cuando un tiempo de espera se alcanza.
Jacobson plantea que eso es muy conservador y que en la realidad hay múltiples reconocimientos
ACK en la realidad, de ahí que propone una técnica de recuperación rápida en sustitución del arranque
lento exponencial.
La misma es establecida a continuación:
1. Cuando un tercer duplicado de ACK llega, entonces se fija
ssthresh= CongWin/2, se retransmite el segmento y se fija
CongWin = ssthresh +3

La razón de porque 3 estriba en que esta es la cuenta del número de segmentos que han dejado
la red y que la otra entidad los ha recibido.

2. Cada vez que un duplicado adicional de ACK (para el mismo segmento) arriba, entonces se
incrementa CongWin en 1 y transmite un segmento si es posible. Esta cuenta para el segmento
adicional que ha dejado la red y que ha disparado el duplicado ACK.
3. Cuando el reconocimiento llega reconociendo que arriba y sea un reconocimiento acumulativo
del segmento perdido mas los siguientes, se fija entonces CongWin = ssthresh

Un ejemplo se muestra en la Figura 9.18, donde hay dos gráficos, en el superior el eje Y representa
número de segmentos.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 241

Fig.9.18 Ejemplo de Recuperación rápida

En el gráfico cada rombo representa un segmento transmitido en un instante de tiempo con la altura
proporcional al tamaño del segmento. Estos segmentos son limitados por dos líneas. La línea inferior
indica el número de secuencia reconocido y la línea superior representa el número de secuencia mas
la ventana enviada. La figura inferior indica el valor de CWDN en ese instante de tiempo.
En la primera parte del gráfico se muestra como un flujo estable es mantenido con un tamaño de
ventana estable, permaneciendo durante este tiempo cwdn a su máximo valor. Justamente antes del
instante 5.43 se reciben reconocimientos duplicados para el segmento 579. Cuando el tercer ACK
duplicado llega, entonces el segmento 580 es retransmitido y CWDN es reducido a la mitad mas 3
segmentos. Entrándose en la región en que la fuente puede transmitir un segmento cada vez que se
recibe un reconocimiento duplicado. Finalmente justo antes del instante 5.6 segundos, un
reconocimiento ACK de segmentos acumulados se recibe, lo que hace que el mismo llegue en un
tiempo RTT a partir de la retransmisión del segmento 580. Este reconocimiento hace que csdn se
repliegue a un valor ssthresh y el emisor pase al modo de reposo para evitar la congestión.
En la implementación de TCP Reno (1990) se mezclan los mecanismos anteriores y se puede apreciar
como mejora su eficiencia en la figura 9.19 con respecto al Tahoe.

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 242

Fig.9.19 Mecanismos implementados por TCP Reno

Los mecanismos anteriores están definidos en la RFC 2581 para el control de la congestión basadas
en la administración de la ventana de congestión.

Transmisión limitada.
La RFC 3042 define un mecanismo para transmitir nuevos segmentos, aún cuando este no es dictado
por condiciones de congestión. Especialmente el algoritmo de transmisión limitada llama al emisor
TCP a transmitir un nuevo segmento cuando son halladas las condiciones siguientes:
1- Dos reconocimientos ACK duplicados son recibidos (un total de tres ACK).
2- La entidad TCP de destino anuncia la ventana que permite la transmisión del segmento. Ya
que suficiente créditos permanecen disponibles para que la fuente TCP sea capaz de enviar
un segmento.
3- La cantidad de datos atrasados, después de enviar el nuevo segmento, debe ser menor o
igual que cwdn +2. Esto es, el emisor solo puede enviar dos segmentos por encima de la
ventana de congestión.

Este mecanismo permite una modesta transmisión de datos por encima de lo que normalmente se
permitiría por los mecanismos de control de la congestión.

Luego a modo de resumen, podemos enunciar diferentes mecanismos de control de la congestión

implementados por TCP:
 Tahoe (Jacobson 1988)
 Slow Start
 Congestion Avoidance
 Fast Retransmit
 Reno (Jacobson 1990)
 Fast Recovery
 Vegas (Brakmo & Peterson 1994)
Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV
 243

 New Congestion Avoidance

 Friendly

 Selective ACK (SACK)

 TCP Friendly Rate Control (Floyd, Handley, Padhye y Widmer, 2000)

o TFRC, se define en la RFC 5348 declara obsolete la RFC 3448

Mediante técnicas de manejo activo de colas (AQM) se tienen entre otros:

 RED (Floyd & Jacobson 1993)
 Probabilistic marking
 REM (Athuraliya & Low 2000)
 Clear buffer, match rate

Tabla de Algoritmos implementados según Sistema Operativo

Win 98 Win 2000 Win Xp Sol 2.9 HP-UX 10.x/11.x

Slow-Start 1 2 1 4 1
cuenta inicial (MSS)
Fast Retransmit Habilitado Habilitado Habilitado Habilitado Habilitado
Fast Recovery Reno Reno Reno Reno Reno
Selective ACK (SACK) Habilitado Habilitado Habilitado Habilitado No habilitado

Notas del Profesor Titular, Dr. C. Ing. Félix F. Alvarez Paliza, Dpto. Telecomunicaciones, UCLV