Resumen

  • Nagle permite enviar un primer segmento pequeño cuando no hay datos anteriores pendientes, pero retiene las escrituras pequeñas posteriores hasta recibir una confirmación o reunir un segmento completo.
  • La regla es independiente de las confirmaciones retrasadas, de la prevención de Silly Window Syndrome y del control de congestión; además, debe poder desactivarse por conexión.

RFC 896, publicado en enero de 1984, describió un problema visible en las primeras redes TCP/IP. Una aplicación que producía un carácter cada vez podía enviar un byte acompañado de cuarenta bytes de cabeceras TCP e IP. En redes heterogéneas y enlaces muy cargados, muchos paquetes pequeños consumían capacidad de transmisión y procesamiento en las pasarelas, aumentaban la congestión y podían contribuir a pérdidas y retransmisiones.

Los temporizadores de agrupación de 200 a 500 milisegundos no se adaptaban bien a recorridos con anchos de banda y tiempos de ida y vuelta distintos. Un valor adecuado para una red local podía agrupar muy poco en un trayecto largo; uno adecuado para ese trayecto podía perjudicar la respuesta local. La propuesta de Nagle trasladó la decisión del reloj al estado de confirmación del emisor.

RFC 1122 expresa ese estado como SND.NXT > SND.UNA: aún hay datos transmitidos que no han sido confirmados. Mientras la condición se mantiene, el emisor almacena los nuevos datos de usuario, sin importar el bit PSH, hasta que los datos pendientes sean confirmados o la cola alcance un segmento de tamaño Eff.snd.MSS. Un segmento completo es, por tanto, otra condición de envío. Si no hay datos pendientes porque la conexión estaba inactiva, la primera escritura pequeña puede salir de inmediato.

RFC 1122 indica que TCP debería implementar Nagle, pero exige que la aplicación pueda desactivarlo en una conexión individual. RFC 9293 conserva ese límite y recuerda que el envío sigue sujeto al slow start. Nagle decide si conviene formar otro segmento pequeño; no sustituye al control de congestión.

Tampoco decide cuándo confirma el receptor. RFC 9293 separa la regla de Nagle de la prevención de Silly Window Syndrome y advierte sobre su interacción con las confirmaciones retrasadas. Un emisor que espera progreso de confirmación y un receptor que retrasa su ACK pueden producir una pausa adicional, aunque cada control funcione conforme a su propósito.

Fuentes