Your SlideShare is downloading. ×
Sistemas de Conmutación: Control de congestión
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Sistemas de Conmutación: Control de congestión

2,199
views

Published on

Primera parte del tercer tema de la asignatura Sistemas de Conmutación de 4º curso de Ingeniería de Telecomunicación (Vigo), donde se trata el control de congestión en redes de conmutación de …

Primera parte del tercer tema de la asignatura Sistemas de Conmutación de 4º curso de Ingeniería de Telecomunicación (Vigo), donde se trata el control de congestión en redes de conmutación de paquetes.

Published in: Education, Business, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,199
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Introducción Congestión: Exceso de demanda de algún recurso (ancho de banda, memoria, capacidad de procesamiento...) que da lugar a una pérdida de prestaciones de la red. Síntomas: Aumentan los retardos y las pérdidas. Una propiedad típica de la congestión es la realimentación, que hace que la situación empeore con el paso del tiempo, pues un nodo congestionado provocará con el tiempo la saturación de los que envían tráfico hacia él. La consecuencia final de la congestión, si ésta no es resuelta, es que la red entra en una situación de colapso: bajada de varios ordenes de magnitud del caudal de información útil. Ideal Capacidad máxima de la subred Tráfico entregado Asintótico Real Zona de Zona de Colapso o Deadlock riesgo congestión Zona de trabajo Tráfico ofrecido ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.1
  • 2. Consecuencias de la congestión Retardos Trabajar cerca de la capacidad de los enlaces es ideal desde el punto de vista de la productividad, pero no lo es respecto al retardo. ´ Perdidas Se producen debido a la finitud de los búferes, con lo que el emisor puede que realice retransmisiones: posible realimentación positiva. Desperdicio de recursos Ante grandes retardos vencen temporizadores en el emisor antes de llegar los asentimientos, con lo que se retransmiten paquetes innecesariamente. Inherente en conmutación de paquetes: un paquete desechado en un punto ha consumido recursos de manera inútil en enlaces y nodos anteriores. ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.2
  • 3. Dinámica del control de la congestión Mecanismos según momento de actuación: Intentan prevenir la congestión. Preventivos o de lazo abierto Control de admision Se limita el número de usuarios o flujos. ´ Regulacion de trafico Se modifica el patrón de tráfico a la entrada ´ ´ de forma que sea más predicible. Monitorizacion Se vigila que un flujo no exceda su cuota de tráfico. ´ Ejemplo: Servicio CBR (Constant Bit Rate) en ATM. Reactivos o de lazo cerrado Intentan resolverla cuando aparece. Realimentacion expl´cita Los nodos de conmutación avisan a los ´ ı extremos cuando están congestionados o en peligro de congestión (envían paquetes especiales o marcan los paquetes de datos si no los van a descartar). Ejemplo: Explicit Congestion Notification en TCP/IP. Realimentacion impl´cita Los extremos infieren la presencia de ´ ı congestión en la red basándose en las pérdidas o en los retardos. Ejemplo: Control de congestión en TCP. ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.3
  • 4. Control de flujo en TCP Emisor Receptor TCP TCP LastByteWritten LastByteRead LastByteAcked LastByteRcv LastByteSent NextByteExpected El receptor informa al emisor de cuantos octetos, RcvWindow (16 bits), está preparado a recibir más allá del octeto asentido: RcvWindow = RcvBuffer − (NextByteExpected − LastByteRead), con RcvBuffer el tamaño de búfer del receptor; el emisor garantizará: LastByteSent − LastByteAcked ≤ RcvWindow ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.4
  • 5. Control de congestión en Internet: TCP Bloqueo por congestión observada por primera vez en Octubre de 1986: NSFnet phase-I backbone pasó de 32 kb/s a 40 b/s; ante pérdida de paquetes y vencimiento de temporización TCP reenviaba a máxima velocidad. En 1988 Van Jacobson introduce el control de congestión, incorporándose en la versión para BSD Tahoe de TCP: cada fuente ha de determinar de cuánta capacidad dispone en la red, limitando el número de paquetes a transmitir. Se añade la ventana de control de congestión, CongWindow, y el emisor restringirá envíos con: LastByteSend − LastByteAcked ≤ m´ (CongWindow, RcvWindow) ın Grosso modo, el emisor consigue ajustar la tasa de envío a CongWindow RTT octetos/s, con RTT (Round Trip Time) el tiempo de respuesta. Detección: bien fin de temporización sin recibir asentimiento, bien recepción de tres asentimientos duplicados. ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.5
  • 6. TCP: Crecimiento aditivo/decrecimiento multiplicativo La idea es incrementar CongWindow en el tamaño máximo de segmento (MSS) cada RTT, que implica incrementar a cada asentimiento nuevo recibido 1 CongWindow · MSS MSS Ante vencimiento de temporización (pérdida de paquete) se reduciría a CongWindow m´x a , MSS 2 El comportamiento de las conexiones TCP de larga duración será el típico en diente de sierra. ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.6
  • 7. TCP: Arranque lento IdeaEvitar el envío de toda la ventana de congestión/flujo de golpe. Algoritmo Se inicia CongWindow a MSS, se incrementa en MSS cada asentimiento nuevo recibido. Crecimiento exponencial CongWindow dobla su tamaño cada RTT Finaliza cuando CongWindow alcanza el valor CongThreshold, que en cada uso tomará un valor distinto: ´ Inicio de conexion Prefijado a un valor elevado. Vencimiento de temporizador Será CongThreshold el que se ponga a CongWindow/2 (CongWindow se pondrá a MSS). ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.7
  • 8. TCP: Retransmisión rápida Ante la recepción de 3 asentimientos duplicados (4 iguales) reenvía el paquete por asentir, con: TCP Tahoe Igual reacción que ante temporización: Arranque lento. TCP Reno Utiliza recuperación rápida. Recuperación rápida o o 1. 1 W ← CongWindow 2 CongWindow ← CongThreshold ← W/2 2. Incrementa CongWindow en MSS por cada asentimiento duplicado recibido (incluyendo los 3 que han generado esta fase): permite o el envío de un máximo (si paquete perdido el 1 de la ventana ⇒ hay W en vuelo) de CongWindow (mitad de W) nuevos octetos mientras espera asentimiento nuevo. 3. Recepción del asentimiento nuevo: CongWindow ← CongThreshold, paso a modo normal. TCP NewReno: No vuelve al modo normal hasta ser asentida toda la ventana W inicial. ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.8
  • 9. TCP Reno: evolución de CongThreshold TRIPLE ASENTIMIENTO DUPLICADO FIN DE TEMPORIZACIÓN 45 40 35 CongThreshold 30 (segmentos) 25 CongThreshold 20 CongWindow 15 CongThreshold 10 5 0 0 2 4 6 8 10 12 14 16 18 20 22 24 26 RTT ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.9
  • 10. TCP: Algunas variantes TCP Vegas Control preventivo a partir de la variaciones del RTT. Fast TCP Ídem pero más agresivo en la búsqueda del ancho de banda utilizable. TCP Veno Híbrido entre Reno y Vegas para intentar evitar falsas pérdidas por congestión en redes móviles. TCP BIC Binary Increase Congestion control, más agresivo que Reno en busca del ancho de banda disponible (Linux >2.6.8). TCP CUBIC Sucesor del BIC, menos agresivo (Linux >2.6.19), intenta limitar el impacto del valor del RTT. TCP SACK Incorpora Selective Acknowledgement para optimizar los reenvíos y el caudal de salida. ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.10
  • 11. Control de congestión en Internet: RED (I) Random Early Detection: los nodos de conmutación IP monitorizan la ocupación media de las colas y ante superación de umbrales notifican con cierta probabilidad al origen de forma implícita mediante el descarte de un paquete (también propuesto explícitamente con Explicit Congestion Notification). El tamaño medio se estima a patir de sucesivas medidas (instantes de llegada de paquetes) Q : Q = (1 − β) × Q + β × Q con 0 < β < 1, y al llegar un paquete se compara con dos límites MinThreshold y MaxThreshold: si Q ≤ MinThreshold se acepta el paquete, si MinThreshold < Q < MaxThreshold con probabilidad P(Q, count) se o descarta el paquete (count n paquetes no descartados en este punto desde el último que sí lo fue), si MaxThreshold ≤ Q se descarta el paquete. ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.11
  • 12. Control de congestión en Internet: RED (y II) R(Q) × (Q − MinThreshold) Pmáx P(Q, count) = , R(Q) = 1 − count × R(Q) MaxThreshold − MinThreshold R(Q) 1.0 Pmáx MinThresh MaxThresh Q ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.12
  • 13. Regulación del tráfico Dado que una de las principales causas de la congestión es que el tráfico es a ráfagas, los mecanimos de regulación de tráfico fuerzan a las fuentes a transmitir de forma más predecible. En realidad, lo que se pretende es regular la tasa media y la variabilidad del tráfico de entrada a la red. Aunque esta regulación es más fácil de implementar con circuitos virtuales, puede aplicarse igualmente a redes de datagramas. Los mecanismos típicos son Leaky Bucket y Token Bucket. ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.13
  • 14. Algoritmo Leaky Bucket Cada fuente se conecta a la red a través de una interfaz que contiene una cola finita (leaky bucket) capaz de almacenar un máximo de K paquetes (u octetos), de forma que cualquier paquete que llegue estando la cola llena será descartado. De esa cola se envían los paquetes a la red a una tasa constante de µ pkt/s (o B/s), independientemente de cuál sea la tasa de llegada al leaky bucket. Fuente flujo no regulado Bucket flujo regulado Red ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.14
  • 15. Algoritmo Token Bucket (I) El algoritmo Leaky Bucket fuerza a una tasa constante, independientemente de lo variable que sea el tráfico. Para muchas aplicaciones se prefiere, sin embargo, que para ráfagas cortas esa tasa pueda ser incrementada. Se necesita un algoritmo más flexible. En el algoritmo Token Bucket, se añade un depósito de testigos (tokens), que son generados a una tasa de µ testigos/s, hasta un máximo de K testigos, de forma que o cada testigo da derecho a transmitir un paquete (o un n de octetos). Así, este algoritmo permite ahorrar testigos cuando no hay datos que transmitir, comportándose de la misma manera que Leaky Bucket cuando siempre hay datos para transmitir. ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.15
  • 16. Algoritmo Token Bucket (II) Para una ráfaga de longitud S segundos, y si la tasa máxima de salida permitida es de M pkt/s, una ráfaga de salida contendrá como mucho K + µ · S paquetes. Por otro lado, el número de paquetes en una ráfaga a velocidad de salida máxima es M · S. Por tanto, la duración máxima Smáx de una ráfaga de salida será: K K + µ · Smáx = M · Smáx =⇒ Smáx = M−µ Para suavizar el tráfico de entrada a la red se puede combinar un Leaky Bucket de tasa µl tras un Token Bucket de tasa µt , de forma que µt < µl < M. ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.16
  • 17. Ejemplo: Leaky Bucket flujo de entrada a la red no regulado Fuente 1 MB cada segundo 25 MBps 25 MBps t 40 ms K = 1 MB flujo de entrada a la red regulado µ = 2 MBps 2 MBps t Red 500 ms ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.17
  • 18. Ejemplo: Token Bucket K Fuente 1 MB cada segundo S= M−µ 25 MBps 10 86 ms — 25 MBps — 271 5 KB K = 250KB 364 ms — 2 MBps — 728 5 KB flujo de entrada a la red regulado 25 MBps 2 MBps M = 25 MBps µ = 2 MBps t 10 86 ms 375 ms Red ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.18
  • 19. Ejemplo: Token Bucket + Leaky Bucket Fuente 1 MB cada segundo Kt S= µl − µt 25 MBps Kt = 500 KB 62 5 ms — 10 MBps — 625 KB Token Bucket 187 5 ms — 2 MBps — 375 KB µt = 2 Mbps flujo de entrada a la red regulado 10 MBps Leaky Bucket 2 MBps t µl = 10 MBps 62 5 ms 250 ms Red ˜ ı ´ Departamento de Enxener´a Telematica ´ Sistemas de Conmutacion ´ Control de congestion– p.19