Re: [babel] New Version Notification for draft-ietf-babel-rtt-extension-06.txt

[Juliusz Chroboczek <[e-mail]>]

I've reordered your text.

> 1) ease/possibility of implementation
> This one is important, but - if we assume that all implementations don't need
> to match - then we can just say "SHOULD implement as low in the stack as you
> can" and everyone can do that on whatever platform they are

[...]

> I guess the bit I'm not sure about is the assumption that I mentioned above:
> the fact that implementations don't need to match. Is there any reason why
> we'd want them to match?

If two implementations don't match by a significant amount, then the
protocol will be biased in favour of one implementation.

Suppose that Linux doesn't include local queueing delay and Mac OS X does.
Then, all other things being equal, the protocol will prefer routing
through Linux routers rather than Mac OS X routers.  Which is probably the
right behaviour, but it should be an explicit decision rather than
a somewhat mysterious side-effect of an implementation detail.

> 2) symmetry
> As you point out, since RTT is the sum of both one-way delays, it will always
> be symmetric :-)

Well, ping is not necessarily symmetric.  If you timestamp ping packets at
the bottom of the stack, then the RTT measured by ping includes remote
queueing delay but not the local counterpart.  And the two queueing delays
are not necessarily equal.

Mills' algorithm, on the other hand, guarantees symmetry.  Good algorithm.

> 3) scheduling jitter
> I would assume that it's best to not count scheduling jitter since that'll
> most likely pollute the measurements and not impact the actual flow of packets
> along this route

Agreed, but what if this contradicts requirement (1)?  We need to make
a choice.

-- Juliusz