4. Modifiche rispetto a RFC 6937 (Changes Relative to RFC 6937)

Il cambiamento più grande rispetto a [RFC6937] è l'introduzione di una nuova euristica che utilizza un buon progresso di ripristino (per TCP, quando l'ultimo ACK fa avanzare SND.UNA e non indica che una fast retransmit precedente è stata persa) per selezionare il limite di riduzione (PRR-CRB o PRR-SSRB).

[RFC6937] lasciava la scelta del limite di riduzione alla discrezione dell'implementatore, ma raccomandava di utilizzare PRR-SSRB come predefinito. Per tutti gli ambienti esplorati nella ricerca PRR precedente, la nuova euristica è coerente con la vecchia raccomandazione.

Introduzione dell'euristica SafeACK

Il documento "Analisi Internet-Wide del policing del traffico" [Flach2016policing] ha scoperto un caso critico precedentemente inesplorato in cui entrambi i limiti di riduzione funzionano male, ma per ragioni diverse.

Sfida dei policer a token bucket

In molte configurazioni, i policer del traffico a token bucket possono iniziare bruscamente a scartare la maggior parte del traffico quando i token sono esauriti, senza alcun avviso ai sistemi terminali. Il controllo della congestione del trasporto non ha alcuna opportunità di misurare il tasso di token e impostare ssthresh in base alle prestazioni del percorso precedentemente osservate. Questo valore di ssthresh può portare a un tasso di dati molto maggiore del tasso di rifornimento dei token, con conseguenti alti tassi di perdita di pacchetti.

In queste condizioni, entrambi i limiti di riduzione funzionano male:

• PRR-CRB è troppo conservativo - a volte risulta in un ripristino molto lungo con una finestra molto più piccola del necessario
• PRR-SSRB è troppo aggressivo - spesso risulta in più round di ritrasmissioni perse, entrambi i casi risultano in tempi di ripristino prolungati che impattano gravemente la latenza e/o il throughput dell'applicazione

Soluzione SafeACK

L'indagine di questi ambienti ha portato allo sviluppo dell'euristica "SafeACK" per commutare dinamicamente il limite di riduzione:

• Predefinito PRR-CRB - iniziare il ripristino in modo conservativo
• Condizione per passare a PRR-SSRB - solo quando un ACK indica che il ripristino sta procedendo bene (SND.UNA avanza e nessuna nuova perdita di pacchetti rilevata)

L'euristica SafeACK è stata sperimentata presso la rete di distribuzione dei contenuti (CDN) di Google [Flach2016policing] ed è stata implementata in Linux TCP dal 2015.

Scenari di applicazione

L'euristica SafeACK viene invocata solo quando:

• La perdita di pacchetti, il comportamento limitato dall'applicazione o altri eventi causano la caduta della stima corrente dei dati in volo al di sotto di ssthresh
• Alti tassi di perdita di pacchetti rendono l'euristica critica, il che è comune solo in presenza di perdite di pacchetti gravi, come i policer del traffico [Flach2016policing]
• In questi ambienti, l'euristica supera l'uso di uno dei due limiti da solo