Redes II

Capa de Transporte

Ing. Gregorio N. Tkachuk

NOTA: esta presentación es adaptada de:

Computer Networking: A Top Down Approach Featuring the
Internet, 7th edition. 2017 Jim Kurose, Keith Ross. Pearson.
 La siguiente presentación, es solo una guía.
Para estudiar, utilice la siguiente Bibliografía:

Título Autor(es) Editorial Edición

Redes de Computadoras. Un enfoque Kurose, James F; Ross, Keiith Pearson 2017,
descendente. 7ª Ed. W España
Redes de Computadoras. 5ª Ed. Tanenbaum, Andrew S.; Pearson 2012,
Wetherall David J. México
Sistemas Distribuidos. Conceptos y Coulouris, George; Dollimore, Pearson 2001,
Diseño. 3ª Ed. Jean; Kindberg, Tim Educación España
Sistemas Distribuidos. Principios y Tanenbaum, Andrew S.; Van Pearson 2008,
Paradigmas. 2ª Ed. Steen, Maarten Educación México

Capa Transporte 3
Capa Transporte: Contenidos
 Transporte orientado a la conexión: TCP
 Estructura de un segmento
 Transferencia confiable de datos
 Control de flujo
 Gestión de la conexión
 Principios del control de congestión
 Control de congestión en TCP
 Notificación Explícita de Congestión
(ECN, Explicit Congestion Notification).

Capa Transporte 4
ISO/OSI - TCP/IP

7 aplicación 5

6 presentación
5 sesión
4 transporte 4 Usted está aquí
3 red 3

2 enlace 2

1 física 1

Capa Transporte 5
Protocolos de capa transporte en
Internet
 Entrega confiable y en orden (TCP)
 Tiene: control de congestión
 Control de flujo
 Establecimiento de conexión
 Entrega no confiable, tal vez
desordenada: (UDP)
 Básicamente el mismo
servicio que “mejor esfuerzo”
(“best-effort”) IP
 Qué servicios no se ofrecen:
 Garantías de retardo
 Garantías de ancho de banda
(Básicamente porque no es posible
ofrecerlo basándose en los
servicios de IP) Capa Transporte 6
Métodos de control de flujo y
control de errores
 Control de flujo
 Control de flujo mediante Parada-Espera
 Control de Flujo mediante Ventana Deslizante (TCP)

 Control de errores
 Detección de errores
• Suma de comprobación de Internet (TCP)
• CRC Comprobación de redundancia cíclica
 Corrección de errores
Métodos ARQ Automatic Repeat reQuest, Solicitud de repetición
automática
• ARQ con parada y espera
• ARQ con Adelante atrás N (Go-Back-N) (TCP)
• ARQ con Repetición Selectiva (SR) (TCP)
Capa Transporte 8
Comunicación confiable
Aplicación P1 P2 P1 P2

datos datos datos datos

envio_rdt() entregar()
protocolo rdt protocolo rdt
Transporte canal confiable
(emisor) (receptor)
envio_udt() recep_rdt()
paquete paquete

Red canal no confiable

Servicio provisto Implementación

rdt_ : reliable data transfer- transferencia de datos fiable

udt_ : unreliable data transfer - transferencia de datos no fiable

Capa Transporte 9
Comunicación confiable
envio_rdt(): invocado desde entregar(): invocado por
arriba, suministra los datos el protocolo para entregar
a ser enviados los datos recibidos
P1 P2
datos datos
envio_rdt() entregar()
protocolo rdt protocolo rdt
(emisor) (receptor)
envio_udt() recep_rdt()
paquete paquete

canal no confiable
envio_udt(): invocado por recep_rdt(): invocado por
el protocolo para transferir el protocolo cuando llega
un paquete a través del canal un nuevo paquete al receptor
no confiable

Capa Transporte 10
Operatoria stop-and-wait

envío del primer bit (t = 0)

envío del último bit (t = L/R)

recep. del primer bit

recep. del último bit
RTT
envío del ACK

recep. del ACK (t = L/R + RTT)

comienza el envío del sig. paq.

L/R .008 ms
uenlace= = = 0.027%
RTT + L/R 30.008 ms

Capa Transporte 11
Operatoria en pipeline

envío del primer bit (t = 0)

envío del último bit (t = L/R)

recep. del primer bit

último bit 1er. paq. / envío ACK
RTT
último bit 2do. paq. / envío ACK

recep. del ACK, comienza el envío último bit 3er. paq. / envío ACK
del sig. paq. (t = L/R + RTT)

¡mejora la utilización
por un factor de 3!

3 x L/R .024 ms
uenlace= = = 0.08%
RTT + L/R 30.008 ms
Capa Transporte 14
Protocolo Go-Back-N
 El protocolo GBN implementa la operatoria
en pipeline comentada.
 Se reservan k bits del encabezado para los números de secuencia de
los paquetes.
 Se permiten hasta una ventana deslizante de N paquetes en tránsito,
esto es, cuya confirmación de su recepción aún no ha sido recibida.

ventana deslizante
de tamaño N

ACK ya todavía
enviados a ser enviados no usables
recibido
esperando ACK
Capa Transporte 15
 Go-Back-N
Transmisor:
 # de secuencia de k-bits en el encabezado del paquete
 “ventana” de hasta N paquetes consecutivos con acuse de recibo pendiente

Núm. Sec. más antiguo Próximo número de secuencia a n° sec.

sin ACK: base usar: nextseqnum Con ACK
Usable, aún
recibidos
no enviados
ACK n° sec.
pendientes No usable
Tamaño de
ventana N
 Cuando llega un ACK(n): da acuse de recibo a todos los paquetes ,
incluyendo aquel con # de secuencia n; corresponde a un “acuse de recibo
acumulado”
 Podría recibir ACKs duplicados (ver receptor)‫‏‬
 Usa un timer para manejar la espera de ack de paquete en tránsito
 timeout(n): retransmitir paquete n y todos los paquetes con número de
secuencia siguientes en la ventana.
Capa Transporte 16
Go-Back-N: Análisis versión
texto guía.
 Idea Básica:
 Tx: Enviar hasta completar ventana.
 Rx: Sólo aceptar paquete correcto y en orden
 En caso de error o pérdida:
 Tx: Lo detecta por timeout y repite envío desde
el perdido o dañado.

Capa Transporte 17
Análisis GBN
 El
receptor sólo envía un mensaje de ACK para el
paquete correctamente recibido con mayor número
de secuencia.
 Esta política puede generar mensajes de ACK duplicados.
 El receptor sólo necesita recordar el número de secuencia
del próximo paquete que desea.

 Lospaquetes recibidos fuera de orden

son descartados.
 El receptor no requiere almacenamiento intermedio.

Capa Transporte 18
GBN en acción

envío paq. 0
envío paq. 1
envío paq. 2 recep. paq. 0, envío ACK 0
envío paq. 3 (agota la ventana) recep. paq. 1, envío ACK 1

recep. paq. 3 (se descarta)

recep. ACK 0, envío paq. 4 reenvío ACK 1
recep. ACK 1, envío paq. 5 recep. paq. 4 (se descarta)
reenvío ACK 1
disparo de alarma, reenvío paq. 2 recep. paq. 5 (se descarta)
reenvío paq. 3 reenvío ACK 1
reenvío paq. 4 recep. paq. 2, envío ACK 2
reenvío paq. 5 recep. paq. 3, envío ACK 3
recep. paq. 4, envío ACK 4
recep. paq. 5, envío ACK 5
Demo Demo

Capa Transporte 19
Repetición Selectiva (SR)
 El
protocolo Repetición Selectiva (SR) es otra
implementación de la operatoria en pipeline.
 La idea central es disminuir el número de paquetes
a ser reenviados al recuperarse de una pérdida.

A diferencia de GBN, el receptor reconoce

por separado a cada uno de los paquetes
correctamente recibidos.
 El receptor debe contar con un almacenamiento intermedio
para alojar los paquetes recibidos correctamente pero
fuera de orden.
Capa Transporte 20
Selective Repeat (repetición selectiva)‫‏‬

 Receptor envía acuse de recibo individuales de

todos los paquetes recibidos
 Almacena paquetes en buffer, según necesidad para su
entrega en orden a la capa superior
 Transmisor sólo re-envía los paquetes sin ACK
recibidos
 Transmisor usa un timer por cada paquete sin ACK
 Ventana del Transmisor
 N #s de secuencia consecutivos
 Nuevamente limita los #s de secuencia de paquetes
enviados sin ACK
Capa Transporte 21
Escenarios de retransmisión:
Pérdida de un paquete
emisor receptor

envío paq. 0
recep. paq. 0
envío ACK 0
recep. ACK 0
envío paq. 1
Expira el paquete
temporizador pérdido

disparo de alarma
reenvío paq. 1
recep. paq. 1
envío ACK 1
recep. ACK 1

Capa Transporte 24
Escenarios de retransmisión:
Pérdida de un ACK
emisor receptor

envío paq. 0
recep. paq. 0
envío ACK 0
recep. ACK 0
envío paq. 1
recep. paq. 1
Expira el envío ACK 1
temporizador
ACK
disparo de alarma pérdido
reenvío paq. 1
recep. paq. 1 (duplicado detec.)
reenvío ACK 1
recep. ACK 1

Capa Transporte 25
Escenarios de retransmisión:
Reenvío prematuro
emisor receptor

envío paq. 0
recep. paq. 0
envío ACK 0

disparo de alarma
reenvío paq. 0
recep. paq. 0 (duplicado detec.)
recep. ACK 0
reenvío ACK 0
envío paq. 1
recep. ACK 0 recep. paq. 1
(duplicado detec.) envío ACK 1
recep. ACK 1

Capa Transporte 26
Visión del emisor y receptor
enviados, ACK ya recibido recibidos fuera de orden, ACK ya enviado
enviados, esperando ACK a la espera, aún no recibidos
usables, a ser enviados aceptables
no usables no usables
ventana deslizante

emisor SR

ventana deslizante

receptor SR

Capa Transporte 27
Emisor SR
 Elemisor SR debe reaccionar ante los eventos que
se presenten de la siguiente manera:
 Al recibir un nuevo paquete a ser enviado debe verificar si
el siguiente número de secuencia se encuentra dentro de la
ventana.
 Al dispararse la alarma de un paquete debe reenviar sólo
ese paquete y debe reiniciar el temporizador.
 Al recibir un ACK debe marcar ese paquete como recibido
y en caso de ser el menor número de paquete del cual
faltaba recibir confirmación, debe avanzar la ventana
hasta el próximo paquete aún sin confirmar.
Capa Transporte 28
Receptor SR
 El
receptor SR debe reaccionar ante los eventos
que se presenten de la siguiente manera:
 Al recibir un paquete con número de secuencia base
se envía su ACK y se avanza la ventana hasta el próximo
paquete esperado pero aún no recibido.
 Al recibir un paquete con número de secuencia entre
base+1 y base+N-1 se envía su ACK y se guarda
provisoriamente en el almacenamiento intermedio.
 Al recibir un paquete con número de secuencia entre base-
N y base-1 sólo se envía su respectivo ACK.
 En cualquier otro caso, no se toma acción alguna.
Capa Transporte 29
Protocolo SR en acción
enviados conf. enviados no conf. fuera de orden
a la espera usables no usables

0 1 2 3 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8 9 0 1 23456789
0 1 2 3 4 5 6 7 8 9 0 1 23456789
alarma
0 1 23456789
paq. 2 0 1 23456789
0 1 23456789
0 1 23456789
0 1 23456789 0 1 23456789
0 1 23456789
0 1 23456789

Capa Transporte 30
El dilema del receptor SR
enviados conf. enviados no conf. fuera de orden
a la espera usables no usables

Ejemplo:
0 1 230 1 2
 #s de sec.: 0, 1, 2, 3 0 1 230 1 2
 Tamaño de ventana=3 0 1 230 1 2 0 1 230 1 2
 Rx no ve diferencia en
0 1 230 1 2
0 1 230 1 2
los dos escenarios!
 Pasa incorrectamente 0 1 230 1 2
datos como nuevos en 0 1 230 1 2
(a)‫‏‬ 0 1 230 1 2 0 1 230 1 2
0 1 230 1 2
Q: ¿Qué relación debe
0 1 230 1 2
existir entre el # de
sec. y el tamaño de
ventana?
Capa Transporte 31
El dilema del receptor SR
enviados conf. enviados no conf. fuera de orden
a la espera usables no usables

0 1 230 1 2
0 1 230 1 2
0 1 230 1 2 0 1 230 1 2
alarma
0 1 230 1 2
paq. 0
0 1 230 1 2

0 1 230 1 2

0 1 230 1 2

¡SR entrega un paquete

fuera de orden!

Capa Transporte 32
Análisis SR
 El
receptor SR no tiene forma de distinguir entre
estos dos escenarios.
 En el primer caso el funcionamiento es el esperado, pero en
el segundo caso, SR termina entregando un paquete fuera
de orden.

 ¿Qué relación tiene que cumplirse entre el tamaño

de ventana y el conjunto de números de secuencia
disponibles?
 El tamaño de ventana debe ser menor o igual a la mitad de
la cantidad de números de secuencia.
Capa Transporte 33
TCP:Transmission Control Protocol
 Es un protocolo punto a punto.
 Permite intercambiar un flujo de bytes.
 No requiere delimitadores de mensajes.

 Implementa una operatoria en pipeline.

 Los mecanismos de control de flujo y de congestión
determinan el tamaño de la ventana deslizante.

 Hace uso de almacenamiento intermedio tanto al

enviar como al recibir.

Capa Transporte 34
Transmission Control Protocol
 Posibilita la transferencia bidireccional de datos.
 Una misma conexión permite enviar y recibir datos.
 El parámetro MSS denota el tamaño máximo de segmento
aceptado por una dada implementación.
 Es orientado a la conexión.
 Requiere una fase previa de inicialización antes
de comenzar con el intercambio de información.
 Implementa control de flujo.
 El emisor nunca satura de datos al receptor.

Capa Transporte 35
Estructura de un segmento TCP
ACK denota que el nro. se cuenta a nivel
de reconocimiento es válido 32 bits
de bytes, no a nivel
puerto origen puerto dest. de paquetes
URG permite marcar a
los datos como urgentes número de secuencia
número de reconocimiento
PSH solicita se procesen
lon. - u a p r s f ven. de recep.
los datos del buffer
checksum punt. urgente
RST, SYN, FIN se utilizan
opciones (tam. variable)
para establecer y finalizar
campo para publicitar
conexiones.
datos de la aplicación el tamaño de la ventana
checksum (tam. variable) de recepción
(análogo a UDP)
formato de
un segmento TCP

Capa Transporte 36
 TCP numero de seq., ACKs
segmento saliente del emisor
Numeros de sequencia: source port # dest port #
sequence number

flujo de bytes, “número” del acknowledgement number

rwnd

primer byte en el segmento checksum urg pointer

Tamaño de ventana
de datos.
Reconocimientos:
espacio de números de secuencia
 # seq. del siguiente byte
esperado desde el otro lado segmentos
reconocidos
Seg no
reconoc.,
usables No
pero no usables
“en vuelo” enviados
ACK acumulativo
segmento entrante al emisor
P: ¿como maneja el receptor los source port # dest port #

segmentos fuera de orden?

sequence number
acknowledgement number
A
R: TCP no dice nada, esta a cargo checksum
rwnd
urg pointer

del implementador. Capa Transporte 37

Secuencia y reconocimiento
 El
número de secuencia de un segmento indica la
posición del byte transferido dentro del flujo de bytes
de la conexión.
 El
número de reconocimiento indica el próximo número
de secuencia esperado del otro lado.
 TCP hace uso de reconocimientos acumulativos, esto es, al
reconocer un cierto número de secuencia se reconocen
implícitamente todos los anteriores.
 Laespecificación formal nada dice acerca de qué hacer
con los segmentos fuera de orden.

Capa Transporte 38
Secuencia y reconocimiento
cliente telnet servidor telnet

el usuario escribe una 'C'

el servidor reconoce
el mensaje y muestra
la 'C' por pantalla
el cliente reconoce
la recepción del echo
de la 'C'

Capa Transporte 39
Round Trip Time y Timeout en TCP
Q: ¿Cómo fijar Q: ¿Cómo estimar el
valor de timeout RTT?
en TCP?  SampleRTT: mide tiempo
desde tx del segmento
 Mayor que RTT hasta recibo de ACK
pero RTT varía
 Ignora retransmisiones


 Muy corto: timeout  SampleRTT varía, hay que

prematuro suavizar el RTT estimado
 Retransmisiones  Promediar varias
innecesarias medidas recientes, no
 Muy largo: lenta considerar sólo el último
reacción a pérdidas SampleRTT
de segmentos
Capa Transporte 40
 Round Trip Time y Timeout en TCP
EstimatedRTTi=(1-)*EstimatedRTTi-1+*SampleRTTi

 Promedio móvil ponderado exponencial

 Influencia de las muestras pasadas decrece
exponencialmente rápido
 Valor típico: = 0.125 = (1/8)

Capa Transporte 41
Ejemplo de estimación de RTT:
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300

250
RTT (milliseconds)

200

150

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)

SampleRTT Estimated RTT

Capa Transporte 42
Timeout en TCP
 Timeout usa EstimatedRTT más un “margen de seguridad”
 Si hay gran variación en EstimatedRTT -> usar mayor margen
 Primero estimamos cuánto se desvía el SampleRTT del
EstimatedRTT:

DevRTTi=(1-)*DevRTTi-1 + *|SampleRTTi-EstimatedRTTi|

(típicamente,  = 0.25)‫‏‬

Entonces fijamos el timeout como:

TimeoutIntervali = EstimatedRTTi + 4*DevRTTi

Capa Transporte 43
Capa Transporte: Contenidos
 Transporte orientado a la conexión: TCP
 Estructura de un segmento
 Transferencia confiable de datos
 Control de flujo
 Gestión de la conexión
 Principios del control de congestión
 Control de congestión en TCP
 Notificación Explícita de Congestión
(ECN, Explicit Congestion Notification).

Capa Transporte 44
Transferencia confiable de datos
en TCP
 TCP crea un servicio  Retransmisiones son
de transferencia activadas por:
confiable sobre el  Eventos de timeout
servicio no confiable  ACKs duplicados
de IP  Inicialmente
 Usa segmentos en un consideremos un Tx
pipeline TCP simplificado:
 ACKs acumulativos  Ignora ACKs duplicados
Ignora control de flujo
 TCP usa un timer de

y control de congestión
retransmisión único
Capa Transporte 45
 Eventos del transmisor en TCP:
Datos recibidos desde
aplicación:
 Crea segmento con # de sec.
 # sec es el número dentro
del flujo para el primer byte
del segmento
 Inicia timer si no está ya
corriendo (asociar el timer al
segmento más viejo sin acuse
de recibo)‫‏‬
 Tiempo de expiración:
TimeOutInterval
Timeout:
 Retransmitir el segmento
que causó el timeout
 Típicamente el intervalo del
timeout se duplica en
retransmisiones. ¿Por qué?
 Re-iniciar el timer
Recepción de ACK:
 Si es el ACK de un
segmento previo sin acuse
de recibo
 Actualizar estado sobre
acuses recibidos
 Iniciar timer si hay
segmentos sin acuses de
recibo.
Capa Transporte 46
 TCP: Retransmisiones Rápidas
 Periodo de Time-out es a  Si Tx recibe 3 ACKs de
menudo largo: un mismo dato, éste
 Largo retardo antes de re- supone que el segmento
envío de paquetes perdidos después de este dato se
 Se detecta paquetes perdió:
perdidos vía ACKs  Retransmisiones rápidas:
duplicados. reenviar el segmento
antes que el timer expire.
 Tx a menudo envía muchos
segmentos seguidos
 Si un segmento es perdido,
probablemente habrá
muchos ACKs duplicados.

Capa Transporte 47
TCP: Retransmisión Rápida
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data
X

ACK=100
timeout

ACK=100
ACK=100
ACK=100
Seq=100, 20 bytes of data

Retransmisión rápida, despues de que

el receptor recibe 3 ACK duplicados Capa Transporte 48
TCP: Timeout
Doblando el tiempo del timeout
 Algunas modificaciones en muchas implementaciones de TCP:
 La primera concierne al largo de tiempo del intervalo del timeout
después que el timer expira
 En esta modificación cuando ocurre un timeout, TCP retransmite el
segmento sin ACK con el número menor de secuencia pero para cada
retransmisión TCP duplica el valor previo de TimeoutInterval
 De esta forma los intervalos crecen exponencialmente después de
cada retransmisión

 La segunda es si se recibe otro evento como datos recibidos de la

aplicación o ACK recibido entonces se recalcula TimeoutInterval
usando EstimatedRTT y DevRTT
 Esta es una forma limitada de control de congestión

Capa Transporte 50
Capa Transporte: Contenidos
 Transporte orientado a la conexión: TCP
 Estructura de un segmento
 Transferencia confiable de datos
 Control de flujo
 Gestión de la conexión
 Principios del control de congestión
 Control de congestión en TCP
 Notificación Explícita de Congestión
(ECN, Explicit Congestion Notification).

http://wps.aw.com/aw_kurose_network_5/
Capa Transporte 51
 Control de flujo en TCP: Cómo
trabaja  Rx comunica el espacio
libre a través del valor
de RcvWindow en los
segmentos
 Así el receptor limita
datos en transito (sin
(supongamos que el receptor descarta ACK) a RcvWindow (Tx
segmentos fuera de orden)‫‏‬ debe respetar el no
 Espacio libre en buffer envío de más datos que
RcvWindow = RcvBuffer - RcvWindows)‫‏‬
[LastByteRcvd - LastByteRead]
 Esto garantiza que el
buffer del Rx no se
rebalse (overflow)‫‏‬
Capa Transporte 52
Estructura de un segmento TCP
ACK denota que el nro. se cuenta a nivel
de reconocimiento es válido 32 bits
de bytes, no a nivel
puerto origen puerto dest. de paquetes
número de secuencia
número de reconocimiento
lon. - u a p r s f ven. de recep.
checksum punt. urgente
opciones (tam. variable)
campo para publicitar
datos de la aplicación el tamaño de la ventana
(tam. variable) de recepción

formato de
un segmento TCP

Capa Transporte 53
Control de flujo en TCP: Cómo
trabaja
 El Transmisor debe tomar en cuenta los segmentos en
tránsito
 Luego el número de bytes que el Tx puede enviar es en
general menor que el anunciado por la RevWindows.
 ¿Cuál es la expresión para el número de Bytes posibles
de enviar sin colapsar al receptor?

Capa Transporte 54
Capa Transporte: Contenidos
 Transporte orientado a la
conexión: TCP
 Estructura de un segmento
 Transferencia confiable de
datos
 Control de flujo
 Gestión de conexión TCP
 Principios del control de
congestión
 Control de congestión en
TCP

Capa Transporte 55
 Gestión de Conexión en TCP
Recordar: Transmisor y
receptor TCP establecen una
“conexión” antes de
intercambiar segmentos de
datos
 TCP inicializa variables:
 # de secuencia
 buffers, información de
control de flujo (e.g.
RcvWindow)‫‏‬
 cliente: Iniciación de conexión
Socket clientSocket = new
Socket("hostname","port
number");
 server: contactado por cliente
Socket connectionSocket =
welcomeSocket.accept();
Saludo de manos de tres vías
(Three way handshake):
Paso 1: host cliente envía
segmento TCP SYN al servidor
 Especifica # secuencia inicial
 no data
Paso 2: host servidor recibe
SYN, responde con segmento
SYN & ACK
 Servidor ubica buffers
 Especifica # secuencia inicial
Paso 3: cliente recibe SYN & ACK,
responde con segmento ACK, el
cual podría contener datos.
Capa Transporte 56
Gestión de Conexión en TCP (cont.)‫‏‬

 Establecimiento de conexión

Host Host
cliente servidor
Solicitud de
Conexión
Conexión
concedida

ACK

Capa Transporte 58
 Gestión de conexiones en TCP
 Recordemos que TCP previo al comienzo
del intercambio de segmentos debe establecer
la conexión entre las partes involucradas.
 Durante la fase de establecimiento de
la conexión se inicializan las variables TCP
tales como:
 Número de secuencia inicial (base, proxnumsec).
 Almacenamientos intermedios (bufrecep).
 Tamaño de la ventana de recepción (ventrecep).

Capa Transporte 59
Establecimiento de conexión
 El
establecimiento de una conexión consiste
en un simple intercambio de segmentos TCP
específicos.
 El cliente envía un segmento TCP con el flag SYN activado,
informando el número de secuencia inicial.
 El servidor contesta con un segmento TCP los flags SYN y
ACK activados, confirmando la recepción del
SYN e informando su número de secuencia inicial.

 Existeun problema: ¡este procedimiento sólo

resulta válido si no se pierden mensajes!
Capa Transporte 60
Saludo de tres fases
 TCPimplementa una versión mejorada del
procedimiento anterior denominada saludo de tres
fases (three way handshake):
 El cliente manda un segmento TCP con el flag SYN, al igual
que antes. Este segmento no contiene datos.
 El servidor contesta con un segmento TCP con los flags
SYN y ACK activados, al igual que antes.
 El cliente confirma establecimiento de la conexión
contestando con un segmento TCP con el flag ACK
activado. Este segmento puede contener datos.
Capa Transporte 61
Finalización de una conexión
 Lafinalización de una conexión es un tanto similar al
establecimiento, si bien se debe tener en cuenta
que la comunicación es bidireccional.
 En primer lugar el cliente envía un segmento TCP con el
flag FIN activado. Con esta acción comienza a cerrar la
conexión.
 El servidor al recibir este segmento contesta con otro
segmento TCP con el flag ACK activado, comienza a cerrar
la conexión y como última acción manda un segmento TCP
con el flag FIN activado al cliente.

Capa Transporte 62
Finalización de una conexión
 Continúa:

 El cliente al recibir este segmento contesta a su vez con

otro segmento TCP con el flag ACK activado, termina de
cerrar la conexión y entra en una fase de espera
temporizada.
 Duramente esta fase de espera el cliente contestará con
mensajes de reconocimiento a todo pedido de desconexión
que reciba del servidor.
 Finalmente cuando el servidor reciba el segmento de
reconocimiento por parte del cliente también terminará de
cerrar la conexión.
Capa Transporte 63
Finalización de una conexión
cliente servidor

comienza a cerrar

comienza a cerrar

espera temporizada
termina de cerrar
termina de cerrar

Capa Transporte 64
Finalización de una conexión
cliente servidor

comienza a cerrar

comienza a cerrar

espera temporizada
termina de cerrar
termina de cerrar

Capa Transporte 65
Gestión de la Conexión TCP (cont)‫‏‬

Ciclo de vida
del servidor TCP

Ciclo de vida del

cliente TCP

Capa Transporte 66
¿Preguntas?

Capa Transporte 67
Clase 02 - Capa Transporte:
Contenidos
 Transporte orientado a la conexión: TCP
 Estructura de un segmento
 Transferencia confiable de datos
 Control de flujo
 Gestión de conexión TCP
 Principios del control de congestión
 Control de congestión en TCP
 Notificación Explícita de Congestión
(ECN, Explicit Congestion Notification).

http://wps.aw.com/aw_kurose_network_5/
Capa Transporte 68
Principios del control de congestión
 Lacongestión se produce cuando los nodos envían
una cantidad tal de información que la red no
alcanza a procesarla correctamente.
 No confundir con el control de flujo.

 ¿Cómo se manifiesta la congestión en la red?

 Por la pérdida de paquetes producto de la saturación del
almacenamiento intermedio de los routers.
 Por el incremento en los retardos producto del aumento del
tiempo de encolado en los routers.

Capa Transporte 69
Control de congestión
 Antes de abordar cómo evitar la congestión nos
concentraremos en entender cuáles son las causas
de la congestión y cuáles son sus consecuencias.
 Laidea es partir de un escenario simplificado, más
simple de analizar, para luego considerar situaciones
más próximas al mundo real.
 Esto es, seguiremos un acercamiento análogo al adoptado
para abordar introducir los desafíos asociados a la
transmisión confiable de datos.

Capa Transporte 70
Congestión con buffer infinito
 Como primer escenario consideremos la siguiente
situación:
 Dos emisores y dos receptores.
 Un único router que los comunica.
 El router cuenta con un almacenamiento intermedio
infinito.

 Alcontar con un buffer infinito, los paquetes no se

pierden, por lo que tampoco se debe retransmitir
paquete alguno.

Capa Transporte 71
Congestión con buffer infinito

buffer infinito
...

ancho de banda R

retardos

out

R/2 R/2
in in

Capa Transporte 72
Congestión con buffer finito
 Consideremos ahora un escenario análogo al
anterior, pero con el router contando con una
cantidad finita de almacenamiento intermedio.
 La eventual pérdida de paquetes ahora causa la
retransmisión de los mismo.
 Idealmente queremos que in = .
out

 Una retransmisión “perfecta” es producto únicamente de

las pérdidas de paquetes.
 Por otra parte, las retransmisiones de paquetes demorados
incrementan la tasa efectiva 'in.
Capa Transporte 73
Estrategias para control de congestión
Los podemos clasificar en dos grupos amplios:

Control de congestión Control de congestión

extremo a extremo:
 No hay información de
realimentación explícita de la
red
 La congestión es inferida desde
las pérdidas y retardos
observados por terminales en
los extremos
 Es la estrategia usada por
TCP
asistido por la red:
 Routers proveen realimentación
a sistemas extremos
 Un Bit único indicando
congestión (e.g. SNA,
DECbit, TCP/IP ECN, ATM)‫‏‬
 Explícitamente se informa al
Tx la tasa que el router
puede soportar

Capa Transporte 74
Capa Transporte: Contenidos
 Transporte orientado a la conexión: TCP
 Estructura de un segmento
 Transferencia confiable de datos
 Control de flujo
 Administración de conexión
 Principios del control de congestión
 Control de congestión en TCP
 Notificación Explícita de Congestión
(ECN, Explicit Congestion Notification).

Capa Transporte 77
Control de congestión en TCP
Adiferencia de ATM, TCP adopta un esquema de
control de congestión extremo a extremo.
 Por ende no recibe asistencia del núcleo de la red.
 El emisor limita su tasa de transmisión respetando la
relación [ultbyterec - ultbyteent] < ventcong.
 Por así decirlo, el tamaño de la ventana de congestión es
una función dinámica que depende del nivel de congestión
en la red percibido por el emisor.
Ver simulación en:
http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/fairne
ss/index.html
Capa Transporte 78
Control de congestión en TCP
 ¿Cómohace el emisor para percibir el nivel de
congestión en la red?
 Tomando nota de los eventos de pérdida.
 Se produce un evento de pérdida toda vez que se vence el
tiempo de espera TCP o bien cuando se reciben tres ACK
para el mismo segmento TCP.
 El emisor responde ante un evento de pérdida reduciendo
su ventana de congestión.

 Se han implementado diversas políticas que mejoran

la respuesta de este mecanismo.
Capa Transporte 79
TCP AIMD
 TCP adopta la política AIMD (Additive Increase
Multiplicative Decrease) Crecimiento aditivo Decrecimiento
multiplicativo para controlar el tamaño de la ventana de
congestión.
 El emisor incrementa de manera lineal su ventana de congestión a cada
RTT, pero ante un evento de pérdida se reduce exponencialmente a la
mitad.

tamaño de
la ventana de
congestión

tiempo

Capa Transporte 81
TCP slow start
 Alcomenzar, la política AIMD puede tomar un
tiempo excesivo en alcanzar el régimen óptimo.
 Consideremos el siguiente ejemplo:
 RTT = 200ms y MSS = 500 bytes.
 Inicialmente ventcong = 1, pero MSS/RTT = 20 Kbps.
 Si se dispone de un mayor ancho de banda, TCP va
a tardar bastante tiempo hasta hacer uso del mismo.
 La política slow start indica que al comenzar se debe
agrandar exponencialmente la ventana de congestión hasta
que se detecte el primer evento de pérdida.
Capa Transporte 83
TCP slow start

un segmento

RTT ventcong se duplica

al pasar un RTT
dos segmentos (es decir, cada vez
que recibe un ACK)

cuatro segmentos

Capa Transporte 85
Ajuste fino
 TCPtiene una política de ajuste sutil en función de
cómo se detecto la congestión.
 Si se reciben tres ACK para el mismo segmento:
 ventcong se reduce a la mitad.
 de ahí crece linealmente como siempre.

 Si se vence el tiempo de espera TCP:

 ventcong se reduce a 1.
 de ahí crece exponencialmente hasta alcanzar un
determinado umbral para luego crecer linealmente.
Capa Transporte 86
 Refinamiento a Partida Lenta en TCP
 Después de 3 ACKs Filosofía:
duplicados: •3 ACKs duplicados indican
 CongWin baja a la mitad la red es capaz de
 Luego la ventana crece transportar algunos
linealmente segmentos (sólo llegan
 Después de un timeout: fuera de orden en el Rx).
 CongWin es fijada en 1 Se perdió uno pero llegaron
MSS; los otros y por eso tenemos
 Luego la ventana crece ACKs duplicados
exponencialmente hasta • timeout antes de 3
un umbral, luego crece duplicados es “más
linealmente alarmante” (no llegaron!)‫‏‬
Capa Transporte 88
Refinamiento a Partida Lenta en TCP (cont)‫‏‬
Q: ¿Cuándo debería Evento: 3 ACKs Duplicados
cambiar el aumento de
exponencial a lineal? Mejor
A: Un buen criterio es:
Cuando CongWin llega
a 1/2 de su valor antes
del timeout.
umbral

Implementación:
 Umbral variable (variable
Tahoe: primera versión de control de
threshold)‫‏‬
 Ante evento de pérdidas, el
congestión en TCP. No distinguía
umbral es fijado en 1/2 de entre timeout o ACK duplicados.
CongWin justo antes de la Reno: versión siguiente en TCP. Sí
pérdida
distingue timeout de ACK duplicados.
Es como TCP opera hoy.
Capa Transporte 89
Resumen: Control de Congestión en TCP

 Cuando CongWin está bajo el Threshold

(umbral), Tx está en fase slow-start, la ventana
de transmisión crece exponencialmente.

 Cuando CongWin está sobre Threshold, Tx está

en fase abolición de congestión, la ventana crece
linealmente.

 Cuando llegan tres ACK duplicados, Threshold

pasa a CongWin/2 y CongWin pasa a Threshold.

 Cuando ocurre un timeout, Threshold pasa a

CongWin/2 y CongWin se lleva a 1 MSS.

Capa Transporte 91
En síntesis
 Mientras ventcong <= umbral, el emisor está en la fase
“slow start”, por lo que la ventana debe crecer
exponencialmente.
 Cuando ventcong > umbral, el emisor entra en la fase de
“evasión de congestión”, por lo que ahora la ventana crece
linealmente.
 Si se reciben tres ACK repetidos, tanto umbral como
ventcong se ajustan a ventcong/2.
 Al vencerse el tiempo de espera TCP, se hace
umbral = ventcong/2 y luego ventcong = 1.

Capa Transporte 92
Versiones de TCP
 TCP de Berkeley (1983)

 TCP TAHOE (1988)

 TCP RENO (1990)

Capa Transporte 95
Versiones de TCP: Berkeley
TCP de Berkeley (1983): versión más antigua y con
menos algoritmos. Se basaba en el control de flujo
entre emisor y receptor. Todos los problemas se
resolvían entre los dos extremos sin considerar lo que
ocurre en la red. Objetivo no ser compleja. No ofrece
buen resultado en redes diferentes, congestionadas o
de mala calidad, pues sólo tiene en cuenta el tamaño de
la ventana del receptor y no considera el tamaño de la
ventana de la red.

Capa Transporte 96
Versiones de TCP: TAHOE
TCP TAHOE (1988): usa los algoritmos Slow Start y
Congestion Avoidance para detectar estado de la red y
el control de flujo para disminuir la pérdida de
segmentos. Se incluye Fast Retransmit para poder hacer
la retransmisión de segmentos perdidos lo más
rápidamente posible sin esperar a que expire el time-out.

Capa Transporte 97
Versiones de TCP: RENO
TCP RENO (1990): la ventana de congestión crece según
Slow Start hasta llegar a un umbral previamente definido
a partir del cual comienza fase de evitación de
congestión creciendo la ventana de forma lineal. Es
Tahoe con Fast Recovery que evita, en lo posible, que el
tamaño de la ventana llegue a uno y se inicie la fase Slow
Start en redes que presentan una determinada
congestión con picos de gran congestión.

Capa Transporte 98
Equidad TCP
 Imaginemos que dos sesiones TCP compiten por
hacer uso de la totalidad del ancho
de banda de un determinado enlace.
 El incremento lineal de la ventana de congestión
hace que ambas sesiones vayan consumiendo
partes equitativas de ese ancho de banda.
 El retroceso exponencial que se produce ante
los eventos de pérdida también se dispara en
ambas sesiones.
 Por ende, se converge hacia un uso equitativo
del enlace entre las sesiones.
Capa Transporte 99
Equidad TCP vs. UDP
 Lasaplicaciones multimediales suelen no hacer uso
de TCP.
 Precisamente, el control de congestión lejos de ser una
virtud sería un inconveniente.
 No es deseable que la ventana de transmisión ni la de
congestión detengan el flujo de datos.

 Por
esta razón, las aplicaciones multimediales suelen
hacer uso de UDP.
 Envían datos a un ritmo constante, tolerando la eventual
pérdida de algún paquete.
Capa Transporte 100
Conexiones TCP paralelas
 ¿Cómo interactúa la equidad TCP con el
establecimiento de conexiones en paralelo?
 Nada impide que una misma aplicación abra
una cantidad de conexiones en paralelo.

 Porcaso, supongamos que un enlace de capacidad R

está soportando 9 conexiones.
 Si una cierta aplicación abre una nueva conexión, recibirá
apenas R / 10 del canal.
 Si más tarde otra aplicación abre 10 nuevas conexiones,
recibirá en cambio R / 2 del canal.
Capa Transporte 101
¿Por qué TCP es justa?
Supongamos dos sesiones compitiendo:
 Aumento aditivo da pendiente de 1, como aumento de throughout
 Reducción multiplicativa reduce throughput proporcionalmente

R Igual bandwidth compartido

Throughput Conexión 2

Pérdida: decrece ancho de banda en factor de 2

Abolición de congestión: aumento aditivo

Pérdida: decrece ancho de banda en factor de 2

Abolición de congestión: aumento aditivo

Throughput Conexión 1 R
Capa Transporte 102
 Equidad (más)‫‏‬
Equidad y conexiones TCP paralelas
Equidad y UDP  Nada previene a las aplicaciones
 Aplicaciones Multimedia de abrir conexiones paralelas
no usan TCP entre dos hosts.

 No quieren tasa ahogada  Navegadores WEB hacen esto

por control de congestión  Ejemplo: Sea un enlace de tasa

R soportando 9 conexiones;
 En su lugar usan UDP:
 Una aplicación nueva pide 1
 Envían audio/vídeo a tasa conexión TCP, obtendrá R/10
constante y toleran
 Si la aplicación nueva pide 11
pérdidas de paquetes conexiones TCP, obtendrá
 Área de investigación: 11R/20 , más de R/2!

Hacerlas amistosas con

TCP (TCP friendly)‫‏‬
Capa Transporte 103
Notificación explícita de congestión
(ECN Explicit Congestion Notification)
Control de congestión asistido por la red:
 Dos bits en el encabezado IP (campo ToS) marcada por router de
red para indicar la congestion.
 Indicación de congestión llevada al host receptor.
 El receptor (al ver la marca de congestión en el datagramas IP)
activa el bit de ECE en el segmento ACK para notificar al remitente
de la congestion.
TCP ACK segment
source destination
application application
ECE=1
transport transport
network network
link link
physical physical

ECN=00 ECN=11

Datagrama IP Capa Transporte 104

¿Preguntas?

Capa Transporte 105