Control de Congestión Claudio Enrique Righetti

Presentación del tema: "Control de Congestión Claudio Enrique Righetti"— Transcripción de la presentación:

1 Control de Congestión Claudio Enrique Righetti
Teoría de las Comunicaciones Departamento de Computación Facultad de Ciencias Exactas y Naturales UBA Curso 2 C 2011

2 Bibliografía Básica Peterson, L., Davie, B.: Computer Networks: A Systems Approach. Third Edition, The Morgan Kaufmann Series in Networking, David Clark, Series Editor, Cap 6 Andrew S. Tanenbaum : Computer Networks, Fourth Edition , Prentice Hall, Cap 5.3 Jim Kurose, Keith Ross Redes de computadores: un enfoque descendente basado en Internet, 2ª edición. 2002

3 Introducción 1 Parte

4 Administración de Buffers
Agregación Diferentes LAN a WAN 10 Mbps 10 Mbps 1000 Mbps 64 Kbps Tendencia a llenarse de los buffers (TCP windowing) Buffering reduce Loss, introduce Delay Overflow de buffers => se descartan paquetes (o frames) Para garantizar QoS se deben prealocar y reservar

5 Que hacer ?? Sobredimensionamiento (Overprovisioning) Diseñar …….
Controlar , Evitar …..

6 Soluciones La presencia de congestión significa que la carga 8 a veces en forma temporaria ) es mayor que los recursos. Desde otro punto de vista que podemos hacer : Incrementar los recursos ( BW , Buffers ??) Decrementar la carga ;-)

7 Retardo de una COLA – M/M/1
Media de retardo de cola R = ancho de banda del enlace (bps). L = longitud del paquete (bits). a = media de tasa de llegada del paquete. Intensidad de tráfico = La/R La/R ~ 0: media de retardo de cola pequeño. La/R -> 1: aumentan los retardos. La/R > 1: ¡Llega más “trabajo” del que puede servirse, media de retardo infinita!

8 “One way delay”

9 Antecedentes [1] Dispositivo control presión en una Máquina de vapor
[1] de la presentacion de Van Jacobson “Notes on Using Red for queue management and Congestion Avoidance “ Junio 1998

10 Fundamentos del control de la congestión
Informalmente: “demasiadas fuentes enviando demasiados datos demasiado de prisa por la red como para poder manejarlo”. ¡Diferente del control de flujo! Manifestaciones: Pérdida de paquetes (Los buffer se saturan en los routers o sw). Largos retardos (por las colas en los buffer ). ¡Uno de los diez problemas fundamentales!

11 Consideraciones sobre los nodos
De no expresarse lo contrario se asume que : FIFO el primer paquete que llega se transmite Cuando se llena la cola se descarta , drop tail FIFO es un mecanismo de scheduling , drop tail es una política Introducen sincronización global cuando los paquetes son descartados desde diversas conexiones

12 Congestión Estado sostenido de sobrecarga de una red donde la demanda de recursos (enlaces y buffers) se encuentra al límite o excede la capacidad de los mismos.

13 Congestion vs. Flow Control
Los mecanismos de control de la Congestión deberían poder evaluar la capacidad de la subnet para transportar determinado tráfico. Congestión es una cuestión global involucra todos los hosts y routers Flow control : controla tráfico point-to-point entre un receptor y un transmisor (supercomputadora - PC sobre fibra)

14 Métricas Varias métricas podría usar para detectar congestión
% de paquetes descartados por falta de espacio en buffer Longitud media de una cola ( buffer) # paquetes que generan time out y son RTX average packet delay standard deviation of packet delay En todos los casos el crecimiento de alguna de esta metricas indican congestion

15 Politicas que influyen en la congestion

16 Causas Inundo con trafico destinado a una misma línea de salida (la cola se llena – tail drop ) Mas Memoria no necesariamente resuelve el problema Procesadores lentos, o problemas con software de ruteo Partes del Sistema ( varias líneas rápidas y una lenta ) Congestión tiene a realimentarse y empeorar

17 Consideraciones Control de Congestión: Es el esfuerzo hecho por los nodos de la red para prevenir o responder a sobrecargas de la red que conducen a perdidas de paquetes. Los dos lados de la moneda Pre-asignar recursos (ancho de banda y espacio de buffers en routers y switches) para evitar la congestión Controlar la congestión si ocurre (y cuando ocurra) Objetivo: asignar los recursos de la red en forma “equitativa”; es decir cuando haya problemas compartir sus efectos entre todos los usuarios, en lugar de causar un gran problema a tan solo unos pocos. Destination 1.5-Mbps T1 link Router Source 2 1 100-Mbps FDDI 10-Mbps Ethernet Alocación de recursos y control de congestión han sido temas de constante estudio desde que estos problemas fueron detectados[1]. Uno de los factores que incrementa la complejidad de estos problemas, es que no están aislados a un único nivel del modelo de arquitectura de redes[2]. La alocación de recursos (principalmente buffers y ancho de banda de los enlaces) se encuentra en parte implementada en los routers o switches dentro de las redes; y en parte en los protocolos de transporte que se ejecutan en los hosts. Algunos de los protocolos de red dentro de los hosts trabajan anunciando los requerimientos de recursos a los nodos, quienes responden con información acerca de la disponibilidad de los mismos. Entendemos por alocación de recursos al proceso por el cual los elementos dentro de una red intentan alcanzar las demandas competitivas que las aplicaciones poseen en cuanto a recursos de red; principalmente ancho de banda y espacio de buffers en routers o switches. Por supuesto, en general no es posible lograr satisfacer todas las demandas, lo que significa que algunos usuarios o aplicaciones podrían recibir menos recursos de red que lo requerido[3]. Esto lleva a la necesidad de decidir cuando y como ceder o no estos recursos. [1] Nagle detecta y reporta congestión en 1984 [RFC 896], y en una primera aproximación propone un mecanismo centrado en los routers. Durante 1986 y 1987 se producen varios fenómenos de congestión, y quienes mantenían el Backbone, BBN, proponen como una solución parcial aumentar el ancho de banda de los enlaces. Finalmente Jacobson y Karels intenta mitigar el problema de congestión introduciendo los algoritmos de control de congestión detallados en [Jac1988]. [2] En [Tan1996] se detalla como afectan a la congestión las políticas de los protocolos de nivel 2, 3 y 4. [3] En realidad alocar recursos, es realizar un reservación de los mismos. Dicha reservación plantea una Paradoja de Reservación: cuando se reserva no se permite que otro interesado acceda a dicho recurso (una analogía de la vida real sucede cuando se reserva la mesa en un restaurante, la misma puede permanecer vacía durante un periodo de tiempo y no puede ser usada por otros comensales que llegan antes que los que realizaron la reserva, esta paradoja realmente va en contra del modelo best effort de Internet )

18 Consideraciones (cont)
Control de flujo v/s control de congestión: el primero previene que los transmisores sobrecarguen a receptores lentos. El segundo evita que los transmisores sobrecarguen el interior de la red. Dos puntos para su implementación maquinas en los extremos de la red (protocolo de transporte) routers dentro de la red (disciplina de encolado, RED , etc ) Modelo de servicio de los niveles inferiores best-effort o mejor esfuerzo (lo asumimos por ahora). Es el servicio de Internet. múltiples calidades de servicio QoS . Por ejemplo ancho de banda (para video streaming bajo) y retardo (para Voz sobre IP VoIP).

19 Marco de trabajo En redes orientadas a conexión. Se reserva ancho de banda y espacio al establecer la conexión. => Subutilización de recursos. Flujos de datos en redes sin conexión (datagramas : Internet) secuencia de paquetes enviados entre el par fuente/destino mantenemos soft-state en el router Taxonomía Centrado en router versus centrado en los hosts basados en reservación versus los basados en realimentación basados en ventanas versus los basados en tasa de transferencia Router Source 2 1 3 Destination

20 Criterios de Evaluación (1)
La idea es que la red sea utilizada eficientemente y al mismo tiempo en forma equitativa Buen indicador para eficiencia: Potencia =throughput / retardo Optimal load Load Throughput/delay Paquetes que saturan capacidad y colas crecen, crece retardo Muy conservativo: Subutilización de recursos

21 Criterios de Evaluación (2)
Equidad: los recursos sean compartidos equitativamente. Indicador de equidad de Jain: Dados n flujos por un enlace (x1, x2, ...xn) 0  f  1

22 Performance de la red en función de la carga
Knee Cliff Tiempo de Respuesta Throughput

23 Performance de la red en función de la carga (2)
A medida que la carga (la tasa de datos transmitida) de la red aumenta, el throughput (tasa de datos que alcanzan el destino) se incrementa linealmente. Sin embargo, a medida que la carga alcanza la capacidad de la red, los buffers en los routers comienzan a llenarse. Esto causa el incremento del tiempo de respuesta (el tiempo que tardan los datos en atravesar la red entre el origen y destino) y disminuye el throughput. Una vez que los buffers de los routers comienzan a sobrecargarse ocurre la pérdida de paquetes. Incrementos en la carga más allá de este punto incrementa la probabilidad de pérdida de paquetes. Bajo cargas extremas, el tiempo de respuesta tiende a infinito y el throughput tiende a cero; este es el punto del colapso de congestión. Este punto es conocido como el cliff debido a la extrema caída en el throughput.

24 Congestión y Calidad de Servicio
Sería muy fácil dar Calidad de Servicio si las redes nunca se congestionaran. Para ello habría que sobredimensionar todos los enlaces, cosa no siempre posible o deseable. Para dar QoS con congestión es preciso tener mecanismos que permitan dar un trato distinto al tráfico preferente y cumplir el SLA (Service Level Agreement). El SLA suele ser estático y definido en el momento de negociación del contrato con el proveedor de servicio o ISP (Internet Service Provider).

25 Efectos de la congestión en el tiempo de servicio y el rendimiento
Aquí QoS!! Sin Congestión Congestión Moderada Congestión Fuerte Sin Congestión Congestión Moderada Congestión Fuerte Tiempo de Servicio Rendimiento Carga Carga Es bien sabido que incluso desde una perspectiva de optimizar el uso global de los recursos no es deseable una excesiva carga en los enlaces. Cuando la carga aumenta el tiempo de servicio crece de forma exponencial y como consecuencia de esto las aplicaciones no pueden funcionar o retransmiten la información que creían perdida. Por tanto a partir de un cierto nivel de carga no solo crece el tiempo de servicio, sino que disminuye el rendimiento obtenido del enlace debido a las retransmisiones. El objetivo de la Calidad de Servicio es asegurar que en casos de carga relativamente elevada (la zona marcada como de ‘congestión moderada’ en la gráfica) las aplicaciones que lo requieran podrán disfrutar de un tiempo de servicio reducido. Si la red tiene siempre niveles de carga inferiores el funcionamiento se complica y no se obtiene beneficio al aplicar mecanismos de Calidad de Servicio. Si la red tiene normalmente niveles fuertes de congestión los mecanismos de Calidad de Servicio difícilmente serán capaces de asegurar el nivel de calidad pedido a las aplicaciones que así lo requieran. QoS inútil QoS útil y viable QoS inviable QoS inútil QoS útil y viable QoS inviable Por efecto de retransmisiones

26 Calidad de Servicio (QoS)
Decimos que una red o un proveedor ofrece ‘Calidad de Servicio’ o QoS (Quality of Service) cuando se garantiza el valor de uno o varios de los parámetros que definen la calidad de servicio que ofrece la red. Si el proveedor no se compromete en ningún parámetro decimos que lo que ofrece un servicio ‘best effort’. El contrato que especifica los parámetros de QoS acordados entre el proveedor y el usuario (cliente) se denomina SLA (Service Level Agreement)

27 Calidad de Servicio en Internet
La congestión y la falta de QoS es el principal problema de Internet actualmente. TCP/IP fue diseñado para dar un servicio ‘best effort’. Existen aplicaciones que no pueden funcionar en una red congestionada con ‘best effort’. Ej.: videoconferencia, VoIP (Voice Over IP), etc. Se han hecho modificaciones a IP para que pueda funcionar como una red con QoS

28 Resumiendo Se utiliza el término control de congestión para describir los esfuerzos que ha de realizar un nodo de red (ya sea un router o un end-host) para prevenir o responder a condiciones de sobrecarga. Llegar al punto de la existencia de congestión es generalmente un mal síntoma. Por lo cual, es conveniente tomar medidas preventivas, y no correctivas cuando ya el problema fue detectado. Una de las posibles soluciones sería simplemente persuadir a unos pocos hosts que disminuyan el flujo de tráfico generado, con una consecuente mejora en la situación del resto de los hosts. Sin embargo, esto lleva a enviar mensajes de señalización a algunos pocos hosts, en vez tratar de distribuirla en forma mas equitativa; obligando así a los mecanismos de control de congestión a poseer una noción de alocación de recursos dentro de ellos.

29 Agenda ( 2 Parte) Control de Congestion ( cont.) Taxonomia Lazo Cerrado-Abierto RED FRED ( optativo)

30 Taxonomia De acuerdo a la taxonomía de Yang y Reddy (1995), los algoritmos de control de congestión se pueden clasificar en lazo abierto y lazo cerrado. A su vez los de lazo cerrado se pueden clasificar de acuerdo a como realizan la realimentación.

31 Taxonomia [YR95] Control Congestión
Lazo Abierto principalmente en redes conmutacion de circutos (GMPLS) Lazo Cerrado Usado principalmente en redes de paquetes Usa informacion de realimentación : global & local Realimentación Implícita “End-to-end congestion control” EJ: TCP Tahoe, TCP Reno, TCP Vegas, etc. Realimentación Explicita “Network-assisted congestion control” Ej: IBM SNA, DECbit, ATM ABR, ICMP source quench,, ECN

32 “Congestion Control and Avoidance
“congestion control” : reactivo “congestion avoidance” : proactivo

33 Feedback Implícito vs. Explicito
“Implicit feedback Congestion Control” “La red dropea” paquetes cuando ocurre la congestión La fuente infiere la congestión en forma implícita time-out, ACKs duplicados, etc. Ej. : CC end-to-end TCP Implementación relativamente simple , “eficiente” ? Normalmente Implementada a nivel de transporte (Ej.., TCP, SCTP )

34 Feedback Implícito vs. Explicito (cont.)
“Explicit feedback Congestion Control “ Componentes de red (Ej., router, sw ) proveen indicación explicita de la congestión a las fuentes usa “packet marking”, o celdas RM (en ATM ABR control) Ej. DECbit, ECN, ATM ABR CC, etc. Provee informacion mas precisa a las fuentes Mas complicada la implementación Se necesitan cambiar fuente y algoritmo de red Es necesaria cooperación entre fuentes y Componentes de red

35 RED

36 RED El algoritmo RED se tiene por objetivo evitar la congestión y de mantener el tamaño medio de las colas en niveles bajos. RED no necesita que los routers mantengan ninguna información del estado de las conexiones. RED fue diseñado para trabajar en la colaboración con un protocolo del control de la congestión de la capa de transporte (TCP, SCTP).

37 Detección aleatoria temprana (Random Early Detection, RED)
Notificación es implícita solo descarta el paquete (en TCP habrá timeout) podría hacerse explícita marcando el paquete Descarte aleatorio temprano en lugar de esperar por que se llene la cola, descarta cada paquete de entrada con alguna probabilidad de descarte cada vez que la cola excede algún nivel de descarte

38 Detalles de RED Calcula largo de cola promedio
AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen 0 < Weight < 1 (usualmente 0.002) SampleLen es el largo de la cola cada vez que un paquete llega MaxThreshold MinThreshold A vgLen

39 Detalles RED (cont) Dos umbrales de largo de cola
if AvgLen <= MinThreshold then encole el paquete if MinThreshold < AvgLen < MaxThreshold then calcule probabilidad P descarte paquete entrante con probabilidad P if ManThreshold <= AvgLen then descartar paquete entrante

40 Detalles RED (cont) Computo de probabilidad P
TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold) P = TempP/(1 - count * TempP) Count cuneta el número de paquetes encolados mientras el AvgLen está entre los dos umbrales Curva de probabilidad de descarte P(drop) 1.0 MaxP MinThresh MaxThresh A vgLen

41 Sintonía en RED Probabilidad de descartar un flujo particular de paquetes es aproximadamente proporcional a parte del ancho de banda que el flujo está obteniendo MaxP es típicamente fijada en 0.02, es decir cuando el tamaño promedio de la cola es la mitad entre los dos umbrales, el gateway descarta +o- uno de cada 50 paquetes. Si el tráfico es rafagoso, entonces MinThreshold debería ser suficientemente grande para permitir que la utilización del enlace sea mantenida a un nivel aceptablemente alto Diferencia entre los dos umbrales debería ser más grande que el incremento típico en el largo de cola promedio calculado en un RTT; fijar MaxThreshold a dos veces MinThreshold es razonable para el tráfico de hoy en Internet

42 Link Management: Increased Link Utilization *
Data from a Burst E1 (2.0 Mbps) Courtesy of Sean Doran RED Was Turned on Friday at 10:00 am; Link Utilization Goes Up to Near 100% Thursday Friday [*] de una presentación de Cisco sobre QoS

43 FRED

44 Flow Random Early Detection (FRED)
Una de las características más importantes RED es el hecho de que proporciona imparcialidad descartando los paquetes de una conexión según la parte que ocupa del ancho de banda. Sin embargo, RED tiene otros problemas de la imparcialidad ( fairness). RED no es justo (fair) con las conexiones de baja velocidad. Cuando se alcanza el alto umbral, RED descarta los paquetes aleatoriamente, y el paquete descartado pertenece probablemente a una conexión que esté utilizando menos recursos que lo que le corresponde. Cuando la longitud media de la cola está en un punto fijo dentro de los dos umbrales, todos los paquetes entrantes se descartan con la misma probabilidad.

45 Flow Random Early Detection (FRED)
Control de usuarios mal comportados ( bandwith hugs) Aunque se hace cumplir el umbral máximo, si el usuario no disminuye su tasa, RED no tiene ningún mecanismo para proteger a otros usuarios. Los usuarios mal comportados podrían terminar ocupando la totalidad del ancho de banda

46 FRED FRED soluciona estos problemas de imparcialidad manteniendo umbrales y ocupaciones del buffer para cada flujo activo (información por conexión). FRED necesita guardar información por cada flujo para descartar paquetes produciendo un alto costo de operación en los routers FRED debe identificar cada flujo que tenga paquetes en el buffer y actualizar la información por cada paquete Debe mirar la fuente del paquete y las direcciones de destino, los puertos, y la identificación del protocolo de cada paquete

47 Policing Mechanisms Average Rate (100 paquetes por segundo o 6000 paquetes por minuto), un aspecto crucial es la longitud del intervalo Peak Rate: e.g., 6000 p p minute Avg and 1500 p p sec Peak Burst Size: número máximo de paquetes enviados consecutivamente ( en un periodo corto de tiempo)

48 Traffic Shaping El trafico es “bursty “ ( con ráfagas) impacta en la congestión. Traffic shaping es un método de lazo abierto que trata de guiar la congestión , forzando a los paquetes a trasnmitirse a uan velocidad mas predecible Se trata de mantener el trafico constante , es decir regular la tasa de transmisión media (y el “burstiness”) de los datos . Por ejemplo en las redes de CV , en el setup de circuito es usuario y el carrier se poden de acuerdo en el conformado (shape) del circuito. Se necesita de un acuerdo del proveedor y el cliente

49 Algoritmo Leaky Bucket
Basicamente se buscar proveer un we want to do is to provide a consistent, even flow of traffic Think of a bucket with a hole in the bottom, or a leaky faucet, no matter how much water enters the bucket the output flow is constant That’s the idea behind the leaky bucket algorithm

50 Algoritmo Leaky Bucket ( idea )
Flujo de paquetes sin regular El flujo de salida tiene una velocidad constante , cuando hay agua en el balde, y cero cuando esta vacío => Se moderan las ráfagas

51 Implementación El mecanismo de leaky bucket no es mas que un sistema single-server queueing con tiempo de servicio constante y cola finita. Paquetes llegan en cualquier instante , pero a lso host se le permite poner solo un paquete por “clock tick” en la red . Si los paquetes son de diferentes tamaños , es mejor usar un numero fijo de bytes por “tick”, antes que uno por paquete Cola llena, los paquetes que llega son descartados ( tail drop)

52 Algoritmo: Token Bucket
Leaky bucket fuerza un patrón de trafico de salida rígido ( tasa promedio) Token bucket permite picos de tráfico ( aumentar la velocidad , durante un intervalo pequeño) cuando le llega una ráfaga grande de paquetes Aca los baldes (buckets) mantienen fichas (tokens), que son generadas por un clock a un rate de un token cada T segundos Para transmitir, se necesita consumir un token. Si no hay , se espera Hosts Idle pueden “ahorrar” permisos para enviar bursts luego

53 Token Bucket

54 Policing Mechanisms En definitiva Token Bucket permite un Burst Size y Average Rate.

55 Sincronización Global
Utilización de la Cola 100% Tiempo Tail Drop 3 Flujos de Tráfico comienzan a distintos tiempos. Otro Flujo comienza en este instante

56 Parte Entrevista a VJ por Loring Wirbel EE Times March 07, 2005
EET: So all the late-1990s studies of QoS involved people speaking different languages, coming from different perspectives. Jacobson: QoS has been an area of immense frustration for me. We're suffering death by 10,000 theses. It seems to be a requirement of thesis committees that a proposal must be sufficiently complicated for a paper to be accepted. Look at Infocom, look at IEEE papers; it seems as though there are 100,000 complex solutions to simple priority-based QoS problems. The result is vastly increased noise in the signal-to-noise ratio. The working assumption is that QoS must be hard, or there wouldn't be 50,000 papers on the subject. The telephony journals assume this as a starting point, while the IP folks feel that progress in QoS comes from going out and doing something.

57 Ejercicios

58 Ej (1) De acuerdo a la taxonomía de Yang y Reddy (1995), los algoritmos de control de congestión se pueden clasificar en lazo abierto y lazo cerrado. A su vez los de lazo cerrado se pueden clasificar de acuerdo a como realizan la realimentación. A que categoria pertenece RED (Randomly Early Detection)?

59 Ej (2) Algunos autores utilizan la relación que denominan Potencia ( P= Throughput/delay ) como una métrica para medir la eficiencia de un esquema de alocación de recursos . Para un flujo de paquetes que ingresa a un router de una red de conmutación de paquetes , la variación de la potencia en función de la carga ( paquetes/seg. ) es la siguiente[1] : [1] En realidad la teoría subyacente en la definición de potencia esta basada en la teoría clásica de colas en este caso particular un router con una entrada y una salida , se modela como una cola M/M/1 , esta notación ( Kendall ) 1 : un servidor , M es que tanto la distribucion de la llegada de paquetes como el tiempo de servicio son Markovianos , esto es exponenciales . Con lo cual el modelo es una cola FIFO con buffer ilimitado y un servidor que despacha n paquetes/seg .,

60 Ej.(2 cont.) a) ¿En que zona de la funcion Potencia se presenta el fenómeno de congestión , que significa la congestión en redes de conmutación de paquetes ? b) Cuales son dos soluciones posibles para evitar entrar en congestión ? c) una de las causas de la congestión es cuando el trafico se presenta en ráfagas , a tal efecto se han desarrollado mecanismos de “traffic shaping “ que “fuerza” a un trafico mas predecible . Mencione un mecanismo de traffic shaping ? Dicho mecanismo es de lazo abierto o cerrado ?

61 Referencias [Jac88] V. Jacobson, Congestion Avoidance and Control. Proceedings of ACM SIGCOMM '88, Aug [MSM+97] M. Mathis, J. Semke, J. Mahdavi, T. Ott, “The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm”, ACM Computer Communication Review, Volume: 27, Issue: 3, July 1997 [APS99]: Allman, M., Paxson, V., Stevens, W.: TCP Congestion Control. RFC 2581 Abril 1999. [Nag87]: Nagle,J: On packet Switches with Infinite Storage. IEEE vol Com-35. Abril 1987 ( RFC 970 – December 1985) [FJ93] Sally Floyd, Van Jacobson Random early detection gateways for congestion avoidance IEEE/ACM Transactions on Networking (TON),  August 1993