On Fri, Jan 19, 2007 at 05:37:30PM +0100, <Alessandro Ordine>:
~> 1)Per quanto riguarda la mobilita' io penso che il trend attuale sia di
~> infischiarsene e gestirla in qualche modo a livelli piu' alti del livello 3.
~> Questo lo dico un po' per esperienza personale, un po' per articoli vari che
~> sto leggendo in questo periodo.
Si, ad esempio, si puo' usare OLSRD sopra ntk, e robe simili.
~> 2)Per quanto riguarda la gnode contiguity penso che una maniera per
~> ottimizzare la faccenda potrebbe essere cercare di assegnare gli id dei
~> gnode (del piu' alto livello) in maniera centralizzata (evitando cosi'
~> collisioni) e caso mai utilizzando forme di aggregazione. Lo so che non ti
~> piace l'idea della centralizzazione ma penso che sia solo un problema
~> filosofico perche' non credo ci siano questioni ne' dal punto di vista
~> dell'affidabilita' ne' dal punto di vista del traffico. Infatti solamente i
~> bnode dei gnode di livello 3 (se pensiamo a ipv4) dovrebbero interrgoare
~> questo(i) server.
brrr
Non e' solo una questione filosofica.
La centralizzazione non e' mai la soluzione piu' efficiente, anche se e' la
soluzione piu' semplice!
(si potrebbe anche cercare di dimostrare questo fatto. Una prima prova
intuitiva: scrivere un algoritmo distribuito e' piu' difficile rispetto allo
stesso centralizzato. Dovrebbero in qualche modo valere sempre queste
condizioni:
Kc=complessita' dell'algoritmo centralizzato
Kd=complessita' dell'algoritmo distribuito
Ec=efficienza dell'algoritmo centralizzato
Ed=efficienza dell'algoritmo distribuito
K=c*E (L'efficienza di un algoritmo e' proporzionale alla sua complessita')
Kc < Kd, Ec < Ed
Ovviamente non e' facile dimostrare una cosa del genere, dovresti considerare
Kolmogorov, la complessita' algoritmica (vedi Algorithimc Information Theory),
e via dicendo...
)
Cmq intuitivamente si vede subito. Un algoritmo centralizzato ti crea molti piu'
problemi a livello di efficienza.
Netsukuku deve rimanere distribuito. Se cominciamo ad aggiungere server qua e
la', si snaturalizza completamente.
Gli unici server che per ora vengono usati sono gli Entry Server (vedi
viphilama). Questi sono necessari, e svolgono un lavoro minimo.
Nota anche che Viphilama fa gia' quello che faresti con dei server
centralizzati: Viphilama permette di evitare che si creino collisioni, perche'
crea gia' una rete uniforme.
~> 3)Quando un node fa l'hooking e trova il gnode pieno abbiamo detto che crea
~> un nuovo gnode. Intendi un nuovo gnode di livello 3 uno nuovo di livello 2 e
~> cosi' via...
Si, ma non esattamente.
n cerca di hookare a g1:12 (gnode lvl 1, ID 12).
g1:12 e' pieno.
Se pero' n confina anche con g1:16, e g1:16 e' libero, allora ovviamente hooka
con lui. In ogni caso n ha preso la mappa esterna da g1:16 e da g1:12.
Se, invece, tutti i suoi g1 confinanti fossero pieni, allora cercherebbe un g1
vuoto (guardando nella mappa esterna al livello 2).
Se tutti i g1 fossero pieni cercherebbe un g2 libero. E cosi' via...
Se non trova mai nulla di libero da lvl 1 a 2, allora quasi sicuramente
troverebbe
un g3 non pieno. Se tutti i g3 fossero pieni, vorrebbe dire che l'intera rete
e' diventata satura.
~> 4)Avete mai pensato alla "local latency"? Se la procedura descritta nella
~> slide e' corretta avete mai pensato a quantificare il tempo che ciascun nodo
~> impiega a trovare il next-hop per la destinazione?? E' se questa fase di
~> lookup viene eseguita su tutti i nodi che collegano sorgente e destinazione
~> non ci mette troppo? Se introduci dei meccanismi per cui all'interno del
~> gnode i nodi intermedi cercano di raggiungere solo il bnode e non ogni volta
~> la destinazione finale semplifichi la lookup phase nei nodi intermedi, devi
~> portarti dietro pero' un informazione in piu' (l'ID del bnode!)
Intendi l' O() dell'algoritmo di lookup?
Per questo non c'e' problema. E' quasi costante, perche' c'e' gia' tutto nella
mappa:
nella mappa posseduta da n, nella struttura di ogni (g)node D e'
presente
il gw (del livello in questione) che n deve usare per raggiungere D
stesso.
Quindi, sono proprio pochissimi passaggi.
O meglio, e' legato al numero di livelli l, quindi sara' qualcosa del tipo O(l).
Cmq di questo non mi preoccuperei proprio.
~> 5)pensavo che ci saranno piu' o meno sparsi ovunque nodi molto
~> congestionati. Voi risolvete il problema del bilanciamento del carico
~> (usando il Caustic Routing) sostanzialmente bilanciando con il multipath il
~> carico lontano dalla destinazione. Se un nodo riceve molto carico i suoi
~> link resteranno comunque il collo di bottiglia. Infatti gli alberi che
~> costruisci col multipath convergono a D!!!
Si e' vero. Ma
Se riceve molto carico esterno (che non genera lui e a cui non e'
interessato),
allora il valore della qualita' del suo link cambiera',
e quindi al prossimo update i nodi non lo considereranno come
un link buono.
Quindi i nodi non cercheranno piu' di usarlo come gw,
e quindi ricevera' meno carico.
se invece il traffico e' interno
allora gli altri nodi non lo useranno come gw,
e potra' usare i suoi link solo per se stesso.
Ovviamente se e' in un punto cruciale (unico link tra europa-america), non
c'e' molto da fare...
--
:wq!
"I don't know nothing" The One Who reached the Thinking Matter '.'
[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9 5277 BFF8 037E 441C F0EE ]
_______________________________________________
Netsukuku mailing list
[email protected]
http://lists.dyne.org/mailman/listinfo/netsukuku
