[Ninux-Wireless] fast-olsr

[Antonio Anselmi]

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 <tonyputi a 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 <reiser4 a gmail.com> ha scritto:
>>
>> Il giorno 26 febbraio 2010 19.56, Gioacchino <gmazzurco89 a 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 a ml.ninux.org
>> http://ml.ninux.org/mailman/listinfo/wireless
>>
>
>
>
> --
> Filippo Sallemi
>
> _______________________________________________
> Wireless mailing list
> Wireless a ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/wireless
>
>