Il metodo descritto in questo documento dovrebbe funzionare anche in altri scenari in ogni caso rimane non testato in tutte le configurazioni eccettuata la seguente:
Red Hat Linux 7.3
Kernel 2.4.18-5 con il supporto QoS fully enabled (moduli OK) con incluse le seguenti patch (le quali potrebbero essere incluse in kernel più recenti):
HTB queue - http://luxik.cdi.cz/~devik/qos/htb/
Nota: è stato segnalato che i kernel dalla versione 2.4.18-3 distibuiti con Mandrake (8.1, 8.2) sono già patchati per l'HTB.
IMQ device - http://luxik.cdi.cz/~patrick/imq/
iptables 1.2.6a o superiore (la versione di iptables distribuita con Red Hat 7.3 manca del length module)
Per facilitare le cose, tutti i riferimenti ai dispositivi di rete e le configurazioni in questo documento si riferiranno al seguente schema:
<-- 128kbit/s -------------- <-- 10Mbit -->
Internet <--------------------> | ADSL Modem | <--------------------
1.5Mbit/s --> -------------- |
| eth0
V
-----------------
| |
| Linux Router |
| |
-----------------
| .. | eth1..ethN
| |
V V
Rete Locale
|
Le Code Pacchetto sono contenitori che mantengono i dati per un dispositivo di rete quando essi non possono essere immediatamente inviati. La maggior parte delle Code Pacchetto utilizzano una disciplina FIFO (first in, first out)a meno che non siano state configurate per fare altrimenti. Questo significa che quando la Coda Pacchetto di un particolare device è completamente piena, il pacchetto più recente posto in essa sarà inviato al dispositivo solo dopo che tutti gli altri pacchetti nella coda in quel momento saranno stati inviati.
Con un modem ADSL, la larghezza di banda è asimmetrica con 1.5Mbit/s di downstream e 128kbit/sec di upstream tipici. Benché questa sia la velocità della linea, l'interfaccia tra il Router Linux e il modem ADSL è tipicamente prossima ai 10Mbit/s. Se l'interfaccia con la rete locale è lo stesso a 10Mbit/s, ci sarà tipicamente un NO QUEUING sul router quando i pacchetti vanno dalla Rete Locale a Internet. I pacchetti sono inviati fuori da eth0 alla stessa velocità a cui sono stati ricevuti dalla Rete Locale. Diversamente sul modem ADSL, i pacchetti vengono messi in coda, dato che essi arrivano a 10Mbit/s e possono essere inviati solo a 128kbit/s. Nell'eventualità la Coda Pacchetto sul modem ADSL diventa piena e ogni pacchetto in più inviatogli verrà silenziosamente scartato. Il TCP è progettato per ovviare a questo problema e provvederà ad aggiustare la dimensione della finestra di trasmissione per ottenere il massimo vantaggio dalla banda disponibile.
Mentre le Code Pacchetto combinate con il TCP danno come risultato un più efficiente uso della larghezza di banda, grandi code FIFO possono aumentare la latenza per il traffico di tipo interattivo.
Un altro tipo di coda con una disciplina alquanto simile a FIFO viene detta coda di priorità n-band (n-band priority queue). In questo caso, invece di avere una sola coda dove mettere i dati, la coda di priorità n-band ha n code FIFO nelle quali i pacchetti sono messi a seconda della loro classificazione. Ogni coda ha una priorità e i pacchetti sono sempre inviati a partire dalla coda con priorità più alta che ne contiene. Utilizzando questa disciplina i pacchetti FTP possono essere messi in una coda con priorità più bassa rispetto a pacchetti telnet cosi che durante un FTP upload, un singolo pacchetto telnet può saltare la coda ed essere inviato immediatamente.
Questo documento è stato rivisto per utilizzare una nuova coda di linux chiamata Hierarchical Token Bucket (HTB). La coda HTB è qualcosa in più rispetto alla coda n-band descritta sopra, e ha la capacità di limitare il tasso di traffico in ciascuna classe. In aggiunta, ha anche la possibilità di creare classi di traffico al di sotto di altre classi creando una gerarchia. La descrizione completa di HTB va oltre lo scopo di questo documento, maggiori informazioni si trovano presso http://www.lartc.org
Il traffico entrante sul vostro modem ADSL viene messo in coda all'incirca come il traffico uscente , in questo caso la coda sta dal vostro ISP. A causa di ciò, probabilmente non avete il controllo diretto di come i pacchetti vengono messi in coda o quale tipo di traffico richiede trattamento preferenziale. L'unico modo di mantenere la latenza bassa è essere sicuri che gli utenti non inviino dati troppo velocemente. Sfortunatamente, non c'è modo di controllare direttamente la velocità a cui i pacchetti arrivano, tuttavia da quando la gran parte del traffico sulle vostre reti è costituita dal TCP, ci sono alcuni modi di rallentare chi invia i dati:
Scartare intenzionalmente pacchetti entranti - il TCP è progettato per ottenere il massimo vantaggio dalla banda disponibile e allo stesso tempo evitare la congestione del link. Questo significa che durante un trasferimento , TCP invia una sempre maggiore quantità di dati fino a che eventualmente un pacchetto viene scartato. TCP riesce a rilevare questo e di conseguenza riduce la sua finestra di trasmissione. Questo ciclo continua durante tutto il processo e assicura che i dati vengano spostati il più velocemente possibile.
Manipolare gli avvisi di ricezione finestra - Durante un trasferimento TCP , il ricevente invia indietro un flusso continuo di pacchetti di acknowledgment (ACK). Inclusi in questi pacchetti ACK c'è un avviso di dimensione finestra il quale dichiara il totale massimo di dati non riconosciuti che il ricevente dovrebbe inviare. Manipolando la dimensione finestra dei pacchetti ACK uscenti possiamo intenzionalmente rallentare chi invia i dati. Attualmente non c'è nessuna (libera) implementazione per questo tipo di controllo di flusso su Linux (Comunque potrei lavorarci su!).