Re: [tsvwg] new tests of L4S RTT fairness and intra-flow latency

[Lars Eggert <[e-mail]>]

Hi,

On 2020-11-16, at 23:13, Jonathan Morton <[e-mail]> wrote:
> It's not running code until it actually *is* implemented, and we can run tests showing whether it actually works or not.  We should not need to change default settings in order to show safety in common network topologies.  It must also be documented in such a way that future implementors are likely to produce a similarly high quality result.
> 
> Frankly, it is not a very high bar we're holding up here.

FWIW, I agree with Jonathan here.

Independent verification of experimental results is an essential part of the scientific process in general. And for TCP in particular, it was used to great effect during the "highspeed TCP wars" of the early 2000s, when the proponents of BIC/CUBIC, Compound TCP, HSTCP, etc. all tried to recreate each others experiments and results. Many bugs and unstated assumptions were identified as a result, and the individual algorithms all benefitted immensely. I'm hoping that we can use this approach to make progress in this (apparently endless) debate, as well.

A reference implementation for a standards proposal therefore really needs to implement that proposal accurately and in its latest instantiation. And if the code requires parameterization (esp. scenario-specific parameterization) beyond what the spec describes, then either the code or the spec are incomplete.

Thanks,
Lars