Resumen

  • El acuse acumulativo de TCP se detenía ante el primer hueco, aunque el receptor ya tuviera fragmentos posteriores. SACK permitió anunciar esos bloques.
  • RFC 2018 dejó al receptor descartar datos que había anunciado. El emisor debía conservar su copia hasta recibir un acuse acumulativo.

Imagine un archivo que llega por entregas: hojas uno, dos y cuatro. El funcionario estampa el recibo hasta la dos; la tres sigue perdida. Puede anotar que la cuatro está en la mesa, pero esa nota no transforma la mesa en una caja fuerte. TCP convirtió esta distinción de oficina en una regla de recuperación de datos.

El RFC 1072, de 1988, describió el problema en enlaces con mucho producto de ancho de banda por retardo. Si faltaba un segmento, el acuse acumulativo dejaba de avanzar. El emisor no veía con claridad cuáles de los segmentos posteriores habían llegado. Esperar nuevas vueltas de la red encarecía la reparación; retransmitir sin información podía repetir trabajo. La propuesta de acuse selectivo buscaba que el receptor dijera qué piezas estaban al otro lado del hueco. Era una propuesta experimental, anterior al formato que terminaría fijándose.

En octubre de 1996, el RFC 2018 definió la opción SACK. Antes de emplearla, el otro extremo tenía que haber anunciado SACK-Permitted en el SYN inicial. El número de acuse normal seguía en la cabecera TCP: indicaba hasta dónde llegaba una secuencia continua. La opción añadía bloques con los límites de rangos recibidos más allá de ese punto. Por la misma conexión viajaban el sello oficial y las notas sobre las hojas sueltas.

El espacio para esas notas era corto. La zona de opciones TCP no podía enumerar todas las islas cuando había muchas. RFC 2018 dio prioridad al bloque que contenía el segmento que acababa de provocar el acuse, salvo que ese segmento hubiera movido el acuse acumulativo. Aconsejó añadir otros bloques distintos y repetir los recientes cuando cupieran. Si se perdía un ACK, una repetición podía salvar la información. El emisor recibía una vista útil, pero parcial y expuesta a pérdidas propias.

La sorpresa aparece en la sección 8. El receptor podía desechar datos fuera de orden que ya había anunciado, por ejemplo cuando necesitaba espacio en su búfer. El texto llama a esto reneging. Después no debía seguir presentando los bloques antiguos descartados como si estuvieran allí. La regla especial del primer bloque seguía haciendo visible el segmento recién llegado, incluso si el receptor pensaba tirarlo. El informe describía una llegada y el estado de una cola en aquel momento; no constituía una promesa de custodia perpetua.

Por eso la instrucción dirigida al emisor fue tajante: guardar los bytes hasta que el número de acuse acumulativo los cubriera. SACK ayudaba a escoger la siguiente retransmisión y a evitar el envío inmediato de bloques que parecían presentes. El emisor seguía siendo responsable de la copia recuperable. Si el receptor vaciaba la mesa antes de completar el hueco, todavía quedaba de dónde reponer la hoja.

El RFC 2883, de julio de 2000, reutilizó la opción para D-SACK: informar de la llegada de datos duplicados. Ni el significado del acuse acumulativo ni el momento de enviar ACK cambiaron. Un duplicado podía mencionarse una sola vez; perder ese ACK borraba la pista. La opción había ganado vocabulario, no un servicio de mensajería infalible.

SACK hizo menos ciega la reparación de una secuencia rota. Su diseño conservó una separación muy terrenal: el receptor podía informar de lo que vio, mientras el emisor esperaba el sello acumulativo antes de destruir su propia copia. En una red, la diferencia entre «lo vi» y «ya puedes tirarlo» vale más que un archivador entero.