Resumen

  • Para RFC 3155, un hueco de secuencia, ACK duplicados o un timeout mostraban falta de progreso, pero no demostraban si la causa era congestión, error de transmisión, reordenamiento o pérdida en el trayecto de vuelta.
  • Fast Retransmit/Fast Recovery, SACK, D-SACK y NewReno permitían reparar mejor sin abandonar la cautela de congestión. Esos mecanismos describían llegadas y retransmisiones; no etiquetaban el origen físico de la ausencia.
  • La evaluación completa necesita unir telemetría de enlace y cola, ambos sentidos del flujo, decisión del emisor, evolución de ventana, reensamblado y resultado de la aplicación. Recuperar bytes no garantiza recuperar el plazo.

El mismo silencio podía venir de lugares distintos

Un emisor TCP no inspeccionaba cada cola ni cada símbolo del enlace. Sabía qué bytes había enviado y qué frontera confirmaba el receptor. Si esa frontera dejaba de avanzar, aparecía un hecho: la entrega ordenada tenía un hueco. La explicación no viajaba necesariamente con él.

Durante años, interpretar la pérdida como congestión había protegido la estabilidad. En las redes ordinarias, los buffers llenos explicaban buena parte de los descartes. Pero la expansión hacia enlaces terrestres inalámbricos, satelitales y otras subredes imperfectas elevó la proporción de errores que el nivel de enlace no conseguía corregir.

Una trama dañada podía ser descartada antes de TCP. Una retransmisión local podía retrasar el paquete y cambiar su orden. Un ACK podía perderse. Una ruta podía variar. Una cola podía saturarse. Desde el extremo, varias de esas historias producían los mismos ACK repetidos o la misma expiración.

RFC 3155 no presentó un clasificador oculto. Al contrario, reconoció que las heurísticas de extremo a extremo estudiadas no habían separado con fiabilidad las pérdidas por congestión de las debidas a corrupción. El emisor debía actuar con evidencia incompleta.

La cautela podía desperdiciar capacidad y aun así ser correcta

Si el origen real era un error de transmisión, reducir la ventana podía dejar capacidad sin usar. El emisor trataba de encontrar un ritmo seguro aunque la cola no estuviera llena. Esa penalización era visible en enlaces con errores persistentes.

Sin embargo, atribuir una pérdida congestionaria a simple corrupción era una apuesta contra los demás flujos. Seguir enviando con agresividad podía aumentar la cola, provocar más descartes y acercar el sistema al colapso. Por eso la prevención de congestión conservaba prioridad cuando faltaba una señal causal digna de confianza.

La regla no afirmaba que toda pérdida fuera físicamente congestión. Ordenaba responder como si el riesgo colectivo pudiera estar presente. Era autoridad de control, no autoridad para reescribir la historia del paquete.

Un gráfico de cwnd que cae prueba la decisión del algoritmo. Para probar el evento hacen falta relojes alineados, contadores de la dirección correcta, secuencias, colas, marcas y errores de enlace. La proximidad temporal ayuda; no sustituye la unión.

El modelo de Reno decidía si valía la pena investigar

El RFC incluyó una aproximación del rendimiento de Reno en función del tamaño de segmento, el RTT de extremo a extremo, el temporizador RTO y la tasa estable de pérdida. Su utilidad estaba en comparar el rendimiento previsto con la velocidad de la conexión.

Si la fórmula daba un valor mayor que la velocidad física, la respuesta de TCP no era el límite principal: ningún algoritmo iba a superar la propia línea. Si daba un valor menor y la investigación confirmaba errores de transmisión relevantes, mejorar la recuperación podía aprovechar capacidad ociosa.

Los matices impedían usar la fórmula como oráculo. El RTT no era solo el del enlace sospechoso. Max(1.0, 4*RTT) era una simplificación para el RTO. Una tasa media podía ocultar ráfagas que borraban varios segmentos de la misma ventana.

El cálculo delimitaba una pregunta. No decía qué paquete se corrompió, dónde se llenó una cola ni qué tasa obtendría una implementación concreta.

Tres ACK repetidos distinguían una acción, no una causa

Cuando llegan segmentos posteriores a un hueco, el receptor vuelve a anunciar el siguiente byte que espera. Tres ACK duplicados permiten a Fast Retransmit reenviar el segmento presuntamente perdido sin aguardar todo el RTO.

Fast Recovery reduce la ventana a la mitad y continúa en evitación de congestión. Un timeout, al no mostrar progreso suficiente, devuelve al emisor a Slow Start con una reducción más dura. Los ACK repetidos prueban que parte del tráfico sigue pasando y justifican esa diferencia.

No prueban congestión. El reordenamiento permitido por IP, una retransmisión de enlace tardía o un cambio de ruta también pueden producirlos. El umbral es un mecanismo de control que convierte una observación en una respuesta.

Si otra pérdida llega antes de que el aumento aditivo restaure la ventana, la nueva reducción actúa sobre un valor ya reducido. RFC 3155 describió esa espiral descendente. En condiciones continuamente malas, la ventana podía permanecer pequeña durante gran parte de la conexión.

Una ventana de menos de cuatro segmentos podía no generar tres ACK duplicados y perder la ventaja de Fast Retransmit. Pero también había ventanas pequeñas sin errores: HTTP/1.0 cerraba conexiones entrenadas y abría otras que repetían Slow Start. La política de la aplicación podía parecer un problema de enlace.

SACK mostraba qué llegó, no por qué faltó lo demás

El ACK acumulativo solo anuncia la frontera contigua. Cuando faltan varios segmentos, no expresa bien los bloques posteriores que el receptor ya guarda. SACK permite informar esos intervalos para que el emisor repare varios huecos sin esperar una ronda completa por cada descubrimiento.

RFC 3155 recomendó combinarlo con la extensión D-SACK de RFC 2883. La información sobre duplicados era valiosa frente a reordenamiento, pérdida de ACK, replicación y retransmisiones tempranas. En una ruta de RTT alto o ante una ráfaga dentro de una ventana grande, la recuperación podía ahorrar rondas y tráfico.

El mapa seguía siendo de recepción. Un bloque SACK demostraba qué bytes habían llegado; un hueco demostraba cuáles aún no estaban en el reensamblado. Ninguno identificaba ruido, buffer o equipo responsable.

NewReno ofrecía una salida cuando ambos extremos no podían usar SACK: los ACK parciales permitían continuar reparando múltiples pérdidas. Limited Transmit buscaba producir suficientes segmentos posteriores para que una ventana pequeña generara los ACK necesarios. El RFC aconsejaba evaluarlo, no declaraba resuelto todo enlace con errores.

El MTU no era un mando único de fiabilidad

Muchos enlaces poco fiables operaban con MTU reducido. Como TCP aumentaba la ventana por segmentos, segmentos pequeños podían hacer más lenta la apertura. Pero recortar el MTU no corregía un canal defectuoso.

Path MTU Discovery evitaba fragmentación y ayudaba a utilizar el mayor paquete admitido por el trayecto. Eso podía acelerar el aprendizaje de capacidad, aunque todavía fueran necesarios varios RTT para abrir por completo la ventana.

Aquí aparece una frontera con RFC 3150. Aquella pieza trata el tiempo durante el que un paquete ocupa una conexión lenta compartida y hace esperar a otros. RFC 3155 trata la interpretación de pérdida y la recuperación de TCP. Una duración larga no es una causa de pérdida; una pérdida no demuestra cuánto tiempo ocupó el enlace el paquete.

El tamaño afecta serialización, proporción de cabeceras, número de segmentos, fragmentación y exposición a errores. Por eso no existe una conclusión honesta del tipo «más pequeño siempre es mejor».

El extremo conservaba el destino compartido y renunciaba a visión local

Las recomendaciones de RFC 3155 no exigían un dispositivo intermedio consciente de TCP. Seguían funcionando con IPsec de extremo a extremo y conservaban la fiabilidad entre quienes originaban y recibían la conexión.

Un PEP situado en el límite de una red podía aprovechar conocimiento local. El precio podía incluir un tercer punto de fallo, estado durante movilidad, necesidad de observar ambas direcciones, problemas de escala, diagnósticos rotos y conflicto con cifrado. No todos los PEP sufrían todos los efectos, pero ninguno debía introducirse como optimización invisible.

El artículo de RFC 3135 posee esa historia del proxy. Aquí la comparación solo fija el límite: ganar conocimiento local suele exigir que el intermediario asuma estado y poder; quedarse en los extremos conserva otras propiedades y acepta una inferencia menos precisa.

ECN no convertía su ausencia en una notificación de error

ECN ofrecía una marca explícita de congestión antes del descarte. Cuando emisor, receptor y red la preservaban, reducía la dependencia de inferir congestión únicamente a partir de pérdida.

RFC 3155 advirtió que no podía emplearse como sustituto de una notificación explícita de error de transmisión. Un paquete perdido sin marca ECN no quedaba certificado como corrupto. Si la propia cabecera estaba dañada, hasta elegir el destinatario de una notificación podía ser imposible.

El documento consideraba útil una señal futura de error, quizá más accesible cerca de un proxy de primer salto. No la especificó. La ausencia de un mensaje no es el significado contrario de otro mensaje.

Las recomendaciones inmediatas convivían con preguntas abiertas

El conjunto recomendado era deliberadamente estrecho: mantener Slow Start y Congestion Avoidance, desplegar Fast Retransmit/Fast Recovery, utilizar SACK y D-SACK, y recurrir a NewReno para mejorar pérdidas múltiples cuando SACK no estuviera disponible a ambos lados.

Retrasar ACK duplicados podía dar tiempo a la recuperación de enlace, pero no existía un retardo apropiado para cualquier topología. El pacing y el control de ACK podían moderar ráfagas. Appropriate Byte Counting ajustaba el crecimiento a bytes confirmados, pero podía agravar una ráfaga después de perder ACK. Eran temas de trabajo, no resultados públicos.

Las conexiones HTTP persistentes y el intercambio de estado de congestión entre conexiones trataban otra fuente de ineficiencia: comenzar una y otra vez sin conocimiento del camino. RFC 2140 y Congestion Manager mostraban que parte del rendimiento dependía de cuánto aprendizaje sobrevivía a la aplicación.

La publicación de una propuesta posterior no demuestra que un host de 2001 la ejecutara. La negociación de una opción tampoco demuestra que intervino correctamente en el incidente examinado. Solo el código y las trazas cierran esa distancia.

La reparación del transporte no garantizaba reparar el servicio

Mientras falta un segmento, TCP puede guardar datos posteriores, pero no entregar el flujo ordenado a través del hueco. Una retransmisión que lo llena permite avanzar. Esa es una victoria verificable del transporte.

No identifica la causa original ni recupera necesariamente el valor temporal. Una operación puede terminar después del plazo, el usuario puede abandonar antes o la transferencia puede completarse con una utilización pobre de la capacidad.

El expediente debe conservar contexto, RTT y RTO; MSS, MTU y ventana; huecos, ACK, SACK y timeout; colas, ECN, errores y reintentos; decisión y algoritmo; retransmisiones y evolución de cwnd; reensamblado; por último, tiempo y resultado de la aplicación.

La lección histórica es incómoda pero fértil: una reacción segura no necesita fingir que es un diagnóstico. RFC 3155 protegió la estabilidad frente a una señal ambigua y buscó reducir el coste de esa prudencia. La evidencia, no el algoritmo, tenía que explicar después quién produjo la pérdida.

Fuentes