UNIVERSIDAD AUTÓNOMA LATINOAMERICANA

“TALLER CAPA DE TRANSPORTE”

POR: MANUELA GONZÁLEZ ARBOLEDA

REDES DE DATOS

INGENIERÍA INFORMÁTICA

MEDELLÍN
15/10/2021
 Lineamientos Taller Capa de Transporte

1. Identifique cuál es la variante de TCP que utiliza su dispositivo móvil (Teléfono

Celular). Investigue y describa con sus propias palabras el mecanismo de control
de congestión que utiliza dicha variante de TCP. Mencione las RFC que definen
dicha variante de TCP.
R/: Identifico que la variante TCP que usa mi dispositivo móvil es TCP CUBIC.
Mecanismo de control de congestión: Cuando se experimenta un evento de
congestión se registra el tamaño de la ventana para ese momento como el tamaño
máximo de la ventana (Wmax), se fija este valor Wmax como punto de inflexión de
la función cúbica que es la que va a dirigir el crecimiento de la ventana de congestión.
Seguido a esto, se va a recomenzar la transmisión con un valor menor de ventana y si
no se llega a experimentar alguna congestión entonces dicho valor va a incrementarse
dependiendo de la porción cóncava de la función cúbica. Cuando la ventana se va
aproximando al Wmax, los incrementos se van a ir ralentizando y una vez alcanzado
Wmax, el valor de la ventana va a seguir aumentando de una forma discreta. Por
último, si la red continúa sin experimentar alguna congestión, el tamaño de la ventana
sigue aumentando respecto a la porción convexa de la función cúbica.
Vemos entonces que CUBIC hace una implementación de grandes incrementos al
inicio que van disminuyendo alrededor del tamaño de la ventana que generó la última
congestión para seguir aumentando con grandes incrementos.

CUBIC está documentado en RFC8312.

2. Identifique cuál es la variante de TCP que utiliza su computador (portátil o de

escritorio), según la versión actual de sistema operativo. Investigue y describa
con sus propias palabras el mecanismo de control de congestión que utiliza dicha
variante de TCP. Mencione las RFC que definen dicha variante de TCP.
Identifique para las 3 últimas versiones mayores del sistema operativo
identificado en su dispositivo, cuáles han sido las variantes de TCP que han sido
utilizadas
R/: Identifico que la variante TCP que utiliza mi computador portátil según la versión
actual del sistema operativo, es TCP SACK. Esta variante es importante porque se
usa para las conexiones que utilizan grandes tamaños de ventana TCP.
Mecanismo de control de congestión: Los algoritmos implementados en SACK
para el control de la congestión son prácticamente los mismos implementados en
Reno, diferenciándose en que en SACK se incluye una variable llamada pipe, la cual
lleva cuenta de la cantidad de paquetes que se mueven por la red en modo rápida
recuperación. Además de ello, adopta un comportamiento diferente en el momento
en el que tiene múltiples paquetes perdidos en una misma ventana. El nodo de
transmisión sólo hace su labor de retransmitir paquetes cuando el número de paquetes
estimado que se mueve por la red es menor que la ventana de congestión.
Ahora bien, cuando se retransmite un paquete anterior o se envía uno nuevo, la
variable pipe se incrementa en 1 y, cuando el nodo que envía recibe un
reconocimiento con la opción SACK, se reduce en 1 indicando así qué paquetes
nuevos ha recibido el destinatario.
Se puede descartar un paquete o serie de paquetes con SACK. El receptor le brinda
información al remitente sobre qué datos han sido recibidos y dónde puede haber
“vacíos” en los datos. Aquí el remitente puede hacer retransmisión selectiva de los
datos faltantes (sin retransmitir aquellos bloques de datos que ya se recibieron con
éxito).
Las RFC que definen esta variante son:
RFC6675
RFC2018
RFC3517
RFC1072
RFC2883

TCP SACK proporciona el soporte que se describe en la RFC2018 con la finalidad

de solucionar problemas relacionados con la congestión y pérdida de múltiples
paquetes, en especial en aplicaciones que utilizan ventanas grandes de TCP mediante
enlaces vía satélite o enlaces transcontinentales.
La RFC1072 hace una descripción de una posible implementación de las opciones
SACK para TCP.
En el RFC6675 se presenta un algoritmo conservador de recuperación de pérdidas
para TCP basado en el uso de TCP SACK. Este documento describe cambios a partir
de RFC3517(obsoleta).

Esta variante SACK es aplicable a todas las ediciones Windows10.

En las últimas tres versiones, las variantes TCP que han sido usadas son: TCP
CUBIC, TCP RENO y TCP SACK.
- TCP CUBIC: Cuya intención es disponer de un algoritmo que trabaje con
ventanas de congestión, cuyos procesos de incremento sean más agresivos,
restringiéndose de sobrecargar la red.
- TCP RENO: Cuyos algoritmos evitan la congestión, retransmisión y
recuperación rápida. La última mejora evita que el canal se quede desocupado
después de hacer una retransmisión.
- TCP SACK: Del cual hablamos al comienzo del punto. Aquí los algoritmos de
control de congestión son prácticamente los mismos que se implementan para
RENO, pero con la diferencia de que SACK incluye la variante pipe.
3. Una variante del protocolo TCP que fue propuesta hace algunos años para su
uso en redes de Centro de Datos fue el protocolo DCTCP. Este protocolo tiene
una característica particular con respecto a la gestión de la congestión.
◦ Cuál es esa característica que diferencia la operación de DCTCP con
respecto a otras variantes de TCP?
R/: DCTCP es un protocolo parecido a TCP para redes de centros de datos.
DCTCP ofrece el mismo o incluso mejor rendimiento que TCP utilizando un
90% menos de espacio de búfer. A diferencia de TCP, esta variante DCTCP
proporciona alta tolerancia a ráfagas y baja latencia para los flujos cortos,
incluso emplea un esquema de administración de cola activa muy simple. Se
recomienda usarlo sólo en entornos de red controlados.
Esta variante soluciona tres deficiencias como lo son la acumulación de colas,
la presión del búfer y el incast.
En la acumulación de colas, los remitentes DCTCP reaccionan tan pronto
como la longitud de la cola en una interfaz excede K, reduciendo así los
retrasos en las colas en los puertos del conmutador congestionados,
minimizando el impacto de los flujos largos en el tiempo de finalización de
los flujos pequeños.
Resuelve el problema de la presión del búfer, ya que la longitud de la cola de
un puerto congestionado no crece demasiado.
En cuanto al incast, como DCTCP marca, por así decirlo, de forma agresiva y
en función de la longitud instantánea de la cola , las fuentes de DCTCP reciben
suficientes marcas durante los primeros uno o d os RTT para controlar el
tamaño de las ráfagas de seguimiento, evitando de esta manera los
desbordamientos del búfer y los tiempos de espera resultantes.

◦ Qué rol cumple en este protocolo el mecanismo de Notificación Explícita

de Congestión (Explicit Congestion Notification – ECN)?
R/: DCTCP aprovecha la notificación explícita de congestión (o denominada
ECN) en la red para suministrar retroalimentación a los hosts finales de
múltiples bits. También combina la notificación explícita de congestión con
un esquema nuevo de control en las fuentes y extrae retroalimentación multibit
sobre la congestión en la red a partir del flujo de bits único de las marcas ECN.
Las fuentes estiman la fracción de paquetes marcados y entonces utilizan
dicha estimación como una señal del grado de congestión. Así, esto permite
que esta variante DCTCP funcione con ocupaciones de búfer muy bajas y al
mismo tiempo alcanza un alto rendimiento.

◦ Qué significan los parámetros K, alfa y g

R:/ -k es el umbral de marcado.
-alfa es la fracción de paquetes marcados.
-g es el parámetro de ajuste de la ventana.
4. El protocolo TCP Hybla se utiliza típicamente para el manejo de conexiones en
enlaces satelitales, e inclusive en las conexiones que corresponden a vehículos
orbitales o naves espaciales.
◦ Por qué hay una particularidad en este tipo de enlaces que hace que las
conexiones requieran un tratamiento particular?
R/: Porque se buscó enfatizar en el problema de la degradación del
rendimiento de TCP con el control de congestión estándar en las redes de
retardo largo. Un flujo con un RTT más corto siempre va a ser más ventajoso
en comparación con un flujo con un RTT más largo. Entonces en redes
heterogéneas, especialmente con segmentos de satélite, los RTT difieren en
varios órdenes de magnitud, lo cual se puede convertir en una injusticia
catastrófica en cuanto a la distribución de los recursos de la red . Los enlaces
por satélite se ven afectados por los retrasos de propagación prolongados y
tasas de error relativamente altas, y frente a todo esto tenemos que las
variantes de control de congestión de TCP estándar no fueron diseñadas para
enfrentar estos desafíos. Generalmente dependen de los tiempos de ida y
vuelta o RTT, y sufren mucho si estos RTT son grandes. Por esta razón se
plantea esta variante TCP Hybla (algoritmo Hybla) como una solución a este
problema de injusticia RTT.

◦ Cuál es la propiedad de Hybla que hace que sea un protocolo adecuado

para estos escenarios?
R/: TCP Hybla reduce en gran medida la penalización que sufren las
conexiones TCP inalámbricas, especialmente por satélite. La idea clave detrás
de TCP Hybla es conseguir para las conexiones RTT largas la misma
velocidad de transmisión instantánea de una conexión TCP de referencia con
RTT más bajo. Esto se puede conseguir modificando la escala de tiempo para
que el rendimiento sea independiente del RTT. Esta independencia se
consigue usando el coeficiente rho. Además de todo ello, Hybla no infringe la
semántica de extremo a extremo del protocolo TCP. También, el hecho de
Hybla presentar una solución prometedora al problema de injusticia RTT o
disparidad del rendimiento en las redes heterogéneas debido a distintas RTT,
todo esto hace que sea un protocolo adecuado para estos escenarios.