dorellik | 2 Aug 2006 01:04
Picon

issues about netsukuku main documentation


Hallo, this is the first time I write to this
mailing list, so I briebly introduce myself.
My name is Cesare Nesi, a,k,a, PincoPallo on
#netsukuku .
I'm interested in udertanding how Netsukuku
(Ntk for short) works ed the ideas behind it.
The main documentation on
http://netsukuku.freaknet.org raise some issues
that deserve more discussion and insight.
I'll submit to you this issues as comments,
criticisms and questions, in the hope this will
be useful not only to me.

Let's begin.

- 1 - Many times the Ntk description rely on the
never stated assumption that every link in the
network is full-duplex.
Wath if some links are sharply asymmetric (e.g.
A-DSL) or even one-way (e.g. satellite broadcast)?
Does this need some rethinking of Ntk logic?

- 2 - Ntk models the net as made of point-to-point
links while a traditional LAN, Ethernet or Token
Ring, is just a single multi-point link.
So a LAN is modeled as a full connected mesh of
logic point-to-point links.
Right?

(Continue reading)

Alpt | 7 Aug 2006 16:26
Gravatar

Viphilama updates

There were few bugs in the Viphilama theory. They are now buried under the
ground ;)

The RFC has been updated, you can check the differences here:
http://lab.dyne.org/Ntk_viphilama?action=diff&rev2=10&rev1=9

Regards ^_^
--

-- 
: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
Netsukuku@...
http://lists.dyne.org/mailman/listinfo/netsukuku

Alpt | 7 Aug 2006 17:15
Gravatar

Re: issues about netsukuku main documentation

On Tue, Aug 01, 2006 at 11:04:37PM -0000, <dorellik@...>:
~> - 1 - Many times the Ntk description rely on the
~> never stated assumption that every link in the
~> network is full-duplex.
~> Wath if some links are sharply asymmetric (e.g.
~> A-DSL) or even one-way (e.g. satellite broadcast)?
~> Does this need some rethinking of Ntk logic?

Yes, it does. If we want a full asymmetric routing we have to retouch this
RFC: http://lab.dyne.org/Ntk_bandwidth_measurement

The asymmetric routing was never taken into account, because we worked mainly
on wifi and direct links.

In the asymmetric routing you need to optimize the upload routes (we are
assuming that the upload bw is <= dowload bw), f.e:

       1.  __ <___<___<__
	  /              \
	A                  B
	  \_____>____>___/
       2.        

`A' can use the route `1' to send packets to `B', while `B' uses the route `2'.

In the current implementation of the QSPN, it is the contrary: A knowns the
best route from B to A, while B knowns the best route from A to B.

In conclusion: it maybe be a new nice TODO to work on ^_-

(Continue reading)


Gmane