1. Introduzione (Introduction)

Il principio di conservazione dei pacchetti (packet conservation principle) di Van Jacobson [Jacobson88] definisce un processo di auto-orologio in cui N segmenti di dati consegnati al ricevitore generano riconoscimenti che il mittente dei dati utilizza come orologio per attivare l'invio di altri N segmenti di dati nella rete.

Gli algoritmi di controllo della congestione come Reno [RFC5681] e CUBIC [RFC9438] sono costruiti sulla base concettuale di questo processo di auto-orologio. Essi controllano il processo di invio di una connessione di protocollo di trasporto utilizzando una finestra di congestione (congestion window, "cwnd") per limitare "inflight", il volume di dati che una connessione stima essere in volo nella rete in un dato momento. Inoltre, questi algoritmi richiedono che le connessioni di protocollo di trasporto riducano il loro cwnd in risposta alle perdite di pacchetti. Il ripristino rapido (fast recovery) (vedere [RFC5681] e [RFC6675]) è l'algoritmo per utilizzare il feedback dai riconoscimenti per eseguire questa riduzione di cwnd. Il suo obiettivo dichiarato è mantenere l'auto-orologio del mittente facendo affidamento sugli ACK di ritorno per temporizzare più dati nella rete durante il ripristino.

Senza riduzione proporzionale del tasso (Proportional Rate Reduction, PRR), il ripristino rapido tipicamente regola la finestra attendendo la maggior parte di un tempo di andata e ritorno (round-trip time, RTT) (metà RTT di ACK per Reno [RFC5681], o 30% di un RTT per CUBIC [RFC9438]) prima di inviare dati.

[RFC6675] rende il ripristino rapido con supporto per il riconoscimento selettivo (Selective Acknowledgment, SACK) [RFC2018] più accurato calcolando "pipe" (la stima del mittente del numero di byte ancora in sospeso nella rete). Con [RFC6675], il ripristino rapido è implementato inviando dati secondo necessità su ogni ACK per consentire a pipe di salire per corrispondere a ssthresh (la dimensione della finestra target come impostata dall'algoritmo di controllo della congestione per il ripristino rapido). Questo protegge il ripristino rapido dai timeout in molti casi in cui c'è una perdita pesante. Tuttavia, [RFC6675] ha due carenze notevoli.

Primo, poiché effettua una riduzione moltiplicativa molto grande di cwnd all'inizio del ripristino rapido, può causare un timeout se i dati o gli ACK per l'intera seconda metà della finestra sono persi. Secondo, un singolo ACK che trasporta opzioni SACK che implicano una grande quantità di dati mancanti può causare uno scalino di discontinuità nello stimatore pipe, che può causare l'invio di una raffica di dati sulla ritrasmissione rapida.

PRR regola il processo di trasmissione durante il ripristino rapido in modo da evitare questi eccessivi aggiustamenti della finestra in modo che le trasmissioni procedano in modo fluido e, alla fine del ripristino, la dimensione effettiva della finestra sarà il più vicino possibile a ssthresh.

L'approccio adottato da PRR è stato ispirato dal principio di conservazione dei pacchetti di Van Jacobson. PRR si basa il più possibile sul processo di auto-orologio ed è solo debolmente influenzato dalla precisione degli stimatori, come quelli per la quantità di dati in volo. Questo è il motivo per cui l'algoritmo mantiene la sua precisione anche in presenza di eventi che causano incertezza per altri stimatori.

Quando inflight è sopra ssthresh, PRR riduce progressivamente inflight fino a ssthresh temporizzando le trasmissioni a una velocità proporzionale ai dati consegnati e a ssthresh.

Quando inflight è sotto ssthresh, PRR seleziona in modo adattivo tra due limiti di riduzione (Reduction Bounds) per limitare la riduzione totale della finestra da tutti i meccanismi (inclusi gli arresti transitori dell'applicazione e le perdite stesse). Come riferimento, PRR utilizza il suo limite di riduzione conservativo (Conservative Reduction Bound, CRB) per seguire rigorosamente la conservazione dei pacchetti, per prudenza quando potrebbe esserci una congestione sostanziale. Quando il ripristino sembra procedere bene, PRR utilizza il suo limite di riduzione di avvio lento (Slow Start Reduction Bound, SSRB), che è più aggressivo di PRR-CRB al massimo di un segmento per ACK.

PRR-CRB soddisfa il limite di conservazione dei pacchetti forte (Strong Packet Conservation Bound) descritto nell'appendice A; tuttavia, le sue prestazioni nelle reti reali non sono buone come l'algoritmo descritto in [RFC6675], che si è dimostrato più aggressivo in un gran numero di casi, quando utilizzato come unico algoritmo. PRR-SSRB offre un compromesso consentendo a una connessione di inviare un segmento aggiuntivo per ACK rispetto a PRR-CRB in determinate situazioni. Sebbene PRR-SSRB sia meno aggressivo di [RFC6675] (trasmettendo meno segmenti o impiegando più tempo per trasmetterli), lo supera a causa della minore probabilità di perdite aggiuntive durante il ripristino.

La definizione originale del principio di conservazione dei pacchetti [Jacobson88] trattava i pacchetti presunti perduti (ad esempio, contrassegnati come candidati per la ritrasmissione) come aver lasciato la rete. Questa idea si riflette nello stimatore inflight utilizzato da PRR, ma differisce dal limite di conservazione dei pacchetti forte descritto nell'appendice A, che è definito solo in base ai dati che sono effettivamente arrivati al ricevitore.

Questo documento specifica diverse modifiche importanti rispetto alla versione precedente di PRR in [RFC6937]. Primo, introduce una nuova euristica adattiva che sostituisce un parametro configurato manualmente che determinava quanto conservativo sarebbe stato PRR quando inflight è sotto ssthresh (se utilizzare PRR-CRB o PRR-SSRB).

Secondo, l'algoritmo specifica il comportamento per le connessioni non-SACK (connessioni che non hanno negoziato il supporto SACK [RFC2018] tramite l'opzione "SACK-permitted"). Terzo, l'algoritmo garantisce un invio fluido anche nei casi in cui un mittente sperimenta un alto riordino e non avvia il ripristino di perdita fino a dopo che uno spazio di sequenza sostanziale sia stato SACKato.

Infine, questo documento include anche una discussione aggiuntiva sull'integrazione di PRR con algoritmi di controllo della congestione e di rilevamento delle perdite.

PRR ha un'ampia esperienza di distribuzione in più implementazioni TCP dalla prima implementazione TCP PRR ampiamente distribuita nel 2011 [First_TCP_PRR].