3.2. Fast Retransmit/Fast Recovery
Comportamento del ricevitore
Un ricevitore TCP DOVREBBE (SHOULD) inviare un ACK duplicato immediato quando arriva un segmento fuori ordine. Lo scopo di questo ACK è informare il mittente che è stato ricevuto un segmento fuori ordine e quale numero di sequenza è previsto.
Cause degli ACK duplicati
Dal punto di vista del mittente, gli ACK duplicati possono essere causati da una serie di problemi di rete:
- Segmenti scartati: Tutti i segmenti dopo il segmento scartato attiveranno ACK duplicati fino a quando la perdita non viene riparata
- Riordino dei segmenti di dati da parte della rete (non un evento raro su alcuni percorsi di rete [Pax97])
- Replica di segmenti ACK o di dati da parte della rete
ACK per riempire le lacune
Inoltre, un ricevitore TCP DOVREBBE (SHOULD) inviare un ACK immediato quando il segmento in arrivo riempie tutto o parte di una lacuna nello spazio delle sequenze.
Algoritmo di Fast Retransmit
Il mittente TCP DOVREBBE (SHOULD) utilizzare l'algoritmo "fast retransmit" per rilevare e riparare la perdita basandosi sugli ACK duplicati in arrivo.
L'algoritmo di fast retransmit utilizza l'arrivo di 3 ACK duplicati (come definito nella sezione 2, senza ACK intermedi che muovono SND.UNA) come indicazione che un segmento è stato perso. Dopo aver ricevuto 3 ACK duplicati, il TCP esegue una ritrasmissione del segmento apparentemente mancante, senza attendere la scadenza del timer di ritrasmissione.
Algoritmo di Fast Recovery
Dopo che l'algoritmo di fast retransmit ha inviato il segmento apparentemente mancante, l'algoritmo "fast recovery" governa la trasmissione di nuovi dati fino all'arrivo di un ACK non duplicato.
Motivazione
La ragione per non eseguire lo slow start è che il ricevimento degli ACK duplicati non indica solo che un segmento è stato perso, ma anche che i segmenti stanno molto probabilmente lasciando la rete (sebbene una massiccia duplicazione di segmenti da parte della rete possa invalidare questa conclusione).
In altre parole, poiché il ricevitore può generare un ACK duplicato solo quando è arrivato un segmento, quel segmento ha lasciato la rete e si trova nel buffer del ricevitore, quindi sappiamo che non sta più consumando risorse di rete.
Implementazione di Fast Retransmit e Fast Recovery
Gli algoritmi di fast retransmit e fast recovery vengono implementati insieme come segue:
1. Primo e secondo ACK duplicato
Al ricevimento del primo e secondo ACK duplicato presso un mittente, un TCP DOVREBBE (SHOULD) inviare un segmento di dati precedentemente non inviati secondo [RFC3042], a condizione che:
- La finestra annunciata dal ricevitore lo consenta
- Il FlightSize totale rimanga minore o uguale a cwnd più 2*SMSS
- Siano disponibili nuovi dati da trasmettere
Inoltre, il mittente TCP NON DEVE (MUST NOT) modificare cwnd per riflettere questi due segmenti [RFC3042].
2. Terzo ACK duplicato
Quando viene ricevuto il terzo ACK duplicato, un TCP DEVE (MUST) impostare ssthresh a non più del valore fornito nell'Equazione (4).
3. Ritrasmettere e gonfiare la finestra
Il segmento perso che inizia a SND.UNA DEVE (MUST) essere ritrasmesso e cwnd impostato a ssthresh più 3*SMSS. Questo "gonfia" artificialmente la finestra di congestione del numero di segmenti (tre) che hanno lasciato la rete e che il ricevitore ha bufferizzato.
4. ACK duplicati aggiuntivi
Per ogni ACK duplicato aggiuntivo ricevuto (dopo il terzo), cwnd DEVE (MUST) essere incrementato di SMSS. Questo gonfia artificialmente la finestra di congestione per riflettere il segmento aggiuntivo che ha lasciato la rete.
5. Inviare dati precedentemente non inviati
Se sono disponibili dati precedentemente non inviati e il nuovo valore di cwnd e la finestra annunciata dal ricevitore lo consentono, un TCP DOVREBBE (SHOULD) inviare 1*SMSS byte di dati precedentemente non inviati.
6. Sgonfiare la finestra
Quando arriva il successivo ACK che riconosce dati precedentemente non riconosciuti, un TCP DEVE (MUST) impostare cwnd a ssthresh (il valore impostato nel passaggio 2). Questo è chiamato "sgonfiamento" della finestra.
Questo ACK dovrebbe essere il riconoscimento suscitato dalla ritrasmissione del passaggio 3, un RTT dopo la ritrasmissione (anche se potrebbe arrivare prima nel caso di consegna significativa di segmenti di dati fuori ordine al ricevitore).
Limitazioni
Nota: Questo algoritmo è noto per non recuperare in modo efficiente da più perdite in un singolo volo di pacchetti in generale [FF96]. La sezione 4.3 di seguito affronta tali casi.