Arquitectura de Redes, capítulo 3 · SNMP transferencia fiable sobre UDP: añadir fiabilidad en la...

3-1

Capítulo 3La capa de transporte

Redes de computadoras: Un enfoque descendente, 5a edición. Jim Kurose, Keith RossPearson Educación, 2010.

A note on the use of these ppt slides:We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:

If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!)

If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material.

Thanks and enjoy! JFK/KWR

All material copyright 1996-2010J.F Kurose and K.W. Ross, All Rights Reserved

Raúl Durán, Nacho Pérez v1.4 Capa de Transporte

3-2

Capítulo 3: La capa de transporteObjetivos:

comprender los principios que están tras los servicios de la capa de transporte

multiplexar/des-multiplexartransferencia de datos fiablecontrol de flujocontrol de congestión

conocer los protocolos de transporte de Internet:

UDP: transporte sin conexiónTCP: transporte orientado a conexióncontrol de flujo TCPcontrol de congestión TCP


3-3

Capítulo 3: índice

3.1 Servicios de la capa de transporte

3.2 Multiplexación y desmultiplexación

3.3 Transporte sin conexión: UDP

3.4 Principios de transferencia de datos fiable

3.5 Transporte orientado a conexión: TCP

estructura de segmentogestión de conexión transferencia de datos fiablecontrol de flujoestimación de RTT y temporización

3.6 Principios de control de congestión

3.7 Control de congestión TCP


3-4

servicios y protocolos de transporteproporcionar comunicaciónlógica entre procesos en ejecución en diferentes hostslos protocolos de transporte corren en sistemas terminales

emisor: divide mensajes en segmentos, los pasa a la capa de redreceptor: reensambla segmentos en mensajes, los pasa a la capa de aplicación

más de un protocolo disponible para las aplicaciones

Internet: TCP y UDP

aplicacióntransporte

redenlacefísica


redenlacefísica

transporte lógico extr.-extr.


ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

3-5

capa de transporte / capa de red

encapsulación:arquitectura en capascapa de red:comunicación lógica entre hostscapa de transporte:comunicación lógica entre procesos

se basa en, y amplía, los servicios de la capa de red

analogía doméstica:12 chicos envían cartas a 12

chicosprocesos = chicosmensajes = cartas en sobreshosts = casasprotocolo de transporte = Ana y Juan, que reparten a sus hermanos respectivosprotocolo de red = Correos


3-6

protocolos de capa de transporte de Internet

distribución fiable en orden (TCP)

control de congestióncontrol de flujoestablecimiento de conexión

distribución no fiable, fuera de orden: UDP

extensión “sin virguerías”de IP “haz lo que puedas”

servicios no disponibles: garantía de retardo mínimogarantía de ancho de banda mínimo


redenlacefísica

redenlacefísica

redenlacefísica

redenlacefísica

redenlacefísica

redenlacefísica

redenlacefísica


redenlacefísica

transporte lógico extr.-extr.


ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

3-7











3-8

Multiplexación/desmultiplexación

aplicación

transporte

red

enlace

física

P1 aplicación

transporte

red

enlace

física

aplicación

transporte

red

enlace

física

P2P3 P4P1

host 1 host 2 host 3

= proceso= socket

entregar segmentos recibidosal socket correcto

Desmultiplexación en el destino:reunir datos de múltiplessockets, empaquetarlos con el encabezado (usado luego para desmultiplexar)

Multiplexación en el emisor:


socket = puerta de comunicación red-proceso

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

Protocolo de red IP

El protocolo de Internet para la capa de red se llama IP.Se encarga de dar una conexión lógica entre hosts.Entrega datagramas de un host a otro, pero sin garantías.Cada host se identifica con una dirección de red, que llamamos dirección IP.

3-9Capa de TransporteRaúl Durán, Nacho Pérez v1.4

3-10

Cómo funciona la desmultiplexaciónel host recibe datagramas IP

cada datagrama tiene IP de origen e IP de destinocada datagrama lleva un segmento de la capa de transportecada segmento tiene nº de puerto de origen y de destino

el host usa IP y nº de puerto para dirigir el segmento al socket apropiado

nº puerto org nº puerto dest

32 bits

datos de la aplicación (mensaje)

otros campos encabezado

formato de segmento TCP/UDP


ÁngelResaltado

ÁngelNota adhesivaCabecera de la capa de transporte (nº puerto origen/destino y otros campos encabezado)

ÁngelNota adhesivaPuerto: identificación "externa" del socket (puerto del 0 al 2^16 -1)

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

3-11

desmultiplexación sin conexión

recordatorio: crear sockets con números de puerto locales:

DatagramSocket mySocket1 = new DatagramSocket(12534);

DatagramSocket mySocket2 = new DatagramSocket(12535);

recordatorio: al crear un datagrama para enviar por un socket UDP, hay que especificar

(IP dest ,nº puerto dest)

cuando un host recibe un segmento UDP

comprueba el nº de puerto destino del segmentoredirige el segmento UDP al socket con ese nº de puerto

datagramas IP con diferente IP origen y/o nº puerto origen se dirigen al mismo socket


3-12

desmultiplexación sin conexión (cont)

DatagramSocket serverSocket = new DatagramSocket(6428);

IPcliente: B

P2

IP cliente: A

P1P1P3

IP servidor: C

PO: 6428PD: 9157

PO: 9157PD: 6428

PO: 6428PD: 5775

PO: 5775PD: 6428

PO proporciona “dirección de retorno”


3-13

Desmultiplexación orientada a conexión

un socket TCP se identifica por una 4-upla:

IP origennº puerto origenIP destinonº puerto destino

el receptor usa los 4 valores para redirigir el segmento al socket adecuado

el host servidor debe soportar varios sockets TCP simultáneos

cada socket identificado por su propia 4-upla

los servidores web tienen sockets diferentes para cada cliente que se conecta

HTTP no persistente tendrá un socket para cada solicitud


3-14

Desmultiplexación orientada a conexión (cont)

IPcliente:B

P1

IPcliente: A

P1P2P4

IPservidor: C

P5 P6 P3

PO: 9157PD: 80IP-O: AIP-D:C

PO: 9157PD: 80

IP-D:CIP-O: B

PO: 5775PD: 80

IP-D:CIP-O: B


3-15

desmultiplexación orientada a conexión: Web Server con hebras

IP cliente:B

P1

IPcliente: A

P1P2

IPservidor: C

SP: 9157DP: 80

SP: 9157DP: 80

P4 P3

D-IP:CS-IP: AD-IP:C

S-IP: B

SP: 5775DP: 80

D-IP:CS-IP: B

PO: 9157PD: 80IP-O: AIP-D:C

PO: 5775PD: 80

IP-D:CIP-O: B

PO: 9157PD: 80

IP-D:CIP-O: B


Sockets en cliente/servidor UDP

socket()

sendto()

recvfrom()

close()sendto()

recvfrom()

bind()

socket()

Cliente UDP Servidor UDP

procesar pedido…

Raúl Durán, Nacho Pérez v1.4 Capa de Transporte 3-16

ÁngelNota adhesivaAsocia un número de puerto

ÁngelNota adhesivaSin conexión

Sockets en cliente/servidor TCP

socket()

write()

read()

close()

accept()

listen()

bind()

socket()

Cliente TCP Servidor TCP

connect()

close()

write()

read()

read()

procesar pedido…


3-18







estructura de segmentogestión de conexióntransferencia de datos fiablecontrol de flujoestimación de RTT y temporización




ÁngelNota adhesivaCon conexión

ÁngelNota adhesivaSe crea un proceso hijo que realiza la función read(), mientras que el proceso padre se queda en el accept()

3-19

UDP: User Datagram Protocol [RFC 768]protocolo de transporte de Internet sin adornos, “con lo puesto”al ser un servicio de “haz lo que puedas”, los segmentos UDP pueden:

perderseser entregados fuera de orden a la aplicación

sin conexión:sin establecimiento de conexión entre el emisor y el receptor UDPcada segmento UDP se trata de forma independiente de los otros

¿Por qué existe UDP?no hay establecimiento de la conexión (que puede añadir retardo)sencillo: no hay estado ni en el emisor ni en el receptorencabezado pequeñono hay control de congestión: UDP puede disparar todo lo rápido que se quiera


3-20

UDP: mása menudo usado para aplicaciones de ‘streaming’multimedia

tolerante a pérdidassensible a la velocidad

otros usos de UDPDNSSNMP

transferencia fiable sobre UDP: añadir fiabilidad en la capa de aplicación

recuperación de errores específica para la aplicación

nº puerto org nº puerto dest

32 bits

datos de la aplicación(mensaje)

formato de segmento UDP

long checksumLongitud, en

bytes, del segmento

UDP, incluido encabezado


0 311615

3-21

UDP: checksum

Emisor:trata contenidos del segmento como secuencia de enteros de 16 bitschecksum: suma (en compl. a 1) del contenido del segmentoel emisor pone el checksum en el campo UDP correspondiente

Receptor:calcula el checksum del segmento recibidocomprueba si el valor calculado = campo checksum

NO - error detectadoSÍ – error no detectado

¿Puede haber errores aun así? Lo veremos más adelante

Objetivo: detectar “errores” (p.ej.: bits alterados) en el segmento transmitido


3-22

Ejemplo de Checksum InternetNota: ¡suma en complemento a 1!Ejemplo: sumar dos enteros de 16 bits

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

acarreo

sumachecksum


3-23











3-24

Principios de transferencia de datos fiable

es importante en las capas de aplicación, transporte y enlace¡en el “top-10” de las cuestiones importantes en redes!

las características del canal no fiable determinarán la complejidad del protocolo de transferencia de datos fiable (rdt: ‘reliable data transfer protocol’)


3-25





3-26





rdt_send(): llamada desde arriba, (p.ej.: por la apl.). Se le

pasan los datos a entregar al nivel superior del receptor

3-27

transferencia de datos fiable: preliminares

ladoemisión

ladorecepción

udt_send(): llamado por rdt para transferir paquete por canal no fiable al receptor

rdt_rcv(): llamado cuando el paquete llegue al extremo de

recepción del canal

deliver_data(): llamada por rdt para entregar datos

al nivel superior


3-28

transferencia de datos fiable: preliminaresVamos a:

desarrollar el emisor y el receptor de un protocolo de transf. de datos fiable (rdt) paso a pasoconsiderar sólo transferencia de datos unidireccional

¡pero el control se transmitirá en ambas direcciones!usar máquinas de estados finitos (MEFs) para definir emisor y receptor

estado1

estado2

evento que causa la transiciónacción tomada en la transición

estado: desde este estado, el siguiente

se determina únicamente por el siguiente evento

eventoacciones


3-29

Rdt1.0: transferencia fiable en canal fiable

canal subyacente perfectamente fiableno hay errores de bitno hay pérdida de paquetes

MEF diferente para emisor y receptorel emisor envía dato al canal subyacenteel emisor lee datos del canal subyacente

esperarllamada de arriba packet = make_pkt(data)

udt_send(packet)

rdt_send(data)extract (packet,data)deliver_data(data)

esperar llamada de abajo

rdt_rcv(packet)

emisor receptor


3-30

Rdt2.0: canal con errores de bitel canal subyacente puede alterar bits del paquete

usar el checksum para detectar errores de bitla cuestión: ¿cómo recuperarse de errores?reconocimientos(‘acknowledgements’, ACKs): el receptor indica explícitamente que la recepción fue buenareconocimientos negativos (NAKs): el receptor indica explícitamente que el paquete tenía erroresel emisor retransmite el paquete si recibe un NAK

nuevos mecanismos en rdt2.0 (sobre rdt1.0):detección de erroresrealimentación del receptor:mensajes de control (ACK,NAK) del receptor al emisor

¿Cómo se recuperan los humanos de “errores”durante la conversación?


3-31

Rdt2.0: canal con errores de bitel canal subyacente puede alterar bits del paquete

usar el checksum para detectar errores de bitla cuestión: ¿cómo recuperarse de errores?reconocimientos(‘acknowledgements’, ACKs): el receptor indica explícitamente que la recepción fue buenareconocimientos negativos (NAKs): el receptor indica explícitamente que el paquete tenía erroresel emisor retransmite el paquete si recibe un NAK

nuevos mecanismos en rdt2.0 (sobre rdt1.0):detección de erroresrealimentación del receptor:mensajes de control (ACK,NAK) del receptor al emisor


3-32

rdt2.0: especificación de la MEF

esperar llamada de

arriba

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)

esperar ACK o NAK

esperar llamada de

abajoemisor

receptorrdt_send(data)

Λ


3-33

rdt2.0: funcionamiento sin errores

esperar llamada de

arriba

snkpkt = make_pkt(data, checksum)udt_send(sndpkt)




udt_send(sndpkt)


udt_send(NAK)


esperar ACK o NAK

esperar llamada de

abajo

rdt_send(data)

Λ


3-34

rdt2.0: caso de error

esperar llamada de

arriba

snkpkt = make_pkt(data, checksum)udt_send(sndpkt)




udt_send(sndpkt)


udt_send(NAK)


esperar ACK o NAK

esperar llamada de

abajo

rdt_send(data)

Λ


3-35

¡ rdt2.0 tiene un defecto fatal !

¿Qué ocurre si ACK o NAK se corrompen?¡¡el emisor no sabe quéocurrió en el receptor!!no es posible simplemente retransmitir: se pueden crear duplicados

Manejo de duplicados: el emisor retransmite el paquete actual si ACK o NAK no llegan bienel emisor añade un número de secuencia a cada paqueteel receptor descarta (no entrega hacia arriba) el paquete duplicado

el emisor envía un paquetey espera la respuesta delreceptor

parada y espera


3-36

rdt2.1: el emisor maneja ACK/NAKs erróneos

esperar llamada 0 de arriba

sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)

rdt_send(data)

esperar ACK o NAK 0 udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )


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)


esperar ACK o NAK 1

ΛΛ


3-37

rdt2.1: el receptor maneja ACK/NAKs erróneos

esperar 0 de abajo

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)

esperar 1 de abajo


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)


3-38

rdt2.1: discusión

Emisor:nº secuencia añadido al paquete2 números valen (0,1). ¿Por qué?comprobar si el ACK/NAK recibido corruptoel doble de estados

el estado debe “recordar” si el paquete “actual” tiene nº sec. 0 ó1

Receptor:debe comprobar si el paquete recibido es duplicado

el estado indica si se espera el paquete 0 ó 1

nota: el receptor no puede saber si su último ACK/NAK se recibió bien en el emisor


3-39

rdt2.2: un protocolo sin NAK

la misma funcionalidad que rdt2.1, usando sólo ACKsen lugar de NAK, el receptor envía ACK para el último paquete recibido bien

el receptor debe incluir explícitamente el nº de secuencia del paquete al que se refiere el ACK

un ACK duplicado en el emisor resulta en la misma acción que un NAK: retransmitir paquete actual


3-40

rdt2.2: fragmentos del emisor y el receptor



rdt_send(data)

udt_send(sndpkt)

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||

isACK(rcvpkt,1) )

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)

esperar ACK 0

fragmento MEF emisor


extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)

esperar 0 de abajo

rdt_rcv(rcvpkt) && (corrupt(rcvpkt) ||

has_seq1(rcvpkt))

udt_send(sndpkt)fragmento MEF

receptor

Λ


3-41

rdt3.0: canales con errores y pérdidas

Nueva suposición: canal subyacente también puede perder paquetes (datos o ACKs)

las retransmisiones de checksum, nº secuencia, ACKs, ayudan, pero no son suficiente

línea de trabajo: emisor espera un tiempo “razonable” al ACKretransmite si no recibe ACK en ese tiemposi el paquete (o ACK) sólo se retrasó (no se perdió):

las retransmisiones estarán repetidas, pero con el nº secuencia esto está resueltoel receptor debe indicar nº secuencia del paquete al que se aplica el ACK

requiere un temporizadorRaúl Durán, Nacho Pérez v1.4 Capa de Transporte

3-42

rdt3.0 emisorsndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)

espe-rar

ACK 0

rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )


sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer

rdt_send(data)


rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,0) )


stop_timerstop_timer

udt_send(sndpkt)start_timer

timeout

udt_send(sndpkt)start_timer

timeout

rdt_rcv(rcvpkt)


esper-rar

ACK 1

Λrdt_rcv(rcvpkt)

ΛΛ

Λ


3-43

rdt3.0 funcionando


3-44

rdt3.0 funcionando


3-45

Rendimiento del rdt3.0

rdt3.0 funciona, pero el rendimiento es muy malop.ej.: enlace de 1Gb/s, 15ms retardo prop., paquete 8k bits

si RTT=30 ms, 1 paquete de 1KB cada 30 sg -> 33KB/s de 1Gbps¡¡el protocolo de red limita el uso de los recursos físicos!!

dosmicrosegun 8bps10bits 8000

9 === RLdtrans

U emisor: utilización – fracción de tiempo que el emisor estáocupado emitiendo


3-46

rdt3.0: funcionamiento de parada y espera

primer bit transmitido, t = 0

emisor receptor

RTT

último bit transmitido, t = L / R

llega primer bitllega último bit, enviar ACK

llega ACK, enviar siguiente paquete, t = RTT + L / R


3-47

Protocolos segmentados (en cadena)segmentar: el emisor permite que haya múltiples

paquetes “en camino”, pendientes de ACKel rango de nº de secuencia debe aumentarsehay que añadir búfferes en el emisor y/o el receptor

hay dos formas genéricas de protocolos segmentados: retroceder N (‘go-Back-N’) y repetición selectiva (‘selective repeat’)


3-48

segmentación: uso mejorado

primer bit transmitido, t = 0

emisor receptor

RTT

último bit transmitido, t = L / R

llega el primer bitllega último bit 1er paquete, enviar ACK

llega ACK, enviar siguiente paquete, t = RTT + L / R

llega último bit 2º paquete, enviar ACKllega último bit 3er paquete, enviar ACK

¡¡Mejora en la utilización en un factor de 3!!


3-49

Protocolos segmentados

Retroceder N: vista globalel emisor puede tener hasta N paquetes pendientes de ACKel receptor sólo envía ACKs acumulativos

no lo envía para un paquete si hay una laguna

el emisor tiene un temporizador para el paquete más antiguo sin ACK

si llega a 0, retransmitir paquetes sin ACK

Repetición selectiva: vista globalel emisor puede tener hasta N paquetes pendientes de ACKel receptor envía ACK para cada paqueteel emisor mantiene un temporizador para cada paquete sin ACK

si llega a 0, retransmitir sólo paquete sin ACK


3-50

Retroceder N (GBN)Emisor:

nº de secuencia de k bits en cabecera del paqueteventana de hasta N paquetes consecutivos sin ACK

ACK(n): ACK para todos los paquetes hasta nº sec. n (inclusive): “ACK acumulativo”

puede recibir ACKs duplicados (ver receptor)temporizador para cada paquete en camino timeout(n): retransmitir paquete n y todos los de mayor nº sec. en la ventanaRaúl Durán, Nacho Pérez v1.4 Capa de Transporte

3-51

GBN: MEF ampliada para el emisor

Wait start_timerudt_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_timernextseqnum++}

elserefuse_data(data)

base = getacknum(rcvpkt)+1If (base == nextseqnum)

stop_timerelsestart_timer


base=1nextseqnum=1


Λ


3-52

GBN: MEF ampliada del receptor

Enviar ACK para paquete correcto con mayor nº de secuencia en orden

se pueden generar ACKs duplicadossólo hay que recordar expectedseqnum

paquete fuera de ordendescartar (no se guarda) -> ¡¡no hay buffer en el receptor!!Reenviar ACK para paquete con mayor nº 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=1sndpkt = make_pkt(expectedseqnum,ACK,chksum)

Λ


3-53

GBN enfunciona-miento


3-54

Repetición selectiva (SR)

el receptor envía ACK individual para cada paquete correcto

se deben guardar los paquetes en buffers según sea necesario, para entregarlos en orden a la capa superior

el emisor sólo reenvía paquetes para los que no reciba ACK

un temporizador para cada paquete en caminoventana de emisor

hay N nº de secuencia consecutivosde nuevo limita nºsec. de los paquetes en camino


3-55

Repetición selectiva: ventanas de emisor y receptor


3-56

Repetición selectiva

datos de arriba:si sig. nº sec. en la ventana vacío, enviar paquete

timeout(n):reenviar paquete n, reiniciar temporizador

ACK(n) en [sendbase,sendbase+N]:marcar paquete n como recibidosi n era el paquete sin ACK con menor nº sec., avanzar el inicio de la ventana al siguiente nº sec. sin ACK

emisorpaquete n en [rcvbase, rcvbase+N-1]

enviar ACK(n)fuera de orden: guardar en bufferen orden: entregar (junto con los previamente guardados por fuera de orden), avanzar ventana al siguiente pendiente de recibir

paquete n en [rcvbase-N,rcvbase-1]ACK(n)

otro caso:ignorar

receptor


3-57

repetición selectiva en funcionamiento


3-58

Repetición selectivadilema

Ejemplo: nos. sec: 0, 1, 2, 3tamaño ventana=3

¡el receptor no ve diferencia entre ambos casos!en (a) pasa datos repetidos por nuevos de forma incorrecta

P: ¿relación entre nº de nos. de secuencia válidos y tamaño de la ventana?Raúl Durán, Nacho Pérez v1.4 Capa de Transporte

3-59











3-60

TCP: Visión global RFCs: 793, 1122, 1323, 2018, 2581

datos full duplex:flujo de datos bidireccional en la misma conexiónMSS: Máximo tamaño de segmento (‘maximum segment size’)

orientado a conexión:establecimiento conexión (intercambio de mensajes) inicializa estados antes del intercambio de datos

con control de flujo:el emisor no satura al receptor

punto a punto:un emisor, un receptor

flujo de bytes fiable, en orden:

no hay “límites de mensaje”segmentado:

el control de flujo y congestión de TCP fijan el tamaño de la ventanabuffers de emisión y recepción

socketdoor

TCPsend buffer

TCPreceive buffer

socketdoor

segment

applicationwrites data

applicationreads data


ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

3-61

estructura del segmento TCP

nº puerto origen nº puerto dest.

32 bits

datosaplicación

(long. variable)

nº secuencianº ACK

ventana recepciónpuntero datos urg.checksum

FSRPAUlong. encab.not

used

Opciones (long. variable)

URG: datos urgentes(la aplicación debe

hacer algo)ACK: nº ACK

válidoPSH: push, enviar

estos datos ya a laaplicación

(el programador no puede manejarlo)

RST, SYN, FIN:estab. conexión

(comandos estab., cerrar)

nº bytes que el receptorestá dispuestoa aceptar

contados en bytes de datos(¡¡no segmentos!!)

checksum Internet

(como en UDP)


0 15 16 31

3-62

TCP: núms. secuencia y ACKsnos. secuencia:

“nº” flujo de bytes del 1er byte de datos del segmento

ACKs:nº sec. del siguiente byte esperado de la otra parteACK acumulativo

P: cómo se tratan los segmentos fuera de orden

R: la especificación de TCP no lo dice: lo que haga el implementador

Host A Host B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK

=43, data = ‘

C’

Seq=43, ACK=80

Usuarioescribe

‘C’

el host envíaACK por ladevolución

de ‘C’

el host envía ACK por ‘C’devuelve ‘C’

tiempoejemplo sencillo de telnet


ÁngelNota adhesivaIndicación del control de flujo

ÁngelResaltado

ÁngelResaltado

3-63







estructura de segmentogestión de conexióntransferencia de datos fiable control de flujoestimación de RTT y temporización




3-64

TCP: gestión de la conexiónRecordatorio: en TCP, emisor y

receptor establecen una “conexión” antes de intercambiar segmentos de datosinicializar variables TCP:

nos. de secuenciabuffers, info. de control de flujo (p.ej.: RcvWindow)

el cliente: inicia la conexiónSocket clientSocket = new Socket(”nombrehost",”numero puerto");

el servidor: el cliente contacta con élSocket connectionSocket = welcomeSocket.accept();

Establecimiento en 3 pasos:

Paso 1: el cliente envia segmento SYN al servidor

especifica nº secuencia inicialsin datos

Paso 2: el servidor recibe SYN, responde con segmento SYNACK

el servidor crea buffersespecifica el nº sec. inicial del servidor

Paso 3: el cliente recibe SYNACK, responde con segmento ACK, que puede contener datos


3-65

TCP: gestión de la conexión (cont.)

Cerrar una conexión:

el cliente cierra el socket:clientSocket.close();

Paso 1: el sistema terminal del cliente envía el segmento de control TCP FIN al servidor

Paso 2: el servidor recibe FIN, responde con ACK. Cierra la conexión, envía FIN

cliente

FIN

servidor

ACK

ACK

FIN

cerrar

cerrar

cerrado

espe

ra

tem

pori

zada


3-66


Paso 3: el cliente recibe FIN, responde con ACK.

entra en “espera temporizada” –responderá con ACK a los FINs que reciba

Paso 4: el servidor recibe ACK. Conexión cerrada.

Nota: con una pequeña modificación, puede manejar FINs simultáneos.

cliente

FIN

servidor

ACK

ACK

FIN

cerrando

cerrando

cerrada

espe

ra

tem

pori

zada

cerrada


3-67


ciclo de vidade cliente TCP

ciclo de vidade servidor TCP


3-68











ÁngelNota adhesivaLas conexiones no mueren hasta que uno de los dos lados (cliente o servidor) cierre la conexión

3-69

TCP transferencia de datos fiable

TCP crea servicio rdtsobre el servicio no fiable de IPsegmentos en cadenaacks acumulativosTCP usa un único temporizador de retransmisión

retransmisiones disparadas por:

eventos de temporizador a ceroACKs duplicados

inicialmente considerar emisor TCP simplificado

ignorar ACKs duplicadosignorar control de flujo, congestión de flujo


3-70

eventos de emisión TCP:datos recibidos de la

aplicación:crear segmento con nºsec.nº sec. es el nº del 1er byte del segmento dentro del flujo de bytesiniciar temporizador si no lo estáintervalo de expiración: TimeOutInterval

‘timeout’ (expiración):retransmitir segmento que la provocóreiniciar temporizador

ACK recibido:si se refiere a segmentos sin ACK previo

actualizar aquellos a los que les falta el ACKiniciar temporizador si hay segmentos pendientes


ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

ÁngelResaltado

3-71

emisor TCP (simplificado)

NextSeqNum = InitialSeqNumSendBase = InitialSeqNum

loop (siempre) {switch(suceso)

suceso: datos recibidos de la aplicación de capa superiorcrear segmento TCP con nº sec. NextSeqNum if (temporizador no en marcha)

iniciar temporizadorpasar segmento a IP NextSeqNum = NextSeqNum + length(data)

suceso: temporizador expiróretransmitir segmento sin ACK con el menor nº sec. iniciar contador

suceso: recibido ACK con valor del campo ACK == yif (y > SendBase) {

SendBase = yif (hay segmentos sin ACK)

iniciar temporizador}

} /* fin de loop siempre */


3-72

TCP: situaciones para retransmisiónHost A

Seq=100, 20 bytes data

ACK=1

00

tiempotimeout prematuro

Host B


ACK=120


Seq=

92 t

imeo

ut

ACK=120

Host A


ACK=100

pérdida

tim

eout

situación de ACK perdido

Host B

X


ACK=100

tiempo

Seq=

92 t

imeo

ut

SendBase= 100

SendBase= 120

SendBase= 120

SendBase= 100


3-73

TCP situaciones para retransmisión (más)Host A


ACK=100

pérdida

tim

eout

ACK acumulativo

Host B

X


ACK=120

tiempo

SendBase= 120


3-74

generación de ACK en TCP [RFC 1122, RFC 2581]

Evento en Receptor

Llegada de segmento en orden connº sec. esperado. Todos hasta elnº sec. esperado ya tienen ACK

Llegada de segmento en orden connº sec. esperado. Hay otro seg. en orden esperando transm. de ACK

Llegada de nº de sec. fuera de orden mayor que el esperado. Detectada laguna

Llegada de segmento que comple-ta parcialmente una laguna

Receptor TCP: acción

ACK retardado. Esperar hasta 500msal siguiente segmento. Si no llega, enviarACK

Inmediatamente enviar ACK acumulativopara ambos segmentos

Inmediatamente enviar ACK duplicadoindicando nº sec. del siguiente byte esperado

Inmediatamente enviar ACK, suponiendo que el segmento empieza en el límite inferior de la laguna


3-75

Retransmisión rápida

período de expiración a menudo relativamente largo

largo retardo antes de reenviar el paquete perdido

se detectan segmentos perdidos por ACKs repetidos

el emisor a menudo envía varios segmentos seguidossi se pierde un segmento, seguramente habrá varios ACKs repetidos

si el emisor recibe 3 ACKs por los mismos datos, supone que el segmento de después de los datos con ACK se perdió:

retransmisión rápida: reenviar segmento antes de que expire el temporizador


3-76

Host A

tim

eout

Host B

tiempo

X

reenviar 2º segmento

Figura 3.37 Reenviar segmento tras triple ACKRaúl Durán, Nacho Pérez v1.4 Capa de Transporte

3-77

suceso: recibido ACK, con campo ACK con valor == s if (s > SendBase) {

SendBase = sif (hay segmentos pendientes de ACK)

iniciar temporizador}

else { incrementar cuenta de ACKs duplicados recibidos para s if (cuenta de ACKs duplicados para s == 3)

reenviar segmento con nº sec. s}

Algoritmo de retransmisión rápida:

un ACK duplicado paraun segmento ya con ACK

retransmisión rápida


Algoritmo de Nagle [RFC896]

Las conexiones interactivas (ssh, telnet) suelen enviar segmentos con muy pocos datos (uno, dos bytes).

¡Pérdida de eficiencia!Es más interesante reunir varios datos procedentes de la aplicación y mandarlos todos juntos.El algoritmo de Nagle indica que no se envíen nuevos segmentos mientras queden reconocimientos pendientes


Algoritmo de Nagle [RFC896]

Evento en emisor

Llegada de datos de la aplicación.Hay ACKs pendientes.

Llegada de un ACK pendiente.

Llegada de datos de la aplicación.No hay ACKs pendientes.

Llegada de datos de la aplicación.No queda sitio en el buffer delemisor.

Acción en emisor

Acumular datos en el buffer del emisor.

Inmediatamente enviar todos los segmen-tos acumulados en buffer.

Inmediatamente enviar datos al receptor.

Inmediatamente enviar datos si lo permi-te la ventana, aunque no se hayan reci-bido ACKs previos.

Capa de Transporte 3-79Raúl Durán, Nacho Pérez v1.4

3-80











3-81

en TCP, el receptor tiene un buffer de recepción

servicio de equilibrado de velocidad: equilibrar la velocidad de envío a la de la aplicación vaciando el buffer de recepciónla aplicación puede ser lenta leyendo del

buffer

el emisor no saturaráel buffer del receptor

a base de enviar mucho muy seguido

control de flujoTCP: Control de flujo


3-82

TCP control de flujo: cómo funciona

(suponer que el receptor TCP descarta segmentos fuera de orden)hay sitio en el buffer

RcvWindow = RcvBuffer -[LastByteRcvd - LastByteRead]

el receptor anuncia el espacio libre incluyendo el valor RcvWindow en los segmentosel emisor limita los datos sin ACK a RcvWindow

garantiza que el buffer de recepción no se desborda


3-83

TCP: ‘Round Trip Time’ y ‘Timeout’

P: ¿cómo fijar el tiempo de ‘timeout’ de TCP?más que RTT

pero RTT varíasi demasiado corto: ‘timeout’ prematuro

retransmisiones innecesarias

si demasiado largo: reacción lenta a pérdidas

P: ¿cómo estimar RTT?SampleRTT: tiempo medido desde transmisión de un segmento hasta recepción de ACK

ignorar retransmisionesSampleRTT variará, queremos un valor más “estable”

promedio de varias mediciones recientes, no el valor actual


3-84

TCP: ‘Round Trip Time’ y ‘Timeout’

EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT

media móvil ponderada exponencialla influencia de una muestra pasada decrece exponencialmentevalor típico: α = 0,125


3-85

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

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RTT

(mill

iseco

nds)

SampleRTT Estimated RTT


3-86

TCP: ‘Round Trip Time’ y ‘Timeout’Fijar el tiempo de expiración (‘timeout’)

EstimatedRTT más “margen de seguridad”gran variación en EstimatedRTT -> mayor margen de seguridad

primero, estimar cuánto SampleRTT se desvía de EstimatedRTT:

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-β)*DevRTT +β*|SampleRTT-EstimatedRTT|

(típicamente, β = 0,25)

Entonces fijar el tiempo de expiración:


Algoritmo de Karn

Si recibimos el reconocimiento de un paquete retransmitido, no tenemos forma de saber a cuál de las retransmisiones corresponde ese reconocimiento.Por ello, se ignoran los paquetes retransmitidos a la hora de computar el RTT.Este procedimiento se denomina algoritmo de Karn.

3-87Capa de TransporteRaúl Durán, Nacho Pérez v1.4

3-88











3-89

Principios de control de la congestión

Congestión:informal: “demasiadas fuentes enviando demasiados datos demasiado deprisa para que la red lo pueda asimilar”¡¡diferente a control de flujo!!síntomas:

paquetes perdidos (desbordamiento de bufferes en los routers)grandes retardos (encolado en los bufferes de los routers)¡¡un problema “top-10”!!


3-90

Formas de abordar el control de congestión

control de terminal a terminal:no hay realimentación explícita de la redla congestión se deduce por el retardo y las pérdidas observadas por los terminaleseste es el método de TCP

control asistido por la red:los routers proporcionan realimentación a los terminales

un bit que indica la congestión (SNA, DECnet, TCP/IP ECN, ATM)indicación explícita de la tasa a la que el emisor debería enviar

Dos formas principales de abordarla:


3-91

Caso de estudio: servicio ABR de las redes ATM

ABR: ‘Available Bit Rate’(Tasa de bits disponible):

“servicio elástico”si la ruta del emisor “infra-cargada”:

el emisor debería usar el ancho de banda disponible

si la ruta del emisor estácongestionada:

el emisor se limita a la tasa garantizada

células RM (‘resource management’, gestión de recursos) :enviado por el emisor, intercalado con las celdas de datoslos bits en las celdas RM se rellenan por los switches (“asistido por la red”)

bit NI : no hay mejora en la velocidad (congestión suave)bit CI : indica congestión

las celdas RM se devuelven al emisor por el receptor, sin modificar


3-92

Caso de estudio: servicio ABR de las redes ATM

campo ER (‘explicit rate’, tasa explícita) de 2 bytes en celda RM

un switch congestionado puede rebajar el valor ERla tasa del emisor es así la máxima que puede aguantar la ruta

bit EFCI en celdas de datos: se pone a 1 en switch congestionado

si la celda que precede a la RM tiene EFCI a 1, el emisor pone a1 el bit CI en la celda RM devueltaRaúl Durán, Nacho Pérez v1.4 Capa de Transporte

3-93











3-94

control de congestión en TCP : incremento aditivo, decremento multiplicativo

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow

filosofía: incrementar la tasa de transmisión (tamaño de la ventana), sondeando el ancho de banda accesible, hasta que hay pérdidas

incremento aditivo: incrementar cwnd en 1 MSS cada RTT hasta que haya pérdidasdecremento multiplicativo: dividir cwnd por 2 cuando las haya

tiempo

cwnd

: tam

año

de la

ven

tana

co

n co

nges

tión

diente de sierra: sondeo del ancho

de banda


3-95

Control de congestión TCP: detalles

el emisor limita la transmisión:LastByteSent-LastByteAcked

≤ cwnd

‘grosso modo’,

cwnd es dinámica, función de la congestión de la red percibida

¿Cómo percibe el emisor la congestión?evento de pérdida = expiración o 3 ACKs duplicadosel emisor reduce la tasa (cwnd) tras un evento de pérdida

3 mecanismos:AIMDarranque lentoconservador tras eventos de expiración

tasa = cwndRTT Bytes/s


3-96

TCP: Arranque lento

cuando se inicia la conexión, la tasa se incrementa exponencialmente hasta la primera pérdida:

inicialmente cwnd = 1 MSScwnd se dobla cada RTTse incrementa cwnd con cada ACK recibido

resumen: la tasa inicial es baja, pero crece exponencialmente rápido

Host A

un segmento

RTT

Host B

tiempo

2 segmentos

4 segmentos


3-97

Refinado: deducción de pérdidastras 3 ACKs duplicados

cwnd se divide por 2la ventana ya crece linealmente

pero tras una expiración:cwnd en cambio se pone a 1 MSS; la ventana entonces crece exponencialmentehasta un umbral, luego linealmente

3 ACKs duplicados indica que la red es capaz de entregar algunos segmentos

expiración indica una situación de congestión “más alarmante”

Filosofía:


3-98

RefinadoP: ¿cuándo debería

pasarse de incremento exponencial a lineal?

R: cuando cwnd llegue a 1/2 de su valor antes de la expiración

Implementación:variable ssthreshcon una pérdida, ssthreshse pone a 1/2 de cwndjusto antes de la pérdida


3-99

Resumen: Control de congestión TCP

expiraciónssthresh = cwnd/2

cwnd = 1 MSSdupACKcount = 0

retransmitir segmento que falta

Λcwnd > ssthresh

evitación decongestion

cwnd = cwnd + MSS (MSS/cwnd)dupACKcount = 0

transmitir nuevo(s) segmento(s), según se pueda

ACK nuevo.

dupACKcount++ACK duplicado

recuperación rápida

cwnd = cwnd + MSStransmitir nuevo(s) segmento(s), según se pueda

ACK duplicado

ssthresh= cwnd/2cwnd = ssthresh + 3


dupACKcount == 3


cwnd = 1 dupACKcount = 0

retransmitir segmento que faltassthresh= cwnd/2

cwnd = ssthresh + 3retransmitir segmento que falta

dupACKcount == 3cwnd = ssthreshdupACKcount = 0

ACK nuevo

arranque lento


cwnd = 1 MSSdupACKcount = 0


cwnd = cwnd+MSSdupACKcount = 0transmitir nuevo(s) segmento(s), según se pueda

ACK nuevodupACKcount++ACK duplicado

Λcwnd = 1 MSS

ssthresh = 64 KBdupACKcount = 0

NewACK!

NewACK!

NewACK!


3-100

eficiencia de TCP

¿cuál es la tasa media de TCP en función del tamaño de ventana y RTT?

ignorar el arranque rápidosea W el tamaño de la ventana cuando ocurre una pérdida

cuando la ventana es W, la tasa es W/RTTjusto tras la pérdida, la ventana pasa a W/2, y la tasa a W/2RTTla tasa media es: 0,75 W/RTT


3-101

Futuros de TCP: TCP sobre “tubos largos y gruesos”

ejemplo: segmentos de 1500 bytes, RTT 100ms, se quiere tasa de 10 Gbps requiere tamaño de ventana W = 83.333 segmentos en tránsitotasa de transferencia en función de la tasa de pérdidas:

L = 2·10-10 ¡¡una tasa de pérdidas muy baja!!nuevas versiones de TCP para alta velocidad

LRTTMSS⋅22,1


3-102

objetivo de equidad: si K sesiones TCP comparten el mismo enlace cuello de botella de ancho de banda R, cada uno debería tener una tasa media de R/K

conexión TCP 1

router cuello de botella

capacidad Rconexión TCP 2

Equidad en TCP


3-103

¿Por qué es equitativoTCP?2 sesiones que compiten:

el incremento aditivo da una pendiente de 1 en los incrementosel decremento multiplicativo decrementa la tasa proporcionalmente

R

R

reparto equitativo del ancho de banda

tasa de transferencia

de la conexión 1

tasa

de

tran

sfer

enci

a

de la

con

exió

n 2

evitación de congestión: incremento aditivopérdida: decrementar ventana en un factor de 2evitación de congestión: incremento aditivo

pérdida: decrementar ventana en un factor de 2


3-104

Equidad (más)Equidad y UDP

las aplicaciones multimedia a menudo no usan TCP

no quieren que la tasa de transf. se limite por el control de congestión

por eso usan UDP:envían audio/video a tasa constante, toleran pérdida de paquetes

Equidad y conexiones TCP paralelasnada impide a una aplicación abrir conexiones paralelas entre 2 hostslos navegadores lo hacenejemplo: enlace de tasa R permite 9 conexiones

una aplicación pide 1 TCP, obtiene tasa R/10una aplicación pide 11 TCPs, ¡¡obtiene tasa R/2!!


3-105

Capítulo 3: Resumenprincipios detrás de los servicios de la capa de transporte

multiplexación, desmultiplexacióntransferencia de datos fiablecontrol de flujocontrol de congestión

instanciación e implementación en Internet

UDPTCP


Arquitectura de Redes, capítulo 3 · SNMP transferencia fiable sobre UDP: añadir fiabilidad en la...

Documents

Transcript of Arquitectura de Redes, capítulo 3 · SNMP transferencia fiable sobre UDP: añadir fiabilidad en la...