Professional Documents
Culture Documents
Capa de transporte
3-1
La capa de transporte
OBJETIVOS: Comprender los principios detras de los servicios de la capa de transporte:
UDP: transporte no orientado a la conexin TCP: transporte orientado a la conexin Control de congestionamiento TCP
Capa de transporte
3-2
Capa de transporte
3-3
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
Capa de transporte
3-4
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
TCP
orden: UDP
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
Capa de transporte 3-8
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.
Formato de segmentoTCP/UDP
Capa de transporte 3-9
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
IP de origen y/o nmeros de puerto origen diferentes se direccionan al mismo puerto, si tienen la direccion IP y puerto destino iguales
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
Direccin IP de origen Nmero de puerto origen Direccin IP de destino Nmero de puerto destino
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
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
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
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
Capa de transporte 3-16
UDP
Comunmente utilizado para
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
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.
Capa de transporte 3-18
Cuando se suma nmeros, un acarreo del bit ms significativo debe sumarse al resultado
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
Capa de transporte 3-19
Lado emisor
Lado receptor
udt_send(): llamado por rdt, para transferir un paquete sobre un canal no fiable al 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
emisor
receptor
Capa de transporte 3-26
paquete
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
Capa de transporte 3-27
receptor
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
udt_send(NAK)
emisor
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
L
Espera ACK o NAK 1
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) && 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
nota: el receptor no
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt)
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)
rdt_rcv(rcvpkt)
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: =
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!
Capa de transporte 3-41
receptor
RTT
receiver
RTT
= 0.0008
microsecon ds
Capa de transporte 3-44
Protocolos encauzados
Regresar a N: resumen: El emisor puede tener hasta N paquetes sin confirmar en el cauce El receptor solo envia ACKs acumulativos
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
confirmar en el cauce El receptor confirma paquetes individuales El emisor mantiene un timer por cada paquete sin confirmar
Regresar a N
Emisor:
#sec de k bits en encabezado de paquete Ventana de hasta N, paquetes consecutivos sin confirmar permitidos
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
L
base=1 nextseqnum=1
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer
ACK-only: siempre enva un ACK por paquete correctamente recibido con el mayor #sec en orden
Paquetes fuera de orden: descartar (no poner en buffer) -> no requiere buffer en el receptor! Reconfirmar el paquete con el mayor #sec en orden
Capa de transporte 3-49
Regresar a N en accin
Repeticin selectiva
El receptor confirma individualmente todos los
Pone en buffer los paquetes, segn se requiera, para su eventual entrega ordenada a la capa superior
se recibi un ACK
Ventana del emisor N #sec consecutivos Limita los #sec de paquetes enviados sin confirmar
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
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
diferencia en los dos escenarios! Erroneamente pasa datos duplicados como nuevos en (a)
TCP: Revisin
Punto a punto:
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
socket door
#puerto origen
#puerto dest.
Nro de secuencia
checksum
Datos de aplicacin
(longitud variable)
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
tiempo
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
average) La influencia de muestras anteriores decrece exponencialmente rpido Valor tpico de = 0.125
300
RTT (milliseconds)
250
200
150
EstimatedRTT:
DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (valor tpico de = 0.25)
TCP
Transporte orientado a la conexin: TCP Estructura de segmento Transferencia de datos fiable Control de flujo Gestin de conexin
TDF sobre el servicio no fiable de IP Segmentos entubados Acks acumulativos TCP utiliza un temporizador de retransmisin nico
ocurren cuando:
Considere inicialmente
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
Capa de transporte 3-66
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
loss
Sendbase = 100 SendBase = 120
SendBase = 100
SendBase = 120
time
Seq=92 timeout
Seq=92 timeout
timeout
timeout
loss
SendBase = 120
Retransmisin rpida
Periodo de Timeout suele ser
Si el emisor recibe 3
relativamente largo:
Deteccin de segmentos
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.
Host A
Host B
timeout
Retransmisin rpida
un buffer de recepcin
Servicio de conciliacin de
El proceso de la
libre incluyendo el valor de RcvWindow en los segmentos El emisor limita datos no confirmados a RcvWindow
= [ ]
Capa de transporte 3-76
close
Paso 2: host servidor recibe FIN, responde con ACK. Cierrra conexin, envia FIN.
closed
Capa de transporte 3-79
client
server
closing
closing
closed
closed
Capa de transporte 3-80
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!
Capa de transporte 3-83
lout
Host B
Retardos largos
Host A
lout
Host B
l in
= l out
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
Capa de transporte 3-86
lin : original data l'in : original data, plus retransmitted data Buffers de enlace de salida compartidos finito
Host 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
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
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
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
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
Capa de transporte 3-91
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
16 Kbytes
8 Kbytes
time
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:
Ejemplo: MSS = 500 bytes & RTT = 200 msec Tasa inicial = 20 kbps
Host A
Host B
Duplicar CongWin cada RTT Se consigue incrementando CongWin por cada ACK recibido
RTT
time
Capa de transporte 3-96
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
SS or CA
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
Rendimiento TCP
Cual es el rendimiento promedio de TCP en funcion
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
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:
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
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
Capa de transporte 3-105
Equidad (continua)
Equidad y UDP
Las aplicaciones
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;
Una nueva aplicacion pide 1 TCP, recibe una tasa de R/10 Una nueva aplicacion pide 11 TCPs, recibe R/2 !