Resumen

  • Multipath TCP ofrece a la aplicación un único flujo fiable y ordenado aunque los extremos lo transporten por uno o varios subflujos TCP.
  • MP_CAPABLE negocia la conexión, MP_JOIN autentica cada subflujo adicional y la secuencia común permite retransmitir los mismos datos por otro camino cuando uno falla.
  • Dos interfaces no prueban resiliencia: pueden compartir un cuello de botella, un dispositivo intermedio puede retirar las opciones y la política del extremo decide si el segundo camino está activo, en reserva o ausente.

Un socket que no termina con el Wi-Fi

El cambio de acceso parece un asunto de direcciones. Una deja de servir y otra aparece. Para la aplicación, sin embargo, el objeto valioso es la conversación ya iniciada: una secuencia de bytes fiable, ordenada y asociada a estado que quizá no convenga reconstruir.

RFC 8684 separa esa conexión de sus caminos. Una conexión MPTCP corresponde a un socket de aplicación, pero está formada por uno o más subflujos. Cada subflujo se comporta como TCP en su propio camino. Por encima, la conexión mantiene el orden y los acuses que la aplicación espera. Perder un subflujo no tiene por qué cerrar el conjunto.

La norma no convierte esa posibilidad en garantía. Ambos extremos deben negociar MPTCP; tiene que quedar o poder crearse al menos un subflujo útil; y el estado común debe sobrevivir. El protocolo permite la continuidad, pero no demuestra cobertura, diversidad física ni calidad del camino alternativo.

Añadir un camino es una decisión de admisión

El primer subflujo incluye MP_CAPABLE. Con él, los extremos confirman que entienden MPTCP e intercambian material de clave. Si el otro host no lo admite o un dispositivo de paso elimina las opciones, el diseño puede volver a TCP convencional.

Para añadir otro subflujo se usa MP_JOIN. Un token identifica la conexión; números aleatorios y un HMAC ligado a las claves originales permiten verificar que el nuevo subflujo pertenece a los mismos pares. La política local todavía puede rechazarlo. Tener una dirección adicional no basta para entrar en la conexión.

ADD_ADDR permite anunciar otra dirección y REMOVE_ADDR retirarla. Los identificadores de dirección ayudan cuando un NAT cambia lo que aparece en la cabecera. Aun así, una dirección anunciada solo es una candidata. No acredita que el camino sea alcanzable, independiente, barato o rápido.

El reparto de poder queda delimitado. La red aporta alcance y condiciona las rutas. Los extremos deciden si MPTCP existe, qué candidatos se convierten en subflujos y cuáles admite su política. Una aplicación heredada puede ver un socket normal y desconocer que la elección económica del acceso ocurre por debajo.

Una secuencia común por encima de cada TCP

Cada subflujo conserva sus números de secuencia TCP. MPTCP añade una secuencia de datos de 64 bits para toda la conexión. La señal DSS asigna bytes del espacio de un subflujo al espacio común y puede confirmar recepción al nivel de la conexión.

Ese segundo registro permite recuperarse. Si un subflujo no entrega ciertos datos, los mismos bytes de la conexión pueden reenviarse por otro con una asignación distinta. La aplicación sigue recibiendo un único flujo ordenado, sin fusionar dos conexiones por su cuenta.

El orden también puede convertirse en fricción. Un camino lento puede retrasar la entrega de bytes que ya llegaron por uno rápido. El planificador de paquetes, la reinyección y el control de congestión determinan si dos caminos suman capacidad o suman demora. RFC 8041 documenta esa realidad operativa y no la reduce a “hay dos enlaces”.

Reserva no significa diversidad

Un subflujo puede ser normal o de respaldo, y MP_PRIO puede solicitar un cambio de prioridad. La marca encierra una decisión de negocio. La red móvil puede salvar una conexión y cobrar por volumen; un satélite puede seguir disponible con mucha latencia; dos accesos fijos pueden acabar en el mismo conducto.

RFC 6182 advierte que varias parejas de direcciones no aseguran caminos disjuntos. La arquitectura busca más rendimiento y resiliencia, conserva el servicio de TCP y pretende no perjudicar injustamente a otros usuarios en cuellos compartidos. Son objetivos de diseño, no resultados medidos en una red concreta.

La prueba útil está en la conexión real: subflujos negociados, función activa o de reserva, dominios de fallo, avance de los acuses comunes y datos que tuvieron que cambiar de camino. Contar interfaces describe opciones; no acredita continuidad.

El repliegue también es un resultado

Los dispositivos intermedios pueden retirar opciones TCP, reescribir direcciones o modificar datos de forma incompatible. RFC 8684 prevé respuestas seguras: el primer subflujo puede volver a TCP normal, un subflujo adicional defectuoso puede cerrarse y uno que pierda sus asignaciones válidas debe tratarse como roto.

Por eso una aplicación puede funcionar mientras la característica multipath está ausente. Una supervisión que solo registre éxito confundirá dos casos distintos: la conexión sobrevivió por otro subflujo, o MPTCP nunca operó y TCP convencional simplemente siguió adelante. Multipath TCP hace que la conexión sea mayor que una ruta; la evidencia debe ser igual de amplia.

Fuentes