Capa Transporte3-1 Capítulo 3: Capa transporte (Continuación) ELO322: Redes de Computadores Agustín J. González Este material está basado en el material.

Presentación del tema: "Capa Transporte3-1 Capítulo 3: Capa transporte (Continuación) ELO322: Redes de Computadores Agustín J. González Este material está basado en el material."— Transcripción de la presentación:

1 Capa Transporte3-1 Capítulo 3: Capa transporte (Continuación) ELO322: Redes de Computadores Agustín J. González Este material está basado en el material preparado como apoyo al texto Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.

2 Capa Transporte3-2 Capítulo 3: Continuación r 3.1 Servicios de la capa transporte r 3.2 Multiplexing y demultiplexing r 3.3 Transporte sin conexión: UDP r 3.4 Principios de transferencia confiable de datos r 3.5 Transporte orientado a la conexión: TCP m Estructura de un segmento m Transferencia confiable de datos m Control de flujo m Gestión de la conexión r 3.6 Principios del control de congestión r 3.7 Control de congestión en TCP

3 Capa Transporte3-3 Principios de transferencia confiable de datos r Importante en capas de aplicación, transporte y enlace de datos r Está en la lista de los 10 tópicos más importantes sobre redes ! r Las características del canal no-confiable determinarán la complejidad del protocolo de datos confiable (reliable data transfer - rdt) rdt_ : reliable data transfer udt_ : unreliable data transfer

4 Capa Transporte3-4 Transferencia confiable datos: aspectos previos lado transmisor lado receptor rdt_send(): llamado desde arriba, (e.g., por aplicación). Recibe datos a entregar a la capa superior del lado receptor udt_send(): llamado por rdt para transferir paquetes al receptor vía un canal no confiable rdt_rcv(): llamada cuando un paquete llega al lado receptor del canal deliver_data(): llamado por rdt para entregar los datos al nivel superior

5 Capa Transporte3-5 Transferencia confiable datos: aspectos previos Qué haremos?: r Desarrollaremos incrementalmente los lados Tx y Rx del protocolo de transferencia confiable (rdt) r Consideraremos sólo transferencias de datos unidireccionales m Pero la información de control fluye en ambas direcciones! r Usaremos máquina de estados finitos (MEF) para especificar el Tx y Rx estado 1 estado 2 Evento que causa transición de estado Acción tomada al transitar estado estado: cuando estamos en este “estado”, el próximo es determinado sólo por el próximo evento evento acción

6 Capa Transporte3-6 Rdt1.0: transferencia confiable sobre canal confiable r Canal subyacente es perfectamente confiable m no hay errores de bit m no hay pérdida de paquetes r MEF separada por Tx y Rx: m Tx envía datos vía en canal inferior m Rx lee datos desde el canal inferior Wait for call from above packet = make_pkt(data) udt_send(packet) rdt_send(data) extract (packet,data) deliver_data(data) Wait for call from below rdt_rcv(packet) Tx Rx

7 Capa Transporte3-7 Rdt2.0: Canal con bits errados r Canal subyacente puede invertir bits del paquete m checksum detecta los errores de bits r La pregunta: Cómo recuperarnos de errores: m acknowledgements (ACKs)- acuses de recibo: receptor explícitamente le dice al Tx que el paquete llegó OK m negative acknowledgements (NAKs) – acuses de recibo negativos: receptor explícitamente le dice al Tx que el paquete tiene errores. m Tx re-transmite el paquete al recibir el NAK  Nuevos mecanismos en rdt2.0 (más allá de rdt1.0 ): m Detección de errores m Realimentación del receptor: mensajes de control (ACK, NAK) Rx -> Tx

8 Capa Transporte3-8 rdt2.0: Especificación de la MEF Wait for call from above sndpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below Tx Rx rdt_send(data)   nada

9 Capa Transporte3-9 rdt2.0 tiene una falla fatal! ¿Qué pasa si se corrompe el ACK/NAK? r Tx no sabe qué pasó en el receptor! r No puede sólo retransmitir: generaría posible duplicado Manejo de duplicados: r Tx agrega números de secuencia a cada paquete r Tx retransmite el paquete actual si ACK/NAK llega mal r El receptor descarta (no entrega hacia arriba) los paquetes duplicados Tx envía un paquete, Luego espera por la respuesta del Rx stop and wait

10 Capa Transporte3-10 rdt2.1: Tx, manejo de ACK/NAKs errados Wait for call 0 from above sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) Wait for ACK or NAK 0 udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Wait for call 1 from above Wait for ACK or NAK 1   Tx

11 Capa Transporte3-11 rdt2.1: Receptor, manejo de ACK/NAKs errados Wait for 0 from below sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Wait for 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) Rx

12 Capa Transporte3-12 rdt2.1: discusión Transmisor: r Agrega # secuencia al paquete r 2 #’s (0,1) de secuencia son suficientes, por qué? r Debe chequear si el ACK/NAK recibido está corrupto r El doble del número de estados m Estado debe “recordar” si paquete “actual” tiene # de secuencia 0 ó 1 Receptor: r Debe chequear si el paquete recibido es duplicado m Estado indica si el número de secuencia esperado es 0 ó 1 r Nota: el receptor no puede saber si su último ACK/NAK fue recibido OK por el Tx

13 Capa Transporte3-13 rdt2.2: un protocolo libre de NAK r La misma funcionalidad que rdt2.1, usando sólo ACKs r En lugar de NAK, el receptor envía ACK por el último paquete recibido OK m Receptor debe explícitamente incluir # de secuencia del paquete siendo confirmado con el ACK r ACK duplicados en el Tx resulta en la misma acción que NAK: retransmitir paquete actual

14 Capa Transporte3-14 rdt2.2: Fragmentos del Transmisor y receptor Wait for call 0 from above sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) Wait for ACK 0 Fragmento MSF Tx Wait for 0 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt) Fragmento MSF Rx 

15 Capa Transporte3-15 rdt3.0: Canales con errores y pérdidas Suposición nueva: canal subyacente también puede perder paquetes (de datos o ACKs) m checksum, # de secuencias, ACKs, y retransmisiones ayudan pero no son suficientes Estrategia: transmisor espera un tiempo “razonable” por el ACK r Retransmitir si no se recibe ACK en este tiempo r Si el paquete (o ACK) está retardado (no perdido): m La retransmisión será un duplicado, pero el uso de #’s de secuencia ya maneja esto m Receptor debe especificar el # de secuencia del paquete siendo confirmado en el ACK r Se requiere un temporizador de cuenta regresiva

16 Capa Transporte3-16 rdt3.0 Transmisor sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) Wait for ACK0 rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) Wait for call 1 from above sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timer udt_send(sndpkt) start_timer timeout udt_send(sndpkt) start_timer timeout rdt_rcv(rcvpkt) Wait for call 0from above Wait for ACK1  rdt_rcv(rcvpkt)   

17 Capa Transporte3-17 rdt3.0 en acción a) Operación sin pérdidas b) Operación con pérdidas

18 Capa Transporte3-18 rdt3.0 en acción c) Pérdida de ACKd) Timeout prematuro

19 Capa Transporte3-19 Desempeño de rdt3.0 r rdt3.0 funciona, pero su desempeño es malo r Ejemplo: enlace de 1 Gbps, 15 ms de retardo ext. a ext, paquetes de 1KB: m U transmisor : utilización del transmisor o canal = fracción de tiempo que el transmisor/canal está ocupado transmitiendo m 1 paquete de 1KB cada ~30 ms -> 33kB/s throughput en enlace de 1 Gbps m Protocolo de red limita el uso de los recursos físicos!

20 Capa Transporte3-20 Protocolos con Pipeline Con Pipeline: Transmisor permite múltiples paquetes en tránsito con acuse de recibo pendiente m El rango de los números de secuencia debe ser aumentado m Se requiere buffers en el Tx y/o Rx r Hay dos formas genéricas de protocolos con pipeline: go-Back-N, selective repeat (repetición selectiva)

21 Capa Transporte3-21 Go-Back-N Transmisor: r # de secuencia de k-bits en el encabezado del paquete r “ventana” de hasta N, paquetes consecutivos con acuse de recibo pendiente r Ante llagada de ACK(n): da acuse de recibo a todos los paquetes, incluyendo aquel con # de secuencia n; corresponde a un “acuse de recibo acumulado” m Podría recibir ACKs duplicados (ver receptor) r Usa un timer por cada paquete en tránsito r timeout(n): retransmitir paquete n y todos los paquetes número de secuencia siguientes en la ventana Próximo número de secuencia a usar Núm. Sec. más antiguo sin ACK: Base Tamaño de ventana N Con ACK recibidos ACK pendientes No usable Usable, aún no enviados

22 Capa Transporte3-22 GBN: MEF extendida del Transmisor Wait start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) timeout rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base=1 nextseqnum=1 rdt_rcv(rcvpkt) && corrupt(rcvpkt)  

23 Capa Transporte3-23 GBN: MEF extendida del Receptor Sólo ACK: siempre envía ACK de paquete correctamente recibido con el # de secuencia mayor en orden m Puede generar ACKs duplicados  Sólo necesita recordar expectedseqnum r Paquetes fuera de orden: m descartarlos (no almacenar en buffer) => no requiere buffer en receptor! m Re-envía ACK del paquete de mayor número de secuencia en orden Wait udt_send(sndpkt) default rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum) 

24 Capa Transporte3-24 GBN en acción

25 Capa Transporte3-25 Selective Repeat (repetición selectiva) r Receptor envía acuse de recibo individuales de todos los paquetes recibidos m Almacena paquetes en buffer, según necesidad para su entrega en orden a la capa superior r Transmisor sólo re-envía los paquetes sin ACK recibido m Transmisor usa un timer por cada paquete sin ACK r Ventana del Transmisor m N # de secuencia consecutivos m Nuevamente limita los #s de secuencia de paquetes enviados sin ACK

26 Capa Transporte3-26 Selective repeat: Ventanas de Tx y Rx Con ACK recibidos ACK pendientes No usable Usable, aún no enviados Esperado, aún no recibido Fuera de orden (almacenados) con ACK enviado Aceptable (en ventana) No usable a) Vista del transmisor de los número de secuencia b) Vista del receptor de los número de secuencia

27 Capa Transporte3-27 Selective repeat (repetición selectiva) Llega datos desde arriba: r Si el próximo # de sec. está en ventana, enviar paquete timeout(n): r Re-enviar paquete n, re- iniciar timer ACK(n) en [sendbase,sendbase+N]: r Marcar paquete n como recibido r Si n es el paquete más antiguo sin ACK, avanzar la base de la ventana al próximo # de sec. sin ACK. Transmisor Llega paquete n en [rcvbase, rcvbase+N-1] r Enviar ACK(n) r Si está fuera de orden: almacenar en buffer r en-orden: entregar a capa superior (también entregar paquetes en orden del buffer), avanzar ventana al paquete próximo aún no recibido paquete n en [rcvbase-N,rcvbase-1] r ACK(n) Otro caso: r ignórelo Receptor

28 Capa Transporte3-28 Repetición Selectiva en Acción

29 Capa Transporte3-29 Dilema de la repetición Selectiva Ejemplo: r #s de sec.: 0, 1, 2, 3 r Tamaño de ventana=3 r Rx no ve diferencia en los dos escenarios! r Pasa incorrectamente datos como nuevos en (a) Q: ¿Qué relación debe existir entre el # de sec. y el tamaño de ventana?

30 Capa Transporte3-30 Q: ¿Qué relación debe existir entre el # de sec. y el tamaño de ventana? r La clave para evitar este problema es impedir que se pueda producir el escenario de la figura adjunta. r Supongamos que la ventana de recepción del receptor es [m,m+w- 1], por lo tanto ha recibido y enviado ACK del paquete m-1 y los w- 1 paquetes previos a éste. r Si ninguno de estos ACK han sido recibidos por le Tx, entonces ACK con valores [m-w,m-1] pueden estar en tránsito. En este caso la ventana del transmisor será [m-w,m-1]. r Así, el límite inferior de la ventan del Tx es m-w, y el mayor número de secuencia de la ventana del Rx será m+w-1. r Para que no haya traslape, debemos tener un espacio de números de secuencia tan grande como para acomodar 2w números de secuencia, luego k >= 2w. r Q:¿Qué relación debe existir en el caso Go-Back-N?

31 Capa Transporte3-31 Capítulo 3: Continuación r 3.1 Servicios de la capa transporte r 3.2 Multiplexing y demultiplexing r 3.3 Transporte sin conexión: UDP r 3.4 Principios de transferencia confiable de datos r 3.5 Transporte orientado a la conexión: TCP m Estructura de un segmento m Transferencia confiable de datos m Control de flujo m Gestión de la conexión r 3.6 Principios del control de congestión r 3.7 Control de congestión en TCP