Red g1 Transporte 2016 II

UNIVERSIDAD
NACIONAL
MAYOR DE SAN
MARCOS
Decana de Amrica
FACULTAD DE INGENIERA DE
SISTEMAS E INFORMATICA
REDES Y TRANSMISION DE DATOS

Mg. JUAN CARLOS GONZALES
SUAREZ
2016-II
Nivel de Transporte
Redes y Transmisin de Datos

Mg. Juan Carlos Gonzales Surez


Nivel de Transporte
Objetivos:
Entender los
principios detrs de
los servicios de la
capa transporte:
Multiplexing /
demultiplexing
Transferencia confiable
de datos
Control de flujo
Control de congestin
Aprender sobre los
protocolos de
transporte en la
Internet:
UDP (User Datagram

Protocol): transporte
sin conexin
TCP (Transmission
Control Protocol):
transporte orientado a
la conexin
en TCP
Protocolos y servicios de
transporte
Proveer comunicacin lgica
network
data link
physical
network
data link
physical
g
lo
e
al
ic
nd
-e
nd
network
data link
physical
tr
network
data link
physical
t
or
sp
an
entre procesos de aplicaciones

corriendo en diferentes hosts
Los protocolos de transporte
corren en sistemas terminales
(computadores, no equipos
internos como routers)
Hay ms de un protocolo de
transporte disponible para las
aplicaciones
Ms comunes: TCP y UDP
Hoy tambin SCTP (Stream
Control Transmission
Protocol, 2000),
DCCP (Datagram Congestion
Control Protocol, 2005)
application
transport
network
data link
physical
network
data link
physical
application
transport
network
data link
physical




Capa transporte vs. capa red
Capa transporte:
encargada de la
comunicacin lgica
entre procesos
Depende y mejora los

servicios de la capa de
red
Capa de red: encargada
de la comunicacin
lgica entre hosts
Analoga:
85 soldados de diferentes
puntos del frente de batalla
envan cartas a sus casas.
Cabo William y Cabo Gil
recopilan las cartas y las envan
por correo. Asimismo, reparten
las cartas que llegan.
Procesos =
Mensajes aplicacin =
Hosts =
Protocolo de transporte =
Protocolo capa red =

Protocolos de capa transporte en Internet

TCP: Entrega confiable y en
orden
vez desordenada:
Qu servicios no se ofrecen:
Garantas de retardo
Garantas de ancho de banda
(Bsicamente porque no es
fcil -o posibleimplementarlo basndose en
los servicios de IP)
network
data link
physical
t
or
sp
an
Bsicamente el mismo
servicio de IP: mejor
esfuerzo (best-effort)
network
data link
physical
tr
nd
-e
nd
UDP: Entrega no confiable, tal
network
data link
physical
e
al
ic
network
data link
physical
g
lo
Tiene: Control de flujo

Tiene: control de congestin
Establecimiento de conexin
application
transport
network
data link
physical
network
data link
physical
application
transport
network
data link
physical

Multiplexacin/demultiplexaci
n
Multiplexacin en host Tx:
Capa de transporte:
Recopila datos desde
mltiples sockets, usa info. de
encabezado (puerto e IP
origen, puerto e IP destino)
= socket
aplicacin
transporte
red
Demultiplexacin en host Rx:

Entrega el segmento recibido
al socket correcto
Basado en puerto (UDP)
Basado en 4-tupla (TCP)
= proceso
P3
P1
P1
aplicacin
transporte
P2
P4
aplicacin
transporte
red
red
enlace
fsica
host 1
enlace
fsica
host 2
enlace
fsica
host 3
Cmo trabaja la
demultiplexacin?
El host Rx recibe datagramas IP
Cada datagrama tiene direccin

IP fuente y direccin IP destino
Cada datagrama incluye 1
segmento de la capa transporte
Cada segmento tiene nmeros
de puerto fuente y destino
32 bits
# puerto fuente # puerto dest.
Otros campos
del encabezado
En general el host usa las
direcciones IPs y nmeros de

puertos para conducir un
segmento al socket apropiado
Puertos 0-1023 reservados por
protocolos establecidos, HTTP:
80, FTP: 21, estn definidos en
RFC 1700
Datos de la aplicacin
(mensaje)
Formato de segmento TCP/UDP

Demultiplexacin sin conexin

(UDP)
Capa de transporte reconoce Socket destino por
puerto destino y la aplicacin reconocer

remitente por la IP y puerto origen.
Cuando la capa transporte recibe un segmento
UDP (lado receptor):
Chequea nmero de puerto destino en
segmento
Dirige el segmento UDP al socket con ese
nmero de puerto
Datagramas IP con direcciones IP y/o nmeros de
puerto origen diferentes pueden ser dirigidos al
mismo socket destino.
Demultiplexacin sin conexin

P2
9157
P3
PO: 6428
3 PD: 9157
cliente
IP: A
PO: 9157
PD: 6428
6428
5775
PO: 6428
PD: 5775
servidor
IP: C
P1
PO: 5775
2 PD: 6428
Cliente
IP:B
PO: puerto origen, junto a IP origen proveen direccin de retorno
Un mismo socket recibe mensajes desde

distintos hosts. La aplicacin los distingue por la IP
y puerto origen de cada mensaje.
Demultiplexacin orientada a la conexin (TCP)

Un host servidor puede
Un socket maneja solo
un cliente.
Sockets TCP queda
definido por (4-tupla):
Direccin IP Origen
Nmero de puerto Origen
Direccin IP Destino
Nmero de puerto
Destino
Host receptor usa los
cuatro valores para

dirigir los segmentos al
socket apropiado.
soportar muchos
sockets TCP en un
mismo puerto
simultneos:
Cada socket es
identificado por su 4-tupla
propia
Un servidores Web tiene

un socket diferente por
cada cliente conectado
HTTP no-persistente
tendr diferentes sockets
por cada peticin de
datos Redes y Transmisin de Datos
Demultiplexacin orientada a la
conexin
P1
P4
P5
P2
P6
P1P3
PO: 5775
PD: 80
IP-O: B
IP-D: C
cliente
IP: A
PO: 9157
PD: 80
IP-O: A
IP-D: C
servidor
IP: C
PO: 9157
PD: 80
IP-O: B
IP-D: C
Cliente
IP:B
Notar puede haber igual puerto Origen en A y B.

Igual puerto destino en ambas conexiones desde B.
Demultiplexacin orientada a la
conexin: Servidor Web con hilos
P1
P2
P4
P1P3
PO: 5775
PD: 80
IP-O: B
IP-D: C
cliente
IP: A
PO: 9157
PD: 80
IP-O: A
IP-D: C
servidor
IP: C
PO: 9157
PD: 80
IP-O: B
IP-D: C
Cliente
IP:B
Aqu un nico proceso maneja distintos sockets

para cada cliente. La programacin de esto se
estudia en ELO330
UDP: User Datagram Protocol

[RFC 768]
Bsicamente agrega puerto
a paquete IP
Servicio de mejor
esfuerzo, un segmento
UDP se puede:
perder
Entregar a la aplicacin
fuera de orden
Sin conexin:
No hay handshaking
(establecimiento de
conexin) entre servidor
y receptor UDP
Cada segmento UDP es
manejado en forma
independiente de los
Mejor
esfuerzo: Har todo lo
otros
posible por entregarlo, pero no lo

garantizo.
Por qu existe UDP?

No requiere
establecimiento de
conexin (lo cual
agregara retardo)
Simple: no se requiere
mantener estado en el Tx
y el Rx
Pequeo segmento de
encabezado => menor
overhead
No hay control de
congestin: UDP puede
transmitir tan rpido
como se desee

UDP: ms detalle Largo, en bytes del

A menudo es usado por flujos
(streaming) multimedia en
aplicaciones que:
segmento UDP, incluyendo

encabezado
Toleran prdida de datos

Son sensibles a la tasa de
transmisin
32 bits
# puerto origen # puerto dest.
largo
checksum
Otros usos de UDP
DNS
SNMP (Simple Network Management
Protocol)
Es posible lograr transferencias
confiables sobre UDP: se debe

programar la confiabilidad en la
capa aplicacin
En este caso la recuperacin de

errores depende de la aplicacin!
Datos de la
Aplicacin
(mensaje)
Formato segmento UDP

Checksum UDP (suma de

chequeo)
Objetivo: detectar errores (e.g., bits cambiados)
en segmentos transmitidos
Transmisor:
Receptor:
Trata el contenido de cada
Calcula el checksum del
segmento como una
segmento recibido
secuencia de enteros de 16
Chequea si el checksum
bits
calculado corresponde al
checksum: suma del
valor de checksum recibido
contenido del segmento y
luego invierte cada bits (se
en el campo:
conoce como tomar el
NO corresponde =>
complemento 1).
error detectado
Transmisor pone el valor del
SI => no hay error
checksum en el campo
detectado. Pero podran
checksum del datagrama
haber errores sin
UDP
embargo!
Incluye algunos campos de
IP (para los que quieren
comprobarlo con wireshark).
Ejemplo Checksum en Internet

Notar
Cuando sumamos nmeros, la reserva del

bit ms significativo debe ser sumada al
resultados
Tomar el complemento 1 no es ms que
invertir los bits
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
Sumar reserva 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
1
suma1 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 confiable de datos

Importante en capas de aplicacin, transporte y enlace
de datos
Est en la lista de los 10 tpicos ms importantes sobre redes !
rdt_ : reliable data transfer
udt_ : unreliable data transfer
Las caractersticas del canal no-confiable determinarn
la complejidad del protocolo de datos confiable (reliable

data transfer - rdt)
Transferencia confiable de datos:

rdt_send(): llamado desde arriba,
(e.g., por aplicacin). Recibe datos a
entregar a la capa superior del lado
receptor
lado
transmisor
udt_send(): llamado por rdt

para transferir paquetes al
receptor va un canal no
confiable
deliver_data(): llamado por

rdt para entregar los datos
al nivel superior
lado
receptor
rdt_rcv(): llamada cuando un

paquete llega al lado receptor del
canal
Limitantes segun Versiones

Si el canal es ideal, el mecanismo es
simple: solo enviar los datos (rdt 1.0).

Si hay errores, pero no se pierden
paquetes, usar ACK y NAK. (rdt 2.0)
Si los ACK o NAK tambin pueden venir
con errores,en este caso el tx re-enva el
paquete; entonces debemos usar nmero
de secuencia para eliminar duplicados.
(rdt 2.1)
Se puede evitar NAK, enviando ACK
duplicados en lugar de NAK, entonces
debemos usar nmero de secuencia para
detectad ACK duplicados (ver rdt 2.2)
rdt3.0: Canales con errores y prdidas

Suposicin nueva:
Canal subyacente tambin
puede perder paquetes
(de datos o ACKs)
checksum, # de
secuencias, ACKs, y
retransmisiones ayudan
pero no son suficientes
Estrategia: transmisor espera

un tiempo razonable por el
ACK
Retransmitir si no se recibe ACK en
este tiempo
Si el paquete (o ACK) est
retardado (no perdido):
La retransmisin ser un
duplicado, pero el uso de #s
de secuencia ya maneja esto
Receptor debe especificar el #
de secuencia del paquete
siendo confirmado en el ACK
Se requiere un temporizador.
Este protocolo se conoce como:
Stop and wait protocol (parar y
esperar)
rdt3.0 en accin
a) Operacin sin prdidas

b) Operacin con prdidas
rdt3.0 en accin
c) Prdida de ACK
d) Timeout prematuro
Protocolos con Pipeline
Con Pipeline: Transmisor permite mltiples

paquetes en trnsito con acuse de recibo
pendiente
El rango de los nmeros de secuencia debe ser

aumentado
Se requiere buffers en el Tx y/o Rx
Hay dos formas genricas de protocolos con
pipeline: go-Back-N y selective repeat (repeticin

selectiva)
Pipelining: utilizacin mejorada

sender
receiver
first packet bit transmitted,

t=
0
last bit transmitted,
t=
L/R
first packet bit arrives
last packet bit arrives, send ACK
last bit of 2nd packet arrives, send
ACK bit of 3rd packet arrives, send
last
ACK
RTT
ACK arrives, send next

packet, t = RTT + L / R
Mejora en utilizacin
por un factor de 3!
sender
3*L/R
RTT + L / R
.024
30.008
= 0.0008 = 0.08%
microseconds

Selective repeat: Ventanas de Tx y Rx

Con ACK
recibidos
Usable,
an no
enviados
ACK
pendientes
No usable
a) Vista de los nmero de secuencia del

transmisor
Fuera de orden
(almacenados)
con ACK
enviado
Esperado,
an no
recibido
Aceptable
(en ventana)
No usable
b) Vista de los nmero de secuencia del receptor

TCP: Generalidades
RFCs: 793, 1122, 1323, 2018, 2581
Es una comunicacin Punto-a
punto:
Transferencia full duplex
(dos sentidos):
Un Tx y un Rx
flujo de bytes confiable y en

orden:
No hay lmites del inicio/trmino

de mensaje
Usa pipeline:
Orientado a la conexin:
El tamao de la ventana TCP es

definido por el control de
congestin y control de flujo
Usa buffer en Tx & Rx

socket
door
Flujo de datos bidireccionales en la

misma conexin
MSS: maximum segment
size, depende del
Maximum Transmission
Unit de la capa enlace
application
writes data
application
reads data
TCP
send buffer
TCP
receive buffer
segment
Handshaking
(intercambio de
mensajes de control)
inicializa al Tx y Rx antes
del intercambio de datos
Tiene control de flujo:
socket
door
Tx no sobrecargar al Rx
Tambin tiene control de

congestin
Estructura de un segmento TCP

URG: urgent data
32 bits
(generalmente no usado) # puerto origen

ACK: mensaje
porta ACK vlido
PSH: push data now
(entregar datos a aplic.
ahora gen. no usado)
RST, SYN, FIN:

Establecimiento de
conexin
(comandos de inicio
y cierre)
checksum
(como en UDP)
# puerto dest.
Nmero de secuencia
Nmero de acknowledgement
largo No
head usado U A P R S F
RcvWindow
checksum
Puntero dato urgente
Opciones (largo variable)

Datos de la
aplicacin
(largo variable)
Cuenta bytes
de datos
(no segmentos)
Sec: flujo ida
Ack: flujo vuelta
# bytes que el
Rx est
dispuesto a
aceptar
(control de flujo)
Usado para
negociar MSS
o para factor
de escalamiento
ventana
Un autodidacta de Internet dice Como el campo

nmero de puerto es de 16 bits, un servidor TCP no
pueden atender ms de 216 clientes
simultneamente. Est usted de acuerdo?
Justifique.
No es correcto. El rango para el nmero de puerto no

limita el nmero de clientes conectados a un servidor. En
general los clientes vienen desde distintas mquinas y el
servidor crear un nuevo socket (no puerto) por cada
cliente. Ciertamente hay un lmite pero no est
relacionado con el rango para los puertos pues todos los
sockets usan nico puerto en el servidor.
Cada conexin TCP queda definida por la 4-tupla:
(IP_Origen, Puerto_origen, IP_destino, Puerto_destino)
Ejemplo: Uso de # de sec. y ACKs en Telnet

(Aplicacin sobre TCP)
# de Sec.:
nmero del byte
dentro del flujo
correspondiente al
primer byte del
segmento de datos
ACKs:
# sec. del prximo
byte esperado desde
el otro lado
ACK es acumulativo
Q: Cmo el receptor
maneja segmentos fuera
de orden?
la especificacin de
TCP lo deja a criterio
del implementador
Host B
Host A
Usuario Seq=4
2, AC
K=79
escribe
, data
= C
C
7
Seq=
host acusa
recibo de
C
C y enva
ta =
a
d
,
=4 3
echo de C
, ACK
host acusa
recibo de Seq
=43,
ACK=
eco C
80
Escenario telnet simple tiempo

Con conexin ya establecida
Transferencia confiable de datos en TCP

TCP crea un servicio
de transferencia
confiable sobre el
servicio no confiable
de IP
Usa envo de
segmentos en
pipeline
ACKs acumulativos
TCP usa un timer
nico de
retransmisin
Retransmisiones son
activadas por:
Eventos de timeout
ACKs duplicados
Inicialmente
consideremos un Tx
TCP simplificado:
Ignora ACKs duplicados
Ignora control de flujo y
control de congestin

Eventos del transmisor en TCP:
Datos recibidos desde

aplicacin:
Crea segmento con # de
sec.
# sec es el nmero dentro
del flujo para el primer
byte del segmento
Inicia timer si no est ya
corriendo (asociar el timer
al segmento ms viejo sin
acuse de recibo)
Tiempo de expiracin:
TimeOutInterval
Timeout:
Retransmitir el segmento que
caus el timeout (slo 1)
Tpicamente el intervalo del
timeout se duplica en
retransmisiones. Por qu?
Re-iniciar el timer
Recepcin de ACK:
Si es el ACK de un segmento
previo sin acuse de recibo
Actualizar estado sobre acuses

recibidos
Iniciar timer si hay segmentos
sin acuses de recibo.

TCP: escenarios de retransmisin

Prdida de ACK
Host A
92, 8
b yt e s
d at a
100
=
K
AC
loss
ACK
time
SendBase
= 92
=10
Sendbase
= 100
SendBase
= 120
SendBase
= 120
Host B
Seq=
Seq=92 timeout
Seq=
Seq=
92, 8
bytes
d at a
SendBase
= 100
Host A
Host B
92, 8
bytes
d at a
Seq=
100,
20 b
ytes
data
00
1
K= K=12
C
A
AC 0
Seq=
92, 8
bytes
data
Seq=92 timeout
timeout
SendBase
= 92
Timeout prematuro
time
K=
AC 0
12

TCP escenarios (ms)

Host A
SendBase = 92
Host B
timeout
Seq=
92, 8
bytes
data
100
Seq=
=
K
C
100,
20 byA
tes d
a ta
SendBase = 120
loss
ACK acumulado
=12
K
C
A
0
time
Estos diagramas no reflejan tiempos de

transmisin ni almacenamientos y reenvos en la ruta.
Retransmisiones rpidas
Host A
Host B
timeout
resen
d
time
2 nd se
gmen
t

TCP: Timeout
Duplicando
el tiempo del timeout
Algunas modificaciones en muchas implementaciones de
TCP:
La primera concierne al largo del intervalo de timeout
despus que el timer expira
En esta modificacin cuando ocurre un timeout, TCP

retransmite el segmento sin ACK con menor nmero de
secuencia pero por cada retransmisin TCP duplica el valor
previo de TimeoutInterval
De esta forma los intervalos crecen exponencialmente
despus de cada retransmisin sucesiva.
La segunda es si se recibe un ACK entonces se recalcula

TimeoutInterval usando EstimatedRTT y DevRTT
Esta es una forma limitada de control de congestin

Control de flujo en TCP

Hemos visto cmo TCP asegura confiabilidad
en la transferencia, ahora veremos cmo

consigue controlar el flujo de datos.
El proceso aplicacin
El lado receptor (Rx)
puede ser lento en la
de TCP tiene un
lectura del buffer
buffer receptor de
(capa transporte).
datos:
Control de flujo
Tx no debe sobrecargar
el buffer del receptor por
transmitir demasiado
rpido
La idea es hacer coincidir la tasa de
transmisin con la tasa de lectura de la

aplicacin.
Control de flujo en TCP: Cmo trabaja

Rx comunica el espacio
libre a travs del
valor de RcvWindow
en los segmentos
As el receptor limita
datos en transito (sin
ACK) a RcvWindow
(supongamos que receptor
(Tx debe respetar el
descarta segmentos fuera de no envo de ms
datos que
orden)
RcvWindow)
Espacio libre en buffer
RcvWindow = RcvBuffer [LastByteRcvd - LastByteRead]
Esto garantiza que el

buffer del Rx no se
rebalse (overflow)

Control de flujo en TCP: Cmo trabaja

El Transmisor debe tomar en cuenta los
segmentos en trnsito
Luego el nmero de bytes que el Tx puede enviar
es en general menor que el anunciado por la
RevWindows.
Cul es la expresin para el nmero de Bytes
posibles de enviar sin colapsar al receptor?

Cul es la funcin principal

o propsito del control de flujo?
Impedir
que el transmisor enve ms

datos que los que puede almacenar el
receptor.
Cuando el transmisor de una conexin TCP est a

punto de enviar un segmento con nmero de
secuencia 773, recibe un acuse de recibo con
numeracin 123 y ventana de recepcin 1300.
Cuntos bytes como mximo puede transportar el
segmento que est a punto de enviar?
Los bytes 123 hasta 772 inclusive (650

bytes) estn en trnsito para el valor de
ventana de recepcin 1300. Es as como
podemos asegurar que el receptor podr
almacenar 1300-650 =650 bytes, ste es
el nmero mximos de bytes a
transportar en el prximo segmento.

Administracin de Conexin en TCP

(cont.)
Establecimiento de conexin
client
Connection
request
ACK
SYN=
1,
server
seq=c
lient_
is
,
r _ is n
e
v
r
q=se sn+1
e
s
,
=1
t_i
SYN ck=clien
a
SYN=
0, seq
ack=s =client_is
n+
erver_
isn+1 1,
Connection
granted

Administracin de la Conexin TCP

Completo
servidor
Diagrama de
estados
completo e
incluyendo
ambos casos
CLOSED
Active open/SYN
Passive open
Close
Close
LISTEN
SYN_RCVD
SYN/SYN + ACK
Send/SYN
SYN/SYN + ACK
ACK
Close/FIN
FIN_WAIT_1
ACK
FIN_WAIT_2
SYN_SENT
Close llega
desde
capa
aplicacin
SYN + ACK/ACK
ESTABLISHED
Close /FIN
Quien
cierra
primero
cliente
AC FIN/ACK
K
+
FI
N
/A
CK
FIN/ACK
FIN/ACK
CLOSE_WAIT
Close/FIN
CLOSING
LAST_ACK
ACK Timeout after two

ACK
segment lifetimes
TIME_WAIT
CLOSED
Quien
cierra
segundo

En una conexin TCP uno de los extremos espera

un tiempo (time_wait) luego de enviar su ltimo
segmento. Usando un diagrama temporal de
intercambio de mensajes muestre y explique el
problema que se presentara si se decidiera no
esperar ese time_wait.
Varias
situaciones
inconvenientes
pueden ocurrir,
una de ellas se
muestra abajo.
Principios del control de congestin

Congestin:
Informalmente: demasiadas fuentes
enviando muchos datos muy rpido para

que la red lo maneje
Es distinto a control de flujo, ste ocurre
entre dos aplicaciones.
Manifestaciones:
Prdidas de paquetes (buffer overflow en
routers)
Grandes retardos (en las colas en los router)
Uno de los problemas top-10!

La capa de red no ofrece garantas de: entrega de

paquetes en orden, tasas de transferencia fija, llegada
confiable de datos, y retardo acotado desde
transmisin hasta recepcin. Cules de estos
requerimientos son posibles de garantizar va una
programacin adecuada de la capa de transporte?
Entrega de paquetes en orden y
llegada confiable de datos

Causas/costos de congestin: escenario 1

(buffer, sin re-envo)
dos transmisores, dos
receptores
un router, buffer tamao
infinito
sin retransmisin
in datos enviados por la
aplicacin (bytes/sec)
out datos recibidos por la
aplicacin (bytes/sec)
Host A
Host B
in : original data
out
unlimited shared
output link buffers
(C = link
capacity)
grandes retardos en
estado
congestionado
(muchos paquetes
esperando en cola)
mximo flujo posible
(throughput = C) de
datos
Redes
y Transmisin de Datos
Causas de congestin: escenario 2

(buffer no, con re-envo )
un router, buffer finito
Se pierden paquetes que no tienen espacio
en buffer.
transmisor retransmite paquetes perdidos
(a) caso perfecto, sin prdidas ni
retransmisiones: in = in
Host A
in : original data
'in : original data, plus
retransmitted data
(b) retransmisin slo en caso de
ou
prdida de segmentos (no por timeout
prematuro): in > out
(b) retransmisin de paquetes hace

que in sea ms grande (que el caso
Host B
perfecto) para el mismo out (No
Buffer enlace de
salida finito
compartido
necesariamente R/3 como cota)

(c) retransmisiones innecesarias
(timeout prematuros) : enlaces envan
mltiples copias del paquete (e.g. dos
re-envos por paquete)
costos de congestin:
ms trabajo (retransmisin) para lograr
el transporte de datos goodput

Causas/costos de congestin: escenario 3
cuatro transmisores
rutas con multihops
timeout/retransmisiones
Q: Qu pasa cuando in se
incrementa y in crece?
Host A
in : original data
'in : original data, plus
retransmitted data
finite shared output

link buffers
Host B
out

Estrategias para control de congestin

Los podemos clasificar en dos grupos amplios:
extremo a extremo:
No hay informacin de
realimentacin explcita de
la red
La congestin es inferida
desde las prdidas y
retardos observados por
terminales en los extremos
Es la estrategia usada
por TCP
asistido por la red:
Routers proveen
realimentacin a sistemas
extremos
Un Bit nico indicando
congestin (e.g. SNA,
DECbit, TCP/IP ECN, ATM)
Explcitamente se informa al
Tx la tasa que el router
puede soportar

Equidad en TCP
Objetivo de la Equidad (fairness): Si K
sesiones TCP comparten un mismo

enlace de ancho de banda R, cada
una debera tener una tasa promedio
de R/KTCP connection 1
TCP
connection 2
Router cuello
de botella de
capacidad R

Por qu TCP es justa?
Supongamos dos sesiones compitiendo:
Aumento aditivo da pendiente de 1, como aumento de
Throughput Conexin 2
throughout
Reduccin multiplicativa reduce throughput
proporcionalmente
R
Recta de Igual tasa
capacidad compartida
Prdida: decrece tasa en factor de 2

Abolicin de congestin: aumento aditivo
Prdida: decrece tasa en factor de 2
Abolicin de congestin: aumento aditivo
Throughput Conexin 1 R
Equidad (ms)
Equidad y UDP
Aplicaciones
Multimedia no usan
TCP
No quieren tasa limitada

por control de
congestin
En su lugar usan UDP:

Envan audio/vdeo a
tasa constante y toleran
prdidas de paquetes
rea de investigacin:
Equidad y conexiones TCP

paralelas
Nada previene a las
aplicaciones de abrir
conexiones paralelas entre
dos hosts.
Navegadores WEB hacen esto
Ejemplo: Sea un enlace de tasa
R soportando 9 conexiones;
Una aplicacin nueva pide 1

conexin TCP, obtendr R/10
Si la aplicacin nueva pide 11
conexiones TCP, sta
obtendr 11R/20 , ms de
R/2!
Hacerlas amistosas
con TCP (TCP friendly)
En una subred hay 6 usuarios viendo vdeos

de Youtube.com va conexiones TCP. Si
stos fueran los nicos usuarios, qu
fraccin de la capacidad de un enlace
congestionado le debera corresponder a
cada uno?
Nota: Se supone que ese es el nico

trfico en el enlace congestionado; en
otro caso ser la misma fraccin del
trfico para cada conexin.
Resumen
Principios detrs de los servicios
de capa transporte:
multiplexing, demultiplexing
Transferencia confiable de
datos
Control de flujo
Uso e implementacin en
Internet
UDP
TCP

Gracias
Juan Carlos Gonzales Suarez
jgonzaless@unmsm.edu.pe

Red g1 Transporte 2016 II

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Red g1 Transporte 2016 II

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDAD

REDES Y TRANSMISION DE DATOS

Redes y Transmisin de Datos

Redes y Transmisin de Datos

Redes y Transmisin de Datos

Aprender sobre los

UDP (User Datagram

entre procesos de aplicaciones

Redes y Transmisin de Datos

Redes y Transmisin de Datos

Redes y Transmisin de Datos

Redes y Transmisin de Datos

Capa transporte vs. capa red

Depende y mejora los

Capa de red: encargada

Redes y Transmisin de Datos

Protocolos de capa transporte en Internet

UDP: Entrega no confiable, tal

Tiene: Control de flujo

Redes y Transmisin de Datos

Demultiplexacin en host Rx:

El host Rx recibe datagramas IP

Cada datagrama tiene direccin

En general el host usa las

direcciones IPs y nmeros de

Formato de segmento TCP/UDP

Demultiplexacin sin conexin

puerto destino y la aplicacin reconocer

Demultiplexacin sin conexin

PO: puerto origen, junto a IP origen proveen direccin de retorno

Un mismo socket recibe mensajes desde

Mg. Juan Carlos Gonzales Surez

Demultiplexacin orientada a la conexin (TCP)

Host receptor usa los

cuatro valores para

Un servidores Web tiene

Notar puede haber igual puerto Origen en A y B.

Aqu un nico proceso maneja distintos sockets

Mg. Juan Carlos Gonzales Surez

UDP: User Datagram Protocol

posible por entregarlo, pero no lo

Por qu existe UDP?

Redes y Transmisin de Datos

UDP: ms detalle Largo, en bytes del

segmento UDP, incluyendo

Toleran prdida de datos

Otros usos de UDP

Es posible lograr transferencias

confiables sobre UDP: se debe

En este caso la recuperacin de

Formato segmento UDP

Checksum UDP (suma de

Mg. Juan Carlos Gonzales Surez

Ejemplo Checksum en Internet

Cuando sumamos nmeros, la reserva del

Ejemplo: sumar dos enteros de 16-bits

Principios de transferencia confiable de datos

Las caractersticas del canal no-confiable determinarn

la complejidad del protocolo de datos confiable (reliable

Transferencia confiable de datos:

udt_send(): llamado por rdt

deliver_data(): llamado por

rdt_rcv(): llamada cuando un

Limitantes segun Versiones