La Capa de Transporte (Pt. 2)ags/RC/downloads/Handouts/Módulo 03 - La Ca… · último bit 1er....

Redes de ComputadorasRedes de ComputadorasDepto. de Cs. e Ing. de la Comp.Depto. de Cs. e Ing. de la Comp.

Universidad Nacional del SurUniversidad Nacional del Sur

Módulo 03Módulo 03La Capa de TransporteLa Capa de Transporte

(Pt. 2)(Pt. 2)

Redes de Computadoras - Mg. A. G. StankeviciusRedes de Computadoras - Mg. A. G. Stankevicius 22

CopyrightCopyrightCopyright © 2010-2020 A. G. Stankevicius

Se asegura la libertad para copiar, distribuir y modificar este documento de acuerdo a los términos de la GNU Free Documentation License, versión 1.2 o cualquiera posterior publicada por la Free Software Foundation,sin secciones invariantes ni textos de cubierta delantera o trasera

Una copia de esta licencia está siempre disponibleen la página http://www.gnu.org/copyleft/fdl.html

La versión transparente de este documento puedeser obtenida de la siguiente dirección:

http://cs.uns.edu.ar/~ags/teaching

http://www.gnu.org/copyleft/fdl.html

http://cs.uns.edu.ar/~ags/teaching


ContenidosContenidosServicios y protocolos de la capa de transporte

Multiplexado y demultiplexado de segmentos

Transporte no orientado a la conexión (UDP)

Teoría de transporte confiable de datos

Transporte orientado a la conexión (TCP)

Establecimiento y cierre de conexiones

Teoría de control de congestión

Control de congestión en TCP


Análisis de RDT/3.0Análisis de RDT/3.0El protocolo RDT/3.0 cumple con el objetivo propuesto, esto es, permite la transmisión confiable de datos sobre un canal no confiable

No obstante, este protocolo presenta un desempeño bastante pobre, lo que lo torna poco aplicable a escenarios del mundo real

Esta es una característica propia de los protocolosde la familia “stop-and-wait”


Desempeño de RDT/3.0Desempeño de RDT/3.0Consideremos la siguiente situación:

Se dispone de una línea dedicada de 1 Gb/s queune dos de las oficinas de una cierta compañía

Se intercambian paquetes de 1 KB y el RTT entreestas oficinas es de 30 ms

uenlace

= L/R

RTT + L/R= .008 ms

30.008 ms= 0.027%

dtrans

= L (cantidad de bits)

R (ancho de banda) = 8000 b

10^9 b/s= 8 microseg.

1 paq. / 30 ms = 1 Gb/s x 0.027% = 33.3 KB/s


Operatoria stop-and-waitOperatoria stop-and-wait

recep. del primer bit

recep. del ACK (t = L/R + RTT)comienza el envío del sig. paq.

envío del primer bit (t = 0)

envío del último bit (t = L/R)

recep. del último bitenvío del ACKRTT

uenlace

= L/R

RTT + L/R= .008 ms

30.008 ms= 0.027%


Operatoria en pipelineOperatoria en pipelineEl factor de utilización obtenido de apenas 0.027% es evidentemente inaceptable

Habría que permitir una operatoria en pipelinea fin de elevar el factor de ocupación

La idea básica es permitir que varios paquetesestén en camino al mismo tiempo

A tal efecto hace falta incrementar los númerosde secuencia disponibles

También hace falta alguna forma de almacenamiento intermedio tanto en emisor como receptor


Operatoria en pipelineOperatoria en pipeline

recep. del primer bit

recep. del ACK, comienza el envíodel sig. paq. (t = L/R + RTT)

envío del primer bit (t = 0)

envío del último bit (t = L/R)

último bit 1er. paq. / envío ACKRTT

uenlace

= 3 x L/R

RTT + L/R= .024 ms

30.008 ms= 0.08%

último bit 2do. paq. / envío ACK

último bit 3er. paq. / envío ACK

¡mejora la utilizaciónpor un factor de 3!


Operatoria en pipelineOperatoria en pipelineGo-Back N (GBN)

El emisor puede tener hasta n paquetes aun sin confirmar

El receptor sólo envía ACKs acumulativos(¡no tolera huecos!)

El emisor sólo requiere un temporizador para el paquete más antiguo sin reconocer

Selective Repeat (SR)

El emisor puede tener hasta n paquetes aun sin confirmar

El receptor envía ACKs individuales para cada paquete

El emisor mantieneun temporizador para paquete aun no reconocido


Protocolo Go-Back-NProtocolo Go-Back-NEl protocolo GBN es una de las formasde implementar la operatoria en pipeline

Se reservan k bits del encabezado para los números de secuencia de los paquetes

Se permiten hasta una ventana deslizante de n paquetes en tránsito, esto es, aquellos cuales cuya confirmación de recepción aún no ha sido recibida

ACK yarecibido

enviadosesperando ACK

a ser enviados todavíano usables

ventana deslizantede tamaño N


Emisor GBNEmisor GBN

esperarllamada

de arriba

base = 1proxnum = 1

envio_rdt(datos)

if(proxnum < base + N) { paqenv[proxnum] = empaq(proxnum, datos, checksum) envio_udt(paqenv[proxnum]) if (proxnum == base) poner(alarma) proxnum++} else rechazar(datos)

disparo(alarma)

poner(alarma)envio_udt(paqenv[base])envio_udt(paqenv[base + 1])¼

envio_udt(paqenv[proxnum - 1])

recep_rdt(paqrec) &&!corrupto(paqrec)

base = nrosec(paqrec) + 1if (proxnum == base) sacar(alarma)else poner(alarma)

recep_rdt(paqrec) &&corrupto(paqrec)


Receptor GBNReceptor GBN

esperarllamadade abajo

recep_rdt(paqrec) && !corrupto(paqrec) &&(nrosec(paqrec) == proxnumreq)

datos = desempaq(paqrec)entregar(datos)paqenv = empaq(proxnumreq, ACK, checksum)envio_udt(paqenv)proxnumreq++

recep_rdt(paqrec) &&(corrupto(paqrec) || (nrosec(paqrec) != proxnumreq)))

envio_udt(paqenv)

proxnumreq = 1paqenv = empaq(0,ACK,checksum)


Análisis GBNAnálisis GBNEl receptor sólo envía un mensaje de ACK para el paquete correctamente recibido con mayor número de secuencia

Esta política puede generar mensajes de ACK duplicados

El receptor sólo necesita recordar el númerode secuencia del próximo paquete que desea

Los paquetes recibidos fuera de ordenson descartados

El receptor no requiere almacenamiento intermedio


GBN en acciónGBN en acción

envío paq. 0

recep. paq. 0, envío ACK 0envío paq. 2

rec. ACK 0, env. paq. 4

reenvío paq. 2

envío paq. 1

envío paq. 3 recep. paq. 1, envío ACK 1

recep. paq. 3 (se descarta)reenvío ACK 1

rec. ACK 1, env. paq. 5 recep. paq. 4 (se descarta)reenvío ACK 1recep. paq. 5 (se descarta)reenvío ACK 1recep. paq. 2, envío ACK 2

reenvío paq. 3

reenvío paq. 5reenvío paq. 4

recep. paq. 3, envío ACK 3recep. paq. 4, envío ACK 4recep. paq. 5, envío ACK 5

1 2 3 4 5 60 71 2 3 4 5 60 71 2 3 4 5 60 71 2 3 4 5 60 7

1 2 3 4 5 60 71 2 3 4 5 60 7

1 2 3 4 5 60 71 2 3 4 5 60 71 2 3 4 5 60 71 2 3 4 5 60 7


Repetición SelectivaRepetición SelectivaEl protocolo Repetición Selectiva (SR) es otra implementación de la operatoria en pipeline

La idea central es disminuir el número de paquetesa ser reenviados al recuperarse de una pérdida

A diferencia de GBN, el receptor reconocepor separado a cada uno de los paquetes correctamente recibidos

El receptor debe contar con un almacenamiento intermedio para alojar los paquetes recibidos correctamente pero fuera de orden


Repetición SelectivaRepetición SelectivaEl emisor sólo debe reenviar aquellos paquetes para los que aún no se haya recibido el mensaje de ACK correspondiente

Esto implica que debemos contar con un temporizador independiente para cada paquete enviado cuyo ACK asociado aún no haya sido recibido

El emisor cuenta con una ventana deslizantede n números consecutivos de secuencia

La ventana representa el conjunto de paquetes que tiene permitido tener en tránsito al mismo tiempo


Visión del emisor y receptorVisión del emisor y receptor

ventana deslizante

enviados, ACK ya recibidoenviados, esperando ACKusables, a ser enviadosno usables

ventana deslizante

emisor SR

receptor SR

recibidos fuera de orden, ACK ya enviadoa la espera, aún no recibidos

aceptablesno usables


Emisor SREmisor SREl emisor SR debe reaccionar ante los eventos que se presenten de la siguiente manera:

Al recibir un nuevo paquete a ser enviado debe verificar si el siguiente número de secuenciase encuentra dentro de la ventana

Al dispararse la alarma de un paquete debe reenviar sólo ese paquete y debe reiniciar el temporizador

Al recibir un ACK debe marcar ese paquete como recibido y en caso de ser el menor número de paquete no reconocido, debe avanzar la ventana hasta el próximo paquete aún sin reconocer


Receptor SRReceptor SREl receptor SR debe reaccionar ante los eventos que se presenten de la siguiente manera:

Al recibir un paquete con número de secuencia basese envía su ACK y se avanza la ventana hastael próximo paquete esperado pero aún no recibido

Al recibir un paquete con número de secuencia entre base+1 y base+n-1 se envía su ACK y se guarda provisoriamente en el almacenamiento intermedio

Al recibir un paquete con número de secuencia entre base-n y base-1 sólo se envía su respectivo ACK

En cualquier otro caso, no se toma acción alguna


Protocolo SR en acciónProtocolo SR en acción

1 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 90

1 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 90

1 2 3 4 5 6 7 8 90

enviados conf. enviados no conf.usables no usables

fuera de ordena la espera

1 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 90

1 2 3 4 5 6 7 8 90

alarmapaq. 2

1 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 90

1 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 90


El dilema del receptor SREl dilema del receptor SR

1 2 3 0 1 20

1 2 3 0 1 20



1 2 3 0 1 201 2 3 0 1 20

1 2 3 0 1 201 2 3 0 1 20

1 2 3 0 1 20

1 2 3 0 1 201 2 3 0 1 201 2 3 0 1 20

1 2 3 0 1 201 2 3 0 1 20


El dilema del receptor SREl dilema del receptor SR

1 2 3 0 1 20

1 2 3 0 1 20



1 2 3 0 1 201 2 3 0 1 20alarma

paq. 0 1 2 3 0 1 201 2 3 0 1 20

1 2 3 0 1 20

1 2 3 0 1 20

¡SR entrega un paquetefuera de orden!


Análisis SRAnálisis SREl receptor SR no tiene forma de distinguir entre estos dos escenarios

En el primer caso el funcionamiento es el esperado, pero en el segundo caso, SR termina entregandoun paquete fuera de orden

¿Qué relación tiene que cumplirse entreel tamaño de ventana y el conjuntode números de secuencia disponibles?

El tamaño de ventana debe ser menor o igual ala mitad de la cantidad de números de secuencia


Transmission Control ProtocolTransmission Control ProtocolEs un protocolo punto a punto

Permite intercambiar un flujo de bytes

Implementa una operatoria en pipeline

Los mecanismos de control de flujo y de congestión determinan el tamaño de la ventana deslizante

Puede requerir hacer uso de almacenamiento intermedio ya sea al enviar o al recibir

Suele ser obligatorio en el emisor pero llamativamente es opcional en el receptor


Transmission Control ProtocolTransmission Control ProtocolPosibilita la transferencia bidireccional de datos

Una misma conexión permite enviar y recibir datos.

El parámetro MSS denota el tamaño máximo de segmento aceptado por una dada implementación

Es orientado a la conexión

Requiere una fase previa de inicialización antesde comenzar con el intercambio de información

Implementa control de flujo

El emisor nunca satura de datos al receptor


Estructura de un segmentoEstructura de un segmento

formato de unsegmento TCP

puerto origen puerto dest.

datos de la aplicación(tam. variable)

32 bits

número de secuencia

número de reconocimiento

f ven. de recep.

checksum punt. urgente

opciones (tam. variable)

srpaulon. -

se cuenta a nivelde bytes, no a nivel

de paquetes

campo para publicitarel tamaño de la ventana

de recepciónchecksum(análogo a UDP)

URG permite marcar alos datos como urgentes

ACK denota que el nro.de reconocimiento es válido

PSH solicita se procesenlos datos del buffer

RST, SYN, FIN se utilizanpara establecer y finalizar

conexiones.


Secuencia y reconocimientoSecuencia y reconocimiento

ACK yarecibido

enviadosesperando ACK

a ser enviados todavíano usables

ventana deslizantede tamaño N




f ven. de recep.srpaulon. -



f ven. de recep.srpaulon. -



Secuencia y reconocimientoSecuencia y reconocimientoEl número de secuencia de un segmento indica la posición del byte transferido dentro del flujo de bytes de la conexión

El número de reconocimiento indica el próximo número de secuencia esperado del otro lado

TCP hace uso de reconocimientos acumulativos,esto es, al reconocer un cierto número de secuenciase reconocen implícitamente todos los anteriores

La especificación formal nada dice acerca de qué hacer con los segmentos fuera de orden


Secuencia y reconocimientoSecuencia y reconocimiento

el usuario escribe una 'C'

el cliente reconocela recepción del echo

de la 'C'

cliente telnet servidor telnet

n.sec=42; n.ACK=79; dato='C' el servidor reconoceel mensaje y muestrala 'C' por pantalla

n.sec=79; n.ACK=43; dato='C'

n.sec=43; n.ACK=80


Tiempo de espera razonableTiempo de espera razonable¿Qué valor resulta conveniente adoptar como tiempo de espera razonable (TCP-timeout)?

Al menos tiene que ser mayor que el RTT

Pero el RTT es un valor dinámico, el cual cambiaen el tiempo

Un valor excesivamente bajo va a causar reenvíos prematuros absolutamente innecesarios

Pero un valor demasiado alto hace que seamuy costoso recuperarse ante una pérdida


Estimación del RTTEstimación del RTT¿Cómo se puede estimar el valor del RTT?

Cada vez que se recibe un ACK como respuesta aun mensaje enviado previamente se puede obtener una nueva estimación del RTT

Es conveniente no hacer uso de las retransmisionesa la hora de estimar el RTT. ¿Por qué será?

La estimaciones obtenidas posiblemente oscilarána lo largo del tiempo, por lo que hace falta concebir algún mecanismo que permita sopesar múltiples estimaciones


TCP RTTTCP RTTPara obtener una estimación adecuada del RTT se hace uso del alisado exponencial EMA (Exponentially-weighed Moving Average)

EMA prioriza la última medición del RTT y penaliza cada vez mas a las mediciones anteriores de forma exponencial

Un valor usual para α es 0.125

RTT-estimado = (1 - α) × RTT-estimado + α × RTT-observadoRTT-estimado = (1 - α) × RTT-estimado + α × RTT-observado


RTT observado vs. estimadoRTT observado vs. estimadoRTT: 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

isec

onds

)

SampleRTT Estimated RTT


TCP timeoutTCP timeoutUna vez obtenida la estimación del RTT es posible elegir un valor adecuado de timeout

Al valor estimado de RTT se le debe incorporarun margen de seguridad adicional

Ante grandes cambios en el valor estimado, el margen de seguridad debería incrementarse

Un valor usual para β es 0.25

desvmed-RTT = (1 - β) × desvmed-RTT + β × | RTT-observado – RTT-estimado |desvmed-RTT = (1 - β) × desvmed-RTT + β × | RTT-observado – RTT-estimado |

TCP-timeout = RTT-estimado + 4 × desvmed-RTTTCP-timeout = RTT-estimado + 4 × desvmed-RTT


Transmisión confiableTransmisión confiableTCP implementa un canal de comunicación confiable por encima del canal no confiable provisto por la capa de red

Hace uso de las técnicas exploradas en la familiade protocolos RDT y de los protocolos GBN y SR

Usa un único temporizador para controlarlas retransmisiones producto de las pérdidas

También se disparan retransmisiones al recibir mensajes de ACK duplicados


Emisor TCP (simplificado)Emisor TCP (simplificado)Al recibir nuevos datos de la aplicación:

Crea un segmento con el número de secuencia que corresponda (esto es, el desplazamiento del primer byte a ser transmitido a través del flujo de bytes)

Programar el temporizador, en caso de no estar ya corriendo, usando el TCP-timeout antes calculado

Al dispararse la alarma de temporizado:

Retransmitir el segmento que expiró

Reprogramar el temporizador.


Emisor TCP (simplificado)Emisor TCP (simplificado)Al recibir un mensaje de ACK:

Si se trata de un mensaje de ACK asociadoa un segmento para el cual se estaba esperado confirmación, marcar el segmento como confirmadoy reiniciar el temporizador sólo en caso de contarcon otros segmentos para los cuales se está aún esperando confirmación

Por el momento asumiremos como simplificaciónque no se reciben mensajes de ACK por duplicado

También ignoraremos el control de flujo y la gestión de las congestiones (por ahora)


Emisor TCP (simplificado)Emisor TCP (simplificado)

a laespera deun evento

proxnumsec = primernumsecbase = primernumsec

“datos” recibidos de la aplicación

“segmento TCP” =empaq(proxnumsec, “datos”, checksum);

enviar(“segmento TCP”);proxnumsec = proxnumsec + largo(“datos”);if (!“alarma puesta”)

poner(alarma);

disparo(alarma)

reenviar el segmento aún-no reconocido con menor-nro. de sec.;

poner(alarma);

mensaje de ACK recibidocon nro. de ACK x

if (x > base)base = x;if (“quedan segmentos-

no reconocidos”)poner(alarma);


Pérdida de un ACKPérdida de un ACK

n.sec=92; 8 bytes de datos

n.ACK=100


n.ACK=100

base = 100;

timeout


Timeout prematuroTimeout prematuro


n.ACK=10

0


n.ACK=120

base = 120;

n.ACK=12

0

base = 120;

base = 100;

timeout



Reconocimiento acumulativoReconocimiento acumulativo


n.ACK=100n.sec=100; 20 bytes de datos

n.ACK=120

base = 120;


Ajuste fino del temporizadorAjuste fino del temporizadorLa pérdida de segmentos se debe usualmentea la congestión en alguno de los routersdel núcleo de la red

Al producirse la retransmisión de un segmento a consecuencia del disparo del temporizadordebemos tener esto en consideración:

Al volver a programar el temporizador a consecuencia de la retransmisión se debe duplicar su duración

Es decir, se dejará momentáneamente de ladoel mecanismo de estimación basado en el RTT


Generación de confirmacionesGeneración de confirmacionesAl llegar un segmento en orden, esto es, conel número de secuencia esperado, y ademássi ya se han confirmado todos los bytesanteriores del flujo de bytes:

Este caso se conoce como “confirmación demorada” (delayed ACK), pues se debe esperar hasta 500ms para ver si se reciben más segmentos

De no aparecer segmento alguno, se envíala confirmación al acabarse el tiempo de espera


Generación de confirmacionesGeneración de confirmacionesAl llegar un segmento en orden, esto es, conel número de secuencia esperado, pero conla salvedad de que el último segmento aúnno fue confirmado:

Enviar inmediatamente un único mensaje confirmando cumulativamente ambos segmentos

Este caso se produce al llegar un segundo segmento mientras que con un segmento anterior se estaba ensayando una confirmación demorada


Generación de confirmacionesGeneración de confirmacionesAl llegar un segmento fuera de orden el cual genera un hueco (faltan bytes en el medio):

Enviar inmediatamente un mensaje de confirmación duplicado indicando el número de secuenciadel primer byte faltante

Al llegar un segmento fuera de orden el cual completa parcial o totalmente el comienzode un hueco anterior:

Enviar inmediatamente un mensaje de confirmación para la parte cubierta del hueco


Retransmisión anticipadaRetransmisión anticipadaEsperar hasta que se dispare la alarma asociada a un segmento implica tenerque esperar una gran cantidad de tiempo

El emisor podría darse cuenta de que se produjo algún inconveniente al detectarla recepción de confirmaciones duplicadas

El emisor suele enviar múltiples segmentos uno tras otro (mientras la ventana lo permita)

Al perderse un segmento llegarán múltiples mensajes de confirmación para el último segmento recibido


Retransmisión anticipadaRetransmisión anticipadaEl emisor al observar tres mensajes de confirmación repetidos puede asumir queel segmento con ese número de secuenciase malogró

La técnica de retransmisión anticipada (fast retransmit) consiste en retransmitir un cierto segmento antes de que se dispare la alarmadel temporizador


Retransmisión anticipadaRetransmisión anticipada


n.ACK=100


n.ACK=100

n.ACK=100

n.ACK=100


timeout


¿¿Preguntas?Preguntas?

La Capa de Transporte (Pt. 2)ags/RC/downloads/Handouts/Módulo 03 - La Ca… · último bit 1er....

Documents

Transcript of La Capa de Transporte (Pt. 2)ags/RC/downloads/Handouts/Módulo 03 - La Ca… · último bit 1er....