Resumen

  • PRR convierte cada ACK en la entrada de un presupuesto acotado de transmisión y acerca gradualmente los datos en vuelo al ssthresh que eligió por separado el control de congestión.
  • El ACK acredita avance de entrega, no la salud completa de la ruta; por eso una afirmación operativa debe conservar la elección del objetivo, la rama de PRR, los bytes enviados, el pacing y el resultado medido.

Llegar a diez no cuenta toda la historia

Supongamos que hay veinte segmentos en vuelo cuando una pérdida obliga al algoritmo de congestión a escoger diez como objetivo de la recuperación. Un esquema tradicional puede recortar la ventana de golpe, esperar a que baje la estimación de datos en vuelo y, más tarde, liberar varios segmentos juntos. El ejemplo de RFC 9937 describe ese intervalo como media ventana de silencio.

Otro emisor también acaba en diez, pero reparte la reducción a lo largo de los acuses de recibo que van llegando. El total puede coincidir. No coinciden la carga instantánea sobre las colas, la continuidad del reloj de ACK ni la posibilidad de explicar después qué hizo el sistema.

Ahí aparece Proportional Rate Reduction, PRR. El artículo de 2011 de Nandita Dukkipati, Matt Mathis, Yuchung Cheng y Monia Ghobadi estudió flujos cortos, pausas de la aplicación, pérdidas en ráfaga, pérdida y reordenación de ACK y ACK acumulados. Encontró que mecanismos anteriores podían reducir demasiado la ventana o transmitir ráfagas grandes. En la población medida, PRR y el trabajo complementario sobre retransmisión temprana redujeron entre un 3 y un 10 % la latencia TCP de conexiones afectadas por pérdidas, según el tamaño de la respuesta. No es una previsión universal.

La RFC experimental 6937 llegó en 2013 con Mathis, Dukkipati y Cheng. En diciembre de 2025, RFC 9937, ya en la vía de estándares y firmada por Mathis, Neal Cardwell, Cheng y Dukkipati, la sustituyó. Esa secuencia documenta una relación sostenida de Dukkipati con el problema. No la convierte en inventora única ni en responsable de todas las implementaciones.

Separar objetivo, observación y permiso

PRR se entiende mejor si tres superficies de control no se mezclan.

El algoritmo de control de congestión elige ssthresh, el volumen de datos en vuelo que desea al terminar el episodio. Reno, CUBIC u otro controlador compatible toma esa decisión. PRR no determina por sí mismo cuánta congestión existe ni firma el objetivo.

La maquinaria de recuperación interpreta después los ACK. DeliveredData es la mejor estimación del emisor sobre cuántos bytes indica el ACK actual que llegaron al receptor desde el ACK anterior. Es una señal situada: no explica por sí sola la causa de la pérdida, el estado de la ruta inversa ni la experiencia de la aplicación.

Por último, PRR calcula SndCnt, la cantidad exacta que se puede transmitir en respuesta. Otra función escoge si serán retransmisiones o datos nuevos. PRR regula cantidad y momento; no selecciona el contenido.

Esta división se parece a una especificación mínima bien trazada. La regla común es precisa y comprobable localmente. Las decisiones que necesitan otra información siguen en manos de los módulos que la poseen. La llegada de un ACK no le transfiere autoridad sobre todo el episodio.

Un recibo que marca el ritmo

Al iniciar la recuperación, el emisor conserva RecoverFS, su cálculo del volumen inicial que podría entregarse durante el episodio. prr_delivered acumula el progreso y prr_out registra lo que ya salió.

Mientras inflight permanezca por encima de ssthresh, el cálculo proporcional estima cuánto debería haberse liberado hasta ese momento según la fracción entregada y el objetivo menor. Redondea el resultado, resta lo que ya envió PRR y obtiene el siguiente SndCnt.

Así, el ACK no actúa como un parte médico de la ruta. Funciona como un recibo que abre un crédito limitado. Si el progreso llega en pasos pequeños, las transmisiones lo siguen. Si se pierden ACK, uno posterior puede representar más bytes entregados y el cálculo se pone al día sin regalar una ráfaga ilimitada a un salto de la estimación.

La autoridad sigue repartida. El ACK aporta evidencia de entrega. El controlador fija el destino. PRR decide la porción liberable. Ninguno de ellos demuestra, por separado, que la ruta esté sana.

Prudencia cuando ya se está por debajo

Las pérdidas pueden dejar inflight por debajo de ssthresh. Un límite completamente conservador corre el riesgo de alargar la recuperación, pero acelerar sin señal suficiente puede provocar nuevas pérdidas. RFC 9937 usa dos límites.

Conservative Reduction Bound es el valor predeterminado y ata la salida al progreso entregado. Slow Start Reduction Bound puede añadir, como máximo, un segmento del tamaño máximo del emisor cuando SafeACK es verdadero. Para ello, el ACK debe avanzar el reconocimiento acumulativo y no anunciar una pérdida nueva.

La revisión de 2025 hizo adaptativa la selección tras observar un caso difícil en los policers con cubeta de tokens. Cuando se agotan los tokens, pueden empezar a descartar una gran parte del tráfico sin haber mostrado antes su tasa de reposición. Un ssthresh basado en el rendimiento anterior puede resultar demasiado alto. La rama conservadora se mantiene hasta que llega la señal estrecha que permite un paso adicional.

El nombre SafeACK no es una declaración general de seguridad. Solo dice que ese ACK cumple las condiciones del incremento limitado definido por el algoritmo.

El final correcto aún necesita pacing

Cada transmisión incrementa prr_out. Al completar el episodio, PRR fija cwnd en ssthresh. Sin embargo, RFC 9937 advierte que este paso puede permitir una ráfaga de segmentos consecutivos en ciertos escenarios y recomienda pacing para suavizarla.

El estándar no borra todos los riesgos de temporización. También distingue entre efectos plausibles del ritmo más suave y efectos que han sido cuantificados. La precisión incluye reconocer ese límite.

RFC 9937 documenta que PRR es desde 2011 el algoritmo de recuperación rápida de Linux TCP para sus módulos de congestión predeterminados y admitidos. Es una huella importante de código en uso. No prueba qué rama ejecutó un kernel concreto, si el pacing estaba activo ni si un servicio consiguió la mejora de la investigación de 2011.

La bitácora que hace comprobable la afirmación

Una operación seria identifica la versión del transporte y del controlador, el disparador de detección de pérdida, cwnd, inflight y RecoverFS al inicio, y el componente que eligió ssthresh con su configuración.

Por cada ACK relevante conserva el avance acumulado, la nueva pérdida notificada, DeliveredData, el valor y la causa de SafeACK, la rama proporcional, CRB o SSRB, SndCnt, los bytes enviados y prr_out. También mantiene separada la decisión entre retransmitir y enviar datos nuevos.

Al terminar registra la ventana final, los datos en vuelo, el estado de pacing, cualquier ráfaga, timeout o pérdida repetida, y distribuciones de latencia y rendimiento frente a una cohorte comparable. Las pruebas cubren reordenación, pausas de aplicación, SACK y no-SACK cuando proceda, y limitación por tokens. Los casos negativos son imprescindibles: pueden avanzar los ACK mientras la ruta o la aplicación sigue funcionando mal.

Esa bitácora conserva el orden de las afirmaciones. El ACK observó una entrega. El controlador escogió un objetivo. PRR calculó un permiso. Otro módulo eligió bytes. El código los transmitió. Solo la medición demuestra el efecto.

Fuentes