5. Relazioni con altri standard (Relationships to Other Standards)
PRR può essere utilizzato con qualsiasi algoritmo di controllo della congestione che intende applicare una riduzione moltiplicativa al suo tasso di invio su una scala temporale di circa un tempo di andata e ritorno, dove la quantità corrente di dati in volo è limitata dalla finestra di congestione (cwnd), e dove la quantità target di dati in volo durante quella riduzione è un valore fisso dato da ssthresh.
In particolare, PRR è adatto per l'uso con il controllo della congestione Reno [RFC5681] e CUBIC [RFC9438].
Relazione con gli algoritmi di recupero delle perdite
PRR è descritto come una modifica all'"Algoritmo conservativo di recupero delle perdite per TCP basato su SACK" [RFC6675]. È più preciso quando utilizzato con SACK [RFC2018], ma SACK non è richiesto.
PRR può essere combinato con un'ampia gamma di algoritmi di rilevamento delle perdite. Questo perché PRR non dipende dai dettagli di come l'algoritmo di rilevamento delle perdite stima quali pacchetti sono stati consegnati e quali pacchetti sono stati persi. Alla ricezione di ogni ACK, PRR ha solo bisogno che l'algoritmo di rilevamento delle perdite comunichi quanti pacchetti sono stati contrassegnati come persi e quanti pacchetti sono stati contrassegnati come consegnati.
Pertanto, PRR può essere combinato con gli algoritmi di rilevamento delle perdite specificati o descritti nei seguenti documenti:
- Reno [RFC5681]
- NewReno [RFC6582]
- SACK [RFC6675]
- Forward Acknowledgment (FACK) [FACK]
- Recent Acknowledgment Tail Loss Probe (RACK-TLP) [RFC8985]
A causa delle caratteristiche prestazionali di RACK-TLP, inclusa la resilienza alla perdita di coda, al riordino e alle ritrasmissioni perse, si RACCOMANDA che PRR sia implementato con il recupero delle perdite RACK-TLP [RFC8985].
Origine dell'euristica SafeACK
L'euristica SafeACK è stata una conseguenza dello sviluppo del rilevamento robusto della ritrasmissione persa in un precursore iniziale di [RFC8985].
Senza rilevamento della ritrasmissione persa, i policer che causavano tassi di perdita di pacchetti molto elevati affrontavano un rischio estremamente alto di causare timeout di ritrasmissione, perché Reno [RFC5681], CUBIC [RFC9438] e [RFC6675] potevano inviare ritrasmissioni ben al di sopra del tasso di policing.
Compatibilità con gli algoritmi di controllo della congestione
PRR è progettato per funzionare bene con vari algoritmi di controllo della congestione:
Controllo della congestione Reno
- PRR leviga il processo di fast recovery di Reno
- Evita la brusca riduzione della finestra di Reno all'inizio del ripristino
- Fornisce un tasso di invio più stabile
Controllo della congestione CUBIC
- PRR è compatibile con il meccanismo di riduzione della finestra di CUBIC
- Fornisce un controllo preciso del tasso durante il fast recovery
- Mantiene le caratteristiche di crescita di CUBIC dopo il ripristino
Compatibilità ECN
PRR può essere adattato per l'uso con Explicit Congestion Notification (ECN) [RFC3168] utilizzando porzioni della macchina a stati di recupero delle perdite per invocare l'elaborazione PRR in risposta al marcaggio ECN piuttosto che alla perdita effettiva di pacchetti.
Compatibilità con i protocolli di trasporto
Sebbene PRR sia stato originariamente progettato per TCP, i suoi principi fondamentali possono essere applicati ad altri protocolli di trasporto, a condizione che:
- Utilizzino un controllo della congestione basato su finestra
- Abbiano un meccanismo simile al fast recovery
- Possano stimare la quantità di dati in volo
- Ricevano conferme per i dati inviati
Il capitolo 9 discute in dettaglio le considerazioni per adattare PRR ad altri protocolli di trasporto.