Standard Linux kernel Traffic Management

Linux offre un ricco set di strumenti per gestire e manipolare la trasmissione di pacchetti. Esistono letteralmente centinaia di tool e servizi di rete che possono girare su tale sistema operativo che permettono di implementare politiche di gestione del traffico anche decisamente sofisticate. Oltre a ciò anche il sottosistema di gestione della rete implementato nel kernel ha una struttura articolata e sofisticata. A titolo di esempio in Appendice C per consentire una migliore leggibilità, Figura C.1, è riportato il diagramma completo che descrive tutti i blocchi di elaborazione presenti nel sottosistema di rete del kernel Linux attuale, versione 2.6.

Controllo del Traffico (ovvero Traffic Control, nel seguito TC) è il nome attribuito ad un sistema di code e più in generale di meccanismi tramite i quali i pacchetti che formano il traffico di una rete TCP/IP vengono ricevuti e trasmessi da un nodo della rete stessa. Le operazioni normalmente eseguite comprendono ad esempio decidere quali e quanti pacchetti accettare e a che ritmo all’ingresso di una interfaccia di rete, ed anche quali pacchetti, in che ordine e a che ritmo trasmettere pacchetti in uscita da una interfaccia.

La situazione più semplice che si può immaginare di TC, che corrisponde a quanto accade in molte situazioni, consiste di una singola coda che raccoglie tutti i pacchetti in ingresso e in seguito li ritrasmette alla massima velocità alla quale l’hardware seguente o il sistema operativo sono in grado di gestirli.

Un coda di questo tipo è detta in inglese First In First Out, ovvero FIFO.

La politica di default di TC di Linux in ingresso ha un comportamento di questo tipo, mentre in uscita è implementata una politica un pò più sofisticata, che è caratterizzata da un numero maggiore di code. Avere una singola coda per tutto il traffico può comportare problemi ad esempio nel momento in cui il traffico generato da due macchine concorrenti dovesse saturare

il canale trasmissivo. Se ammettiamo che una delle due macchine possa generare la quasi totalità del traffico in maniera tale da saturare le code disponibili, l’altra macchina potrebbe non riuscire a comunicare in rete vedendosi scartare gran parte dei pacchetti a causa del riempimento dell’unica coda disponibile.

La separazione delle code associate a tipi di traffico diversi in un caso del genere può essere molto utile per far sì che diverse applicazioni possano condividere in modo efficace lo stesso canale trasmissivo. TC è il set di strumenti che consente di avere un controllo granulare sulle code legate alle interfacce di rete e sui loro meccanismi di gestione, e può essere molto utile ad implementare la politica di gestione a priorità richiesta dal nuovo protocollo.

Nel nostro caso si vorrebbe ottenere bassa latenza per le applicazioni che richiedono prestazioni real-time, consentendo però anche la contemporanea trasmissione di dati a priorità normale.

Nella seguente Figura 6.6 è evidenziata la struttura di gestione del traffico utilizzata di default in uscita nel kernel linux 2.6:

Figura 6.6: Default output policy del Linux kernel 2.6

Il nome che nel kernel Linux viene dato a strutture di questo tipo è qdisc. Un qdisc detto semplicemente è una sorta di scheduler associato ad una interfaccia di rete. In realtà un qdisc è qualcosa di più complesso, dato dalla associazione di alcune strutture dati alle quali è possibile associare dei comportamenti, ottenendo come risultato delle politiche anche decisamente complesse. Però per quanto riguarda il presente lavoro la definizione introdotta è sufficiente, e si è ritenuto inutile approfondire troppo la questione. In ogni caso ulteriori riferimenti per reperire ulteriori elementi sono segnalati a fine paragrafo. La struttura evidenziata in figura fa

riferimento al qdisc detto ‘pfifo_fast’, ed è in pratica ottenuta dalla combinazione di tre code FIFO, che singolarmente non effettuano nessun speciale trattamento sui pacchetti. Quello che però realizza una gestione del traffico è la suddivisione stessa del traffico in code separate e la politica di svuotamento delle code stesse. Finché sono presenti pacchetti in una coda a più alta priorità le altre code non vengono processate. Il kernel Linux onora il flag ‘Type of Service’ presente nei pacchetti IP, ed automaticamente inserisce i pacchetti contrassegnati a minimo ritardo (‘minimum delay’) nella coda a massima priorità.

Questo comportamento è molto simile a quanto si vorrebbe per il progetto del nuovo protocollo nel campo agricolo oggetto del Task 2, ed è stato estensivamente utilizzato nei test preliminari. Il protocollo si propone di estendere ad un numero maggiore di livelli di priorità la gestione del traffico, ma molto probabilmente ciò si può ottenere tramite una semplice ‘riprogrammazione’ del kernel e opportuna marcatura del traffico in modo da implementare il comportamento richiesto. Ulteriori opzioni sono state considerate, viste le varie possibilità di sviluppo del nuovo Standard, ma il loro trattamento esula dagli scopi del presente documento. E’ molto importante notare però che mentre la politica di default per il traffico in uscita da un sistema Linux è già molto vicina al caso ideale, così non avviene per quanto riguarda l’ingresso. Infatti il TC sotto Linux non consente di implementare in ingresso politiche di gestione del traffico altrettanto sofisticate, anzi l’unica disponibile è del tipo singola coda FIFO, con la possibilità aggiuntiva di poter eventualmente solo scartare dei pacchetti in ingresso. Ciò non è sufficiente per gli scopi del presente lavoro, che richiederebbero una gestione della priorità anche per i pacchetti in ingresso. Nel seguito dunque verranno introdotti due strumenti che consentono di ottenere questo risultato, dei quali il primo è immediatamente disponibile, mentre il secondo, il cui sviluppo è stato avviato nel corso del presente Dottorato ed è attualmente in fase di test, sarà disponibile a breve. Per ulteriori approfondimenti sulle sofisticate possibilità offerte dal Controllo del Traffico sotto Linux sono presenti molti documenti in rete ed alcuni riferimenti in bibliografia [66], [67].