4.2. Generazione di riconoscimenti

L'algoritmo di ACK ritardato specificato in [RFC1122] DOVREBBE (SHOULD) essere utilizzato da un ricevitore TCP. Quando si utilizzano ACK ritardati, un ricevitore TCP NON DEVE (MUST NOT) ritardare eccessivamente i riconoscimenti. In particolare, un ACK DOVREBBE (SHOULD) essere generato per almeno ogni secondo segmento di dimensione piena, e un ACK DEVE (MUST) essere generato entro 500 ms dall'arrivo del primo pacchetto non riconosciuto.

Il requisito che un ACK "DOVREBBE (SHOULD)" essere generato per almeno ogni secondo segmento di dimensione piena è elencato in [RFC1122] in un punto come SHOULD e in un altro come MUST. Qui affermiamo senza ambiguità che si tratta di uno SHOULD. Sottolineiamo inoltre che si tratta di uno SHOULD, il che significa che un implementatore dovrebbe effettivamente discostarsi da questo requisito solo dopo un'attenta considerazione delle sue implicazioni. Si veda la discussione sulla "violazione di Stretch ACK" in [RFC2525] e i riferimenti ivi contenuti per una discussione dei possibili problemi di prestazioni derivanti dalla generazione di ACK con frequenza inferiore a ogni secondo segmento di dimensione piena.

In alcuni casi, mittente e ricevitore possono non essere d'accordo su che cosa costituisca un segmento di dimensione piena. Un'implementazione si considera conforme a questo requisito se invia almeno un riconoscimento ogni volta che riceve 2RMSS byte di nuovi dati dal mittente, dove RMSS è la dimensione massima del segmento specificata dal ricevitore al mittente (o il valore predefinito di 536 byte, secondo [RFC1122], se il ricevitore non specifica un'opzione MSS durante l'instaurazione della connessione). Il mittente può essere costretto a utilizzare una dimensione del segmento inferiore a RMSS a causa dell'unità di trasmissione massima (MTU), dell'algoritmo di scoperta del MTU del percorso o di altri fattori. Per esempio, si consideri il caso in cui il ricevitore annuncia una RMSS di X byte ma il mittente finisce per utilizzare una dimensione del segmento di Y byte (Y < X) a causa della scoperta del MTU del percorso (o della dimensione del MTU del mittente). Il ricevitore genererà stretch ACK se attende l'arrivo di 2X byte prima che venga inviato un ACK. Chiaramente ciò richiederà più di 2 segmenti di dimensione Y byte. Pertanto, sebbene non sia definito alcun algoritmo specifico, è auspicabile che i ricevitori tentino di prevenire questa situazione, ad esempio riconoscendo almeno ogni secondo segmento, indipendentemente dalla dimensione. Infine, ripetiamo che un ACK NON DEVE (MUST NOT) essere ritardato per più di 500 ms in attesa dell'arrivo di un secondo segmento di dimensione piena.

I segmenti di dati fuori sequenza DOVREBBERO (SHOULD) essere riconosciuti immediatamente, al fine di accelerare il recupero dalla perdita. Per attivare l'algoritmo di ritrasmissione rapida, il ricevitore DOVREBBE (SHOULD) inviare immediatamente un riconoscimento duplicato quando riceve un segmento di dati al di sopra di una lacuna nello spazio delle sequenze. Per fornire un riscontro ai mittenti che si riprendono dalle perdite, il ricevitore DOVREBBE (SHOULD) inviare immediatamente un ACK quando riceve un segmento di dati che colma del tutto o in parte una lacuna nello spazio delle sequenze.

Un ricevitore TCP NON DEVE (MUST NOT) generare più di un ACK per ogni segmento in ingresso, salvo per aggiornare la finestra offerta quando l'applicazione ricevente consuma nuovi dati (si vedano [RFC813] e pagina 42 di [RFC793]).