Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 33 Anzeige
Anzeige

Weitere Verwandte Inhalte

Weitere von CSUC - Consorci de Serveis Universitaris de Catalunya (20)

Aktuellste (20)

Anzeige

Què està passant a la capa 4?

  1. 1. ¿Qué está pasando en la capa 4? João Damas, Geo ff Huston
  2. 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. 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. 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. 5. ¿Qué pinta tiene TCP en la red?
  6. 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. 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. 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. 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. 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. 11. Midiendo la congestión • Pérdida vs latencia • Pérdida: Reno y (CU)BIC • Latencia: Vegas, BBR, LEDBAT
  12. 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. 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. 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. 15. ¿Cómo se detecta el comienzo del llenado de buffers? • Midiendo el RTT
  16. 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. 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. 18. BBR • Comportamiento ideal
  19. 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. 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. 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. 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. 23. Volviendo a la evolución de TCP
  24. 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. 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. 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. 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. 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. 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. 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. 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. 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. 33. ¿Preguntas?

×