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

[Toke Høiland-Jørgensen <[e-mail]>]

Juliusz Chroboczek <[e-mail]> writes:

>> Well, the issue we're trying to resolve in Bird by using kernel
>> timestamps is that if the application blocks for a long time without
>> processing incoming packets, that will be part of the RTT which can (it
>> seems) lead to some pretty inflated RTT values.
>
> Why would the application block?  Isn't that a bug in the application?

Well, not so much block as being busy doing something else (and being
single-threaded and using a coarse-grained event loop). And yes,
arguably it's a bug in the application, but if we're giving advice about
how to write a robust implementation, it might be worth addressing anyway.

>> Or drop this entirely if we really believe that it doesn't make any
>> difference?
>
> On the write side, it definitely makes a difference: if memory serves,
> kernel timestamping happens after queueing, so any local congestion is
> going to make the two timestamps very different.
>
> On the receive side, it probably doesn't.

Yeah, on the receive side the difference will be microseconds, unless
the application suffers from the issue mentioned above. I agree that the
calculated RTT should include any congestion in the local qdisc layer
(or equivalent), so using kernel timestamping on TX is probably not a
good idea; but that's not really feasible to do either, as you'd have to
instruct the kernel how to insert the timestamp into the packet at the
right place. We don't even have a BPF hook that can do this without
jumping through a lot of weird hoops :)

So maybe we should change the text to address the RX side only, so
instead of:

"and receive timestamps SHOULD be computed just after the packet is
received from the network stack."

we'd have something like:

"and receive timestamps SHOULD be computed at the earliest possible time
after the packet is received from the networking hardware. The latter
can be achieved by instructing the operating system kernel to add a
timestamp to packets when they are received (using a mechanism such as
the SO_TIMESTAMP option), or it can be done by timestamping the packet
as soon as the babel implementation receives it from the networking
stack. If timestamping is done in the application itself, care needs to
be taken to make sure the application always processes incoming packets
in a timely manner, to avoid inflating the estimated RTT by the time
packets are waiting to be processed by the application."

The above is probably way too verbose, but I'm sure you get the gist of
it :)

>>>> We don't explicitly expire RTT state if the sanity checks keep failing,
>>>> so I don't believe we're compliant with the last paragraph of section
>>>> 3.3.
>
>> > I have misgivings about this paragraph myself.  Shall I remove it?
>> 
>> I'm not sure I understand the issue it is trying to solve, TBH; why was
>> it added?
>
> Right, I'll remove it.

OK, SGTM!

-Toke