Re: [babel] Éric Vyncke's Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS and COMMENT)

[Juliusz Chroboczek <[e-mail]>]

Hello Eric,

> # DISCUSS (blocking)


> ```
>   Checking nits according to https://www.ietf.org/id-info/checklist :
>   ----------------------------------------------------------------------------
> 
>   -- The draft header indicates that this document updates RFC8967, but the
>      abstract doesn't seem to mention this, which it should.
> ```

Oops, that's a typo (copy-paste gone wrong), it should certainly not update
8967.  I'll fix that.  Thanks for noticing.

> # COMMENTS (non-blocking)
> 
> ## Generic question
> 
> It seems that the assumption is that the transmission delay is symmetric.

The actual assumption is that high RTT is a good predictor of a link
being undesirable.

It's certainly not always the case that links are symmetric.  However, we
have never encountered a real-world topology where penalising high-RTT
links is a bad idea, even when the high RTT is due to asymmetric delay in
the reverse direction.

The reason for that is that our goal is not to measure delay, our goal is
to converge on as good a set of routes as possible.  In the case of an
ADSL line, for example, the ADSL line is most probably the only link
towards an access network, so penalising the ADSL line is not going to
change the routing decision: the metrics will be slightly higher, but we
will converge to the same set of routes.

As to WiFi links, they induce asymmetric delays on the order of a few ms,
which is under the suggested value for rtt-min (Section 4.2), so they
won't get penalised with default values.

> Does babel also handle average transmission queue length/delay as input ?

None of the implementations known to me do so.  It would certainly be
allowed by RFC 8966 Section 3.5.2, but it could possibly lead to
oscillations, we'd need to do some careful measuring (as we did in the
work leading to this draft).

> ## Section 3.1
> 
> Is the Receive timestamp also modulo 2**32 ? Perhaps worth specifying.

Noted, will do.

> ## Section 3.2
> 
> Like noted by other ADs, please expand 'IHU' at first use.

Will do.

> ## Section 3.4
> 
> While I like the useful implementation note, should there be a reference to
> CLOCK_MONOTONIC ?

Would you be satisfied with "IEEE Std 1003.1-2017"?  Or do you want me to
find the right chapter and verse?

> ## Section 4
> 
> As noted by other ADs, I also find strange to use the word "experimental" in a
> standard track document. Suggest rewriting this part using other terms.

I agree, will do.

> ## Section 6.2
> 
> About the discussion when the Length field is larger than 8, I would strongly
> suggest to also ignore the TLV as the timestamps length cannot be asserted,
> i.e., the first octet of receive timestamp could actually be part of the origin
> timestamp.

Thanks for the comment, I'll try to clarify this.

(The intent is that the two timestamps are always 4 octets each, but may
in a future revision be followed by other fields, which should be silently
ignored.)

> # NITS (non-blocking / cosmetic)
> 
> ## µs or microsecond
> 
> Suggest to use either "µs" or "microsecond" but not both forms in the same
> document.

Will do.

Thanks again,

-- Juliusz