2 - capaDeTransporte

LA CAPA DE TRANSPORTE
Capa de transporte
3-1
La capa de transporte
OBJETIVOS: Comprender los principios detras de los servicios de la capa de transporte:

Aprender sobre los
protocolos de transporte en Internet:

multiplexado/demultiplex ado Transferencia de datos fiable Control de flujo Control de congestionamiento
UDP: transporte no orientado a la conexin TCP: transporte orientado a la conexin Control de congestionamiento TCP
Capa de transporte
3-2
Servicios de la capa de transporte
Capa de transporte
3-3
Servicios y protocolos de transporte

Proporcionar comunicacin lgica
entre procesos de aplicaciones ejecutndose en hosts diferentes Los protocolos de transporte se ejecutan en sistemas finales Lado emisor: dividir los mensajes de las aplicaciones en segmentos, pasarlos a la capa de red Lado receptor: reensamblar segmentos en mensajes, pasar a la capa de aplicacin Ms de un protocolo de transporte disponible para las aplicaciones Internet: TCP , UDP y SCTP
application transport network data link physical
Capa de transporte
3-4
Capa de transporte vs. capa de red

Capa de red:
comunicacin lgica entre hosts

Capa de transporte:
Comunicacin lgica entre procesos
Opera sobre y mejora los servicios de la capa de red
Analoga con una familia: 12 nios envian cartas a otros 12 nios Procesos = nios Mensajes de aplicacion = cartas en sobres Hosts = casas Protocolo de transporte = Ana y Bill Protocolo de la capa de red = servicio postal
Capa de transporte 3-5
Protocolos de la capa de transporte de Internet

Entrega fiable y ordenada:
TCP

Control de congestionamiento Control de flujo Configuracin de conexin
network data link physical
Entrega no fiable y fuera de
orden: UDP
network data link physicalnetwork network data link physical
data link physical application transport network data link physical
Una extension sin mas del protocolo IP de mejor esfuerzo
Servicios no disponibles: Garantas de retardo Garantas de ancho de banda
Capa de transporte
3-6
Multiplexado y demultiplexado
Capa de transporte
3-7
Multiplexado/demultiplexado
Demultiplexado en el host receptor: Entregando los segmentos recibidos al socket correcto
= socket aplicacin transporte red enlace fisica P3 = proceso P1 P1 aplicacin transporte red enlace fisica P2 P4 aplicacin transporte
Multiplexado en el host emisor: Reuniendo datos de multiples sockets, etiquetndo los datos con un encabezado (usado luego para el demultiplexado)
red
enlace fisica
host 1
host 2
host 3
Como funciona el demultiplexado

Un host recibe datagramas IP
Cada datagrama tiene una direccin IP de origen y una direcin IP de destino Cada datagrama transporta 1 segmento de la capa de transporte Cada segmento tiene un nmero de puerto de origen y de destino El host usa las direcciones IP y los nmeros de puerto para dirigir los segmentos a los sockets apropiados
32 bits
# puerto origen # puerto dest.
Otros campos de encabezado Datos de aplicacin (mensaje)
Formato de segmentoTCP/UDP
Demultiplexado no orientado a la conexin

Crear sockets con
Cuando un host recibe un
nmeros de puerto:
DatagramSocket mySocket1 = new DatagramSocket(12534); DatagramSocket mySocket2 = new DatagramSocket(12535);
segmento UDP:

Verifica el nmero de puerto destino en el segmento Dirige el segmento UDP al socket con dicho nmero de puerto
Un socket UDP se
Datagramas IP con direcciones
identifica por la tupla : (direccin IP destino, nmero de

puerto destino)
IP de origen y/o nmeros de puerto origen diferentes se direccionan al mismo puerto, si tienen la direccion IP y puerto destino iguales
Demultiplexado no orientado a la conexin (cont)

DatagramSocket serverSocket = new DatagramSocket(6428);
P2 P3 P1 P1
SP: 6428
DP: 9157 SP: 9157 IP de Cliente: A DP: 6428
SP: 6428
DP: 5775 SP: 5775
IP de Servidor: C
DP: 6428
IP de Cliente:B
SP proporciona la direccin de retorno

Demultiplexado orientado a la conexin

Un socket TCP se El host servidor puede
identifica por la tupla:

Direccin IP de origen Nmero de puerto origen Direccin IP de destino Nmero de puerto destino
admitir muchos sockets TCP simultneos:
Cada socket se identifica mediante su propia tupla
Los servidores Web tiene
El host receptor usa los
4 valores para dirigir el segmento al socket apropiado
diferentes sockets para cada conexin de cliente
HTTP no persistente tendr sockets diferentes para cada consulta
Demultiplexado orientado a la conexin(cont)

P1 P4 P5 P6 SP: 5775 DP: 80 P2 P1 P3
S-IP: B D-IP:C
SP: 9157 IP de Cliente: A DP: 80 S-IP: A D-IP:C IP de Servidor: C SP: 9157 DP: 80 S-IP: B D-IP:C IP de Cliente:B
Demultiplexado orientado a la conexin: Web Server multihilo

P1 P4 SP: 5775 DP: 80 P2 P1 P3
S-IP: B D-IP:C
SP: 9157 IP de Cliente: A DP: 80 S-IP: A D-IP:C IP de Servidor: C SP: 9157 DP: 80 S-IP: B D-IP:C IP de Cliente:B
Transporte no orientado a la conexin UDP
UDP: User Datagram Protocol [RFC 768]

Protocolo de transporte de
Internet sin adornos Servicio de mejor esfuerzo, los segmentos UDP pueden ser: Perdidos Entregados fuera de orden a las aplicaciones No orientado a la conexin: Sin handshaking entre el emisor y receptor UDP Cada segmento UDP se maneja independientemente de los dems
Porqu existe UDP?

No hay establecimiento de
conexin (lo que puede agregar retardo) Simple: sin estado de conexin en emisor o en receptor Encabezado de segmento pequeo Sin control de congestionamiento: UDP puede ir tan rpido como se desee
UDP
Comunmente utilizado para
Longitud, en bytes, de segmento UDP, incluyendo el encabezado
aplicaciones de difusin multimedia Tolerante a prdidas Sensible a la velocidad Otros usos para UDP DNS SNMP Transferencia fiable sobre UDP: agregar fiabilidad en la capa de aplicacin Recuperacin de errores especfica de cada aplicacin
32 bits
# puerto origen # puerto dest.
Longitud
checksum
Datos de aplicacin (mensaje)
Formato de segmento UDP

Checksum UDP
Objetivo: detectar errores (e.g., bits invertidos) en segmentos transmitidos Emisor:
Procesa el contenido de un
Receptor:
Calcula la suma de verificacin
del segmento recibido segmento como una secuencia de enteros de 16 Verifica si la suma calculada es bits igual al valor del campo checksum: checksum: suma (en complemento a 1) de los NO - error detectado contenidos del segmento YES no se detectaron El emisor coloca el valor de la errores. Pero an asi, suma de verificacin en el podria haber errores? campo UDP checksum Veremos.
Ejemplo de checksum Internet

Nota
Cuando se suma nmeros, un acarreo del bit ms significativo debe sumarse al resultado
Por ejemplo: sumar dos enteros de 16 bits
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
wraparound
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
sum 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
Principios de transferencia de datos fiable
Principios de trasferencia de datos fiable

Importante en las capas de aplicacin, transporte y enlace En la lista de los 10 tpicos ms importantes de redes!
Las caractersticas del canal no fiable determinarn la complejidad
del protocolo de transferencia de datos fiable (rdt)





Transferencia de datos fiable: comenzando

rdt_send(): llamado de arriba, (e.g., por una aplicacin). Pasa datos para entregar a la capa superior del receptor
deliver_data(): llamado por rdt para entregar datos a la capa superior
Lado emisor
Lado receptor
udt_send(): llamado por rdt, para transferir un paquete sobre un canal no fiable al receptor
rdt_rcv(): llamado cuando llega un paquete al lado receptor del canal

Transferencia de datos fiable: comenzando

Qu haremos? : Desarrollar incrementalmente los extremos emisor y receptor del protocolo de transferencia de datos fiable (rdt) Considerar solo la transferencia de datos unidireccional Pero la informacin de control fluir en ambas direcciones! Usar mquinas de estado finito (FSM) para especificar el emisor y el receptor
Evento que causa el cambio de estado Acciones tomadas al cambiar el estado estado: estando en este estado, el siguiente estado se determina univocamente por el siguiente evento
estado 1
evento
accin
estado 2
Capa de transporte
3-25
Rdt1.0: Transferencia fiable sobre un canal fiable

Canal subyascente perfectamente fiable No hay errores de bit No hay prdida de paquetes FSMs separados para emisor, receptor: Emisor envia datos al canal subyascente Receptor lee datos del canal subyascente
Espera llamada de arriba
rdt_send(data) packet = make_pkt(data) udt_send(packet)
Espera llamada de abajo
rdt_rcv(packet) extract (packet,data) deliver_data(data)
emisor
receptor
Rdt2.0: canal con errores de bit

Canal subyascente puede invertir los bits en un
paquete
checksum para detectar errores de bit
La pregunta: como recuperarse de errores: confirmacin (ACKs): el receptor explcitamente le dice al emisor que un paquete se recibio bien Confirmacin negativa (NAKs): el receptor explcitamente le dice al emisor que el paquete tuvo errores El emisor retransmite el paquete al recibir un NAK Nuevos mecanismos en rdt2.0 (sobre rdt1.0): Deteccin de errores Retroalimentacin del receptor: mensajes de control (ACK, NAK) del receptor al emisor
rdt2.0: Especificacin FSM

rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Espera Wait for llamada de ACK or udt_send(sndpkt) arriba NAK
receptor
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt) L
emisor
Espera llamada de abajo rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

rdt2.0: operacin sin errores

rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Espera Espera llamada de ACK o udt_send(sndpkt) arriba NAK

udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt) L

rdt2.0: Escenario con error

rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Espera Espera llamada de ACK o udt_send(sndpkt) arriba NAK

udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt2.0 tiene una falla fatal!

Qu ocurre si los ACK/NAK se corrompen? Manejar duplicados:
El emisor retransmite el
paquete atual si el ACK/NAK est daado El emisor no sabe que ocurri El emisor agrega un nmero de en el receptor! secuencia a cada paquete No puede retransmitir El receptor descarta (no simplemente: posible entrega hacia arriba) el duplicado paquete duplicado
Parada y espera (Stop and wait)

El emisor envia un paquete y espera la respuesta del receptor
rdt2.1: El emisor maneja ACK/NAKs daados

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

Espera llamada 1 de arriba
rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) udt_send(sndpkt)
rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt)
rdt2.1: el receptor maneja ACK/NAKs daados

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 0 de abajo Espera 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)
rdt2.1: Discusin
Emisor: #sec agregado al paquete Dos #sec (0,1) sern suficientes. Porqu? Debe verificar si el ACK/NAK recibido esta daado Dos veces mas estados
Receptor: Debe verificar si el paquete recibido es duplicado
El estado indica si el #sec esperado es 0 o 1
nota: el receptor no
Un estado debe recordar si el paquete actual tiene #sec 0 o 1
puede saber si su ltimo ACK/NAK fu recibido correctamente en el emisor

rdt2.2: Un protocolo libre de NAK

La misma funcionalidad que rdt2.1, usando solo ACKs En vez de un NAK, el receptor enva un ACK por el
ltimo paquete recibido OK
El receptor debe incluir explcitamente el #sec del paquete confirmado
Un ACK duplicado en el emisor resulta en la misma
accin que un NAK: se retransmite el paquete actual
rdt2.2: Fragmentos del emisor y receptor

rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || Wait for Wait for isACK(rcvpkt,1) ) ACK call 0 from 0 udt_send(sndpkt) above
sender FSM fragment
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)
Wait for 0 from below
receiver FSM fragment
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt)
rdt3.0: Canal con errores y prdida

Nueva presuncin: El canal subyascente puede tambin perder paquetes (de datos o ACKs)
Enfoque: el emisor espera por un tiempo razonable un ACK

Retransmite si no se recibe ningun
Suma de verificacin, #sec, ACKs y retransmisiones son de ayuda, pero no suficientes
ACK en ese tiempo Si el paquete (o ACK) solo se retras (no se perdi) : La retransmisin generar un duplicado, pero el uso de #sec resuelve este problema El receptor debe especificar #sec del paquete confirmado Requiere de un contador descendente
rdt3.0 emisor
rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer Wait for call 0from above Wait for ACK0 rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) rdt_rcv(rcvpkt)
L
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 Wait for ACK1 rdt_send(data)
timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) )
Wait for call 1 from above
rdt_rcv(rcvpkt)
sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer
rdt3.0 en accin
rdt3.0 en accin
Desempeo de rdt3.0
rdt3.0 funciona, pero el desempeo es bajo Ejemplo: enlace de 1 Gbps, retardo de propagacin 15 ms, paquete de
8000 bits: =
8000 = 9 = 8 10 fraccin de tiempo que el emisor est ocupado enviando
Utilization del emisor U emisor:
0.008 = = 0.00027 30.008 +
1 paq. de 1KB cada 30 ms 33kBps an sobre un enlace de 1Gbps El protocolo de red limita el uso de los recursos fsicos!
rdt3.0: operacin de parada y espera

emisor
Primer bit de paquete transmitido, t = 0 Ultimo bit de paquete transmitido, t=L/R Llega primer bit de paquete
receptor
RTT
Llega ltimo bit de paquete, enviar ACK
ACK llega, enviar siguientepaquete, t = RTT + L / R
0.008 = = = 0.00027 30.008 +

Protocolos entubados (encauzados)

Encauzamiento: el emisor permite mltiples paquetes, en camino, por confirmar

El rango de nmeros de secuencia debe incrementarse Buffers en el emisor y receptor
Dos formas genricas de protocolos encauzados:
regresar a N, repeticin selectiva

Encauzamiento: utilizacin mejorada

sender
Primer bit de paq. transmitido, t = 0
receiver
Ultimo bit transmitido, t=L/R

Llega primer bit de paquete Llega ltimo bit de paquete, enviar ACK Llega ltimo bit de 2 paquete, enviar ACK Llega ltimo bit de 3 paquete, enviar ACK
RTT
ACK llega, enviar siguiente paquete, t = RTT + L / R
Incrementa la utilizacin en un factor de 3!
.024 3 * L / R = = emisor RTT + L / R 30.008
= 0.0008
microsecon ds
Protocolos encauzados
Regresar a N: resumen: El emisor puede tener hasta N paquetes sin confirmar en el cauce El receptor solo envia ACKs acumulativos
No confirma un paquete si existe un espacio
El emisor tiene un timer para
Repeticin selectiva: resumen: El emisor puede tener hasta N paquetes sin confirmar en el cauce El receptor confirma paquetes individuales El emisor mantiene un timer por cada paquete sin confirmar
el paquete mas viejo sin confirmar
Si el timer expira, retransmite todos los paquetes no confirmados
Cuando expira el timer, retransmite solo el paquete no confirmado
Repeticin selectiva: resumen

El emisor puede tener hasta N paquetes sin
confirmar en el cauce El receptor confirma paquetes individuales El emisor mantiene un timer por cada paquete sin confirmar
Cuando expira el timer, retransmite solo el paquete no confirmado
Regresar a N
Emisor:
#sec de k bits en encabezado de paquete Ventana de hasta N, paquetes consecutivos sin confirmar permitidos
ACK(n): Confirma todos los paquetes hasta #sec n inclusive ACK
acumulativo Puede recibir ACKs duplicados (ver receptor) Timer para cada paquete en camino timeout(n): Retransmite el paquete n y todos los paquetes con #sec mayor en la ventana
Regresar a N: FSM extendido 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])
L
base=1 nextseqnum=1
Esperar rdt_rcv(rcvpkt) && corrupt(rcvpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer
Regresar a N: FSM extendido 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++
L Wait expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum)
ACK-only: siempre enva un ACK por paquete correctamente recibido con el mayor #sec en orden

Puede generar ACKs duplicados Solo necesita recordar expectedseqnum
Paquetes fuera de orden: descartar (no poner en buffer) -> no requiere buffer en el receptor! Reconfirmar el paquete con el mayor #sec en orden
Regresar a N en accin
Repeticin selectiva
El receptor confirma individualmente todos los
paquetes correctamente recibidos
Pone en buffer los paquetes, segn se requiera, para su eventual entrega ordenada a la capa superior
El emisor solo reenva los paquetes para los cuales no
se recibi un ACK
Un timer por cada paquete no confirmado en el emisor
Ventana del emisor N #sec consecutivos Limita los #sec de paquetes enviados sin confirmar
Repeticin selectiva: ventanas de emisor y receptor
Repeticin selectiva
Emisor
Datos desde arriba :
Si el siguiente #sec disponible
Receptor
Paquete n en [rcvbase, rcvbase+N-1]
enviar ACK(n) Fuera de orden: buffer En orden: entregar (tambin
esta en la ventana, enviar paquete
Timeout(n):
Reenviar paquete n, reiniciar
timer
entregar paquetes ordenados en buffer), avanzar la ventana al siguiente paquete por recibir
ACK(n) en [sendbase,sendbase+N]:
Marcar paquete n como recibido Si n es el paquete menor sin
Paquete n en [rcvbase-N,rcvbase-1]
ACK(n)
En otro caso:
Ignorar
confirmar, avanzar la base de la ventana al siguiente #sec sin confirmar
Repeticin selectiva en accin
Repeticin selectiva: dilema

Ejemplo:
#s sec: 0, 1, 2, 3 Tamao de ventana=3 El receptor no ve ninguna
diferencia en los dos escenarios! Erroneamente pasa datos duplicados como nuevos en (a)
Q: Que relacin existe entre el tamao de #sec y el tamao de la ventana?

TCP transmission Control Protocol

Transporte orientado a la conexin: TCP

Estructura de segmento Transferencia de datos fiable Control de flujo Gestin de conexin
TCP: Revisin
Punto a punto:
RFCs: 793, 1122, 1323, 2018, 2581

Transmisin full duplex:
Un emisor, un receptor Fiable, flujo de bytes en orden: No existe delimitacin de mensajes Encauzado: Control de congestionamiento y flujo TCP determina el tamao de la ventana Buffers de envio y recepcin
Flujo de datos bidireccional en la misma conexin MSS: maximum segment size Orientado a la conexin: handshaking (intercambio de mensajes de control) inicia el estado de emisor y receptor antes del intercambio de datos Flujo controlado: El emisor no inundar al receptor
application reads data TCP receive buffer socket door
socket door
application writes data TCP send buffer

segment
Estructura de segmento TCP

32 bits
URG: urgent data (generalmente no usado)
#puerto origen
#puerto dest.
ACK: ACK # valido

PSH: push data now (generalmente no usado) RST, SYN, FIN: Establecimiento de conexin (setup, teardown commands) Internet checksum (como en UDP)
Nro de secuencia
Conteo por bytes de datos (no segmentos!)
Nro confirmacin (ACK#)

head not UA PRS F len used
Receive window Urg data pnter

# bytes que el Receptor desea aceptar
checksum
Opciones (longitud variable)
Datos de aplicacin
(longitud variable)
#sec y ACKs TCP

#Sec:
nmero de byte en el flujo del primer byte en el segmento de datos
Host A
Usuario escribe C
Host B
ACKs: Nmero de secuencia del siguiente byte esperado del otro lado ACK acumulativos Q: Cmo maneja el receptor los segmentos fuera de orden? Rpta: TCP deja esto al implementador
host confirma La recepcin deC. Devuelve C
host ACKs La recepcin del C reenviado
tiempo
ESCENARIO SIMPLE DE TELNET

TCP: Round Trip Time y Timeout

Q: Como establecer el valor del timeout de TCP?
Mayor que RTT
Q: Como estimar RTT?

SampleRTT: tiempo medido
pero RTT vara
Muy corto: timeout
prematuro Retransmisiones innecesarias Muy largo: reaccin lenta ante la prdida de segmentos
desde la transmisin del segmento hasta la recepcin del ACK Ignorar retransmisiones SampleRTT variar , se requiere un RTT estimado suave Promediar varias mediciones recientes, no solo el SampleRTT actual

EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
Promedio ponderado exponencial (Exponential weighted moving
average) La influencia de muestras anteriores decrece exponencialmente rpido Valor tpico de = 0.125
Ejemplo de estimacin 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

Establecimiento del timeout
EstimatedRTT ms un margen de seguridad
Mayor variacion en EstimatedRTT -> margen de seguridad mayor
Primero estimar en cunto SampleRTT se desva del
EstimatedRTT:
DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (valor tpico de = 0.25)
Luego establecer el intervalo del timeout :

TimeoutInterval = EstimatedRTT + 4*DevRTT
TCP
Transporte orientado a la conexin: TCP Estructura de segmento Transferencia de datos fiable Control de flujo Gestin de conexin
Principios de control de congestionamiento

Control de congestionamiento TCP
Transferencia de datos fiable TCP

TCP crea un servicio Las retransmisines
TDF sobre el servicio no fiable de IP Segmentos entubados Acks acumulativos TCP utiliza un temporizador de retransmisin nico
ocurren cuando:

Ocurre un timeout Se recibe acks duplicados
Considere inicialmente
un emisor TCP simplificado:

Ignora acks duplicados Ignora control de flujo y control de congestionamiento
Eventos del emisor TCP:

Datos recibidos de la aplicacin: Crear segmento con seq# seq# es el nmero en el flujo de bytes del primer byte de datos del segmento Iniciar timer si ste an no esta activado (el timer se asocia al segmento no confirmado ms antiguo) Intervalo de expiracin:
TimeOutInterval
timeout: Retransmitir el segmento que ocasion el timeout Reiniciar timer Ack recibido: Si confirma segmentos previamente no confirmados
Actualizar aquello que deba ser confirmado Iniciar timer si existen segmentos pendientes
NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: Datos recibidos de la capa de aplicacion Crear segmento TCP con nro de secuencia NextSeqNum si (timer no esta corriendo) iniciar timer pasar segmento a IP NextSeqNum = NextSeqNum + longitud(data) event: timeout de timer retransmitir segmentos aun-no-reconocidos con el menor nmero de secuencia iniciar timer event: Arribo de ACK, con campo ACK con valor y si (y > SendBase) { SendBase = y si (existen segmentos aun-no-reconocidos) iniciar timer } } /* fin de loop infinito */
Emisor TCP
(simplificado)
Comentario: SendBase-1: ltimo byte confirmado acumulativamente Ejemplo: SendBase-1 = 71; y= 73, entonces el Rcvr espera 73+ ; y > SendBase, entonces se confirma data nueva
TCP: escenarios de retransmisin

Host A Host B Host A Host B
loss
Sendbase = 100 SendBase = 120
SendBase = 100
SendBase = 120
time
time Timeout prematuro ACK perdido

Seq=92 timeout
Seq=92 timeout
timeout
TCP escenarios de retransmisin (mas)

Host A Host B
timeout
loss
SendBase = 120
time ACK acumulativo

Generacin de ACK TCP

Evento en el Receptor
Llegada de segmento con seq# esperado. Todos los datos hasta el seq# esperado ya confirmados
Llegada de segmento con seq# esperado.Otro segmento tiene un ACK pendiente Llegada de un segmento fuera de orden con seq# mayor al esperado. Se detecta un hueco Llegada de un segmento que llena parcial o completamente un hueco
[RFC 1122, RFC 2581]
Accin en el Receptor TCP

Ack retrazado. Esperar hasta 500 ms por un siguiente segmento. Si no hay, enviar Ack Enviar inmediatamente un nico Ack Acumulativo, confirmando los dos segmentos llegados en orden Enviar inmediatamente un Ack duplicado, Indicando el seq# del siguiente Byte Esperado Enviar inmediatamente un Ack, siempre que el Segmento comienza en el limite inferior del hueco
Retransmisin rpida
Periodo de Timeout suele ser
Si el emisor recibe 3
relativamente largo:
Retardo largo antes de reenviar un paquete perdido
Deteccin de segmentos
perdidos mediante ACKs duplicados.

ACKs para el mismo dato, este supone que el segmento despues de los datos confirmados se perdi:
El emisor suele enviar muchos segmentos back-to-back Si se pierde un segmento, puede haber muchos ACKs duplicados.
Retransmisin rpida: reenviar segmento antes que el timer expire
Host A
Host B
timeout
time Reenvio de un segmento despus de un ACK duplicado tres veces

Algoritmo de Retransmisin Rpida:

evento: ACK recibido, con campo ACK con valor y si (y > SendBase) { SendBase = y si (existen segmentos aun-no-confirmados) iniciar timer } sino { incrementar cuenta de ACKs duplicados recibidos por y si (cuenta de ACKs duplicados recibidos por y = 3) { renviar segmento con numero de secuencia y }
Un ACK duplicado para un segmento ya confirmado
Retransmisin rpida
TCP: Control de flujo
Control de flujo TCP

Control de flujo
El receptor TCP tiene
un buffer de recepcin
El emisor no desbordar el buffer del receptor transmitiendo demasiado a excesiva velocidad
Servicio de conciliacin de
El proceso de la
velocidad: conciliar la tasa de transmisin con la tasa de extraccin de la aplicacin receptora
aplicacin puede ser lento al leer del buffer

Control de flujo TCP: Cmo funciona

El receptor notifica espacio
(Suponga que el receptor TCP
libre incluyendo el valor de RcvWindow en los segmentos El emisor limita datos no confirmados a RcvWindow
descarta segmentos fuera de orden) Espacio libre en buffer =
Garantiza que el buffer de recepcin no se desbordar
= [ ]
TCP: Gestion de conexin
Gestion de conexin TCP

Recuerde: el emisor y el receptor
TCP establecen una conexin antes de intercambiar segmentos de datos Inicializar variables TCP : seq. #s buffers, informacin de control de flujo (e.g. RcvWindow ) Cliente: iniciador de la conexin
Socket clientSocket = new Socket("hostname","port number");
Three way handshake:

Paso 1: host cliente envia un segmento TCP SYN al servidor Especifica seq# inicial No enva datos Paso 2: host servidor recibe SYN, responde con un segmento SYNACK
Servidor asigna buffers Especifica el seq# inicial del servidor Paso 3: el cliente recibe SYNACK, responde con un segmento ACK, que puede contener datos
Servidor: contactado por cliente

Socket connectionSocket = welcomeSocket.accept();
Gestion de conexin TCP (cont.)

Cierre de conexin: client closes socket: clientSocket.close();
close
client server
Paso 1: host cliente envia un segmento de control TCP FIN al servidor

timed wait
close
Paso 2: host servidor recibe FIN, responde con ACK. Cierrra conexin, envia FIN.
closed
Gestion de conexin TCP (cont.)

Paso 3: host cliente recibe FIN, responde con ACK.
client
server
closing
Ingresa en timed wait responder con ACK a los FINs recibidos
closing
Paso 4: host servidor, recibe ACK. Conexin cerrada.

timed wait
closed
closed
TCP Connection Management (cont)
TCP server lifecycle
TCP client lifecycle
PRINCIPIOS DE CONTROL DE CONGESTIONAMIENTO
Principios de control de congestionamiento

Congestion:
Informalmente: demasiadas fuentes enviando
demasiados datos mas rpido de lo que la red puede manejar Diferente del control de flujo! Manifestaciones: Paquetes perdidos (desbordamiento de buffers en los enrutadores) Retardos largos (encolamiento en buffer de enrutadores) Un problema crtico!
Causas/costos de la congestion: escenario 1

Host A
Dos emisores, dos
lin : original data
lout
receptores Un enrutador, buffer infinito Sin retransmisin
Host B
Buffers de enlace de salida compartidos infinito
Retardos largos
cuando congestionado Rendimiento mximo alcanzable

Un enrutador, buffer finito Retransmision de paquetes perdidos por el emisor
Host A
lin : datos originales l'in : datos originales , mas datos retransmitidos
lout
Host B
Buffers de enlace de salida compartidos finito

Siempre:
l in
= l out
(goodput) l in > l out mayor (que
Retransmisin perfecta solo por prdidas:
Retransmisin de paquetes retrasados (no perdidos) hace l in
el caso perfecto) para el mismo l out

R/2 R/2 R/2
R/3
lout
lout
lin
R/2
lin
R/2
lout
R/4
lin
R/2
a.
b.
c.
Costos de congestion: Mas trabajo (retransmisiones) para dado goodput Retransmisiones innecesarias: el enlace transporta multiples copias de un paquete

Cuatro emisores Rutas multisalto timeout/retransmision
Host A
Q: que pasa cuando l in y l in se incrementan?

lout
lin : original data l'in : original data, plus retransmitted data Buffers de enlace de salida compartidos finito
Host B

H o s t A H o s t B
l
o u t
Otro costo de la congestin: Cuando un paquete es descartado, toda capacidad de transmisin usada para dicho paquete fue desperdiciada
Enfoques para el control de congestionamiento

Dos enfoques para el control de congestionamiento:
Control de congestionamiento asistido por la red:
Los enrutadores proveen
Control de congestionamiento extremo-extremo:

No hay retroalimentacion
explicita de la red El congestionamiento se infiere de las prdidas y retardos observados por el sistema final Es el enfoque tomado por TCP
retroalimentacion a los sistemas finales Bit indicador de congestion (SNA, DECbit, TCP/IP ECN, ATM) Tasa de transmisin explicita a la cual debe transmitir el emisor
Caso de estudio: control de congestionamiento ABR de ATM

ABR: available bit rate:
servicio elastico
Si la ruta del emisor esta
Celulas RM (resource management) :

Enviadas por el emisor, intercaladas
subcargada: El emisor debe utilizar el ancho de banda disponible Si la ruta del emisor esta congestionada: El emisor es limitado a la tasa mnima garantizada.
con celulas de datos. Bits en celula RM establecidas por switches (network-assisted) NI bit: sin incremento en tasa (congestion leve) CI bit: indicacin de congestion Celulas RM devueltas al emisor por el receptor, con bits intactos
Caso de estudio: control de congestionamiento ABR de ATM
campo ER (Explicit Rate) de 2 bytes en celula RM

Switch congestionado puede reducir el valor de ER en la celula La tasa de emisin del emisor sera la tasa mxima soportable en la ruta
Bit EFCI en celulas de datos: puesto en 1 en switches
congestionados
Si una celda de datos que precede a una celula RM tiene EFCI en 1, el emisor pone CI en 1 en la celula RM devuelta
CONTROL DE CONGESTIONAMIENTO TCP
Control de congestionamiento TCP:

incremento aditivo, decremento multiplicativo
Enfoque: incrementar tasa de transmisin (tamao de ventana),
verificando ancho de banda usable, hasta que ocurra prdida Incremento aditivo: incrementar CongWin en 1 MSS cada RTT hasta que se detecte prdida Decremento multiplicativo: reducir CongWin a la mitad despues de una prdida
congestion window 24 Kbytes
Comportamiento de diente de sierra: verificando ancho de banda
16 Kbytes
8 Kbytes
time
Control de congestionamiento TCP : Detalles

Emisor limita la transmisin:
LastByteSent-LastByteAcked CongWin
Aproximadamente,
tasa =
CongWin RTT
Bytes/sec
Cmo percibe el emisor el congestionamiento? loss event = timeout o 3 acks duplicados Emisor TCP reduce tasa (CongWin) despues de loss event Tres mecanismos:

CongWin es dinamica, funcin del
congestionamiento de red percibido
AIMD slow start conservative after timeout events

TCP Slow Start

Cuando se inicia una Cuando una conexin
conexin, CongWin = 1 MSS

Ejemplo: MSS = 500 bytes & RTT = 200 msec Tasa inicial = 20 kbps
comienza, incrementar la tasa exponencialmente hasta que ocurra la primera prdida
Ancho de banda disponible
puede ser >> MSS/RTT
Es deseable escalar rpidamente a una tasa respetable
TCP Slow Start (mas)

Cuando una conexin
comienza, incrementar la tasa exponencialmente hasta que ocurra la primera prdida:

Host A
Host B
Duplicar CongWin cada RTT Se consigue incrementando CongWin por cada ACK recibido
Resumen: tasa inicial es
baja pero escala exponencialmente rpido
RTT
time
Refinamiento: infiriendo prdida

Despues de 3 ACKs duplicados:
CongWin se reduce a la mitad Luego la ventana crece linealmente Pero despues de un timeout: CongWin se establece en 1 MSS; Luego la ventana crece exponencialmente Hasta un umbral, luego crece linealmente
Filosofia:
3 ACKs duplicados indican
que la red puede entregar algunos segmentos un timeout indica un escenario de congestion mas alarmante
Refinamiento
Q: Cuando, debe el crecimiento exponencial pasar a ser lineal? A: cuando CongWin sea igual a de su valor antes de un timeout.
Implementacion:
Umbral(Threshold ) variable Ante una prdida, el umbral se
iguala a de CongWin justo antes de la prdida

Resumen: Control de congestionamientoTCP

Cuando CongWin esta por debajo del Threshold, el emisor
en fase slow-start, la ventana crece exponencialmente

Cuando CongWin esta por encima del Threshold, el emisor
esta en fase congestion-avoidance, la ventana crece linealmente

Cuando ocurre triple ACK duplicado, el Threshold se iguala
a CongWin/2 y CongWin se iguala al Threshold

Cuando ocurre un timeout, el Threshold se iguala a
CongWin/2 y CongWin se iguala a 1 MSS
Control de congestionamiento de emisor TCP

Estado Slow Start (SS) Evento ACK recibido por datos previmente no confirmados Accin de Emisor TCP CongWin = CongWin + MSS, If (CongWin > Threshold) set state to Congestion Avoidance CongWin = CongWin+MSS * (MSS/CongWin) Comentario Resulting in a doubling of CongWin every RTT
Congestion Avoidance (CA)
ACK recibido por datos previmente no confirmados
Additive increase, resulting in increase of CongWin by 1 MSS every RTT
SS or CA
Prdida detectada por tres ACKs duplicados Timeout
Threshold = CongWin/2, CongWin = Threshold, Set state to Congestion Avoidance Threshold = CongWin/2, CongWin = 1 MSS, Set state to Slow Start Increment duplicate ACK count for segment being acked
Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. Enter slow start
SS or CA
SS or CA
ACK duplicado
CongWin and Threshold not changed
Algoritmo de control de congestionamiento

Th = ? CongWin = 1 MSS /* slow start or exponential increase */ While (No Packet Loss and CongWin < Th) { send CongWin TCP segments for each ACK increase CongWin by 1 } /* congestion avoidance or linear increase */ While (No Packet Loss) { send CongWin TCP segments for CongWin ACKs, increase CongWin by 1 } Th = CongWin/2 If (3 Dup ACKs) CongWing = Th; If (timeout) CongWin=1;
Rendimiento TCP
Cual es el rendimiento promedio de TCP en funcion
del tamano de ventana y el RTT?
Ignore slow start
Sea W el tamano de la ventana cuando ocurre una
perdida. Cuando la ventana es W, el rendimiento es W/RTT Justo despues de la perdida, la ventana cae a W/2 y el rendimiento a W/2RTT. Rendimiento promedio = 0.75W/RTT
TCP Futures: TCP over long, fat pipes

Por ejemplo: segmentos de 1500 bytes, RTT de 100ms,
se desea un rendimiento de 10Gbps Se requiere una ventana de tamano W = 83,333 segmentos (in-flight) Rendimiento en terminos de la tasa de perdida:
1.22 MSS RTT L

L = 210-10
Equidad de TCP
Objetivo de equidad: si K sesiones TCP comparten el mismo enlace con ancho de banda R, cada uno debe tener una tasa promedio de R/K
Conexion TCP 1
Conexion TCP 2
Router con capacidad R
Porque TCP es equitativo?

Dos sesiones concurrentes:
Additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally
equal bandwidth share
loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase
Connection 1 throughput R
Equidad (continua)
Equidad y UDP
Las aplicaciones
Equidad y conexiones TCP paralelas

Nada prohibe a las aplicaciones
multimedia generalmente no usan TCP
No desean ahogar la tasa por el control de congestionamiento Bombean audio/video a tasa constante, toleran prdida de paquetes
de abrir conexiones paralelas entre 2 hosts. Los navegadores web lo hacen Por ejemplo: un enlace de tasa R que soporta 9 conexiones;

En su lugar usan UDP:
Una nueva aplicacion pide 1 TCP, recibe una tasa de R/10 Una nueva aplicacion pide 11 TCPs, recibe R/2 !

2 - capaDeTransporte

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

2 - capaDeTransporte

Diunggah oleh

Hak Cipta:

Format Tersedia

LA CAPA DE TRANSPORTE

Aprender sobre los

protocolos de transporte en Internet:

multiplexado/demultiplex ado Transferencia de datos fiable Control de flujo Control de congestionamiento

Servicios de la capa de transporte

Servicios y protocolos de transporte

application transport network data link physical

application transport network data link physical

Capa de transporte vs. capa de red

comunicacin lgica entre hosts

Comunicacin lgica entre procesos

Opera sobre y mejora los servicios de la capa de red

Protocolos de la capa de transporte de Internet

application transport network data link physical

Control de congestionamiento Control de flujo Configuracin de conexin

network data link physical

network data link physical

Entrega no fiable y fuera de

network data link physicalnetwork network data link physical

data link physical application transport network data link physical

Una extension sin mas del protocolo IP de mejor esfuerzo

network data link physical

Servicios no disponibles: Garantas de retardo Garantas de ancho de banda

Como funciona el demultiplexado

Otros campos de encabezado Datos de aplicacin (mensaje)

Demultiplexado no orientado a la conexin

Datagramas IP con direcciones

identifica por la tupla : (direccin IP destino, nmero de

Capa de transporte 3-10

Demultiplexado no orientado a la conexin (cont)

SP proporciona la direccin de retorno

Demultiplexado orientado a la conexin

identifica por la tupla:

admitir muchos sockets TCP simultneos:

Cada socket se identifica mediante su propia tupla

Los servidores Web tiene

El host receptor usa los

4 valores para dirigir el segmento al socket apropiado

diferentes sockets para cada conexin de cliente

HTTP no persistente tendr sockets diferentes para cada consulta

Capa de transporte 3-12

Demultiplexado orientado a la conexin(cont)

Capa de transporte 3-13

Demultiplexado orientado a la conexin: Web Server multihilo

Capa de transporte 3-14

Transporte no orientado a la conexin UDP

Capa de transporte 3-15

UDP: User Datagram Protocol [RFC 768]

Porqu existe UDP?

Longitud, en bytes, de segmento UDP, incluyendo el encabezado

Datos de aplicacin (mensaje)

Formato de segmento UDP

Ejemplo de checksum Internet

Por ejemplo: sumar dos enteros de 16 bits

Principios de transferencia de datos fiable

Capa de transporte 3-20

Principios de trasferencia de datos fiable

Las caractersticas del canal no fiable determinarn la complejidad

del protocolo de transferencia de datos fiable (rdt)

Principios de trasferencia de datos fiable

Las caractersticas del canal no fiable determinarn la complejidad

del protocolo de transferencia de datos fiable (rdt)

Principios de trasferencia de datos fiable