[babel] Martin Duke's Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS and COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-babel-rtt-extension-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-rtt-extension/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

- I support Rob's DISCUSS on the status of this document, and would like to
expand on it a bit. I can support this document, with a few modifications, as
experimental, but there are huge gaps in a standards-track spec. If, per the
shepherd writeup, this has been successfully deployed for years, there are
numerous implementation details that are missing. Specifically: o In (3.3) and
(4), there is a weak non-normative suggestion of an algorithm, rather than a
standard way of doing things. o (4.1) There is an allusion to a perfectly
reasonable TCP-like smoothing algorithm in [DELAY-BASED], but this is an
informative reference and the algorithm is not actually described in the text.
o (4.1) "Other algorithms have also been considered, such as a moving average
or a moving minimum, but we have not evaluated their behaviour." This does not
strike me as the maturity level of a proposed standard. Furthermore, the
TCP-like algorithm is a computationally efficient approximation of a moving
average!

- If this document moves to Experimental, there should be a description of what
the experiment is, including dependent (algorithm? cost function parameters?)
and independent variables.

- Given how loosely defined this spec is, does it matter if different nodes
select different magic numbers and/or algorithms?

- I would like to amplify Zahed's COMMENT to a DISCUSS. As these RTT
measurements are not communicated beyond one hop, is RTT-based routing limited
to the next hop? Is there even a way to measure RTT over multiple hops? If so,
how is this done scalably?

(I will note that another approach would simply take local link-layer delay/RTT
measurements and communicate them as link costs using the normal process, which
would be much easier and tolerant of implementation variances)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Is there any notion of RTT variance, jitter, or other statistical properties
in this framework? ISTM to me that 20 ms RTT + 50 ms variance is a worse link
than 40ms RTT + 2ms variance.

- Assuming, as is likely, this document goes for significant rework, I suggest
an early TSVART review.