to get the file - OCW - Universidad de Murcia

1908 – Arquitectura de Redes
Tema 5. Control de Tráfico y
Control de Congesión
Pedro M. Ruiz
<[email protected]>
Francisco J. Ros
<[email protected]>
3º Grado en Ingeniería Informática – 2011/2012
Organización del tema
Introducción al control de congestión en el nivel de
red
Control de admisión y contrato de tráfico
Control de congestión en Frame Relay
Control de congestión en ATM
Control de congestión en Internet
Arquitectura de Redes - Universidad de Murcia
2
Organización del tema
Introducción al control de congestión en el nivel de
red
Control de admisión y contrato de tráfico
Control de congestión en Frame Relay
Control de congestión en ATM
Control de congestión en Internet
Arquitectura de Redes - Universidad de Murcia
3
Congestión
En el tema anterior estudiamos el problema de la
congestión y cómo lo gestiona TCP a nivel de
transporte
En este tema abordamos el mismo problema
desde el punto de vista del nivel de red
– Redes de Circuitos Virtuales
– Redes de Datagramas
Arquitectura de Redes - Universidad de Murcia
4
Mecanismos para tratar la Congestión
Mecanismos de prevención y/o control
–
–
–
–
–
Back pressure (retrocontención)
Choke packet (paquete de boqueo)
Señalización implícita
Señalización explícita
Policing
Arquitectura de Redes - Universidad de Murcia
5
Control de Congestión
Retrocontención
El nodo congestionado avisa al nodo previo (previous hop)
para que reduzca o detenga el flujo de datos que le envía
El nodo previo puede sufrir entonces congestión porque
debe retener los paquetes en el buffer durante más tiempo
El nodo previo repite entonces el proceso, hasta llegar
salto a salto a la fuente de los datos
Uso
– Poco útil
– Se puede utilizar en redes de circuitos virtuales X.25, pero no se
usa en Frame Relay ni ATM
– No se suele usar en redes de datagramas como TCP/IP
Arquitectura de Redes - Universidad de Murcia
6
Control de Congestión
Paquete de Bloqueo
Paquete de control que envía un nodo congestionado a
una fuente de datos
La fuente puede reducir o detener el flujo
Uso
– Solución poco sofisticada
– Se usa en redes de datagramas TCP/IP: ICMP Source Quench
Nodo congestionado envía un Source Quench a la fuente por cada
datagrama descartado debido a que el buffer está lleno.
Adicionalmente, un nodo puede enviar un Source Quench cuando el
buffer se aproxima a su capacidad máxima, para tratar de anticiparse a
la congestión y evitarla.
La fuente reduce la emisión para el destino indicado en el Source
Quench.
Arquitectura de Redes - Universidad de Murcia
7
Control de Congestión
Señalización Implícita
Se deduce que la red está congestionada cuando
– aumenta el retardo de la misma
– se descartan paquetes
Cuando las fuentes detectan que la red está congestionada
reducen su flujo de datos
Uso
– Se usa en redes de datagramas TCP/IP a nivel de transporte (TCP)
– En redes de circuitos virtuales, el protocolo de Control LAPF de
Frame Relay proporciona una funcionalidad similar
Arquitectura de Redes - Universidad de Murcia
8
Control de Congestión
Señalización Explícita
El nodo de red congestionado avisa a los sistemas finales
mediante marcado de bits de control o con mensajes de
control.
– Hacia atrás (backward): se notifica a la fuente de datos.
– Hacia delante (forward): se notifica al destino de datos, que a su
vez informa a la fuente a través del propio nivel de red o el de
transporte.
Uso
– Se usa en redes de circuitos virtuales (Frame Relay, ATM) y de
datagramas (Internet).
Arquitectura de Redes - Universidad de Murcia
9
Medidas ante Congestión
Reducir o detener el flujo de datos:
– En las fuentes, principalmente.
– En los routers intermedios, ocasionalmente.
Descartar paquetes de forma inteligente
– Existen paquetes “de primera” y “de segunda”, de forma
que se deben descartar primero aquellos que se han
marcado para ello.
– Si se descarta un fragmento/trama/celda de un paquete,
descartar también el resto de fragmentos.
Arquitectura de Redes - Universidad de Murcia
10
Organización del tema
Introducción al control de congestión en el nivel de
red
Control de admisión y contrato de tráfico
Control de congestión en Frame Relay
Control de congestión en ATM
Control de congestión en Internet
Arquitectura de Redes - Universidad de Murcia
11
Control de Admisión
Usuario: Quiero
enviar tráfico de
este tipo y quiero
esta QoS…
Red: ¿Puedo soportar
esto de forma fiable
sin perjudicar otros
contratos?
Solicitud de QoS garantizada
No o Sí, pactar un
contrato de tráfico
Host
Red
Si se supera el control de admisión, la red
y el usuario pactan un contrato de tráfico
Arquitectura de Redes - Universidad de Murcia
12
Contrato de Tráfico
Cliente y proveedor acuerdan un contrato
– SLA (Service Level Agreement)
– Tasa de datos promedio, tráfico a ráfagas
Funciones
– Traffic shaping
Perfil de tráfico, conformado de tráfico
Condiciones máximas de uso de la red que el usuario se compromete a cumplir
con el proveedor del servicio
– Traffic policing
Vigilancia de tráfico
Monitorización que realiza el proveedor para asegurarse de que el usuario
cumple el contrato
Si el usuario incumple el contrato, el proveedor puede
– Descartar el tráfico no conforme con el contrato
– Marcar ese tráfico como descartable (paquetes “de segunda”)
– Pasar normalmente el tráfico a la red, lo que no es habitual
Arquitectura de Redes - Universidad de Murcia
13
Cubo Agujereado
El Algoritmo de Cubo Agujereado (Leaky Bucket) se
utiliza para:
– Traffic shaping: Suavizar las ráfagas según lo acordado en el
contrato.
– Traffic policing: Asegurar que el tráfico introducido es el acordado.
El usuario dispone de:
– Un buffer de capacidad C (tamaño del cubo) que absorbe las
ráfagas de datos producidas por el usuario.
– Un caudal constante ρ (tamaño del agujero del cubo) que indica la
velocidad a la que se inyecta tráfico en la red.
Si el cubo se llena, tráfico excedente es no conforme:
– Se descarta, o
– Se marca como descartable (paquetes “de segunda”).
Arquitectura de Redes - Universidad de Murcia
14
Cubo Agujereado
C (Mb)
ρ (Kb/s)
Arquitectura de Redes - Universidad de Murcia
15
Cubo Agujereado
Ejemplo
Ráfaga de 10 Mb recibida en 50 ms
ρ = 20 Mbps
Instante
Entrado
C = 10 Mb
Salido
En Cubo
0 ms
0
0
0
10 ms
2 Mb
0,2 Mb
1,8 Mb
20 ms
4 Mb
0,4 Mb
3,6 Mb
30 ms
6 Mb
0,6 Mb
5,4 Mb
40 ms
8 Mb
0,8 Mb
7,2 Mb
50 ms
10 Mb
1,0 Mb
9 Mb
60 ms
10 Mb
1,2 Mb
8,8 Mb
70 ms
10 Mb
1,4 Mb
8,6 Mb
80 ms
10 Mb
1,6 Mb
8,4 Mb
10 Mb
10 Mb
0 Mb
Máximo
...
500 ms
Arquitectura de Redes - Universidad de Murcia
16
Cubo con Créditos
Leaky bucket es muy rígido
– El tráfico sale a la red a una tasa promedio constante. Si llegan
ráfagas grandes, podría ser conveniente acelerar la salida a la red.
– No se fomenta el “ahorro”, puesto que hosts que transmiten mucho
reciben el mismo servicio que los que transmiten poco.
Algoritmo de Cubo con Créditos (Token Bucket)
– El cubo contiene una capacidad C de tokens (en vez de datos)
– Los tokens se generan a un ritmo constante de ρ bps
– Los tokens permiten enviar su equivalente en datos
Arquitectura de Redes - Universidad de Murcia
17
Cubo con Créditos
Token Bucket vs Leaky Bucket
Diferencias con leaky bucket
– Permite ráfagas de hasta el número de tokens acumulados
– Fomenta el ahorro: host inactivo acumula tokens hasta poder enviar
una ráfaga de C bits
– No descarta datos, sólo descarta tokens si el cubo se llena
Semejanza con leaky bucket
– Si no hay tokens acumulados, funciona como un leaky bucket de
tamaño C y caudal ρ
Arquitectura de Redes - Universidad de Murcia
18
Cubo con Créditos
Ráfagas
Uso de token bucket
– Permite ráfagas limitadas a una duración S determinada
– Las ráfagas se envían a la tasa máxima M bps
– Como máximo, una ráfaga de salida tiene C +ρS bits
C bits si el cubo está lleno de tokens
ρS bits por los tokens que se generan mientras se envía la ráfaga
– Como máximo, una ráfaga de salida tiene MS bits
– Por tanto: C +ρS = MS S = C/(M - ρ).
Token bucket permite ráfagas de M bps. Si queremos un
tráfico más uniforme: token bucket que alimenta a un leaky
bucket de mayor caudal
– ρtoken_bucket < ρleaky_bucket < M
Arquitectura de Redes - Universidad de Murcia
19
Duración de Ráfagas
Ejercicio
Ráfaga 1MB en 40 ms = 25 MBps.
M = 200 Mbps = 25 MBps.
Salida de leaky bucket con C=1MB y
ρ=2 MBps.
Salida de token bucket lleno con
C=250KB y ρ=2 MBps.
Salida de token bucket lleno con
C=500KB y ρ=2 MBps.
Salida de token bucket lleno con
C=750KB y ρ=2 MBps.
Salida de token bucket lleno con
C=500KB y ρ=2 MBps seguido de
leaky bucket con ρ=10 MBps.
Arquitectura de Redes - Universidad de Murcia
20
Traffic Shaping y Traffic Policing
Datos reales
Switch
Shaper
Host
Datos Conformados
Conformado de Tráfico:
Cumplir el contrato
Leaky bucket y/o token bucket
Limitar tamaño de ráfagas
Limitar retardo y variación del
retardo (jitter)
Arquitectura de Redes - Universidad de Murcia
Vigilancia de Tráfico: Vigilar y
obligar su cumplimiento
¿El tráfico recibido cumple el
contrato?
-
Sí: se deja pasar.
No: se descarta o se marca para ser
descartado.
21
Organización del tema
Introducción al control de congestión en el nivel de
red
Control de admisión y contrato de tráfico
Control de congestión en Frame Relay
Control de congestión en ATM
Control de congestión en Internet
Arquitectura de Redes - Universidad de Murcia
22
Frame Relay
Ideas Generales
Frame Relay es una tecnología de red de conmutación de
paquetes basada en circuitos virtuales (CV)
– Más simple que su predecesor X.25 para soportar mayores tasas
de bits
– Define el nivel físico y el de enlace (protocolo LAPF)
– Usado en redes WAN
Usa CV de control para establecer “llamadas” (CV de
datos)
– Control de admisión y contrato de tráfico
Los datos se transportan en tramas de longitud variable
– Servicio de transmisión ordenada de tramas
– Núcleo LAPF (obligatorio) y Control LAPF (opcional)proporcionan
funciones de control de congestión
Arquitectura de Redes - Universidad de Murcia
23
Contrato de Tráfico
Parámetros del contrato entre usuario y red
– CIR = Bc / Tc
EIR = Be / Tc
CIR (Commited Information Rate): ancho de banda que la red se compromete a
soportar para un CV.
Bc (Commited Burst): tamaño de ráfaga que la red se compromete a soportar
durante el intervalo de medición Tc.
EIR (Excess Information Rate): ancho de banda en exceso del CIR que la red
intentará soportar para un CV.
Be (Excess Burst): tamaño máximo de bits en exceso del Bc que la red intentará
soportar durante Tc.
(CIR + EIR)
Arquitectura de Redes - Universidad de Murcia
24
Control de Tráfico
Se implemena con dos leaky buckets
– C1 = Bc, ρ1 = CIR
– C2 = Be, ρ2 = EIR
Las tramas que se desbordan del primer cubo se marcan
como descartables
– Bit DE (Discard Eligible) = 1
Las tramas que se desbordan del segundo cubo se
descartan
Arquitectura de Redes - Universidad de Murcia
25
Control de Tráfico
Tramas enviadas por
el usuario con DE=0
Tramas enviadas por
el usuario con DE=1
Bc
Be
CIR
Tramas descartadas
DE=0
EIR
DE=1
Arquitectura de Redes - Universidad de Murcia
26
Control de Tráfico
Arquitectura de Redes - Universidad de Murcia
27
Control de Tráfico
Ejemplo
PVC
CIR 1024 Kb/s
EIR 384 Kb/s
Traffic Policing
Switch
FR
Switch
FR
Traffic Shaping
Switch
FR
Línea de acceso
2048 Kb/s
PVC
CIR 1024 Kb/s
EIR 384 Kb/s
Arquitectura de Redes - Universidad de Murcia
28
Control de Tráfico
Ejemplo
Línea de acceso: 2048 Kbps
CIR = 1024 Kbps, EIR = 384 Kbps, Tc = 1 seg
Bc = 1.024.000 bits, Be =384.000 bits
Tramas fijas de 50.000 bits (flujo de vídeo)
–
–
–
–
Caso 1: 40 tramas/seg (2.000 Kbps) sostenido
Caso 2: 28 tramas/seg (1.400 Kbps) sostenido
Caso 3: 20 tramas/seg (1.000 Kbps) sostenido
Caso 4: ráfaga de 40 tramas precedida y seguida de un segundo
sin tráfico
Arquitectura de Redes - Universidad de Murcia
29
Control de Tráfico
Ejemplo
Caso
Tramas
enviadas
por seg.
Tramas con
DE=0 por
seg.
1
40
20
8
12
2
28
20
8
0
3
20
20
0
0
Arquitectura de Redes - Universidad de Murcia
Tramas con
Tramas
DE=1 por descartadas
seg.
por seg.
30
Caso 4:
Ráfaga de
40 tramas
en 1 seg.
Fin de la
ráfaga
Tiempo
(ms)
Tramas
entradas
Tramas
salidas CIR
Tramas
en
cubo CIR
0
0
0
0
25
1
0
1
50
2
0
2
73,2
2
1
1
75
3
1
2
97,6
3
1
2
100
4
1
3
122
4
2
2
......
......
......
927,2
37
18
19
950
38
18
20
951,6
38
19
19
975
39
19
20
976
39
19
20
1000
40
19
21
1000,4
40
20
20
1049,2
40
21
19
Arquitectura de Redes - Universidad de Murcia
Cubo
desbordado
en una trama
32
Control de Tráfico
Ejemplo
Funcionamiento del poz al agujereado
Ráfaga de 40 tramas
45
40
35
21 tramas
en el cubo
Tram
as
30
25
Serie1
Entrada
Serie3
Salida
20
15
10
1928
1781
1635
1488
1342
1196
1049
900
750
600
450
300
150
0
0
5
Milise gundos
Arquitectura de Redes - Universidad de Murcia
34
Control de Congestión
Detección de congestión
– Los switches Frame Relay monitorizan la ocupación de sus
buffers (longitud de las colas).
Evitar congestión
– Se descartan las tramas con bit DE=1.
– Se notifica a los sistemas finales para que reduzcan su
velocidad de transmisión. Notificaciones explícitas (Núcleo
LAPF) y/o implícitas (Control LAPF).
Notificación explícita de congestión
– Hacia atrás: Backward Explicit Congestion Notification (BECN).
– Hacia delante: Forward Explicit Congestion Notification (FECN).
Notificación implícita de congestión
– Control de flujo estilo TCP
Arquitectura de Redes - Universidad de Murcia
35
Control de Congestión
Notificación Explícita
Notificación explícita de congestión hacia atrás
– Bit BECN.
– Lo activa el switch Frame Relay que está sufriendo congestión
en las tramas que viajan hacia la fuente.
– Fuente disminuye velocidad hasta que deja de recibir tramas
con bit BECN=1.
Notificación explícita de congestión hacia delante
– Bit FECN.
– Lo activa el switch Frame Relay que está sufriendo congestión
en las tramas que viajan hacia el destino.
– Destino debería notificar a la fuente para que reduzca velocidad,
pero dicha función no se incluye en LAPF Se delega en un
protocolo de nivel superior.
Arquitectura de Redes - Universidad de Murcia
36
Control de Congestión
Frame Relay
Switch
FR
Switch
FR
Tráfico
incontrolado
Congestión
Switch
FR
Switch
FR
BECN
FECN
Switch
FR
1. Descartar tramas con bit DE=1.
2. Identificar CVs afectados y sentido.
3. Poner bit FECN=1 en tramas de ida.
4. Poner bit BECN=1 en tramas de vuelta.
Arquitectura de Redes - Universidad de Murcia
37
Organización del tema
Introducción al control de congestión en el nivel de
red
Control de admisión y contrato de tráfico
Control de congestión en Frame Relay
Control de congestión en ATM
Control de congestión en Internet
Arquitectura de Redes - Universidad de Murcia
38
ATM
Ideas Generales
Asynchronous Transfer Mode (ATM) es una tecnología
de red de conmutación de paquetes basada en circuitos
virtuales (CV)
– Permite velocidades mucho mayores que Frame Relay
– Define el nivel físico, de enlace (nivel ATM) y superiores (incluído
nivel de adaptación AAL para transportar IP, IPX, etc)
– Tecnología WAN predominante
CVs de datos o de control
– VCC (Virtual Channel Connection): CV, análogo a Frame Relay.
– VPC (Virtual Path Connection): agrupación de VCCs conmutados a
lo largo de un mismo camino.
Los datos se transportan en celdas de longitud fija
– 53 bytes: 5 de cabecera + 48 de datos
Arquitectura de Redes - Universidad de Murcia
39
ATM
Clases de Servicio
ATM define distintas clases de servicio (categorías)
– Clasificación de los “contratos” más comunes entre el usuario y el
operador.
– Las categorías se caracterizan por medio de una serie de
atributos.
Clases de servicio
– Tiempo real: CBR, rt-VBR
– No tiempo real: nrt-VBR, ABR, UBR, GFR
Atributos ATM:
– Descriptores de tráfico: caracterizan el tráfico de una fuente para
una conexión. Control de Admisión: la red establece el CV si hay
recursos disponibles.
– Parámetros QoS: caracterizan el rendimiento esperado en
términos de Calidad de Servicio (Quality of Service, QoS).
Arquitectura de Redes - Universidad de Murcia
40
Servicio CBR
Constant Bit Rate
Caudal constante y retardo máximo estable
Usado para audio y vídeo de tiempo real sin comprimir
– La mayoría de aplicaciones no usan el ancho de banda máximo que
se reserva, por lo que se desperdicia capacidad del canal
Capacidad
reservada
no aprovechable
Capacidad
del enlace
CBR2
CBR2
CBR1
Arquitectura de Redes - Universidad de Murcia
CBR1
41
Servicio VBR
Variable Bit Rate
Caudal variable (a ráfagas), permitiendo un mejor aprovechamiento del
canal que en CBR
La capacidad se reserva para la conexión, pero se permiten otros flujos si
no se usa el máximo reservado (multiplexación estadística)
Tiempo real rt-VBR
– Aplicaciones sensibles al retardo y jitter
– Usado para audio y vídeo de tiempo real comprimido
No tiempo real nrt-VBR
– Red proporciona QoS respecto a pérdidas y retardo
– Usado en aplicaciones críticas, como transacciones bancarias
Capacidad
del enlace
VBR
VBR
CBR
Arquitectura de Redes - Universidad de Murcia
CBR
42
Servicio UBR
Unspecified Bit Rate
No reserva caudal alguno, servicio de mejor esfuerzo (best effort)
La red no informa a los sistemas finales si hay congestión
Usa el ancho de banda disponible en el canal
– El que no está reservado para CBR ni VBR (si es que queda)
– El que no está utilizando VBR debido a su naturaleza a ráfagas
Usado por servicios típicos TCP/IP
– Algunas aplicaciones no toleran bien la pérdida de celdas
Capacidad excedente
utilizada por UBR
Capacidad
del enlace
VBR
UBR
CBR
VBR
UBR
CBR
Celdas descartadas en caso de congestión
Arquitectura de Redes - Universidad de Murcia
43
Servicio ABR
Available Bit Rate
Mejora el servicio ofrecido por UBR para las aplicaciones a ráfagas
– Garantía de QoS: la red reserva un caudal mínimo, ocasionalmente el flujo
puede usar un mayor ancho de banda
– La capacidad no utilizada por flujos ABR queda disponible para UBR
La red informa a los sistemas finales acerca de la congestión, reduciendo
así la tasa de pérdidas
Usado para tráfico IP que necesite ciertas garantías, como en la
interconexión de redes LAN
Tráfico ABR elástico
VBR
Capacidad
del enlace
ABR
CBR
VBR
ABR
CBR
con garantías
(PCR, MCR, CLR)
La realimentación de la red evita la
congestión y la pérdida de celdas
Arquitectura de Redes - Universidad de Murcia
44
Servicio GFR
Guaranteed Frame Rate
Servicio similar a ABR, pero su especificación es más
sencilla de implantar
– Garantía de QoS como en ABR: la red reserva un caudal mínimo,
ocasionalmente el flujo puede usar un mayor ancho de banda
– Transmite tramas adicionales si la red no está congestionada
Descarte inteligente de celdas
– Si debido a la congestión es necesario descartar una celda, se descartan
también todas aquellas que forman parte del mismo paquete/trama
Usado principalmente en troncales IP
Arquitectura de Redes - Universidad de Murcia
45
Parámetros de Tráfico
PCR: Peak Cell Rate
– Tasa máxima de celdas que
pueden ser entregadas por la
fuente en un VCC
– Obligatorio en CBR y VBR
SCR: Sustainable Cell Rate
MBS: Maximum Burst Size
– Tamaño máximo de ráfaga
– Necesario para VBR
Si las celdas llegan en ráfagas de
MBS celdas, el tiempo entre ráfagas
debe ser tal que la velocidad de
transmisión media < SCR
– Cota superior de la tasa media de
MCR: Minimum Cell Rate
celdas que envía la fuente durante
– Tasa mínima de celdas que se solicita
un periodo de medición
a la red
– Útil si SCR < PCR: permite
– Necesario para ABR y GFR
multiplexar múltiples VCCs
MFS: Maximum Frame Size
– Necesario para VBR
- Tamaño máximo de trama
CDVT: Cell Delay Variation
- Sólo para GFR
Tolerance
– Jitter debido a la fuente: nivel ATM
y medio físico
Arquitectura de Redes - Universidad de Murcia
47
Parámetros de QoS
MaxCTD: Maximum Cell Transfer Delay
– Retardo máximo permitido para una celda
Desde que se envía el primer bit en origen hasta que se recibe el último en destino
Si llega más tarde se descarta
– CTD es una variable aleatoria
– Usado en CBR y rt-VBR
Peak-to-Peak CDV: Peak-to-Peak Cell Delay Variation
– Variación del retardo entre picos: rango de retardos que sufren las celdas
que no son descartadas
– Va desde el retardo mínimo (dependiente del medio físico) hasta MaxCTD
– Usado en CBR y rt-VBR
CLR: Cell Loss Rate
– Máxima tasa de celdas perdidas que es aceptable
– CLR = celdas perdidas / celdas transmitidas
– Usado en CBR, VBR
Arquitectura de Redes - Universidad de Murcia
48
Probabilidad de Retardo de Celdas
Densidad de Probabilidad
Servicios de Tiempo Real
Mínimo
Peak-to-Peak CDV
MaxCTD
Arquitectura de Redes - Universidad de Murcia
CTD
Celdas perdidas o
entregadas demasiado tarde
49
Control de Tráfico
ATM define múltiples funciones de control de tráfico para
mantener la QoS y evitar/minimizar la congestión en la red
–
–
–
–
Control de Admisión de Conexiones (CAC)
Traffic shaping
Traffic policing (UPC, Utilization Parameter Control)
Descarte selectivo de celdas
Bit CLP=1 (Cell Loss Priority)
– Notificación explícita de congestión
Arquitectura de Redes - Universidad de Murcia
51
Control de Admisión
CAC se aplica para cada conexión
entrante
Quiero un CV con:
Serv={CBR,rt-VBR,nrt-VBR,ABR,UBR}
PCR=A, SCR=B, MBS=C, MCR=D
CDVT=E
MaxCTD=F, PtPCDV=G, CLR=H
CAC
¿Puedo soportar esto
de forma fiable sin
perjudicar otros
contratos?
Petición de QoS garantizada
No o Sí, acordar un
Contrato de Tráfico
Red ATM
Contrato
Arquitectura de Redes - Universidad de Murcia
52
Traffic Shaping
Lo realiza el host ATM (User-Network Interface, UNI)
Servicios CBR y VBR
Algoritmo de token bucket
Quiero cumplir
con mi contrato,
por tanto suavizaré
mi tráfico
Shaper
Datos
reales
Adelante,
alégrame el día
Datos conformados
Red ATM
Arquitectura de Redes - Universidad de Murcia
53
Traffic Policing
Lo realiza el switch ATM (interfaz UNI)
Servicios CBR, VBR, ABR y GFR
Algoritmos basados en leaky bucket
Contrato
APLICACIÓN
REBELDE
Arquitectura de Redes - Universidad de Murcia
Este usuario no está
cumpliendo el contrato,
¿cuál deberá ser
la multa?
OPCIONES:
• MARCAR BIT CLP
• DESCARTAR
Red ATM
54
Traffic Policing
CBR y VBR
CBR
-
Leaky bucket
-
ρ = PCR
C se deduce a partir de CDVT
Las celdas no conformes (las que desbordan el cubo) se
descartan
VBR
-
Dos leaky buckets
Una implementación al estilo Frame Relay:
Primer cubo: ρ = SCR, C = BT (Burst Tolerance, se deduce a partir de
MBS)
Segundo cubo: ρ = PCR, C se deduce a partir de CDVT
Las celdas que desbordan el primer el primer cubo se marcan con bit
CLP=1, las que desbordan el segundo se descartan
Arquitectura de Redes - Universidad de Murcia
55
Traffic Policing
VBR
CLP = 1
Tráfico entrante
CLP = 0
Primer cubo lleno
Segundo cubo lleno
CLP = 1
Descartar
Primer
Cubo
(BT)
Vaciar el caudal
SCR en el CV
Arquitectura de Redes - Universidad de Murcia
Segundo
Cubo
(CDVT)
Vaciar el caudal
PCR-SCR en el CV
56
Traffic Policing
ABR y GFR
ABR
-
El caudal debe estar entre los valores MCR y PCR acordados
Hay retroalimentación por parte de la red para ajustar la tasa de
envío
GFR
-
Se comprueba que el tamaño de cada trama sea menor que el
MFS acordado
Dos leaky buckets
Leaky bucket con ρ = PCR, C se deriva de CDVT. Se descartan las
tramas con al menos una celda no conforme.
Leaky bucket con ρ = MCR, C se deriva de MBS y CDVT. Las tramas
con al menos una celda no conforme son descartadas o marcadas
con CLP=1.
Arquitectura de Redes - Universidad de Murcia
57
Capacidad de un Enlace
Distribución por Clases de Servicio
ABR MCR
ABR
ABR PCR
VBR PCR
UBR
VBR SCR
CBR PCR
Arquitectura de Redes - Universidad de Murcia
Capacidad
del enlace
VBR
CBR
CBR
58
Control de Congestión
En todas las clases de servicio se aplica CAC
En CBR y VBR se aplica traffic shaping
En CBR, VBR, ABR y GFR se aplica traffic policing
En todos los servicios, incluido UBR, se descartan celdas
cuando hay congestión
-
Primero aquéllas con bit CLP=1
En GFR se realizan descartes preventivos cuando la ocupación
de los buffers crece prevención de congestión
En ABR se proporcionan también mecanismos de
notificación explícita
Arquitectura de Redes - Universidad de Murcia
60
Notificación Explícita
Las fuentes envían celdas de datos y celdas de gestión
de recursos (RM)
– Habitualmente, 1 celda RM cada 32 celdas de datos
Bits destinados a información de congestión
– Celdas de datos
Bit EFCI (Explicit Forward Congestion Indication)
– Celdas RM
Bit CI (Congestion Indication)
Bit NI (No Increment)
Campo ER (Explicit Rate)
Modos de notificación explícita de congestión
– Marcado EFCI
– Marcado de tasa relativa (RR, Relative Rate)
– Marcado de tasa explícita (ER, Explicit Rate)
Arquitectura de Redes - Universidad de Murcia
61
Notificación Explícita
Marcado EFCI
Switch ATM detecta congestión
– Activa bit EFCI=1 en celda de datos
– El destino activa bit CI=1 en celda RM de vuelta
– La fuente reduce la tasa de envío
Tiempo de reacción depende del RTT del CV
EFCI=1 marcado
por switch
Fuente
x
CI=1 marcado
por Destino
Arquitectura de Redes - Universidad de Murcia
x
Destino
Celda de datos
Celda RM
62
Notificación Explícita
Marcado RR
Switch ATM detecta congestión
– Activa bit CI=1 ó NI=1 en celda RM de vuelta
– La fuente reduce o mantiene la tasa de envío
Menor tiempo de reacción que en EFCI
Fuente
x
CI=1 ó NI=1
marcado por el
switch
Arquitectura de Redes - Universidad de Murcia
Destino
Celda de datos
Celda RM
63
Notificación Explícita
Marcado ER
Fuente de datos envía celdas RM con ER=X (X ≤ PCR)
Switch ATM detecta congestión
– Decrementa el valor ER (RM de ida o de vuelta)
– La fuente reduce la tasa de envío X = max{ER,MCR}
Proporciona buena convergencia
155
100
50
100
Fuente
Destino
Campo ER
Celda de datos
Celda RM
Arquitectura de Redes - Universidad de Murcia
64
Notificación Explícita
Comparación EFCI, RR y ER
Modo Tasa Explícita
Eficiencia
El más sofisticado
Ideal para redes WAN
Conmutador
de Operador
Modo Tasa Relativa
Sencillo y eficiente
Ideal para redes LAN/MAN
Conmutador
de Campus
Modo EFCI
El más sencillo
Alta latencia
Coste/Complejidad
Arquitectura de Redes - Universidad de Murcia
65
Organización del tema
Introducción al control de congestión
Control de admisión y alisado de tráfico
Control de congestión en Frame relay
Control de congestión en ATM
Control de congestión en Internet
Arquitectura de Redes - Universidad de Murcia
68
Control de Congestión en TCP/IP
Mecanismos de control y/o prevención de congestión
Mecanismo
Tipo
Consiste en:
Aplicado a
nivel de:
Tahoe, Reno,
NewReno,
etc.
Notificación
implícita
Cuando un host detecta pérdidas
reduce el ritmo y se autocontrola.
Transporte (TCP)
ICMP Source
Quench
Paquete de
bloqueo
Los routers notifican a las fuentes
cuando detectan (o prevén)
congestión. TCP reduce el ritmo.
Red (IP)
RED
Notificación
implícita por
gestión de colas
Los routers descartan paquetes al
azar cuando prevén congestión.
TCP reduce el ritmo.
Red (IP)
ECN
Notificación
explícita
Los routers notifican a los hosts
cuando detectan (o prevén)
congestión. TCP reduce el ritmo.
Red (IP) y
Transporte (TCP)
Arquitectura de Redes - Universidad de Murcia
69
Gestión de Colas
Algoritmos
El algoritmo de gestión de colas de un router tiene una gran
importancia en el comportamiento y eficiencia global de la red
Algoritmo usado tradicionalmente: FIFO (First In, First Out)
– El primer paquete en llegar a la cola es el primero que sale de ella
– Si la cola está llena cuando llega un paquete, éste se descarta
Problemas del algoritmo FIFO
– No es adecuado para flujos con distintos requisitos de QoS, pues no
permite un tratamiento diferenciado
– Genera un alto retardo medio para los flujos que envían paquetes de datos
pequeños, en comparación con los que envían paquetes mayores
– Trata por igual a los flujos que generan mucho tráfico y a los que generan
poco
Otros algoritmos con múltiples colas tratan de solucionar estos
problemas (FQ, BRFQ, GPS, etc.)
Arquitectura de Redes - Universidad de Murcia
70
Gestión de Colas
Política de Descartes
Los algoritmos anteriores son de tipo Tail Drop
– Se eliminan los paquetes que llegan cuando la cola está llena
Problemas del descarte Tail Drop
– Unos pocos flujos de mayor tasa pueden monopolizar la cola
– No se toman medidas hasta que la cola está llena
Una vez congestionado, es difícil salir de la congestión
Las ráfagas no podrán ser absorbidas por la cola
Lo anterior conduce al problema de sincronización de fuentes TCP
A
B
C
D
RTT
f(RTT)
Flujo agregado
Avg
Arquitectura de Redes - Universidad de Murcia
71
Gestión de Colas
Política de Descartes
Idea: Mantener la tasa de ocupación de las colas baja para
poder absorber ráfagas. No sincronizar las fuentes,
evitando que todas detecten la congestión a la vez.
¿Cómo? Descarte preventivo de paquetes al azar:
– RED (Random Early Detection), RFC 2309.
– Descarta paquetes antes de que la cola se llene. Baja ocupación de
la cola es beneficiosa:
Permite absorber ráfagas.
Limita el retardo y jitter.
– TCP reduce la tasa de envío para aliviar la congestión.
– Como los descartes tienen una componente aleatoria:
Las fuentes no tienden a sincronizarse
Las fuentes que más consumen son las que más descartes sufren
Arquitectura de Redes - Universidad de Murcia
72
RED
Algoritmo
RED calcula la longitud media de la cola (QAVG) como una
media ponderada exponencial:
– QAVG = (1 – W)QAVG + QINSTW
Cada vez que llega un paquete:
– Si QAVG < min, se encola
– Si min < QAVG < max, se descarta con probabilidad p que crece
linealmente con QAVG
– Si QAVG > max, se descarta
Inconvenientes
– Sólo sirve para flujos adaptables
– Los paquetes descartados no siempre pertenecen a los flujos
causantes de la congestión
Arquitectura de Redes - Universidad de Murcia
73
RED
Probabilidad de Descarte
Probabilidad de Descarte
Zona normal
Controlar
congestión
Evitar
congestión
1
p
0
min
0%
m
max
100%
Ocupación Media de la Cola QAVG
Arquitectura de Redes - Universidad de Murcia
74
RED
Fuentes Desincronizadas
RTT
A
B
C
D
N × RTT
Flujo Agregado
Avg
Arquitectura de Redes - Universidad de Murcia
75
RED
Variantes
WRED (Weighted RED)
– Aplica distintas funciones de probabilidad p según el tráfico vaya marcado
RIO (RED with In/Out bit)
– Calcula QAVG de forma independiente para el tráfico que cumple con el
perfil de tráfico acordado (In) y el que no (Out)
– Probabilidad de descarte p más agresiva para tráfico Out
ARED (Adaptive RED)
– Varía el valor máximo que puede tomar p en función de QAVG
– Pretende hacer más agresivo el descarte cuando la congestión es mayor
FRED (Flow RED)
– Guarda estado de los flujos cuyos paquetes hay almacenados en la cola,
descartando en función del número de paquetes de cada flujo
Arquitectura de Redes - Universidad de Murcia
76
¿Por Qué Notificación Explícita?
RED y sus variantes implementan un esquema de
notificación implícita para prevenir la congestión
– Sólo es válido para aplicaciones TCP (o similares)
– Requiere la expiración de un timeout para detectar la situación
– Requiere la retransmisión de los paquetes descartados
Podemos mejorar el rendimiento si usamos un esquema de
notificación explícita
– ECN (Explicit Congestion Notification).
– RFC 2481 (1999) define el uso de los dos bits libres del campo
DSCP de la cabecera IP para indicar congestión. A su vez, añade
dos flags a la cabecera TCP. La especificación es de carácter
“experimental”.
– RFC 3168 (2001) deja obsoleto al 2481 y eleva la categoría de ECN
a “standards track”.
Arquitectura de Redes - Universidad de Murcia
81
ECN
Cabecera IP
El campo ECN es similar a los campos FECN en Frame
Relay y EFCI de ATM.
Está definido en la cabecera IP, dentro del campo DSCP
(RFC 3168).
DSCP
ECN
ECN
Significado
00
El Host emisor no soporta ECN.
01
El Host emisor soporta ECN (caso alternativo).
10
El Host emisor soporta ECN (caso normal).
11
El Host soporta ECN. La red ha marcado congestión.
Arquitectura de Redes - Universidad de Murcia
82
ECN
Cabecera TCP
Antes de ECN:
4 bits
6 bits
Long.
Cabecera
Reservado
6 bits
U A P R S F
R C S S Y I
G K H T N N
Flags
Después de ECN:
4 bits
Long.
Cabecera
4 bits
Reservado
8 bits
C E U A P R S F
W C R C S S Y I
R E G K H T N N
Flags
CWR: Congestion Window Reduced
ECE: ECN Echo
Arquitectura de Redes - Universidad de Murcia
83
ECN
Funcionamiento
1: A envía un paquete a B
IP: ECN = ‘10’
’
TCP: CWR = 0, ECE = 0
A
1
2: Router Y recibe el
paquete, detecta
congestión y cambia ECN
IP: ECN = ‘11’
’
3: B recibe el paquete y
detecta que ha habido
congestión en el camino
(ECN == ‘11’
’)
2
X
3
Y
Z
5
5: A recibe aviso
de B (ECE == 1)
B
4
6
7
6: TCP de A reduce su ventana
y envía confirmación a B
indicando que ha recibido el
aviso
IP: ECN = ‘10’
’
TCP: CWR = 1, ECE = 0
Arquitectura de Redes - Universidad de Murcia
4: TCP de B envía
paquete de aviso a A
IP: ECN = ‘10’
’
TCP: CWR = 0, ECE = 1
7: B recibe confirmación
(CWR == 1) y se queda
tranquilo (sabe que no ha de
insistir con ECE == 1)
84
Bibliografía
Básica
–
–
–
–
Stallings, “High Speed Networks and Internets”, Cap. 10, 13.
Tanembaum, Sec. 5.3 y 5.4.
Comer, Sec. 12.21 a 12.23.
G. Armitage, “Quality of Service in IP Networks”, Pearson
Education, 2000, Sec. 3.4.
Complementaria
– S. Floyd, V. Jacobson, “Random Early Detection gateways for
Congestion Avoidance”, IEEE/ACM Transactions on Networking,
Vol. 1, No. 4, 1993.
– “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC
3168.
Arquitectura de Redes - Universidad de Murcia
87