Am Fri October 16 2009 12:03:58 schrieb Philippe Jacquet: > Hello, Henning, > > I would add two points to the discussion which is interesting and > important. > > First point: there are many ways to have a MANET/OLSR not working > well: bugs, badly tuned parameters. The main source of trouble is in > general how neighbor sensing asserts the quality of a link in order to > accept it or reject it, and I agree that using a metric will greatly > help. > > Anyhow RFC 3626 was not excluding the use of link quality in neighbor > sensing, and was suggesting some. The hop count should not be problem > as long as the links that are on the path are good links. In other > words I would see the use of path quality as a minor improvement over > the use link quality in neighbor sensing. Anyhow this would help > traffic engineering. I don't agree. In practice it's very difficult to decide if a link is "good" or "bad" as a binary decission. Maybe the bad link is really important for another node, maybe it is not. Link sensing and hysteresis, even with a local metric, is no replacement for a good additive routing metric used for the dijkstra algorithm in global routing. > Second point: adding a default link quality in OLSRv2 may be as > complicated as inserting general metric in OLSv2, eg in MPR selection, > so we might be careful if we hurry too much. If we put only hop count metric into the main document that's what most research projects will be using as a comparision. And you will hear things like "yes, AODV has lot's of delay for route creation, but OLSR has 30% packet loss". It's more a matter of perception. People will use "Core RFC OLSR without extensions" and will get bad results from it. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Straße 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge at fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
Attachment:
signature.asc
Description: This is a digitally signed message part.