Control de Congesti

1
Control de Congestión

• Adaptación de Agustín J. González de la versión
  por
• Jennifer Rexford
• http//www.cs.princeton.edu/courses/archive/spring
  06/cos461/

2
Objetivos de esta sección

• Principios del control de congestión
• Entender que la congestión ocurre
• Adaptación para aliviar la congestión
• Control de Congestión en TCP
• Aumento aditivo, reducción multiplicativa
• Partida lenta y re-inicios con partida lenta
• Mecanismos de TCP relacionados
• Algoritmo de Nagle y acuses de recibo retardados
• Manejo Activo de colas
• Random Early Detection (RED)
• Explicit Congestion Notification (ECN)

3
Asignación de recursos vs. Control de congestión

• Asignación de Recursos
• Cómo los nodos logran recursos demandados en
  forma competitiva
• Ej., anchos de banda y espacio en buffers
• Cómo decir no, y a quien
• Control de Congestión
• Cómo los nodos previenen o responden a
  condiciones de sobrecarga
• Ej., persuadir host que pare de enviar o baje su
  tasa
• Típicamente procura la justicia (i.e., compartir
  el dolor)

4
Control de Flujo vs. Control de Congestión

• Control de Flujo
• Impedir que un transmisor rápido sobrecargue a un
  receptor lento
• Control de Congestión
• Impedir que un conjunto de transmisores
  sobrecargue la red
• Conceptos diferentes, pero similares en mecanismo
• Control de flujo en TCP Ventana de recepción
• Control de Congestión en TCP Ventana de
  Congestión
• Ventana TCP minventana de recepción, ventana de
  congestión

5
Tres características claves de Internet

• Conmutación de paquetes
• Una fuente dada puede tener suficiente capacidad
  para enviar paquetes de datos
• pero los paquetes pueden encontrar un enlace
  sobrecargado
• Flujo sin conexión
• No hay noción de conexión dentro de la red
• y no hay reservación de recursos de la red
• Aún así, podemos ver paquetes relacionados como
  un grupo (flujo)
• e.g., paquetes en la misma transferencia TCP
• Servicio Best-effort
• No hay garantía de entrega de paquetes o retardo
  dado
• No hay tratamiento preferencial de ciertos
  paquetes

6
Congestión es inevitable

• Dos paquetes llegan al mismo tiempo
• El nodo puede transmitir sólo uno
• y ya sea almacena o descarta el otro
• Si muchos paquetes llegan en un corto periodo de
  tiempo
• El nodo no puede atender el tráfico de llegada
• y el buffer eventualmente es superado

7
Colapso de Congestión

• Definición Aumento en la carga de la red resulta
  en caída de trabajo útil hecho
• Muchas causas posibles
• Retransmisiones espurias de paquetes aun en viaje
• Colapso de congestión clásico
• Solución mejores timers y control de congestión
  TCP
• Paquetes no entregados
• Paquetes consumen recursos y son descartados en
  alguna parte de la red
• Solución Control de congestión para todo tipo de
  tráfico

8
Qué queremos, realmente?

• Alto throughput
• Throughput mide el desempeño de un sistema
• Ej., número de bits/s de datos que llegan a
  destino
• Bajo retardo
• Retardo tiempo requerido para entregar un
  paquete o mensaje
• Ej., número de ms para entregar un paquete
• Estas dos métricas son algunas veces
  contrapuestas
• Ej., supongamos que transmitimos al máximo del
  enlace
• entonces, throughput será alto, pero retardo
  también

9
Carga, retardo, y potencia
Comportamiento típico de un sistema de colas
con llegadas aleatorias
Una métrica simple sobre qué tan bien se
desempeña la red
Power
Average Packet delay
Load
Load
optimal load
Meta Maximizar potencia
10
Justicia

• La utilización efectiva no es la única meta
• También queremos ser justos para varios flujos
• pero qué significa esto?
• Definición Simple igual porción del ancho de
  banda
• N flujos que cada uno obtiene 1/N del BW?
• Pero, Y si los flujos atraviesan caminos
  diferentes?

11
Asignación de recursos simple

• Esquema más simple encolado FIFO y descarte por
  la cola
• Ancho de banda de enlace encolado first-in
  first-out
• Los paquetes son transmitidos en el orden que
  llegan
• Espacio de buffer descarte por la cola
• Si la cola está llena, descarta paquetes entrantes

12
Detección de Congestión Simple

• Pérdida de paquetes
• Paquetes son descartados a lo largo del la ruta
• Retardo de paquetes
• Paquetes experimentan alto retardo cuando hay
  congestión
• Cómo los transmisores TCP se dan cuenta de esto?
• Pérdidas
• Se hace uso de Timeout
• Luego de tres acuses de recibo duplicados
• Retardo
• Round-trip time (RTT) es estimado

13
Idea de Control de Congestión en TCP

• Cada fuente determina la capacidad disponible
• así sabe cuántos paquetes puede transmitir
• Ventana de Congestión
• máximo de bytes sin acuse de recibo a tener en
  tránsito
• Es el control de congestión equivalente a la
  ventana de recepción
• MaxWindow mincongestion window, receiver
  window
• Enviar a la tasa de la componente más lenta
• Adaptación de la ventana de congestión
• Reducción bajo pérdida de un paquete retroceso
• Aumento bajo éxito exploración optimista

14
Aumento aditivo, reducción multiplicativa

• Cuánto aumentar y reducir? (cómo se hace en
  control?)
• Aumento lineal, reducción multiplicativa
• Es una condición necesaria para estabilidad de
  TCP
• Consecuencias de ventanas sobredimensionadas son
  mucho peores que subdimensionadas
• Ventanas sobredimensionadas descarte de paquete
  y retransmisión
• Ventana subdimensionadas menor throughput
• Reducción multiplicativa
• Bajo pérdida de paquetes, divide la ventana de
  congestión a la mitad
• Aumento aditivo
• Bajo éxito para última ventana de datos, aumento
  linealmente

15
Conduce al diente de sierra de TCP
Window
Loss
halved
t
16
Detalles prácticos

• Ventana de congestión
• Representada en bytes, no en paquetes (por qué?)
• Paquetes tienen MSS (Maximum Segment Size) bytes
• Aumentos de la ventana de congestión
• Aumento en MSS bajo éxito de última ventana de
  datos
• En práctica, aumento en fracciones de MSS por
  cada ACK recibido
• paquetes por ventana CWND / MSS
• Aumento por ACK MSS (MSS / CWND)
• CWND Congestion Window
• Reducción de la ventana de congestión
• Nunca se reduce la ventana bajo 1 MSS

17
Iniciación
Partimos con pequeño CWND para evitar sobrecarga.
Window
Pero, puede demorar mucho!
t
18
Fase de Partida Lenta

• Partimos con ventana de congestión pequeña
• Inicialmente, CWND es 1 MSS
• Así, tasa inicial es MSS/RTT
• Eso puede ser muy ineficiente
• Puede ser mucho menos que el BW disponible
• Aumento lineal toma mucho tiempo en subir tasa
• Fase de partida lenta (realmente partida
  rápida)
• Transmisor parte a tasa baja (de allí su nombre)
• pero aumenta la tasa exponencialmente
• hasta primer evento de pérdida

19
Partida Lenta en Acción
Duplica CWND por cada round-trip time
1
2
4
8
Src
D
D
D
A
A
D
D
D
D
A
A
A
A
A
Dest
20
Partida Lenta y diente se sierra
Window
Pérdida
t
Partida lenta Exponencial
Por qué se llama partida lenta? Porque TCP
originalmente no tenía mecanismo de control de
congestión. La fuente sólo partía enviando una
ventana completa de datos.
21
Dos tipos de pérdidas de paquetes

• Triple ACK duplicado
• Paquete n se pierde, pero paquetes n1, n2, etc.
  llegan
• Receptor envía ACK duplicados
• y el transmisor retransmite paquete n
  rápidamente
• Hace una reducción multiplicativa y sigue
• Timeout
• Paquete n se pierde y es detectado vía un timeout
• E.g.,porque todos los paquetes en vuelo se
  perdieron
• Después del timeout, envío completo de la ventana
• gatillaría una ráfaga muy grande de tráfico
• Así que mejor partir nuevamente con bajo CWND

22
Después de timeout se repite Slow Start
Window
timeout
Slow start en operación hasta alcanzar ½ de
ventana previa
t
Reinicio en Slow-start volver a CWND de 1, pero
tomar ventaja de valor conocido previo de CWND.
23
Repetición de Slow Start después de un periodo de
inactividad

• Supongamos que la conexión suspende tráfico por
  un rato
• Ej., sesión shell donde no tipeamos por una hora
• La condiciones de la red pueden cambiar
• Pueden haber muchos otros flujos transitando el
  enlace
• Ej., todos volvieron del almuerzo!
• Es peligroso partir a tasa antigua
• Transmisores TCP previos podrían llenar la red
• causando congestión excesiva y pérdida de
  paquetes
• Así que, algunas implementaciones de TCP repiten
  slow start
• Slow-start se reinicia después de periodo de
  inactividad

24
Otros mecanismos TCP

• Algoritmo de Nagle y ACK retardados

25
Motivación para Algoritmo de Nagle

• Aplicaciones interactivas
• Shell, telnet, rlogin
• Generan muchos paquetes pequeños (ej., teclado)
• Paquetes pequeños es un derroche
• Casi todo es encabezado (ej., 40 bytes v/s 1 de
  data)
• Es atractivo reducir el número de paquetes
• Podemos forzar que cada paquete tenga algún
  tamaño mínimo
• pero, y si la persona no escribe más
  caracteres?
• Necesitamos balancear compromisos en competencia
• Transmitir paquetes grandes
• pero no introducir mucho retardo por esperas

26
Algoritmo de Nagle

• Y si la cantidad de datos es pequeña?
• Más pequeña que Maximum Segment Size (MSS)
• Y algún otro paquete ya está en transito
• I.e., aún esperando por el ACKs de paquetes
  previo
• Esto es, enviar a lo más un paquete por RTT
• esperar hasta que todos los ACKs pendientes han
  llegado
• Efecto en desempeño
• Aplicaciones interactivas permite enviar tandas
  de bytes
• Transferencias masivas transmite paquetes de
  tamaño MSS igualmente

ACK
vs.
27
Motivación de ACK retardado

• Tráfico TCP es a menudo bidireccional
• Data viaja en ambas direcciones
• ACKs viajan en ambas direcciones
• Paquetes ACK tiene alto overhead
• 40 bytes por encabezados IP y TCP
• y ningún tráfico de datos
• Piggybacking (llevar a cuestas) es atractivo
• Host B puede enviar un ACK a host A
• como parte del paquete de datos desde B a A

28
Encabezado TCP permite Piggybacking
Source port
Destination port
Sequence number
Flags
SYN FIN RST PSH URG ACK
Acknowledgment
Advertised window
HdrLen
Flags
0
Checksum
Urgent pointer
Options (variable)
Data
29
Ejemplo de Piggybacking
B
A
Data
B tiene datos para enviar
DataACK
Data
B no tiene datos para enviar
ACK
Data
A tiene datos para enviar
Data ACK
30
Aumento de probabilidad de Piggybacking

• Aumento de piggybacking
• TCP permite que el Rx espere antes de enviar ACK
• en la esperanza que el host tendrá datos para
  enviar
• Ejemplo ssh, rlogin o telnet
• Host A escribe en la consola UNIX
• Host B recibe los caracteres y ejecuta un comando
• y entonces los datos son generados
• Sería bueno si B pudiera enviar el ACK con nuevos
  datos

B
A
Data
DataACK
Data
ACK
Data
Data ACK
31
ACK retardado

• Retardamos el envío de un ACK
• Bajo recibo de un paquete, el host B fija un
  timer
• Tipicamente, 200 msec o 500 msec
• Si la aplicación de B genera datos, eviarlo
• y piggyback el ACK
• Si el timer expira, enviar un ACK sin piggyback
• Limite de espera
• Timer de 200 msec o 500 msec
• ACK paquete por medio de tamaño competo

32
Mecanismos de encoamiento

• Random Early Detection (RED)
• Explicit Congestion Notification (ECN)

33
Pérdidas de ráfagas por descarte por la cola

• TCP depende de pérdida de paquetes
• Pérdida de paquetes es la indicación de
  congestion
• TCP conduce a la red a pérdida de paquetes
• por aumento continuo de tasa de envío.
• Descarte de la cola conduce a pérdidas en ráfaga
• Cuando el enlace se congestiona
• muchos paquetes encuentran la cola llena
• y, muchos flujos individuales pierden múltiples
  paquetes
• y, como resultado, muchos flujos dividen su
  tasa a la mitad

34
Realimentación lenta en descarte de cola

• Realimentación llega sólo cuando el buffer está
  lleno
• aún cuando se estaba llenando desde hace un
  rato
• Más, el buffer hace aumentar el RTT
• y la varianza en el RTT
• Puede ser mejor dar realimentación temprana
• Hacer que uno o dos flujos bajen tasa, no todos
  ellos
• Hacer que bajen tasa antes que sea muy tarde

35
Random Early Detection (RED)

• Idea básica de RED
• Router notan que la cola se está llenando
• y aleatoriamente descartan paquetes para
  señalar congestión
• Probabilidad de descarte de paquetes
• Probabilidad de descarte aumenta con el tamaño de
  la cola
• Bajo ciento nivel no descartar
• de otra manera, la probabilidad d e descarte es
  función del largo de la cola

Probability
Average Queue Length
36
Propiedades de RED

• Descarta paquetes antes que la cola está llena
• Con la esperanza de reducir tasa de algunos
  flujos
• Descarta paquetes en proporción a la tasa de cada
  flujo
• Flujos de lata tasa tienen mas paquetes
• y, por ello, una mayor chance de ser
  seleccionados
• Descartes son espaciados en tiempo
• Lo cual debería ayudar a desincronizar
  transmisores TCP
• Tolera ráfagas de tráfico
• Al basar su decisión en el promedio del largo de
  la cola

37
Problemas con RED

• Difícil de ajustar los parámetros correctamente
• Cuan pronto comenzar a descartar paquetes?
• Qué pendiente usar para aumentar probabilidad de
  descarte?
• Qué escala de tiempo usar para promediar largo de
  cola?
• Algunas veces RED ayuda pero otras no
• Si los parámetros no son los correctos, RED no
  ayuda
• Y es difícil fijar los parámetros
• RED es implementado en la práctica
• Pero, a menudo no usado por la dificultad de
  sintonizarlo bien.
• Muchas variaciones
• Con nombres simpáticos como Blue y FRED ?

38
Notificación de Congestión Explícita

• Descarte temprano de pauetes
• Bueno da realimentación temprana
• Malo debe descartar paquete para avisar
• Notificación de Congestión Explícita
• Routers marcan los paquetes con un bit ECN
  (Explicit Congestion Notification)
• y host Tx interpreta como signo de congestión
• Superando el desafío
• Debe ser soportado por los host extremos y
  routers
• Requiere dos bits en encabezado de IP (uno para
  marcar ECN, y uno para indicar capacidad de ECN)
• Solución usar dos de los bits de Type-Of-Service
  en encabezado de IPv4

39
Conclusiones

• Congestión es inevitable
• Internet no reserva recursos por adelantado
• TCP activamente trata de empujar el tráfico
• Congestión puede ser manejada
• Aumento aditivo, reducción muktiplicativa
• Slow start, y reinicios en slow-start
• Administración activa de colas puede ayudar
• Random Early Detection (RED)
• Explicit Congestion Notification (ECN)