Re: [babel] Iotdir telechat review of draft-ietf-babel-rtt-extension-05

[Juliusz Chroboczek <[e-mail]>]

Hello Pascal,

I've added an applicability section following your advice.  I'll be
grateful if you find the time to review it.  (David, Toke, Donald, anyone
else, your comments are also welcome.)

1.1.  applicability

   The extension defined in Section 3 provides a sequence of accurate
   but potentially noisy RTT samples.  Since the round-trip time is a
   symmetric measure of delay, this protocol is only applicable in
   environments where the symmetric delay is a good predictor of whether
   a link should be taken by routing traffic; this is the case in most
   networks known to the authors, but might not necessarily be the case
   in networks built over exotic link technologies.

   The extension makes minimal requirements on the nodes.  In
   particular, it does not assume synchronised clocks, but only requires
   that clock drift be negligible during the time interval between two
   Hello TLVs.  Since that is on the order of a few seconds, this
   requirement is met even with cheap crystal oscillators such as the
   ones used in consumer electronics.

   The algorithm defined in Section 4 makes a number of assumptions
   about the network.  The assumption with most severe consequences is
   that all links below a certain RTT (rtt-min in Section 4.2) can be
   grouped in a single category of "good" links.  While this is the case
   in wide-area overlay networks, it makes the algorithm inapplicable in
   networks where distinguishing between low-latency links is important.

   There are other assumptions, but they are less likely to limit the
   algorithm's applicability.  The algorithm assumes that all links
   above a certain RTT (rtt-max in Section 4.2) can be assumed to be
   equally bad, and will only be used as a last resort.  In addition, in
   order to avoid oscillations, the algorithm is designed to react
   slowly to RTT variations, thus causing suboptimal routing for seconds
   or even minutes after an RTT change; while this is a desirable
   property in fixed networks, as it avoid excessive route oscillations,
   it might be an issue with networks with high rates of node mobility.