Multipath TCP para Linux (2022)

 (mptcp.dev)
1 puntos por GN⁺ 2024-04-21 | 1 comentarios | Compartir por WhatsApp
  • MPTCP es una extensión de TCP basada en RFC 8684, que permite que una sola conexión use simultáneamente varias interfaces de red para mejorar el ancho de banda, la latencia y la respuesta ante fallas
  • Como usa varias rutas en paralelo, permite agregación de ancho de banda, preferir rutas de baja latencia y reinyectar tráfico por otra ruta cuando una falla
  • En Linux, se crea un socket con IPPROTO_MPTCP y se configuran subflows, que son conexiones TCP normales; si el otro extremo o algún equipo intermedio no lo soporta, se degrada automáticamente a TCP de ruta única
  • Para la gestión de rutas, en Linux v5.19 existen el modo integrado en el kernel y el modo con un demonio de espacio de usuario como mptcpd; en Linux v6.8 solo hay un planificador de paquetes, controlado mediante sysctl en net.mptcp
  • En Linux v6.10, las funciones incluyen soporte de socket(), degradación a TCP, gestión de rutas en kernel/espacio de usuario, opciones de socket TCP, contadores MIB, diagnósticos con ss y depuración con tracepoints

Cómo MPTCP cambia la forma de las conexiones TCP

  • Multipath TCP(MPTCP) es una extensión del TCP estándar, definida en RFC 8684
  • Una sola conexión MPTCP puede enviar y recibir paquetes TCP usando varias interfaces al mismo tiempo
  • Puede agregar el ancho de banda de varias interfaces o priorizar la interfaz con menor latencia
  • Si una ruta se cae, reinyecta el tráfico de forma fluida por otra ruta para realizar una conmutación por falla
  • A diferencia del TCP común, que usa una sola ruta a la vez, MPTCP puede usar varias rutas, como 5G y Wi‑Fi, en conjunto como subflows

Casos de uso representativos

  • Handover sin interrupciones

    • Permite cambiar de una ruta a otra manteniendo la conexión existente
    • Apple usa Multipath TCP en smartphones desde 2013 principalmente por este motivo

  • Selección de la red óptima

    • Elige la “mejor” ruta entre las disponibles según condiciones como latencia, pérdida, costo y ancho de banda

  • Agregación de redes

    • Permite aumentar el throughput usando varias rutas al mismo tiempo
    • Un ejemplo es combinar una red fija con una red móvil para transferir archivos más rápido

Cómo se establece una conexión en Linux

  • Al crear un nuevo socket con el protocolo exclusivo de Linux IPPROTO_MPTCP, se genera un subflow o path
  • Un subflow es una conexión TCP normal que transmite datos a través de una interfaz
  • Luego, mediante negociación entre hosts, se pueden crear subflows adicionales
  • En el campo de opciones TCP del subflow TCP subyacente se agregan nuevos campos para que el host remoto pueda detectar el uso de MPTCP
    • Este campo incluye, entre otras, la opción MP_CAPABLE, que informa al otro extremo que se usará MPTCP
  • Si el host remoto o un middlebox intermedio no soporta MPTCP, el campo de opciones TCP del paquete SYN+ACK devuelto no incluye opciones MPTCP
    • En ese caso, la conexión se degrada a TCP normal y continúa por una sola ruta

Gestor de rutas y planificador de paquetes

  • Internamente, MPTCP divide el trabajo entre un Path Manager y un Packet Scheduler, que se encargan de crear subflows, anunciar direcciones y elegir la ruta de transmisión

  • Path Manager

    • El Path Manager gestiona los subflows desde su creación hasta su eliminación, y también se encarga de anunciar direcciones
    • Por lo general, el lado cliente inicia los subflows, y el lado servidor anuncia direcciones adicionales mediante las opciones ADD_ADDR y REMOVE_ADDR
    • En Linux v5.19, dos path managers se controlan mediante el knob sysctl net.mptcp.pm_type
      • type 0: modo integrado en el kernel; aplica las mismas reglas a todas las conexiones. Está relacionado con ip mptcp
      • type 1: modo de espacio de usuario; lo controla un demonio como mptcpd y puede aplicar reglas distintas por conexión

  • Packet Scheduler

    • El Packet Scheduler selecciona el subflow que se usará para enviar el siguiente paquete de datos
    • Puede maximizar el ancho de banda disponible, elegir solo rutas con menor latencia o aplicar otras políticas según la configuración
    • En Linux v6.8 solo hay un planificador de paquetes, controlado mediante knobs sysctl de net.mptcp

Funciones en Linux v6.10

  • En Linux v6.10, MPTCP ofrece las siguientes funciones
    • Soporte del protocolo IPPROTO_MPTCP en la llamada al sistema socket()
    • Degradación de MPTCP a TCP cuando el otro extremo o un middlebox no soporta MPTCP
    • Gestión de rutas con un path manager integrado en el kernel o de espacio de usuario
    • Opciones de socket usadas comúnmente en sockets TCP
    • Contadores MIB, soporte de diag usado por el comando ss y funciones de depuración que incluyen tracepoints
  • Los cambios detallados se pueden consultar en el ChangeLog

Comunicación y proyectos relacionados

Recursos para desarrollo del kernel

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-21
Opiniones de Hacker News

  • Ya había oído hablar de MPTCP en 2013
    Considerando que en ese entonces las apps móviles no eran muy resistentes a los cambios de red, pensé que se adoptaría rápido porque la mejora de UX era grande
    Pero en los últimos 10 años casi no ganó traction, y es bastante deprimente que recién ahora aparezca como opción del kernel. Mientras tanto, todos envolvieron las llamadas HTTP con varios manejadores de reintentos, y los sistemas operativos móviles abstrajeron tanto la conectividad de red que se siente más cercano a usar zeromq que TCP

    • Parece que mucha energía de innovación se trasladó a QUIC. Porque en TCP, aunque se diseñe bien una nueva variante, los equipos intermedios pueden romperla arbitrariamente
      Para un ejemplo, ver https://blog.apnic.net/2021/12/08/efficient-multipath-transp...
    • Quería que me gustara, y Apple también lo incluyó en iOS, pero era demasiado difícil soportarlo en servidores reales
      Cuando lo desplegamos en FreeBSD sin balanceador de carga, no tenía los parches más recientes; e incluso si los hubiera tenido, habría requerido bastante trabajo evitar que anunciara IPs de redes privadas como rutas alternativas
      En Linux, cuando estaba detrás de un balanceador de carga, enviar el stream al lugar correcto era demasiado complejo, y el balanceador tampoco quería hacerlo
      Procesar dos streams juntos implica meter mucha complejidad en la ruta de alto rendimiento, así que es muy riesgoso, y para cambiarlo también hace falta reiniciar
      Incluso haciendo todo eso, el beneficio va principalmente a usuarios de iOS, que para empezar suelen usar mejores redes
    • También vale la pena mirar SCTP, que salió en 2000. Este tampoco ha logrado mucha adopción hasta hoy
      https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
    • Cuando construía robots de reparto, tenía expectativas en MPTCP porque quería conmutación por error inmediata con 2 módems celulares
      Al final usamos SpeedFusion de PepLink para ahorrar tiempo de desarrollo, pero el costo de licencia era alto. Espero que en el futuro aparezca una solución gratuita para usar 2 redes celulares y tener conmutación por error de menos de 50 ms
      UDP multipath + OpenVPN probablemente también podría ser una solución práctica
    • Más bien, lo deprimente es que esto reciba una atención que no merece. TCP debería ser reemplazado por SCTP, no seguir sumándole hacks que encajan más o menos en la mitad de los casos de uso modernos y dejar que se elija la combinación

  • No sé qué es más triste: que el espacio de direcciones IPv4 tenga solo 32 bits, o que TCP use las direcciones IP de origen/destino en la tupla de conexión
    Si tuviera una máquina del tiempo, volvería con Cerf y Kahn para que cambiaran ambas cosas

    • Me da curiosidad qué quieres decir con cambiar TCP
      ¿Te refieres a la estructura en la que hay que rastrear una conexión con las direcciones IP y puertos de ambos lados, es decir, 4 campos?
    • Creo que ellos dirían que ya nos dieron source routing, que eso es la mitad de lo que quieres, y que está especificado correctamente como opción

  • Es una lástima que no haya enlaces a proyectos que usen MPTCP, por ejemplo algún proyecto derivado de OpenWrt
    Durante 2 años en GSOC mentoreé a un estudiante que parcheó OpenWrt con MPTCP
    https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...

    • Este proyecto podría ser interesante: https://github.com/Ysurac/openmptcprouter
      Hace poco compré una propiedad donde no puedo contratar una línea completa de fibra, pero con 5G obtengo entre 150 y 400 Mbps. Estoy pensando en usar 2 líneas 5G y tunelizar el tráfico con MPTCP hasta un VPS para agrupar las conexiones
    • Hace poco se activó en el kernel de Home Assistant HAOS
      https://github.com/home-assistant/operating-system/pull/3248
    • Un ejemplo en OpenWrt es este
      http://www.openmptcprouter.com/
    • Me pregunto qué ventajas tendría que un router OpenWrt soporte MPTCP
      Me parece que lo más importante sería que lo soporten los servidores web y los dispositivos móviles

  • Si existe una ruta alternativa transparente, no entiendo por qué hace falta que la aplicación lo elija explícitamente
    ¿No podría el kernel manejarlo de forma transparente para todas las conexiones TCP, y así tomar mejores decisiones globales como agregación de rutas o preferencia de enlaces?

    • Entiendo que fue una condición que prácticamente impusieron los mantenedores del subsistema TCP/redes de Linux. Si se miran las primeras discusiones upstream[1], eso ya estaba establecido como regla básica
      La vieja implementación de Multipath TCP anterior a upstream estaba pensada para ser completamente transparente para las aplicaciones, y creo que eso encaja mejor con el propósito del protocolo
      Claro que en muchos casos MPTCP puede funcionar mejor si recibe instrucciones de la aplicación, pero por ejemplo, con solo tener un enfoque estándar del sistema que cree un subflujo sobre la conexión LTE para tener lista la conmutación por error automática, pero sin enviar datos por ese subflujo, habría sido suficiente en el 95% de los casos
      [1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
    • Usar esto significa que, para una sola conexión TCP, puede haber varias IP asociadas en cada extremo. En muchos casos eso requiere soporte o conocimiento explícito por parte de la aplicación
    • Permitir que varias IP se comuniquen sobre la misma conexión TCP puede abrir nuevos agujeros de seguridad
      Por ejemplo, se puede imaginar una aplicación que al momento de conectar compara la IP del cliente con una lista blanca y luego asume que no cambiará

  • Para mí, el único uso práctico de MPTCP es aumentar la velocidad usando la red móvil y Wi‑Fi juntos. Tanto iOS como WeChat lo soportan.
    Pero como la red móvil se cobra por consumo, siempre la tengo apagada. Así que, personalmente, MPTCP no me sirve.

    • He lidiado con este problema. Internamente lo llamábamos el bug del estacionamiento.
      Es la situación en la que la señal Wi‑Fi todavía aparece, pero no hay una conexión adecuada. Con MPTCP, se hace failover a la red celular.

  • Trabajo dando soporte, depurando y corrigiendo el stack de red y los drivers de Linux, y me sorprende que esto haya tenido tan poca adopción.
    Al igual que otras cosas que intentaron reemplazar al TCP común, como SCTP, parece que MPTCP se queda como una tecnología de nicho que algunos desarrolladores de aplicaciones siguen usando, mientras el resto del mundo la olvida.

    • Apple Siri usa MPTCP, así que considerando la cantidad de dispositivos, no es tan fácil decir que sea solo de nicho.

  • Encontré un material que explica las diferencias estructurales entre MPTCP y QUIC, y también presenta el protocolo MPQUIC propuesto por los autores.
    QUIC multiplexa streams de aplicación sobre un único flujo UDP, mientras que MPTCP divide un único stream en varios subflujos TCP. MPQUIC combina ambas características y multiplexa streams de aplicación sobre varios subflujos UDP.
    [1]: "Multipath QUIC: A Deployable Multipath Transport Protocol" https://www.researchgate.net/publication/327122884_Multipath...
    Ahora me da curiosidad cómo se comparan estos protocolos en entornos de producción. ¿Alguien ha usado ambos?

    • MPQUIC todavía está en discusión en la IETF. En la última reunión de la IETF también se discutieron más cambios y, lamentablemente, eso está ralentizando su adopción.
      https://lwn.net/Articles/964377/
      Ambos intentan lograr el mismo objetivo. Técnicamente, se puede crear un comportamiento muy similar. MPTCP está implementado en el kernel de Linux, mientras que QUIC está del lado del espacio de usuario.

  • Apple también lo soporta y lo usa en Siri.
    https://developer.apple.com/documentation/foundation/urlsess...

    • También se puede usar bastante fácilmente en otras apps. Está incluido en la funcionalidad base.
      En 2011 me sorprendió ver que nuestra app de VoIP funcionaba de forma bastante robusta :D

  • Suena bastante limitante que, si cualquiera de los equipos intermedios no lo soporta, el paquete SYN+ACK devuelto no tenga la opción MPTCP en el campo de opciones TCP.
    ¿El único requisito para los equipos intermedios es pasar la opción MPTCP tal cual?

  • Puede ayudar en configuraciones de seguridad y privacidad.
    Por ejemplo, pensando en el Great Firewall de China, si se puede dividir el tráfico entre varios canales de uplink, ¿no se le haría más difícil al firewall reensamblarlo y aplicar sus reglas?

    • Si es tráfico desconocido, basta con bloquearlo o limitarle severamente la velocidad.