REDES DE COMPUTADORAS

MÓDULO 2: CAPA DE TRANSPORTE

2.1 Introducción y Servicios de la Capa de Transporte

2.1.1 Relación entre las capas de transporte y de red
2.1.2 Overview of the Transport Layer in the Internet
2.2 Multiplexión y Demultiplexión
2.2.1 Identificación del Endpoint
2.2.2 Multiplexión y Demultiplexión Sin Conexión
2.2.3 Multiplexión y Demultiplexión Orientada a Conexiones
2.2.4 Servidores Web y TCP
2.3 Transporte sin conexión: UDP
2.3.1 Estructura del segmento UDP
2.3.2 Suma de verificación UDP
2.4 Principios de Transferencia de Datos Fiables
2.4.1 Construyendo un Protocolo de Transferencia de Datos Confiable
[Link] Transferencia de Datos Confiable a Través de un Canal Perfectamente Confiable: rdt1.0
[Link] Transferencia de Datos Confiable a través de un Canal con Errores de Bit: rdt2.0
[Link].1 El remitente maneja ACK/NAK corruptos: rdt2.1
[Link].2 El remitente usa ACK/NAKs: rdt2.2
[Link] Transferencia de Datos Confiable a Través de un Canal Perdido con Errores de Bits: rdt3.0
2.4.2 Protocolos de Transferencia de Datos Confiables en Tubería
2.4.3 Volver Atrás-N (GBN)
[Link] Enviador GBN
[Link] Receptor GBN
[Link] Operation of the GBN Protocol
2.4.4 Repetición Selectiva (SR)
[Link] Remitente SR
[Link] Receptor SR
2.4.5 Resumen de los mecanismos de transferencia de datos confiables y su uso
Transporte Orientado a Conexión: TCP
2.5.1 La Conexión TCP
2.5.2 Estructura del segmento TCP
[Link] Números de secuencia y números de reconocimiento
[Link] Telnet: Un Estudio de Caso sobre Números de Secuencia y Confirmación
2.5.3 Estimación del Tiempo de Ida y Vuelta y Timeout
[Link] Estimando el Tiempo de Ida y Vuelta
[Link] Configuración y Gestión del Intervalo de Tiempo de Reenvío
2.5.4 Transferencia de Datos Confiable

[Link].1 Primer Escenario

[Link].2 Segundo Escenario
[Link].3 Tercer Escenario
[Link] Reenvío Rápido
2.5.5 Control de Flujo
2.5.6 Gestión de Conexiones TCP
[Link] Configuración de Conexión y Transferencia de Datos
[Link] Liberación de Conexión
2.6 Principios del Control de Congestión
2.6.1 Las causas y los costos de la congestión
[Link] Escenario 1: Dos Remitentes, un Enrutador con Buffers Infinitos
[Link] Escenario 2: Dos Enviadores y un Enrutador con Buffers Finito
[Link] Escenario 3: Cuatro Remitentes, Enrutadores con Buffers Finitos y Rutas Multisalto

"La mayor decepción de la que sufren los hombres proviene de sus propias opiniones." —Leonardo da Vinci

2-1
REDES DE COMPUTADORAS
2.6.2 Enfoques para el Control de Congestión
2.6.3 Ejemplo de Control de Congestión Asistido por Red: Control de Congestión ABR de ATM
[Link] Tres métodos para indicar congestión
2.7 Control de Congestión TCP
2.7.1 Control de Congestión TCP
[Link] Inicio Lento
[Link] Evitación de Congestión
[Link] Recuperación Rápida
[Link] Control de Congestión TCP: Retrospectiva
2.7.2 Equidad
[Link] Equidad y UDP
[Link] Equidad y Conexiones TCP Paralelas

“Si buscas venganza, comienza por cavar dos tumbas.” —Proverbio chino antiguo

2-2
REDES DE ORDENADORES

MÓDULO 2: CAPA DE TRANSPORTE

2.1 Introducción y Servicios de Capa de Transporte

• Un protocolo de capa de transporte proporciona comunicación lógica entre procesos de aplicación que se ejecutan en
diferentes anfitriones.
•Transport-layer protocols are implemented in the end-systems but not in network-routers.
•On the sender, the transport-layer
→recibe mensajes de un proceso de aplicación
→convierte los mensajes en los segmentos y
→pasa el segmento a la capa de red.
•En el receptor, la capa de transporte
recibe el segmento de la capa de red
→convierte los segmentos en los mensajes y
→pasa los mensajes al proceso de aplicación.
•Internet tiene 2 protocolos de capa de transporte: TCP y UDP

2.1.1 Relación entre las capas de transporte y red

Un protocolo de capa de transporte proporciona comunicación lógica entre procesos que se ejecutan en diferentes hosts.
Mientras tanto, un protocolo de capa de red proporciona comunicación lógica entre hosts.
Los protocolos de la capa de transporte se implementan en los sistemas finales, pero no en los enrutadores de red.
•Dentro de un sistema final, un protocolo de transporte
→ mueve mensajes de los procesos de la aplicación a la capa de red y viceversa.
→pero no dice nada sobre cómo se mueven los mensajes dentro del núcleo de la red.
Los enrutadores no reconocen ninguna información que se adjunta a los mensajes por la capa de transporte.

2.1.2 Visión general de la capa de transporte en Internet

•Al diseñar una aplicación de red, debemos elegir entre TCP o UDP como protocolo de transporte.
1) UDP (Protocolo de Datagramas de Usuario)
UDP proporciona un servicio sin conexión a la aplicación que lo invoca.
El UDP proporciona los siguientes 2 servicios:
i) Entrega de datos de proceso a proceso y
ii) Verificación de errores.
UDP es un servicio no confiable, es decir, no garantiza que los datos lleguen al proceso de destino.
2) TCP (Protocolo de Control de Transmisión)
TCP proporciona un servicio orientado a la conexión a la aplicación que lo invoca.
El TCP proporciona los siguientes 3 servicios:
1) Transferencia de datos confiable, es decir, garantiza que los datos llegarán al destino y se procesarán correctamente.
2) Control de congestión y

Nunca he conocido a un hombre tan ignorant que no pudiera aprender algo de él.

2-3
REDES COMPUTACIONALES
2.2 Multiplexión y Demultiplexión
Un proceso puede tener uno o más sockets.
Los sockets se utilizan para transmitir datos de la red al proceso y viceversa.
Multiplexación
En el emisor, la capa de transporte
→recoge fragmentos de datos en el host fuente de diferentes sockets
→encapsula un fragmento de datos con un encabezado para crear segmentos y
→pasa los segmentos a la capa de red.
El trabajo de combinar los fragmentos de datos de diferentes sockets para crear un segmento se llama
multiplexión.
2) Demultiplexión
En el receptor, la capa de transporte
→examina los campos en los segmentos para identificar el socket receptor y
dirige el segmento al socket receptor.
El trabajo de entregar los datos en un segmento al socket correcto se llama desmultiplexión.
• En la Figura 2.1,
En el host intermedio, la capa de transporte debe desmultiplexar los segmentos que llegan de la red.
capa para procesar P1 o P2.
Los datos del segmento entrante se dirigen al socket del proceso correspondiente.

Figura 2.1: Multiplexión y demultiplexión en la capa de transporte

“Solo los tontos y los muertos nunca cambian de opinión.” — James R. Lowell

2-4
REDES DE ORDENADORES
2.2.1 Identificación de Endpoint
Cada enchufe debe tener un identificador único.
•Cada segmento debe incluir 2 campos de encabezado para identificar el socket (Figura 2.2):
1) Campo de número de puerto de origen y
2) Campo de número de puerto de destino.
Cada número de puerto es un número de 16 bits: 0 a 65535.
Los números de puerto que van de 0 a 1023 se llaman números de puerto bien conocidos y están restringidos.
Por ejemplo: HTTP utiliza el puerto número 80
FTP utiliza el puerto número 21

•Cuando desarrollamos una nueva aplicación, debemos asignarle un número de puerto, que se conoce
como puertos efímeros (49152–65535).

Figura 2.2: Campos de número de puerto de origen y destino en un segmento de capa de transporte

¿Cómo implementa la capa de transporte el servicio de desmultiplexión?

• Respuesta:
A cada socket en el host se le asignará un número de puerto.
Cuando un segmento llega al host, la capa de transporte
→examina el puerto de destino en el segmento
→dirige el segmento al socket correspondiente y
→pasa entonces el segmento al proceso adjunto.

“Cuando no puedes cambiar la dirección del viento - ajusta tus velas.” —H. Jackson Brown

2-5
REDES DE COMPUTADORAS
2.2.2 Multiplexión y Demultiplexión Sin Conexión
• En el lado del cliente de la aplicación, la capa de transporte asigna automáticamente el número de puerto.
Mientras tanto, en el lado del servidor, la aplicación asigna un número de puerto específico.
•Supongamos que un proceso en Host-A (puerto 19157) quiere enviar datos a un proceso en Host-B (puerto 46428).

Figura 2.3: La inversión de los números de puerto de origen y destino

•En el emisor A, la capa de transporte

→ crea un segmento que contiene el puerto de origen 19157, el puerto de destino 46428 y datos
→pasa luego el segmento resultante a la capa de red.
•En el receptor B, la capa de transporte
→examina el campo de puerto de destino en el segmento y
→entrega el segmento al socket identificado por el puerto 46428.
•Un socket UDP se identifica por un par de tuplas:
1) Dirección IP de destino &
2) Número de puerto de destino
•Como se muestra en la Figura 2.3,
El puerto de origen de Host-A se utiliza en Host-B como "dirección de retorno", es decir, cuando B quiere enviar un
segmento de regreso a A.

“Aunque el mundo está lleno de sufrimiento, también está lleno de su superación.” —Helen Keller

2-6
REDES DE COMPUTADORAS
2.2.3 Multiplexión y Demultiplexión Orientadas a Conexiones
Cada conexión TCP tiene exactamente 2 puntos finales. (Figura 2.4).
Así, 2 segmentos TCP que llegan con diferentes números de puerto de origen serán dirigidos a 2 sockets diferentes.
incluso si tienen el mismo número de puerto de destino.
•Un socket TCP se identifica mediante una tupla de cuatro elementos:
1) Dirección IP de origen
2) Puerto de origen no
3) Dirección IP de destino &
4) Número del puerto de destino

Figura 2.4: La inversión de los números de puerto de origen y destino

El servidor-anfitrión puede soportar muchos sockets de conexión simultáneos.

Cada enchufe será
→adjunto a un proceso.
→identificado por su propio cuádruple.
Cuando un segmento llega al host, se utilizan los 4 campos para dirigir el segmento al apropiado
socket. (es decir, Demultiplexación).

“Las dificultades son cosas que muestran a una persona quién es.” —Epicteto

2-7
REDES DE ORDENADORES
2.2.4 Servidores Web y TCP
•Considere un host que ejecuta un servidor web (por ejemplo: Apache) en el puerto 80.
•Cuando los clientes (por ejemplo: navegadores) envían segmentos al servidor, todos los segmentos tendrán el puerto de destino 80.
•El servidor distingue los segmentos de los diferentes clientes utilizando un par de tuplas:
1) Direcciones IP de origen &
2) Números de puerto de origen.

La Figura 2.5 muestra un servidor web que crea un nuevo proceso para cada conexión.
•El servidor puede usar i) HTTP persistente o ii) HTTP no persistente
i) HTTP Persistente
A lo largo de la duración de la conexión persistente, el cliente y el servidor intercambian HTTP
mensajes a través del mismo socket de servidor.
ii) HTTP no persistente
Se crea y cierra una nueva conexión TCP para cada solicitud/respuesta.
Por lo tanto, se crea y se cierra un nuevo socket para cada solicitud/respuesta.
Esto puede afectar gravemente el rendimiento de un servidor web muy ocupado.

Figura 2.5: Dos clientes, utilizando el mismo número de puerto de destino (80) para comunicarse con el mismo Web.
aplicación de servidor

Nunca subestimes el poder de la pasión.

2-8
REDES DE COMPUTADORAS
2.3 Transporte sin conexión: UDP
UDP es un protocolo no confiable y sin conexión.
Un servicio poco confiable significa que UDP no garantiza que los datos lleguen al proceso de destino.
Sin conexión significa que no hay intercambio de saludos entre el remitente y el receptor antes de enviar datos.
•Proporciona los siguientes 2 servicios:
i) Entrega de datos de proceso a proceso y
ii) Comprobación de errores.
No proporciona control de flujo, control de errores ni control de congestión.
•En el emisor, UDP
recibe mensajes del proceso de aplicación
→adjunta los números de puerto de origen y destino y
→pasa el segmento resultante a la capa de red.
•En el receptor, UDP
→ examina el número de puerto de destino en el segmento y
→ entrega el segmento al proceso de aplicación correcto.
•Es adecuado para programas de aplicación que
→necesita enviar mensajes cortos &
no puede permitirse la retransmisión.
•UDP es adecuado para muchas aplicaciones por las siguientes razones:
1) Control más fino a nivel de aplicación sobre qué datos se envían y cuándo.
Cuando un proceso de aplicación pasa datos a UDP, el UDP
→empaca los datos dentro de un segmento y
→pasa inmediatamente el segmento a la capa de red.
Por otro lado,
En TCP, un mecanismo de control de congestión limita al remitente cuando la red está congestionada
2) No se establece conexión.
TCP utiliza un apretón de manos de tres vías antes de comenzar a transferir datos.
UDP simplemente transmite los datos de inmediato sin preliminares formales.
Por lo tanto, UDP no introduce ningún retraso para establecer una conexión.
Por eso, DNS funciona sobre UDP en lugar de TCP.
3) Sin estado de conexión.
TCP mantiene el estado de conexión en los sistemas finales.
Este estado de conexión incluye
→recibir y enviar buffers
→parámetros de control de congestión y
→parámetros de número de secuencia y de reconocimiento.
Por otra parte,
En UDP, no se mantiene un estado de conexión.
4) Pequeño sobrecarga de encabezado de paquete.
El segmento TCP tiene 20 bytes de sobrecarga de encabezado en cada segmento.
Por otro lado, UDP tiene solo 8 bytes de sobrecarga.

Tabla 2.1: Aplicaciones de Internet populares y sus protocolos de transporte subyacentes

Aplicación Capa de Aplicación Transporte Subyacente
Protocolo Protocolo
Correo electrónico SMTP TCP
Acceso remoto a terminal Telnet TCP
Web HTTP TCP
Transferencia de archivos FTP TCP
Servidor de archivos remoto NFS Típicamente UDP
Streaming multimedia típicamente propietario UDP o TCP
Telefonía por Internet típicamente propietario UDP o TCP
Gestión de redes SNMP Típicamente UDP
Protocolo de enrutamiento Descanse en paz Típicamente UDP
traducción de nombre DNS Típicamente UDP

Cuando ya no podemos cambiar una situación, se nos desafía a cambiar a nosotros mismos. -Victor Frankl

2-9
REDES DE COMPUTADORAS
2.3.1 Estructura del Segmento UDP

Figura 2.6: Estructura del segmento UDP

•El segmento UDP contiene los siguientes campos (Figura 2.6):

1) Datos de la aplicación: Este campo ocupa el campo de datos del segmento.
2) Número de puerto de destino: Este campo se utiliza para entregar los datos al proceso correcto que se está ejecutando en el
host-destino. (es decir, función de desmultiplexión).
3) Longitud: Este campo especifica el número de bytes en el segmento (cabecera más datos).
4) Suma de verificación: Este campo se utiliza para la detección de errores.

2.3.2 Suma de Verificación UDP

El checksum se utiliza para la detección de errores.
•El checksum se utiliza para determinar si los bits dentro del segmento han sido alterados.
•Cómo calcular el checksum en el remitente:
1) Todas las palabras de 16 bits en el segmento se suman para obtener un total.
2) Luego, se obtiene el complemento a 1 de la suma para obtener un resultado.
3) Finalmente, el resultado se añade al campo de suma de verificación dentro del segmento.
•Cómo verificar errores en el receptor:
1) Todas las palabras de 16 bits en el segmento (incluido el checksum) se suman para obtener una suma.
i) Para que no haya errores: En la suma, todos los bits son 1. (Ej: 1111111)
ii) Para cualquier error: En la suma, al menos uno de los bits es un 0. (Ej: 1011111)
Ejemplo:
•En el remitente:
Supongamos que tenemos las siguientes tres palabras de 16 bits:
0110011001100000
0101010101010101 tres palabras de 16 bits
1000111100001100
La suma de las primeras dos palabras de 16 bits es:
0110011001100000
0101010101010101
1011101110110101
Agregar la tercera palabra a la suma anterior da:
1011101110110101 suma de 1stdos palabras de 16 bits
1000111100001100 tercera palabra de 16 bits
0100101011000010 →suma de todas las tres palabras de 16 bits
Tomando el complemento a 1 para la suma final:
0100101011000010 →suma de las tres palabras de 16 bits
1011010100111101 → complemento a 1 para la suma final
El valor del complemento a 1 se llama suma de verificación, que se añade dentro del segmento.
•En el receptor
Se suman las cuatro palabras de 16 bits, incluido el checksum.
i) Si no se introducen errores en el paquete, entonces claramente la suma será
1111111111111111.
ii) Si uno de los bits es un 0, entonces se han introducido errores en el paquete.

Solo se vive una vez, pero si lo haces bien, una vez es suficiente.

2-10
REDES DE COMPUTADORAS
2.4 Principios de Transferencia de Datos Confiable
La Figura 2.7 ilustra el marco del protocolo de transferencia de datos confiable.

Figura 2.7: Transferencia de datos confiable: modelo de servicio e implementación del servicio

•En el emisor, rdt_send() será llamado cuando un paquete deba ser enviado por el canal.
•En el receptor,
i) rdt_rcv() se llamará cuando un paquete tenga que ser recibido en el canal.
ii) deliver_data() se llamará cuando los datos tengan que ser entregados a la capa superior

“Si amas la vida, no pierdas el tiempo, porque el tiempo es de lo que está hecha la vida.” —Bruce Lee

2-11
REDES DE ORDENADORES
2.4.1 Construyendo un Protocolo de Transferencia de Datos Fiable
[Link] Transferencia de Datos Confiable a Través de un Canal Perfectamente Confiable: rdt1.0
•Considerar la transferencia de datos a través de un canal perfectamente fiable.
Llamamos a este protocolo rdt1.0.

Figura 2.8: rdt1.0 - Un protocolo para un canal completamente fiable

Las definiciones de la máquina de estados finitos (FSM) para el emisor y receptor rdt1.0 se muestran en la Figura 2.8.
Los autómatas de estado finito del remitente y del receptor tienen solo un estado.
•En FSM, se utilizan las siguientes notaciones:
i) Las flechas indican la transición del protocolo de un estado a otro.
ii) El evento que causa la transición se muestra sobre la línea horizontal que etiqueta la transición.
iii) La acción tomada cuando ocurre el evento se muestra debajo de la línea horizontal.
iv) La flecha discontinua indica el estado inicial.
•En el emisor, rdt
→ acepta datos de la capa superior a través del evento rdt_send(data)
→crea un paquete que contiene los datos (a través de la acción make_pkt(data)) y
→envía el paquete al canal.
•En el receptor, rdt
→recibe un paquete del canal subyacente a través del evento rdt_rcv(packet)
→elimina los datos del paquete (a través de la acción extraer (paquete, datos)) y
→pasa los datos a la capa superior (a través de la acción deliver_data(data)).

Escríbelo en tu corazón que cada día es el mejor día del año.

2-12
REDES DE COMPUTADORAS
[Link] Transferencia de Datos Confiable a Través de un Canal con Errores de Bit: rdt2.0
•Considera la transferencia de datos a través de un canal no confiable en el que los bits en un paquete pueden estar corruptos.
Llamamos a este protocolo rdt2.0.
•El protocolo de dictado de mensajes utiliza tanto
→confirmaciones positivas (ACK) y
→acknowledgements negativos (NAK).
•El receptor utiliza estos mensajes de control para informar al remitente sobre
→lo que ha sido recibido correctamente y
→ lo que ha sido recibido por error y, por lo tanto, requiere retransmisión.
•Reliable data transfer protocols based on the retransmission are known as ARQ protocols.
Se requieren tres capacidades de protocolo adicionales en los protocolos ARQ:
1) Detección de Errores
Se necesita un mecanismo para permitir que el receptor detecte cuándo han ocurrido errores de bits.
UDP utiliza el campo de suma de verificación para la detección de errores.
Las técnicas de corrección de errores permiten al receptor detectar y corregir errores de bits en los paquetes.
2) Retroalimentación del receptor

Dado que el remitente y el receptor suelen ejecutarse en sistemas finales diferentes.

La única forma en que el remitente puede conocer el estado del receptor es a través de la información proporcionada por el receptor.
retroalimentación explícita al remitente.
Por ejemplo: ACK y NAK
3) Retransmisión
Un paquete que se recibe con error en el receptor será retransmitido por el remitente.
•La figura 2.9 muestra la representación FSM de rdt2.0.

Figura 2.9: rdt2.0–Un protocolo para un canal con errores de bits

«Todo es gracioso, siempre que le ocurra a otra persona.» —Will Rogers

2-13
REDES INFORMÁTICAS
FSM de remitente
•El remitente de rdt2.0 tiene 2 estados:
1) En un estado, el protocolo está esperando que se pasen datos desde la capa superior.
2) En otro estado, el protocolo está esperando un ACK o un NAK del receptor.
i) Si se recibe un ACK, el protocolo
sabe que el paquete transmitido más recientemente ha sido recibido correctamente
→regresa al estado de espera de datos de la capa superior.
ii) Si se recibe un NAK, el protocolo
retransmite el último paquete y
→espera que se devuelva un ACK o NAK por el receptor.
• El remitente no enviará nuevos datos hasta que esté seguro de que el receptor los ha recibido correctamente.
paquete actual.
• Debido a este comportamiento, el protocolo rdt2.0 es conocido como protocolos de esperar y parar.
FSM del receptor
El receptor de rdt2.0 tiene un único estado.
• Al recibir el paquete, el receptor responde con un ACK o un NAK, dependiendo del paquete recibido.
está corrupto o no.

“Si pasas demasiado tiempo pensando en algo, nunca lo terminarás.” —Bruce Lee

2-14
REDES DE COMPUTADORAS
[Link].1 El remitente maneja ACK/NAKs distorsionados: rdt2.1
• Problema con rdt2.0:
Si un ACK o NAK está dañado, el remitente no puede saber si el receptor ha recibido correctamente.
¿recibió los datos o no?
•Solución: El remitente reenvía el paquete de datos actual cuando recibe un paquete ACK o NAK distorsionado.
Problem: This approach introduces duplicate packets into the channel.
Solución: Agregar el campo de número de secuencia al paquete de datos.
El receptor solo tiene que verificar el número de secuencia para determinar si el recibido
el paquete es una retransmisión o no.
Para un protocolo de parar y esperar, un número de secuencia de 1 bit será suficiente.
Un número de secuencia de 1 bit permite al receptor saber si el remitente está enviando
→paquete transmitido anteriormente (0) o
→nuevo paquete (1).
Llamamos a este protocolo rdt2.1.
•La Figura 2.10 y 2.11 muestra la descripción del FSM para rdt2.1.

Figura 2.10: rdt2.1 emisor

“Por cada minuto que permaneces enojado, renuncias a 60 segundos de paz mental.” —Ralph Waldo Emerson

2-15
REDES DE COMPUTADORAS

Figura 2.11: receptor rdt2.1

“Cuando estés enojado cuenta hasta diez antes de hablar. Si estás muy enojado, cuenta hasta cien.” —Thomas Jefferson

2-16
REDES INFORMÁTICAS
[Link].2 Sender uses ACK/NAKs: rdt2.2
El protocolo rdt2.2 utiliza tanto confirmaciones positivas como negativas del receptor al emisor.
i) Cuando se recibe un paquete fuera de orden, el receptor envía un reconocimiento positivo (ACK).
ii) Cuando se recibe un paquete corrupto, el receptor envía un reconocimiento negativo (NAK).
Llamamos a este protocolo como rdt2.2. (Figura 2.12 y 2.13).

Figura 2.12: rdt2.2enviador

Figura 2.13: receptor rdt2.2

Cree que puedes y ya estás a medio camino.

2-17
REDES DE COMPUTADORAS
[Link] Transferencia de Datos Confiable a Través de un Canal Pérdido con Errores de Bit: rdt3.0
•Considera la transferencia de datos a través de un canal poco fiable en el que pueden ocurrir pérdidas de paquetes.

Llamamos a este protocolo rdt3.0.

•Dos problemas deben ser resueltos por el rdt3.0:
1) ¿Cómo detectar la pérdida de paquetes?
2) ¿Qué hacer cuando ocurre pérdida de paquetes?
• Solución:
El remitente
→envía un paquete y empieza un temporizador y
→espera ACK del receptor (ok para continuar).
Si el temporizador expira antes de que llegue el ACK, el emisor retransmite el paquete y reinicia el
temporizador.
El remitente debe esperar al menos tanto tiempo como
1) Un tiempo de retraso de ida y vuelta entre el remitente y el receptor más
2) Cantidad de tiempo necesaria para procesar un paquete en el receptor.
Implementar un mecanismo de retransmisión basado en el tiempo requiere un temporizador de cuenta regresiva.
El temporizador debe interrumpir al remitente después de que haya transcurrido un tiempo determinado.
•La figura 2.14 muestra el FSM del emisor para rdt3.0, un protocolo que transfiere datos de manera confiable a través de un canal
que puede corromper o perder paquetes;
•La figura 2.15 muestra cómo opera el protocolo sin paquetes perdidos o retrasados y cómo maneja los paquetes perdidos
paquetes de datos.
•Debido a que los números de secuencia alternan entre 0 y 1, el protocolo rdt3.0 es conocido como el protocolo de bit alternante.

Figura 2.14: remitente rdt3.0

La vida no es justa; acostúmbrate a ello

2-18
REDES DE ORDENADORES

Figura 2.15: Operación de rdt3.0, el protocolo de bit alternante

“La clave para la inmortalidad es primero vivir una vida que valga la pena recordar.” —Bruce Lee

2-19
REDES DE COMPUTADORAS
2.4.2 Protocolos de Transferencia de Datos Fiables en Canalizaciones
El remitente puede enviar múltiples paquetes sin esperar a las confirmaciones.
• Esto se ilustra en la Figura 2.16 (b).
• El pipelining tiene las siguientes consecuencias:
1) El rango de los números de secuencia debe aumentarse.
2) El remitente y el receptor pueden tener que almacenar en búfer más de un paquete.
Se pueden identificar dos enfoques básicos para la recuperación de errores en tuberías:
1) Go-Back-N and 2) Selective repeat.

Figura 2.16: Envío de detener y esperar y envasado en pipelining

La vida debe ser vivida como un juego.

2-20
REDES INFORMÁTICAS
2.4.3 Regresar-N (GBN)
Se permite al remitente transmitir múltiples paquetes sin esperar una confirmación.
•Pero, el remitente está limitado a tener un máximo de N paquetes no reconocidos en la tubería.
Donde N = tamaño de ventana que se refiere al número máximo de paquetes no reconocidos en la tubería
El protocolo GBN se llama un protocolo de ventana deslizante.
•La Figura 2.17 muestra la vista del remitente del rango de números de secuencia.

Figura 2.17: Vista del remitente sobre los números de secuencia en Go-Back-N

•La figura 2.18 y 2.19 dan una descripción FSM del emisor y receptores de un protocolo GBN.

Figura 2.18: Descripción extendida del FSM del remitente GBN

Figure 2.19: Extended FSM description of GBN receiver

"Trata de no convertirte en un hombre de éxito, sino más bien trata de convertirte en un hombre de valor." —Albert Einstein

2-21
REDES DE COMPUTADORAS
[Link] Remitente GBN
•El remitente debe responder a 3 tipos de eventos:
1) Invocación desde arriba.
Cuando se llama a rdt_send() desde arriba, el remitente primero verifica si la ventana está llena
es decir, si hay N paquetes pendientes y no reconocidos.
i) If the window is not full, the sender creates and sends a packet.
ii) Si la ventana está llena, el emisor simplemente devuelve los datos a la capa superior.
es una indicación implícita de que la ventana está llena.
2) Recepción de un ACK.
Se considerará que un acuse de recibo para un paquete con número de secuencia n es acumulativo
reconocimiento.
Todos los paquetes con un número de secuencia hasta n han sido recibidos correctamente en el receptor.
3) Un Evento de Tiempo de Espera.
Se utilizará un temporizador para recuperar datos perdidos o paquetes de acknowledge.
i) Si ocurre un tiempo de espera, el remitente reenvía todos los paquetes que se han enviado previamente pero
que aún no han sido reconocidos.
ii) Si se recibe un ACK pero todavía hay transmisiones adicionales que no se han recibido.
los paquetes reconocidos, el temporizador se reinicia.
iii) Si no hay paquetes pendientes no reconocidos, el temporizador se detiene.
[Link] Receptor GBN
•Si un paquete con número de secuencia n se recibe correctamente y en orden, el receptor
→envía un ACK para el paquete n y
→entrega el paquete a la capa superior.
•En todos los demás casos, el receptor
→descarta el paquete y
→ reenvía un ACK para el paquete recibido en orden más recientemente.

“Juzga tu carácter natural por lo que haces en tus sueños.” —Ralph Waldo Emerson

2-22
REDES DE COMPUTADORAS
[Link] Operación del Protocolo GBN

Figura 2.20: Go-Back-N en operación

•La Figura 2.20 muestra el funcionamiento del protocolo GBN para el caso de un tamaño de ventana de cuatro paquetes.
El remitente envía los paquetes 0 a 3.
El remitente debe esperar a que uno o más de estos paquetes sean reconocidos antes de continuar.
A medida que se recibe cada ACK sucesivo (por ejemplo, ACK0 y ACK1), la ventana avanza.
el remitente transmite un nuevo paquete (pkt4 y pkt5, respectivamente).
•En el receptor, el paquete 2 se pierde y, por lo tanto, los paquetes 3, 4 y 5 se encuentran desordenados y son
descartado.

La naturaleza y los libros pertenecen a los ojos que los ven.

2-23
REDES DE ORDENADORES
2.4.4 Repetición Selectiva (SR)
• Problema con GBN:
GBN sufre de problemas de rendimiento.
Cuando el tamaño de la ventana y el producto de ancho de banda y retraso son grandes, muchos paquetes pueden estar en
el tubo
Thus, a single packet error results in retransmission of a large number of packets.
• Solución: Utilizar Repetición Selectiva (RS).

Figura 2.21: Vistas del emisor y receptor de un repetidor selectivo (SR) del espacio de números de secuencia

El remitente retransmite solo aquellos paquetes que sospecha que eran erróneos.
• Por lo tanto, evita retransmisiones innecesarias. De ahí el nombre 'repetición selectiva'.
El receptor reconoce individualmente los paquetes recibidos correctamente.
Se utiliza un tamaño de ventana N para limitar el número de paquetes pendientes y no reconocidos en el canal.
La figura 2.21 muestra la vista del espacio de números de secuencia del emisor SR.

[Link] SR Remitente
Las diversas acciones tomadas por el remitente SR son las siguientes:
1) Datos recibidos de arriba.
Cuando se reciben datos de arriba, el remitente verifica el siguiente número de secuencia disponible para
el paquete.
Si el número de secuencia está dentro de la ventana del remitente;
Luego, los datos se empaquetan y se envían;
De lo contrario, los datos se almacenan en caché para su transmisión posterior.
2) Tiempo de espera.

Cada paquete debe tener su propio temporizador lógico. Esto se debe a que
→ solo se transmitirá un solo paquete en caso de tiempo de espera.
3) ACK recibido.
Si se recibe un ACK, el remitente marca ese paquete como recibido.
Si el número de secuencia del paquete es igual a send_base, la base de la ventana se incrementa en el
número de secuencia más pequeño.
Si hay paquetes no transmitidos con números de secuencia que se encuentran dentro de la ventana, estos
se transmiten paquetes.

«La vida se pasa a medias antes de que sepamos lo que es.» —George Herbert

2-24
REDES DE COMPUTADORAS
[Link] Receptor SR
Las diversas acciones tomadas por el receptor SR son las siguientes:
1) El paquete con número de secuencia en [rcv_base, rcv_base+N-1] se recibe correctamente.
En este caso,
→el paquete recibido cae dentro de la ventana del receptor y
→ se devuelve un paquete ACK selectivo al remitente.
Si el paquete no fue recibido previamente, se almacena en búfer.
Si este paquete tiene un número de secuencia igual a rcv_base, entonces este paquete y cualquier anterior
Los paquetes en búfer y numerados de manera consecutiva se entregan a la capa superior.
La ventana de recepción se mueve hacia adelante por el número de paquetes entregados a la capa superior.
Por ejemplo: considera la Figura 2.22.
¤ Cuando se recibe un paquete con un número de secuencia de rcv_base=2, este y los paquetes 3, 4,
y 5 se puede entregar a la capa superior.
2) El paquete con número de secuencia en [rcv_base-N, rcv_base-1] se recibe correctamente.
En este caso, se debe generar un ACK, aunque este sea un paquete que el receptor ha
reconocido anteriormente.
3) De lo contrario.
Ignora el paquete.

Figura 2.22: operación SR

“Todo tiene belleza, pero no todos la ven.” —Confucio

2-25
REDES INFORMÁTICAS
2.4.5 Resumen de los mecanismos de transferencia de datos confiables y su uso

Tabla 2.2: Resumen de mecanismos de transferencia de datos confiables y su uso

Mecanismo Use, Comments
Suma de verificación Utilizado para detectar errores de bits en un paquete transmitido.
Temporizador Se utilizó para esperar tiempo de espera/retransmitir un paquete porque el paquete (o su ACK) fue
perdido.
Porque pueden ocurrir tiempo de espera cuando un paquete se retrasa pero no se pierde,
Se pueden recibir copias duplicadas de un paquete por un receptor.
Número de secuencia utilizado para la numeración secuencial de los paquetes de datos que fluyen del remitente a
receptor.
Las brechas en la secuencia de números de los paquetes recibidos permiten al receptor
detectar un paquete perdido.
Los paquetes con números de secuencia duplicados permiten al receptor detectar
copias duplicadas de un paquete.
Reconocimiento Usado por el receptor para indicar al remitente que un paquete o conjunto de paquetes ha
ha sido recibido correctamente.
Los acuses de recibo generalmente llevarán el número de secuencia del paquete o
paquetes siendo reconocidos.
Los reconocimientos pueden ser individuales o acumulativos, dependiendo del
protocolo.
Negativo Utilizado por el receptor para informar al emisor que un paquete no ha sido recibido
reconocimiento correctamente.
Los reconocimientos negativos generalmente llevarán el número de secuencia del
paquete que no fue recibido correctamente.
Ventana, canalización El remitente puede estar restringido a enviar solo paquetes con secuencia-
números que caen dentro de un rango dado.
Al permitir que se transmitan múltiples paquetes pero que aún no se hayan reconocido,
La utilización del emisor se puede aumentar en un modo de operación de parar y esperar.

“Entre dos males, siempre elijo el que nunca he probado antes.” —Mae West

2-26
REDES DE COMPUTADORAS
2.5 Transporte Orientado a Conexión: TCP
TCP es un protocolo orientado a la conexión y fiable.
Orientado a la conexión significa que se establece una conexión entre el emisor y el receptor antes de enviar.
los datos.
Un servicio confiable significa que TCP garantiza que los datos llegarán al proceso de destino.
correctamente.
•TCP proporciona control de flujo, control de errores y control de congestión.

2.5.1 La conexión TCP

Las características de TCP son las siguientes:
1) Orientado a la conexión
Se dice que TCP es orientado a conexiones. Esto se debe a que
Los 2 procesos de aplicación deben primero establecer conexión entre sí antes de que ellos
comenzar la comunicación.
Ambos procesos de aplicación inicializarán muchas variables de estado asociadas con la conexión.
2) Se ejecuta en los sistemas finales
TCP se ejecuta solo en los sistemas finales, pero no en los enrutadores intermedios.
Los routers no mantienen ninguna variable de estado asociada con la conexión.
Servicio Dúplex Completo
La conexión TCP proporciona un servicio de dúplex completo.
Ambos procesos de aplicación pueden transmitir y recibir los datos al mismo tiempo.
4) Punto a Punto
Una conexión TCP es punto a punto, es decir, solo 2 dispositivos están conectados a través de un enlace dedicado.
Entonces, el multicast no es posible.
5) Conexión de tres vías
El proceso de establecimiento de conexión se conoce como un apretón de manos de tres vías. Esto se debe a que
Se envían 3 segmentos entre los dos hosts:
i) El cliente envía un primer segmento.
ii) El servidor responde con un segundo segmento y
iii) Finalmente, el cliente responde nuevamente con un tercer segmento que contiene la carga útil (o datos).
6) Tamaño Máximo de Segmento (MSS)
MSS limita la cantidad máxima de datos que se pueden colocar en un segmento.
Por ejemplo: MSS = 1,500 bytes para Ethernet
7) Buffers de Envío y Recepción
Como se muestra en la Figura 2.23, se considera el envío de datos del proceso cliente al proceso servidor.
En el remitente
i) El proceso del cliente pasa un flujo de datos a través del socket.
ii) Luego, TCP envía los datos al búfer de envío.
iii) Cada trozo de datos se añade con un encabezado para formar un segmento.
iv) Los segmentos se envían a la red.
En el receptor
Los datos del segmento se colocan en el búfer de recepción.
ii) La aplicación lee el flujo de datos del búfer de recepción.

Figura 2.23: Buffers de envío y recepción de TCP

«El secreto del éxito es estar preparado cuando llegue tu oportunidad.» —Benjamin Disraeli

2-27
REDES DE COMPUTADORAS
2.5.2 Estructura del Segmento TCP
• El segmento consta de campos de encabezado y un campo de datos.
• El campo de datos contiene un fragmento de datos.
Cuando TCP envía un archivo grande, divide el archivo en fragmentos de tamaño MSS.
• La Figura 2.24 muestra la estructura del segmento TCP.

Figura 2.24: Estructura del segmento TCP

Los campos del segmento TCP son los siguientes:

1) Números de puerto de origen y destino
Estos campos se utilizan para la multiplexión/demultiplexión de datos de/a aplicaciones de capa superior.
2) Número de Secuencia y Número de Acuse de Recibo
Estos campos son utilizados por el remitente y el receptor en la implementación de un servicio de transferencia de datos confiable.
3) Longitud del encabezado

Este campo especifica la longitud de la cabecera TCP.

4) Bandera
Este campo contiene 6 bits.
i) ACK
¤ Este bit indica que el valor del campo de reconocimiento es válido.
ii) RST, SYN y FIN
¤ Estos bits se utilizan para la configuración y cierre de la conexión.
iii) PSH
¤ Este bit indica que el remitente ha invocado la operación de envío.
iv)URG
¤ Este bit indica que el segmento contiene datos urgentes.
5) Ventana de Recepción
Este campo define el tamaño de la ventana del receptor
Este campo se utiliza para el control de flujo.
6) Suma de verificación
Este campo se utiliza para la detección de errores.
7) Puntero de Datos Urgente
Este campo indica la ubicación del último byte de los datos urgentes.
8) Opciones
Este campo se utiliza cuando un remitente y un receptor negocian el MSS para su uso en redes de alta velocidad.

“Cada fracaso es solo un paso más cerca de una victoria. Nunca dejes de intentarlo.” —Robert M. Hensel

2-28
REDES DE ORDENADORES
[Link] Números de secuencia y números de reconocimiento
Números de Secuencia
• El número de secuencia se utiliza para la numeración secuencial de paquetes de datos que fluyen del remitente a
receptor.
•Applications:
1) Los huecos en la secuencia de números de los paquetes recibidos permiten que el receptor detecte un paquete perdido.
2) Los paquetes con números de secuencia duplicados permiten al receptor detectar copias duplicadas de un
paquete.
Números de acuse de recibo
• El número de acuse de recibo es utilizado por el receptor para informar al remitente que un paquete ha sido
recibido correctamente.
Las confirmaciones típicamente llevarán el número de secuencia del paquete que se está confirmando.

Figura 2.25: Números de secuencia y reconocimiento para una aplicación Telnet simple sobre TCP

• Considera un ejemplo (Figura 2.25):

Un proceso en el Host-A quiere enviar un flujo de datos a un proceso en el Host-B.
En Host-A, cada byte en el flujo de datos está numerado como se muestra en la Figura 2.26.

Figura 2.26: Dividiendo los datos del archivo en segmentos TCP

El primer segmento de A a B tiene un número de secuencia 42, es decir, Seq=42.

El segundo segmento de B a A tiene un número de secuencia 79, es decir, Seq=79.
El segundo segmento de B a A tiene el número de reconocimiento 43, que es la secuencia-
número del siguiente byte, el Host-B está esperando de Host-A. (es decir, ACK=43).
¿Qué hace un host cuando recibe bytes fuera de orden?
Respuesta: Hay dos opciones:
1) El receptor descarta inmediatamente los bytes fuera de orden.
2) El receptor
mantiene los bytes fuera de orden y
espera a que los bytes faltantes llenen los huecos.

No serás castigado por tu ira; serás castigado por tu ira.

2-29
REDES INFORMÁTICAS
[Link] Telnet: Un estudio de caso sobre números de secuencia y reconocimiento
Telnet es un protocolo de capa de aplicación popular utilizado para iniciar sesión de forma remota.
•Telnet se ejecuta sobre TCP.
Telnet está diseñado para trabajar entre cualquier par de hosts.
• Como se muestra en la Figura 2.27, supongamos que el cliente inicia una sesión de Telnet con el servidor.
• Ahora supongamos que el usuario escribe una sola letra, 'C'.
• Tres segmentos se envían entre el cliente y el servidor:
1) Primer segmento
El primer segmento se envía del cliente al servidor.
El segmento contiene
→letra ‘C’
→número-de-secuencia 42
→acknowledgment-number 79
2) Segundo segmento
El segundo segmento se envía desde el servidor al cliente.
Dos propósitos del segmento:
i) Proporciona un reconocimiento de los datos que el servidor ha recibido.
ii) Se utiliza para devolver la letra 'C'.
El reconocimiento para los datos de cliente a servidor se lleva en un segmento que lleva de servidor a cliente
datos.
Se dice que este acuse de recibo está apoyado en el segmento de datos de servidor a cliente.
3) Tercer segmento
El tercer segmento se envía del cliente al servidor.
One purpose of the segment:
i) Reconoce los datos que ha recibido del servidor.

Figura 2.27: Números de secuencia y reconocimiento para una aplicación Telnet simple sobre TCP

“If you live your life in the past, you waste the life you have to live.” —Jessica Cress

2-30
REDES DE COMPUTADORAS
2.5.3 Estimación del Tiempo de Viaje de Ida y Vuelta y Tiempo de Espera
• TCP utiliza un mecanismo de tiempo de espera/retransmisión para recuperarse de segmentos perdidos.
• Claramente, el tiempo de espera debe ser mayor que el tiempo de ida y vuelta (RTT) de la conexión.

[Link] Estimando el Tiempo de Viaje de Ida y Vuelta

•El SampleRTT se define como
El tiempo que transcurre entre el envío del segmento y la recepción de un acuse de recibo.
• Obviamente, los valores de SampleRTT fluctuarán de segmento a segmento debido a la congestión.
TCP mantiene un promedio de los valores SampleRTT, que se conoce como EstimatedRTT.

•DevRTT se define como

Una estimación de cuánto se desvía típicamente SampleRTT de EstimatedRTT.

Si los valores de SampleRTT tienen poca fluctuación, entonces DevRTT será pequeño.
Si los valores de SampleRTT tienen una gran fluctuación, entonces DevRTT será grande.

[Link] Configuración y gestión del intervalo de tiempo de retransmisión

¿Qué valor debe utilizarse para el intervalo de tiempo de espera?
• Claramente, el intervalo debe ser mayor o igual a EstimatedRTT.
• El intervalo de tiempo de espera se da por:

"Los ganadores nunca se rinden y los que se rinden nunca ganan." —Vince Lombardi

2-31
REDES DE COMPUTADORAS
2.5.4 Transferencia de Datos Confiable
• IP es poco confiable, es decir, IP no garantiza la entrega de datos.
IP does not guarantee in-order delivery of data.
IP no garantiza la integridad de los datos.
TCP crea un servicio de transferencia de datos confiable sobre el servicio poco confiable de IP.
• En el receptor, el servicio confiable significa
→el flujo de datos no está corrupto
El flujo de datos está libre de duplicación y
→el flujo de datos está en secuencia.

[Link] Algunos Escenarios Interesantes

[Link].1 Primer Escenario
• Como se muestra en la Figura 2.28, el Host-A envía un segmento al Host-B.
• Supón que el reconocimiento de B a A se pierde.
• En este caso, ocurre el evento de tiempo de espera, y Host-A retransmite el mismo segmento.
Cuando Host-B recibe la retransmisión, observa que el número de secuencia ya ha sido recibido.
Así, el Host-B descartará el segmento retransmitido.

Figura 2.28: Retransmisión debido a un reconocimiento perdido

La acción es la verdadera medida de la inteligencia.

2-32
REDES DE COMPUTADORAS
[Link].2 Segundo Escenario
• Como se muestra en la Figura 2.29, el Host-A envía dos segmentos uno tras otro.
El Host-B envía dos acuses de recibo separados.
• Supongamos que ninguno de los acuses de recibo llega a Host-A antes del tiempo de espera.
• Cuando ocurre el evento de tiempo de espera, el Host-A reenvía el primer segmento y reinicia el temporizador.
El segundo segmento no será retransmitido hasta que llegue el ACK para el segundo segmento.
nuevo tiempo de espera.

Figura 2.29: Segmento 100 no retransmitido

[Link].3 Tercer Escenario

• Como se muestra en la Figura 2.30, el Host-A envía los dos segmentos.
Se pierde el reconocimiento del primer segmento.
• But just before the timeout event,Host-A receives an acknowledgment-no 120.
Por lo tanto, el Host-A sabe que el Host-B ha recibido todos los bytes hasta el 119.
Entonces, el Host-A no reenvía ninguno de los dos segmentos.

Figura 2.30: Un reconocimiento acumulativo evita la retransmisión del primer segmento

«La fe es el pájaro que siente la luz cuando el amanecer aún está oscuro.» —Rabindranath Tagore

2-33
REDES DE COMPUTADORAS
[Link] Retransmisión Rápida
El periodo de tiempo de espera puede ser relativamente largo.
•El remitente a menudo puede detectar la pérdida de paquetes mucho antes de que ocurra el tiempo de espera al notar ACKs duplicados.
• Un ACK duplicado se refiere al ACK que el remitente recibe por segunda vez. (Figura 2.31).

Tabla 2.3: Recomendación de Generación de ACK TCP

Evento Acción del receptor TCP
Llegada del segmento en orden con ACK retrasado esperado.
número-de-secuencia. Espera hasta 500 mseg para la llegada de otro en-
Todo hasta el número de secuencia esperado ya está ordenado en segmentos.
reconocido. Si el siguiente segmento en orden no llega en este
, envía un ACK.
Llegada del segmento en orden con el esperado. Enviar inmediatamente un ACK acumulativo único, confirmando
número-de-secuencia. ambos segmentos en orden.
One other in-order segment waiting for ACK
transmisión.
Arrival of out-of-order segment with higher- Immediately send duplicate ACK, indicating
número de secuencia menor de lo esperado. número de secuencia del siguiente byte esperado.
Brecha detectada.
Llegada del segmento que se envía ACK de inmediato, ya sea parcial o completamente.
completa el vacío en los datos recibidos.

Figura 2.31: Retransmisión rápida: retransmitiendo el segmento faltante antes de que expire el temporizador del segmento

“Life is really simple, but we insist on making it complicated.” —Confucius

2-34
REDES DE COMPUTADORAS
2.5.5 Control de Flujo
• TCP proporciona un servicio de control de flujo a sus aplicaciones.
Un servicio de control de flujo elimina la posibilidad de que el remitente desborde el búfer del receptor.

Figura 2.32:a)Send buffer and b) Receive Buffer

Como se muestra en la Figura 2.32, definimos las siguientes variables:

1) MaxSendBuffer: Un búfer de envío asignado al remitente.
2) MaxRcvBuffer: A receive-buffer allocated to the receiver.
3) LastByteSent: The no. of the last bytes sent to the send-buffer atthe sender.
4) LastByteAcked: The no. of the last bytes acknowledged in the send-buffer at the sender.
5) LastByteRead: The no. of the last bytes read from the receive-buffer at the receiver.
6) LastByteRcvd: The no. of the last bytes arrived & placed in receive-buffer at the receiver.
Enviar búfer
• El emisor mantiene un búfer de envío, dividido en 3 segmentos, a saber
1) Datos reconocidos
2) Datos no reconocidos y
3) Datos a ser transmitidos
• El buffer de envío mantiene 2 punteros: LastByteAcked y LastByteSent. La relación entre estos dos es:

Buffer de Recepción
El receptor mantiene un búfer de recepción para retener datos incluso si llegan fuera de orden.
•El búfer de recepción mantiene 2 punteros: LastByteRead y LastByteRcvd. La relación entre estos dos es:

Operación de Control de Flujo

•El remitente previene el desbordamiento del búfer de envío manteniendo

•El receptor evita desbordar el búfer de recepción al mantener

•El receptor limita al emisor al anunciar una ventana que es más pequeña que la cantidad de espacio libre.
que puede bufferas:

No puedes ganar a menos que aprendas a perder.

2-35
REDES DE COMPUTADORAS
2.5.6 Gestión de Conexiones TCP
[Link] Configuración de conexión y transferencia de datos
• Para establecer la conexión, se envían tres segmentos entre los dos hosts. Por lo tanto, este proceso es
conocido como un apretón de manos de tres vías.
• Supongamos que un proceso cliente quiere iniciar una conexión con un proceso servidor.
La figura 2.33 ilustra los pasos involucrados:
Paso 1: El cliente envía un segmento de solicitud de conexión al servidor
El cliente primero envía un segmento de solicitud de conexión al servidor.
El segmento de solicitud de conexión contiene:
1) El bit SYN está configurado en 1.

2) Número de secuencia inicial (client_isn).

El segmento SYN está encapsulado dentro de un datagrama IP y se envía al servidor.
Paso 2: El servidor envía un segmento de conexión concedida al Cliente
Entonces, el servidor
→extrae el segmento SYN del datagrama
→asigna los búferes y variables a la conexión y
→envía un segmento de conexión otorgada al cliente.
El segmento de conexión concedida contiene:
1) El bit SYN está configurado en 1.
2) El campo de acuso de recibo está configurado como client_isn+1.
3) Número de secuencia inicial (server_isn).
Paso 3: El cliente envía un segmento ACK al servidor
Finalmente, el cliente
→asigna buffers y variables a la conexión y
→envía un segmento ACK al servidor
El segmento ACK reconoce al servidor.
El bit SYN está configurado en cero, ya que la conexión está establecida.

Figura 2.33: Proceso de conexión de tres vías de TCP: intercambio de segmentos

La autosugestión te convierte en el maestro de ti mismo.

2-36
REDES DE COMPUTADORAS
[Link] Liberación de Conexión
Cualquiera de los dos procesos en una conexión puede finalizar la conexión.
Cuando una conexión termina, los "recursos" en los anfitriones son desasignados.
• Suponga que el cliente decide cerrar la conexión.
•La figura 2.34 ilustra los pasos involucrados:
1) El proceso cliente emite un comando de cierre.
Entonces, el cliente envía un segmento de cierre al servidor.
¤ Este segmento tiene un bit FIN establecido en 1.
2) El servidor responde con un acuse de recibo al cliente.
3) El servidor luego envía su propio segmento de apagado.
¤ Este segmento tiene un bit FIN establecido en 1.
4) Finalmente, el cliente reconoce el segmento de apagado del servidor.

«Los hombres deben vivir y crear. Vivir hasta el punto de las lágrimas.» —Albert Camus

2-37
REDES DE COMPUTADORAS
2.6 Principios del Control de Congestión
2.6.1 Las Causas y los Costos de la Congestión
[Link] Escenario 1: Dos Emisores, un Enrutador con Buffers Infinitos
• Dos anfitriones (A y B) tienen una conexión que comparte un solo salto entre la fuente y el destino.
• Esto se ilustra en la Figura 2.35.

Figura 2.35: Escenario de congestión 1: Dos conexiones compartiendo un solo salto con búferes infinitos

• Deja
Tasa de envío de Host-A = λenbytes/seg
La capacidad del enlace saliente = R
• Packets from Hosts A and B pass through a router andover a sharedoutgoing link.
El enrutador tiene búferes.
• Los búferes almacenan paquetes entrantes cuando la tasa de llegada de paquetes supera la capacidad del enlace saliente.

Figura 2.36: Escenario de congestión 1: Rendimiento y retraso como función de la tasa de envío del host

•La Figura 2.36 muestra el rendimiento de la conexión del Host-A.

Gráfico de la Mano Izquierda
• El gráfico de la izquierda representa el rendimiento por conexión en función de la tasa de envío de la conexión.
• Para una tasa de envío entre 0 y R/2, el rendimiento en el receptor es igual a la tasa de envío del remitente.
Sin embargo, para una tasa de envío superior a R/2, el rendimiento en el receptor es solo R/2. (Figura 2.36a)
• Conclusión: El enlace no puede entregar paquetes a un receptor a una tasa de estado estable que exceda R/2.
Gráfico de Mano Derecha
• El gráfico de la derecha representa el retraso promedio como una función de la tasa de envío de conexión (Figura 2.36b).
A medida que la tasa de envío se acerca a R/2, el retraso promedio se vuelve cada vez mayor.
Sin embargo, para una tasa de envío superior a R/2, el tiempo de retraso promedio se vuelve infinito.
• Conclusión: Se experimentan grandes retrasos en la cola a medida que la tasa de llegada de paquetes se acerca a la capacidad del enlace.

Regla No.1: Nunca pierdas dinero. Regla No.2: Nunca olvides la regla No.1.

2-38
REDES DE COMPUTADORAS
[Link] Escenario 2: Dos emisores y un enrutador con búferes finitos
• Aquí, tenemos 2 suposiciones (Figura 2.37):
La cantidad de almacenamiento en búfer del enrutador es finita.

Los paquetes se perderán al llegar a un búfer ya lleno.

2) Cada conexión es fiable.
Si un paquete se pierde en el enrutador, el remitente eventualmente lo retransmitirá.
• Deja
Application’s sending-rate of Host-A= λenbytes/seg
La tasa de envío de la capa de transporte del Host-A = λenbytes/seg (también llamado carga ofrecida a la red)
La capacidad del enlace saliente = R

Figure 2.37: Scenario 2: Two hosts (with retransmissions) and a router with finite buffers

Caso 1 (Figura 2.38(a)):

El Host-A envía un paquete solo cuando hay un búfer libre.
• En este caso,
→no ocurre pérdida
→λenserá igual a λen‘, y
→el rendimiento de la conexión será igual a λen.
El remitente retransmite solo cuando se pierde un paquete.
• Considerar la carga ofrecida λen=R/2.
La tasa a la que se entregan los datos a la aplicación receptora es R/3.
El remitente debe realizar retransmisiones para compensar los paquetes perdidos debido al desbordamiento del búfer.

Figura 2.38: Rendimiento del escenario 2 con búferes finitos

Case 3 (Figure 2.38(c)):

El remitente puede agotar el tiempo y retransmitir un paquete que ha sido retrasado en la cola pero que aún no se ha perdido.
Tanto el paquete de datos original como la retransmisión pueden llegar al receptor.
El receptor necesita una copia de este paquete y descartará la retransmisión.
• El trabajo realizado por el enrutador al reenviar la copia retransmitida del paquete original fue en vano.

El tiempo descubre la verdad.

2-39
REDES DE COMPUTADORAS
[Link] Escenario 3: Cuatro Enviadores, Enrutadores con Buffers Finitos y Rutas de Múltiples Saltos
Cuatro anfitriones transmiten paquetes, cada uno a través de rutas de dos saltos superpuestas.

Esto se ilustra en la Figura 2.39.

Figura 2.39: Cuatro emisores, enrutadores con búferes finitos, y caminos de múltiples saltos

• Considera la conexión desde el Host-A al Host C, pasando a través de los enrutadores R1 y R2.
• La conexión A–C
→comparte el enrutador R1 con la conexión D–B y
→comparte el router R2 con la conexión B–D.
• Caso-1: Para valores extremadamente pequeños de λ
→ los desbordamientos de búfer son raros (como en los escenarios de congestión 1 y 2) y
el rendimiento aproximadamente iguala la carga ofrecida.
• Caso-2: Para valores ligeramente más grandes de λen, el rendimiento correspondiente también es mayor. Esto se debe a que
→se transmite más datos originales a la red
→data is deliveredto the destination and
Los desbordamientos todavía son raros.

• Caso-3: Valores de λ extremadamente grandesen.

Considerar el enrutador R2.

valor de λdentro.
donde R = la capacidad del enlace de R1 a R2.
Siλenes extremadamente grande para todas las conexiones, entonces la tasa de llegada del tráfico B–D en R2 puede ser
mucho más grande que el del tráfico A–C.
El tráfico A–C y B–D deben competir en el enrutador R2 por la cantidad limitada de espacio en el búfer.
Así, la cantidad de tráfico A–C que pasa con éxito a través de R2 se vuelve más pequeña y
más pequeño a medida que la carga ofrecida de B-D se hace cada vez más grande.
En el límite, a medida que la carga ofrecida se acerca a infinito, un búfer vacío en R2 es inmediatamente
llenado por un paquete B-D, y el rendimiento de la conexión A-C en R2 se vuelve cero.
Cuando un paquete se pierde a lo largo de un camino, la capacidad de transmisión termina siendo
desperdiciado.

Las personas que viven profundamente no tienen miedo a la muerte.

2-40
REDES DE COMPUTADORAS
2.6.2 Enfoques para el Control de Congestión
• Los enfoques de control de congestión se pueden clasificar en función de si la capa de red proporciona alguna
asistencia explícita a la capa de transporte:
1) Control de Congestión de Extremo a Extremo
La capa de red no proporciona soporte explícito a la capa de transporte para el control de congestión.
Incluso la presencia de congestión debe ser inferida por los sistemas finales basándose solo en
comportamiento de red observado.
La pérdida de segmentos se toma como una indicación de congestión de la red y el tamaño de la ventana es
disminuyó en consecuencia.
Control de congestión asistido por la red
Los componentes de la capa de red proporcionan retroalimentación explícita al remitente con respecto a la congestión.
Este feedback puede ser un único bit que indica congestión en un enlace.
La información de congestión se retroalimenta de la red al remitente de una de dos formas:
i) La retroalimentación directa puede ser enviada desde un enrutador de red al remitente (Figura 2.40).
¤ Esta forma de notificación típicamente toma la forma de un paquete de estrangulación.
ii) Un enrutador marca un campo en un paquete que fluye del remitente al receptor para indicar
congestión.
¤ Al recibir un paquete marcado, el receptor luego notifica al remitente del
indicación de congestión.
¤ Esta forma de notificación toma al menos un tiempo de ida y vuelta completo.

Figura 2.40: Dos rutas de retroalimentación para la información de congestión indicada por la red

Se logran grandes cosas cuando los hombres y las montañas se encuentran.

2-41
REDES DE COMPUTADORAS
2.6.3 Ejemplo de Control de Congestión Asistido por Red: Control de Congestión ABR de ATM
El protocolo ATM (Modo de Transferencia Asincrónica) utiliza un enfoque asistido por la red para el control de congestión.
• ABR (Tasa de Bit Disponible) ha sido diseñado como un servicio de transferencia de datos elástico.
i) Cuando la red está poco cargada, ABR tiene que aprovechar el ancho de banda disponible sobrante.
ii) Cuando la red está congestionada, ABR debería reducir su tasa de transmisión.

Figura 2.41: Marco de control de congestión para el servicio ABR de ATM

La Figura 2.41 muestra el marco para el control de congestión ABR de ATM.

Las celdas de datos se transmiten desde una fuente a un destino a través de una serie de conmutadores intermedios.
•Las células RM se colocan entre las células de datos. Gestión de Recursos.
Las celdas TheRM se utilizan para enviar información relacionada con la congestión a los hosts y conmutadores.
• Cuando una celda RM llega a un destino, la celda será enviada de vuelta al remitente
• Así, las células RM se pueden utilizar para proporcionar tanto
→retroalimentación directa de la red y
→retroalimentación de red a través del receptor.

[Link] Tres Métodos para Indicar Congestión

El control de congestión ATM ABR es un enfoque basado en la tasa.
• ABR proporciona 3 mecanismos para indicar información relacionada con la congestión:
1) Bit EFCI
Cada celda de datos contiene un bit EFCI. (EFCI Indicación de congestión hacia adelante explícita
Un conmutador congestionado establece el bit EFCI en 1 para señalizar congestión al destino.
El destino debe verificar el bit EFCI en todas las celdas de datos recibidas.
Si la celda de datos recibida más recientemente tiene el bit EFCI establecido en 1, entonces el destino
→establece el bit CI en 1 en la celda RM (CI indicación de congestión
→envía el RM-cellback al remitente.
Así, se puede notificar a un remitente sobre la congestión en un conmutador de red.
2) Bits de CI y NI
La tasa de interspersiones de células RM es un parámetro ajustable.
El valor predeterminado es una celda RM cada 32 celdas de datos. (NI Sin Aumento
Las celdas RM tienen un bit CI y un bit NI que pueden ser configurados por un conmutador congestionado.

→ establece el bit NI en 1 en una celda RM bajo congestión leve y

→establece el bit CI en 1 en condiciones de congestión severa.
3) Configuración de la Sala de Emergencias

Cada celda RM también contiene un campo ER. (ERtasa explícita

A congested-switch may lower the value contained in the ER field in a passing RM-cell.
De esta manera, el campo ER se establecerá en la tasa mínima soportable de todos los interruptores en el camino.

Si quieres conocer el valor del dinero, ve y intenta pedir prestado algo.

2-42
REDES DE COMPUTADORAS
2.7 Control de Congestión TCP
2.7.1 TCP Congestion Control
• TCP tiene un mecanismo de control de congestión.
• TCP utiliza control de congestión de extremo a extremo en lugar de control de congestión asistido por la red
• Así es como funciona:
Cada remitente limita la tasa a la que envía tráfico en su conexión como función de
congestión percibida.
i) Si el remitente percibe que hay poca congestión, entonces el remitente aumenta su tasa de datos.
ii) Si el emisor percibe que hay congestión, entonces el emisor reduce su tasa de datos.
• Este enfoque plantea tres preguntas:
¿Cómo limita un remitente la tasa a la que envía tráfico a su conexión?
2) ¿Cómo percibe un remitente que hay congestión en el camino?
¿Qué algoritmo debería usar el remitente para cambiar su tasa de datos?
• El remitente realiza un seguimiento de una variable adicional llamada la ventana de congestión (cwnd).
La ventana de congestión impone una restricción en la tasa de datos de un emisor.
La cantidad de datos no reconocidos en un emisor no excederá el mínimo de (cwnd y rwnd), es decir:

La tasa de datos del remitente es aproximadamente cwnd/RTT bytes/segundo.

•Explicación del evento de pérdida:
Un "evento de pérdida" en un emisor se define como la ocurrencia de cualquiera de
→timeout o
→recepción de 3 ACKs duplicados del receptor.
Debido a la congestión excesiva, el búfer del enrutador a lo largo del camino se desborda. Esto causa un
datagrama a ser descartado.
El datagrama perdido, a su vez, resulta en un evento de pérdida en el remitente.
El remitente considera el evento de pérdida como una indicación de congestión en la ruta.
¿Cómo se detecta la congestión?
Considere que la red está libre de congestión.
Los reconocimientos por segmentos previamente no reconocidos serán recibidos por el remitente.
TCP
tomará la llegada de estos reconocimientos como una indicación de que todo está bien y
→ utilizará reconocimientos para aumentar el tamaño de la ventana (& por lo tanto la tasa de datos).

Se dice que TCP tiene auto-reloj porque

Las confirmaciones se utilizan para activar el aumento en el tamaño de la ventana.
El algoritmo de control de congestión tiene 3 componentes principales:
1) Comienzo lento
2) Evitación de la congestión y
3) Recuperación rápida.

Si tratas a las personas bien, ellas te tratarán bien... el 90% del tiempo.

2-43
REDES DE COMPUTADORAS
[Link] Comienzo Lento
• Cuando comienza una conexión TCP, el valor de cwnd se inicializa en 1 MSS.
•TCP duplica el número de paquetes enviados cada RTT en una transmisión exitosa.
• Así es como funciona:
Como se muestra en la Figura 2.42, el TCP
→envía el primer segmento a la red y
→espera un reconocimiento.
When an acknowledgment arrives, the sender
aumenta la ventana de congestión en un MSS y
→envía 2 segmentos.
Cuando llegan dos reconocimientos, el remitente
→aumenta la ventana de congestión en un MSS y
→envía 4 segmentos.
Este proceso resulta en un duplicado de la tasa de envío cada RTT.
Así, la tasa de datos TCP comienza lenta pero crece exponencialmente durante la fase de arranque lento.

Figura 2.42: Inicio lento de TCP

• When should the exponential growth end?

Un comienzo lento proporciona varias respuestas a esta pregunta.
1) Si hay un evento de pérdida, el remitente
→ establece el valor de cwnd en 1 y
umbral de inicio lento
→comienza de nuevo el proceso de inicio lento. (ssthresh
→establece el valor de ssthresh a cwnd/2.
2) Cuando el valor de cwnd es igual a ssthresh, TCP entra en el estado de evitación de congestión.
3) Cuando se detectan tres ACK duplicados, TCP
realiza una retransmisión rápida y
→entra en el estado de recuperación rápida.
• TCP’s behavior in slow start is summarized in FSM description inFigure 2.43.

Los hombres no son prisioneros del destino, sino solo prisioneros de sus propias mentes.

2-44
REDES DE COMPUTADORAS

Figura 2.43: Descripción de FSM del control de congestión TCP

El éxito es hacer cosas ordinarias de manera extraordinaria.

2-45
REDES INFORMÁTICAS
[Link] Evitación de Congestión
• Al entrar en el estado de evitación de congestión, el valor de cwnd es aproximadamente la mitad de su valor anterior.
Por lo tanto, el valor de cwnd se incrementa en un solo MSS cada RTT.
• El remitente debe aumentar cwnd en bytes MSS (MSS/cwnd) cada vez que llega un nuevo reconocimiento.
¿Cuándo debería terminar el aumento lineal (de 1 MSS por RTT)?
1) Cuando ocurre un tiempo de espera.
Cuando ocurrió el evento de pérdida,
→el valor de cwnd se establece en 1 MSS y
El valor de ssthresh se establece en la mitad del valor de cwnd.
2) Cuando ocurre un ACK duplicado triple.
Cuando se recibieron los ACK triples duplicados,
el valor de cwnd se reduce a la mitad.
El valor de ssthresh se establece en la mitad del valor de cwnd.

[Link] Recuperación Rápida

El valor de cwnd se incrementa en 1 MSS por cada ACK duplicado recibido.
Cuando llega un ACK para el segmento perdido, se ingresa al estado de evitación de congestión.
• Si ocurre un evento de timeout, la recuperación rápida pasa al estado de inicio lento.
• Cuando ocurrió el evento de pérdida
→el valor de cwnd se establece en 1 MSS, y
El valor de ssthresh se establece en la mitad del valor de cwnd.
• Hay 2 versiones de TCP:
1) TCP Tahoe
Una versión temprana de TCP era conocida como TCP Tahoe.
TCP Tahoe
→reduzca la ventana de congestión a 1 MSS y
→entró en la fase de inicio lento después de que ya sea
i) indicado por tiempo de espera o
ii) evento de pérdida indicado por triple duplicado de ACK.
2) TCP Reno
La versión más nueva de TCP se conoce como TCP Reno.
TCP Reno incorporó la recuperación rápida.
La figura 2.44 ilustra la evolución de la ventana de congestión de TCP tanto para Reno como para Tahoe.

Figure 2.44: Evolution of TCP’scongestion-window (Tahoe and Reno)

El principio es la parte más importante del trabajo.

2-46
REDES DE COMPUTADORAS
[Link] Control de Congestión TCP: Retrospectiva
• El control de congestión de TCP consiste en (AIMD aumento aditivo, disminución multiplicativa
→Aumentando linealmente (aditivo) el valor de cwnd en 1 MSS por RTT y
→Reducción a la mitad (decrecimiento multiplicativo) del valor de cwnd en un evento de tres ACK duplicados.
Por esta razón, el control de congestión TCP se conoce a menudo como AIMD.
El control de congestión AIMD da lugar al comportamiento de "diente de sierra" que se muestra en la Figura 2.45.
• TCP
aumenta linealmente el tamaño de la ventana de congestión hasta que ocurre un evento de triple ACK duplicado y
→ disminuye entonces el tamaño de la ventana de congestión por un factor de 2

Figura 2.45: Control de congestión de aumento aditivo y disminución multiplicativa

O tú controlas el día o el día te controla a ti.

2-47
REDES DE ORDENADORES
2.7.2 Equidad
El mecanismo de control de congestión es justo si cada conexión recibe una parte igual del ancho de banda del enlace.
• Como se muestra en la Figura 2.46, considere 2 conexiones TCP compartiendo un único enlace con una tasa de transmisión R.
• Suponga que las dos conexiones tienen el mismo MSS y RTT.

Figura 2.46: Dos conexiones TCP compartiendo un único enlace de estrangulamiento

La Figura 2.47 muestra el rendimiento realizado por las dos conexiones TCP.
Si TCP comparte el ancho de banda del enlace de manera equitativa entre las 2 conexiones,
entonces el rendimiento cae a lo largo de la flecha de 45 grados que parte del origen.

Figura 2.47: Rendimiento realizado por las conexiones TCP 1 y 2

[Link] Equidad y UDP

Muchas aplicaciones multimedia (como el teléfono por Internet) a menudo no funcionan a través de TCP.
• En cambio, estas aplicaciones prefieren ejecutarse sobre UDP. Esto se debe a que
→las aplicaciones pueden inyectar su audio en la red a una tasa constante y
→ ocasionalmente perder paquetes.

[Link] Equidad y Conexiones TCP Paralelas

Los navegadores web utilizan múltiples conexiones paralelas para transferir los múltiples objetos dentro de una página web.
Así, la aplicación obtiene una mayor fracción del ancho de banda en un enlace congestionado.
El tráfico web es tan omnipresente en Internet; las conexiones paralelas múltiples son comunes en la actualidad.

Cuida tu cuerpo. Es el único lugar en el que tienes que vivir.

2-48
REDES DE COMPUTADORAS

PREGUNTAS POR MÓDULOS

PARTE 1
1) Con un diagrama, explica la multiplexión y demultiplexión. (6*)
2) Explica la importancia del número de puerto de origen y del número de puerto de destino en un segmento. (4*)

3) Con un diagrama, explica el multiplexado y demultiplexado sin conexión. (4)

4) Con un diagrama, explica el multiplexión y demultiplexión orientados a la conexión. (4)
5) Explicar brevemente UDP y sus servicios. (6*)
6) Con formato general, explica varios campos del segmento UDP. Explica cómo se calcula el checksum (8*)
7) Con un diagrama, explica el funcionamiento de rdt1.0. (6)
8) Con un diagrama, explica el funcionamiento de rdt2.0. (6*)
9) Con un diagrama, explica el funcionamiento de rdt2.1. (6)
10) With a diagram, explain the working of rdt3.0. (6*)
11) Con un diagrama, explica el funcionamiento de Go-Back-N. (6*)
12) Con un diagrama, explica el funcionamiento de la repetición selectiva. (6*)
13) Explica los siguientes términos: (8)
i) Número de secuencia
ii) Reconocimiento
iii) Reconocimiento negativo
iv) Ventana, canalización

PARTE 2
14) Explica brevemente TCP y sus servicios. (6*)
15) Con formato general, explique varios campos del segmento TCP. (6*)
16) Con un diagrama, explica la importancia de los números de secuencia y de reconocimiento. (4*)
17) Con un diagrama, explica la transferencia de datos confiable con algunos escenarios interesantes. (8)
18) Con un diagrama, explica la retransmisión rápida en TCP. (6*)
19) Con un diagrama, explica el control de flujo en TCP. (6)
20) Con un diagrama, explica la gestión de conexiones en TCP. (8*)
21) Con un diagrama, explica las causas de la congestión con algunos escenarios. (8)
22) Explica brevemente los enfoques para el control de congestión. (6*)
23) Con un diagrama, explica el control de congestión ABR de ATM. (8)
24) Con un diagrama, explica el lento inicio en TCP. (6*)
25) Con un diagrama, explica la recuperación rápida en TCP. (6*)

La vida es como montar en bicicleta. Para mantener tu equilibrio, debes seguir adelante.

2-49