Passa al contenuto principale

8. Esempi (Examples)

Questa sezione illustra il comportamento degli algoritmi PRR e [RFC6675] mostrando come differiscono nella loro risposta a due scenari di esempio: una connessione che subisce la perdita di un singolo pacchetto o una raffica di 15 pacchetti consecutivi persi.

Configurazione dello scenario di test​

Tutti i casi utilizzano:

  • Trasferimento dati in blocco (nessuna pausa dell'applicazione)
  • Controllo della congestione Reno [RFC5681]
  • Stato iniziale: cwnd = FlightSize = inflight = 20 segmenti
  • ssthresh: Sarà impostato a 10 all'inizio del ripristino
  • Fast Retransmit: Utilizza il fast retransmit standard [RFC5681]
  • Limited Transmit [RFC3042]: Invia 2 nuovi segmenti + 1 ritrasmissione in risposta ai primi tre ACK duplicati

Spiegazione del diagramma​

I seguenti diagrammi mostrano la risposta per ACK per il primo round trip dopo la perdita del segmento 0. La riga superiore ("ack#") indica il numero di segmento che ha attivato l'ACK, con X che indica i segmenti persi.

Le righe "cwnd" e "inflight" mostrano i valori di cwnd e inflight di questi algoritmi dopo l'elaborazione di ciascun ACK di ritorno ma prima di ulteriori (ri)trasmissioni. La riga "sent" indica quanti "N" nuovi dati o "R" ritrasmissioni verranno inviati.

Esempio 1: Perdita di un singolo segmento​

RFC 6675
a  X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
c 20 20 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
i 19 19 18 18 17 16 15 14 13 12 11 10  9  9  9  9  9  9  9  9  9  9
s  N  N  R  N  N  N  N  N  N  N  N  N  N

PRR
a  X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22
c 20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10 10
i 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 10  9  9
s  N  N  R  N  N  N  N  N  N  N  N  N  N

a: ack#; c: cwnd; i: inflight; s: sent

Analisi​

In questo primo esempio:

Sequenza ACK:

  • Gli ACK dal #1 al #19 trasportano SACK del volo di dati originale
  • Gli ACK #20 e #21 trasportano SACK per i due segmenti attivati da limited transmit
  • L'ACK #22 trasporta un ACK cumulativo completo che copre tutti i dati (incluso limited transmit)
  • L'ACK #22 completa la fase di fast recovery, completando così la fase PRR

Confronto dei comportamenti:

  • Entrambi gli algoritmi inviano la stessa quantità totale di dati
  • Entrambi terminano il fast recovery con cwnd corrispondente a ssthresh con un valore di 20
  • RFC 6675 sperimenta un "silenzio di mezza finestra"
  • PRR distribuisce le riduzioni volontarie della finestra sull'intero RTT

Esempio 2: Perdita a raffica di 15 segmenti​

Successivamente, consideriamo lo scenario di esempio con le stesse condizioni iniziali, tranne che i primi 15 pacchetti (0-14) vengono persi. Durante il resto del RTT con perdite, solo 5 ACK vengono restituiti al mittente. Ciascun algoritmo viene esaminato in sequenza di seguito.

RFC 6675
a  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
c 20 20 10 10 10
i 19 19  4  9  9
s  N  N  6R  R  R

PRR
a  X  X  X  X  X  X  X  X  X  X  X  X  X  X  X 15 16 17 18 19
c 20 20  5  5  5
i 19 19  4  4  4
s  N  N  R  R  R

a: ack#; c: cwnd; i: inflight; s: sent

Analisi​

In questo caso particolare:

Comportamento RFC 6675:

  • Una volta attivato il fast retransmit (sull'ACK del segmento 17), il mittente ritrasmette immediatamente dati sufficienti affinché inflight aumenti per corrispondere a cwnd
  • Le misurazioni iniziali (discusse nella sezione 6 di [RFC6675]) mostrano che [RFC6675] supera significativamente la versione [RFC6937] di PRR (che utilizzava solo PRR-CRB) e altri algoritmi simili testati in modo conservativo
  • Dimostra che le situazioni in cui le perdite effettive superano la riduzione di cwnd determinata dall'algoritmo di controllo della congestione sono molto comuni

Comportamento PRR:

  • Durante il primo RTT del fast recovery, PRR segue la conservazione dei pacchetti utilizzando PRR-CRB
  • Poiché le perdite totali mantengono inflight sotto ssthresh, i dati inviati fanno sì che i dati totali trasmessi prr_out seguano i dati totali riportati dagli ACK di ritorno come consegnati al ricevitore
  • Le trasmissioni sono controllate dal limite di invio, impostato su prr_delivered - prr_out

Processo di ripristino:

  • Sebbene non mostrato nel diagramma, una volta che le ritrasmissioni rapide inviate a partire dall'ACK #17 vengono consegnate e causano ACK che aumentano SND.UNA, PRR entra in PRR-SSRB
  • Aumenta la finestra di esattamente 1 segmento per ACK durante il ripristino fino a quando inflight raggiunge ssthresh durante il ripristino
  • Per perdite gravi quando cwnd è grande, PRR-SSRB recupera esponenzialmente più velocemente di PRR-CRB
  • Sebbene possa sembrare imprudente aumentare la finestra durante il ripristino, è importante ricordare che questo è in realtà più conservativo di ciò che [RFC6675] consente, che invia la stessa quantità di dati aggiuntivi come singola raffica in risposta all'ACK che ha attivato il fast retransmit

Casi di perdita lieve: Per eventi di perdita meno gravi in cui le perdite totali sono inferiori alla differenza tra FlightSize e ssthresh, PRR-CRB e PRR-SSRB non vengono invocati perché PRR rimane in modalità di riduzione proporzionale della velocità.

Ultimo aggiornamento il