la capa de transporte -...

1

La capa de transporte

Redes deComputadoras

Funciones en capa de transporte

2

Servicios y protocolos de transporteSe provee comunicaciónlógica entre procesos de aplicación corriendo en diferentes hosts

– Los protocolos de transportecorren en sistemas finales

servicios de transporte vs. de red :

– capa de red: transferencia de datos entre sistemas finales (hosts)

– capa de transporte: transferencia de datos entreprocesos

La capa de transporte se apoya en y enriquece losservicios la capa de red

Protocolos de capa de transporteServicios de transporte en Internet :

Entrega confiable, ordenada, unicast (uno a uno) : TCP– control de congestión– control de flujo– establece conexión

Entrega no confiable (“best-effort”), desordenada, unicast o multicast (uno a muchos): UDP

servicios no disponibles:– tiempo real– garantías de ancho de banda– multicast confiable

3

TCP/IP vs. OSI

Protocolos de transporte en Internet

4

Encapsulación de las PDUs

Multicanalización/demulticanalización

5

Cómo funciona la demulticanalizaciónEl host recibe datagramas IP

– cada datagrama tiene direcciónIP 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 puertobien conocidos paraaplicaciones específicas(RFC1700)

host usa direcciones IP y números de puerto para dirigirsegmento al socket apropiado

demux “connectionless”Crear sockets con números de puerto:

– 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)

Cuando un host recibe un segmento UDP:– 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/onúmeros de puerto dirigidos al mismo socket

6

demux “connectionless”

demux “connection-oriented”socket TCP identificado por 4-tupla única:

– dir IP fuente– número puerto fuente– dir IP destino– número puerto destino

host receptor usa los cuatro valores para dirigir el segmento al socket apropiadohost servidor puede dar soporte a muchos sockets TCP simultáneos:

– cada socket identificado por su propia 4-tuplaLos servidores Web tienen sockets diferentes paracada cliente que se conecta

– HTTP no-persistente tendrá socket diferente para cadapetición

7

demux “connection-oriented”

User Datagram Protocol (UDP)

8

User Datagram Protocol (UDP)Protocolo sin conexión (connectionless).Provee un servicio de datagramas en mejoresfuerzo (best-effort) a los sistemas.Servicio no confiable que no garantiza la entrega, no entrega en orden y no protegecontra duplicados.Una computadora puede enviar paquetes sin haber establecido antes una conexión con el receptor.

User Datagram Protocol (UDP)No hay ACKs para confirmar recepción.

No hay ordenamiento de paquetes.

No hay feedback para controlar la velocidad a la quefluye la información entre las máquinas.

Resulta útil en casos donde se prefiere simplicidad.

Las capas superiores pueden agregar corrección de errores, verificación de duplicados, etc.

9

User Datagram Protocol (UDP)Estructura de mensajes UDP

Campos encabezado UDPPuerto fuente y destino. Usados paraindicar 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.

10

PuertosLos sistemas pueden tener muchascomunicaciones simultáneas. ¿Cómoasignar los paquetes a los procesosadecuados?

Se asigna un identificador llamado númerode puerto.

Hay puertos bien conocidos asignados a servicios estándar.

Servicios estándarHay puertos asignados (RFC 1700) a servicios estándares en Internet.

En sistemas Unix el archivo /etc/services tiene la relación de los puertos y losservicios.

Los números de puerto 0 a 1023 estánreservados (por IANA).

11

Servicios estándarAlgunas entradas en /etc/services

Fundamentos de transferenciaconfiable

12

Transferencia confiable de datosMuy importante en capas de aplicación, transporte y enlaceEstá en la lista “top-10” de los tópicos fundamentales en redes

Las características del canal no confiable determinan la complejidad del protocolo de transferencia confiable

Transferencia confiable: principios

13

Protocolos stop-and-wait

Protocolos “pipelined”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

Dos formas genéricas de protocolos pipelined: Go-Back-N, Selective Repeat

14

Pipelining: mejora utilización

Go-Back-NEmisor:

– # 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 vuelotimeout(n): retransmitir paquete n y todos con # secuencia mayor en la ventana

15

Go-Back-N

Cuatro rangos números de secuencia:1. 0 hasta send_base – 1: ya enviados y con ACK2. send_base hasta nextseqnum – 1: enviados y sin

ACK3. nextseqnum hasta send_base + (N-1): pueden

enviarse4. mayor que send_base + N: no pueden enviarse

Go-Back-N enacción

16

Selective Repeatel receptor confirma individualmente todos lospaquetes recibidos correctamente

– mete paquetes en buffers, según se necesite, para eventual entrega ordenada a la capa superior

el receptor solo reenvía paquetes para los cuales no se ha recibido ACK

– 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

17

Selective repeat

Selective repeat en acción

18

Transmission Control Protocol (TCP)

TCP

Protocolo con conexión (connectionoriented).

Provee comunicación con confiabilidad, secuenciamiento, control de flujo y transmisión tipo streaming.

Algunos servicios que usan TCP son ftp, telnet, rsh, smtp, etc.

19

Encabezado TCP

Operación de TCPEstablecimiento de conexión.

20

Operación de TCPCerrar conexión.

Operación de TCPCerrar conexión (caso 1)

A: “ya acabé, no tengo mas datos”B: “OK”B: “yo también ya acabé”A: “OK”

21

Operación de TCPCerrar conexión (caso 2)

A: “ya acabé, no tengo mas datos”B: “aquí te van mas datos”B: “yo también ya acabé”A: “OK”

TCPUna vez establecida la conexión se envíandatos en forma confiable.

Existen varias técnicas para ello.

TCP es un protocolo con ventanasdeslizantes (sliding windows) que proveecontrol de flujo.

22

Stop and wait

Técnica rudimentaria, usada en protocolos muysimples.

Stop and wait ARQ

Pequeña mejora, detecta pérdidas y retransmite.

23

Ventana deslizante (sliding window)

Mayor eficiencia que stop-and-wait.

Entrega confiable de paquetes sobre enlaces no confiables.

Preserva el orden de transmisión de lospaquetes.

Soporte al control de flujo.

Ventana deslizanteCaracterísticas:

Pueden enviarse varios paquetes antes de recibir el ACK para el primero.

Requiere de buffers en ambos extremos.

Se usan números de secuencia para marcostransmitidos.

24

Ventana deslizante

Ventana deslizante

25

Inicio lento (slow-start)

Las ventanas se adaptan de forma dinámica paraproveer control de flujo.

Se inicia transmitiendo a baja velocidad e incrementándola hasta recibir notificación del receptor sobre congestión.

El algoritmo es el de slow-start e usa la ventana de congestión (cwnd).

Ver RFC 2001.

Inicio lento (slow-start)

Hay un límite para cwnd llamado ssthresh(slow-start threshold).

Cuando ssthresh es rebasado se entra en control de congestión.

Entonces, ssthresh se establece a la mitadde su valor.

26

Control de congestiónLos sistemas en los extremos realizan este control con TCP.

Principio: el transmisor incrementa su ventana hastadetectar pérdidas, luego la reduce.

En slow-start el incremento es multiplicativo.

En control de congestión es aditivo.

Ver RFC 1323.

Control de congestión

Aunque el control de congestión es realizadopor los extremos, los sistemas intermediospueden auxiliar.

Algunas técnicas son RED (Random Early Discard) y ECN (Explicit Congestion Notification).

27

Control de congestión en TCP

Principios del control de congestión

Congestión:informalmente: “muchas fuentes enviandomuchos datos demasiado rápido como paraque la red pueda manejarlo”diferente del control de flujoManifestaciones (síntomas):– pérdida de paquetes (buffer overflow en

enrutadores)– largos retardos (colas en buffers de enrutadores)

¡uno de los problemas top-10!

28

Control de congestión y de flujo

La congestión se presenta en redes muycargadas– cuando esta ocurre los extremos y la red deben

trabajar juntos para minimizarlaEn 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 TCPreceptor: informa explícitamente al emisor de cantidad (dinámicamente cambiante) de espacio libre de buffer

– RcvWindow campo en segmento TCP

emisor: mantiene la cantidad de datos transmitidos, sin ACK, menor que RcvWindowmás recientemente recibida

29

Ventana de recepción

Control de flujo con TCP

30

Control de flujo con TCP

Congestión

Si ambas fuentes envían con ventanas completas, puede tenerse colapso por congestiónOtras formas de colapso por congestión :

– Retransmisiones de paquetes grandes tras pérdida de un solo fragmento

– Fuentes sin control por retroalimentación

31

Respuesta a la congestión

El evitamiento (avoidance) mantiene al sistemadesempeñándose en la “rodilla” de la gráficaEl control entra una vez que el sistema ha alcanzado un estado de congestión

EnfoquesDos enfoques generales al control de congestión :

control de congestion extremo a extremo :•no hay retroalimentaciónexplícita de la red•la congestión se infiere de pérdidas y retrasosobservados en extremo•enfoque tomado por TCP (IP no proveeretroalimentación)

control de congestiónasistido por la red :•los enrutadores proveenretroalimentación a losextremos•un bit indicando congestión(SNA, DECnet, TCP/IP ECN,•ATM)•tasa explícita la cual debeenviarse

32

Diseño de control de congestión¿evitamiento o control?

– El evitamiento mantiene el sistema en la “rodilla” de la curva

– Pero, para eso, necesita que los enrutadores envíenseñales precisas (algún tipo de retroalimentación)

El host emisor debe ajustar la cantidad de datos quemete 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

Se estudia esta pregunta usando un modelode feedback de control :– 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)

33

Separación de funcionalidad

El host emisor debe ajustar la cantidad de datos que mete a la red con base en la congestión detectada

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

34

Causas/costos de congestión: escenario 1

dos emisores, dos receptoresun enrutador, buffers infinitosno retransmisión

Grandes retardoscuando hay congestiónMáximo throughput teórico alcanzable = C/2


un enrutador, buffers finitosretransmisión de paquete perdido

35



cuatro emisorestrayectorias multi-saltotimeout/retransmisión

36


GeneralidadesIdea– 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 (self-

clocking)Reto– determinar la capacidad disponible– ajustarse a cambios en la capacidad disponible

37

Generalidades

Una colección de mecanismosinterrelacionados:– Slow start– Evitamiento de congestión– Estimación precisa del timeout de retransmisión– Retransmisión rápida– Recuperación rápida

Generalidades

Mantener una ventana de congestión, cwnd– Denota cuánto es capaz de absorber la red

Ventana máxima de emisión :– Min(ventana anunciada, cwnd)

Ventana actual de emisión:– Ventana max - segmentos sin confirmar

38

Control de congestión TCPcontrol end-end (sin asistencia de la red)tasa de transmisión limitada por tamaño de ventanade congestión, cwnd, sobre segmentos:

w segmentos, cada uno con MSS bytes enviados en un RTT:

Control de congestión TCP“sondeo” de ancho de banda utilizable:

– idealmente: transmitir tan rápido como se pueda(cwnd tan grande como se pueda) sin pérdidas

– incrementar cwnd hastapérdidas (congestión)

– pérdidas: decrementarcwnd, luego inicia sondeo

(incrementando) de nuevo

dos “fases”– slow start– evitamiento de

congestiónvariables importantes:– cwnd– ssthresh: define

umbral entre fasesslow start y de evitamiento de congestión

39

Slow-start en TCP

incremento exponencial(por RTT) en tamaño de ventana (¡no tan lento!)evento de pérdida: timeout (TCP Tahoe) y/o tres ACKsduplicados (TCP Reno)

Slow-start en TCP

40

Evitamiento de congestiónFin: mantener el punto de operación a la derecha de la “rodilla”¿Cómo?

– incremento aditivo: inicando de estimación burda(ssthresh), incrementar cwnd lentamente para sondearancho 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 segmentoincrementar cwnd por 1/cwnd

i.e. (cwnd += 1/cwnd)

Evitamiento de congestiónEmisores establecen ssthresh (umbral de slow start).

Cuando se tira un paquete se reduce ssthresh a la mitad de su valor original.

Regresar a modo de slow-start.

Exponencialmente incrementar transmisiónhasta ssthresh, luego linealmente.

41

Slow-start con evitamiento de congestión

Evitamiento de congestión

1: TCP Reno se salta slow start (fastrecovery) tras tres ACKs duplicados

42

Comportamiento general

Retransmisión rápidaIntervalo de timeout para detectar pérdidas puedeser largo.TCP puede enviar un ACK duplicado para un paquete al que ya se le hizo ACK

– e.g., si se recibe un segmento con núm de secuenciamayor que el que se espera

– esto quiere decir: se perdió un segmento, o simplementeestá desordenado

– No hay NACKs en TCP, en vez de eso se envía ACK duplicado

El emisor no reenvía el paquete perdidoinmediatamente al recibir el ACK duplicado.Espera hasta recibir tres ACKs duplicados.

43

Retransmisión rápidaSe eliminan retransmisiones innecesarias y capacidad desperdiciada de red si el paquetesimplemente está fuera de orden y no se ha perdido.

Permite a TCP no esperar a que expire el timer de retransmisión antes de reenviar un segmentopotencialmente perdido.

Permite mejor utilización del canal y throughput de la conexión.

Recuperación rápida

Aquí, tras recepción del ACK duplicado, la fuente TCP no se reduce inmediatamente al slow-start.

En vez de esto, después de responder a la recepción de tres ACKs duplicados medianteretransmisión del segmento perdido, la fuente TCP pone cwnd a la mitad de su valor actual y realiza evitamiento de congestión.

44

Recuperación rápida después de retransmisión rápida

Sabores de TCPTahoe, Reno, New-Reno, SACKTCP 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)

45

TCP Reno1990, incluye:

– 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-RenoEn recuperación rápida de Reno, múltiplespaquetes perdidos en ventana– 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 salirde recuperación rápida

46

ACKs parciales de New-Reno

retransmisión y recuperación rápidas sóloreparan un segmento perdido por RTT

idea de New-Reno: use ACKs parciales parapermanecer en recuperación rápida y arreglar mas segmentos perdidos

¿Qué variaciones se usan?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

47

TCP actualmenteTCP está definido por:

IETF STDs: RFC793, RFC1122 (Tahoe sin FR)

IETF STDs propuestos :– 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

la capa de transporte -...

Documents