Multipath TCP para Linux (2022)

Resumen de Multipath TCP

• Multipath TCP (MPTCP) es una extensión del TCP estándar y está descrita en la RFC 8684
• Permite que un dispositivo use varias interfaces al mismo tiempo para enviar y recibir paquetes TCP a través de una sola conexión MPTCP
• MPTCP puede agregar el ancho de banda de varias interfaces o priorizar la interfaz con menor latencia
• Además, incluso si una ruta se cae, permite failover y el tráfico se reinserta sin interrupciones por otra ruta

Casos de uso de MPTCP

• Al permitir usar varias rutas en paralelo o simultáneamente con MPTCP, surgen nuevos casos de uso frente a TCP:
  • Seamless handovers: cambiar de una ruta a otra manteniendo la conexión. Apple usa principalmente MPTCP en smartphones por esta razón desde 2013.
  • Best network selection: usar la ruta “óptima” según ciertas condiciones como latencia, pérdida, costo o ancho de banda.
  • Network aggregation: usar varias rutas al mismo tiempo para obtener mayor throughput. Ej.: combinar red fija y red móvil para enviar archivos más rápido.

Conceptos de MPTCP

• Al crear un nuevo socket con el protocolo IPPROTO_MPTCP (solo Linux), se genera un subflujo (o ruta) compuesto por una conexión TCP normal que se usa para transmitir datos a través de una interfaz
• Los subflujos adicionales pueden negociarse más adelante entre hosts
• Se agregan nuevos campos al campo de opciones TCP del subflujo TCP inicial para que el host remoto pueda detectar el uso de MPTCP
• Estos campos incluyen opciones como MP_CAPABLE, que le indican al otro host que use MPTCP si lo soporta
• Si el host remoto o un middlebox intermedio no soporta MPTCP, el paquete SYN+ACK devuelto no incluirá opciones de MPTCP en el campo de opciones TCP
• En ese caso, la conexión se “degrada” a TCP normal y continúa por una sola ruta

Este comportamiento es posible gracias a dos componentes internos: Path Manager y Packet Scheduler.

Path Manager

• Path Manager se encarga de los subflujos desde su creación hasta su eliminación, y también de anunciar direcciones
• En general, el lado cliente inicia los subflujos y el lado servidor anuncia direcciones adicionales mediante las opciones ADD_ADDR y REMOVE_ADDR
• A partir de Linux v5.19, existen 2 Path Manager controlados por la perilla sysctl net.mptcp.pm_type:
  • in-kernel (tipo 0): aplica las mismas reglas a todas las conexiones (ver ip mptcp)
  • userspace (tipo 1): controlado por un daemon en espacio de usuario (por ejemplo, mptcpd) y puede aplicar reglas distintas para cada conexión

Packet Scheduler

• Packet Scheduler se encarga de seleccionar, entre los subflujos disponibles, cuál usar para enviar el siguiente paquete de datos
• Puede decidir políticas como maximizar el uso del ancho de banda disponible, elegir solo la ruta con menor latencia u otras según la configuración
• A partir de Linux v6.8, solo existe un Packet Scheduler controlado por perillas sysctl de net.mptcp

Características principales de MPTCP (a partir de Linux v6.10)

• Soporte del protocolo IPPROTO_MPTCP en la llamada al sistema socket()
• Sustitución de MPTCP por TCP cuando el peer o un middlebox no soportan MPTCP
• Gestión de rutas usando un path manager dentro del kernel o en espacio de usuario
• Opciones de socket usadas habitualmente en sockets TCP
• Funciones de depuración, incluidos contadores MIB, soporte diag (usado por el comando ss) y tracepoints

Opinión de GN⁺

• MPTCP es una tecnología muy útil cuando un dispositivo está conectado a varias redes. Puede aprovecharse eficazmente para handover entre 5G y Wi‑Fi o para agregación entre redes heterogéneas.
• Sin embargo, tiene la limitación de que tanto el servidor como el cliente deben implementarlo, y además la red intermedia debe soportar MPTCP. Parece que tomará tiempo para que se generalice.
• El protocolo QUIC de Google también ofrece funciones multipath similares, y se espera que QUIC se expanda más rápido por ser más simple y estar basado en UDP. Se anticipa una competencia entre MPTCP y QUIC.
• A diferencia de la implementación de MPTCP para Linux, que depende del kernel, Apple implementa MPTCP por su cuenta en espacio de usuario y lo integra en iOS y macOS. Parece posible que Google adopte un enfoque similar.
• Para que el control de rutas y las políticas de scheduling de MPTCP se optimicen según los requisitos de la aplicación, parece necesario intercambiar información entre la aplicación y MPTCP mediante una API. Por lo que se entiende, todavía no existe una forma estandarizada para esto.

[GN⁺]

Comentarios de Hacker News

• Cuando escuché por primera vez sobre MPTCP en 2013, pensé que ayudaría mucho a mejorar la experiencia de usuario porque las apps móviles respondían mal a los cambios de red, pero es muy decepcionante que después de 10 años casi no haya recibido atención
• No sé qué da más tristeza: el espacio de direcciones de 32 bits de IPv4 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 al pasado para cambiar esas dos cosas
• El uso práctico de MPTCP es combinar redes móviles y Wi‑Fi para aumentar la velocidad, pero en lo personal siempre lo tengo desactivado por los planes de datos móviles, así que no me sirve
• Es una lástima que no haya enlaces a proyectos que usan MPTCP, como proyectos derivados de OpenWrt. Durante 2 años, asesoré a un estudiante en GSOC que parcheaba soporte de MPTCP en OpenWrt
• Si existe un fallback transparente, me pregunto por qué sería necesario que la aplicación haga opt-in explícito. Parecería más sensato que el kernel lo manejara de forma transparente para todas las conexiones TCP y tomara decisiones globales sobre agregación de rutas o preferencia de enlaces
• Trabajando en soporte/debugging/modificación del stack de red y de drivers de Linux, me sorprende la baja adopción de MPTCP. Parece que todo lo que ha intentado reemplazar al TCP existente, como SCTP, está destinado a ser usado solo por unos pocos desarrolladores mientras el resto del mundo lo olvida
• Encontré un paper que explica las diferencias de arquitectura entre MPTCP y QUIC, y el protocolo MPQUIC propuesto por los autores. QUIC multiplexa streams de aplicación sobre un único flujo UDP, y MPTCP divide un solo stream en múltiples subflujos TCP. MPQUIC combina ambas funciones al multiplexar streams de aplicación sobre múltiples subflujos UDP
• Apple también soporta MPTCP y lo usa en Siri
• Parece bastante limitante que, si una middlebox en el medio no soporta opciones de MPTCP, el paquete SYN+ACK no incluya la opción MPTCP. ¿El único requisito para la middlebox es simplemente reenviar intacta la opción MPTCP?
• MPTCP podría ayudar con configuraciones de seguridad/privacidad. Por ejemplo, si se divide el tráfico entre varios canales uplink, al firewall del gobierno chino le resulta más difícil recombinar el tráfico para bloquearlo