Congestion 2C2011

Descargar como ppt, pdf o txt
Descargar como ppt, pdf o txt
Está en la página 1de 61

Control de Congestin

Claudio Enrique Righetti

Teora de las Comunicaciones


Departamento de Computacin
Facultad de Ciencias Exactas y Naturales
UBA

Curso 2 C 2011

1
Bibliografa Bsica

Peterson, L., Davie, B.: Computer Networks: A Systems


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

2
Introduccin

1 Parte

3
Administracin de Buffers

Agregacin 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
Que hacer ??

Sobredimensionamiento (Overprovisioning)
Disear .
Controlar , Evitar ..

5
Soluciones

La 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 ;-)

6
Retardo de una COLA M/M/1
Media de
R = ancho de banda del enlace retardo de cola
(bps).
L = longitud del paquete (bits).
a = media de tasa de llegada
del paquete.

Intensidad de trfico = La/R

La/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!
7
One way delay

8
Antecedentes [1]

Dispositivo control presin en una


Mquina de vapor

[1] de la presentacion de Van Jacobson Notes on Using Red for queue management
and Congestion Avoidance Junio 1998
9
Fundamentos del control de la congestin

Congestin:
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!

10
Consideraciones sobre los nodos

De no expresarse lo contrario se asume que :

1. FIFO el primer paquete que llega se transmite


2. Cuando se llena la cola se descarta , drop tail
3. FIFO es un mecanismo de scheduling , drop tail es
una poltica
4. Introducen sincronizacin global cuando los paquetes
son descartados desde diversas conexiones
11
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.

12
Congestion vs. Flow Control

Los 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 routers
Flow control : controla trfico point-to-point entre un
receptor y un transmisor (supercomputadora - PC
sobre fibra)

13
Mtricas

Varias mtricas podra usar para detectar congestin


% 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

14
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

15
Causas

Inundo 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
ruteo
Partes del Sistema ( varias lneas rpidas y una
lenta )
Congestin tiene a realimentarse y empeorar

16
Consideraciones
Control 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 moneda
Pre-asignar recursos (ancho de banda y espacio de buffers en
routers y switches) para evitar la congestin
Controlar la congestin si ocurre (y cuando ocurra)

Router Destination
1.5-Mbps T1 link

Source
2

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.
17
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 implementacin


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.
mltiples calidades de servicio QoS . Por ejemplo ancho de
banda (para video streaming bajo) y retardo (para Voz sobre
IP VoIP).

18
Marco de trabajo
En 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/destino
mantenemos soft-state en el router
Source
1
Router Destination
1
Router
Source
2
Router
Destination
2
Source
3
Taxonoma
Centrado en router versus centrado en los hosts
basados en reservacin versus los basados en
realimentacin
basados en ventanas versus los basados en tasa de
transferencia
19
Criterios de Evaluacin (1)
La idea es que la red sea utilizada eficientemente y al
mismo tiempo en forma equitativa
Buen indicador para eficiencia: Potencia =throughput /
retardo
Throughput/delay

Paquetes que saturan


capacidad y colas
crecen, crece retardo

Optimal Load
load
Muy conservativo:
Subutilizacin de recursos
20
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 f1

f ( x , x ,..., x )

n
x
i 1 i
2

n x
1 2 n n 2
i 1 i

21
Performance de la red en funcin de la carga

Knee Cliff Knee Cliff

Throughput Tiempo de
Respuesta

Carga Carga

22
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.

23
Congestin y Calidad de Servicio

Sera 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).

24
Efectos de la congestin en el tiempo de servicio y el
rendimiento

Aqu QoS!!

Sin Congestin Congestin Sin Congestin Congestin


Tiempo de Servicio

Congestin Moderada Fuerte Congestin Moderada Fuerte

Carga Rendimiento Carga

QoS intil QoS til QoS inviable QoS intil QoS til QoS inviable
y viable y viable

Por efecto de retransmisiones 25


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)

26
Calidad de Servicio en Internet

La 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

27
Resumiendo

Se 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.
28
Agenda ( 2 Parte)

Control de Congestion ( cont.) Taxonomia Lazo


Cerrado-Abierto
RED
FRED ( optativo)

29
Taxonomia

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.

30
Taxonomia [YR95]

Control Congestin

Lazo Abierto Lazo Cerrado


principalmente en redes Usado principalmente en redes de paquetes
conmutacion de circutos Usa informacion de realimentacin : global &
(GMPLS) local

Realimentacin Implcita Realimentacin Explicita


End-to-end congestion control Network-assisted congestion control
EJ: Ej:
TCP Tahoe, TCP Reno, TCP Vegas, IBM SNA, DECbit, ATM ABR, ICMP
etc. source quench,, ECN

31
Congestion Control and Avoidance

congestion control : reactivo

congestion avoidance : proactivo

32
Feedback Implcito vs. Explicito

Implicit feedback Congestion Control


La red dropea paquetes cuando ocurre la congestin
La fuente infiere la congestin en forma implcita
time-out, ACKs duplicados, etc.

Ej. : CC end-to-end TCP


Implementacin relativamente simple , eficiente ?
Normalmente Implementada a nivel de transporte (Ej.., TCP, SCTP )

33
Feedback Implcito vs. Explicito (cont.)

Explicit feedback Congestion Control


Componentes de red (Ej., router, sw ) proveen indicacin
explicita de la congestin 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 implementacin
Se necesitan cambiar fuente y algoritmo de red
Es necesaria cooperacin entre fuentes y Componentes
de red

34
RED

35
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).

36
Deteccin aleatoria temprana (Random Early
Detection, RED)
Notificacin es implcita
solo descarta el paquete (en TCP habr timeout)
podra hacerse explcita 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 algn nivel de descarte

37
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

AvgLen

38
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

39
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 umbrales
Curva de probabilidad de descarte

P(drop)

1.0

MaxP
AvgLen
MinThresh MaxThresh

40
Sintona 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 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

41
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 presentacin de Cisco sobre QoS 42


FRED

43
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.

44
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

45
FRED

FRED 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 paquete
Debe mirar la fuente del paquete y las direcciones de destino, los puertos, y la
identificacin del protocolo de cada paquete

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

47
Traffic Shaping

El 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
predecible
Se 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

48
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
Thats the idea behind the leaky bucket algorithm

49
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
vaco

=> Se moderan las rfagas 50


Implementacin

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 tamaos , 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)

51
Algoritmo: Token Bucket

Leaky 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
segundos
Para transmitir, se necesita consumir un token. Si no hay ,
se espera
Hosts Idle pueden ahorrar permisos para enviar bursts
luego

52
Token Bucket

53
Policing Mechanisms

En definitiva Token Bucket permite un Burst Size y


Average Rate.

54
Sincronizacin Global

Utilizacin
100%
de la Cola

Tiempo

Tail Drop

3 Flujos de Trfico Otro Flujo


comienzan a distintos comienza en este
tiempos. instante
55
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.

56
Ejercicios

57
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)?

58
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 .,

59
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 ?
Optimal Dicho mecanismo es de lazo
Load
load abierto o cerrado ?

60
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

61

También podría gustarte