On Tue, Mar 24, 2015 at 08:32:11PM +0100, Juliusz Chroboczek wrote: > Any interesting metric (packet loss, delay, etc.) will cause a negative > feedback loop, which will lead to oscillations. In Babel, there are three > mechanisms that cope with the oscillations caused by feedback loops:
The oscillations are caused by usage of the route interfering with usability of the route. It's a problem created by deriving the metric from live "use and see" measurements. Taking measurements more intelligently - like looking at the wifi neighbor state - is another way of reducing oscillation. It might be true that we can't avoid live metrics, but it still is misrepresenting the problem to plainly say "interesting metrics lead to scillations". > 1. the protocol is loop-avoiding, which means that even when oscillations > happen they don't normally cause packets to be lost; > 2. the protocol uses delayed updates, which means that even when a metric > is varying the amount of network traffic remains controlled; IS-IS wouldn't change the metric inside the routing protocol process, it would be steered by a separate component that derives a metric for a given neighbor. Thus, you get the same result by applying this delay on that separate component. > 3. the protocol uses a hysteresis mechanism which limits the frequency of > oscillations. Same for the hysteresis. > IS-IS is fundamentally based on the notion that a topology change is > propagated throughout the network in a timely manner and SPF is recomputed > by all nodes -- it has no loop-avoidance mechanism other then timely > reconvergence. If implemented naively, a dynamically computed metric will > cause repeated flooding, repeated SPF computation, and repeated transient > loops. Indeed transient loops can occur during recomputation. I don't see the flooding being much different than babel, it's the same distribution-of-information problem. > I'm sure these issues can be solved, and I'm pretty confident that Henning > can tell you how; at any rate, it would be a very interesting research > project. However, it is a difficult one, and the three techniques used in > Babel do not apply directly to a link-state protocol. 2 of the 3 do. Babel really does two things, a routing protocol and fancy metric management. The latter is indeed a very interesting research project, in fact one that all the Mesh networks struggle or have struggled with. Knowing you, I assume you did a great job on the metric part. That means I will very likely try and see how much of it I can steal ;) It also means that I'll be happy about someone coming up with an even better metric in 2 years. The consensus needed to make this work isn't on the algorithm, it's on the values - as in: what number is a good wifi link, what number is GigE, what number is a horrible 4 MBit/s powerline link. -David _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
