Resumen

  • RFC 3135 examinó proxies que intentaban mejorar TCP en enlaces satelitales e inalámbricos mediante tratamiento de ACK, retransmisión local, conexiones divididas, compresión, túneles y ocultación de desconexiones.
  • Cuando el proxy generaba el ACK, el emisor obtenía evidencia de custodia intermedia, no de recepción por el TCP remoto ni por la aplicación. La mejora de rendimiento desplazaba también responsabilidad y riesgo.

El camino pareció más corto sin haberse acortado

La velocidad de la luz no negocia con TCP. En un salto satelital geoestacionario, cada confirmación puede tardar cientos de milisegundos solo en propagarse. Si la ventana del emisor depende de esa ida y vuelta, una capacidad física considerable puede quedar infrautilizada.

Un proxy cercano ofrece una salida tentadora. Recibe segmentos, responde antes y deja que el emisor mantenga más datos en vuelo. El RTT aparente disminuye. La congestión global deja de reaccionar a cada particularidad del enlace local. Para el usuario, una aplicación que parecía inmóvil puede empezar a funcionar.

Pero el ACK no hizo avanzar los bytes restantes. Tras la respuesta, podían seguir en la memoria del proxy, pendientes del salto satelital, de una radio intermitente, de otro componente, del TCP distante y de la aplicación. Si desaparecían después, el emisor original ya había recibido la señal de progreso. La recuperación pasaba a depender del intermediario.

RFC 3135 llamó Performance Enhancing Proxy a esta familia de funciones. Publicado en junio de 2001 como documento informativo, era una encuesta técnica: describía diseños utilizados frente a latencia, asimetría, errores, poco ancho de banda y desconexiones. No definía un estándar ni ordenaba instalar un proxy. Su gran pregunta era más precisa: ¿qué significado cambia cuando el rendimiento se mejora desde dentro del camino?

Había proxies muy distintos bajo una sola sigla

PEP no designaba una caja idéntica en todos los casos. Algunos dispositivos trabajaban en transporte y observaban TCP. Otros entendían protocolos de aplicación. Algunos eran un componente integrado en la frontera entre una red fija y una radio. Otros formaban una pareja distribuida a ambos lados del enlace difícil.

Una pareja podía tratar de forma diferente cada sentido. En un acceso satelital asimétrico, el componente del sentido de datos podía confirmar localmente para llenar la capacidad, mientras el del canal de retorno filtraba ACK para no saturar un recurso pequeño. El mismo flujo quedaba sometido a dos economías físicas.

La conexión dividida iba más lejos. El primer TCP terminaba en el PEP y otro nacía desde allí hacia el destino. Entre dos proxies podía existir una tercera conexión optimizada, incluso un protocolo propietario sobre UDP. Varias conexiones de usuarios podían multiplexarse dentro de esa relación intermedia.

No todas las técnicas alteraban la autoridad del ACK. Espaciar confirmaciones podía suavizar ráfagas conservando al receptor original como autor. Filtrar ACK redundantes reducía tráfico. Una función de tipo Snoop almacenaba segmentos cerca de la radio y reparaba pérdidas locales. Comprimir disminuía bytes. La evaluación debía nombrar el mecanismo, no juzgar una sigla abstracta.

RFC 3135 añadió otra separación decisiva: transparencia no equivalía a semántica de extremo a extremo. Un PEP podía ser invisible para los hosts y, aun así, terminar su conexión. Otro podía ser explícito para el usuario y conservar un acuse de aplicación hasta el destino. Transparencia describía conocimiento; no describía custodia.

El ACK local trasladó la obligación de reparar

TCP ya ofrece una prueba limitada. Su ACK indica que la implementación TCP del par recibió datos, pero no certifica que la aplicación los haya leído, almacenado o procesado. Por eso una operación que exige una garantía completa necesita un control en el nivel de aplicación.

El PEP introducía un recibo anterior. Si confirmaba datos localmente, el RFC le asignaba la carga de recuperar cualquier pérdida posterior. Para hacerlo necesitaba una copia de los bytes, secuencias, temporizadores y observación del tramo descendente. El rendimiento dependía de que esa nueva custodia fuese efectiva.

La ventaja no era ficticia. Una retransmisión local podía corregir una pérdida radio sin esperar al emisor remoto. Una conexión dividida podía conservar estado durante una interrupción, cerrar la ventana anunciada hacia el origen y reanudar la entrega cuando volviera el enlace. La multiplexación por prioridad podía detener un flujo de fondo durante mucho tiempo sin provocar las reacciones que tendría un silencio inexplicado en la conexión completa.

Sin embargo, cada mejora creaba preguntas que el ACK no respondía. ¿El buffer era persistente o solo memoria volátil? ¿Qué ocurría si el proceso se reiniciaba? ¿Cuándo asumía realmente la responsabilidad el proxy? ¿Qué evidencia mostraba que cumplió la entrega? ¿El usuario podía evitarlo si prefería seguridad y semántica de extremo a extremo?

El problema no era que el proxy mintiera. Decía “yo lo recibí”. El error aparecía cuando una métrica o un operador traducía esa frase como “la aplicación lo recibió”.

La entrega era una escalera de recibos

Para no perder el hilo causal, conviene conservar cinco momentos.

Primero, la aplicación emisora entrega bytes a su TCP local. Segundo, el PEP los acepta y quizá los confirma. Tercero, los bytes atraviesan el subcamino degradado. Cuarto, el TCP remoto los recibe. Quinto, la aplicación remota produce la respuesta que su protocolo define.

Cada nivel tiene dueño y alcance. La entrada en un buffer no es la salida de ese buffer. El ACK TCP remoto no es la escritura duradera. Un ACK de aplicación tampoco tiene un significado universal: puede decir “analizado”, “encolado”, “guardado” o “ejecutado”. La semántica debe estar documentada.

El ejemplo del correo electrónico en RFC 3135 mostraba una transferencia explícita de responsabilidad. Un MTA de relevo podía almacenar un mensaje de forma no volátil, confirmarlo a nivel de aplicación y seguir intentando la entrega durante días. No daba una garantía absoluta, pero el protocolo y la operación reconocían quién custodiaba el mensaje.

Un PEP de transporte normalmente no fabrica ese ACK de aplicación; deja que el diálogo de nivel superior continúe de extremo a extremo. Eso protege el último escalón. Pero no convierte el ACK local de transporte en una versión anticipada del último. Entre ambos persisten el enlace, el receptor y el trabajo de la aplicación.

Al guardar estado, el proxy compartió el destino de la conexión

El principio de destino compartido ayuda a ver el nuevo riesgo. Si el estado esencial permanece en los extremos, la caída de un router no destruye necesariamente una conexión: otra ruta puede transportar los paquetes y los hosts conservan la memoria.

Un PEP con datos ya confirmados y estado de una conexión dividida no es un simple salto reemplazable. Su caída puede borrar la única copia que sostiene la promesa. Aunque exista una ruta alternativa, la sesión termina porque el camino perdió memoria, no conectividad.

El RFC no convirtió esa posibilidad en una prohibición. Muchos PEP servían un último enlace sin alternativa real. Un cliente podía preferir una sesión más rápida y tolerante a cortes aunque dependiera de otro componente. La condición era que la elección estuviera bajo control del usuario o administrador responsable y que las consecuencias fueran conocidas.

Esa condición tiene una dimensión de poder. La red de acceso puede imponer un PEP transparente y celebrar una mejora promedio. El usuario quizá no sabe que el ACK viene de allí. El fabricante controla cómo guarda y recupera. La aplicación asume las consecuencias si el estado se pierde. Sin registros compartidos, nadie puede reconstruir la responsabilidad después.

Cifrar de extremo a extremo dejó ciego al intermediario

La mayor parte de estas funciones necesitaba visibilidad. Para reconocer ACK, secuencias, ventanas y opciones TCP, el PEP debía leer cabeceras. Para terminar una aplicación o comprimir su protocolo, necesitaba ver más.

IPsec ESP entre los hosts ocultaba la cabecera TCP y la carga al nodo intermedio. RFC 3135 observó que muchos PEP no podían funcionar bien, o no podían funcionar en absoluto, en esas condiciones. Incluso una técnica que preservaba semántica, como espaciar ACK, necesitaba identificar los paquetes pertinentes.

La solución de terminar seguridad en el PEP y abrir otra asociación hacia el destino protegía cada enlace, pero exponía los datos dentro del proxy. Exigía confiar en él y podía producir niveles distintos en los dos tramos. La protección segmentada no era la misma propiedad que la protección de extremo a extremo.

También era posible proteger el tramo entre dos PEP, permitir que ciertos flujos evitaran la optimización o usar seguridad de aplicación. Cada opción podía ser razonable, pero cambiaba quién veía el contenido y qué configuración debía probarse.

Los RFC posteriores conservaron la cuestión. RFC 3449 señaló que varias técnicas para rutas asimétricas requieren cabeceras visibles e identificación de flujos. RFC 8404 y RFC 8517 inventariaron la tensión entre cifrado y funciones de transporte del operador. RFC 8684 tuvo que considerar PEP que confirman datos proactivamente al definir retransmisiones de Multipath TCP. Son ecos arquitectónicos, no estadísticas sobre 2001.

Ocultar el corte alteró también el diagnóstico

Una desconexión inalámbrica breve no siempre debe matar la aplicación. El proxy podía conservar datos, detener al emisor con control de flujo y continuar cuando la radio regresara. Para una persona en movimiento, la ocultación podía ser la diferencia entre un servicio usable y una reconexión constante.

La misma ocultación retrasaba el conocimiento de un fallo largo. Un extremo podía esperar mientras el proxy mantenía una apariencia de continuidad. Una aplicación que disponía de otra vía de comunicación podía iniciar el cambio demasiado tarde.

Ping y traceroute no proporcionaban necesariamente el recibo faltante. ICMP podía seguir otra ruta, pasar por el PEP sin el procesamiento de TCP o recibir una respuesta del propio intermediario. El ping verde podía demostrar llegada al proxy, no a la aplicación. Traceroute podía dibujar routers mientras omitía la división de TCP y el estado que decidía la entrega.

Las rutas asimétricas podían impedir que una pareja distribuida viera ambos sentidos. Un host móvil podía cambiar de nodo y necesitar traslado del estado antes de que caducara la sesión. La escala añadía otro límite: inspeccionar capas altas y mantener estado por flujo consume más CPU y memoria que reenviar IP. Varios PEP en paralelo requerían un sistema adicional para conservar afinidad.

El dispositivo instalado para hacer desaparecer un problema de enlace podía convertirse en el lugar más difícil de observar del camino.

El documento no era una licencia de generalización

RFC 3135 era informativo y estaba redactado con cautela. Mantenía el principio de extremo a extremo como orientación dominante. Decía que un PEP debía reservarse para circunstancias específicas donde no existiera una mejora equivalente en los extremos, y que las nuevas tecnologías de enlace deberían evitar necesitarlo cuando fuera posible.

Sus ejemplos —VSAT, WAN inalámbrica, WAP, Snoop— ilustraban familias de decisión. No probaban una adopción general, una implementación correcta ni un resultado medido para todos los productos. Tampoco sostenían que todo PEP quebrara fiabilidad o seguridad.

RFC 3234 amplió después la taxonomía de middleboxes. RFC 3426 utilizó los PEP como ejemplo de balance: beneficio frente a pérdida de IPsec de extremo a extremo, nuevo punto de fallo, diagnóstico más difícil, asimetría y movilidad. La arquitectura no rechazaba el beneficio. Se negaba a contarlo sin contar también su coste.

Medir la mejora sin blanquear la custodia

Una prueba responsable debe identificar el problema inicial: dirección, enlace, RTT, errores, asimetría, interrupciones, carga y objetivo de la aplicación. Debe fijar versión, propietario, ubicación y modo del PEP, mecanismos activos, transparencia, división y capacidad de exclusión voluntaria.

Después debe guardar la cronología completa. Hora de envío, ACK del PEP, bytes almacenados, persistencia del buffer, cruce del enlace, retransmisión local, ACK TCP remoto, respuesta de aplicación y confirmación duradera. Debe registrar quién retransmitió, qué temporizador actuó, qué ruta siguió cada sentido y qué ocurrió al reiniciar, migrar o conmutar.

La seguridad necesita sus propios campos: extremos criptográficos, cabeceras visibles, exposición dentro del proxy, políticas de bypass y posibles diferencias entre tramos. El resultado debe comparar rendimiento de transporte con tiempo y corrección de la aplicación.

Las alarmas nacen de las discrepancias: ACK antes de custodia fiable; reinicio que pierde datos confirmados; ping sano y TCP inmóvil; cifrado que elimina silenciosamente la función; retorno que evita el PEP; transferencia de movilidad incompleta; más throughput y menos operaciones terminadas.

RFC 3135 no negó el valor de un bucle corto. Negó que la proximidad otorgara autoridad sobre el extremo lejano. El ACK del proxy podía ser una promesa útil. Hasta recibir la prueba de la aplicación, seguía siendo la promesa del proxy.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3135.txt
  2. https://www.rfc-editor.org/info/rfc3135
  3. https://www.rfc-editor.org/rfc/rfc3135.html
  4. https://www.rfc-editor.org/rfc/rfc793.html
  5. https://www.rfc-editor.org/rfc/rfc1122.html
  6. https://www.rfc-editor.org/rfc/rfc2401.html
  7. https://www.rfc-editor.org/rfc/rfc2488.html
  8. https://www.rfc-editor.org/rfc/rfc2760.html
  9. https://www.rfc-editor.org/rfc/rfc2775.html
  10. https://www.rfc-editor.org/rfc/rfc3234.html
  11. https://www.rfc-editor.org/rfc/rfc3426.html
  12. https://www.rfc-editor.org/rfc/rfc3449.html
  13. https://www.rfc-editor.org/rfc/rfc8404.html
  14. https://www.rfc-editor.org/rfc/rfc8517.html
  15. https://www.rfc-editor.org/rfc/rfc8684.html