La capa de transporte Funciones en capa de transporte

La capa de transporte
Redes de
Computadoras
Funciones en capa de transporte
1
Servicios y protocolos de transporte
z
Se provee comunicación
lógica entre procesos de
aplicación corriendo en
diferentes hosts
–
z
servicios de transporte vs. de
red :
–
–
z
Los protocolos de transporte
corren en sistemas finales
capa de red: transferencia de
datos entre sistemas finales
(hosts)
capa de transporte:
transferencia de datos entre
procesos
La capa de transporte se
apoya en y enriquece los
servicios la capa de red
Protocolos de capa de transporte
Servicios de transporte en Internet :
z
Entrega confiable, ordenada, unicast (uno a uno) : TCP
–
–
–
control de congestión
control de flujo
establece conexión
z
Entrega no confiable (“best-effort”), desordenada, unicast o
multicast (uno a muchos): UDP
z
servicios no disponibles:
–
–
–
tiempo real
garantías de ancho de banda
multicast confiable
2
TCP/IP vs. OSI
Protocolos de transporte en Internet
3
Encapsulación de las PDUs
Multicanalización/demulticanalización
4
Cómo funciona la demulticanalización
z
El host recibe datagramas IP
–
–
–
–
z
cada datagrama tiene dirección
IP fuente, dirección IP destino
cada datagrama carga 1
segmento de capa de transporte
cada segmento trae números de
puerto fuente y destino
recordar: números de puerto
bien conocidos para
aplicaciones específicas
(RFC1700)
host usa direcciones IP y
números de puerto para dirigir
segmento al socket apropiado
demux “connectionless”
z
Crear sockets con números de puerto:
–
–
z
DatagramSocket mySocket1 = new DatagramSocket();
DatagramSocket mySocket2 = new DatagramSocket(13542);
El cliente identifica un socket UDP por la 2-tupla:
(dir IP dest, número puerto dest)
z
Cuando un host recibe un segmento UDP:
–
–
z
verifica número de puerto destino en el segmento
dirige el segmento UDP al socket ese número de puerto
Datagramas IP con dirs IP fuente diferentes y/o
números de puerto dirigidos al mismo socket
5
demux “connectionless”
demux “connection-oriented”
z
socket TCP identificado por 4-tupla única:
–
–
–
–
z
z
host receptor usa los cuatro valores para dirigir el
segmento al socket apropiado
host servidor puede dar soporte a muchos sockets
TCP simultáneos:
–
z
dir IP fuente
número puerto fuente
dir IP destino
número puerto destino
cada socket identificado por su propia 4-tupla
Los servidores Web tienen sockets diferentes para
cada cliente que se conecta
–
HTTP no-persistente tendrá socket diferente para cada
petición
6
demux “connection-oriented”
User Datagram Protocol (UDP)
7
User Datagram Protocol (UDP)
z
z
z
z
Protocolo sin conexión (connectionless).
Provee un servicio de datagramas en mejor
esfuerzo (best-effort) a los sistemas.
Servicio no confiable que no garantiza la
entrega, no entrega en orden y no protege
contra duplicados.
Una computadora puede enviar paquetes sin
haber establecido antes una conexión con el
receptor.
User Datagram Protocol (UDP)
z
No hay ACKs para confirmar recepción.
z
No hay ordenamiento de paquetes.
z
No hay feedback para controlar la velocidad a la que
fluye la información entre las máquinas.
z
Resulta útil en casos donde se prefiere simplicidad.
z
Las capas superiores pueden agregar corrección de
errores, verificación de duplicados, etc.
8
User Datagram Protocol (UDP)
z
Estructura de mensajes UDP
Campos encabezado UDP
z
z
z
Puerto fuente y destino. Usados para
indicar el proceso que origina/recibe.
Longitud. Número de octetos en el
datagrama, incluyendo encabezado
(entonces la longitud mínima 8).
Checksum (opcional). En el destino se
verifica y si no es válido se descarta. Si no
se usa se indica con 0.
9
Puertos
z
Los sistemas pueden tener muchas
comunicaciones simultáneas. ¿Cómo
asignar los paquetes a los procesos
adecuados?
z
Se asigna un identificador llamado número
de puerto.
z
Hay puertos bien conocidos asignados a
servicios estándar.
Servicios estándar
z
Hay puertos asignados (RFC 1700) a
servicios estándares en Internet.
z
En sistemas Unix el archivo /etc/services
tiene la relación de los puertos y los
servicios.
z
Los números de puerto 0 a 1023 están
reservados (por IANA).
10
Servicios estándar
Algunas entradas en /etc/services
Fundamentos de transferencia
confiable
11
Transferencia confiable de datos
z
z
Muy importante en capas de aplicación, transporte y enlace
Está en la lista “top-10” de los tópicos fundamentales en redes
zLas características del canal no confiable determinan la
complejidad del protocolo de transferencia confiable
Transferencia confiable: principios
12
Protocolos stop-and-wait
Protocolos “pipelined”
z
Pipelining: emisor permite múltiples paquetes “en
vuelo”, todavía por confirmar
–
–
rango de números de secuencia debe incrementarse
buffers en el emisor y/o receptor
zDos
formas genéricas de protocolos pipelined: GoBack-N, Selective Repeat
13
Pipelining: mejora utilización
Go-Back-N
z
Emisor:
–
–
z
z
z
# secuencia de k-bits en encabezado
“ventana” de hasta N paquetes consecutivos sin ACK permitidos
ACK(n): hace ACK a todos los paquetes hasta el n (“ACK
acumulativo”)
timer para cada paquete en vuelo
timeout(n): retransmitir paquete n y todos con # secuencia
mayor en la ventana
14
Go-Back-N
Cuatro rangos números de secuencia:
1. 0 hasta send_base – 1: ya enviados y con ACK
2. send_base hasta nextseqnum – 1: enviados y sin
ACK
3. nextseqnum hasta send_base + (N-1): pueden
enviarse
4. mayor que send_base + N: no pueden enviarse
Go-Back-N en
acción
15
Selective Repeat
z
el receptor confirma individualmente todos los
paquetes recibidos correctamente
–
z
el receptor solo reenvía paquetes para los cuales no
se ha recibido ACK
–
z
mete paquetes en buffers, según se necesite, para eventual
entrega ordenada a la capa superior
timer de envío para cada paquete sin ACK
ventana de envío
–
–
N # de secuencia consecutivos
limita # de secuencia de paquetes enviados y sin ACK
Selective repeat: ventanas
16
Selective repeat
Selective repeat en acción
17
Transmission Control Protocol
(TCP)
TCP
z
Protocolo con conexión (connection
oriented).
z
Provee comunicación con confiabilidad,
secuenciamiento, control de flujo y
transmisión tipo streaming.
z
Algunos servicios que usan TCP son ftp,
telnet, rsh, smtp, etc.
18
Encabezado TCP
Operación de TCP
z
Establecimiento de conexión.
19
Operación de TCP
z
Cerrar conexión.
Operación de TCP
Cerrar conexión (caso 1)
z
z
z
z
A: “ya acabé, no tengo mas datos”
B: “OK”
B: “yo también ya acabé”
A: “OK”
20
Operación de TCP
Cerrar conexión (caso 2)
z
z
z
z
A: “ya acabé, no tengo mas datos”
B: “aquí te van mas datos”
B: “yo también ya acabé”
A: “OK”
TCP
z
Una vez establecida la conexión se envían
datos en forma confiable.
z
Existen varias técnicas para ello.
z
TCP es un protocolo con ventanas
deslizantes (sliding windows) que provee
control de flujo.
21
Stop and wait
z
Técnica rudimentaria, usada en protocolos muy
simples.
Stop and wait ARQ
z
Pequeña mejora, detecta pérdidas y retransmite.
22
Ventana deslizante (sliding window)
z
Mayor eficiencia que stop-and-wait.
z
Entrega confiable de paquetes sobre enlaces
no confiables.
z
z
Preserva el orden de transmisión de los
paquetes.
z
Soporte al control de flujo.
Ventana deslizante
Características:
z
Pueden enviarse varios paquetes antes de
recibir el ACK para el primero.
z
Requiere de buffers en ambos extremos.
z
Se usan números de secuencia para marcos
transmitidos.
23
Ventana deslizante
Ventana deslizante
24
Inicio lento (slow-start)
z
Las ventanas se adaptan de forma dinámica para
proveer control de flujo.
z
Se inicia transmitiendo a baja velocidad e
incrementándola hasta recibir notificación del
receptor sobre congestión.
z
El algoritmo es el de slow-start e usa la ventana de
congestión (cwnd).
z
Ver RFC 2001.
Inicio lento (slow-start)
z
Hay un límite para cwnd llamado ssthresh
(slow-start threshold).
z
Cuando ssthresh es rebasado se entra en
control de congestión.
z
Entonces, ssthresh se establece a la mitad
de su valor.
25
Control de congestión
z
Los sistemas en los extremos realizan este control
con TCP.
z
Principio: el transmisor incrementa su ventana hasta
detectar pérdidas, luego la reduce.
z
En slow-start el incremento es multiplicativo.
z
En control de congestión es aditivo.
z
Ver RFC 1323.
Control de congestión
z
Aunque el control de congestión es realizado
por los extremos, los sistemas intermedios
pueden auxiliar.
z
Algunas técnicas son RED (Random Early
Discard) y ECN (Explicit Congestion
Notification).
26
Control de congestión en TCP
Principios del control de congestión
Congestión:
z informalmente: “muchas fuentes enviando
muchos datos demasiado rápido como para
que la red pueda manejarlo”
z diferente del control de flujo
z Manifestaciones (síntomas):
–
–
z
pérdida de paquetes (buffer overflow en
enrutadores)
largos retardos (colas en buffers de enrutadores)
¡uno de los problemas top-10!
27
Control de congestión y de flujo
z
La congestión se presenta en redes muy
cargadas
–
z
cuando esta ocurre los extremos y la red deben
trabajar juntos para minimizarla
En contraste, el control de flujo se lleva a
cabo entre los extremos solamente
–
–
un receptor usa control de flujo para señalar al
emisor que está sobrecargado
el emisor decrementa su flujo o incluso lo
interrumpe
Control de flujo con TCP
z
receptor: informa
explícitamente al emisor
de cantidad
(dinámicamente
cambiante) de espacio
libre de buffer
–
z
RcvWindow campo en
segmento TCP
emisor: mantiene la
cantidad de datos
transmitidos, sin ACK,
menor que RcvWindow
más recientemente
recibida
28
Ventana de recepción
Control de flujo con TCP
29
Control de flujo con TCP
Congestión
z
z
Si ambas fuentes envían con ventanas completas,
puede tenerse colapso por congestión
Otras formas de colapso por congestión :
–
–
Retransmisiones de paquetes grandes tras pérdida de un
solo fragmento
Fuentes sin control por retroalimentación
30
Respuesta a la congestión
z
z
El evitamiento (avoidance) mantiene al sistema
desempeñándose en la “rodilla” de la gráfica
El control entra una vez que el sistema ha
alcanzado un estado de congestión
Enfoques
Dos enfoques generales al control de congestión :
control de congestion
extremo a extremo :
•no hay retroalimentación
explícita de la red
•la congestión se infiere de
pérdidas y retrasos
observados en extremo
•enfoque tomado por TCP
(IP no provee
retroalimentación)
control de congestión
asistido por la red :
•los enrutadores proveen
retroalimentación a los
extremos
•un bit indicando congestión
(SNA, DECnet, TCP/IP ECN,
•ATM)
•tasa explícita la cual debe
enviarse
31
Diseño de control de congestión
z
¿evitamiento o control?
–
–
z
El evitamiento mantiene el sistema en la “rodilla” de la
curva
Pero, para eso, necesita que los enrutadores envíen
señales precisas (algún tipo de retroalimentación)
El host emisor debe ajustar la cantidad de datos que
mete a la red con base en la congestión detectada
–
–
TCP usa sus ventanas para esto
Pero ¿cuál es la estrategia adecuada para incrementar o
decrementar la ventana?
Modelo de feedback de control
z
Se estudia esta pregunta usando un modelo
de feedback de control :
–
–
z
Reducir ventana cuando se percibe congestión
Incrementar la ventana de lo contrario
Restricciones:
–
–
–
Eficiencia
Justicia
Estabilidad o convergencia (el sistema no debe
oscilar significativamente)
32
Separación de funcionalidad
z
El host emisor debe ajustar la cantidad de
datos que mete a la red con base en la
congestión detectada
z
Los enrutadores pueden ayudar :
–
–
Enviando señales de congestión precisas
Aislando fuentes bien comportadas de las mal
comportadas
Manejo de congestión con TCP
33
Causas/costos de congestión:
escenario 1
z
z
z
dos emisores,
dos receptores
un enrutador,
buffers infinitos
no retransmisión
z
z
Grandes retardos
cuando hay congestión
Máximo throughput
teórico alcanzable = C/2
Causas/costos de congestión:
escenario 2
z
z
un enrutador, buffers finitos
retransmisión de paquete perdido
34
Causas/costos de congestión:
escenario 2
Causas/costos de congestión:
escenario 3
z
z
z
cuatro emisores
trayectorias multi-salto
timeout/retransmisión
35
Causas/costos de congestión:
escenario 3
Generalidades
z
Idea
–
–
–
–
z
suponer red best-effort (enrutadores FIFO o FQ)
cada fuente determina capacidad de la red por sí
misma
usar retroalimentación implícita
los ACKs dan ritmo a la transmisión (selfclocking)
Reto
–
–
determinar la capacidad disponible
ajustarse a cambios en la capacidad disponible
36
Generalidades
z
Una colección de mecanismos
interrelacionados:
–
–
–
–
–
Slow start
Evitamiento de congestión
Estimación precisa del timeout de retransmisión
Retransmisión rápida
Recuperación rápida
Generalidades
z
Mantener una ventana de congestión, cwnd
–
z
Ventana máxima de emisión :
–
z
Denota cuánto es capaz de absorber la red
Min(ventana anunciada, cwnd)
Ventana actual de emisión:
–
Ventana max - segmentos sin confirmar
37
Control de congestión TCP
z
z
z
control end-end (sin asistencia de la red)
tasa de transmisión limitada por tamaño de ventana
de congestión, cwnd, sobre segmentos:
w segmentos, cada uno con MSS bytes
enviados en un RTT:
Control de congestión TCP
z
“sondeo” de ancho de
banda utilizable:
z
idealmente: transmitir tan
rápido como se pueda
(cwnd tan grande como se
pueda) sin pérdidas
z
– incrementar cwnd hasta
pérdidas (congestión)
– pérdidas: decrementar
cwnd, luego inicia sondeo
(incrementando) de nuevo
–
dos “fases”
–
–
slow start
evitamiento de
congestión
variables importantes:
–
–
cwnd
ssthresh: define
umbral entre fases
slow start y de
evitamiento de
congestión
38
Slow-start en TCP
z
z
incremento exponencial
(por RTT) en tamaño de
ventana (¡no tan lento!)
evento de pérdida:
timeout (TCP Tahoe)
y/o tres ACKs
duplicados (TCP Reno)
Slow-start en TCP
39
Evitamiento de congestión
z
z
Fin: mantener el punto de operación a la derecha de
la “rodilla”
¿Cómo?
–
–
z
incremento aditivo: inicando de estimación burda
(ssthresh), incrementar cwnd lentamente para sondear
ancho de banda adicional disponible
decremento multiplicativo: cortar tamaño de ventana de
congestión agresivamente si se detecta pérdida.
If cwnd > ssthresh then
cada vez que hay ACK para un segmento
incrementar cwnd por 1/cwnd
i.e. (cwnd += 1/cwnd)
Evitamiento de congestión
z
Emisores establecen ssthresh (umbral de
slow start).
z
Cuando se tira un paquete se reduce
ssthresh a la mitad de su valor original.
z
Regresar a modo de slow-start.
z
Exponencialmente incrementar transmisión
hasta ssthresh, luego linealmente.
40
Slow-start con evitamiento de
congestión
Evitamiento de congestión
1: TCP Reno se salta slow start (fast
recovery) tras tres ACKs duplicados
41
Comportamiento general
Retransmisión rápida
z
z
Intervalo de timeout para detectar pérdidas puede
ser largo.
TCP puede enviar un ACK duplicado para un
paquete al que ya se le hizo ACK
–
–
–
z
z
e.g., si se recibe un segmento con núm de secuencia
mayor que el que se espera
esto quiere decir: se perdió un segmento, o simplemente
está desordenado
No hay NACKs en TCP, en vez de eso se envía ACK
duplicado
El emisor no reenvía el paquete perdido
inmediatamente al recibir el ACK duplicado.
Espera hasta recibir tres ACKs duplicados.
42
Retransmisión rápida
z
Se eliminan retransmisiones innecesarias y
capacidad desperdiciada de red si el paquete
simplemente está fuera de orden y no se ha perdido.
z
Permite a TCP no esperar a que expire el timer de
retransmisión antes de reenviar un segmento
potencialmente perdido.
z
Permite mejor utilización del canal y throughput de la
conexión.
Recuperación rápida
z
Aquí, tras recepción del ACK duplicado, la
fuente TCP no se reduce inmediatamente al
slow-start.
z
En vez de esto, después de responder a la
recepción de tres ACKs duplicados mediante
retransmisión del segmento perdido, la
fuente TCP pone cwnd a la mitad de su valor
actual y realiza evitamiento de congestión.
43
Recuperación rápida después de
retransmisión rápida
Sabores de TCP
z
z
z
Tahoe, Reno, New-Reno, SACK
TCP Tahoe (distribuido con BSD 4.3)
implementación original de mecanismos de
Van Jacobson incluyendo:
–
–
–
Slow start (incremento exponencial de ventana
inicial)
Evitamiento de congestión (incremento aditivo de
ventana)
retransmisión rápida (3 ACKs duplicados)
44
TCP Reno
z
1990, incluye:
–
–
–
–
z
Todos los mecanismos en Tahoe
Se agrega recuperación rápida (abrir la ventana tras
retransmisión rápida)
ACKs retardados (para evitar síndrome de ventana tonta)
Predicción de encabezado (para mejorar desempeño)
Variante mas ampliamente en uso
–
(Reno+NewReno)
TCP New-Reno
z
En recuperación rápida de Reno, múltiples
paquetes perdidos en ventana
–
z
pueden causar que la ventana se “desinfle”
prematuramente
En New-Reno
–
–
Recordar paquetes pendientes al inicio de
recuperación rápida
Si nuevo ACK es sólo ACK parcial, asumir que
siguiente segmento se perdió y reenviar, no salir
de recuperación rápida
45
ACKs parciales de New-Reno
z
retransmisión y recuperación rápidas sólo
reparan un segmento perdido por RTT
z
idea de New-Reno: use ACKs parciales para
permanecer en recuperación rápida y
arreglar mas segmentos perdidos
¿Qué variaciones se usan?
z
resultados experimentales obtenidos al
probar 3728 servidores web :
–
–
–
–
–
NewReno 42%
Tahoe 27% (sin retransmisión rápida)
Reno 18%
Otro 8%
Tahoe 5%
Fuente: Padhye and Floyd, SIGCOMM ‘01, August 27-31, San Diego, CA
46
TCP actualmente
TCP está definido por:
z
IETF STDs: RFC793, RFC1122 (Tahoe sin FR)
z
IETF STDs propuestos :
–
–
–
–
–
–
z
RFC1323 (Scaled windows & timestamps)
RFC2018, RFC2883, RFC3517 (SACK)
RFC2581 (Reno)
RFC2988 (RTO)
RFC3168 (ECN)
RFC3390 (Larger IW)
IETF RFCs experimentales:
–
–
RFC2582 (NewReno)
Muchos muchos mas!
Resumen de comportamiento TCP
47