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
