In che modo sono correlati l'accodamento ponderato equo e il rilevamento casuale casuale ponderato?

Sto cercando di capire come funzionano i sistemi QoS e non sono sicuro di come interagirebbero esattamente WFQ e WRED.

All'inizio, ho pensato che WFQ fosse un meccanismo di accodamento e che WRED fosse un meccanismo di prevenzione della congestione. WFQ dovrebbe programmare i pacchetti nelle code e WRED è lì per rilasciarli quando le code sono piene. Se sto impostando QoS per esempio su uno switch L3, creerei un meccanismo di accodamento e un meccanismo di prevenzione della congestione, quindi in teoria potrei avere WFQ e WRD che lavorano insieme. Ad esempio, questo documento sembra implicare che sarebbero stati istituiti in questo modo. Alcuni altri documenti Cisco menzionano che potrei usarli indipendentemente.

Quindi volevo saperne di più su come funzionavano e ho iniziato a cercare in Internet. Di conseguenza, ora non ho idea di cosa siano e come funzionano.

Alcuni siti (almeno per quanto ne so del contenuto) sostengono che gli algoritmi di pianificazione dei pacchetti e gli algoritmi di prevenzione della congestione sono sostanzialmente gli stessi. Ad esempio in questo articolo di Wikipedia, sono tutti inseriti in uno stesso gruppo. Alcuni articoli casuali menzionavano che avrei potuto usare WFQ XOR WRED.

Quindi quello che volevo chiedere è quanto sono correlati WFQ e WRED? Quando userei l'uno o l'altro e quando entrambi, se fosse possibile?

Il ponderato Accodamento equo (WFQ) è come il nome implica un algoritmo di accodamento. L'accodamento viene utilizzato in caso di congestione su un'interfaccia. Questo viene di solito rilevato attraverso che l'anello di trasmissione (TX-Ring) è pieno. Ciò significa che l'interfaccia è occupata nell'invio di pacchetti. L'accodamento non ha luogo a meno che non ci sia congestione sull'interfaccia. In alcuni casi è possibile manipolare la dimensione dell'anello TX. Un piccolo TX-ring fornisce alla coda del software più potenza su quali pacchetti vengono inviati per primi ma non è molto efficace. Un anello TX troppo grande renderebbe la coda del software quasi inutile e porterebbe a latenza e jitter più elevati per i pacchetti importanti.

L'algoritmo di accodamento predefinito è in genere First In First Out (FIFO). Ciò significa che i pacchetti vengono consegnati esattamente nell'ordine in cui arrivano sull'input dell'interfaccia. Questo di solito non è desiderabile perché alcuni pacchetti dovrebbero avere la priorità.

È abbastanza comune che un cliente acquisti un servizio da un provider di servizi Internet (ISP) a Subrate. Cioè, il cliente acquista un servizio a 50 Mbit / s ma l'interfaccia fisica funziona a 100 Mbit / s. In questo caso non ci sarà congestione, ma l'ISP limiterà la quantità di traffico dal cliente. Per introdurre la congestione artificiale in questi casi è possibile applicare uno shaper.

Quindi ora che c'è congestione è possibile applicare un algoritmo di accodamento. Si noti che gli algoritmi di accodamento non forniscono alcuna larghezza di banda aggiuntiva, ma ci lasciano solo decidere quali pacchetti sono più importanti per noi. WFQ è un algoritmo che accetta diversi parametri e prende una decisione in base a quello. L'algoritmo è piuttosto complesso e utilizza peso (precedenza IP), dimensione dei pacchetti e tempo di pianificazione come parametri. C'è una spiegazione molto dettagliata da INE qui. WFQ è una buona scelta se non si vuole armeggiare troppo con l'accodamento poiché fornisce una larghezza di banda adeguata a flussi di piccole dimensioni come SSH, Telnet, voce e ciò significa che un trasferimento di file non ruberà tutta la larghezza di banda.

La rilevazione precoce casuale ponderata (WRED) è un meccanismo di prevenzione della congestione. WRED misura la dimensione delle code in base al valore di Precedenza e inizia a eliminare i pacchetti quando la coda è compresa tra la soglia minima e la soglia massima. La configurazione deciderà che 1 in ogni N pacchetti vengono eliminati. WRED aiuta a prevenire la sincronizzazione TCP e la fame di TCP. Quando TCP perde i pacchetti, si avvia lentamente e se tutte le sessioni TCP perdono i pacchetti contemporaneamente, potrebbero sincronizzarsi, fornendo un grafico come questo:

Come si può vedere se WRED non è configurato, il grafico diventa full blast, quindi silent, poi full blast e così via. WRED fornisce una velocità di trasmissione più media. È importante notare che UDP non viene influenzato dal rilascio di pacchetti perché non ha meccanismi di riconoscimento e finestre scorrevoli implementate come TCP. Pertanto WRED non deve essere implementato su una classe basata su UDP come una classe che gestisce protocolli SNMP, DNS o altri protocolli basati su UDP.

Sia WFQ che WRED possono e devono essere distribuiti insieme.

Prima di tutto, non credere a tutto ciò che leggi su Internet ;-)

A volte gli algoritmi (o il modo in cui sono implementati fisicamente) non si adattano perfettamente a una categoria teorica. Ciò che lo chiami è meno importante della comprensione di ciò che fa.

Il punto centrale di WFQ (o di qualsiasi altro algoritmo di schedulazione) è condividere la larghezza di banda del collegamento limitato tra i vari flussi. WFQ tenta di allocare la larghezza di banda proporzionalmente a ciascun flusso. CBWFQ fa lo stesso per ogni "classe". In un mondo perfetto, con code illimitate e memoria illimitata, sarebbe tutto ciò di cui hai bisogno: condividi la larghezza di banda e tutti sono felici.

Ma poiché i dispositivi non hanno code e memoria illimitate, è necessario creare alcune "scorciatoie". Poiché una coda ha dimensioni limitate, esiste il pericolo che la coda si riempia, causando cadute di coda e sincronizzazione del traffico. In sostanza, se la mia coda è straripante, non controllo più la larghezza di banda.

Per evitare lo straripamento delle mie code, utilizzo Random Early Detection. Questo algoritmo elimina casualmente i pacchetti dalla coda in base alla quantità della coda (profondità): più la coda è piena, più i pacchetti verranno eliminati. L'obiettivo è evitare che la coda trabocchi, in modo che l'algoritmo di pianificazione possa funzionare.

Quindi un brillante ingegnere Cisco ha notato che si potevano usare meno code (hardware più semplice) e rilasciare casualmente diversi tipi di traffico a diverse profondità della coda. WRED elimina il traffico dalla coda a diverse profondità a seconda del tipo di traffico. Sebbene sia possibile chiamare WRED un meccanismo di prevenzione della congestione, poiché la profondità in cui viene rilasciato il traffico varia a seconda del tipo di traffico, l' effetto è che tipi diversi ottengono meno spazio nella coda e quindi meno larghezza di banda. Quindi funge anche da algoritmo di pianificazione. Dici po-tay-to e io dico po-tah-toe.

Un'altra differenza: FQ e WFQ funzionano su tutti i tipi di traffico, poiché essenzialmente contano i byte. RED e WRED funzionano solo con TCP, poiché dipendono dal meccanismo di controllo del flusso di TCP per rallentare il traffico e impedire che la coda trabocchi.

(Nota: per motivi di spiegazione, sto ignorando le code prioritarie e LLQ. Questa è un'altra risposta).

Sono d'accordo con tutto ciò che ha detto anche Mike.

Ecco un esempio di CBWFQ e WRED:

mappa delle politiche OUT

classe
Priorità vocale percentuale 20

class Percentuale di
larghezza di banda video 30

classe P1
larghezza di banda percentuale 10
rilevamento
casuale basato su dscp rilevamento casuale dscp af31 26 40 10

percentuale di larghezza di banda di classe P2 15
rilevamento
casuale basato su dscp rilevamento casuale dscp af21 24 40 10

basato su dscp basato su dscp per il rilevamento casuale delle
code di classe