PDF de programación - Control de congestión en TCP

Imágen de pdf Control de congestión en TCP

Control de congestión en TCPgráfica de visualizaciones

Publicado el 13 de Mayo del 2021
112 visualizaciones desde el 13 de Mayo del 2021
152,6 KB
20 paginas
Creado hace 15a (07/11/2005)
Redes de Ordenadores

Control de congestión en TCP



Mikel Izal Azcárate
([email protected])

En clases anteriores

‣ TCP y UDP
‣ TCP

> Transporte fiable
> Control de flujo
> Manejo de conexiones

‣ El problema de la congestión en redes
Hoy
‣ Control de congestión en TCP

7 noviembre 2005

Transporte-7

2

/20

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

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

confirmados

7 noviembre 2005

enviados

se pueden
enviar

Transporte-7

no se pueden
enviar

3

/20

v=CongWinRTT 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

> En la siguiente clase veremos como se elige el MSS

7 noviembre 2005

Transporte-7

4

/20

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
> En congestion avoidance se abre 1 MSS cada vez que enviamos con exito

toda la ventana

> La ventana sube linealmente

CongWin=4 MSS

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

CongWin=5 MSS

Enviado
por RTT

7 noviembre 2005

tiempo

Transporte-7

5

/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

CongWin=8 MSS

Enviado
por RTT

7 noviembre 2005

CongWin=4 MSS

tiempo

Transporte-7

6

/20

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

7 noviembre 2005

1 pérdida

1 pérdida

1 pérdida

tiempo

Transporte-7

7

/20

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

7 noviembre 2005

tiempo

Transporte-7

8

/20

TCP: Slow Start

‣ El slow start se mantiene hasta que se produce una

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

+ Fast retransmit + fast recovery CongWin = CongWin/2

‣ Y si se produce un timeout?

slow start

congestion avoidance

7 noviembre 2005

Transporte-7

9

/20

tiempo

TCP: pérdidas y congestión

‣ Pérdida detectada por ACK duplicados

> Congestión “ligera”: hay perdidas pero siguen llegando paquetes
> Acciones:

+ Retransmitir el paquete perdido (Fast retransmit)
+ Bajar la ventana de congestion para reducir la tasa
+ Pasar a congestion avoidance (si no estabas)
‣ Pérdida detectada por timeout

> Congestión “grave”. Probablemente hemos perdido toda la ventana. Si el

timeout ha caducado llevamos un rato parados sin transmitir. Tasa =0

> Acciones:

+ Poner la ventana de congestión a 1MSS
+ Pasar a slow start
+ Recordar a cuanto estaba la ventana de congestión al producirse el

error (poner la variable threshold=CongWin/2)

7 noviembre 2005

Transporte-7

10

/20

TCP: slow start

‣ Despues de una perdida por timeout

> el slow start no espera a otra pérdida para entrar en congestion

avoidance.

> Pasa a congestion avoidance en cuanto llega al humbral de la mitad

de la ventana de congestion al producirse el timeout

pérdidas y
timeout

slow start

congestion avoidance

7 noviembre 2005

Transporte-7

11

/20

tiempo

TCP: control de congestión

En resumen
‣ Cuando CongWin está por debajo de Threshold.
Slow start. La ventana crece exponencialmente
‣ Cuando CongWin está por encima de Threshold.

Congestion avoidance. La ventana crece
linealmente

‣ Cuando ocurre un triple ACK duplicado.

Threshold se pone a CongWin/2 y CongWin a
Threshold

‣ Cuando ocurre un timeout. Threshold se pone a

CongWin/2 y CongWin se pone a 1MSS

7 noviembre 2005

Transporte-7

12

/20

TCP: control de congestión
‣ Eventos en el emisor

Evento
Recibe ACK para
datos no
confirmados

Estado
Slow Start
(SS)

Acción
CongWin = CongWin + MSS,
If (CongWin > Threshold)
set state to “Congestion Avoidance”

Notas
CongWin se dobla por cada
RTT

Recibe ACK para
datos no
confirmados

Congestion
Avoidance
(CA)

CongWin = CongWin+MSS * (MSS/CongWin)


Additive increase, CongWin
aumenta 1 MSS por cada
RTT

Perdida
detectada por
triple ACK
duplicado
Timeout

SS or CA

SS or CA

Threshold = CongWin/2,
CongWin = Threshold,
Set state to “Congestion Avoidance”

Fast recovery+multiplicative
decrease. CongWin nunca
baja a menos de 1MSS

Threshold = CongWin/2,
CongWin = 1 MSS,
Set state to “Slow Start”

vuelve a slow start

ACK duplicado

SS or CA

Incrementar contador de ACKs duplicados
para ese segmento

CongWin y Threshold no
cambian

7 noviembre 2005

Transporte-7

13

/20

TCP: evolución de la conexión
‣ Ejemplo, una conexión TCP

La ventana de control de
flujo impone el máximo

w start

slo

n



e

t i o
n
a

c

s

e
g
o i d

c

n
v

o

a



n

e

t i o
n
a

c

s

e
g
o i d

c

n
v

o

a

slow start

pérdida

muchas
perdidas

pérdida

7 noviembre 2005

Transporte-7

14

/20

TCP: eficiencia de la conexión

‣ Sigue el límite de AdvertisedWindow/RTT
‣ Esto es para una conexión que este siempre

enviando
> Tenga siempre datos en el buffer de emisión
> La aplicación del receptor lea los datos suficientemente rápido

como para que el emisor siempre anuncie la ventana máxima

‣ Cómo podemos transmitir a mayor velocidad?
> Mejorando TCP para que permita ventanas mayores (próxima clase)
> Usando más de una conexión TCP??
> UDP tiene control de flujo??

7 noviembre 2005

Transporte-7

15

/20

TCP: equidad (fairness)

‣ Equidad para TCP

> Si N conexiones TCP comparten un enlace la capacidad del enlace R

debería repartirse entre todas por igual R/N

7 noviembre 2005

Transporte-7

16

/20

Cuello de botellacapacidad R TCP: equidad (fairness)

‣ Por qué es TCP equitativo?

> 2 sesiones compitiendo por el ancho de banda
> Modelo simple. Si la capacidad de las dos suma mas que R habra perdidas
> Additive increase: sube linealmente el throughput,

Multiplicative decrease: si hay perdidas baja rapidamente

t1+t2 >R

R

2

x
n
c

t
u
p
h
g
u
o
r
h
t

t1+t2 <R

7 noviembre 2005

Transporte-7

R

throughput cnx 1

17

/20

Más sobre equidad

‣ ¿Qué pasa con UDP?

> Las aplicaciones multimedia suelen usar UDP para evitar el control

de congestión.

> Envían a tasa constante y no quieren que esta se vea reducida
> Son capaces de tolerar pérdidas

‣ Sin embargo

> Es dificil garantizar la equidad en ese ambiente TCP+UDP
> El control de congestión de TCP es justo si compite con otros TCPs
> Esto es un área de investigación activa

+ UDP que sea TCP friendly?
+ Envio de multimedia sobre TCP?

7 noviembre 2005

Transporte-7

18

/20

Más sobre equidad

‣ Las aplicaciones pueden abrir más de una

conexión TCP entre dos hosts
> Así podrían superar la limitación de la ventana de control de flujo de

65KB

> Los navegadores web hacen esto
> Parte de la mejora de transferencia de los sistemas P2P viene de

este efecto !!

‣ Sin embargo

> Esto también dificulta el problema de la equidad en TCP
> Si en un enlace de capacidad R hay 9 conexiónes TCP

+ Puedo abrir una conexión y conseguir un reparto de R/10
+ O puedo abrir 11 y conseguir R/2 !!!

7 noviembre 2005

Transporte-7

19

/20

Conclusiones

‣ El control de congestión TCP se basa en una

serie de principios simples
> ventana de congestion
> AIMD + slow start para el principio
> reacción a los ACKs duplicados (congestion ligera) y timeouts

(congestion severa)

‣ TCP reparte la capacidad de forma equitativa

> Pero sigue habiendo problemas en una Internet en la que no todo es

TCP

‣ Próxima clase:

Ultimos detalles de TCP
Mejoras y futuro de TCP

7 noviembre 2005

Transporte-7

20

/20
  • Links de descarga
http://lwp-l.com/pdf19188

Comentarios de: Control de congestión en TCP (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios...
CerrarCerrar
CerrarCerrar
Cerrar

Tienes que ser un usuario registrado para poder insertar imágenes, archivos y/o videos.

Puedes registrarte o validarte desde aquí.

Codigo
Negrita
Subrayado
Tachado
Cursiva
Insertar enlace
Imagen externa
Emoticon
Tabular
Centrar
Titulo
Linea
Disminuir
Aumentar
Vista preliminar
sonreir
dientes
lengua
guiño
enfadado
confundido
llorar
avergonzado
sorprendido
triste
sol
estrella
jarra
camara
taza de cafe
email
beso
bombilla
amor
mal
bien
Es necesario revisar y aceptar las políticas de privacidad