*Control de CongestinClaudio Enrique Righetti

Teora de las Comunicaciones Departamento de ComputacinFacultad de Ciencias Exactas y Naturales UBA

Curso 2 C 2011

*Bibliografa BsicaPeterson, L., Davie, B.: Computer Networks: A Systems Approach. Third Edition, The Morgan Kaufmann Series in Networking, David Clark, Series Editor, 2003 . Cap 6Andrew S. Tanenbaum : Computer Networks, Fourth Edition , Prentice Hall, 2003. Cap 5.3Jim Kurose, Keith Ross Redes de computadores: un enfoque descendente basado en Internet, 2 edicin. 2002

*Introduccin1 Parte

AgregacinDiferentes 10 Mbps1000 MbpsLAN a WAN10 Mbps64 KbpsAdministracin de Buffers

Tendencia a llenarse de los buffers (TCP windowing)Buffering reduce Loss, introduce DelayOverflow de buffers => se descartan paquetes (o frames)Para garantizar QoS se deben prealocar y reservar

*Que hacer ??Sobredimensionamiento (Overprovisioning)Disear .Controlar , Evitar ..

*SolucionesLa presencia de congestin 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 ;-)

*Retardo de una COLA M/M/1R = ancho de banda del enlace (bps).L = longitud del paquete (bits).a = media de tasa de llegada del paquete.Intensidad de trfico = La/RLa/R ~ 0: media de retardo de cola pequeo.La/R -> 1: aumentan los retardos.La/R > 1: Llega ms trabajo del que puede servirse, media de retardo infinita!Media de retardo de cola

*One way delay

*Antecedentes [1][1] de la presentacion de Van Jacobson Notes on Using Red for queue management and Congestion Avoidance Junio 1998Dispositivo control presin en unaMquina de vapor

*Fundamentos del control de la congestinCongestin:Informalmente: demasiadas fuentes enviando demasiados datos demasiado de prisa por la red como para poder manejarlo.Diferente del control de flujo!Manifestaciones:Prdida 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!

*Consideraciones sobre los nodosDe no expresarse lo contrario se asume que :

FIFO el primer paquete que llega se transmite Cuando se llena la cola se descarta , drop tailFIFO es un mecanismo de scheduling , drop tail es una poltica Introducen sincronizacin global cuando los paquetes son descartados desde diversas conexiones

*Congestin Estado sostenido de sobrecarga de una red donde la demanda de recursos (enlaces y buffers) se encuentra al lmite o excede la capacidad de los mismos.

*Congestion vs. Flow ControlLos mecanismos de control de la Congestin deberan poder evaluar la capacidad de la subnet para transportar determinado trfico.Congestin es una cuestin global involucra todos los hosts y routersFlow control : controla trfico point-to-point entre un receptor y un transmisor (supercomputadora - PC sobre fibra)

*MtricasVarias mtricas podra usar para detectar congestin % de paquetes descartados por falta de espacio en bufferLongitud media de una cola ( buffer) # paquetes que generan time out y son RTXaverage packet delaystandard deviation of packet delayEn todos los casos el crecimiento de alguna de esta metricas indican congestion

*Politicas que influyen en la congestion

Layer

Policies

Transport

Retransmission policy

Out-of-order caching policy

Acknowledgement policy

Flow control policy

Timeout determination

Network

Virtual circuits versus datagram inside the subnet

Packet queueing and service policy

Packet discard policy

Routing Algorithm

Packet lifetime management

Data Link

Retransmission policy

Out-of-order caching policy

Acknowledgement policy

Flow control policy

*CausasInundo con trafico destinado a una misma lnea de salida (la cola se llena tail drop )Mas Memoria no necesariamente resuelve el problema Procesadores lentos, o problemas con software de ruteoPartes del Sistema ( varias lneas rpidas y una lenta ) Congestin tiene a realimentarse y empeorar

*ConsideracionesControl de Congestin: 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 monedaPre-asignar recursos (ancho de banda y espacio de buffers en routers y switches) para evitar la congestinControlar la congestin 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.

*Consideraciones (cont)Control de flujo v/s control de congestin: 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 implementacinmaquinas 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 inferioresbest-effort o mejor esfuerzo (lo asumimos por ahora). Es el servicio de Internet.mltiples calidades de servicio QoS . Por ejemplo ancho de banda (para video streaming bajo) y retardo (para Voz sobre IP VoIP).

*Marco de trabajoEn redes orientadas a conexin. Se reserva ancho de banda y espacio al establecer la conexin. => Subutilizacin de recursos. Flujos de datos en redes sin conexin (datagramas : Internet)secuencia de paquetes enviados entre el par fuente/destinomantenemos soft-state en el router

TaxonomaCentrado en router versus centrado en los hostsbasados en reservacin versus los basados en realimentacinbasados en ventanas versus los basados en tasa de transferencia

*Criterios de Evaluacin (1)La idea es que la red sea utilizada eficientemente y al mismo tiempo en forma equitativaBuen indicador para eficiencia: Potencia =throughput / retardoMuy conservativo: Subutilizacin de recursosPaquetes que saturan capacidad y colas crecen, crece retardo

*Criterios de Evaluacin (2)Equidad: los recursos sean compartidos equitativamente.Indicador de equidad de Jain: Dados n flujos por un enlace (x1, x2, ...xn)

0 f 1

*Performance de la red en funcin de la carga

*Performance de la red en funcin 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 prdida de paquetes. Incrementos en la carga ms all de este punto incrementa la probabilidad de prdida 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 congestin. Este punto es conocido como el cliff debido a la extrema cada en el throughput.

*Congestin y Calidad de ServicioSera muy fcil dar Calidad de Servicio si las redes nunca se congestionaran. Para ello habra que sobredimensionar todos los enlaces, cosa no siempre posible o deseable.Para dar QoS con congestin es preciso tener mecanismos que permitan dar un trato distinto al trfico preferente y cumplir el SLA (Service Level Agreement).El SLA suele ser esttico y definido en el momento de negociacin del contrato con el proveedor de servicio o ISP (Internet Service Provider).

*CargaRendimientoSinCongestinCongestinFuerteCongestinModeradaEfectos de la congestin en el tiempo de servicio y el rendimientoSinCongestinCongestinFuerteCongestinModeradaTiempo de ServicioCargaQoS til y viableQoS intilQoS inviableQoS til y viableQoS intilQoS inviablePor efecto de retransmisionesAqu QoS!!

*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 parmetros que definen la calidad de servicio que ofrece la red. Si el proveedor no se compromete en ningn parmetro decimos que lo que ofrece un servicio best effort.El contrato que especifica los parmetros de QoS acordados entre el proveedor y el usuario (cliente) se denomina SLA (Service Level Agreement)

*Calidad de Servicio en InternetLa congestin y la falta de QoS es el principal problema de Internet actualmente.TCP/IP fue diseado 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

*ResumiendoSe utiliza el trmino control de congestin 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 congestin es generalmente un mal sntoma. Por lo cual, es conveniente tomar medidas preventivas, y no correctivas cuando ya el problema fue detectado. Una de las posibles soluciones sera simplemente persuadir a unos pocos hosts que disminuyan el flujo de trfico generado, con una consecuente mejora en la situacin del resto de los hosts. Sin embargo, esto lleva a enviar mensajes de sealizacin a algunos pocos hosts, en vez tratar de distribuirla en forma mas equitativa; obligando as a los mecanismos de control de congestin a poseer una nocin de alocacin de recursos dentro de ellos.

*Agenda ( 2 Parte)Control de Congestion ( cont.) Taxonomia Lazo Cerrado-AbiertoREDFRED ( optativo)

*TaxonomiaDe acuerdo a la taxonoma de Yang y Reddy (1995), los algoritmos de control de congestin 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 realimentacin.

*Taxonomia [YR95] Control CongestinLazo Abierto principalmente en redes conmutacion de circutos (GMPLS)Lazo Cerrado Usado principalmente en redes de paquetes Usa informacion de realimentacin : global & localRealimentacin Implcita End-to-end congestion control EJ:TCP Tahoe, TCP Reno, TCP Vegas, etc.Realimentacin Explicita Network-assisted congestion control Ej:IBM SNA, DECbit, ATM ABR, ICMP source quench,, ECN

*Congestion Control and Avoidancecongestion control : reactivo

congestion avoidance : proactivo

*Feedback Implcito vs. ExplicitoImplicit feedback Congestion ControlLa red dropea paquetes cuando ocurre la congestinLa fuente infiere la congestin en forma implcitatime-out, ACKs duplicados, etc.

Ej. : CC end-to-end TCP Implementacin relativamente simple , eficiente ? Normalmente Implementada a nivel de transporte (Ej.., TCP, SCTP )

*Feedback Implcito vs. Explicito (cont.)Explicit feedback Congestion Control Componentes de red (Ej., router, sw ) proveen indicacin explicita de la congestin a las fuentesusa packet marking, o celdas RM (en ATM ABR control)Ej. DECbit, ECN, ATM ABR CC, etc.Provee informacion mas precisa a las fuentesMas complicada la implementacinSe necesitan cambiar fuente y algoritmo de red Es necesaria cooperacin entre fuentes y Componentes de red

*RED

*RED El algoritmo RED se tiene por objetivo evitar la congestin y de mantener el tamao medio de las colas en niveles bajos.

RED no necesita que los routers mantengan ninguna informacin del estado de las conexiones.

RED fue diseado para trabajar en la colaboracin con un protocolo del control de la congestin de la capa de transporte (TCP, SCTP).

*Deteccin aleatoria temprana (Random Early Detection, RED)Notificacin es implcitasolo descarta el paquete (en TCP habr timeout)podra hacerse explcita marcando el paqueteDescarte aleatorio tempranoen 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 algn nivel de descarte

*Detalles de REDCalcula largo de cola promedioAvgLen = (1 - Weight) * AvgLen + Weight * SampleLen0 < Weight < 1 (usualmente 0.002)SampleLen es el largo de la cola cada vez que un paquete llega

*Detalles RED (cont)Dos umbrales de largo de cola

if AvgLen

*Detalles RED (cont)Computo de probabilidad P

TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold)P = TempP/(1 - count * TempP)

Count cuneta el nmero de paquetes encolados mientras el AvgLen est entre los dos umbralesCurva de probabilidad de descarte

*Sintona en REDProbabilidad de descartar un flujo particular de paquetes es aproximadamente proporcional a parte del ancho de banda que el flujo est obteniendo

MaxP es tpicamente fijada en 0.02, es decir cuando el tamao promedio de la cola es la mitad entre los dos umbrales, el gateway descarta +o- uno de cada 50 paquetes.

Si el trfico es rafagoso, entonces MinThreshold debera ser suficientemente grande para permitir que la utilizacin del enlace sea mantenida a un nivel aceptablemente alto

Diferencia entre los dos umbrales debera ser ms grande que el incremento tpico en el largo de cola promedio calculado en un RTT; fijar MaxThreshold a dos veces MinThreshold es razonable para el trfico de hoy en Internet

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

*FRED

*Flow Random Early Detection (FRED)Una de las caractersticas ms importantes RED es el hecho de que proporciona imparcialidad descartando los paquetes de una conexin segn 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 conexin 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.

*Flow Random Early Detection (FRED)Control de usuarios mal comportados ( bandwith hugs)Aunque se hace cumplir el umbral mximo, si el usuario no disminuye su tasa, RED no tiene ningn mecanismo para proteger a otros usuarios. Los usuarios mal comportados podran terminar ocupando la totalidad del ancho de banda

*FREDFRED soluciona estos problemas de imparcialidad manteniendo umbrales y ocupaciones del buffer para cada flujo activo (informacin por conexin).

FRED necesita guardar informacin por cada flujo para descartar paquetes produciendo un alto costo de operacin en los routers

FRED debe identificar cada flujo que tenga paquetes en el buffer y actualizar la informacin por cada paqueteDebe mirar la fuente del paquete y las direcciones de destino, los puertos, y la identificacin del protocolo de cada paquete

*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 PeakBurst Size: nmero mximo de paquetes enviados consecutivamente ( en un periodo corto de tiempo)

*Traffic ShapingEl trafico es bursty ( con rfagas) impacta en la congestin.Traffic shaping es un mtodo de lazo abierto que trata de guiar la congestin , forzando a los paquetes a trasnmitirse a uan velocidad mas predecibleSe trata de mantener el trafico constante , es decir regular la tasa de transmisin 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

*Algoritmo Leaky BucketBasicamente se buscar proveer un we want to do is to provide a consistent, even flow of trafficThink 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 constantThats the idea behind the leaky bucket algorithm

*Algoritmo Leaky Bucket ( idea )El flujo de salida tiene una velocidad constante , cuando hay agua en el balde, y cero cuando esta vacoFlujo de paquetes sin regular=> Se moderan las rfagas

*ImplementacinEl 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 tamaos , es mejor usar un numero fijo de bytes por tick, antes que uno por paqueteCola llena, los paquetes que llega son descartados ( tail drop)

*Algoritmo: Token BucketLeaky bucket fuerza un patrn de trafico de salida rgido ( tasa promedio)Token bucket permite picos de trfico ( aumentar la velocidad , durante un intervalo pequeo) cuando le llega una rfaga grande de paquetes

Aca los baldes (buckets) mantienen fichas (tokens), que son generadas por un clock a un rate de un token cada T segundosPara transmitir, se necesita consumir un token. Si no hay , se esperaHosts Idle pueden ahorrar permisos para enviar bursts luego

*Token Bucket

*Policing MechanismsEn definitiva Token Bucket permite un Burst Size y Average Rate.

*Sincronizacin GlobalTiempoUtilizacin de la Cola100%Tail Drop3 Flujos de Trfico comienzan a distintos tiempos.Otro Flujo comienza en este instante

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.

*

*Ejercicios

*Ej (1) De acuerdo a la taxonoma de Yang y Reddy (1995), los algoritmos de control de congestin 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 realimentacin. A que categoria pertenece RED (Randomly Early Detection)?

*Ej (2)Algunos autores utilizan la relacin que denominan Potencia ( P= Throughput/delay ) como una mtrica para medir la eficiencia de un esquema de alocacin de recursos . Para un flujo de paquetes que ingresa a un router de una red de conmutacin de paquetes , la variacin de la potencia en funcin de la carga ( paquetes/seg. ) es la siguiente[1] :

[1] En realidad la teora subyacente en la definicin de potencia esta basada en la teora clsica de colas en este caso particular un router con una entrada y una salida , se modela como una cola M/M/1 , esta notacin ( 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 .,

*Ej.(2 cont.)a) En que zona de la funcion Potencia se presenta el fenmeno de congestin , que significa la congestin en redes de conmutacin de paquetes ?b) Cuales son dos soluciones posibles para evitar entrar en congestin ?

c) una de las causas de la congestin es cuando el trafico se presenta en rfagas , 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 ?

*Referencias[Jac88] V. Jacobson, Congestion Avoidance and Control. Proceedings of ACM SIGCOMM '88, Aug. 1988.[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

*****************Alocacin de recursos y control de congestin 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 estn aislados a un nico nivel del modelo de arquitectura de redes[2].La alocacin 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 informacin acerca de la disponibilidad de los mismos.Entendemos por alocacin 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 podran 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 congestin en 1984 [RFC 896], y en una primera aproximacin propone un mecanismo centrado en los routers. Durante 1986 y 1987 se producen varios fenmenos de congestin, y quienes mantenan el Backbone, BBN, proponen como una solucin parcial aumentar el ancho de banda de los enlaces. Finalmente Jacobson y Karels intenta mitigar el problema de congestin introduciendo los algoritmos de control de congestin detallados en [Jac1988].[2] En [Tan1996] se detalla como afectan a la congestin las polticas de los protocolos de nivel 2, 3 y 4.[3] En realidad alocar recursos, es realizar un reservacin de los mismos. Dicha reservacin plantea una Paradoja de Reservacin: cuando se reserva no se permite que otro interesado acceda a dicho recurso (una analoga de la vida real sucede cuando se reserva la mesa en un restaurante, la misma puede permanecer vaca 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 )

********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 informacin que crean 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 congestin moderada en la grfica) las aplicaciones que lo requieran podrn 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 congestin los mecanismos de Calidad de Servicio difcilmente sern capaces de asegurar el nivel de calidad pedido a las aplicaciones que as lo requieran.***********************************