Adaptación de Agustín J. González de la versión por 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/spring06/cos461/

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)

Asignación de recursos vs. Control de congestión 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)

Control de Flujo vs. Control de Congestión 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: min{ventana de recepción, ventana de congestión}

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

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

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

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

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: Average Packet delay Power Load Load “optimal load” Meta: Maximizar “potencia”

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?

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

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

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 = min{congestion 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

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

Conduce al “diente de sierra” de TCP Window Loss halved t

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

Partimos con pequeño CWND para evitar sobrecarga. Iniciación Partimos con pequeño CWND para evitar sobrecarga. Window Pero, puede demorar mucho! t

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

Partida Lenta en Acción Duplica CWND por cada round-trip time 1 2 4 8 Src D D A A D D D D D A A A A A Dest

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.

Dos tipos de pérdidas de paquetes Triple ACK duplicado Paquete n se pierde, pero paquetes n+1, n+2, 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

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.

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

Algoritmo de Nagle y ACK retardados Otros mecanismos TCP Algoritmo de Nagle y ACK retardados

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

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.

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

Encabezado TCP permite Piggybacking Source port Destination port Sequence number Flags: SYN FIN RST PSH URG ACK Acknowledgment HdrLen Flags Advertised window Checksum Urgent pointer Options (variable) Data

Ejemplo de Piggybacking Data B tiene datos para enviar Data+ACK Data B no tiene datos para enviar ACK Data A tiene datos para enviar Data + ACK

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 A B Data Data+ACK Data ACK Data Data + ACK

ACK retardado Retardamos el envío de un ACK Limite de espera 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

Mecanismos de encoamiento Random Early Detection (RED) Explicit Congestion Notification (ECN)

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

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

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

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

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”… 

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

Conclusiones Congestión es inevitable Congestión puede ser manejada 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)