9. Adattamento di PRR ad altri protocolli di trasporto
L'algoritmo PRR principale e i limiti di riduzione possono essere adattati a qualsiasi protocollo di trasporto che possa supportare [RFC6675]. In un'implementazione importante (Linux TCP), PRR è stato l'algoritmo di fast recovery per i suoi moduli di controllo della congestione predefiniti e supportati dalla sua introduzione nel 2011 [First_TCP_PRR].
L'euristica SafeACK può essere generalizzata a qualsiasi ACK per una ritrasmissione che non causa che qualche altro segmento venga contrassegnato per la ritrasmissione.
10. Studi di misurazione (Measurement Studies)
Per [RFC6937], un documento compagno [IMC11] ha valutato [RFC3517] e varie versioni sperimentali di PRR in studi di misurazione su larga scala. Al momento della pubblicazione, gli algoritmi legacy utilizzati nello studio non esistevano più nelle basi di codice utilizzate per lo studio, rendendo difficili tali confronti senza ricreare algoritmi storici.
I lettori interessati agli studi di misurazione dovrebbero consultare la sezione 5 di [RFC6937] e il documento IMC [IMC11].
11. Considerazioni operative (Operational Considerations)
11.1. Distribuzione incrementale (Incremental Deployment)
PRR è distribuibile in modo incrementale perché sfrutta solo i meccanismi del protocollo di trasporto esistenti per confermare la consegna dei dati e rilevare i dati persi.
Requisiti di distribuzione:
- PRR richiede solo modifiche all'implementazione del protocollo di trasporto del mittente dei dati
- Non sono necessarie modifiche al ricevitore dei dati
- Non sono necessarie modifiche alla rete
Ciò consente ai mittenti di dati che utilizzano PRR di funzionare correttamente con qualsiasi ricevitore di dati o rete esistente. PRR non richiede modifiche o assistenza da router, switch o altri dispositivi nella rete.
11.2. Equità (Fairness)
PRR mira a mantenere le proprietà di equità dell'algoritmo di controllo della congestione con cui è distribuito.
Come funziona:
- PRR funziona solo durante una fase di risposta del controllo della congestione (come il fast recovery o una riduzione a gradini di cwnd da una reazione TCP ECN definita in [RFC3168])
- Prende solo decisioni a breve termine, per conferma, per regolare in modo fluido la quantità di dati in volo durante la fase di regolazione
- In modo che alla fine della fase si avvicini il più possibile alla soglia di avvio lento (ssthresh) determinata dall'algoritmo di controllo della congestione
Meccanismi non modificati:
- PRR non modifica i meccanismi di aumento o diminuzione di cwnd del controllo della congestione al di fuori delle fasi di risposta del controllo della congestione
11.3. Protezione della rete contro l'accodamento eccessivo e la perdita di pacchetti
Impatto a lungo termine
Su scale temporali lunghe, PRR mira a mantenere le proprietà di accodamento e perdita di pacchetti dell'algoritmo di controllo della congestione con cui è distribuito.
Come descritto sopra, PRR funziona solo durante una fase di risposta del controllo della congestione (come il fast recovery o la risposta a ECN), e prende solo decisioni a breve termine, per conferma, per regolare in modo fluido la quantità di dati in volo durante la fase di regolazione, in modo che alla fine della fase si avvicini il più possibile alla soglia di avvio lento (ssthresh) determinata dall'algoritmo di controllo della congestione.
Impatto a breve termine
Su scale temporali brevi, PRR mira a risultare in tassi di perdita di pacchetti inferiori rispetto agli approcci precedenti come [RFC6675].
Principio di vantaggio:
- PRR è ispirato dal principio di conservazione dei pacchetti
- Si affida a processi auto-temporizzati ovunque possibile
- Con [RFC6675], un singolo ACK che porta opzioni SACK e implica una grande quantità di dati mancanti può causare una discontinuità a gradini nello stimatore di pipe
- Ciò può risultare in un fast retransmit che invia una grande raffica di dati che supera di gran lunga la quantità di dati consegnati
- PRR evita tali raffiche prendendo decisioni di trasmissione basate sulla quantità di dati consegnati piuttosto che sulla quantità di dati persi
Miglioramento delle prestazioni:
- Come descritto sopra, PRR-SSRB è meno aggressivo di [RFC6675] (trasmettendo meno segmenti o impiegando più tempo per trasmetterli)
- A causa di una minore probabilità di perdita di pacchetti aggiuntiva durante il ripristino, supera quest'ultimo
12. Considerazioni IANA (IANA Considerations)
Questo documento non ha azioni IANA.
13. Considerazioni sulla sicurezza (Security Considerations)
PRR non modifica il profilo di rischio del protocollo di trasporto.
Protezione dall'attacco di divisione ACK:
Gli implementatori che adattano PRR dal conteggio dei byte al conteggio dei segmenti devono fare attenzione all'impatto degli attacchi di divisione ACK [Savage99], dove i ricevitori confermano segmenti parziali con l'intento di confondere la contabilità della congestione del mittente.
Raccomandazione: L'uso del conteggio dei byte anziché del conteggio dei segmenti difende meglio contro tali attacchi.