Lo scenario odierno di Internet

Per comprendere a pieno la necessità di migrare verso reti di tipo DTN (di cui ho parlato nell’articolo «Un’introduzione alle reti DTN») è necessario avere una panoramica più o meno dettagliata di cosa oggi sia la comunicazione a mezzo Internet.

Assunzione molto forte e intrinseca all’architettura di Internet è che per scambiare messaggi fra due o più terminali è necessario che vi sia un collegamento continuo di tipo end-to-end fra sorgente e destinatario, caratterizzato da trasmissione a basso ritardo e da un basso tasso di errore.

Il protocollo TCP, descritto prima nel RFC 793 poi esteso in RFC 1122 e RFC 3168, effettua l’inizializzazione della connessione fra due nodi tramite una procedura denominata three-way handshake (stretta di mano a tre vie), ovvero lo scambio di tre messaggi fra il Client (il terminale che intende aprire una connessione) e il Server (il terminale di destinazione). Se tale procedura si conclude senza errori, una nuova connessione fra i due punti della rete viene instaurata e i due terminali possono scambiarsi dati.

Durante la trasmissione dei dati, per ciascun segmento inviato, il protocollo TCP avvia un timer, detto timer di ritrasmissione RTO (Retransmission Time Out), scaduto il quale se il terminale che ha inviato il pacchetto non riceve la conferma di avvenuta ricezione da parte del destinatario, attraverso il corrispondente ACK (Acknowledgment number), il protocollo assume che il segmento trasmesso sia andato perso e quindi lo ritrasmette. Come descritto nel RFC 2988, RTO deve essere raddoppiato (exponential backoff) ad ogni re-invio fino (eventualmente) al raggiungimento di un valore massimo. Allo scadere di un intervallo prefissato (oppure, come in Linux, dopo un numero massimo di ritrasmissioni) in assenza di conferma, il mittente chiude la connessione in corso. La medesima procedura si applica con soglie diverse durante il three-way handshake, ove la prolungata assenza di conferme impedisce l’apertura della stessa connessione.

In entrambi i casi è evidente che il protocollo TCP, progettato per essere robusto alla perdita di pacchetti dovuta a congestione sulla rete, è in grado con i medesimi meccanismi di far fronte a momentane e brevi assenze di collegamento, ma presenta serie difficoltà a fronte di interruzioni lunghe o, addirittura, non è in grado di instaurare il collegamento in assenza di un canale end-to-end, come può verificarsi nell’Internet interplanetaria o in alcune reti di sensori.