3. Compression method (Metodo di compressione)
3. Compression method (Metodo di compressione)
Gran parte delle informazioni di intestazione resta invariata per tutta la durata di un flusso di pacchetti. Per i flussi non TCP, quasi tutti i campi di intestazione sono costanti. Per TCP, molti campi sono costanti, mentre altri cambiano con valori piccoli e prevedibili.
Per iniziare a comprimere le intestazioni di un flusso di pacchetti, sul link viene trasmessa un'intestazione completa che trasporta il context identifier CID. Il compressore e il decompressore memorizzano la maggior parte dei campi di questa intestazione completa come contesto. Il contesto e composto dai campi dell'intestazione i cui valori sono costanti, e quindi non devono essere inviati affatto sul link, oppure cambiano cosi poco tra intestazioni consecutive che inviare la differenza rispetto al valore precedente richiede meno bit rispetto all'invio del valore assoluto.
Qualsiasi modifica in un campo che ci si aspetta resti costante nel flusso di pacchetti fara si che il compressore invii nuovamente un'intestazione completa per aggiornare il contesto presso il decompressore. Finche i contesti del compressore e del decompressore sono identici, un'intestazione puo essere decompressa esattamente nella forma che aveva prima della compressione. Tuttavia, se durante la trasmissione viene persa un'intestazione completa o compressa, il contesto del decompressore puo diventare obsoleto perche non e stato aggiornato correttamente. Le intestazioni compresse verranno quindi decompresse in modo errato.
IPv6 non e pensato per link che possono consegnare al modulo IPv6 grandi quantita di pacchetti danneggiati. Questo significa che il link deve avere un tasso di errore sui bit molto basso, oppure che i frame del livello di collegamento devono essere protetti da un checksum forte, da forward error correction o da protezioni analoghe. La compressione delle intestazioni non dovrebbe essere usata per IPv4 senza un checksum forte a livello di collegamento. I frame danneggiati saranno quindi scartati dal livello di collegamento. L'implementazione del livello di collegamento puo indicare al modulo di compressione delle intestazioni che un frame e danneggiato, ma non puo indicare a quale flusso di pacchetti appartenga, perche il CID potrebbe essere la parte danneggiata. Inoltre, un frame puo scomparire senza che l'implementazione del livello di collegamento lo sappia, ad esempio se il link e multi-hop e i frame possono essere scartati a causa della congestione in ciascun hop. Di conseguenza, il tipo di errore di link che il modulo di compressione delle intestazioni dovrebbe gestire e prevenire e la perdita di pacchetti.
Lo schema di compressione delle intestazioni richiede quindi meccanismi per aggiornare il contesto presso il decompressore e per rilevare o evitare una decompressione errata. Questi meccanismi sono molto diversi per i flussi TCP e non TCP, e sono descritti nelle Sezioni 3.2 e 3.3.
I meccanismi di compressione descritti in questo documento assumono che i pacchetti non vengano riordinati tra compressore e decompressore. Se il link puo riordinare i pacchetti, la Sezione 11 descrive un meccanismo per ordinarli prima della decompressione. Si assume inoltre che l'implementazione del livello di collegamento possa fornire la lunghezza del pacchetto e che i pacchetti UDP o incapsulati in tunnel non contengano padding.
3.1 Packet types (Tipi di pacchetto)
Oltre ai tipi di pacchetto IPv4 e IPv6, questo metodo di compressione usa quattro tipi di pacchetto. La combinazione tra il tipo di pacchetto del livello di collegamento e il valore dei primi quattro bit del pacchetto identifica in modo univoco il tipo di pacchetto. I dettagli sulla rappresentazione di questi tipi di pacchetto sono nella Sezione 13.
FULL_HEADER - Indica un pacchetto con intestazione non compressa, incluso il CID e, se non e un pacchetto TCP, la generazione. Stabilisce o rinfresca il contesto del flusso di pacchetti identificato dal CID.
COMPRESSED_NON_TCP - Indica un pacchetto non TCP con intestazione compressa. L'intestazione compressa e composta dal CID che identifica il contesto usato per la decompressione, dalla generazione usata per rilevare contesti incoerenti e dai campi dell'intestazione che cambiano in modo casuale.
COMPRESSED_TCP - Indica un pacchetto con intestazione TCP compressa, contenente il CID, un ottetto di flag che identifica i campi modificati e i campi modificati codificati come differenza rispetto al valore precedente.
COMPRESSED_TCP_NODELTA - Indica un pacchetto con intestazione TCP compressa in cui tutti i campi normalmente inviati come differenza rispetto al valore precedente sono invece inviati cosi come sono. Questo tipo di pacchetto viene inviato solo come risposta a una richiesta di intestazione proveniente dal decompressore. Non puo essere inviato come risultato di una ritrasmissione.
Oltre ai tipi di pacchetto usati per la compressione, vengono usati pacchetti IPv4 e IPv6 regolari ogni volta che il compressore decide di non comprimere un pacchetto. Possono essere usati tipi di pacchetto aggiuntivi per accelerare la riparazione dei flussi TCP sul link quando il decompressore puo inviare pacchetti al compressore.
CONTEXT_STATE - Indica un pacchetto speciale inviato dal decompressore al compressore per comunicare un elenco di CID (TCP) che hanno perso la sincronizzazione. Questo pacchetto viene inviato solo su un singolo link e quindi non richiede un'intestazione IP. Il formato e mostrato nella Sezione 10.2.
3.2 Lost packets in TCP packet streams (Pacchetti persi nei flussi TCP)
Poiche le intestazioni TCP sono compresse usando differenze rispetto all'intestazione TCP precedente, la perdita di un pacchetto con intestazione compressa o completa fara si che le intestazioni compresse successive vengano decompresse in modo errato, perche il contesto usato per la decompressione non e stato incrementato correttamente.
La perdita di un'intestazione TCP compressa fara si che il numero di sequenza TCP nelle intestazioni TCP decompresse successivamente sia spostato di k, dove k e la dimensione del segmento perso. Tali intestazioni TCP decompresse in modo errato saranno scartate dal ricevitore TCP, perche il checksum TCP cattura in modo affidabile, per valori ragionevoli di k, l'errore "spostato di k" nel numero di sequenza.
Il meccanismo di riparazione di TCP alla fine ritrasmettera il segmento scartato e il compressore osserva le intestazioni TCP per rilevare quando TCP effettua una ritrasmissione. Quando questo accade, il compressore invia un'intestazione completa, assumendo che la ritrasmissione sia dovuta a uno stato di compressione non corrispondente presso il decompressore. [RFC-1144] spiega bene questo meccanismo.
I meccanismi della Sezione 10 dovrebbero essere usati per accelerare la riparazione del contesto. Questo e importante per link a media velocita con alto tasso di perdita dei pacchetti, ad esempio wireless. Non e accettabile perdere pacchetti per un intero valore di timeout a causa di contesti incoerenti dopo ogni perdita di pacchetto sul link, specialmente quando la connessione TCP attraversa una rete geografica.
3.3 Lost packets in UDP and other non-TCP packet streams (Pacchetti persi nei flussi UDP e non TCP)
Le intestazioni di pacchetti UDP decompresse in modo errato e le intestazioni di altri pacchetti non TCP non sono protette dal checksum quanto i pacchetti TCP. Non esiste un numero di sequenza che diventi "spostato di k" e causi quasi certamente il fallimento del checksum, come accade con TCP. Il checksum UDP copre solo il payload, l'intestazione UDP e la pseudo-intestazione. La pseudo-intestazione include gli indirizzi sorgente e destinazione, il tipo di protocollo di trasporto e la lunghezza del pacchetto di trasporto. A parte questi campi, gran parte dell'intestazione IPv6 non e coperta dal checksum UDP. Inoltre, altre intestazioni non TCP, ad esempio quelle di frammentazione, sono completamente prive di checksum.
Per evitare in modo sicuro la decompressione errata delle intestazioni non TCP, ogni versione del contesto di un flusso di pacchetti non TCP e identificata da una generazione, un piccolo numero trasportato dalle intestazioni complete che stabiliscono e rinfrescano il contesto. Le intestazioni compresse trasportano il valore di generazione del contesto con cui sono state compresse. Quando il decompressore vede che il valore di generazione trasportato da un'intestazione compressa non coincide con la generazione del proprio contesto per quel flusso di pacchetti, il contesto non e aggiornato e il pacchetto deve essere scartato o memorizzato finche un'intestazione completa non stabilisce il contesto corretto.
La codifica differenziale non viene usata per i flussi non TCP, quindi le intestazioni non TCP compresse non modificano il contesto. Di conseguenza, la perdita di un'intestazione compressa non invalida i pacchetti successivi con intestazioni compresse. Inoltre, la generazione cambia solo quando il contesto dell'intestazione completa differisce dal contesto dell'intestazione completa precedente. Questo significa che la perdita di un'intestazione completa rende obsoleto il contesto del decompressore solo se l'intestazione completa avrebbe effettivamente modificato il contesto.
Il campo generation e lungo 6 bit, quindi i valori di generazione si ripetono dopo 64 modifiche del contesto. Per evitare una decompressione errata dopo una raffica di errori o un'altra interruzione temporanea, il compressore non puo riutilizzare lo stesso valore di generazione prima che siano trascorsi MIN_WRAP secondi. Un decompressore disconnesso per MIN_WRAP secondi o piu deve attendere la prossima intestazione completa prima di decomprimere. Il compressore deve attendere almeno MIN_WRAP secondi dopo l'avvio prima di comprimere intestazioni non TCP. Invece di riutilizzare prematuramente valori di generazione, il compressore puo passare a un altro CID o inviare intestazioni regolari finche non sono trascorsi MIN_WRAP secondi. Il valore di MIN_WRAP si trova nella Sezione 14.
3.3.1 Compression Slow-Start (Slow-start della compressione)
Per consentire al decompressore di recuperare rapidamente dalla perdita di un'intestazione completa che modifica il contesto, dopo una modifica del contesto vengono inviate periodicamente intestazioni complete con intervalli a crescita esponenziale. Questa tecnica evita lo scambio di messaggi tra compressore e decompressore usato da altri schemi di compressione, ad esempio in [RFC-1553]. Tale scambio puo essere costoso per dispositivi mobili wireless, perche il trasmettitore consuma piu energia e il passaggio tra trasmissione e ricezione puo introdurre ritardi. Inoltre, le tecniche che richiedono scambio di messaggi non possono essere usate su link simplex, ad esempio canali satellitari broadcast diretti o sistemi televisivi via cavo, e sono difficili da adattare al multicast su link multiaccesso.
|.|..|....|........|................|..............................
^
Change Sent packets: | with full header, . with compressed header
La figura mostra come vengono inviati i pacchetti dopo una modifica. Il compressore mantiene per ogni flusso di pacchetti non TCP una variabile F_PERIOD, che tiene traccia di quante intestazioni compresse possono essere inviate tra due intestazioni complete. Quando l'intestazione di un flusso di pacchetti non TCP cambia al punto da modificarne il contesto, viene inviata un'intestazione completa e F_PERIOD viene impostato a 1. Dopo l'invio di F_PERIOD intestazioni compresse, viene inviata un'intestazione completa. Durante lo slow-start della compressione, ogni volta che viene inviata un'intestazione completa F_PERIOD raddoppia.
3.3.2 Periodic Header Refreshes (Refresh periodici delle intestazioni)
Per evitare di perdere troppi pacchetti quando il ricevitore perde il proprio contesto, esiste un limite superiore F_MAX_PERIOD al numero di pacchetti non TCP con intestazione compressa che possono essere inviati tra due refresh dell'intestazione. Se deve essere inviato un pacchetto e, dall'ultima intestazione completa inviata per quel flusso, sono gia state inviate F_MAX_PERIOD intestazioni compresse, deve essere inviata un'intestazione completa.
Per evitare lunghe disconnessioni nei flussi a basso bitrate, esiste anche un limite superiore F_MAX_TIME al tempo tra intestazioni complete in un flusso di pacchetti non TCP. Se deve essere inviato un pacchetto e dall'ultima intestazione completa inviata per quel flusso sono trascorsi piu di F_MAX_TIME secondi, deve essere inviata un'intestazione completa. I valori di F_MAX_PERIOD e F_MAX_TIME si trovano nella Sezione 14.
3.3.3 Rules for sending Full Headers (Regole per l'invio di intestazioni complete)
Il compressore puo usare il seguente pseudocodice per determinare quando inviare un'intestazione completa per un flusso di pacchetti non TCP. Il codice mantiene due variabili:
C_NUM -- conteggio delle intestazioni compresse inviate dall'ultima intestazione completa.
F_LAST -- momento in cui e stata inviata l'ultima intestazione completa.
e usa le funzioni
current_time() restituisce il tempo corrente
min(a,b) restituisce il minore tra a e b
Le procedure send_full_header(), increment_generation_value() e send_compressed_header() eseguono le operazioni ovvie.
if ( <questa intestazione cambia il contesto> )
C_NUM := 0;
F_LAST := current_time();
F_PERIOD := 1;
increment_generation_value();
send_full_header();
elseif ( C_NUM >= F_PERIOD )
C_NUM := 0;
F_LAST := current_time();
F_PERIOD := min(2 * F_PERIOD, F_MAX_PERIOD);
send_full_header();
elseif ( current_time() > F_LAST + F_MAX_TIME )
C_NUM := 0;
F_LAST := current_time();
send_full_header();
else
C_NUM := C_NUM + 1
send_compressed_header();
endif
3.3.4 Cost of sending Header Refreshes (Costo dell'invio dei refresh dell'intestazione)
Se ogni f-esimo pacchetto trasporta un'intestazione completa, H e la dimensione dell'intestazione completa e C e la dimensione dell'intestazione compressa, la dimensione media dell'intestazione e:
(H-C)/f + C
Per f > 1, la dimensione media dell'intestazione e maggiore dell'intestazione compressa di (H-C)/f.
In un grafico della dimensione media dell'intestazione per vari valori di f, la curva presenta un chiaro punto di flesso: esiste cioe un limite oltre il quale aumentare ulteriormente f produce rendimenti decrescenti. F_MAX_PERIOD dovrebbe essere scelto come frequenza a destra del punto di flesso della curva. Per dimensioni tipiche di H e C, ad esempio 48 ottetti per un'intestazione completa (IPv6/UDP) e 4 ottetti per un'intestazione compressa, impostare F_MAX_PERIOD > 44 significa che le intestazioni complete contribuiscono alla dimensione media dell'intestazione per meno di un ottetto. Con una Routing header a quattro indirizzi, F_MAX_PERIOD > 115 ha lo stesso effetto.
Il valore predefinito di F_MAX_PERIOD, 256 (Sezione 14), colloca la frequenza delle intestazioni complete a destra del punto di flesso e implica che, in genere, le intestazioni complete contribuiscono alla dimensione media dell'intestazione per molto meno di un ottetto. Per H = 48 e C = 4, dopo il raggiungimento della frequenza di refresh a regime determinata dal valore predefinito di F_MAX_PERIOD, l'intestazione completa contribuisce alla dimensione media dell'intestazione per circa 1.4 bit. 1.4 bit e un overhead molto piccolo.
Dopo una modifica del contesto, lo schema di backoff esponenziale invia inizialmente intestazioni complete con frequenza elevata. Il valore predefinito di F_MAX_PERIOD viene raggiunto dopo l'invio di 9 intestazioni complete e 255 intestazioni compresse. Per un tipico flusso vocale con campioni vocali di 20 ms per pacchetto, questo equivale a poco piu di 5 secondi.
Durante l'intero periodo di backoff, con H = 48 e C = 4, le intestazioni complete contribuiscono alla dimensione media dell'intestazione per 1.5 ottetti. Per campioni vocali di 20 ms, servono meno di 1.3 secondi perche il contributo delle intestazioni complete scenda sotto un ottetto; durante questi 1.3 secondi iniziali, le intestazioni complete aggiungono meno di 4 ottetti alla dimensione media dell'intestazione. Il costo del backoff esponenziale non e elevato e, poiche ci si aspetta che le intestazioni dei flussi non TCP cambino raramente, viene ammortizzato su un periodo lungo.
Il costo dei refresh dell'intestazione in termini di banda e superiore a quello di uno schema hard-state simile (come [RFC-1553]), in cui le intestazioni complete devono essere confermate dal decompressore prima di inviare intestazioni compresse. Tali schemi in genere inviano un'intestazione completa piu alcuni messaggi di controllo quando il contesto cambia. Gli schemi hard-state richiedono piu tipi di messaggi di protocollo e richiedono scambio di messaggi. Inoltre, richiedono la gestione esplicita di varie condizioni di errore che il soft-state gestisce automaticamente, ad esempio il caso in cui una delle parti scompaia improvvisamente, evento comune sui link wireless quando un dispositivo mobile esce dalla portata della stazione base.
Il principale vantaggio dello schema soft-state e che non richiede handshake tra compressore e decompressore, quindi puo essere usato su link simplex. Il costo in termini di banda e superiore a quello degli schemi hard-state, ma la semplicita del decompressore, la semplicita del protocollo e l'assenza di handshake tra compressore e decompressore giustificano questo piccolo costo. Inoltre, lo schema soft-state si estende piu facilmente al multicast su link multiaccesso, ad esempio link wireless.