Fast TCP, la nuova promessa di Internet?

Un articolo rivela nuovi dettagli su Fast TCP, uno dei protocolli su cui potrebbe poggiare l'Internet del futuro, una rete dove il contenuto di un DVD potrà essere trasmesso nel giro di pochi secondi

Pasadena (USA) - "Immaginate una connessione ad Internet così veloce da permettervi di scaricare un intero film nel giro di pochi secondi". Questo l'incipit di un recente articolo apparso sulla rivista New Scientist e riguardante Fast TCP, nuova versione di uno dei protocolli storici su cui poggia Internet.

Il compito del TCP (Transmission Control Protocol) è quello di verificare che i dati trasmessi arrivino a destinazione senza errori e nel giusto ordine attraverso un meccanismo basato su ricevute di ritorno e ritrasmissione. Fast TCP, il cui sviluppo viene portato avanti da un gruppo di ricercatori del California Institute of Technology di Pasadena, apporta diverse modifiche a questo meccanismo così da minimizzare le attese e le ritrasmissioni.

I ricercatori californiani hanno spiegato che il nuovo protocollo, di cui pochi mesi fa è stato fatto un primo test pratico, è in grado, grazie al supporto del software e dell'hardware, di misurare in continuazione il tempo impiegato dai pacchetti per arrivare a destinazione e il tempo impiegato dalle ricevute per tornare indietro.
"Questo - scrive il New Scientist - rivela i ritardi sulla linea avvertendo in anticipo di eventuali pacchetti persi. Il software Fast TCP utilizza questo per predire il massimo data rate che la connessione può supportare senza perdere dati".

In sostanza, dunque, Fast TCP promette di ottimizzare la trasmissione dei dati e sfruttare più a fondo la banda passante di ogni tipo di connessione. Una delle caratteristiche chiave di questo protocollo è infatti proprio quella di funzionare sulla stessa infrastruttura di rete dell'attuale Internet e utilizzare gli stessi dispositivi e le stesse applicazioni di rete già sul mercato.

Nonostante Fast TCP funzioni benissimo anche con le tradizionali connessioni, il suo utilizzo è stato pensato soprattutto per adeguare l'attuale protocollo TCP alle esigenze delle reti di nuova generazione, le stesse che dovranno presto trasportare milioni di chiamate vocali non compresse su di un singolo percorso o supportare grandi esperimenti scientifici che richiederanno il trasferimento on demand di gigabyte o terabyte di dati.
TAG: ricerca
56 Commenti alla Notizia Fast TCP, la nuova promessa di Internet?
Ordina
  • Alcuni anni fa uscì in Italia l'edizione tradotta di New scientist dal Titolo "Scienza Nuova", fu un'ottima rivista e coniugò informazione non fantascientifica (alla Focus) e non noiosa (tipo alcuni articoli di Le Scienze), tuttavia alcuni mesi dopo fallì.
    Questo esempio rimarca di cultura scientifica degli Italiani è quanto meno scarsa, tuttavia non si hanno scrupoli ad armare un popolo di ignoranti con la potente arma referendaria su un argomento che ha un forte valenza scientifica.
  • internet è nata principalmente come strumento di comunicazione fra centri di ricerca...

    adesso molti credono internet serva soprattutto a scaricare films e canzoni (nonchè pornazziCon la lingua fuori)a manetta, scrivere buoiate sui forum, spedirsi le cazzatine via email etc etc

    e in fondo è innegabile, adesso internet serve anche a questo.


    probabilmente ci vorranno davvero taaaanti anni perchè il comune utonto abbia bisogno di una banda capace di scambiare i giga al secondo... tuttavia la mia domanda/fantasticheria è: quando saranno disponibili all'utonto queste tecnologie, adesso riservate unicamente a centri di ricerca o per lo spostamento on demand di dati?

    si accettano scommesse.


    avvelenato che pensa sarebbe realmente bello possedere una banda infinita.
  • Allora,
    tra tutti gli interventi NON ho ancora visto citato il vero e semplice motivo per cui il TCP ha problemi su reti molto veloci (e con latenza relativamente elevata).

    Per chi e' interessato alla (semplice) spiegazione tecnica, riassumo i termini della questione:

    In sintesi:
    - il TCP usa un meccanismo di congestion-control a finestre;
    - i meccanismi a finestre per riuscire a sfruttare la capacita' teorica del canale devono usare finestre (cioe' buffer, nella implementazione pratica) di dimensioni pari _almeno_ al prodotto banda*RTT della rete;
    - nel caso della rete usata al Caltech, si ha RTT~0.2s, banda~1Gbps;
    - il TCP standard dovrebbe quindi usare un buffer di circa 200Mbit=25Mbyte (!) per riuscire ad usare completamente la capacita' del canale;
    - ovviamente, non e' possibile implementare un buffer di 25Mbyte nello stack TCP/IP di un PC (!!);
    - tipicamente invece il TCP usa finestre di congestione molto piu' piccole (circa 65Kbyte nei PC desktop, fino a circa 1Mbyte nei casi di server ad alte prestazioni configurati ad-hoc).

    Conclusione: il TCP non e' in grado di funzionare efficientemente su di una rete con 200Mbyte di prodotto banda*RTT.

    Funziona invece benissimo su una LAN FastEthernet, perche' in questo caso banda*RTT = 100Mbps*0.001s = 0.1Mbit = 100Kbit = 12.5Kbyte.

    Il FastTCP semplicemente sfrutta un meccanismo di congestion-control di tipo diverso (non a finestre, immagino), che non ha bisogno di buffer enormi per funzionare efficientemente su tale tipo di reti.

    Nota: questa non e' fantascienza, e' banale ed assodato know-how di TLC.

    Ciao
  • una spiegazione forse un po' tecnica per chi come me non è addetto ai lavori, però tutto sommato semplice e concisa. ti ringrazio.Sorride


    avvelenato che pensa certe persone farebbero bene a non postare commenti idioti su argomenti che non riguardano le loro competenze.
  • - Scritto da: avvelenato
    > una spiegazione forse un po' tecnica per chi
    > come me non è addetto ai lavori, però tutto
    > sommato semplice e concisa. ti ringrazio.Sorride

    Mi permetto si semplificare/spiegare l'idea:

    >In sintesi:
    >- il TCP usa un meccanismo di congestion-control a >finestre;

    Immaginati la finestra come una lista della spesa che contiene pacchetti dei quali non siamo sicuri la trsmissione sia andata a buon fine o che sono ancora da trasmettere.
    Ovviamente questa in RAM ed occupa spazio.

    >- i meccanismi a finestre per riuscire a sfruttare la >capacita' teorica del canale devono usare finestre (cioe' >buffer, nella implementazione pratica) di dimensioni pari >_almeno_ al prodotto banda*RTT della rete;

    Che dimensione deve avere questa finestra (quanti pacchetti devono stare im memoria)?
    Ovviamente non ha senso metterne meno di quanti ce ne entrano nella rete. Immagina la rete come un tubo, il suo volume e' dato dall'area della base per la lunghezza. Queste dimensioni in informatica sono dati dalla larghezza di banda (che sarebbe l'area della base, ovvero quanti dati entrano nella largheza del tubo) * il tempo che i dati impiegano ad arrivare a destinazione per 2 (RTT, Round Trip Time). Si moltiplica per 2 perche' si prende il tempo per il dato per andare in la e il tempo per ricevere la ricevuta di buona trasmissione in qua'.

    Va dasse' che piu' banda ha la rete piu' dati devi tenere in memoria.

    >- nel caso della rete usata al Caltech, si ha RTT~0.2s, >banda~1Gbps;
    >- il TCP standard dovrebbe quindi usare un buffer di circa >200Mbit=25Mbyte (!) per riuscire ad usare completamente >la capacita' del canale;

    Dato l'uso di una grete a larga banda la finestra occupa uno sfacelo di RAM. (Considera inoltre che la finestra molte volte sta nello spazio kernel).

    >- ovviamente, non e' possibile implementare un buffer di >25Mbyte nello stack TCP/IP di un PC (!!);

    >- tipicamente invece il TCP usa finestre di congestione >molto piu' piccole (circa 65Kbyte nei PC desktop, fino a >circa 1Mbyte nei casi di server ad alte prestazioni >configurati ad-hoc).

    >Conclusione: il TCP non e' in grado di funzionare >efficientemente su di una rete con 200Mbyte di prodotto >banda*RTT.

    >Funziona invece benissimo su una LAN FastEthernet, >perche' in questo caso banda*RTT = 100Mbps*0.001s = >0.1Mbit = 100Kbit = 12.5Kbyte.

    >Il FastTCP semplicemente sfrutta un meccanismo di >congestion-control di tipo diverso (non a finestre, >immagino), che non ha bisogno di buffer enormi per >funzionare efficientemente su tale tipo di reti.

    >Nota: questa non e' fantascienza, e' banale ed assodato >know-how di TLC.

    >Ciao

    Penso che chiariti quei 2 termini tecnici il resto sia molto piu' chiaro.


    Ciao, Krecker
    non+autenticato
  • > Un articolo rivela nuovi dettagli su Fast TCP, uno dei
    > protocolli su cui potrebbe poggiare l'Internet del futuro, una
    > rete dove il contenuto di un DVD potrà essere trasmesso
    > nel giro di pochi secondi

    davvero? quindi non dipende dalla banda passante, qualunque fesso con un 56k basta che utilizzi tale protocollo e scarica Gbyte su Gbyte in pochi secondi...ma per favore!!!! Ma chi li scrive sti articoli gianni e pinotto?
    non+autenticato
  • - Scritto da: Anonimo
    >> il contenuto di un DVD potrà essere trasmesso
    >> nel giro di pochi secondi
    > davvero? quindi non dipende dalla banda
    > passante, qualunque fesso con un 56k basta
    > che utilizzi tale protocollo e scarica Gbyte
    > su Gbyte in pochi secondi...ma per
    > favore!!!! Ma chi li scrive sti articoli
    > gianni e pinotto?
    Probabilmente il discorso era focalizzato sul throughput a livello di backbone: se tento l'esperimento con il 56k di casa il primo ostacolo lo incontro sull'ampiezza di banda della seriale Occhiolino))

    E' comunque vero che, anche su un link telefonico "tradizionale", l'ampiezza di banda teorica del mezzo è ben superiore ai 3,5KHz che Telecom garantirebbe (maschera per i 2400baud): dovrebbe arrivare fino ai 100Mbps (tant'è che se ti attivano ADSL a casa NON ti cambiano il cavo del telefono e NON ti portano a casa un cavetto STP, coax o ottico).
    885

  • - Scritto da: Sky
    > Probabilmente il discorso era focalizzato
    > sul throughput a livello di backbone: se
    > tento l'esperimento con il 56k di casa il
    > primo ostacolo lo incontro sull'ampiezza di
    > banda della seriale Occhiolino))

    si ma messo come e' nel articolo sembra che per magia cambiare protocollo ti aumenti la banda passante (al limite ti permette di ottimizzarne l'uso)

    > E' comunque vero che, anche su un link
    > telefonico "tradizionale", l'ampiezza di
    > banda teorica del mezzo è ben superiore ai
    > 3,5KHz che Telecom garantirebbe (maschera
    > per i 2400baud): dovrebbe arrivare fino ai
    > 100Mbps (tant'è che se ti attivano ADSL a
    > casa NON ti cambiano il cavo del telefono e
    > NON ti portano a casa un cavetto STP, coax o
    > ottico).

    questo perche' il segnale telefonico (che usano anche i modem analogici) si tiene sotto i 3000Khz mentre la banda passante del doppino telefonico e' ben superiore.
    non+autenticato
  • ipsec?
    ipv6?


    tutta questa roba ... si usa o no?
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 10 discussioni)