1.
¿Qué está pasando en la capa 4?
João Damas, Geo
ff
Huston

2.
Capa 4 en la Internet
• La historia canónica es que TCP/IP tiene dos protocolos en la capa 4
(transporte):
• UDP: simple, no
fi
able, sin concepto de conexión
• TCP:
fi
able, orientado a conexiones

3.
UDP (RFC 768)
• Es poco más que añadir el concepto de puerto/servico por encima de
IPv(4|6)
• Muy ligero (añade 8 bytes a un paquete IP)
• Normalmente se usa para transacciones cortas o streaming donde
puede que sea inútil recuperar la pérdida de un paquete

4.
TCP (RFC 793)
• El protocolo de transporte usado para la gran mayoría de intercambios en la Internet.
• Desde su primera de
fi
nición ha visto algunos cambios y aclaraciones
• Cambios visibles en las cabeceras
• Bits originariamente reservados usados ahora usados para señalización ECN
• Cambios en el proceso de los emisores y receptores
• MP-TCP, congestión
• La mayoría de estas aportaciones al estándar han sido refundidas en un nuevo RFC,
el 9293, en Agosto de 2022

5.
¿Qué pinta tiene TCP en la red?

6.
Evolución de TCP
• Fuera de los bits que se ven en las cabeceras de TCP existen una serie de
algoritmos que son fundamentales y que si han visto mucha evolución
• Son los llamados mecanismos de control de congestión

7.
Mecanismos de control de congestión
• Son los encargados de controlar la velocidad de transmisión de datos en
una sesión TCP
• En general, tienen dos objetivos:
• Hacer el mayor uso posible del ancho de banda disponible
• Evitar congestión en la red
• Pérdida de paquetes por exceder la capacidad de los enlaces
• Aumento de la demora por llenado de bu
ff
ers

8.
Mecanismos de control de congestión
• Dos categorias principales:
• Basados en la detección de pérdidas de paquetes
• Basados en un modelo de la red
• Intentan estimar los dos componentes del producto BWxRTT

9.
Mecanismos de control de congestión
Variant Feedback
Required
changes
Bene
fi
ts Fairness
(New)
Reno
Loss — — Delay
Vegas Delay Sender Less loss Proportional
High
Speed
Loss Sender High bandwidth
BIC Loss Sender High bandwidth
CUBIC Loss Sender High bandwidth
C2TCP[11][12] Loss/Delay Sender
Ultra-low latency and high
bandwidth
NATCP[13]
Multi-bit
signal
Sender
Near Optimal
Performance
Elastic-
TCP
Loss/Delay Sender
High bandwidth/short &
long-distance
Agile-TCP Loss Sender
High bandwidth/short-
distance
H-TCP Loss Sender High bandwidth
FAST Delay Sender High bandwidth Proportional
Compound
TCP
Loss/Delay Sender High bandwidth Proportional
Westwood Loss/Delay Sender L
Jersey Loss/Delay Sender L
BBR Delay Sender BLVC, Bufferbloat
CLAMP
Multi-bit
signal
Receiver, Router V Max-min
TFRC Loss Sender, Receiver No Retransmission
Minimum
delay
XCP
Multi-bit
signal
Sender, Receiver,
Router
BLFC Max-min
VCP 2-bit signal
Sender, Receiver,
Router
BLF Proportional
MaxNet
Multi-bit
signal
Sender, Receiver,
Router
BLFSC Max-min
JetMax
Multi-bit
signal
Sender, Receiver,
Router
High bandwidth Max-min
RED Loss Router Reduced delay
ECN
Single-bit
signal
Sender, Receiver,
Router
Reduced loss
A estos cabe añadir los “less than best e
ff
ort”, tipo LEDBAT(++)
Tabla tomada de la wikipedia

10.
Mecanismos de control de congestión
¿Cómo afectan a la red?
• Todos queremos que nuestros datos se trans
fi
eran lo más rápido posible
y que nuestras conexiones se establezcan al instante.
• ¿Qué pasa cuándo no estamos solos en la red?
• ¿Cómo averiguamos de que velocidad es capaz la red que nos une a
nuestro punto de destino?

11.
Midiendo la congestión
• Pérdida vs latencia
• Pérdida: Reno y (CU)BIC
• Latencia: Vegas, BBR, LEDBAT

12.
CUBIC
• CUBIC se enfoca a obtener alta velocidad en sesiones intentando comportarse de
forma justa con otras sesiones y mantenerse e
fi
ciente a bajas velocidades
• En lugar de explorar a que capacidad de red se detectan perdidas de una forma
lineal, CUBIC usa un algoritmo de búsqueda no-lineal (cúbico)

13.
CUBIC
• CUBIC es bastante bueno:
• Puede usar rápidamente la
capacidad de la red
• Pasa bastante tiempo si saturar la
cola
• Reacciona bien en lineas de alta
capacidad y larga distancia
• Por otro lado, tiende a saturar los
bu
ff
ers

14.
¿Esto se puede mejorar?
• Al enviar datos por encima de la
capacidad de la red, se acumulan
paquetes en los bu
ff
ers
• Se incrementa la latencia
• Si la situación persiste se pierden
paquetes
• https://queue.acm.org/detail.cfm?id=3022184
• https://www.potaroo.net/presentations/2018-05-10-bbr.pdf

15.
¿Cómo se detecta el comienzo del llenado de
buffers?
• Midiendo el RTT

16.
Midiendo latencia
• Vegas: 1994, Lawrence Brakmo, Larry Peterson, U Arizona
• BBR: 2016, Invento de Google y Van Jacobson
• LEDBAT: 2012, Usado por Apple/MS para bajar actualizaciones y por el
protocolo uTP de BitTorrent (Less than best e
ff
ort)

17.
BBR
• Principios
• Tantear la capacidad del enlace de forma intermitente
• Tantear la capacidad incremento el ritmo de envío durante un breve periodo volviendo
a bajarlo
• Si el RTT medido no cambia, signi
fi
ca que hay capacidad disponible
• Si el RTT se incrementa es posible que hayamos empezado a formar una cola
• Ignorar la perdida de paquetes a la hora de estimar el ancho de banda
• Mantener el máximo ritmo descubierto anteriormente y volver a probar de forma
intermitente

18.
BBR
• Comportamiento
ideal

19.
BBR en la práctica
• Hemos usado iperf3 sobre Linux (kernel 4.9)
• Atravesando la Internet (no en una red local o laboratorio)

20.
BBR en la práctica
• Brutal!
• BBR hecha a CUBIC de la red y
es incapaz de volver a crecer
• Parece que BBR establece su
estado de equilibrio no al
formarse las colas sino al
llenarlas por entero

21.
BBR en la práctica
• Prueba en la Internet entre Europa y
Australia
• CUBIC pierde
• Dos sesiones BBR simultáneas luchan y
oscilan

22.
BBR en la práctica
• Cuando la red pierde paquetes BBR
empieza a explorar
• Cuando desaparece la pérdida de
paquetes las oscilaciones son mínimas

23.
Volviendo a la evolución de TCP

24.
Evolución de TCP
¿Qué le falta?
• A lo largo de los años se han ido echando en falta algunas características en
TCP
• La posibilidad de sobrevivir a cambios en la red
• Por ejemplo, un dispositivo que pasa de usar una Wi
fi
a usar una red de
datos celular ( o viceversa), donde cambia la capa IP
• Usar varios caminos simultáneamente pre
fi
riendo cual de ellos se usa
en algún momento aunque sigan todos disponibles
• La posibilidad de tener más de un
fl
ujo de datos en una misma sesión de
TCP

25.
Problemas que previenen la evolución del
transporte
• Dispositivos de red que:
• Malinterpretan los estándares
• Sone restrictivos en puntos donde no debieran
• No se actualizan
• Middle boxes, sobre todo
• Routers, NATs, CPEs
• Firewalls

26.
La razón de fondo
No haber sido
fi
eles al diseño original
• Una de las principales razones del éxito de Internet frente a otras redes
anteriores reside en su principio más básico
• UNA RED SIMPLE QUE UNE NODOS INTELIGENTES
• TCP ha podido evolucionar en los aspectos que controlan los nodos que se
están comunicando (hosts) pero no en lo que se re
fl
eja en los paquetes que
aparecen en la red
• Otros intentos de modi
fi
car los protocolos de transporte (ej. SCTP) no han
tenido éxito por esta razón

27.
Evolución
• Las aplicaciones de la red cambian y la red tienen que encontrar la forma de
ofrecer respuestas
• Redes móviles
• Aplicaciones interactivas de baja latencia
• El deseo de cambiar protocolos estaba ahi, sobretodo en los equipos de ingeniería
de sitios como Google, etc
• Empezaron con mejoras en HTTP -> SPDY, HTTP/2 (Google controla Chrome y
sus servidores)
• Cambios en sus redes internas de distribución (datacenter e inter-datacenter)

28.
¿Cómo seria el transporte ideal?
• Desplegable desde el primer dia
• Baja latencia
• Multiplexación
• Privacidad
• Fiable (en el sentido de TCP)
• Soporta migración de conexiones
• Compare bien la red con protocolos existentes (gestión de congestión)
• Reutiliza tecnologías existentes

29.
¿Cómo seria el transporte ideal?
• Preservar la posibilidad de evolucionar
• Encriptar todo, todo, todo de forma que los middleboxes no interferir
• Poner todo como una capa sobre UDP
• mínimo overhead
• Alta probabilidad de que se acepte el trá
fi
co

30.
QUIC: un nuevo protocolo de transporte
• En el año 2012 Jim Roskind del grupo de Chromium creó la propuesta
para un nuevo protocolo
• https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-
saqsQx7rFV-ev2jRFUoVD34/edit?usp=sharing

31.
QUIC en el IETF
• Google presentó la versión inicial de QUIC en 2015
• Grupo de trabajo formado ~1 año después
• Muchísimas mejoras conservando las ideas originales
• Adición de TLS 1.3
• 0-rtt
• Flow control
• Congestion control (BBRv2, LEDBAT, etc)

32.
QUIC en la red hoy
• Los mayores generadores de tra
fi
co QUIC en la actualidad son las
plataformas que controlan los dos extremos del sistema:
• Google/Youtube+Chrome, Meta+(instagram/Facebook, Net
fl
ix
• QUIC puede representar fácilmente el 75% de su trá
fi
co
• El trá
fi
co QUIC fuera de estos sistema era en Enero alrededor del 5%

33.
¿Preguntas?