Re: [Ninux-Wireless] fast-olsr
Grande Antonio! Il giorno 27 febbraio 2010 10.43, Antonio Anselmi tony.anse...@gmail.comha scritto: la caduta di chiamate non dipende tanto dalla velocita' con cui ti muovi ma dal conseguente fatto che cambiando il path (la route) devi rinnovare gli handshake TCP con il next hop. Ergo: quanto piu' a lungo la route e' considerata valida (anche se degradata) minore e' il rischio di connessioni TCP abbattute (poprio perche' cambia il gateway). olsrd usa l'algoritmo shortest path first per quanto riguarda il mantenimento dello status di un link (almeno le versioni RFC compliant...). Ora supponiamo che: - al tempo t0 sei collegato al gateway G con un solo hop (te - nodo G) - al tempo t0+n e' *disponibile* una rotta migliore: te - nodo-intermedio - nodo G (2 hop) orbene, olsrd privilegia il link con un solo hop (con ETX povero) a dispetto due hop (ciascuno con ETX migliore). Questo dovrebbe garantire una certa persistenza delle connessioni TCP, perlomeno in presenza di una mobilita' circolare, ovvero ti muovi gironzolando e NON orizzontalmente in fuga. Ma non bisogna esagerare nel tenersi stretta una rotta che - piu' o meno velocemente - sta' degradandosi, e qui entra in gioco la velocita'. Occorre anche stimare il ritardo tra quando la route e' andata definitivamente a fangala e quando (invece) olsrd ne prendera' atto. Ovvero riflettere sia su gli intervalli con cui le informazioni sono aggiornate (Hello e TC interval) sia sul periodo di tempo durante il quale quelle informazioni sono considerate attendibili *anche* in assenza di un loro aggiornamento (soft state). Un soft state eccessivamente conservativo rischia di mantenere come praticabili rotte che in realta' sono cadute. Diminuendo i due valori HelloInterval e HelloValidityTime otterremo sicuramente un demone piu' reattivo ai cambiamenti di topologia ma aumenteremo - e non di poco - l'overhead (la vita e' un compromesso). In buona sostanza, email, web o chat (o streaming video se bufferizzati) non creano grossi problemi mentre il voip ne risente in misura maggiore. Ma non e' finita qui Altre considerazioni devono essere fatte a seconda che il terminale skype stesso esegua olsrd (ed e' quindi lui stesso un nodo del mesh!) oppure se il termnale skype si connette ad un nodo meshato (magari statico, montato su un palo) che esegue olsrd. In questo ultimo caso non e' la mobilita' del nodo mesh che deve essere presa in considerazione (e quindi tutto l'ambaradan di olsrd) bensi' la mobilita' di un client nei confonti di un AP. ...post poco adatto per un sabato mattina (quasi) primaverile, ma mi e' presa cosi' :) Antonio Il 27 febbraio 2010 04.08, Filippo Sallemi tonyp...@gmail.com ha scritto: Gioacchino intende questo se io sono in un parco comunale, tipo villa margherita, e mi muovo a piedi trai nodi, come faccio a non far cadere la mia chiamata skype? Ovviamente lui pensa in grande e 150 Km/h sono tanti, a me ne basterebbero 1/3 per far contentala gente... e sarebbero costretti a non correre :-) Ovviamente la risposta più banale è IPv6 ma non sono io l'esperiente in merito. Ciao Il giorno 26 febbraio 2010 20.08, Reiser4 reis...@gmail.com ha scritto: Il giorno 26 febbraio 2010 19.56, Gioacchino gmazzurc...@gmail.com ha scritto: ciao ragazzi cercando come si comporta olsr con al mobilita' ho trovato informazioni su un plugin chiamato fast-olsr con tanto di simulazioni che dice di avere a 150km/h una perdita di pacchetti del 15% ma cercando il sorgente o comunque un modo per poterlo usare ho trovato solo un'archivio su una pagina di un professore francese che contiene cose che il mio pc dice che sono script mathlab ma se li apro con un editor di testo mi dice che sono binari infatti del testo si riesce a leggere solo qualcosa il resto sono simboli strani cosa ne sapete/pensate voi ? andando a 150km/h hai perso per strada la punteggiatura? non capisco la finalità del mesh a 150km/h nè come possa un plugin cambiare la situazione. Spiegaci cosa vuoi fare che ci pensiamo su.. Enrico ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless -- Filippo Sallemi ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless -- Filippo Sallemi ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] fast-olsr
Il 26/02/10 19:56, Gioacchino ha scritto: ciao ragazzi cercando come si comporta olsr con al mobilita' ho trovato informazioni su un In mobilita' non e' molto importante OLSR - l'algoritmo di routing. Da quel punto di vista ti serve sia reattivita' che proattivita', mescolate ad arte. Aggiungendo il movimento dei nodi aggiungi un nuovo grado di liberta': 3) tempo di convergenza (che c'e' anche sulla connettivita' cablata) 2) caos dei fenomeni elettromagnetici (che c'e' anche sul wifi) 1) sostanziale imprevedibilita' del movimento del nodo (che implica ad esempio dover fare i conti con la velocita' di sintonizzazione della radio e/o una qualche forma di predittivita' dello spostamento del nodo) Per risolvere efficientemente questo issue senza fare uno stack apposito, e cioe' riciclando la tecnologia gia' in mano agli utenti puoi procedere - che io sappia - in tre direzioni diverse (tutte e tre efficaci, dipende dalla strategia di penetrazione sul mercato... dagli assets cioe' che hai a disposizione: se la Fiat te lo piazza sulle automobili, o se Autostrade Spa te lo piazza sulle autostrade, etc). Altrimenti puoi risolvere facendo una tecnologia completamente nuova ma poi devi spiegare a X milioni di felici possessori di roba wifi, wimax, hspa, IP, perche' dovrebbero ricomprare tutto con la tua tecnologia dentro. plugin chiamato fast-olsr con tanto di simulazioni che dice di avere a 150km/h una perdita di pacchetti del 15% ma cercando il sorgente o comunque un modo per poterlo usare ho trovato solo un'archivio su una pagina di un professore francese che contiene cose che il mio pc dice che sono script mathlab ma se li apro con un editor di testo mi dice che sono binari infatti del testo si riesce a leggere solo qualcosa il resto sono simboli strani cosa ne sapete/pensate voi ? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] fast-olsr
cosa ne sapete/pensate voi ? questo fast-olsr che hai trovato mi sembra più che altro una ricerca accademica. Quando trovi simulazioni in ns2 o matlab, a meno che non ci sia una successiva implementazione per un prototipo, puoi fermarti su quella strada perché non troverai niente di pratico ed utilizzabile subito. Li forse si parla di 150Km/h perché si astrae completamente il layer2 wifi e si considera solo lo strato di rete... cmq vado ad intuito, non ho googlato niente quindi mi fermo qui. cmq, per la mia esperienza al Tuscolo, se configuri bene OLSR come ti suggeriva anche Antonio, mettendo HELLO più frequenti ed expire times più brevi, dovresti gestire bene la mobilità. Però quanti utenti mobili che parlano su skype pensi di avere ? Perché una rete mobile è anche più instabile quindi io ti sconsiglio di configurare la rete con lo scopo di gestire la mobilità. Vai a leggere degli archivi della lista olsrd-dev perché questo argomento è stato discusso più volte. Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] fast-olsr
la caduta di chiamate non dipende tanto dalla velocita' con cui ti muovi ma dal conseguente fatto che cambiando il path (la route) devi rinnovare gli handshake TCP con il next hop. Ergo: quanto piu' a lungo la route e' considerata valida (anche se degradata) minore e' il rischio di connessioni TCP abbattute (poprio perche' cambia il gateway). Scusate c'è una grossa imprecisione in questo paragrafo. Provo a decifrare ed a scrivere in modo più corretto. Un handshake TCP non si fa con il next hop ma con l'host remoto con il quale ho una sessione TCP (non è detto che sia il next hop). TCP è quindi end2end, lo parlano solo i due host ai capi della connessione TCP. Nel caso di NAT questo spezza la natura end to end della sessione TCP, creandone di fatto due, una tra il primo host ed il NAT, ed una tra il NAT ed il secondo host. Ora se gli host si muovono cosa succede? Se la sessione TCP cambia percorso e non attraversa più il NAT la sessione TCP cade. Nel pratico se io esco dal NAT di una ADSL, e poi mi muovo ed esco con altra ADSL il mio IP pubblico cambia quindi la sessione TCP che potevo avere con un host su Internet cambia, perché quell'host vede un altro IP pubblico ed ovviamente non capisce che sono io. Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] fast-olsr
si questo e' il discorso esaminato nelle sue casistiche, praticamente abbiamo quindi visto che per un nodo che si muove il max che si puo' fare e' qualcosa tipo fast-olsr ( cmq i 150km/h non interessavano a me ma sono quelli riportati nei loro studi ) che da quello che dicono funziona anche abbastanza bene ora bisogna trovare il sorgente o riscriverlo ( dalla spiegazione che fanno non sembra troppo complicato ) nel caso due bisogna vedere come fare un'idea era usare una subnettona gigante per tutti i client cosi' che spostandosi da un nodo all'altro non sia necessario cambiare ip ma a questo punto bisogna vedere come si comporta l'instradamento verso la nuova strada On Saturday 27 February 2010 10:43:57 Antonio Anselmi wrote: la caduta di chiamate non dipende tanto dalla velocita' con cui ti muovi ma dal conseguente fatto che cambiando il path (la route) devi rinnovare gli handshake TCP con il next hop. Ergo: quanto piu' a lungo la route e' considerata valida (anche se degradata) minore e' il rischio di connessioni TCP abbattute (poprio perche' cambia il gateway). olsrd usa l'algoritmo shortest path first per quanto riguarda il mantenimento dello status di un link (almeno le versioni RFC compliant...). Ora supponiamo che: - al tempo t0 sei collegato al gateway G con un solo hop (te - nodo G) - al tempo t0+n e' *disponibile* una rotta migliore: te - nodo-intermedio - nodo G (2 hop) orbene, olsrd privilegia il link con un solo hop (con ETX povero) a dispetto due hop (ciascuno con ETX migliore). Questo dovrebbe garantire una certa persistenza delle connessioni TCP, perlomeno in presenza di una mobilita' circolare, ovvero ti muovi gironzolando e NON orizzontalmente in fuga. Ma non bisogna esagerare nel tenersi stretta una rotta che - piu' o meno velocemente - sta' degradandosi, e qui entra in gioco la velocita'. Occorre anche stimare il ritardo tra quando la route e' andata definitivamente a fangala e quando (invece) olsrd ne prendera' atto. Ovvero riflettere sia su gli intervalli con cui le informazioni sono aggiornate (Hello e TC interval) sia sul periodo di tempo durante il quale quelle informazioni sono considerate attendibili *anche* in assenza di un loro aggiornamento (soft state). Un soft state eccessivamente conservativo rischia di mantenere come praticabili rotte che in realta' sono cadute. Diminuendo i due valori HelloInterval e HelloValidityTime otterremo sicuramente un demone piu' reattivo ai cambiamenti di topologia ma aumenteremo - e non di poco - l'overhead (la vita e' un compromesso). In buona sostanza, email, web o chat (o streaming video se bufferizzati) non creano grossi problemi mentre il voip ne risente in misura maggiore. Ma non e' finita qui Altre considerazioni devono essere fatte a seconda che il terminale skype stesso esegua olsrd (ed e' quindi lui stesso un nodo del mesh!) oppure se il termnale skype si connette ad un nodo meshato (magari statico, montato su un palo) che esegue olsrd. In questo ultimo caso non e' la mobilita' del nodo mesh che deve essere presa in considerazione (e quindi tutto l'ambaradan di olsrd) bensi' la mobilita' di un client nei confonti di un AP. ...post poco adatto per un sabato mattina (quasi) primaverile, ma mi e' presa cosi' :) Antonio Il 27 febbraio 2010 04.08, Filippo Sallemi tonyp...@gmail.com ha scritto: Gioacchino intende questo se io sono in un parco comunale, tipo villa margherita, e mi muovo a piedi trai nodi, come faccio a non far cadere la mia chiamata skype? Ovviamente lui pensa in grande e 150 Km/h sono tanti, a me ne basterebbero 1/3 per far contentala gente... e sarebbero costretti a non correre :-) Ovviamente la risposta più banale è IPv6 ma non sono io l'esperiente in merito. Ciao Il giorno 26 febbraio 2010 20.08, Reiser4 reis...@gmail.com ha scritto: Il giorno 26 febbraio 2010 19.56, Gioacchino gmazzurc...@gmail.com ha scritto: ciao ragazzi cercando come si comporta olsr con al mobilita' ho trovato informazioni su un plugin chiamato fast-olsr con tanto di simulazioni che dice di avere a 150km/h una perdita di pacchetti del 15% ma cercando il sorgente o comunque un modo per poterlo usare ho trovato solo un'archivio su una pagina di un professore francese che contiene cose che il mio pc dice che sono script mathlab ma se li apro con un editor di testo mi dice che sono binari infatti del testo si riesce a leggere solo qualcosa il resto sono simboli strani cosa ne sapete/pensate voi ? andando a 150km/h hai perso per strada la punteggiatura? non capisco la finalità del mesh a 150km/h nè come possa un plugin cambiare la situazione. Spiegaci cosa vuoi fare che ci pensiamo su.. Enrico ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless -- Filippo Sallemi
Re: [Ninux-Wireless] fast-olsr
bisognerebbe magari fare il mesh a layer 2 cosi' che il cloud-mesh e' visto come un gran_bel_switch. Antonio Il 27 febbraio 2010 12.40, Reiser4 reis...@gmail.com ha scritto: Il giorno 27 febbraio 2010 12.29, Gioacchino gmazzurc...@gmail.com ha scritto: si puo' evitare il nat in qualche modo ? usando il routing ed assegnando a tutti un indirizzo ip diverso? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] fast-olsr
si puo' evitare il nat in qualche modo ? usando il routing ed assegnando a tutti un indirizzo ip diverso? il problema è quando parli con Internet. Dovresti dare a tutti un IPv4 pubblico. Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] fast-olsr
Il giorno 27 febbraio 2010 12.52, ZioPRoTo (Saverio Proto) ziopr...@gmail.com ha scritto: si puo' evitare il nat in qualche modo ? usando il routing ed assegnando a tutti un indirizzo ip diverso? il problema è quando parli con Internet. ah in questo caso si: o assegni a ciascuno un ipv4 pubblico individuale oppure fai in modo che escano tutti dallo stesso nat, quindi che l'altra parte della comunicazione veda sempre lo stesso ip (quello del nat) ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] fast-olsr
ma se a noi non interessa tanto internet quante/quali diventano le soluzioni ? usare un ip statico all'interno della rete con cui vuoi comunicare ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
[Ninux-Wireless] fast-olsr
ciao ragazzi cercando come si comporta olsr con al mobilita' ho trovato informazioni su un plugin chiamato fast-olsr con tanto di simulazioni che dice di avere a 150km/h una perdita di pacchetti del 15% ma cercando il sorgente o comunque un modo per poterlo usare ho trovato solo un'archivio su una pagina di un professore francese che contiene cose che il mio pc dice che sono script mathlab ma se li apro con un editor di testo mi dice che sono binari infatti del testo si riesce a leggere solo qualcosa il resto sono simboli strani cosa ne sapete/pensate voi ? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] fast-olsr
Gioacchino intende questo se io sono in un parco comunale, tipo villa margherita, e mi muovo a piedi trai nodi, come faccio a non far cadere la mia chiamata skype? Ovviamente lui pensa in grande e 150 Km/h sono tanti, a me ne basterebbero 1/3 per far contentala gente... e sarebbero costretti a non correre :-) Ovviamente la risposta più banale è IPv6 ma non sono io l'esperiente in merito. Ciao Il giorno 26 febbraio 2010 20.08, Reiser4 reis...@gmail.com ha scritto: Il giorno 26 febbraio 2010 19.56, Gioacchino gmazzurc...@gmail.com ha scritto: ciao ragazzi cercando come si comporta olsr con al mobilita' ho trovato informazioni su un plugin chiamato fast-olsr con tanto di simulazioni che dice di avere a 150km/h una perdita di pacchetti del 15% ma cercando il sorgente o comunque un modo per poterlo usare ho trovato solo un'archivio su una pagina di un professore francese che contiene cose che il mio pc dice che sono script mathlab ma se li apro con un editor di testo mi dice che sono binari infatti del testo si riesce a leggere solo qualcosa il resto sono simboli strani cosa ne sapete/pensate voi ? andando a 150km/h hai perso per strada la punteggiatura? non capisco la finalità del mesh a 150km/h nè come possa un plugin cambiare la situazione. Spiegaci cosa vuoi fare che ci pensiamo su.. Enrico ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless -- Filippo Sallemi ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
