Vorrei aggiungere una sorta di gestione del traffico alla nostra linea Internet. Dopo aver letto molta documentazione, penso che HFSC sia troppo complicato per me (non capisco tutto il materiale delle curve, temo di non riuscire mai a farlo bene), CBQ non è raccomandato e fondamentalmente HTB è il modo di andare per la maggior parte delle persone.
La nostra rete interna ha tre "segmenti" e mi piacerebbe condividere la larghezza di banda più o meno equamente tra quelli (almeno all'inizio). Inoltre, devo dare la priorità al traffico in base ad almeno tre tipi di traffico (traffico in tempo reale, traffico standard e traffico di massa). La condivisione della larghezza di banda non è importante quanto il fatto che il traffico in tempo reale dovrebbe sempre essere trattato come traffico premium ogni volta che è possibile, ma ovviamente nessun'altra classe di traffico può morire di fame.
La domanda è: cosa ha più senso e garantisce anche una migliore produttività in tempo reale:
Creazione di una classe per segmento, ognuna con la stessa frequenza (la priorità non ha importanza per le classi che non sono lasciate secondo lo sviluppatore HTB) e ciascuna di queste classi ha tre sottoclassi (foglie) per i 3 livelli di priorità (con priorità diverse e tariffe diverse).
Avere una classe per livello di priorità in cima, ognuna con un tasso diverso (di nuovo la priorità non ha importanza) e ognuna con 3 sottoclassi, una per segmento, mentre tutte e 3 nella classe in tempo reale hanno il prio più alto, il prio più basso nella massa classe e così via.
Proverò a renderlo più chiaro con la seguente immagine di arte ASCII:
Case 1:
root --+--> Segment A
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment B
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment C
+--> High Prio
+--> Normal Prio
+--> Low Prio
Case 2:
root --+--> High Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Normal Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Low Prio
+--> Segment A
+--> Segment B
+--> Segment C
Caso 1 Sembra come farebbe la maggior parte delle persone, ma se non leggo correttamente i dettagli dell'implementazione HTB, il Caso 2 potrebbe offrire una migliore definizione delle priorità.
Il manuale HTB afferma che se una classe ha raggiunto il suo tasso, può prendere in prestito dal suo genitore e, quando prende in prestito, alle classi con priorità più alta viene sempre offerta la larghezza di banda per prima. Tuttavia, afferma anche che le classi con larghezza di banda disponibile a un livello di albero inferiore sono sempre preferite a quelle a un livello di albero superiore, indipendentemente dalla priorità .
Supponiamo la seguente situazione: il segmento C non sta inviando alcun traffico. Il segmento A sta inviando solo traffico in tempo reale, il più velocemente possibile (abbastanza per saturare il collegamento da solo) e il segmento B sta inviando solo traffico di massa, il più velocemente possibile (ancora, abbastanza per saturare l'intero collegamento da solo). Cosa accadrà?
Caso 1:
Il segmento A-> Prio alto e il segmento B-> Prio basso hanno entrambi pacchetti da inviare, poiché A-> Prio alto ha la priorità più alta, sarà sempre programmato per primo, fino a quando non raggiungerà la sua velocità. Ora cerca di prendere in prestito dal segmento A, ma poiché il segmento A è a un livello più alto e il segmento B-> Prio basso non ha ancora raggiunto il suo tasso, questa classe è ora servita per prima, fino a quando non colpisce anche il tasso e vuole prendere in prestito da Segmento B. Una volta che entrambi hanno toccato i loro tassi, entrambi sono di nuovo allo stesso livello e ora il segmento A-> Alto Prio vincerà di nuovo, fino a raggiungere il tasso del segmento A. Ora prova a prendere in prestito dalla radice (che ha molto traffico di riserva, poiché il segmento C non utilizza alcuno del suo traffico garantito), ma deve ancora attendere che il segmento B-> Low Prio raggiunga anche il livello principale. Una volta che succede,
Caso 2:
Alta Prio-> Segmento A e Bassa Prio-> Segmento B hanno entrambi pacchetti da inviare, di nuovo Alta Prio-> Segmento A vincerà poiché ha la priorità più alta. Una volta raggiunto il suo tasso, tenta di prendere in prestito da High Prio, che ha una larghezza di banda libera, ma essendo a un livello più alto, deve attendere di nuovo Low Prio-> Segmento B per raggiungere anche il suo tasso. Una volta che entrambi hanno raggiunto il loro tasso ed entrambi devono prendere in prestito, l'Alto Prio-> Segmento A vincerà nuovamente fino a raggiungere il tasso della classe Alto Prio. Una volta che ciò accade, tenta di prendere in prestito da root, che ha ancora molta larghezza di banda rimasta (al momento non viene utilizzata tutta la larghezza di banda di Normal Prio), ma deve attendere di nuovo fino a quando Low Prio-> Segment B raggiunge il limite di frequenza del Classe Prio bassa e cerca anche di prendere in prestito dalla radice. Alla fine entrambe le classi cercano di prendere in prestito dalla radice, viene presa in considerazione la priorità e High Prio->
Entrambi i casi sembrano non ottimali, poiché in entrambi i casi il traffico in tempo reale a volte deve attendere il traffico di massa, anche se è rimasta molta larghezza di banda che potrebbe prendere in prestito. Tuttavia, nel caso 2 sembra che il traffico in tempo reale debba attendere meno rispetto al caso 1, poiché deve solo attendere fino a quando non viene colpito il traffico di massa, che è molto probabilmente inferiore al tasso di un intero segmento (e nel caso 1 è il tasso che deve attendere). O mi sbaglio totalmente qui?
Ho pensato a configurazioni ancora più semplici, usando un qdisc prioritario. Ma le code prioritarie hanno il grosso problema di causare fame se non sono limitate in qualche modo. La fame non è accettabile. Ovviamente si può mettere un TBF (Token Bucket Filter) in ogni classe di priorità per limitare la velocità ed evitare così la fame, ma in tal caso, una singola classe di priorità non può più saturare il collegamento da sola, anche se tutte le altre classi di priorità sono vuoti, il TBF impedirà che ciò accada. E questo è anche non ottimale, dal momento che una classe non dovrebbe ottenere il 100% della larghezza di banda della linea se nessun'altra classe ne avesse bisogno al momento?
Hai commenti o idee su questa configurazione? Sembra così difficile da fare usando qcisc standard tc. Come programmatore è stato un compito così semplice se potessi semplicemente scrivere il mio programmatore (cosa che non mi è permesso fare).