Cap3 Transporte

Capa de Transporte
Gran parte de este material fue tomado del captulo 3 del libro:
3rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004. Traduccin: Vctor J. Sosa
Computer Networking: A Top Down Approach Featuring the Internet,
copyright 1996-2004 J.F Kurose and K.W. Ross, All Rights Reserved
Capa de transporte
3-1
Capa de Transporte
Objetivos: Comprender los principios que fundamentan los servicios de transporte:
Multiplexado/demulti plexado Transferencia de datos fiable Control de flujo Control de congestin
Aprender los protocolos de transporte en Internet:

UDP: transporte no orientado a conexin TCP: transporte orientado a conexin Control de congestin en TCP
Capa de transporte
3-2
Temas a cubrir
3.1 servicios a nivel de transporte 3.2 multiplexado y /demultiplexado 3.3 transporte sin conexin: UDP 3.4 principios sobre transferencia de datos fiable 3.5 transporte orientado a conexin: TCP
Estructura del segmento Transferencia de datos fiable Control de flujo Gestin de la conexin
3.6 Principios de control de congestin 3.7 control de congestin en TCP

Capa de transporte 3-3
Funciones de la Capa de Transporte

Esta capa debe proporcionar un transporte de datos desde la mquina origen a la mquina de destino, independientemente de la red o redes fsicas en uso. La capa de transporte es el corazn de la jerarqua de protocolos.
Capa de transporte
3-4
Comunicacin en la Capa de Transporte

Mquina origen
Capa de aplicacin
Mquina destino
Capa de aplicacin
Capa de transporte Capa de red Capa de enlace de datos
Virtual
Capa de transporte Capa de red Capa de enlace de datos
Capa fsica
Capa fsica
Real
Capa de transporte
3-5
Relacin con las Capas Vecinas

Host 1
Capa de aplicacin
Direccin de transporte (TSAP)
Host 2
Capa de aplicacin
Entidad de transporte
TPDU Protocolo de transporte
Entidad de transporte
Capa de red
Direccin de red (NSAP)
Capa de red
TSAP: Transport Service Access Point NSAP: Network Service Access Point
Capa de transporte
3-6
Servicios Proporcionados a las Capas Superiores

Ofrece servicios especiales que no estn en la capa de red. Proporciona primitivas independientes de la capa de red. Asla las capas superiores de la tecnologa, el diseo y las imperfecciones de la subred. Se pueden tener servicios orientados a conexiones (confiable) o sin conexiones.
Capa de transporte
3-7
Servicios de transporte y protocolos

Provee comunicacin lgica entre aplicaciones corriendo en diferentes mquinas Los protocolos de transporte slo corren en los sistemas finales Lado emisor: divide el mensaje de la aplicacin en segmentos y los pasa a la capa de red Lado receptor: reensambla los segmentos en forma de mensajes y los pasa a la capa de aplicacin Se cuenta con ms de un protocolo de transporte disponible para las aplicaciones en Internet TCP y UDP
application transport network data link physical network data link physical network data link physical
te or sp an tr
network data link physical
co gi l
e oem tr ex
network data link physical application transport network data link physical
Capa de transporte
re xt
o m
3-8
Primitivas de la Capa de Transporte

Cliente Paquetes TPDU Connect Receive Send Receive Send Disconnect Send Receive Send Receive Servidor Listen
Capa de transporte
3-9
Capa de Transporte vs. Red

Capa de red:
Analoga: comunicacin lgica entre dos mquinas (hosts) comunicacin lgica entre procesos
12 chicos envan cartas a 12 chicas
procesos = chicos(as) Mensajes de la aplicacin = las cartas en los sobres Mquinas = sus casas Protocolo de transporte = Ana y Beto Protocolo en la capa de red = servicio postal
Capa de transporte:
Mejora y se apoya de los servicios de la capa de red.
Capa de transporte
3-10
Protocolos de transporte en Internet

Confiable, manteniendo el orden en los envos: TCP
Control de congestin Control de flujo Inicio de conexin
application transport network data link physical
network data link physical network data link physical
te or sp an tr
co gi l
No fiable, sin mantener el orden en los envos: UDP

Breve extensin al esquema de mejor esfuerzo de IP
e oem tr ex
network data link physical application transport network data link physical
re xt
o m
Servicios no disponibles:
Garanta en retrasos Garanta en ancho de banda
Capa de transporte
3-11
Temas a cubrir

Multiplexado/demultiplexado
Demultiplexado en mquina receptora: Multiplexado en mquina emisora: Colecta los datos que provienen de los sockets, envolvindolos con una cabecera (que posteriormente ser utilizada para demultiplexar)
Pasa los segmentos recibidos al socket indicado

= socket aplicacin transporte red enlace fsico P3 = proceso P1 P1 aplicacin transporte red enlace fsico
P2
P4
aplicacin transporte red enlace fsico
host 1
host 2
host 3
Cmo funciona el demultiplexado?

Las mquinas reciben datagramas de IP Cada datagrama cuenta con sus direcciones IP origen y destino, Cada datagrama transporta un segmento de la capa de transporte Cada segmento tiene un nmero de puerto origen y destino Las mquinas utilizan las direcciones IP y los nmeros de puertos para dirigir los segmentos al socket correcto
32 bits
Puerto origen # Puerto dest #
Otros campos de la cabecera
Datos de la aplicacin (mensaje)

Formato general de un segmeto TCP/UDP
Capa de transporte
3-14
Demultiplexado en servicios sin conexin

Se crean sockets con sus nmeros de puerto:
DatagramSocket mySocket1 = new DatagramSocket(99111); DatagramSocket mySocket2 = new DatagramSocket(99222);
Cuando un host recibe un segmento UDP:

Verifica su puerto de destino Conduce el segmento UDP hacia el socket con ese puerto.
El socket UDP se identifica por:

(dir IP origen, nm. de puerto origen, dir IP dest, num. Puerto destino)
Puede recibir distintos datagramas IP con diferentes direccin de origen y/o nmeros de puerto que direccionar al socket indicado
Demultiplexado en servicio sin conexin

DatagramSocket serverSocket = new DatagramSocket(6428);
P2 P3 P1 P1
SP: 6428 DP: 9157 SP: 9157 DP: 6428
SP: 6428 DP: 5775 SP: 5775 DP: 6428
cliente IP: A
servidor IP: C
Cliente
IP:B
Capa de transporte
3-16
Demultiplexado en servicio con conexin

El socket TCP se identifica por TCP:
(dir IP origen, nm. de puerto origen, dir IP dest, num. Puerto destino)
Las mquinas servidoras suelen utilizar mltiples sockets TCP al mismo tiempo:
Cada socket identificado por sus 4 valores: Ip origen y dest, puerto origen y destino
Los servidores Web mantienen diferentes sockets con cada cliente que se conecta
La versin no persistente de HTTP utiliza diferentes sockets en cada peticin
Capa de transporte
3-17
Demultiplexado en servicio con conexin

P1 P4 P5 P6 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 DP: 80 S-IP: B D-IP:C P2 P1 P3
client IP: A
SP: 9157 DP: 80 S-IP: A D-IP:C
server IP: C
Client
IP:B
Capa de transporte
3-18
Demux en servicio con conexin: utilizando Threadeds

P1 P4 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 DP: 80 S-IP: A D-IP:C SP: 9157 DP: 80 S-IP: B D-IP:C P2 P1 P3
cliente IP: A
servidor IP: C
Cliente
IP:B
Capa de transporte
3-19
Temas a cubrir

UDP: User Datagram Protocol [RFC 768]

Protocolo de transporte muy ligero! Servicio con filosofa del mejor esfuerzo. Los segmentos UDP pudieran: perderse Llegar en desorden a la aplicacin
Porqu usar UDP?
sin conexin refiere a:
No hay previo acuerdo (handshaking) entre emisor y receptor Cada segmento UDP es manejado sin considerar a los dems
No pierde tiempo en establecer una conexin Es simple: no se mantiene un estado de la conexin en el emisor ni el receptor Cabecera muy pequea (igual a menos carga) No hay control de congestin: con lo cual se pueden emitir paquetes tan rpido como los requiera la aplicacin.
Capa de transporte
3-21
UDP (Cont..)
Es muy popular en aplicaciones multimedia, las cuales son: Tolerantes a prdidas Sensibles a la tasa de Longitud, en bytes del segmento UDP, transferencia incluyendo 32 bits #Puerto origen # Puerto dest long checksum
Otros usos de UDP
la cabecera
DNS SNMP Si queremos dar confiabilidad de transmisin utilizando UDP, tenemos que hacer lo que corresponda en la capa de aplicacin Recuperacin de errores especficos de la aplicacin.
Datos de la aplicacin (mensaje)
Formato del segmento UDP

UDP: checksum
Objetivo: detectar errores (e.g., bits cambiados) en el segmento transmitido Emisor:
Trata el contenido del segmento como palabras de 16 bits checksum: suma todas las palabras de 16 bits y aplica complemento a 1. Graba el valor del checksum en su campo correspondiente en el segmento
Receptor:
Calcula el checksum del segmento recibido Verifica si el valor obtenido es igual al que trae el campo de checksum: NO se detect un error Si ho hay error. Quizs si pudiera haber otro tipo de errores.
Ejemplo de Checksum
Ejemplo: tenemos 2 palabras de 16 bits en el contenido del segmento
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 acarreo 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
suma 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Complemento a 1 Nota: Cuando sumamos nmeros binarios, si un bit se desborda en la parte ms significativa, se suma al resultado.
Temas a cubrir

Principios sobre transferencia de datos fiable
Tiene gran relevancia en las capas de aplicacin, transporte y enlace. Se encuentra en la lista de los 10 temas ms importantes de redes
Las caractersticas que proporcione el canal no fiable determinarn la complejidad del protocolo de transferencia fiable Capa de transporte
3-26
Transferencia de datos fiable (tdf): introduccin

rdt_send(): llamado por la capa superior, (e.g., por una aplic.). Proporciona datos que sern enviados
deliver_data(): llamado por el servicio de transporte fiable para enviar datos a la capa superior
Lado emisor
Lado receptor
udt_send(): llamado por el servicio de transporte fiable, para transferir paquetes de datos sobre un canal no fiable
rdt_rcv(): llamado cuando se reciben paquetes del lado del receptor
Capa de transporte
3-27
tdf: anlisis
Revisaremos como
Desarrollar de manera incremental la parte emisora y receptora de un protocolo de tdf Iniciamos considerando transferencia de datos de manera unidireccional Aunque la informacin de control fluir en ambas direcciones. Utilizaremos mquinas de estados finitos (FSM) para mostrar la especificacin del emisor y receptor
Evento que causa una transicin Acciones tomadas en la transicin
estado 1
evento acciones
estado 2
Capa de transporte
3-28
tdf1.0:
transferencia fiable sobre un canal fiable
Partimos de que el canal a utilizar es totalmente fiable

No hay errores en los bits No hay prdida de paquetes Se transmite slo un paquete a la vez.
Diagramas de transicin para el emisor y receptor:

El emisor enva datos utilizando el canal fiable El receptor recibe los datos de dicho canal
rdt_send(data) packet = make_pkt(data) udt_send(packet)
Espera por llamada de abajo
Espera por llamada de arriba
rdt_rcv(packet) extract (packet,data) deliver_data(data)
emisor
receptor
tdf2.0: usando canal con errores

El canal podra modificar bits del paquete
Pregunta: Cmo nos recuperamos del error? :
Usar checksum para detectar errores
Lo anterior nos ha hecho incorporar nuevos mecanismos con los que no contaba el tdf1.0 :
emisor de manera explicita que el paquete lleg bien Usando acknowledgements negativos(NAKs): el receptor informa al emisor que el paquete tuvo errores Cuando el emisor recibe un NAK retransmite el paquete
Usando acknowledgements (ACKs): el receptor informa al
Deteccin de errores Retroalimentacin por parte del receptor: mensajes de control (ACK,NAK) receptor->emisor
Capa de transporte
3-30
tdf2.0: Diagrama de estados

rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt)
Espera por ACK o NAK
receptor
rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
emisor
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

No hacer nada
Capa de transporte
3-31
tdf2.0: operacin sin errores

udt_send(sndpkt)


tfd2.0: escenario con errores

udt_send(sndpkt)


tdf2.0 tiene un grave desperfecto

qu pasara si los mensajes de ACK/NAK se corrompieran? Necesitamos manejo de duplicados:
El emisor retransmite el paquete actual si el ACK/NAK es difuso. El emisor aade un nmero de secuencia a cada paquete El receptor descarta duplicados
El emisor no sabe lo que ha pasado en el receptor. Podramos retransmitir, pero generamos duplicados
Se considera filosofa stop & wait
El emisor enva un paquete y espera por la respuesta del receptor

Capa de transporte
3-34
tdf2.1: manejo de los ACK/NAKs difusos por parte del emisor

rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) &&
Espera por llamada 0 de arriba Espera por ACK o NAK 0
( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)

Espera por ACK o NAK 1
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt)
Espera por llamada 1 de arriba
rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt)
Capa de transporte
3-35
tdf2.1: manejo de los ACK/NAKs difusos por parte del receptor

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(NAK, chksum) udt_send(sndpkt)
Espera por llamada 0 de abajo Espera por llamada 1 de abajo
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)
rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)
Capa de transporte
3-36
tdf2.1: anlisis
Emisor: Aadimos un nmero de secuencia al paquete Para este caso 2 nmeros de secuencia son suficientes (0,1). por qu? Debemos garantizar que nos llego el ACK/NAK correcto Hemos duplicado la cantidad de estados Receptor: Debe revisar que el paeuqte recibido no sea duplicado
El estado debe recordar si el nmero de secuencia del paquete a esperar es 0 o 1.
nota: el receptor no puede saber si su ltimo ACK/NAK recibi un OK en el emisor.
En el estado se indica que el nmero de secuencia del paquete 0 o 1 es el que se espera.
Capa de transporte
3-37
tdf2.2: protocolo libre de NAK

Podemos tener la misma funcionalidad que rdt2.1, utilizando slo ACKs En lugar de un NAK, el receptor emite un ACK por el ltimo paquete recibido bien.
El receptor debe incluir explcitamente el nmero de secuencia del paquete que fue recibido bien.
Un ACK duplicado en el emisor ocasionar la misma accin que el NAK: retransmitir el paquete actual.
Capa de transporte
3-38
tdf2.2: fragmentos de emisor y receptor

rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || Espera Espera por por llamada isACK(rcvpkt,1) ) ACK 0 0 udt_send(sndpkt) de arriba
Fragmento de emisor
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)
Espera por llamada 0 de abajo
Fragmento del receptor
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt)
Capa de transporte
3-39
tdf3.0: Canales con errores y prdidas

Tenemos una nueva consideracin: el canal a utilizar puede perder paquetes (datos o ACKs) Estratega: Que el emisor espere un tiempo razonable por el ACK
Tenemos: checksum, num. de secuencia, ACKs, en este caso la retransmisin ser de ayuda, pero no lo suficiente.
Retransmite si no se recibe ACK es ese tiempo Si el paquete (o el ACK) slo se retras (no se perdi) : Tendremos un duplicado en la transmisin, pero el uso de los nmeros de secuencia ya nos ayuda con esto. El receptor debe especificar el num de secuencia del paquete que es confirmado (ACK) Requerimos de un temporizador
tdf3.0 emisor (diagrama de estados)

rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer
Espera por llamada 0 de arriba Espera por ACK0
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) )
rdt_rcv(rcvpkt)
timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timer timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) )
Espera por ACK1
Espera por llamada 1 de arriba rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer
rdt_rcv(rcvpkt)
Capa de transporte
3-41
tdf3.0 forma de actuar

emisor receptor emisor receptor
(a) Operacin sin prdidas
(b) Operacin con prdidas
Capa de transporte
3-42
tdf3.0 forma de actuar

emisor receptor emisor receptor
(c) Prdida de ACK
(d) Timeout prematuro
Capa de transporte
3-43
Eficiencia de tdf3.0
tdf3.0 funciona bien, pero su eficiencia es muy discutible. ejemplo: consideremos un enlace de 1 Gbps, un retardo de propagacin de 15 ms, (RTT=30ms), Un tamao de paquete de 8Kb
T transmisin =
L (long paq en bits) R (tasa de transm, bps)
8000bits = 8 microseg 10**9 bits/seg
U emisor: utilizacin fraccin de tiempo que el emisor estuvo enviando Suponiendo ACK extremadamente pequeo y el receptor enva el ACK tan pronto como recibe el ltimo bit del paquete. El ACK estar de vuelta en el emisor en t = RTT + L/R = 30,008ms
emisor
L/R RTT + L / R
.008
30.008
= 0.00027
El emisor solo est emitiendo una mnima parte del tiempo que utiliza. Un mensaje de 1KB cada 30 ms -> un throuput de 267Kbps en un enlace de 1Gbps Se manifiesta que el protocolo est desaprovechando el uso de los recursos fsicos.
Capa de transporte
3-44
tdf3.0: usando operacin stop-andwait

emisor
Primer bit transmitido del paquete, t = 0 ltimo bit transmitido del paquete, t = L / R
receptor
primer bit del paquete llega
RTT
Llega ltimo bit,se enva ACK
Llegada del ACK, enva sig paquete
t = RTT + L / R
emisor
L/R RTT + L / R
.008
30.008
= 0.00027
Capa de transporte
3-45
Mejora: Protocolos con pipelining

Pipelining: el emisor emite mltiples paquetes que tendrn que ser reconocidos (AKCs)
Necesitaremos incrementar el rango del nmero de secuencias (ya no ser posible slo 1 y 0) Se ocupar tambin el manejo de buffers en el emisor y/o receptor
(a) Operacin stop and wait
(b) Operacin con pipelining
Dos formas gnericas de protocolos con pipelining: GBN (go-Back-N), y SR (selective repeat) de transporte Capa
3-46
Pipelining: Incrementa la utilizacin

emisor
Primer bit transmitido del paquete, t = 0 ltimo bit transmitido del paquete, t = L / R
receptor
RTT
primer bit del paquete llega Llega ltimo bit,se enva ACK ltimo bit del 2do paquete, se enva ACK ltimo bit del 3er paquete, se enva ACK
Llegada del ACK, enva sig paquete t = RTT + L / R
Se incrementa el factor de utilizacin en un factor de 3!
sender
3*L/R RTT + L / R
.024
30.008
= 0.0008
Capa de transporte
3-47
Protocolo Go-Back-N (GBN)

emisor:
Incluye un nmero de secuencia de k-bits en la cabecera Permite una ventana de hasta N paquetes consecutivos sin reconocer (ACKs)
ACK(n): se van haciendo confirmaciones (ACKs) acumulativas de todos los paquetes hasta el nmero de secuencia n Pudiera ver ACKs duplicados (ver receptor) Utiliza un temporizador por cada paquete timeout(n): se retransmite el paquete n y todos los paquetes con Capa de transporte 3-48 nmero de secuencia superior en la ventana.
GBN: extensin del diagrama de estados del emisor

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) timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) udt_send(sndpkt[nextseqnum-1])
base=1 nextseqnum=1
Espera
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer
Capa de transporte
3-49
GBN: extensin del diagrama de estados del receptor

default udt_send(sndpkt)
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)
espera
ACKs: siempre se enva ACK para aquellos paquetes que fueron recibidos correctamente con nmero de secuencia ms alto (ms reciente en orden)
Podra general ACKs duplicados Se necesita slo recordar el nmero de secuencia esperado (expectedseqnum)
Paquetes fuera de orden:
Se descartan (no tiene bufer el receptor) Se retransmite ACK al paqute con nmero de secuencia mayor
GBN en accin
emisior receptor
Tamao de ventana = 4
Ver applet
SR: Repeticin selectiva

El receptor da reconocimiento de los paquetes de manera selectiva
Almacena en un buffer los paquetes, segn lo necesite, para un eventual envo en orden a la capa superior
El emisor slo retransmite paquetes para los cuales no recibi ACK

El emisor maneja un temporizador por cada paquete no confirmado (no ACK)
La ventana del emisor cuenta con:

N nmeros de secuencia consecutivos Los nmeros de secuencia de paquetes de envo se limita a los paquetes no confirmados
SR: Ventanas del emisor y receptor
(a) Vista del emisor de los nmeros de secuencia
(b) Vista del receptor de los nmeros de secuencia

SR:Selective repeat
Evento: Datos de capa superior
Si el prox nmero de secuencia est disponible en la ventana, enviar paquete Reenva paquete n, reinicia temporizador
emisor
Evento: timeout(n)
Evento: recepcin de un ACK de un paquete n que se encuentre dentro de [sendbase,sendbase+N]:
Marcar el paquete n como recibido Si n es el num secuencia ms pequeo de los paquetes sin confirmar, avanzar la base de la ventana al prximo nmero de secuencia sin confirmar.
Si el paquete n est en [rcvbase, rcvbase+N-1] Enva ACK(n) Si viene fuera de orden: usar buffer Si viene en orden: emitirlo a la capa superior (tambin emitir los que estn en el bufer, en orden), avanzar la ventana al prximo paquete an no recibido Si el paquete esta en [rcvbaseN,rcvbase-1] Confirmar ACK(n) De lo contrario: ignorar
receptor
Capa de transporte
3-54
Selective repeat en accin
Capa de transporte
3-55
SR: dilema
Ejemplo:
Num seqs: 0, 1, 2, 3 Tamao ventana=3 El receptor no detecta la diferencia entre los dos escenarios! Incorrectamente se pueden pasar datos duplicados creyendo que son nuevos en (a) Q: qu relacin debiera de
haber entre el tamao de num secuencia y el tamao de la ventana?
Capa de transporte
3-56
Temas a cubrir

TCP: Panorama
Punto-a-punto: Un emisor, un receptor fiable, ordenamiento por bytes: sin lmites de mensajes pipelined: El esquema de control de congestin y flujo en TCP inicializan la ventana
RFCs: 793, 1122, 1323, 2018, 2581 Datos en full duplex:

Flujo de datos bidireccional en la misma conexin MSS: maximum segment size
Orientado a conexin:
intercambio de mensajes de control (handshaking ) que inician el estado del emisor y el receptor antes de intercambiar datos.
cuenta con buffers para envo y recepcin
Flujo controlado:
socket door application writes data TCP send buffer
segment
application reads data TCP receive buffer
socket door
El emisor no saturar al receptor

Estructura del segmento TCP

32 bits URG: urgent data (en general no usado) ACK: ACK # vlido PSH: push data now (en general no usado)
Establecimiento de la conexin
source port #
dest port #
sequence number
head not UA P R S F len used
Se cuenta por bytes de datos (no segmentos!)
acknowledgement number
Receive window Urg data pnter checksum
# bytes El receptor estar dispuesto a aceptar
RST, SYN, FIN:
opciones (long variable) Datos de la aplicacin (long variable)
(setup, terminar) Internet checksum (como en UDP)
Capa de transporte
3-59
TCP seq. #s and ACKs

Seq. #s: El nmero del segmento refiere al primer byte del segmento de datos ACKs: Refiere al # del siguiente byte esperado por el receptor Puede haber ACKs acumulativos P: Cmo manejar el receptor los segmentos en desorden? R: La especificacin del TCP no lo dice, se lo deja a sus implementadores
Host A
Un usuario Escribe la letra C
Seq=4 2 , A CK =79, d a
Host B
ta = C
ta = 3, da CK=4 79, A Seq=
El receptor enva ACK y emite un C como eco
Se confirma la recepcin de la C con un eco
Seq=4 3
, A CK = 80
Escenario simple del Telnet

Capa de transporte
tiempo
3-60
TCP: RTT y Timeout

P: Con qu valor iniciaremos el timeout en TCP?
Preferible que sea mayor de su RTT
PERO: el RTT vara
P: Cmo estimar el RTT?

RTTmuestra: tiempo medido desde la transmisin del segmento hasta la recepcin de su ACK Ignora retransmisiones Debido que RTTmuestra variar, debemos suavizarlo Obtener promedio de medidas recientes, no utilizar slo una
Muy cortos: ocasionan timeouts prematuros Retransmisiones innecesarias Muy largo: ocasionan una reaccin lenta en la prdida de paquetes
Capa de transporte
3-61
TCP: RTT y Timeout

RTTEstimado = (1- )*RTTEstimado + *RTTmuestra Utilizamos la media ponderada de desplazamiento exponencial. (EWMA: Exponential Weighted Moving Average). Esta media ponderada da ms peso a las muestras recientes que a las antiguas. El peso de las RTTmuestras dadas decaen a una velocidad exponencial segn se actualizan. Valor recomendado para = 0.125 [RFC2988]
Capa de transporte
3-62
Ejemplo de estimaciones de RTT:

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
300
RTT (milliseconds)
250
200
150
100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) SampleRTT Estimated RTT
Capa de transporte
3-63
TCP: RTT y Timeout

Inicializando el Timeout
Calculado como el RTTestimado ms un margen de seguridad
Mayor variacin en el RTTestimado -> mayor margen de seguridad
Calculamos cunto se desva el RTTmuestra del RTTestimado: DesvRTT = (1-)*DesvRTT + *|RTTmuestra-RTTEstimado| (tpicamente tenemos, = 0.25) [RFC2988]
Entonces podemos inicializar el intervalo de timeouts:
TimeoutInterval = RTTestimado + 4*DesvRTT

Temas a cubrir

TCP: Trasnferencia fiable de datos

TCP crea el servicio de tdf sobre el servicio no fiable de IP Utiliza segmentos con Pipelining ACKs acumulativos TCP utiliza un nico temporizador de retransmisin Las retransmisiones son activadas por:
Eventos timeout ACKs duplicados
Inicialmente describimos un emisor TCP simplificado:

Ignora ACKs duplicados Ignora control de flujo, ignora control de congestin Utiliza slo tiempo limite de espera para recuperarse de prdidas
Capa de transporte
3-66
TCP: eventos del emisor

Recepcin de datos desde la aplic:
Crea un segmento asignandole un # de secuencia El # de secuencia corresponde al nmero del primer byte en el segmento Inicia temporizador si an no est corriendo (no olvidar el uso del temporizador para segmentos no reconocidos) Intervalo de expiracin: TimeOutInterval timeout: Se retransmite segmento que causo el timeout Reinicia temporizador Recepcin de Ack: Si tenemos segmentos no reconocidos previos a ese ACK
Reconoce la recepcin de bytes con nmeros anteriores a ese. Inicia temporizador si an existen segmentos no reconocidos.
Capa de transporte
3-67
NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */
TCP: emisor
(simplificado)
Comentarios: SendBase-1: refiere al
ltimo byte reconocido acumulativamente
Capa de transporte
3-68
TCP: escenarios de retransmisin

Host A
Seq=9 2
Host B
, 8 byt es da
Host A
Seq=9 2
Host B
, 8 byt es da
Seq=92 timeout
ta
Seq= 1
timeout
loss
Seq=9 2 , 8 byt es da ta
=100 A CK
00, 2 0 byt
ta
ta
es da
0 10 K= 120 AC ACK=
Seq=92 timeout
100 C K=
Sendbase = 100 SendBase = 120
Seq=9 2
, 8 byt es da
ta
AC
2 K=1
SendBase = 100
SendBase = 120
time Escenario: prdida de ACK
time
Timeout prematuro
TCP: escenarios de retransmisin (cont..)

Host A
Seq=9 2
Host B
, 8 byt es da
ta
timeout
Seq=1 0
loss
AC K =120
=100 A CK 0, 20 bytes data
SendBase = 120
time Escenario: ACK acumulativos

TCP: generacin de ACK

Evento
Llegada de un segmento en orden con # de secuencia esperado. Todos los datos hasta el # de secuencia esperado ya reconocidos. Llegada de un segmento en orden con # de secuencia esperado. Se est esperando el ACK de uno de los otros segmentos recibidos en orden. Llegada de un segmento en desorden con un nmero de secuencia mayor que el esperado. Agujero detectado. Llegada de un segmento que completa parcialmente el agujero en los datos recibidos
[RFC 1122, RFC 2581]
Accin en el receptor
Retrasar ACK. Esperar hasta 500ms la llegada de algn otro segmento en orden. Si el siguiente segmento en orden no llega durante este intervalo, enviar ACK. Enviar inmediatamente un nico ACK acumulado, reconociendo ambos segmentos en orden. Enviar inmediatamente un ACK duplicado, indicando el nmero de secuencia del siguiente byte esperado (el lmite inferior del agujero). Enviar inmediatamente un ACK, si ese segmento arranca en el extremo inferior del agujero Capa de transporte 3-71
Retransmisin rpida
Motivada por que algunos periodos de espera son relativamente largos: Si el emisor recibe 3 ACKs RFC[2581] para los mismos datos, supondr que el segmento despus del dato confirmado se perdi. :
Detectar segmentos perdidos va ACKs duplicados.
Forzando a largas esperas antes de reenviar el paquete perdido
La retransmisin rpida: Reenva el segmento antes de que el temporizador expire.
El emisor enva a menudo muchos segmentos de extremo a extremo Si algn segmento se pierde, probablemente habr muchos ACKs duplicados.
Algoritmo para retransmisin rpida:

event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } Un ACK duplicado para Un segmento que ya ha sido reconocido
Retransmisin rpida
Capa de transporte
3-73
Temas a cubrir

TCP: Control de flujo

Control de flujo
El lado receptor cuenta con un buffer:
Se trata de que el emisor no sature el buffer del receptor
La aplicacin puede ser lenta para leer el buffer
Servicio de acoplado de velocidades: acoplar la velocidad del emisor con la tasa de consumo de la aplicacin
Capa de transporte
3-75
TCP Control de flujo: funcionamiento

El receptor comunica su espacio disponible mediante incluir el valor de RcvWindow en los segmentos El emisor limita los nuevos datos a RcvWindow
Esto garantiza que el buffer del receptor no se satura.
(Suponemos que el receptor descarta segmentos fuera de orden) Espacio en el buffer

= RcvWindow = RcvBuffer-[LastByteRcvd LastByteRead]
Capa de transporte
3-76
Temas a cubrir

TCP: Gestin de la conexin

Retomamos: el emisor y receptor en TCP
establecen una conexin antes de emitir segmentos Se inicializan las siguientes variables:: # secuencia buffers, informacin de control de flujo (e.g. RcvWindow) cliente: inicia la conexin
Saludo en tres vas (handshaking):

Paso 1: el cliente enva un segmento TCP SYN al servidor Especifica el # secuencia inicial Sin datos Paso 2: el servidor recibe el SYN, y responde con un segmento SYNACK El servidor asigna buffers Especifica el # secuencia inicial Paso 3: el cliente recibe el SYNACK, responde con un segmento ACK, el cual puede contener datos
Socket clientSocket = new Socket("hostname","port number");
cliente
servidor: contactado por el

Socket connectionSocket = welcomeSocket.accept();
TCP: Gestin de la conexin (cont.)

Cerrar una conexin:
El cliente cierra el socket: clientSocket.close();
close
client
FIN
server
Paso 1: cliente enva un
AC K FIN
segmento de control TCP FIN al servidor

timed wait
close
Paso 2: el servidor recibe el
A CK
FIN, responde con un ACK. Cierra la conexin, enva FIN.
closed
Capa de transporte
3-79

Paso 3: el client recibe un
FIN, responde con ACK. Entra a una esperas temporal- responder con un ACK a los mensajes de FIN recibidos
closing
client
FIN
server
AC K FIN
closing
ACK. La conexin se cierra.
Espera temporal
Paso 4: el servidor, recibe el
A CK
closed
closed
La espera_temporal permite que el cliente TCP reenve el reconocimiento final en caso de que el ACK se pierda
Capa de transporte
3-80
Ciclo de vida de un servidor TCP
Ciclo de vida de un cliente TCP
Capa de transporte
3-81
Temas a cubrir

Principios de control de congestin

Congestin:
De manera informal: muchas fuentes emitiendo muchos datos a la red muy rpidamente Es diferente del control de flujo Forma de manifestarse: Paquetes perdidos(saturacin del buffer en los routers) Largos retrasos(crecimiento de colas en los buffers de los routers) Es uno de los principales problemas en redes.
Causas/costos de la congestin: escenario 1

Dos emisores, dos receptores Un router, buffer infinito Sin retransmisin
Host A
in : original data
out
Host B
buffer del enlace de salida, ilimitado y compartido
Grandes retrasos al estar congestionado C/2 Mxima tasa de transferencia posible Se experimentas grandes retardos en las colas segn la tasa de llegada de paquetes se acerca a la capacidad del enlace
C:capacidad del canal
Capa de transporte
3-84

Un router, buffer finito Asumimos retransmisin por parte del emisor ante prdida de paquetes.
Host A
in : original data 'in : original data, plus retransmitted data
out
Host B
Buffers finitos
Capa de transporte
3-85
In
in Caso a: Consideramos que el emisor sabe cundo se llena el buffer del router = por lo tanto no hay prdida in
Caso b: slo retransmite cuando realmente se perdi un paquete Caso c: retransmite paquetes repetidos debido a expiracin de timeout
R/2 R/2 R/2
Buffers finitos (al llenarse se desechan los paquetes) Hay retransmisin, datos originales = datos originales + retransmitidos =
> out
in
out
out
out
out
R/3
R/4
in
R/2
costos de congestin:
in
R/2
in
R/2
b.
c.
Ms trabajo (retransmisin) La tasa a la cual los datos son entregados a la aplicacin baja debido tambin a retransmisiones innecesarias que no eran prdidas originalmente, pero debido al retardo en el buffer del router para emitirlos el timout lleg en el emisor Capa de transporte 3-86

Cuatro emisores Caminos multisalto timeout/retransmicin
P: qu pasa cuando in y in incrementan?

in : original data 'in : original data, + retransmitted data out
Host D
Host A
Buffer finito
Host B Host C
Capa de transporte
3-87

H o s t A H o s t B
o u t
Poco trfico
mucho trfico
Otro costo de congestin: Cuando se desechan paquetes, cualquier capacidad de tranmisin utilizada por esos paquetes ha sido un desperdicio.
Con trfico muy alto compitiendo por los routers en comn la productividad de extremo a extremo tiende a caer
Capa de transporte
3-88
Aproximaciones al control de congestin

Dos grandes enfoques: Control de congestin entre extremos:
No hay retroalimentacin explcita por parte de la capa de red Congestin inferida por los sistemas finales observando las prdidas y retardos. Aproximacin llevada por TCP Control de la congestin asistido por la red:
Los routers proveen retroalimentacin a los sistemas finales Podra ser un slo bit indicando congestin (SNA, DECbit, TCP/IP ECN, ATM) Informar al emisor de manera explcita la tasa de bits que puede consumir el router (e.g. uso de ABR)
Temas a cubrir

TCP: Control de congestin

Control extremo a extremo (sin Cmo percibe un emisor la congestin? asistencia de la capa de red) Evento prdida = timeout o El emisor limita la transmisin: 3 ACKs duplicados
LastByteSent-LastByteAcked CongWin
En general,
rate = CongWin Bytes/sec RTT
El emisor reduce la tasa (CongWin) despus del evento de prdida (congwin=congwin/2) Tres mecanismos:
El CongWin es dinmico, en funcin de la congestin de red percibida.
AIMD (additive increase, multiplicative decrease) slow start Conservador despus de eventos de timeout (tamao de Congwin=1MSS)
TCP: AIMD
Decremento multiplicativo: disminuye a la mitad la CongWin despus de un evento de prdida
congestion window 24 Kbytes
Incremento aditivo: incrementa la CongWin por 1 MSS cada RTT en ausencia de eventos de prdida: avanza con cautela
16 Kbytes
8 Kbytes
time
Control de congestin: AIMD

TCP: Arranque lento(Slow Start)

Al inicio de la conexin empezamos con una CongWin = 1 MSS As que al inicio de la conexin, se va incrementando la tasa de manera exponencial hasta encontrar el primer evento de prdida.
Ya que el ancho de banda disponible pudiera ser mucho mayor a MSS/RTT

Es deseable saltar de manera rpida a una tasa ms conveniente.
Ejemplo: MSS = 500 bytes y RTT = 200 mseg Tasa inicial 20 kbps
Capa de transporte
3-93
TCP: Arranque lento(cont..)

Al inicio de la conexin la tasa de transmisin se va incrementando de manera exponencial hasta encontrar la primera prdida:
Duplica el CongWin cada RTT Lo hace mediante incrementar el CongWin por cada ACK recibido
Host A Host B
un segme n to
RTT
dos segm entos
cuatro seg
mentos
En resumen: la tasa inicial es lenta pero tiene un salto rpido (exponencial)
time
Capa de transporte
3-94
Mejoras
Filosofa:
Despus de 3 ACKs duplicados: CongWin se va a la mitad posteriormente la ventana crece linealmente PERO despus de alcanzado el timeout: CongWin se va a 1 MSS; posteriormente la ventan crece exponencialmente Hasta llegar a un umbral, donde seguir creciendo linealmente
3 ACKs duplicados indican que la red an puede ir haciendo algo limitado timeout antes de 3 ACKs duplicados es algo ms alarmante
Capa de transporte
3-95
Mejoras (cont..)
Ventana de congestin (CongWin)
P: Cundo debiera el crecimiento exponencial pasar a lineal? R: Cuando la CongWin llegue a 1/2 del valor que tena justo antes del timeout. Implementacin:
Ciclo de transmisin
Uso de variable: Threshold En un evento de prdida, la variable Threshold es iniciada a 1/2 del tamao que CongWin tena justo antes del evento de prdida.
Resumen: Control de Congestion en TCP

Cuando la CongWin est debajo de Treshold, la ventana del emisor en fase slow-start, crece exponencialmente. Cuando la CongWin est sobre Threshold, la ventana del emisor en fase evasin-de-congestin, la ventana crece linealmente. Cuando ocurre un ACK duplicado 3 veces, la variable Threshold toma el valor de CongWin/2 y CongWin el de Threshold. Cuando ocurre un timeout, la variable Threshold toma el valor de CongWin/2 y CongWin es iniciada a 1 MSS.
Emisor TCP: control de congestin

Estado Slow Start (SS) Evento
Recepcin de ACK para segmento previo no confirmado Recepcin de ACK para segmento previo no confirmado Evento de prdida detectado con un triple ACK Timeout
Accin del emisor CongWin = CongWin + MSS, If (CongWin > Threshold) set state to Congestion Avoidance CongWin = CongWin+MSS * (MSS/CongWin)
Comentario
Se duplica CongWin cada RTT
Congestion avoindance (CA) SS o CA
Incremento aditivo: se incrementa CongWin en 1 MSS cada RTT
Threshold = CongWin/2, CongWin = Threshold, Inicio estado Congestion Avoidance Threshold = CongWin/2, CongWin = 1 MSS, Inicio estado a Slow Start Incrementamos el contador de ACK duplicados para el segmento que est siendo reconocido
Recuperacin rpida, implementando decremento multiplicativo. CongWin will not drop below 1 MSS. Entro a slow start
SS o CA
SS o CA
ACK duplicado
CongWin y Threshold no cambio
Capa de transporte
3-98
TCP: tasa de transferencia (throughput)

Analizamos la capacidad de transferencia del TCP tomada como una funcin del tamao de la ventana y el RTT
Modo simplificado: ignoramos slow start
Sea W el tamao de la ventana cuando ocurre una prdida. Cuando la ventana es de tamao W, la capacidad de transferencia es W/RTT Justo despus de la prdida, la ventana cae a W/2, y la capacidad de transferencia a (W/RTT). La capacidad promedio que se puede obtener bajo estas asunciones se extrae tomando los valores de transferencia que tena antes y despus de la falla:
(W/RTT)+(W/2RTT) ------------------------------ = 0.75W/RTT 2
TCP: Qu tan justo es?

Referimos a TCP como justo si: en K sesiones TCP que comparten algn enlace en comn (cuello de botella) con ancho de banda de R, cada sesin obtiene una tasa promedio de R/K
TCP conexin 1
TCP conexin 2
Router Cuello de botella capacidad R
Porqu es justo TCP?

En dos sesiones compitiendo:
El incremento aditivo da un avance en 1, en tanto el troughtput va creciendo El decremento multiplicativo desciende el trhoughput proporcionalmente R
Conexin 2 throughput
Mismo ancho de banda compartido
prdida: decrese la ventana en un factor de 2 Evacin de la congestin: incremento aditivo prdida: decrese la ventana en un factor de 2 Evacin de la congestin: incremento aditivo
Conexin 1 throughput
Justicia en TCP
La justicia y el UDP Las aplicaciones multimedia a menudo no usan TCP
No desean que su tasa de trsnferencia sea regulada por el control de congestin
Por ello mejor usan UDP:
Lnea de investigacin posible: bsqueda de un TCP amigable
Transmiten audio/video en tasas constante, tolerando prdida de paquetes
Qu tan justo es el TCP cuando trabaja en aplicaciones que invocan proceso en paralelo? Nada evita que las aplicaciones abran conexiones en paralelo entre 2 hosts. Los navegadores Web lo hacen. ejemplo: enlace con tasa R soportando 9 conexiones;
Entra una nueva aplicacin y pide una conexin TCP, as que obtiene una tasa de R/10 La nueva aplicacin solicita 11 conexiones TCP en paralelo, esa sla aplicacin acaparar R/2 !
Modelado del retardo en TCP

P: cuando le toma a un cliente recibir un objeto de un servidor Web despus de hacerle una peticin? Si ignoramos la congestin, bsicamente el retardo est influenciado por:
Establecimiento de la conexin El retardo en la transmisin del objeto (datos) slow start
Asunciones:
Asumimos un enlace entre el cliente y el servidor con tasa R S: MSS (bits) O: tamao del objeto (bits) Sin retransmisin (sin prdida, sin paquetes corrompidos)
Tamao de la ventana:
Asumimos primero: ventana de congestin esttica, W segmentos Despus analizamos con ventana dinmica, modelando slow start
Ventana de congestin esttica (1)

Primer caso:
WS/R > RTT + S/R: El ACK del primer segmento llega antes de que todos los datos de la ventana sean enviados
retardo = 2RTT + O/R
W=4
Ventana de congestin esttica (1)

Segundo caso:
WS/R < RTT + S/R: espera por el ACK despus de haber enviado el contenido de la ventana.
K= O/WS, # ventanas que abarca el Objeto Tiempo de parada del servidor entre cada envo de ventana= RTT (W 1)S/R
retardo = 2RTT + O/R + (K-1)[S/R + RTT - WS/R]
W=2
Modelado del retardo en TCP: Slow Start (1)

Suponemos ahora que la ventana crece acorde al slow start
Sea K el nmero de ventanas que abarcan al objeto. Se puede expresar K en funcin de O/S (# de segmentos que abarcan al objeto):
K = min{ k: 20 + 21+ . . . + 2k-1 O/S } = min{ k: 2k-1 O/S } = min{ k: k log2(O/S +1)} = log2(O/S +1) Desde que el servidor comienza a transmitir la k-sima ventana hasta que recibe un reconocimiento para el primer segmento de la ventana trascurren: S/R + RTT segs. El tiempo transmitido de la k-sima ventana es de (S/R)2k-1. El tiempo de parada sera la Diferencia entre : [S/R + RRT - 2k-1 (S/R)]+
As la latencia tiene 3 componentes: 2RTT para establecer la conexin, O/R tiempo para transmitir el objeto y la suma de todos los tiempos de Parada: 2RTT + O/R + [ S/R + RTT - 2k-1 (S/R)]+
k=1 k-1
[x]+ = max(x,0)

Sea Q el nmero de veces que debemos de parar si el objeto contuviese un nmero infinito de segmentos. A partir de que el tiempo de transferencia de segmentos sea igual al RTT ya no se tendrn paros por parte del servidor. As tenemos que: RTT 2Q-1(S/R) = 0 2Q = RTT/(S/R) + 1 Q = log2(1 + RTT/(S/R)) + 1
El nmero real de veces que TCP parara en el servidor sera_
P = min{Q, K 1}
As tenemos que:
Re tardo = 2 RTT +
O S S + P RTT + (2 P 1) R R R

Componentes del retardo: 2 RTT para
initiate TCP connection
establecimiento de la conexin e inicio de peticin O/R para transmitir el objeto completo tiempo que el servidor para debido a que
WS/R < RTT + S/R
request object
first window = S/R second window = 2S/R
RTT
third window = 4S/R
Paros en el servidor: P = min{K-1,Q} veces

ejemplo: O/S = 15 segmentos K = 4 ventanas Q=2 P = min{K-1,Q} = 2
fourth window = 8S/R
object delivered time at client time at server
complete transmission
Modelado del retardo en TCP (3)

S + RTT = tiempo desde que inicia el servidor el envo del segmento R hasta que recibe el reconocimiento
2 k 1 S = tiempo en transmitir la k - sima ventana R
+
initiate TCP connection
request object
first window = S/R second window = 2S/R
RTT
S k 1 S = tiempo de paro despus de la k - sima ventana R + RTT 2 R
third window = 4S/R
retardo =
P O + 2 RTT + idleTime p R p =1
fourth window = 8S/R
P O S S = + 2 RTT + [ + RTT 2 k 1 ] R R k =1 R O S S = + 2 RTT + P[ RTT + ] (2 P 1) R R R
object delivered time at client time at server
complete transmission
Ejemplo
Tamao del segmento (S) = 536 RTT = 100miliseg Tamao del objeto (O) = 100KB Ventanas que abarca (K) = 8 Latencia mnima: O/R + 2RTT 28,8 seg 8,2 seg 1 seg 0,28 seg Latencia con arranque lento 28,9 seg 8,4 seg 1,5 seg 0,98 seg
R 28kbps 100kbps 1 Mbps 10 Mbps
O/R 28,6 seg 8 seg 800 mseg 80 mseg
P 1 2 5 7
Ejemplo
Tamao del segmento (S) = 536 RTT = 100miliseg Tamao del objeto (O) = 5 KB Ventanas que abarca (K) = 4 Latencia mnima: O/R + 2RTT 1,63 seg 0,6 seg 0,24 seg 0,20 seg Latencia con arranque lento 1,73 seg 0,76 seg 0,52 seg 0,50 seg
R 28kbps 100kbps 1 Mbps 10 Mbps
O/R 1,43 seg 0.4 seg 40 mseg 4 mseg
P 1 2 3 3
Ejemplo
Tamao del segmento (S) = 536 RTT = 1 seg Tamao del objeto (O) = 5 KB Ventanas que abarca (K) = 4 R 28kbps 100kbps 1 Mbps 10 Mbps O/R 1,43 seg 0.4 seg 40 mseg 4 mseg P 3 3 3 3 Latencia mnima: O/R + 2RTT 3,4 seg 2,4 seg 2,0 seg 2,0 seg Latencia con arranque lento 5,8 seg 5,2 seg 5,0 seg 5,0 seg
El arranque lento puede incrementar significativamente la latencia cuando el tamao del objeto es relativamente pequeo y el RTT es relativamente grande. Cosa que ocurre con mucha frecuencia en la Web. Capa de transporte 3-112
Modelando HTTP
Asumimos que una pgina Web consiste de: 1 pgina HTML base (de tamao O bits) M imgenes (cada una de tamao O bits) HTTP No-persistente: M+1 conexiones TCP en serie
HTTP persistente: 2 RTT para solicitar y empezar a recibir el archivo HTML base 1 RTT para solicitar las M imgenes HTTP Persistente con X conexiones paralelas Supongamos M/X como entero. 1 conexin TCP para el archivo base M/X conjuntos de conexiones paralelas por imagen
Tiempo de respuesta = (M+1)O/R + (M+1)2RTT + suma de tiempos de paro
Tiempo de respuesta = (M+1)O/R + 3RTT + suma de tiempos de paro
Tiempo de respuesta = (M+1)O/R + (M/X + 1)2RTT + suma de tiempos de paro

Tiempo de respuesta en HTTP (en segundos)

RTT = 100 mseg, O = 5 Kbytes, M=10 and X=5
20 18 16 14 12 10 8 6 4 2 0
no-persistente persistente no-persist paralelo 28 Kbps 100 1 Mbps 10 Kbps Mbps
Donde se presentan anchos de banda bajos, el tiempo de respuesta y de conexin es dominado por el tiempo de transmisin Las conexiones persistentes tienen una mejora mnima usando conexiones paralelas
Tiempo de respuesta en HTTP (en segundos) RTT =1 seg, O = 5 Kbytes, M=10 and X=5
70 60 50 40 30 20 10 0 no-persistente persistente no-persist paralela
28 100 1 Mbps 10 Kbps Kbps Mbps Para RTTs grandes, el tiempo de respuesta es dominado por los retardos en establecimiento y slow start de TCP. Las conexiones persistentes ofrecen ahora una importante mejora: especialmente en redes con alto retraso y ancho de banda
Resumn
Principios detrs de los servicios de transporte: multiplexing, demultiplexing Transferencia de datos fiable Control de flujo Control de congestin Formas de implementarse en internet: UDP TCP
A continuacin: Dejamos el entorno de la red (capas de aplicacin y transporte) Continuamos con el nucleo de la red

Cap3 Transporte

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Cap3 Transporte

Загружено:

Авторское право:

Доступные форматы

Capa de Transporte

Computer Networking: A Top Down Approach Featuring the Internet,

Aprender los protocolos de transporte en Internet:

3.6 Principios de control de congestin 3.7 control de congestin en TCP

Funciones de la Capa de Transporte

Comunicacin en la Capa de Transporte

Capa de transporte Capa de red Capa de enlace de datos

Capa de transporte Capa de red Capa de enlace de datos

Relacin con las Capas Vecinas

TPDU Protocolo de transporte

Direccin de red (NSAP)

Servicios Proporcionados a las Capas Superiores

Servicios de transporte y protocolos

network data link physical

network data link physical

Primitivas de la Capa de Transporte

Capa de Transporte vs. Red

Protocolos de transporte en Internet

network data link physical

network data link physical network data link physical

No fiable, sin mantener el orden en los envos: UDP

network data link physical

3.6 Principios de control de congestin 3.7 control de congestin en TCP

Pasa los segmentos recibidos al socket indicado

aplicacin transporte red enlace fsico

Cmo funciona el demultiplexado?

Otros campos de la cabecera

Datos de la aplicacin (mensaje)

Demultiplexado en servicios sin conexin

Cuando un host recibe un segmento UDP:

El socket UDP se identifica por:

Demultiplexado en servicio sin conexin

SP: 6428 DP: 9157 SP: 9157 DP: 6428

SP: 6428 DP: 5775 SP: 5775 DP: 6428

Demultiplexado en servicio con conexin

Demultiplexado en servicio con conexin

SP: 9157 DP: 80 S-IP: A D-IP:C

Demux en servicio con conexin: utilizando Threadeds

3.6 Principios de control de congestin 3.7 control de congestin en TCP

UDP: User Datagram Protocol [RFC 768]

Porqu usar UDP?

sin conexin refiere a:

Otros usos de UDP

Datos de la aplicacin (mensaje)

Formato del segmento UDP

3.6 Principios de control de congestin 3.7 control de congestin en TCP

Principios sobre transferencia de datos fiable

Transferencia de datos fiable (tdf): introduccin

rdt_rcv(): llamado cuando se reciben paquetes del lado del receptor

transferencia fiable sobre un canal fiable

Partimos de que el canal a utilizar es totalmente fiable

Diagramas de transicin para el emisor y receptor:

Espera por llamada de arriba

rdt_rcv(packet) extract (packet,data) deliver_data(data)

tdf2.0: usando canal con errores

Pregunta: Cmo nos recuperamos del error? :

Usar checksum para detectar errores

Usando acknowledgements (ACKs): el receptor informa al

tdf2.0: Diagrama de estados

Espera por llamada de arriba

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Espera por llamada de abajo

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)