Resumen

  • El método común limita el aumento de la ventana cuando la aplicación o el receptor restringen al emisor, tomando como base el mayor FlightSize realmente utilizado desde la última reducción de cwnd.
  • Un ACK válido acredita la recepción de datos enviados; no acredita una capacidad ociosa que nunca atravesó la ruta.

El contador vio veinticuatro; la ruta solo vio diez

El ejemplo del borrador comienza con una ventana inicial de diez segmentos. El emisor manda los diez y hace una pausa. Sin pérdida y con un ACK por segmento, slow start eleva cwnd a veinte.

Más tarde, la aplicación aporta cuatro segmentos. También llegan y son confirmados. Sin una cota, esos cuatro ACK elevan cwnd a veinticuatro, pese a que el mayor vuelo por RTT sigue siendo diez.

Las confirmaciones no son falsas. El salto indebido aparece cuando la entrega de un vuelo pequeño se interpreta como autorización para ampliar una porción de ventana que jamás fue puesta a prueba.

La escena es aritmética, no un incidente conocido. Suprime ACK retardados, cómputo por bytes, pacing y pérdida para mostrar una pregunta concreta: ¿qué observación permite aumentar los datos no confirmados que un host puede colocar en la red?

Aprobación no equivale a ejecución

El anuncio del 24 de agosto a las 17:57 UTC aprueba la revisión 10 de “Increase of the Congestion Window when the Sender Is Rate-Limited” como Proposed Standard. El documento del Congestion Control Working Group actualiza DCCP CCID 2, TCP, QUIC, SCTP y CUBIC.

El 28 de agosto, Datatracker todavía mostraba un Active Internet-Draft en la cola del RFC Editor y una intervención de autor pendiente. No solicita acción de IANA. La decisión del IESG, la publicación de un RFC, la integración en software, la activación y el resultado de servicio son hechos separados.

El anuncio registra apoyo amplio y varias implementaciones, incluida una trayectoria Linux desde la versión 3.16. Eso prueba experiencia práctica, no que cada kernel, biblioteca QUIC o plataforma operativa exponga y aplique exactamente el mismo estado.

Encontrar la restricción correcta

Un transporte puede permitir más envío y no usarlo. La aplicación puede quedarse sin datos. El receptor puede cerrar parte de rwnd o del crédito de conexión o stream en QUIC. Un pacer puede espaciar las salidas.

El texto llama cwnd-limited al flujo que consume su permiso. Siguiendo RFC 7661, llama rate-limited al que utiliza como máximo la mitad de cwnd y permanece en fase no validada.

No son etiquetas intercambiables. La aplicación controla la oferta; el receptor, el crédito; el transporte, la ventana; el pacer, el calendario; la ruta, la pérdida, ECN, el retraso y la entrega. Un indicador genérico de subutilización borra quién cerró cada superficie.

Cwnd tampoco es ancho de banda. Es permiso local para mantener bytes sin confirmar en vuelo. No certifica reserva en el enlace, preparación de la aplicación receptora ni estabilidad futura de la ruta.

El límite nace del vuelo ejercido

La nueva regla mantiene maxFS, el mayor FlightSize observado desde la última reducción de cwnd. Empieza en la ventana inicial y se actualiza con el máximo entre su valor y cada vuelo.

Cualquier reducción de cwnd pone maxFS a cero. El siguiente vuelo crea una nueva base. Así, la pérdida, ECN u otra reacción que recorta la ventana también retira la autoridad histórica del máximo anterior.

Si FlightSize < cwnd, el emisor puede procesar crecimiento por ACK, pero el resultado no supera limit(maxFS): la ventana que produciría el algoritmo si enviara y recibiera confirmación correcta de un vuelo completo de tamaño maxFS.

En slow start de RFC 5681, el ejemplo limita a dos veces maxFS. En congestion avoidance, a maxFS + SMSS. El método conserva información de entrega y acota el permiso que deriva de ella.

Con diez más cuatro, cwnd llega legítimamente a veinte tras el primer vuelo. Los cuatro ACK posteriores no desaparecen, pero tampoco rompen esa cota. Cuando un vuelo futuro supere diez, moverá maxFS y dará fundamento a un límite mayor.

Cinco transportes, una cota y códigos distintos

El TCP estándar no expresaba este tope. DCCP CCID 2 podía crecer en un periodo sin congestión sin estar limitado por cwnd. QUIC desaconsejaba cualquier aumento con ventana infrautilizada. SCTP y CUBIC imponían barreras conservadoras en partes de sus algoritmos.

El nuevo documento sustituye esa divergencia por un principio común. Permite un crecimiento acotado donde QUIC, SCTP o CUBIC podían detenerlo por completo y evita crecimiento sin límite para TCP y DCCP. No obliga a que todos tengan el mismo código.

Los controles basados en tasa deben mantener su máximo sostenido por debajo de lo que habría permitido el método de ventana. El pacing sigue siendo posible si solo modifica el espaciado, no los bytes en vuelo por RTT. En BBR y otros híbridos, estimación de tasa, pacing, cwnd y muestras limitadas por aplicación deben observarse por separado.

Una prueba vieja puede sobrevivir a otra ruta

El borrador advierte que maxFS puede conservarse durante mucho tiempo si cwnd no disminuye y dejar de representar la ruta actual. Una transición móvil, un cambio de ruta, túnel o cola puede ocurrir sin reset automático.

RFC 7661 aborda el problema relacionado de validar una ventana mayor que el vuelo reciente y define pipeACK. No es la misma función. Rate-Limited Increase controla el aumento; Congestion Window Validation gestiona una ventana infrautilizada y su reacción a congestión.

Guardar el máximo evita reaprender después de cada pausa. Guardarlo sin tiempo, ruta y causa de reducción convierte evidencia útil en memoria sin procedencia.

La autenticidad del ACK no amplía su significado

El control de congestión depende de confirmaciones apropiadas. La capacidad de un atacante para influir en ellas depende de la protección del transporte. Pero incluso un ACK auténtico solo confirma bytes concretos; no garantiza capacidad ociosa, RTT futuro, equidad o ruta estable.

La revisión debe separar aceptación del ACK, envío que confirma y aumento autorizado localmente. El código Linux actual de Reno y CUBIC comprueba si el flujo está limitado por cwnd antes de crecer. Es evidencia de código en funcionamiento, no inventario de una flota.

La cadena operacional conserva transporte y build, estado de la aplicación, crédito receptor, pacing, cwnd, FlightSize, maxFS, ventana inicial, ssthresh, bytes confirmados, reducción por pérdida o ECN, límite calculado, ruta y resultado después de reanudar. El estándar fija la regla mínima; solo el comportamiento medido prueba su efecto local.

Fuentes