La capa de transporte

Transcripción

1 La capa de transporte Redes de Computadoras Funciones en capa de transporte 1

2 Servicios y protocolos de transporte Se provee comunicación lógica entre procesos de aplicación corriendo en diferentes hosts Los protocolos de transporte corren 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 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 : 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 2

3 TCP/IP vs. OSI Protocolos de transporte en Internet 3

4 Encapsulación de las PDUs Multicanalización/demulticanalización 4

5 Cómo funciona la demulticanalización El host recibe datagramas IP 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 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/o números de puerto dirigidos al mismo socket 5

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 apropiado host servidor puede dar soporte a muchos sockets TCP simultáneos: 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

7 demux connection-oriented User Datagram Protocol (UDP) 7

8 User Datagram Protocol (UDP) 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) No hay ACKs para confirmar recepción. No hay ordenamiento de paquetes. No hay feedback para controlar la velocidad a la que fluye 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. 8

9 User Datagram Protocol (UDP) Estructura de mensajes UDP Campos encabezado UDP 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

10 Puertos Los sistemas pueden tener muchas comunicaciones simultáneas. Cómo asignar los paquetes a los procesos adecuados? Se asigna un identificador llamado número de puerto. Hay puertos bien conocidos asignados a servicios estándar. Servicios estándar Hay 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 los servicios. Los números de puerto 0 a 1023 están reservados (por IANA). 10

11 Servicios estándar Algunas entradas en /etc/services Fundamentos de transferencia confiable 11

12 Transferencia confiable de datos Muy importante en capas de aplicación, transporte y enlace Está 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 12

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 13

14 Pipelining: mejora utilización Go-Back-N Emisor: # 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

15 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

16 Selective Repeat el receptor confirma individualmente todos los paquetes 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 16

17 Selective repeat Selective repeat en acción 17

18 Transmission Control Protocol (TCP) TCP Protocolo con conexión (connection oriented). 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. 18

19 Encabezado TCP Operación de TCP Establecimiento de conexión. 19

20 Operación de TCP Cerrar conexión. Operación de TCP Cerrar conexión (caso 1) A: ya acabé, no tengo mas datos B: OK B: yo también ya acabé A: OK 20

21 Operación de TCP Cerrar 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 TCP Una vez establecida la conexión se envían datos en forma confiable. Existen varias técnicas para ello. TCP es un protocolo con ventanas deslizantes (sliding windows) que provee control de flujo. 21

22 Stop and wait Técnica rudimentaria, usada en protocolos muy simples. Stop and wait ARQ Pequeña mejora, detecta pérdidas y retransmite. 22

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 los paquetes. Soporte al control de flujo. Ventana deslizante Caracterí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 marcos transmitidos. 23

24 Ventana deslizante Ventana deslizante 24

25 Inicio lento (slow-start) Las ventanas se adaptan de forma dinámica para proveer 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 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 mitad de su valor. 25

26 Control de congestión Los sistemas en los extremos realizan este control con TCP. Principio: el transmisor incrementa su ventana hasta detectar pérdidas, luego la reduce. En slow-start el incremento es multiplicativo. En control de congestión es aditivo. Ver RFC Control de congestión Aunque el control de congestión es realizado por los extremos, los sistemas intermedios pueden auxiliar. Algunas técnicas son RED (Random Early Discard) y ECN (Explicit Congestion Notification). 26

27 Control de congestión en TCP Principios del control de congestión Congestión: informalmente: muchas fuentes enviando muchos datos demasiado rápido como para que la red pueda manejarlo diferente del control de flujo Manifestaciones (síntomas): pérdida de paquetes (buffer overflow en enrutadores) largos retardos (colas en buffers de enrutadores) uno de los problemas top-10! 27

28 Control de congestión y de flujo La congestión se presenta en redes muy cargadas 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 receptor: 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 RcvWindow más recientemente recibida 28

29 Ventana de recepción Control de flujo con TCP 29

30 Control de flujo con TCP Congestión 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

31 Respuesta a la congestión 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

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í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 Se estudia esta pregunta usando un modelo de 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) 32

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 33

34 Causas/costos de congestión: escenario 1 dos emisores, dos receptores un enrutador, buffers infinitos no retransmisión Grandes retardos cuando hay congestión Máximo throughput teórico alcanzable = C/2 Causas/costos de congestión: escenario 2 un enrutador, buffers finitos retransmisión de paquete perdido 34

35 Causas/costos de congestión: escenario 2 Causas/costos de congestión: escenario 3 cuatro emisores trayectorias multi-salto timeout/retransmisión 35

36 Causas/costos de congestión: escenario 3 Generalidades Idea 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

37 Generalidades 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 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 37

38 Control de congestión TCP 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 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 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

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 ACKs duplicados (TCP Reno) Slow-start en TCP 39

40 Evitamiento de congestión Fin: 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 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 Emisores 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ón hasta ssthresh, luego linealmente. 40

41 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

42 Comportamiento general Retransmisión rápida 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 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

43 Retransmisión rápida Se eliminan retransmisiones innecesarias y capacidad desperdiciada de red si el paquete simplemente 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 segmento potencialmente 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 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

44 Recuperación rápida después de retransmisión rápida Sabores de TCP 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

45 TCP Reno 1990, 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-Reno En recuperación rápida de Reno, múltiples paquetes 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 salir de recuperación rápida 45

46 ACKs parciales de New-Reno retransmisión y recuperación rápidas sólo reparan un segmento perdido por RTT idea de New-Reno: use ACKs parciales para permanecer 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 46

47 TCP actualmente TCP 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 47