Nuovo protocollo per BitTorrent, supporto al throttling

[elevul]

Originariamente inviato da II ARROWS

Esatto Gainder, proprio quello che stavo pensando io...

Secondo me dovrebbero pensare delle idee del tipo inviare alcune parti in broadcasting... in modo che se 100 utenti devono scaricare una stessa parte, io la mando in broadcast a tutti questi spendendo solo 10kB/s in upload ma in download diventa 1 000 kB/s.

Aka usare tutti l'IPV6. Ottima idea, Arrows!
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica.

[ice_v]

Originariamente inviato da Superboy

Cavolo la tua Adsl va più forte della mia rete locale

...ma LOL

[Perseverance]

Originariamente inviato da elevul

Aka usare tutti l'IPV6. Ottima idea, Arrows!
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica.

Domanda. Perché implementare ipv6? Quali vantaggi darebbe?

[Severnaya]

da piccolo giocavo a throttling throttling cavallino

[fraussantin]

Originariamente inviato da elevul Guarda i messaggi
Aka usare tutti l'IPV6. Ottima idea, Arrows!
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica.

Originariamente inviato da Perseverance

Domanda. Perché implementare ipv6? Quali vantaggi darebbe?

quoto perche ipv6?? che centra?? non serve per aumentare il numero di ip che sis sta esaurendo??

[ciccio er meglio]

Originariamente inviato da fraussantin

quoto perche ipv6?? che centra?? non serve per aumentare il numero di ip che sis sta esaurendo??

non solo, migliora il routing con una migliore gestione del qos. Ha anche altre funzioni per la criptazione dei dati...però neanche io ho capito che vantaggi puo avere con bittorrent. COme fa a inviare i dati in broadcast? i route interrompono il dominio di broadcast, al massimo FORSE potrebbe usare il multicast...

[nudo_conlemani_inTasca]

Originariamente inviato da g.luca86x

Il traffico torrent può creare problemi di occupazione della banda nel resto del pianeta ma non in Italia. Stando alle statistiche di speedtest.net siamo tra gli ultimi in europa e nel mondo civilizzato per banda disponibile in upload, 83° con 44kb/s in upload (in upload siamo 44°). Perciò ben vengano queste tecnologie che ottimizzano la congestione del traffico sulla rete, sperando ci sia la rete. E dire che ho una 8 mega che viaggia sempre, anche nel cuore della notte a 6,56 Mb/s in down ma in upload non supero i 55kb/s. E mi ritengo ultra abitando a Torino... quando sto in Calabria dai miei invece è una pena perchè tele2 (leggi vodafone) castra pesantemente il traffico torrent... Sarebbe meglio trovare un modo di offuscare completamente il protocollo...

E ti lamenti?
E io che devo navigare col cellulare.. sulla carta vanno più veloci della ADSL cablata terrestere.. nella realtà manco 1MBit/s! (se non salta direttamente in UMTS.. e ciao ciao)

Spiegatemi una cosa, visto che esistono 50 clients torrent differenti (se non di più) con diverse funzionalità, tra cui DHT;
come facciamo a sapere da quale versione e quali clients supporteranno questa nuova funzionalità del protocollo UTP???

Io uso abitualmente 3 Clients torrent (e sono quelli che ad oggi mi hanno dato maggiori soddisfazioni) su Win ovviamente.

In ordine di merito: µTorrent 2.10, BitSpirit 3.60 (che ha la patch integrata per portare le porte halfopen @256) e BitTirant (che però usa il Frame 2.0).

Come leggerezza µTorrent (200KB), consumo risorse esiguo e velocità rimane imbattibile a mio avviso,
poi nella scheda avanzate (advanced) è possibile migliorare i parametri interni del client P2P e farlo correre ancora di più (sono disponibili su youtube) basta cercare

Come si fa a sapere se i clients più utilizzati adotteranno questa nuova funzionalità?

[cionci]

Originariamente inviato da sna696

ma nel protocollo TCP/IP c'è già il controllo sulla congestione... O_O

No, il TCP ce l'ha. Per TCP/IP si intendono tutti i protocolli che si appoggiano ad IP, quindi si intende tutto lo stack di internet.

Originariamente inviato da marcurs

Capito...
Mi pare che esista già qualcosa del genere rimanendo a livello di rete senza coinvolgere il protocollo bittorrent, mi pare si chiami DCCP, che integra un meccanismo di congestion control, è connection oriented come il tcp (3-way handshake per l'istaurazione e il teardown), e con header corto e semplice per essere veloce come l'UDP... ma non so quanto sia diffuso (è un protocollo abbastanza nuovo, l'rcf dice 2006) ad oggi!

Ma non serve, nel senso che probabilmente in BitTorrent non volevano aggiungere un altro livello di incapsulamento, volevano solo modificare il proprio protocollo, i cui pacchetti vengono incapsulati in UDP.

Originariamente inviato da elevul

Mah, dal mio modestissimo punto di vista prima di mettersi ad abbassare le velocità avrebbero dovuto provare ad applicare l'idea del p4p, e cioé una geo-localizzazione dei peer e, quindi, una diminuzione della distanza e dei nodi per cui il pacchetto deve passare, riducendo appunto anche la congestione.

Originariamente inviato da ciccio er meglio

non solo, migliora il routing con una migliore gestione del qos. Ha anche altre funzioni per la criptazione dei dati...però neanche io ho capito che vantaggi puo avere con bittorrent. COme fa a inviare i dati in broadcast? i route interrompono il dominio di broadcast, al massimo FORSE potrebbe usare il multicast...

Il problema principale in questo caso è la congestione causata sul provider congestionato dalla quantità di pacchetti inviata dal client in upload. Il client BitTorrent tentava di saturare la connessione in upload. Questa saturazione provoca però necessità di scartare pacchetti sul router.
I buffer dei router si basano sul concetto di leaky bucket. Immaginiamoci il buffer come un secchio forato sul fondo, il flusso che esce dal fondo sono i dati che il router riesce a gestire.
Se il secchio si piena i dati cominciano a venire scartati tutti, se il secchio si sta pienando si usano algoritmi di congestion avoidance per scartare intelligentemente i pacchetti in modo da indurre i client ad abbassare il rate di invio dei pacchetti.
Il TCP supporta il congestion control e quindi reagisce in modo prevedibile, il traffico UDP può invece non reagire in modo prevedibile se nel protocollo incapsulato su UDP non c'è il controllo di congestione. Questi client continueranno quindi ad inviare pacchetti al rate massimo dell'upload, andando a peggiorare la situazione del buffer del router, ma, non solo, andranno anche ad interagire su tutte le altre sessioni TCP o UDP del router provocandone il throttling.
Ed è proprio per questo che i provider hanno aggiunto il traffic shaping. Limitano il traffico identificando in qualche modo il flusso dati (o direttamente il traffico UDP) ad una certa percentuale della connessione di uscita. In questo modo ogni flusso o tipologia di flusso ha un proprio leaky bucket con dimensione e rate limitati. Quindi diventa chiaro che la maggior parte del traffico che verrà scartato sarà quello del P2P.

Riguardo all'IP multicast, purtroppo la gestione delle classi multicast è troppo particolare per essere instaurata automaticamente a livello mondiale. Esistono però altri protocolli che tentano di sopperire a questa mancanza, ad esempio RTP, anche se viene più spesso usato in unicast.

[ATi7500]

Originariamente inviato da JackZR

In Giappone vanno a 160Mbps a 44€ al mese...

non c'e' bisogno di andare in estremo oriente, anche qui a Budapest ci sono quelle velocita' a quei prezzi..

io ho una 15Mbit/1.5Mbit a circa 16 euro al mese (pagati pure dalla compagnia dove lavoro )

[g.luca86x]

vi invito davvero a visionare le statistiche di speedtest.net per avere davvero i dati di velocità su tutto il pianeta e capirete come la 7° economia mondiale possa essere 83° per velocità delle linee...

[cionci]

Originariamente inviato da g.luca86x

vi invito davvero a visionare le statistiche di speedtest.net per avere davvero i dati di velocità su tutto il pianeta e capirete come la 7° economia mondiale possa essere 83° per velocità delle linee...

Il problema nostro non è la banda concessa dai provider. Il nostro problema è la non capillarità delle centrali e l'antiquatezza degli impianti dell'ultimo miglio. Sono tutti problemi che costringono ad usare la metà ed a volte anche un terzo della banda che concederebbe il provider.
C'è troppa gente che dista oltre 3 km dalla centrale o che pur essendo molto più vicina è costretta a non poter raggiungere la portante massima perché ci sono problemi sulla rete di distribuzione (ad esempio giunti fatti male o giunti che raccolgono i segnali AM).

[Stefano Villa]

Ma sono io l'unico che 24\24 riesce a saturare sempre la banda in download senza alcun problema ???
Mahhhh !!! Certo che finchè la gente continua ad usare i router che danno in prestito gli ISP stiamo freschi !!!

[ciccio er meglio]

Originariamente inviato da cionci

No, il TCP ce l'ha. Per TCP/IP si intendono tutti i protocolli che si appoggiano ad IP, quindi si intende tutto lo stack di internet.

Ma non serve, nel senso che probabilmente in BitTorrent non volevano aggiungere un altro livello di incapsulamento, volevano solo modificare il proprio protocollo, i cui pacchetti vengono incapsulati in UDP.


Il problema principale in questo caso è la congestione causata sul provider congestionato dalla quantità di pacchetti inviata dal client in upload. Il client BitTorrent tentava di saturare la connessione in upload. Questa saturazione provoca però necessità di scartare pacchetti sul router.
I buffer dei router si basano sul concetto di leaky bucket. Immaginiamoci il buffer come un secchio forato sul fondo, il flusso che esce dal fondo sono i dati che il router riesce a gestire.
Se il secchio si piena i dati cominciano a venire scartati tutti, se il secchio si sta pienando si usano algoritmi di congestion avoidance per scartare intelligentemente i pacchetti in modo da indurre i client ad abbassare il rate di invio dei pacchetti.
Il TCP supporta il congestion control e quindi reagisce in modo prevedibile, il traffico UDP può invece non reagire in modo prevedibile se nel protocollo incapsulato su UDP non c'è il controllo di congestione. Questi client continueranno quindi ad inviare pacchetti al rate massimo dell'upload, andando a peggiorare la situazione del buffer del router, ma, non solo, andranno anche ad interagire su tutte le altre sessioni TCP o UDP del router provocandone il throttling.
Ed è proprio per questo che i provider hanno aggiunto il traffic shaping. Limitano il traffico identificando in qualche modo il flusso dati (o direttamente il traffico UDP) ad una certa percentuale della connessione di uscita. In questo modo ogni flusso o tipologia di flusso ha un proprio leaky bucket con dimensione e rate limitati. Quindi diventa chiaro che la maggior parte del traffico che verrà scartato sarà quello del P2P.

Riguardo all'IP multicast, purtroppo la gestione delle classi multicast è troppo particolare per essere instaurata automaticamente a livello mondiale. Esistono però altri protocolli che tentano di sopperire a questa mancanza, ad esempio RTP, anche se viene più spesso usato in unicast.

visto che udp non fa alcun controllo di flusso e va a creare questi problemi perchè non usano tcp? Se non ricordo male il problema del tcp era la maggiore lentezza a causa del fatto che prima di inviare i dati si deve instaurare una connessione tra trasmettitore e ricevitore. Inoltre il tcp usa gli acknoledgement e quindi è tendenzialmente piu lento dell'udp. Però se non ricordo male TCP tende a incrementare la finestra di trasmissione e ricezione (aumentando la finestra di trasmissione e ricezione si arriverà ad un momento in cui non ci sarà attesa per l'ack e si avrà trasmissione continua)gradualmente quindi a lungo andare si comporta come l'udp con il vantaggio di poter controllare la congestione

[ciccio er meglio]

Originariamente inviato da Stefano Villa

Ma sono io l'unico che 24\24 riesce a saturare sempre la banda in download senza alcun problema ???
Mahhhh !!! Certo che finchè la gente continua ad usare i router che danno in prestito gli ISP stiamo freschi !!!

ma quanto caxxo scarichi?

io ho gli hdd saturi

[Stefano Villa]

Magari non 24 ore consecutive, anche se a volte è capitato.... ma a qualsiasi ora inizio ci voglio quei 5 minuti per andare a regime e poi non si scosta mai dal 90% della banda disponibile.... e fino a quando avevo il router di alice queste velocità me le potevo solo sognare !!!

[cionci]

Originariamente inviato da ciccio er meglio

visto che udp non fa alcun controllo di flusso e va a creare questi problemi perchè non usano tcp? Se non ricordo male il problema del tcp era la maggiore lentezza a causa del fatto che prima di inviare i dati si deve instaurare una connessione tra trasmettitore e ricevitore. Inoltre il tcp usa gli acknoledgement e quindi è tendenzialmente piu lento dell'udp. Però se non ricordo male TCP tende a incrementare la finestra di trasmissione e ricezione (aumentando la finestra di trasmissione e ricezione si arriverà ad un momento in cui non ci sarà attesa per l'ack e si avrà trasmissione continua)gradualmente quindi a lungo andare si comporta come l'udp con il vantaggio di poter controllare la congestione

Perché gestire un peer che invia tanti messaggi a tanti altri peer è troppo complesso con TCP. Senza contare che, pur se l'overhead per un singola sessione TCP è piccolo, per una moltitudine di connessioni TCP è molto alto.
Le primitive messe a disposizione per UDP sono semplicissime: sendto e recvfrom e lavorano direttamente sugli indirizzi ip.
UDP permette quindi di personalizzare al massimo il protocollo, ecco perché viene usato in praticamente tutti i protocolli P2P.

[ciccio er meglio]

ma quindi anche il controllo di errore viene fatto a livelli piu alti?

[cionci]

Originariamente inviato da ciccio er meglio

ma quindi anche il controllo di errore viene fatto a livelli piu alti?

Viene fatto il controllo di errore sul protocollo BitTorrent ?
Il controllo di errore che io sappia nel BitTorrent viene fatto a livello di chunks e non a livello di pacchetto. Quindi se una volta che il chunk viene completato il fingerprint è errato, il chunk viene eliminato e richiesto nuovamente ai peer.
Quindi nel protocollo non solo non c'è la correzione dell'errore, ma nemmeno la possibilità di verificare la presenza di un errore.

UDP ha un checksum, addirittura credo che possa venire ignorato (trasmettendo tutti 1) oppure semplicemente viene riportato un errore del checksum al ricevente. Il problema è che il ricevente, a meno che non abbia una singola sessione UDP aperta, non può affidarsi al pacchetto con checksum errato per determinare l'indirizzo ip dal quale proviene il pacchetto, infatti il checksum è calcolato sul pacchetto UDP e su parte dell'header IP (compresi gli indirizzi). Quindi anche l'indirizzo IP potrebbe essere errato

Il nuovo sistema di controllo di congestione sembra che si affidi ad un semplice timestamp per la stima del round trip time. Imho ci saranno due campi in più nel protocollo BitTorrent, un bit da mettere ad 1 che attiva uTP ed un campo opzionale in cui andare ad inserire il timestamp del mittente.
Il ricevente quando trova il campo uTP ad 1 prende il timestamp e lo invia nuovamente al peer che lo aveva generato. In questo modo si riesce a stimare il tempo che ci impiega il pacchetto per andare ad un peer e tornare indietro. Ovviamente c'è congestione se questo tempo aumenta troppo o se la risposta non ritorna (entro un opportuno timeout proporzionale al RTT stimato precedentemente).

[Perseverance]

OK ho capito ma ricapitolando; la congenstione del traffico provoca la perdita dei pacchetti che devono essere inviati reiterate volte sul protocollo UDP, il quale non prevede nessun meccanismo anti-traboccamento. Il nuovo protocollo uTP permetterebbe di inviare intelligentemente i pacchetti agli utenti non saturi e limitare il reinvio agli utenti saturi.

Grazie a questo cosa migliorera?

La velocità di download dipende dalla velocità di upload dell'altro utente, quindi al massimo si scaricherà come ora. Xò il fatto di inviare i pacchetti alle persone giuste permette di incrementare le prestazioni solo nel caso di congestione. Questo protocollo infine non è per aumentare la velocità di download\upload in generale, ma specificamente nel caso in cui ci sia una congestione.

Staremo a vedere...

[JackZR]

Originariamente inviato da II ARROWS

Secondo me dovrebbero pensare delle idee del tipo inviare alcune parti in broadcasting... in modo che se 100 utenti devono scaricare una stessa parte, io la mando in broadcast a tutti questi spendendo solo 10kB/s in upload ma in download diventa 1 000 kB/s.

Indubbiamente andare in Multicast sarebbe molto più comodo per tutti, magari un giorno...

Originariamente inviato da elevul

Aka usare tutti l'IPV6. Ottima idea, Arrows!
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica.

Ma penso che ci stiano già lavorando visto che presto (2011) si comincerà ad usarlo e non troppo più tardi (2025) l' IPv4 morirà...

Originariamente inviato da cionci

Il problema nostro non è la banda concessa dai provider. Il nostro problema è la non capillarità delle centrali e l'antiquatezza degli impianti dell'ultimo miglio. Sono tutti problemi che costringono ad usare la metà ed a volte anche un terzo della banda che concederebbe il provider.
C'è troppa gente che dista oltre 3 km dalla centrale o che pur essendo molto più vicina è costretta a non poter raggiungere la portante massima perché ci sono problemi sulla rete di distribuzione (ad esempio giunti fatti male o giunti che raccolgono i segnali AM).

Abito a neanche 500m in linea d'aria dalla centrale e godo solo di 13 mega su 20 che ne pago