Capa de Transporte

FACULTAD DE INGENIERÍA
Redes de Computadores
Capítulo 3: Capa de Transporte
Escuelas: Ingeniería Electrónica y Telecomunicaciones

Semestre: Marzo 2018 – Agosto 2018
Docente: Santiago González Martínez
santiago.gonzalezm@ucuenca.edu.ec
Cuenca - Ecuador
Bibliography
A note on the use of these ppt slides:

We’re making these slides freely available to all (faculty, students, readers). Computer
They’re in PowerPoint form so you see the animations; and can add, modify,
and delete slides (including this one) and slide content to suit your needs. Networking: A Top
They obviously represent a lot of work on our part. In return for use, we only
ask the following: Down Approach
 If you use these slides (e.g., in a class) that you mention their source
(after all, we’d like people to use our book!)
6th edition
 If you post any slides on a www site, that you note that they are adapted Jim Kurose, Keith Ross
from (or perhaps identical to) our slides, and note our copyright of this
material.
Addison-Wesley
March 2012
Thanks and enjoy! JFK/KWR
All material copyright 1996-2012

J.F Kurose and K.W. Ross, All Rights Reserved
Sesión 13
3.1 Servicios de la Capa de Transporte
3.2 Multiplexación y Demultiplexación
3.3 Transporte no orientado a la conexión: UDP
Capítulo 3 – Sesión 13
Sesión 13
Capa de Transporte: Servicios y Protocolos
application
 Permite una comunicación lógica transport
network
entre procesos (aplicaciones) data link
physical
que se ejecutan en diferentes
hosts
 Los protocolos de transporte se
ejecutan en los sistemas finales
(end systems)
 Transmisor: Divide los mensajes
generados por las aplicaciones en
segmentos, los cuales se envían a la
capa de red application
transport
 Receptor: Reensambla los segmentos network
en mensajes y los envía a la capa de data link
physical
aplicación
 En cuanto a protocolos de
transporte existen dos opciones
 Internet: TCP y UDP Capítulo 3 – Sesión 13
Capa de Transporte vs. Capa de Red
Capa de Red: Analogía:

 Comunicación lógica entre A envía desde su casa una
hosts carta a la dirección de la casa
de B, mediante correo postal
Capa de Transporte:
 Comunicación lógica entre
procesos
 Depende o confía en los procesos y
mejoras que se implemente en los
servicios de la capa de red
A B

Capa de Transporte:
 Comunicación lógica entre Hosts = Casas (end systems)
procesos
Casa de A Casa de
B Capítulo 3 – Sesión 13

Capa de Transporte:
 Comunicación lógica entre Procesos = Escribir carta, leer
procesos carta

A B

Capa de Transporte:
 Comunicación lógica entre Mensaje = Carta en el sobre
procesos
A Mensaje B

Capa de Transporte:
 Comunicación lógica entre Protocolo de Transporte = A y
procesos B
(establecen comunicación
 Depende o confía en los procesos y desde sus ubicaciones)
A B

Capa de Transporte:
 Comunicación lógica entre Protocolo de Red = Servicio
procesos postal

A B
Protocolos de Transporte en Internet
application
 Transferencia fiable y en transport
network
orden (TCP) data link
physical
network
network data link
 Control de congestión data link physical
physical
 Control de flujo network
data link
 Establecimiento de conexión physical
network
data link
 Transferencia no fiable y no physical
network
ordenada (UDP) data link
physical
network
data link
 Servicio de máximo esfuerzo (best physical
application
transport
effort) network
data link network
data link
Servicios no disponibles
physical
physical

 Garantías de retardos
 Garantías de ancho de banda
Sesión 13
¿Como Trabaja la Mux/Demux?
 Los host reciben datagramas IP 32 bits
 Cada datagrama tiene una dirección IP source port # dest port #

orígen y una dirección IP destino
 Cada datagrama lleva un segmento other header fields
generado por la capa de transporte
 Cada segmento tiene un número de
puerto de orígen y destino
application
 Los host emplean las direcciónes IP data
y los números de puerto para enviar (payload)
un segmento al socket apropiado
TCP/UDP segment format
Mux/Demux sin Conexión (UDP)
 Recuerde: Para crear un socket  Cuando se crea un datagrama
se le debe asignar un número que emplea UDP, se debe
de puerto en el host local especificar
DatagramSocket mySocket1  destination IP address
= new
DatagramSocket(12534);  destination port #
 Cuando un host recibe un Los datagramas IP con el

segmento UDP mismo número de puerto
de destino, pero diferentes
 Chequea el número de puerto de direcciones IP y/o puertos
destino
 Direcciona o envía el segmento al
de orígen, serán enviados al
socket con ese número de puerto  mismo socket de destino
Ejemplo: Mux/Demux sin Conexión (UDP)
DatagramSocket
DatagramSocket serverSocket = new
DatagramSocket DatagramSocket
mySocket2 = new mySocket1 = new
DatagramSocket (6428); DatagramSocket
(9157); application
(5775);
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical
source port: 6428 source port: 6428

dest port: 9157 dest port: 5775
source port: 9157 source port: 5775

dest port: 6428 dest port: 6428
Mux/Demux con Conexión (TCP)
 Un socket TCP está definido  La comunicación puede soportar
por cuatro elementos multiples conexiones TCP
simultáneas
 source IP address
 Donde cada socket está identificado
 source port number por sus cuatro elementos
 dest IP address
 dest port number
 Los servidores web tienen
diferentes sockets para cada
 Demux: El receptor emplea los cliente
cuatro elementos para
direccionar un segmento al  HTTP no persistente: emplea diferentes
socket apropiado sockets para cada request
Ejemplo: Mux/Demux con Conexión (TCP)
application
application P4 P5 P6 application
P3 P2 P3
transport
transport transport
network
link physical link
physical server: IP physical
address B
host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
application
P3 P2 P3
transport
transport transport
network
link physical link
address B

dest IP,port: B,80
dest IP, port: B,80
dest IP,port: B,80
application
P3 P2 P3
transport
transport transport
network
link physical link
address B

dest IP,port: B,80
dest IP, port: B,80
dest IP,port: B,80
application
P3 P2 P3
transport
transport transport
network
link physical link
address B

dest IP,port: B,80
dest IP, port: B,80
dest IP,port: B,80
Ejemplo:Mux/Demux con Conexión (TCP)
application
P3 P2 P3
transport
transport transport
network
link physical link
address B

dest IP,port: B,80
dest IP, port: B,80
dest IP,port: B,80
application
P3 P2 P3
transport
transport transport
network
link physical link
address B

dest IP,port: B,80
dest IP, port: B,80
dest IP,port: B,80
three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets Capítulo 3 – Sesión 13
Gestionado por la aplicación
application
P4
P3 P2 P3
transport
transport transport
network
link physical link
address B

dest IP,port: B,80
dest IP, port: B,80
dest IP,port: B,80
Sesión 13
UDP: User Datagram Protocol [RFC 768]
 Servicio de máximo esfuerzo  UDP aplicaciones:
(best effort), los segmentos
UDP pueden  streaming multimedia apps (loss
tolerant, rate sensitive)
 Perderse  DNS
 Enviarse en desorden
 SNMP
 No orientado a la conexión  ¿Transferencia fiable mediante

 No handshaking entre el
UDP?
transmisor UDP y el receptor
UDP  Agregar fiabilidad en la capa de
 Cada segmento UDP es manejado aplicación
independientemente de los otros  Mecanismos de recuperación de
segmentos errores en la capa de aplicación
UDP: Segment header
length, in bytes of
32 bits UDP segment,
source port # dest port # including header
length checksum Por qué usar UDP?

 No require establecimiento de
conexión (menor retardo)
application
 Diseño simple: No se mantiene el
data
estado de la conexión entre el
(payload)
transmisor y receptor
 Menor tamaño de headers
 No tiene mecanismos de control
UDP segment format de congestion (por tanto la
información se envía tan rápido
como se desee y sea posible)
UDP: Segment header
length, in bytes of
32 bits UDP segment,
source port # dest port # including header
length checksum Por qué usar UDP?

 No require establecimiento de
conexión (menor retardo)
application
 Diseño simple: No se mantiene el
data
estado de la conexión entre el
(payload)
transmisor y receptor
 Menor tamaño de headers
 No tiene mecanismos de control
UDP segment format de congestion (por tanto la
información se envía tan rápido
como se desee y sea posible)
UDP Checksum
Una suma de verificación, (también llamada suma de
chequeo o checksum), en telecomunicación e informática,
es una función que tiene como propósito principal
detectar cambios accidentales en una secuencia de datos
para proteger la integridad de estos, verificando que
no haya discrepancias entre los valores obtenidos al
hacer una comprobación inicial y otra final tras la
transmisión
¿Qué es una función

HASH?
UDP Checksum
Objetivo: Detectar errores en los segmentos transmitidos
Transmisor:
 Toma el contenido de los
segmentos, incluyendo el header
como secuencias de 16 bits
 Checksum: Realiza la suma de
las secuencias de 16 bits y al
final calcula el complemento a1
de la suma, este valor es el
checksum
 Incluye el valor obtenido en el
campo denominado checksum
UDP Checksum
Objetivo: Detectar errores en los segmentos transmitidos
Transmisor: Receptor:
 Toma el contenido de los  Calcula el valor del checksum
segmentos, incluyendo el header para el segmento recibido
como secuencias de 16 bits  Verifica si el checksum calculado
 Checksum: Realiza la suma de es igual al valor que se encuentra
las secuencias de 16 bits y al en el campo correspondiente
final calcula el complemento a1 (checksum field)
de la suma, este valor es el
checksum NO – Error detectado
 Incluye el valor obtenido en el YES – No se ha detectado
campo denominado checksum
errores
Internet Checksum: Ejemplo
Ejemplo: Suma dos secuencias de 16-bit
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
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
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
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 se
suma al resultado 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
Nota. Durante la suma si existen acarreos, este se suma 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
Acarreo se
sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
1

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
Acarreo se
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
(Complemento a1)

resultado
Análisis UDP
 Configuración de un servidor de video streaming empleando VLC
Análisis UDP/Wireshark
 Instalar VLC en un dos ordenadores e iniciar el programa en el
ordenador que cumple la función de servidor de video streaming y en el
cliente
 En el servidor seleccionar Medio/emitir
 A continuación, mediante la opción añadir, seleccionar el archivo
de video a emitir
 Selccionamos emitir y a continuación siguiente
 En el menú archivo, seleccionamos el protocolo RTP/MPEG
Transport Stream y a continuación seleccionamos añadir
 En el menú archivo, seleccionamo el protocolo RTP/MPEG
Transport Stream y a continuación seleccionamos añadir
RTP (Real Time Protocol,

RFC 3550): Es un protocolo
de capa de aplicación para
el envío de información
multimedia y emplea UDP como
protocolo de transporte
¿Qúe es DASH?
¿Qué es HLS?
 Especificamos la IP/Puerto del ordenador cliente hacia donde
transmitiremos el video (puerto por defecto 5004). Además es
conveniente asignar un nombre de la Emisión
 Seleccionamos siguiente (Opciones adicionales de codificación)
 En este punto, el servidor está listo para emitir. Antes de
seleccionar emitir, vamos a configurar el lado del cliente
 En el cliente vamos la opción ver/lista de reproducción
 A continuación seleccionamos la opción emisiones de red.
 En el lado del servidor seleccionamos la opción emitir y en el
cliente aparecerá el nombre de la emisión que está transmitiendo
el servidor
 Hacemos doble clik sobre la emisión disponible (Video) y el vídeo
iniciará
 Si durante el proceso ejecutamos wireshark ya sea en el lado del
cliente o el servidor y aplicamos los filtros adecuados, podemos
capturar los paquetes UDP
Práctica 6
o Tema:
Configuración de un Servidor de Video Streaming RTP y
Análisis del Protocolo de Transporte UDP con Wireshark
o Materiales:
o Dos ordenadores con Sistema Operativo Linux (Preferencia) o Windows
o Software VLC, Wireshark
o Archivo de video.mp4
o Objetivo Principal:
o Implementar un servidor de video streaming básico que emplee como protocolo de
transporte UDP
o Objetivos Específicos:
o Configurar un servidor de streaming empleando la aplicación VLC
o Emplear la aplicación wireshark para la captura y análisis de paquetes UDP
Práctica 6
o Tema:
o Instrucciones generales
1. Conforma grupos de dos personas
2. Seguir los pasos descritos previamente para la configuración del
servidor de video streaming y captura de paquetes UDP
3. Realizar un análisis de la operación del protocolo UDP a través
de los paquetes capturados
4. Emitir de forma simultánea el video tanto en el cliente como
en el servidor y a continuación realice una valoración subjetiva de
la calidad del video obtenida en el cliente
5. Analice y determine un mecanismo para verificar si existe
pérdida de paquetes durante la transmisión del video
Práctica 6
o Tema:
Fecha Máxima de Entrega del Reporte: Lunes 30 de Abril del 2018, (18h00)
Formato: pdf. (Apellidos-P6-RC.pdf) a través del evirtual
Sesión 14
3.4 Principios de la Transmisión Fiable de Datos
Principios:Transmisión Fiable de Datos
 El desafío de la transferencia fiable
de datos no es exclusivo de la capa
de transporte.
 Es uno de los principales objetivos
de la arquitectura de la red (capas)
 Para iniciar nuestro estudio se
considerará el esquema de la figura,
donde las capas superiores
proporciona un servicio de
abstracción acerca de la existencia
de un canal confiable para el envío
de datos
 Dicho modelo de abstracción es el
que proporciona TCP en Internet
para las aplicaciones
 Es responsabilidad de un protocolo
fiable de transferencia de datos
implementar dicho servicio de
abstracción
 No obstante esta tarea es compleja,
debido a que las capas bajo un
protocolo fiable pueden ser no
fiables
 Por ejemplo TCP es un protocolo
fiable (rdt, reliable data transfer)
que está implementado sobre una
capa no fiable (capa de Red, IP)
 Para el estudio se considera por
tanto las capas inferiores como no
fiables
 Es responsabilidad de un protocolo
fiable de transferencia de datos
implementar dicho servicio de
abstracción
 No obstante esta tarea es compleja,
debido a que las capas bajo un
protocolo fiable pueden ser no
fiables
 Por ejemplo TCP es un protocolo
fiable (rdt, reliable data transfer) que
está implementado sobre una capa
no fiable (capa de Red, IP)
 Para el estudio se considera por
tanto las capas inferiores como no
fiables
Diseñando un Protocolo RDT (Realiable Data Transfer)
A continuación se describirá las características deseadas para un
protocolo tipo rdt, considerando gradualmente la complejidad que
ocasiona el canal subyacente (unreliable chanel)
Aplicación
Transporte
Capas
inferiores
(Red, Enlace
de datos,
Física)
Aplicación
Transporte
Capas
inferiores
(Red, Enlace
de datos,
Física)
Aplicación Definir Interfaces

Para el Protocolo
rdt
Transporte
Capas
inferiores
(Red, Enlace
de datos,
Física)
Aplicación Definir Interfaces

Para el Protocolo
rdt
Transporte
Capas
inferiores
(Red, Enlace
de datos,
Física)
Aplicación rdt_send(): Empleada por

la capa de aplicación.
Pasa los datos al
Transmisor para su envío
fiable al host Receptor
Transporte
Capas
inferiores
(Red, Enlace
de datos,
Física)
Aplicación
Transporte
udt_send(): Invocado por
el rdt, usualmente para
Capas el envío de mensajes de
inferiores control sobre el canal
(Red, Enlace
de datos,
Física)
Aplicación
rdt_rcv(): Invocado
cuando la información
llega al host receptor
Transporte
Capas
inferiores
(Red, Enlace
de datos,
Física)
Aplicación
Transporte
deliver_data(): Invocado
Capas por el rdt para pasar
inferiores los datos a la capa de
(Red, Enlace aplicación del host
de datos,
Física) receptor
Consideraciones del análisis:
 Se desarrollará gradualmente la operación del protocol rtd

 Se considerará el caso de una comunicación unidireccional
 Sin embargo se emplearán mensajes de control en ambas direcciones
 Se empleará modelos de máquina de estados para describir al

transmisor y al receptor (FMS, Finite State Machines)
Transferencia Fiable sobre un Canal Fiable
Canal con Errores de Bits (Bits en desorden)
Canal con Errores y Pérdidas (Bits en desorden y pérdida de datos)
rdt1.0: Transferencia Fiable sobre un Canal Fiable
 Canal subyacente perfectamente fiable

 No existen errores en los bits
 No se producen pérdida de paquetes
 Modelo FSM independiente para el Tx y el Rx
 El transmisor envía los datos hacia el canal subyacente
 El receptor lee los datos desde el canal subyacente
Wait for rdt_send(data) Wait for rdt_rcv(packet)

call from call from extract (packet,data)
above packet = make_pkt(data) below deliver_data(data)
udt_send(packet)
sender receiver

 No existen errores en los bits

udt_send(packet)
sender receiver

 No existen errorers en los bits

udt_send(packet)
sender receiver

 No existen errorers en los bits

udt_send(packet)
sender receiver
Diseñando un Protocolo RTD (Realiable Data Transfer)
rdt2.0: Canal con Errores de Bits
 El canal subyacente ocasiona errores en los bits de
un paquete (por ejemplo: los bits llegan en desorden)
 Checksum: Permite detectar los errores
¿Cómo se puede recuperar tales errores?
 acknowledgements (ACKs): receiver explicitly tells sender
that pkt received OK
¿Cómo hacen
 negative las personas(NAKs):
acknowledgements parareceiver
recuperar “errores”
explicitly tells
sender that pkt had errors
Durantepktuna
 sender retransmits conversación?
on receipt of NAK
 new mechanisms in rdt2.0 (beyond rdt1.0):
 error detection
 receiver feedback: control msgs (ACK,NAK) rcvr->sender
un paquete (por ejemplo: desordenar los bits)
 checksum Permite detector los errores
 Acknowledgements (ACKs): El Rx le indica explícitamente

al Tx que un paquete llegó correctamente OK
 Negative Acknowledgements (NAKs): El Rx le indica al Tx

que un paquete presenta errores y a continuación el Tx
retransmite el paquete
un paquete (por ejemplo: desordenar los bits)
 checksum Permite detector los errores
Nuevos mecanismos en rdt2.0 (mejora rdt1.0):

 Detección de errores (checksum)
 Rx retroalimentación: Mensajes de control
(ACK,NAK) Rx  Tx
rdt2.0: Modelo FSM
rdt_send(data)
sndpkt = make_pkt(data, checksum) receiver
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L
call from
sender below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt2.0: Modelo FSM
rdt_send(data)
sndpkt = make_pkt(data, checksum) receiver
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
above NAK
udt_send(NAK)

Wait for
L
call from
sender below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
rdt2.0: Ejemplo Operación sin Errores
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
above NAK
udt_send(NAK)

Wait for
L call from
below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
rdt2.0: Ejemplo Operación con Errores
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
above NAK
udt_send(NAK)

Wait for
L call from
below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
rdt2.0: Fallas
¿Qué ocurre si los
mensaje ACK/NACK
se corrompen?
 Tx no conocerá que
ocurrió en recepción
rdt2.0: Fallas
¿Qué ocurre si los mensaje
ACK/NACK se corrompen?
 Tx no conocerá que ocurrió en
recepción
 Posibles soluciones:
 Checksum en los mensajes ACK
para detectar errores
rdt2.0: Fallas
mensaje ACK/NACK
se corrompen?
 Tx no conocerá que
ocurrió en recepción
 Posibles soluciones:
 Retransmitir el paquete
rdt2.0: Fallas
mensaje ACK/NACK
se corrompen?
 Tx no conocerá que El receptor no conoce si
ocurrió en recepción el paquete enviado es una
 Posibles soluciones: retransmisión o es
 Retransmitir el paquete información nueva, por
tanto puede dar lugar a
paquetes duplicados
rdt2.0: Solución  rdt2.1
mensaje ACK/NACK
se corrompen? rdt2.1
 Tx no conocerá que Añadir un número de
ocurrió en recepción secuencia a cada paquete,
 Posibles soluciones: de esta forma el receptor
 Retransmitir el paquete descartará un paquete si
detecta que es un
duplicado
rdt2.1: Modelo FSM del Transmisor
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK or
isNAK(rcvpkt) )
call 0 from
NAK 0 udt_send(sndpkt)
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
L
L
Wait for Wait for
ACK or call 1 from
rdt_rcv(rcvpkt) && NAK 1 above
isNAK(rcvpkt) ) rdt_send(data)
udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)
rdt_send(data)
Wait for Wait for
ACK or
isNAK(rcvpkt) )
call 0 from
above
rdt_rcv(rcvpkt)
&& isACK(rcvpkt)
L
L
Wait for Wait for
ACK or call 1 from

udt_send(sndpkt)
rdt_send(data)
Wait for Wait for
ACK or
isNAK(rcvpkt) )
call 0 from
above
rdt_rcv(rcvpkt)
&& isACK(rcvpkt)
L
L
Wait for Wait for
ACK or call 1 from

udt_send(sndpkt)
rdt_send(data)
Wait for Wait for
ACK or
isNAK(rcvpkt) )
call 0 from
above
rdt_rcv(rcvpkt)
&& isACK(rcvpkt)
L
L
Wait for Wait for
ACK or call 1 from

udt_send(sndpkt)
rdt_send(data)
Wait for Wait for
ACK or
isNAK(rcvpkt) )
call 0 from
above
rdt_rcv(rcvpkt)
&& isACK(rcvpkt)
L
L
Wait for Wait for
ACK or call 1 from

udt_send(sndpkt)
rdt2.1: Modelo FSM del Receptor
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Wait for Wait for
rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && below below not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
&& has_seq1(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
Wait for Wait for
&& has_seq1(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
Wait for Wait for
&& has_seq1(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
Wait for Wait for
&& has_seq1(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
Wait for Wait for
&& has_seq1(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
Wait for Wait for
&& has_seq1(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
Wait for Wait for
&& has_seq1(rcvpkt)
Envía el ACK, pero
extract(rcvpkt,data) descarta el paquete si
deliver_data(data) está duplicado
udt_send(sndpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
Wait for Wait for
&& has_seq1(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
&& has_seq0(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
Wait for Wait for
&& has_seq1(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
rdt2.2: Protocolo sin NAK
 Funcionalidad similar a rtd2.1, empleando únicamente ACKs
 Rx incluye el número de secuencia de un paquete en el mensaje

ACK
 En este caso si el Tx recibe un ACK duplicado resulta en la

misma acción que un NAK es decir retransmite el paquete
Canal con Errores y Pérdidas
Nuevas condiciones:
El canal subyacente puede
ocasionar tanto errores
como pérdidas en los
paquetes (datos, ACKs)
 En este caso los mecanismos
anteriores (checksum,
números de secuencia, ACKs,
retransmisiones) no son
suficiente
rdt3.0: Canal con Errores y Pérdidas
Nuevas condiciones: Enfoque: El transmisor espera un
El canal subyacente puede tiempo “razonable” por un ACK
ocasionar tanto errores  Retransmite el paquete si no recibe
como pérdidas en los un ACK en ese tiempo
paquetes (datos, ACKs)  Si el paquete (o el ACK)
 En este caso los mecanismos experimenta un retardo (no
anteriores (checksum, pérdida)
números de secuencia, ACKs,  La retransmisión generará un
retransmisiones) no son duplicado, pero este inconveniente
suficiente será manejado a través de los
números de secuencia
 Receptor tiene que especificar el
número de secuencia de un
paquete en el ACK
 Requiere un Contador (timer)
rdt3.0: Operación
sender receiver sender receiver
send pkt0 pkt0 send pkt0 pkt0
rcv pkt0 rcv pkt0
ack0 send ack0 ack0 send ack0
rcv ack0 rcv ack0
send pkt1 pkt1 send pkt1 pkt1
rcv pkt1 X
ack1 send ack1 loss
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout
ack0 send ack0 resend pkt1 pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) no loss rcv pkt0
ack0 send ack0
(b) packet loss

rdt3.0: Operación
sender receiver
sender receiver send pkt0 pkt0
send pkt0 pkt0 rcv pkt0
send ack0
rcv pkt0 ack0
send ack0 rcv ack0
ack0 send pkt1 pkt1
rcv ack0 rcv pkt1
send pkt1 pkt1
send ack1
rcv pkt1 ack1
ack1 send ack1
X
loss timeout
resend pkt1 pkt1
rcv pkt1
timeout
resend pkt1 pkt1 rcv ack1 (detect duplicate)
rcv pkt1 send pkt0
pkt0
send ack1
(detect duplicate) ack1
ack1 send ack1 rcv ack1 rcv pkt0
rcv ack1 send pkt0
ack0 send ack0
send pkt0 pkt0 pkt0
rcv pkt0
rcv pkt0 ack0 (detect duplicate)
ack0 send ack0 send ack0
(c) ACK loss (d) premature timeout/ delayed ACK
Sesión 15
(Continuación….)
3.5 Transporte Orientado a la Conexión: TCP

 Estructura de los Segmentos
 Transferencia Fiable de Datos
 Control de Flujo
 Gestión de la Conexión
Sesión 15
(Continuación….)

Evaluación de rdt3.0
 El diseño de rtd3.0, es adecuado, pero
¿Cuál es su efecto en la red?
8000 bits x
paquete
8000 bits x
paquete
Dprop=15ms
8000 bits x
paquete
Dprop=15ms
Se requiere esperar un ACK para

transmitir el próximo paquete!!!
8000 bits x
paquete
Dprop=15ms
RTT30ms
Tiempo que tarda la
transmisión de un
paquete (debido a la
espera por un ACK) 8000 bits x
paquete
Dprop=15ms
RTT30ms
Tiempo que tarda la
transmisión de un
paquete (debido a la
espera por un ACK) 8000 bits x
paquete
Dprop=15ms Velocidad a la
RTT30ms que se inyectan
paquetes en el
enlace
L 8000 bits
Dtrans = R = = 8 microsecs
109 bits/sec
8000 bits x
paquete
Dprop=15ms
RTT30ms
RTT + L/R = 30.008ms, es decir que el Tx

ocupa 0.008ms del tiempo total (30.008) en
inyectar los paquetes en el enlace
8000 bits x
paquete
Dprop=15ms
RTT30ms
Es decir el throughput efectivo es tan

8000𝑏𝑖𝑡𝑠
solo de: = 265957𝑏𝑝𝑠266𝐾𝑏𝑝𝑠 , de
0.03008𝑠
un enlace de 1Gbps
8000 bits x
paquete
Dprop=15ms
RTT30ms
¡El protocolo limita el uso de los recursos de la red!
Es decir el throughput efectivo es tan solo de:
8000𝑏𝑖𝑡𝑠
= 265957𝑏𝑝𝑠266𝐾𝑏𝑝𝑠, de un enlace de 1Gbps
0.03008𝑠
Protocolo Tipo “Pipeline”
Para mejorar el uso de los recursos de la red, una
solución consiste en permitir al Tx enviar conjuntos de
paquetes antes de tener que esperar por los mensajes
ACK. Esta técnica se denomina pipeline (tubería)
Para mejorar el uso de los recursos de la red, una solución
consiste en permitir al Tx enviar conjuntos de paquetes
antes de tener que esperar por los mensajes ACK. Esta
técnica se denomina pipeline (tubería o canalización
Mejora el uso de los
recursos en un factor
igual al número de
paquetes enviados
antes de esperar los
ack
 Existen dos variantes de protocolos pipeline

 go-Back-N,
 selective repeat
Para mejorar el uso de los recursos de la red, una solución
consiste en permitir al Tx enviar conjuntos de paquetes
antes de tener que esperar por los mensajes ACK. Esta
técnica se denomina pipeline (tubería o canalización)
Mejora el uso de los
recursos en un factor
igual al número de
paquetes enviados
antes de esperar los
ack
 ¿Investigar
Existen dos variantes de protocolos algunas
pipeline
 go-Back-N, características de las dos
 selective repeat variantes?
Protocolos Tipo “Pipeline”
Sesión 15
(Continuación….)

Sesión 15
(Continuación….)

Estructura de los segmentos TCP
32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UAP R S F receive window
(generally not used) # bytes
checksum Urg data pointer
rcvr willing
RST, SYN, FIN: to accept
options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)
TCP seq. numbers, ACKs
outgoing segment from sender
Sequence Numbers: source port # dest port #
 Los mensajes se dividen en sequence number
segmentos acknowledgement number
 El número de segmentos depende checksum

rwnd
urg pointer
de la longitud total del mensaje y
el tamaño máximo de un window size
N
segmento (Maximun Segment
Size, MSS)
 TCP numera implícitamente la
cantidad de bytes en un segmento
y le asigna al segmento el número
del primer byte
Mensaje : 500.000 bytes

MSS: 1000 bytes
Número de segmentos: 500
Cumulative ACK
Primer Segmento: 0 (Num Secuencia)
Segundo Segmento 1000 (Num Secuencia)
Tercer Segmento 2000 (Num Secuencia)
TCP seq. numbers, ACKs
Acknowledgements Number: sender sequence number space
sent sent, not- usable not

 Número de secuencia del ACKed yet ACKed but not usable
próximo segmento esperado (“in- yet sent
flight”)
 Cumulative ACK incoming segment to sender
source port # dest port #
Continuando con el ejemplo anterior, sequence number
acknowledgement number
si un Host A recibe el segmento 0 A rwnd
(bytes 0 – 999). A continuación checksum urg pointer
esperará por el segmento numerado

como 1000 y por tanto incluirá éste
valor como acknowledgement number
TCP Round Trip Time, Timeout
¿Como define TCP el valor de
espera antes de un
retransmisión (timeout)?
¿Como define TCP el valor de ¿Cómo se estima el RTT?
espera antes de un
retransmisión (timeout)?  SampleRTT: Medir el tiempo
 El valor debe ser mayor al RTT desde la transmisión de un
 RTT puede variar segmento hasta la recepción
de un ACK
 Espera muy corta: ocasiona un
 SampleRTT: Para mayor
timeout prematuro
precisión se realiza un
retransmisión innecesaria promedio de varias
 Espera muy larga: reacción mediciones recientes para
lenta ante la pérdida de obtener el valor RTT
segmentos  TCP timers [RFC 6298]
TCP timers [RFC 6298]
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
 typical value:  = 0.125 RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

RTT (milliseconds)
300
250
RTT (milliseconds)
200
sampleRTT
150
EstimatedRTT
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
time (seconds) Capítulo 3 – Sesión 15
SampleRTT Estimated RTT
Sesión 15
(Continuación….)

TCP:Transferencia Fiable de Datos (RDT)
Host A Host B
 TCP proporciona un servicio
rdt sobre una capa de red no
fiable (IP)
Seq=92, 8 bytes of data
 Segmentos tipo Pipelined
timeout
 Cumulative ACKs ACK=100
X
 Timer para retransmisiones
 Las retransmisión se generan
Seq=92, 8 bytes of data
debido:
 Timeouts
ACK=100
 ACKs duplicados
lost ACK scenario

Sesión 15
(Continuación….)

TCP: Control de Flujo
application
application may process
remove data from application
TCP socket buffers ….
TCP socket OS
receiver buffers
… slower than TCP
receiver is delivering
(sender is sending) TCP
code
Control de Flujo IP
code
El receptor controla al
transmisor, de esta forma
from sender
el transmisor no puede
sobrecargar al receptor Receiver Protocol Stack
con exceso de datos
application
application may process
remove data from application
TCP socket buffers ….
source port # dest port # TCP socket OS
sequence number receiver buffers
acknowledgement number … slower than TCP
rwnd receiver is delivering
checksum urg pointer (sender is sending) TCP
code
rwnd
Control de Flujo IP
code
Receptor controla al
transmisor, de esta forma
from sender
el transmisor no puede
sobrecargar al receptor Receiver Protocol Stack
con exceso de datos
 El receptor advierte acerca
to application process
del espacio libre en el buffer
a través del campo rwnd
RcvBuffer buffered data
 RcvBuffer Este valor se
configura durante la
programación de un socket
rwnd free buffer space
(default 4096 bytes)
 Los sistemas operativos TCP segment payloads
usualmente realizan un
ajuste automático del buffer receiver-side buffering
 El transmisor limita la
cantidad de datos acorde al
valor rwnd recibido
Sesión 15
(Continuación….)

Gestión de la Conexión
Antes del intercambio de datos se lleva a cabo el
“handshake” entre el Tx y el Rx:
 Acuerdo para establecer la comunicación (identificación)
 Acuerdo acerca de los parámetros para la comunicación
connection state: ESTAB connection state: ESTAB

connection variables: connection Variables:
seq # client-to-server seq # client-to-server
server-to-client server-to-client
rcvBuffer size rcvBuffer size
at server,client at server,client
network network
Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");
Gestión de la Conexión
Antes del intercambio de datos se lleva a cabo el
“handshake” entre el Tx y el Rx:
 Acuerdo para establecer la comunicación (identificación)
 Acuerdo acerca de los parámetros para la comunicación
connection state: ESTAB connection state: ESTAB

connection variables: connection Variables:
seq # client-to-server seq # client-to-server
server-to-client server-to-client
rcvBuffer size rcvBuffer size
at server,client at server,client
network network
Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");
TCP 3-way handshake
client state Primer Paso server state

LISTEN LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT SYNbit=1, Seq=x
SYN RCVD
ESTAB
ESTAB
TCP 3-way handshake
client state Primer Paso server state

LISTEN LISTEN
send TCP SYN msg
choose init seq num, y
send TCP SYNACK
• El cliente TCP envía un segmento msg,
TCPacking SYN
especial SYN RCVD
hacia
SYNbit=1, Seq=y
el servidor TCP ACKbit=1; ACKnum=x+1
• Este segmento
received SYNACK(x)no contiene datos (capa de aplicación)
indicates server is live;
•ESTAB
Camposend
SYN esSYNACK;
ACK for configurado a 1 (Segmento SYN)
• El thiscliente
segment may contain
escoge
client-to-server data
ACKbit=1, ACKnum=y+1
aleatoriamente un número de
secuencia por razones de seguridadreceived ACK(y)
(client_isn),
indicates client is live
• Finalmente el segmento es enviado al servidor TCPESTAB
TCP 3-way handshake
client state server state

LISTEN LISTEN
send TCP SYN msg
Segundo Paso
send TCP SYNACK
msg, acking SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
ESTAB
ESTAB
TCP 3-way handshake

LISTEN LISTEN
send TCP SYN msg
Segundo Paso
send TCP SYNACK
SYNbit=1, Seq=y
received SYNACK(x)
ESTAB indicates server is live;
send ACK for SYNACK;
• El servidor extrae
this segment may contain el ACKbit=1,
segmento TCPSYN del datagrama
ACKnum=y+1
• Realiza client-to-server
una reserva data de recursos para la conexión (buffer)
received ACK(y)
• Envía un segmento al cliente indicando indicates client
queis liveacepta la
ESTAB
conexión (SYNACK)
• Este segmento no contiene datos (capa de aplicación)
TCP 3-way handshake

LISTEN LISTEN
send TCP SYN msg
Segundo Paso
send TCP SYNACK
SYNbit=1, Seq=y
received SYNACK(x)
• SYN=1this send ACK for SYNACK;
segment may contain ACKbit=1, ACKnum=y+1
• client-to-servernumber=cliente_isn
Acknowledgement data
received ACK(y) + 1
• Finalmente el servidor selecciona aleatoriamente
indicates client is live un número
ESTAB
de secuencia (server_isn) e incluye este valor en el campo
sequence number
TCP 3-way handshake

LISTEN LISTEN
send TCP SYN msg
send TCP SYNACK
Tercer Paso SYNbit=1, Seq=y
received SYNACK(x)
this segment may contain ACKbit=1, ACKnum=y+1
received ACK(y)
ESTAB
TCP 3-way handshake
• El cliente recibe el SYNACK, a continuación reserva los
recursos para la conexión (buffer)
• El cliente envía un último segmento al servidor confirmando la
LISTEN
conexión LISTEN
• Se incluye sendunTCPACK con número de secuencia= server_isn + 1.
SYN msg
•SYNSENT
SYN = 0 SYNbit=1, Seq=x
• Este segmento ya puede incluir datos generados choose initpor la ycapa de
seq num,
aplicación send TCP SYNACK
received SYNACK(x)
received ACK(y)
ESTAB
TCP 3-way handshake

LISTEN LISTEN
send TCP SYN msg
send TCP SYNACK
received SYNACK(x)
received ACK(y)
ESTAB
TCP 3-way handshake

LISTEN LISTEN
send TCP SYN msg
send TCP SYNACK
received SYNACK(x)
received ACK(y)
Debido a que el proceso de establecimientoESTAB indicates client is live
de la conexión, se realiza mediante el

intercambio de tres segmentos, se denomina
3-WAY HANDSHAKE
TCP: Finalización de la Conexión
 El cliente envía un segmento con el campo
FIN=1 hacia el servidor (Fase 1 de
finalización)
 El cliente espera por un ACK del servidor
 Cuando recibe el ACK, el cliente inicia la
etapa 2 de finalización de la conexión
 En la etapa 2, el cliente espera por un
segmento del servidor con el bit FIN=1
 Una vez recibido dicho segmento, envía un
ACK al servidor e inicia un proceso de
espera (durante este tiempo se puede
reenviar el ACK en caso de pérdida)
 Finalmente, pasado el tiempo de espera
(30s, 1min, 2min), la conexión finaliza
Sesión 16
3.6 Principios del Control de Congestión
3.7 Control de Congestión en TCP
Sesión 16
Principios del Control de Congestión
Congestión:
 Demasiadas fuentes de datos, enviando gran cantidad de
información a una tasa alta, que impide la gestión
adecuada de la información en la red
 Consecuencias
 Pérdida de paquetes
 Incremento significativo del retardo (delay)
Congestión Causas/Efectos: Escenario 1
original data: lin throughput: lout
Host A
unlimited shared
output link buffers
Host B
Host A
unlimited shared
output link buffers
Host B
l  tasa de datos (bytes/sec)

(Generado por la capa de aplicación)
 2 Tx – 2 Rx
 1 Router (buffer infinito) Host A
 Capacidad del enlace: R unlimited shared

output link buffers
 No existen retransmisiones
Host B
l  tasa de datos (bytes/sec)

 2 Tx – 2 Rx

output link buffers
Host B
R/2
lout
lin R/2
 Throughput máximo por

conexión: R/2

 2 Tx – 2 Rx

output link buffers
Host B
R/2
delay
lout
lin R/2 lin R/2

 Throughput máximo por  Conforme alcanzamos la tasa
conexión: R/2 máxima de ingreso, el retardo se
incrementa en la red
lin : original data

lout
l'in: original data, plus
retransmitted data
Host A
finite shared output

Host B
link buffers
 1 Router, buffer finito
 Mecanismo de retransmisión (Tx) luego de un timeout
 application-layer input = application-layer output: lin = lout
 transport-layer input includes retransmissions : l‘in ≥ lin
lin : original data

lout
retransmitted data
Host A

Host B
link buffers
R/2
Comportamiento ideal
lout
 El Tx envía datos solo cuando
existe espacio libre en el buffer
del router lin R/2
lin : original data

lout
copy l'in: original data, plus
retransmitted data
A free buffer space!

Host B
link buffers
Condiciones Realistas:
 Los paquetes pueden perderse
 Los paquetes son descartados por el router cuando no hay
espacio en el buffer
 El transmisor reenvía paquetes si conoce de la pérdida
lin : original data

lout
copy l'in: original data, plus
retransmitted data
A
no buffer space!
Host B
 Los paquetes pueden perderse
 Los paquetes son descartados por el router cuando no hay
espacio en el buffer
 El transmisor reenvía paquetes si conoce de la pérdida
lin : original data

lout
retransmitted data
A
free buffer space!
Host B
 El transmisor puede generar duplicados de paquetes debido al
timeout
l'in  lin
La cantidad de información
resultante (capa de aplicación más
capa de trasporte) es mayor a la
generada por la capa de aplicación
lin
timeout
copy l'in lout
A
free buffer space!
Host B
R/2
when sending at R/2,

some packets are
lout
retransmissions
including duplicated
that are delivered!
lin
R/2
Efectos de la Congestión:
 Incrementa significativamente el esfuerzo (retransmisiones)
en la red para un mismo “goodput”
R/2

some packets are
lout
retransmissions
that are delivered!
lin R/2
Se denomina goodput al valor del throughput a nivel de capa

de aplicación.Es decir es la tasa de datos (bytes/sec)
generada únicamente por la aplicación sin considerar el
overhead añadido por las capas inferiores
 Incrementa significativamente el esfuerzo (retransmisiones)
en la red para un mismo “goodput”
R/2

some packets are
lout
retransmissions
that are delivered!
lin R/2
Se denomina goodput al valor del throughput a nivel de capa

de aplicación.Es decir es la tasa de datos (bytes/sec)
generada únicamente por la aplicación sin considerar el
overhead añadido por las capas inferiores
 Las retransmisiones innecesarias (paquetes duplicados – timeout)
disminuyen el goodput
Enfoques para el Control de la Congestión
end-end network-feedback
 No existe una
retroalimentación explicita de
la red
 La congestion es inferida a
partir de los end systems
(hosts) acorde al delay y
pérdidas
 Enfoque empleado por TCP
 No existe una  Los routers proveen una
retroalimentación explicita de retroalimentación a los end
la red systems
 La congestion es inferida a
partir de los end systems
(hosts) acorde al delay y
pérdidas
la red systems
 Por ejemplo: Un bit que
 La congestion es inferida a indica congestión (ECN)
partir de los end systems  Indica explicitamente un
(hosts) acorde al delay y valor de tasa de envío (rate)
pérdidas al Tx
la red systems
pérdidas al Tx
ECN (Explicit Congestion Notification)

la red systems
pérdidas al Tx
Trabajo en conjunto de la capa de red y

transporte
la red systems
pérdidas al Tx
Sesión 16
TCP: Control de Congestión
Enfoque: Tx incrementa la tasa de transmisión (bit rate)
(window size) dentro del ancho de banda disponible hasta
que ocurren pérdidas
 El mecanismo de control de congestion en el Tx emplea la

variable denominada congestion window (cwnd)
 Dicha variable (cwnd), impone una restricción sobre el rate al

cual el Tx puede enviar tráfico en la red
cwnd = cantidad de bytes que envía el Tx

El proceso inicia estableciendo cwnd = 1 MSS



MSS default = 576 bytes (RFC 879)
No obstante depende de la tecnología empleada en las

capas inferiores Maximum Transmission Unit (MTU)


MSS default = 576 bytes (RFC 879)
Para Ethernet MTU = 1500 bytes

TCP: Slow Start
Host A Host B
 Una vez iniciada la conexión,
se incrementa el rate
exponencialmente hasta que
RTT
ocurra la primera pérdida
 Inicialmente cwnd = 1 MSS
 Se duplica cwnd cada RTT
 Es decir se produce el
incremento por cada ACK time
recibido
TCP: Detección y reacción a las pérdidas
bytes
cwnd
sec
time
Incremento del tamaño de la ventana
(cantidad de bytes), hasta detectar
pérdidas
bytes
Umbral detectado
cwnd
sec
time
Incremento del tamaño de la ventana,

hasta detectar pérdidas
bytes
Umbral detectado
cwnd
sec
time Reducir el tamaño de la
ventana y reiniciar el
incremento
¿A que valor se debe reducir el tamaño
de la ventana al detectar pérdidas?
¿Cómo se debe realizar el incremento de

cwnd
la ventana, posterior a una pérdida de

datos?
time
Existen Opciones  Algoritmos
TCP Tahoe: Las pérdidas se detectan mediante ACKs
duplicados o por el timeout
cwnd
time
TCP Tahoe: Una vez detectado la pérdida establece el
valor de cwnd a 1 y se reinicia el proceso
TCP Reno: Las pérdidas se detectan mediante ACKs
duplicados
cwnd
time
TCP Reno: Una vez detectada la pérdida, establece el
valor de cwnd a la mitad y a continuación inicia un
incremento lineal de la ventana cwnd Capítulo 3 – Sesión 16
¿Existen más algoritmos, para el control de
congestión con TCP? Reno
Tahoe
Vegas
Cubic
cwnd
H-TCP
Compound TCP
TCP BBR
Scalable TCP
time .
.
TCP-LP
Entre otros!!
Video Resumen: ¿Como Funciona Internet?
EVALUACIÓN CAPÍTULO 3 (5 PUNTOS)
FECHA: LUNES 30 DE ABRIL (07H00-09H00)
FACULTAD DE INGENIERÍA
Redes de Computadores
Capítulo 3: Capa de Transporte
Escuelas: Ingeniería Electrónica y Telecomunicaciones

Semestre: Marzo 2018 – Agosto 2018
Docente: Santiago González Martínez
santiago.gonzalezm@ucuenca.edu.ec
Cuenca - Ecuador

Capa de Transporte

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capa de Transporte

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA

Escuelas: Ingeniería Electrónica y Telecomunicaciones

A note on the use of these ppt slides:

All material copyright 1996-2012

3.2 Multiplexación y Demultiplexación

3.3 Transporte no orientado a la conexión: UDP

3.2 Multiplexación y Demultiplexación

3.3 Transporte no orientado a la conexión: UDP

Capa de Red: Analogía:

Capa de Red: Analogía:

Capa de Red: Analogía:

 Depende o confía en los procesos y

Capa de Red: Analogía:

Capa de Red: Analogía:

Capa de Red: Analogía:

 Depende o confía en los procesos y

3.2 Multiplexación y Demultiplexación

3.3 Transporte no orientado a la conexión: UDP

 Cada datagrama tiene una dirección IP source port # dest port #

 Cuando un host recibe un Los datagramas IP con el

source port: 6428 source port: 6428

source port: 9157 source port: 5775

host: IP source IP,port: B,80 host: IP

host: IP source IP,port: B,80 host: IP

host: IP source IP,port: B,80 host: IP

host: IP source IP,port: B,80 host: IP

host: IP source IP,port: B,80 host: IP

host: IP source IP,port: B,80 host: IP

host: IP source IP,port: B,80 host: IP

3.2 Multiplexación y Demultiplexación

3.3 Transporte no orientado a la conexión: UDP

 No orientado a la conexión  ¿Transferencia fiable mediante

length checksum Por qué usar UDP?

length checksum Por qué usar UDP?

¿Qué es una función

Nota. Durante la suma si existen acarreos, este se suma al

Nota. Durante la suma si existen acarreos, este se suma al

Nota. Durante la suma si existen acarreos, este se suma al

RTP (Real Time Protocol,

Aplicación Definir Interfaces

Aplicación Definir Interfaces

Aplicación rdt_send(): Empleada por

Consideraciones del análisis:

 Se desarrollará gradualmente la operación del protocol rtd

 Se empleará modelos de máquina de estados para describir al

Consideraciones del análisis:

Transferencia Fiable sobre un Canal Fiable

Canal con Errores de Bits (Bits en desorden)

Canal con Errores y Pérdidas (Bits en desorden y pérdida de datos)

Consideraciones del análisis:

Transferencia Fiable sobre un Canal Fiable

Canal con Errores de Bits (Bits en desorden)

Canal con Errores y Pérdidas (Bits en desorden y pérdida de datos)

 Canal subyacente perfectamente fiable

Wait for rdt_send(data) Wait for rdt_rcv(packet)

 Canal subyacente perfectamente fiable

Wait for rdt_send(data) Wait for rdt_rcv(packet)

 Canal subyacente perfectamente fiable

Wait for rdt_send(data) Wait for rdt_rcv(packet)

 Canal subyacente perfectamente fiable

Wait for rdt_send(data) Wait for rdt_rcv(packet)

Consideraciones del análisis:

Transferencia Fiable sobre un Canal Fiable