Resumen

  • Tras el retroceso mediante mapeo infinito, una conexión no puede volver a MPTCP aunque las condiciones de la red mejoren.
  • Mantener el servicio y recuperar el transporte multicamino son decisiones distintas: una nueva conexión es necesaria para lo segundo, pero no garantiza su éxito.

La palabra «recuperación» puede esconder dos trabajos. Uno consiste en evitar que se detenga el flujo de datos. El otro, en devolverle las capacidades que tenía antes del problema. MPTCP permite que el primero salga bien sin que el segundo haya ocurrido. En su procedimiento de retroceso mediante mapeo infinito, la conexión puede continuar como TCP convencional, pero pierde la opción de regresar a MPTCP durante el resto de su vida.

No es una prohibición permanente para el equipo. Tampoco implica que todas las conexiones de una red hayan dejado de admitir varios caminos. El límite afecta a la conexión que ha realizado esa transición. Esa precisión es decisiva: la mejora posterior de una interfaz no convierte por sí sola el flujo superviviente de nuevo en MPTCP.

El protocolo puede haber tomado una decisión razonable de compatibilidad. Lo que no puede hacer es elegir, en nombre de la aplicación, cuánto tiempo conviene conservar el resultado. La continuidad inmediata deja pendiente una pregunta de explotación: ¿hasta cuándo se acepta esta capacidad reducida antes de intentar una conexión nueva?

Dos espacios de secuencia, dos obligaciones de recepción

Para entender qué se ha perdido hay que mirar más allá del número de caminos. MPTCP ofrece un flujo ordenado de bytes sobre subflujos TCP. Cada uno tiene su propia numeración; las señales DSS vinculan esa numeración con la secuencia de datos de la conexión. Así puede reconstruirse el flujo aunque partes de los datos hayan recorrido subflujos diferentes.

Los acuses de recibo también tienen ámbitos distintos. En el funcionamiento normal de MPTCP, el emisor no puede liberar los datos almacenados solo porque un subflujo los haya reconocido. Necesita el reconocimiento a nivel de conexión y el de todos los subflujos por los que envió esos datos. El receptor podría haber reconocido un segmento TCP y posteriormente descartado datos que mantenía pendientes, por ejemplo ante falta de memoria.

Con el mapeo infinito cambian esas reglas. Una longitud de datos reservada, cero, establece la correspondencia para el resto de la conexión. Tras el retroceso, el emisor utiliza únicamente los acuses del subflujo para vaciar su búfer; el receptor debería dejar de emitir los acuses de datos propios de MPTCP. La continuidad utiliza las reglas de TCP convencional.

Por tanto, el mecanismo no equivale a un planificador que decide concentrar hoy el tráfico en un camino. Modifica el estado de transporte y la forma de conservar datos. Las secciones 3.3 y 3.7 de RFC 8684 son la base de esta distinción. Ningún acuse descrito allí debe interpretarse como confirmación de que una operación de negocio ha quedado completada.

No todos los fallos conducen al mismo destino

Los equipos intermedios pueden eliminar opciones o alterar la carga útil. Si esas modificaciones rompen la relación entre la secuencia del subflujo y la de la conexión, MPTCP debe evitar entregar datos mal interpretados. La suma de comprobación, cuando se ha negociado, permite detectar daños relevantes; no demuestra quién los causó ni constituye autenticación criptográfica.

Cuando hay varios subflujos, un fallo de suma de comprobación puede resolverse cerrando el afectado y retransmitiendo los datos por otros. Los datos asociados al mapeo fallido no reciben un acuse a nivel de conexión. Este comportamiento conserva la posibilidad de seguir utilizando MPTCP; no es automáticamente un retroceso de toda la conexión.

El caso de un único subflujo tiene una condición adicional. Para pasar al mapeo infinito sin cerrarlo antes, debe saberse que los datos en vuelo todavía no reconocidos son contiguos. Contar un subflujo no demuestra esa continuidad. El estado puede incluir retransmisiones procedentes de otro subflujo que desapareció de forma anómala.

MP_FAIL señala la posición de secuencia de datos donde empieza el mapeo que falló. En el intercambio de retroceso correspondiente también se lleva el sentido contrario a TCP convencional. Si los datos no son contiguos, existe una variante con reinicio y posible creación de otro subflujo al que se aplica inmediatamente el mapeo infinito. Ese subflujo nuevo sigue perteneciendo a la conexión antigua: no es una renovación que devuelva MPTCP.

Además, la pérdida de opciones al comienzo y el daño a mapeos ya establecidos tienen tratamientos diferentes. En determinados casos se abandona el subflujo problemático. No hay una conversión universal, segura y sin condiciones para cualquier avería. Si no se negoció la suma de comprobación, detectar modificaciones de carga útil para este retroceso requiere una señal de otra capa.

La cifra uno no cuenta toda la historia

Una conexión MPTCP con un solo subflujo puede conservar la capacidad de establecer otros. Después del mapeo infinito, en cambio, solo uno puede enviar, los demás deben terminar y queda prohibido volver a MPTCP en esa misma conexión. Dos paneles con el mismo contador pueden estar describiendo futuros operativos incompatibles.

Tampoco basta con consultar las direcciones. RFC 6897 presenta una interfaz abstracta para aplicaciones: contempla activar MPTCP antes del establecimiento, consultar el soporte después y obtener los subflujos establecidos. No acredita que un sistema operativo actual concreto exponga, con esos nombres simbólicos, una señal fiable de retroceso posterior.

El documento advierte de que las listas pueden quedar desactualizadas. Las consultas de direcciones heredadas devuelven la información del primer subflujo incluso si ya no se utiliza. Una dirección conocida en un registro no identifica necesariamente el camino actual. Las notificaciones avanzadas propuestas en el apéndice eran materia de trabajo futuro, no prestaciones garantizadas por la interfaz básica.

La ficha de RFC 8684 sitúa la especificación en marzo de 2020 como Proposed Standard que reemplazó la versión anterior. Su errata verificada corrige un ejemplo de TCP Fast Open sobre un acuse prematuro, no la prohibición de regresar a MPTCP. La ficha de RFC 6897 lo clasifica como Informational de marzo de 2013, y su consulta de erratas no muestra entradas coincidentes. Son fuentes de diseño y normas, no una auditoría de equipos desplegados.

Renovar no es deshacer

Si el regreso está prohibido en la conexión existente, recuperar MPTCP requiere otra conexión. Esa conclusión se deriva de la regla; no promete que la negociación siguiente salga bien. El intermediario que provocó el problema puede seguir en el camino, y una dirección adicional no garantiza un subflujo utilizable.

Por eso el momento de renovación pertenece también a la aplicación. Un trabajo finito puede concluir en la conexión conservada. Una sesión de larga duración puede necesitar una frontera de renovación explícita. Pero cerrar y abrir no demuestra que sea seguro repetir solicitudes cuyo resultado todavía es incierto. El transporte de bytes no resuelve por sí mismo esa incertidumbre.

La tesis de Lu Heng sobre la relación de agencia invita a examinar quién decide y quién asume las consecuencias. Su explicación del propósito de BTW pone la descripción de la realidad por delante de la promoción. En este caso, describir bien exige reconocer simultáneamente el valor de mantener el flujo y el coste de la capacidad que ya no puede volver a él.