Am Fri October 16 2009 14:00:49 schrieb Philippe Jacquet: > Henning Rogge <henning.rogge at fkie.fraunhofer.de> a ?it : > >> 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. > > Dear Henning, > > we are in agreement, protocol solely based on link admissions control > have basically two defaults: > > 1. either the link admission conditions are too loose and the network > accepts links that are too instable for sustained data traffics > 2. or the conditions are too tight and the network excludes too many > links and makes the graph disconnected. > > > What is difficult is to get experimental situations where you have > both cases. I don't say it is impossible, but it is likely marginal, > anyhow worthy enough to include path metrics in OLSR. Anyhow an > additive path metric won't give the garantee that all links in the > path are good enough, one may have one very bad link, hidden by the > quality of the other links that are good enough to make the overall > path optimal by Dijskstra. I still disagree. The problem with hopcount and local "filtering" of links is that hopcount still optimize to use the "worst" of your good links. Which might still not be a good idea. > There are no perfect specifications but one cannot say that all buggy > situations necessarily come from the absence of good specifications. > Some may come from a too strict application of the default values of > the tuning parameters parameters proposed in the RFC. > > I remember an experiment that concludes that OLSR between high speed > cars was great to reduce overhead but led to too faulty links. I > remember of another similar experiment that use much faster hellos > between high speed cars, that lead to still very good overhead > reduction and made link failure detection very good (good enough at > least to open succesful TCP/IP connections between cars moving in > opposite direction at 100 km/h). Notice that path metric won't help > when bad or delayed estimate of link qualities are advertized. > > A last point: one must be careful in defining default metrics if it > requires some link layer notification that are not easy to implement. > > I am looking forward the draft about ETX, it will be useful in > improving the practice of use of metrics in OLSR. A good link hysteresis/filtering can enhance a path metric based OLSR network, thats true. But I think path metric is at least as important as link hysteresis. 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.