Resumen

  • El receptor puede esperar tras el primer segmento completo y confirmar dos con un solo ACK, o combinarlo con una respuesta propia.
  • La llegada del segundo segmento, el vencimiento del temporizador o una señal de pérdida rompe la espera antes de que el ahorro se convierta en ausencia de control.

Cuando llega el primer segmento en orden, el receptor acepta los octetos y avanza su próximo número esperado. Lo pendiente no es la recepción, sino hacerla visible. Un segundo segmento permite que un ACK acumulativo cubra ambos; si no llega, el reloj libera la confirmación.

RFC 1122 convirtió esta práctica en una recomendación para el host. Menos ACK puros podían reducir trabajo y tráfico, pero el retraso debía ser inferior a medio segundo y, en un flujo de segmentos completos, se recomendaba que hubiera al menos un ACK cada dos. El ejemplo del terminal interactivo añadía otra ganancia: confirmación, actualización de ventana y eco podían viajar juntos.

RFC 5681 despejó una ambigüedad normativa y dejó la frecuencia de uno por cada dos segmentos completos como SHOULD, manteniendo 500 ms como máximo absoluto. También advirtió que contar 2*RMSS puede ser engañoso: si la MTU del camino obliga al emisor a usar segmentos más pequeños, un ACK puede abarcar más de dos segmentos reales. Para evitar ese stretch ACK, recomienda confirmar al menos uno de cada dos segmentos recibidos, cualquiera que sea su tamaño.

Las pérdidas cambian la decisión. Los datos por encima de un hueco deberían provocar de inmediato un ACK duplicado, y los que rellenan total o parcialmente el hueco también requieren respuesta pronta. En ese momento el ACK alimenta la recuperación y no debe esperar una agrupación más elegante.

RFC 2525 documentó el stretch ACK como fallo conocido. La consecuencia alcanza al reloj de control del emisor: menos eventos de ACK de los previstos pueden frenar el crecimiento o concentrar envíos en ráfagas.