Què està passant a la capa 4?
0 recomendaciones165 vistas
El documento examina la capa 4 de la pila TCP/IP, enfocándose en la evolución de los protocolos TCP y UDP, así como los mecanismos de control de congestión que han sido desarrollados para optimizar la transferencia de datos. Se discuten algoritmos modernos como BBR y CUBIC, y se mencionan las limitaciones del protocolo TCP en situaciones de red cambiantes. Además, se presenta QUIC como un nuevo protocolo de transporte que busca mejorar la eficiencia y la rapidez en la transmisión de datos en la red.
![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](https://image.slidesharecdn.com/capa4-221129081645-c967d991/85/Que-esta-passant-a-la-capa-4-9-320.jpg)
Què està passant a la capa 4?
- 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
- 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?