Primera parte del tercer tema de la asignatura Sistemas de Conmutación de 4º curso de Ingeniería de Telecomunicación (Vigo), donde se trata el control de congestión en redes de conmutación de paquetes.

1. Introducción
Congestión: Exceso de demanda de algún recurso (ancho de banda, memoria, capacidad de
procesamiento...) que da lugar a una pérdida de prestaciones de la red.
Síntomas: Aumentan los retardos y las pérdidas.
Una propiedad típica de la congestión es la realimentación, que hace que la situación empeore con el
paso del tiempo, pues un nodo congestionado provocará con el tiempo la saturación de los que envían
tráfico hacia él. La consecuencia final de la congestión, si ésta no es resuelta, es que la red entra en una
situación de colapso: bajada de varios ordenes de magnitud del caudal de información útil.
Ideal
Capacidad máxima
de la subred
Tráfico entregado
Asintótico
Real
Zona de Zona de Colapso o Deadlock
riesgo congestión
Zona de trabajo
Tráfico ofrecido
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.1

2. Consecuencias de la congestión
Retardos Trabajar cerca de la capacidad de los enlaces es ideal
desde el punto de vista de la productividad, pero no lo es
respecto al retardo.
´
Perdidas Se producen debido a la finitud de los búferes, con lo que el
emisor puede que realice retransmisiones: posible realimentación
positiva.
Desperdicio de recursos
Ante grandes retardos vencen temporizadores en el emisor
antes de llegar los asentimientos, con lo que se retransmiten
paquetes innecesariamente.
Inherente en conmutación de paquetes: un paquete
desechado en un punto ha consumido recursos de manera
inútil en enlaces y nodos anteriores.
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.2

3. Dinámica del control de la congestión
Mecanismos según momento de actuación:
Intentan prevenir la congestión.
Preventivos o de lazo abierto
Control de admision Se limita el número de usuarios o flujos.
´
Monitotizacion Se vigila que un flujo no exceda su cuota de tráfico.
´
Regulacion de trafico Se modifica el patrón de tráfico a la entrada
´ ´
de forma que sea más predicible.
Ejemplo: Servicio CBR (Constant Bit Rate) en ATM.
Reactivos o de lazo cerrado Intentan resolverla cuando aparece.
Realimentacion expl´cita Los nodos de conmutación avisan a los
´ ı
extremos cuando están congestionados o en peligro de
congestión (envían paquetes especiales o marcan los
paquetes de datos si no los van a descartar). Ejemplo: Explicit
Congestion Notification en TCP/IP.
Realimentacion impl´cita Los extremos infieren la presencia de
´ ı
congestión en la red basándose en las pérdidas o en los
retardos. Ejemplo: Control de congestión en TCP.
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.3

4. Control de flujo en TCP
Emisor Receptor
TCP TCP
LastByteWritten LastByteRead
LastByteAcked LastByteRcv
LastByteSent NextByteExpected
El receptor informa al emisor de cuantos octetos, RcvWindow (16 bits),
está preparado a recibir más allá del octeto asentido:
RcvWindow = RcvBuffer − (NextByteExpected − LastByteRead),
con RcvBuffer el tamaño de búfer del receptor; el emisor garantizará:
LastByteSent − LastByteAcked ≤ RcvWindow
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.4

5. Control de congestión en Internet: TCP
Bloqueo por congestión observada por primera vez en Octubre de
1986: NSFnet phase-I backbone pasó de 32 kb/s a 40 b/s; ante
pérdida de paquetes y vencimiento de temporización TCP reenviaba
a máxima velocidad.
En 1988 Van Jacobson introduce el control de congestión,
incorporándose en la versión para BSD Tahoe de TCP: cada fuente
ha de determinar de cuánta capacidad dispone en la red, limitando el
número de paquetes a transmitir. Se añade la ventana de control de
congestión, CongWindow, y el emisor restringirá envíos con:
LastByteSend − LastByteAcked ≤ m´ (CongWindow, RcvWindow)
ın
Grosso modo, el emisor consigue ajustar la tasa de envío a CongWindow
RTT
octetos/s, con RTT (Round Trip Time) el tiempo de respuesta.
Detección: bien fin de temporización sin recibir asentimiento, bien
recepción de tres asentimientos duplicados.
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.5

6. TCP: Crecimiento aditivo/decrecimiento multiplicativo
La idea es incrementar CongWindow en el tamaño máximo
de segmento (MSS) cada RTT, que implica incrementar a
cada asentimiento nuevo recibido
1
CongWindow
· MSS
MSS
Ante vencimiento de temporización (pérdida de paquete)
se reduciría a
CongWindow
m´x
a , MSS
2
El comportamiento de las conexiones TCP de larga
duración será el típico en diente de sierra.
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.6

7. TCP: Arranque lento
IdeaEvitar el envío de toda la ventana de congestión/flujo
de golpe.
Algoritmo Se inicia CongWindow a MSS, se incrementa en
MSS cada asentimiento nuevo recibido.
Crecimiento exponencial CongWindow dobla su tamaño cada
RTT
Finaliza cuando CongWindow alcanza el valor CongThreshold,
que en cada uso tomará un valor distinto:
´
Inicio de conexion Prefijado a un valor elevado.
Vencimiento de temporizador Será CongThreshold el que se
ponga a CongWindow/2 (CongWindow se pondrá a MSS).
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.7

8. TCP: Retransmisión rápida
Ante la recepción de 3 asentimientos duplicados (4 iguales) reenvía
el paquete por asentir, con:
TCP Tahoe Igual reacción que ante temporización: Arranque lento.
TCP Reno Utiliza recuperación rápida.
Recuperación rápida
o o
1. 1 W ← CongWindow 2 CongWindow ← CongThreshold ← W/2
2. Incrementa CongWindow en MSS por cada asentimiento duplicado
recibido (incluyendo los 3 que han generado esta fase): permite
o
el envío de un máximo (si paquete perdido el 1 de la ventana ⇒
hay W en vuelo) de CongWindow (mitad de W) nuevos octetos
mientras espera asentimiento nuevo.
3. Recepción del asentimiento nuevo: CongWindow ← CongThreshold,
paso a modo normal.
TCP NewReno: No vuelve al modo normal hasta ser asentida toda la
ventana W inicial.
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.8

9. TCP Reno: evolución de CongThreshold
TRIPLE ASENTIMIENTO DUPLICADO FIN DE TEMPORIZACIÓN
45
40
35
CongThreshold
30
(segmentos)
25
CongThreshold
20
CongWindow
15 CongThreshold
10
5
0
0 2 4 6 8 10 12 14 16 18 20 22 24 26
RTT
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.9

10. TCP: Algunas variantes
TCP Vegas Control preventivo a partir de la variaciones del
RTT.
Fast TCP Ídem pero más agresivo en la búsqueda del
ancho de banda utilizable.
TCP Veno Híbrido entre Reno y Vegas para intentar evitar
falsas pérdidas por congestión en redes móviles.
TCP BIC Binary Increase Congestion control, más
agresivo que Reno en busca del ancho de banda
disponible (Linux >2.6.8).
TCP CUBIC Sucesor del BIC, menos agresivo (Linux
>2.6.19), intenta limitar el impacto del valor del RTT.
TCP SACK Incorpora Selective Acknowledgement para
optimizar los reenvíos y el caudal de salida.
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.10

11. Control de congestión en Internet: RED (I)
Random Early Detection: los nodos de conmutación IP monitorizan la
ocupación media de las colas y ante superación de umbrales
notifican con cierta probabilidad al origen de forma implícita mediante
el descarte de un paquete (también propuesto explícitamente con
Explicit Congestion Notification).
El tamaño medio se estima a patir de sucesivas medidas (instantes
de llegada de paquetes) Q′ :
Q = (1 − β) × Q + β × Q′
con 0 < β < 1, y al llegar un paquete se compara con dos límites
MinThreshold y MaxThreshold:
si Q ≤ MinThreshold se acepta el paquete,
si MinThreshold < Q < MaxThreshold con probabilidad P(Q, count) se
o
descarta el paquete (count n paquetes no descartados en este
punto desde el último que sí lo fue),
si MaxThreshold ≤ Q se descarta el paquete.
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.11

12. Control de congestión en Internet: RED (y II)
R(Q) × (Q − MinThreshold)
Pmáx
P(Q, count) = , R(Q) =
1 − count × R(Q) MaxThreshold − MinThreshold
R(Q)
1.0
Pmáx
MinThresh MaxThresh Q
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.12

13. Regulación del tráfico
Dado que una de las principales causas de la congestión
es que el tráfico es a ráfagas, los mecanimos de
regulación de tráfico fuerzan a las fuentes a transmitir de
forma más predecible.
En realidad, lo que se pretende es regular la tasa media y
la variabilidad del tráfico de entrada a la red. Aunque esta
regulación es más fácil de implementar con circuitos
virtuales, puede aplicarse igualmente a redes de
datagramas.
Los mecanismos típicos son Leaky Bucket y Token
Bucket.
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.13

14. Algoritmo Leaky Bucket
Cada fuente se conecta a la red a través de una interfaz que contiene
una cola finita (leaky bucket capaz de almacenar un máximo de K
paquetes (u octetos), de forma que cualquier paquete que llegue
estando la cola llena será descartado. De esa cola se envían los
paquetes a la red a una tasa constante de µ pkt/s (o B/s),
independientemente de cuál sea la tasa de llegada al leaky bucket.
Fuente
flujo no regulado
Bucket
flujo regulado
Red
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.14

15. Algoritmo Token Bucket (I)
El algoritmo Leaky Bucket fuerza a una tasa constante,
independientemente de lo variable que sea el tráfico. Para
muchas aplicaciones se prefiere, sin embargo, que para
ráfagas cortas esa tasa pueda ser incrementada. Se
necesita un algoritmo más flexible.
En el algoritmo Token Bucket, se añade un depósito de
testigos (tokens), que son generados a una tasa de µ
testigos/s, hasta un máximo de K testigos, de forma que
o
cada testigo da derecho a transmitir un paquete (o un n
de octetos). Así, este algoritmo permite ahorrar testigos
cuando no hay datos que transmitir, comportándose de la
misma manera que Leaky Bucket cuando siempre hay
datos para transmitir.
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.15

16. Algoritmo Token Bucket (II)
Para una ráfaga de longitud S segundos, y si la tasa
máxima de salida permitida es de M pkt/s, una ráfaga de
salida contendrá como mucho K + µ · S paquetes. Por otro
lado, el número de paquetes en una ráfaga a velocidad de
salida máxima es M · S.
Por tanto, la duración máxima Smáx de una ráfaga de
salida será:
K
K + µ · Smáx = M · Smáx =⇒ Smáx =
M−µ
Para suavizar el tráfico de entrada a la red se puede
combinar un Leaky Bucket de tasa µl tras un Token
Bucket de tasa µt , de forma que µt < µl < M.
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.16

17. Ejemplo: Leaky Bucket
flujo de entrada a la red no regulado
Fuente 1 MB cada segundo
25 MBps
25 MBps
t
40 ms
K = 1 MB
flujo de entrada a la red regulado
µ = 2 MBps
2 MBps
t
Red
500 ms
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.17

18. Ejemplo: Token Bucket
K
Fuente 1 MB cada segundo S=
M−µ
25 MBps 10′ 86 ms — 25 MBps — 271′ 5 KB
K = 250KB
364 ms — 2 MBps — 728′ 5 KB
flujo de entrada a la red regulado
25 MBps
2 MBps
M = 25 MBps
µ = 2 MBps
t
10′ 86 ms 375 ms
Red
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.18

19. Ejemplo: Token Bucket + Leaky Bucket
Fuente 1 MB cada segundo Kt
S=
µl − µt
25 MBps
Kt = 500 KB
62′ 5 ms — 10 MBps — 625 KB
Token Bucket
187′ 5 ms — 2 MBps — 375 KB
µt = 2 Mbps
flujo de entrada a la red regulado
10 MBps
Leaky Bucket
2 MBps
t
µl = 10 MBps
62′ 5 ms 250 ms
Red
˜ ı ´
Departamento de Enxener´a Telematica ´
Sistemas de Conmutacion ´
Control de congestion– p.19