PDF de programación - TCP y control de congestión en Internet

REDES
Área de Ingeniería Telemática

TCP

y control de congestión en Internet

Area de Ingeniería Telemática

http://www.tlm.unavarra.es

Redes

4º Ingeniería Informática

a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


S
E
D
E
R

e
d



a
e
r
Á

Hoy...

1. Introducción a las redes
2. Tecnologías para redes de área local
3. Conmutación de circuitos
4. Tecnologías para redes de área extensa y última milla
5. Encaminamiento
6. Arquitectura de conmutadores de paquetes
7. Control de acceso al medio
8. Transporte extremo a extremo

¿Por qué se pierden los paquetes?

‣ Varias causas

> Errores de transmisión.

Modifican bits aleatorios de los
paquetes. Los niveles que hacen
detección de errores se ven
obligados a descartar el paquete al
no estar seguros de entregarlo
correctamente
Independiente del tráfico
> Desbordamiento de buffer
Un router que debe reenviar un
paquete se encuentra con que todos
sus recursos de memoria (por
ejemplo en la cola de paquetes
esperando la salida están ocupados).
Debe descartar el paquete por falta
de recursos
Dependiente de la carga de la
red

R1

R2

R3

R4

Para R3

R1

R2

R3

R4

3

Congestión de red

¿Qué es?
‣ Demasiadas fuentes enviando demasiado trafico para

que la red pueda manejarlo

‣ No es lo mismo que el control de flujo
> Relacionado con que el receptor pueda manejar el tráfico
> La congestión puede darse aunque todos los receptores sean capaces de aceptar

el trafico que se está enviando

‣ Efectos:

> Pérdidas de paquetes (debido a desbordamiento de colas de routers)
> Tiempos de espera elevados (debido a tiempos de espera en colas altos)

‣ Es uno de los problemas más importantes de redes

4

Escenario 1
‣ Dos emisores y dos receptores
‣ Un router común (supongamos que con buffer infinito)

> Nunca ocurren retransmisiones
> Las dos fuentes envian a una media de λin
> La capacidad del router es C

‣ Como se comporta el sistema??

5

Escenario 1

‣ Entrada y salida. Cuanto throughput obtenemos del sistema?

λout para cada λin aceptable (con un scheduler perfecto)

C/2

t
u
o

!

o
d
r
a
e
r

t

!

in

C/2

!
in
‣ Pero el retardo aumenta indefinidamente
‣ Cada vez tiene más paquetes que procesar
‣ Recursos infinitos no garantizan un buen funcionamiento

C/2

6

Escenario 2

‣ Igual que el anterior pero ahora el router tiene

recursos finitos.
> Los paquetes no esperan indefinidamente (retardo limitado)
> Si se transmite a mucha velocidad algunos paquetes se perderan

y el nivel de transporte los retransmitirá

> Tráfico

λ’in = λin + retransmisiones

7

Escenario 2
‣ λin = λout (goodput)
‣ Envío perfecto (no hay retransmisiones hasta que alcancemos R/2)

Retransmisión implica λ’in > λout

t

u
o

!

R/2

t

u
o

!

R/3

t

u
o

!

R/4

R/2

!'

in

Perfecto

R/2

!'

in
Retransmisiones sólo por

no retransmisiones
‣ Coste de la congestión

desbordamiento

R/2

!'
Retransmisiones por
timeout prematuro

in

> Más trabajo (retransmisiones) para el mismo resultado (goodput)
> Retransmisiones innecesarias: capacidad perdida

8

Escenario 3

‣ 4 fuentes, buffers finitos y múltiples caminos
‣ Retransmisiones por timeout
‣ ¿Qué pasa al aumentar λin y por tanto λ’in ?

H2

R1

H1

R2

R3

H3

R4

H4

9

Escenario 3

‣ El trafico que entra a R2
proveniente de R1 tiene
límite R
Cuando la carga es muy
alta R2 esta saturado por
el trafico de H2

‣

t
u
o

!

‣
C/2

Con carga alta el trafico util
que se cursa tiende a 0
Cuando se descarta un
paquete la capacidad usada
para llevarlo hasta ese
punto se desperdicia

!'

in

10

Control de congestión

‣ Problema:

cuando la red está saturada por alta carga proveniente de
muchas fuentes
se pierden paquetes, se cursa menos tráfico útil y aumenta
el retardo de los paquetes que llegan a su destino
Los protocolos de transporte reaccionan
aumentando las retransmisiones causando más
carga y más congestión

‣ Si estamos en esta situación es más rentable que los
emisores no envíen tan rápido para mantenerse por
debajo de esta carga total...
Como conseguimos esto?
Qué pasa si la mayoría hacen eso pero unos pocos no?11

Control de congestión

Dos enfoques para control de congestión
‣ Control de congestión extremo a extremo

> No hay indicación explicita de la congestión
> Los extremos estiman la congestión basandose en sus propias

observaciones de la red
+ Perdidas observadas
+ Retardo observado

> Los extremos reacciónan a la congestión reduciendo la carga:

disminuyendo retransmisiones, tasa de envíos, aumentando timeouts...

> Esta es la filosofía que utiliza TCP (clasico)

12

Control de congestión

Dos enfoques para control de congestión
‣ Control de congestión asistido por la red

> Los routers informan de la congestión a los extremos de la

comunicación
+ Modificando un bit para indicar congestión:

SNA, DECnet, TCP/IP ECN (RFC2481), ATM

+ Indicando la tasa máxima a la que puede enviar

ATM ABR

+ Remember ECN: Explicit Congestion Notification

13

Ejemplo

ATM

‣ Control de congestión asistido por la red en

‣ ATM red de comunicaciones para transporte

de RDSI de banda ancha
> Filosofía de conmutación de paquetes con paquetes de tamaño pequeño

y fijo (celdas) y con circuitos virtuales

> Orientado a conexión
> Estado de las conexiones en cada nodo (switch)

14

Control de congestión en ABR

‣ ABR (Available Bit Rate)

> Si el camino está descargado puede usar más capacidad
> Si el camino está cargado el emisor debe limitarse a una capacidad mínima garantizada

‣ Celdas RM (resource management)

> Enviadas por el emisor mezcladas con las celdas de datos
> Bits en estas celdas permiten indicar la congestión de red

+ NI bit No Increase rate Indica congestión moderada
+ CI bit Congestion Indication

> El emisor devuelve estas celdas sin tocar esos bits

15

Control de congestión en ABR
‣ Varios mecanismos

> Bit EFCI en las celdas de datos (Explicit Forward Congestion Indication).

El destino reacciona devolviendo celdas RM con el bit CI a 1

> Celdas RM con bits NI y CI

El destino las devueve sin tocar los bits (salvo poner CI)

> Los switchs pueden incluso generar RMs hacia atras

> Campo ER (Explicit Rate) de dos bytes en las celdas RM

Los switchs del camino pueden modificar el valor

16

Control de congestión en Internet

‣ Pero Internet se basa en un nivel de red simple que no

asiste en la detección de la congestión

‣ TCP (originalmente) utiliza control de congestión

extremo a extremo
> Como inferimos que hay congestión en la red?

+ Perdidas?
+ Retardo?

> Qué hacemos para evitarlo?

+ Reducir la tasa de envío? Cómo?
+ Aumentar el timeout de retransmisión?

‣ Si hay errores bajar la tasa de transferencia?
‣ Algo más?

17

TCP: Control de congestión

‣ Usa control de congestión extremo a extremo

> La ventana deslizante de transporte fiable tenia un limite máximo impuesto por

el control de flujo igual a la ventana anunciada por el receptor

> Se utiliza otra ventana de congestión que limita los datos que se pueden

enviar a la red dependiendo de la percepción que tiene TCP de la congestión

> La ventana anunciada depende del receptor
> La ventana de congestión se reduce ante la congestión limitando la tasa a la que

enviamos

v =

Ventana = min { ventana anunciada, ventana de congestión }

CongWin

RT T

confirmados

enviados

se pueden
enviar

no se pueden
enviar

18

TCP: Control de congestión

‣ ¿Cómo percibe TCP la congestión?

> Perdida de paquetes = congestión

+ Evento de timeout
+ 3 ACKs duplicados (Fast retransmit)

‣ Ajustando la ventana de congestión

> Congestion avoidance (evitación de congestion)
> Slow start
> Fast recovery
> Timeout

‣ MSS: maximun segment size

> Aun cuando TCP utiliza secuencias y ACKs por bytes individuales cuando tiene
mucho que enviar utiliza un máximo tamaño de segmento, que llamaremos MSS

> Negociado en la apertura de conexión

19

TCP: Congestion avoidance

‣ Tras detectar congestión TCP entra en una fase de

evitación de congestión (congestion avoidance)
> Si la ventana de congestión tiene un valor de N MSS y es menor que la ventana

anunciada por el receptor

> En congestion avoidance se abre 1 MSS cada vez que enviamos con exito toda la

ventana

> La ventana sube linealmente

Buscando encontrar el punto de
equilibrio sin aumentar demasiado la
congestión

Enviado
por RTT

CongWin=4 MSS

CongWin=5 MSS

tiempo

20

TCP: Congestion avoidance
‣ Si en esta situación se produce una pérdida

> De un sólo paquete, lo que provoca 3 ACKs duplicados. Se interpreta como

congestión ligera

> La ventana se reduce inmediatamente a la mitad

A la vez que se hace fast retrasmit del paquete perdido
Esto se conoce como fast recovery (originalmente se reducía a 1MSS)

> Buscando reducir notablemente la
tasa de transmisión y colaborar en
que la congestión no crezca

> Si se siguen recibiendo ACKs la

ventana sigue creciendo linealmente

Enviado
por RTT

CongWin=8 MSS

CongWin=4 MSS

tiempo

21

TCP: Congestion avoidance
‣ Se puede ver que la tasa se va ajustando alrededor

del punto de congestión
> si hay muchos errores la tasa baja y se tarda más en recuperarla
> si hay pocos errores el crecimiento lineal es capaz de llegar mas a mas

velocidad

> Este mecanismo se suele llamar AIMD
Additive Increase Multiplicative Decrease

‣ Y cómo empieza la conexión??

> Con CongWin = 1 MSS

Enviado
por RTT

1 pérdida

1 pérdida

1 pérdida

tiempo

22

TCP: Slow Start

‣ En el principio CongWin=1 MSS pero...

> Crecer linealmente es demasiado precavido, no

tenemos motivos para pensar que hay
congestión

> Se utiliza un enfoque más agresivo, crecimiento

exponencial

> Slow Start: cada vez que transmitimos una

ventana con éxito la ventana se dobla

CongWin
=1 MSS

CongWin
=2 MSS

CongWin
=4 MSS

CongWin
=8 MSS

tiempo

23

TCP: Slow Start

‣ El slow start se mantiene hasta que se produce una

pérdida haciendo entrar en congestion avoidance
(o bien se alcanza la ventana de control de flujo)
> Si la perdida se detecta por ACKs duplicados...

+ Fast r