Come viene gestito il QoS dal Fritz

Da Vocesuip.

Il ToS è soltanto un flag contenuto nei pacchetti IP. Tempo fa fu battezzato uno dei byte non usati (reserved) all'interno del pacchetto in modo che impostando determinati bit i vari router, in fase di gestione delle code, potessero intraprendere delle azioni differenti per realizzare ed implementare una sorta di QoS. Il QoS era l'obiettivo da raggiungere, visto che il protocollo IP è nato come Best Effort Service e non aveva nessuna caratteristica che permettesse il QoS.

Pensare ad un QoS che attraversi tutta la rete fino alla destinazione è impossibile, a meno che tutti i provider e tutte le network non si accordino sugli stessi principi: questo era un pò quello che accadeva 10 anni fa quando nelle università si faceva ricerca sul modo di implementare i cosidetti DS (servizi differenziati) su rete IP con scarsi risultati.

In realtà è possibile fare QoS in locale, sul proprio border router o modem adsl, per avere migliori prestazioni sul traffico in uscita (e tramite i pacchetti ack anche in ingresso). Non è possibile fare QoS sul traffico in ingresso, non per problemi tecnici, ma per un discorso di utilità: una volta che il pacchetto ha attraversato tutta la rete ed è giunto a destinazione, scartarlo o prioritizzarlo produce solo effetti negativi quali buffering, latenza e ritrasmissioni (= spreco di banda).

Visto che quindi l'unica è implementare un QoS in uscita dal proprio border router o dal proprio modem adsl si possono utilizzare le più svariate tecniche o algoritmi: si possono utilizzare code HTB o CBQ che permettono un controllo granulare sulla quantità di banda per servizio (usati in Linux), oppure si può utilizzare un più semplice ma ugualmente efficace algoritmo di ripartizione proporzionale come WF2Q+ (usato in FreeBSD), oppure si può usare un banale algoritmo a priorità PRIO (come quello usato dal Fritz).

Rimane comunque il fatto che occorre in qualche modo 'selezionare' i pacchetti per passarli in modo corretto ad uno degli algoritmi visti sopra. Questa cosa può essere fatta filtrando le porte, gli indirizzi, la dimensione del payload, i flag TCP oppure, perché no, il flag ToS all'interno del pacchetto IP. E' soltanto un mettersi d'accordo, tutto qui.

Ora tornando a noi, di default il Fritz utilizza una coda PRIO e fa un leggero shaping.

Vediamo lo shaping:


bps_limit {
   limit_total = 100;
   limit_p0 = 0;
   limit_p1 = 95;
   limit_p2 = 95;
   limit_p3 = 0;
}

Intanto fa uno shaping globale del 100%, poi limita i flussi a priorità 1 e 2 al massimo al 95%. Questo vuole dire che con la linea di upload completamente libera, se tiro fuori un flusso al massimo sulla coda 1 o sulla coda 2 non supero il 95% di banda occupata.

Le code come dicevo sono 4 numerate da 0 a 3, la 0 è quella bulk, la 3 è quella a priorità più alta.

Per decidere quali pacchetti instradare su quali code il Fritz usa una sintassi molto simile a tcpdump:


                       out_rules {
                               name = "download-tcp-ack";
                               filter = "tcp and len <= 64";
                               priority = 2;
                               limiters = "default-out";
                       } {
                               name = "dns";
                               filter = "udp port 53";
                               priority = 1;
                               limiters = "default-out";
                       } {
                               name = "fon-rtp";
                               filter = "udp[8] = 0x80 or udp port 5060";
                               priority = 3;
                               limiters = "default-out";
                       } {
                               name = "http-requests";
                               filter = "(tcp dst port 80 or dst port 8080 or  dst port 3128) and (len <= 800)";
                               priority = 1;
                               limiters = "default-out";
                       } {
                               name = "pri-out";
                               filter = "icmp";
                               priority = 1;
                               limiters = "default-out";
                       } {
                               name = "default";
                               filter = "";
                               priority = 0;
                               limiters = "default-out";
                       }


Nella coda 2 ci finiscono gli ack, ovvero tutti i pacchetti tcp con dimensione inferiore a 64 byte, in realtà la regola è un pò superficiale poiché non testa il flag tcp ack, ma semplicemente filtra sulla dimensione. Mettere in priorità alta gli ack significa avere buone velocità di download quando il canale di upload è saturo. Per maggiori info a riguardo vi rimando qui: http://www.benzedrine.cx/ackpri.html.

Nella coda 1 le richieste dns filtrate in base alla porta udp 53, i pacchetti icmp (ad esempio i ping, così i valori dei ping sembrano sempre buoni anche se il link è saturo) e per finire le richieste http: furbi quelli della AVM, danno priorità a tutti i pacchetti diretti verso le porte 80, 8080 e 3128 (web e proxy) con lunghezza inferiore a 800 byte, quanto basta per inoltrare una richiesta ad un server web.

Nella coda 3 ci finisce la parte che riguarda la telefonia e cioè pacchetti UDP con il flag ToS impostato a 0x80 oppure pacchetti UDP in cui la porta sorgente o destinazione è 5060.

Ora, se abbiamo esigenze differenti, giocando con le regole è possibile variare il modo in cui devono essere gestiti i pacchetti: ad esempio possiamo aggiungere in coda 2 il traffico ssh o vnc che richiede una certa bassa latenza.


Ad ogni modo la domanda da un milione di dollari: perché mentre siamo in telefonata la velocità di download scende se il fritz fa QoS solo in upload? Semplice: il 99% del traffico in download è in TCP e per sua natura il TCP vuole che ad ogni pacchetto ricevuto, il ricevente invii un pacchetto di conferma ACK, la velocità di risposta agli ACK determina la velocità con cui l'host inviante manda i pacchetti in rete. Detto questo il QoS del Fritz mette gli ACK in coda 2 e la voce in coda 3, la voce, avendo più priorità, rallenta l'invio degli ACK e quindi l'host inviante rallenta il ritmo di invio dei pacchetti. Ecco spiegato il download che scende mentre siamo in telefonata facendo QoS solo in uscita.


Estratto da http://www.vocesuip.com/2-vt6268.html?postdays=0&postorder=asc&start=20#_Single_Post_View

Strumenti personali