Resumen

  • RFC 3517 organizó ACK acumulativos y bloques SACK en un marcador del emisor; SetPipe() calculaba una estimación de los octetos que debía tratar como aún en tránsito.
  • Contar dos veces ciertas retransmisiones era una precaución ante lo desconocido. cwnd - pipe habilitaba otro envío, pero no certificaba inventario de red ni entrega.

SACK resolvía un problema concreto. Tras varias pérdidas, el ACK acumulativo solo mostraba el borde continuo, mientras los bloques selectivos podían señalar islas ya recibidas. RFC 2018 permitía evitar retransmisiones ciegas, pero calificaba esa información de consultiva: el receptor podía descartar datos previamente SACKeados.

Por eso el búfer de retransmisión no podía liberarse hasta que avanzara el ACK acumulativo. El mensaje del receptor aportaba evidencia, no custodia irrevocable.

RFC 3517 construyó encima un estado local. HighACK, HighData, HighRxt y RecoveryPoint delimitaban el episodio. Update() modificaba el marcador. IsLost() infería pérdida cuando suficientes bloques discontinuos o suficientes octetos superiores habían sido SACKeados. Inferir no significaba observar dónde cayó el segmento.

SetPipe() recorría el espacio entre HighACK y HighData. Los octetos no SACKeados y aún no declarados perdidos sumaban porque se suponían en la red. Las retransmisiones hasta HighRxt también sumaban. Así nacía pipe: un cálculo coherente con la evidencia disponible.

La doble contabilidad mostraba su naturaleza. Si el emisor retransmitía antes de clasificar la copia original como perdida, ambas podían aumentar pipe. El emisor no sabía si una, otra o las dos seguían en tránsito. Contarlas de forma conservadora evitaba abrir demasiado pronto la ventana para más tráfico.

Al entrar en recuperación, RecoveryPoint tomaba el valor de HighData, se ajustaba la ventana, se retransmitía la primera pérdida presumida y se ejecutaba SetPipe(). Cada nuevo ACK actualizaba el marcador. Cuando cwnd - pipe dejaba al menos un SMSS, NextSeg() elegía el siguiente rango.

La resta no medía una cola. Era la condición con la que el emisor se concedía permiso. Incrementar pipe después de transmitir tampoco demostraba que el paquete permaneciera en el camino, llegara al receptor o fuera leído por la aplicación. Esos hechos pertenecían a recibos diferentes.

RFC 3042 había definido Limited Transmit para los primeros ACK duplicados. RFC 2883 permitió con D-SACK informar duplicados. RFC 5681 reunió el marco de control de congestión, y RFC 6582 describió NewReno con ACK parciales. Todas estas reglas refinaban decisiones; ninguna daba visión directa del trayecto.

El temporizador seguía siendo el último recurso. Un RTO obligaba a ignorar información SACK anterior ante la posibilidad de reneging. El marcador detallado nunca fue una réplica permanente del búfer receptor.

RFC 6675 dejó obsoleto a RFC 3517 y corrigió umbrales, entrada y retransmisión de rescate. Conservó, sin embargo, la palabra «estimación» para pipe. RFC 6937 introdujo después Proportional Rate Reduction y otro modo de acompasar la recuperación con datos entregados. El cambio demuestra que la contabilidad es diseño de control, no lectura de un sensor.

RFC 9293 es la base TCP actual; IANA registra las opciones SACK-Permitted y SACK. El registro prueba autoridad sobre códigos, no uso, pérdida o entrega en una conexión. RFC 3517 dejó una disciplina: actuar con evidencia parcial sin ampliar su significado.

Fuentes