One more question. Why the Section 12.1.2 Asymmetry in Q2 present in the qspn.pdf of may 2007 is not present anymore in the september 2007 document ??
Saverio Proto 2007/10/22, ZioPRoTo (Saverio Proto) <[EMAIL PROTECTED]>: > Hello, > > I had a very good time in Pisa at the hackmeeting with the Netsukuku > team! That was already 22 days ago! I want to apologize for not > writing before. > > In Pisa, me and some other people from University of Rome Tor Vergata, > had the opportunity to talk with AlpT to make questions regarding the > QSPN > > To our feeling after the hackmeeting is that there are very good ideas > behind the project, but somehow this ideas should be written in a > proper way. > > The excellent work carried out by AlpT in the documentation, only > explains the theory behind the netsukuku network protocol. > > We strongly believe that writing a specification, in parallel during > the implementation, can prevent protocol design problems that might > arise in the future. > > > First problem. > > As far as we understood a Netsukuku node to execute the hook procedure > has to choose a random IP address, and exchange maps with neighbours > nodes. > We strongly believe this is unnecessary (choose the temporary IP) and > should be managed in UDP. > You might want to read Noa-OLSR and have a look at their approach. > > Second problem. > > This is about metrics. > As far as our knowdge IP protocol uses hop count as metric. Problems > started to arise when the TCP/IP protocol stack moved from on top of > wired connections to wireless connections. > IP itself does not provide the necessary tools to integrate new > metrics (protocol design problem) so we adjust the hop count (faking > more hops than real) in order to cope with. > I mean that in a routing table we have an integer value that should > represent the hop count, and that's the metric to choose the best > route. Some protocols use that valure related to another metric > different than hop count. > As an example OLSR or batman feed the routing table of the kernel with > hops calculated by other means than hop count. > So all this was just to say that IP is not very friendly in adding a > new kind of metric. > > The biggest NEW problem comes taking into consideration asymmetric > links (that in the wired world didn't exist if we don't think about > ADSL lines that are asymmetric for choice of ISP). > > Now consider two nodes A and B phisically connected with a wireless > link. In netsukuku a TP Generated by the node A and received by the > node B let's be node that there is a link A->B but B can't be sure > that there is also a B->A node, and there is an high probability that > bandwidth of A->B is very different than bandwidth of B->A. > > So, if you are writing Netsukuku in order to be adaptable to many > metrics, you should make it adaptable also di metrics that take into > consideration asymmetric links. This means signalling of QSPN should > be able to assign 2 metric values per link. > > my 2 cents > > feel free to go ahead with questions :) > > Saverio Proto (and some more Tor Vergata people) > _______________________________________________ Netsukuku mailing list [email protected] http://lists.dyne.org/mailman/listinfo/netsukuku
