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

[Ingemar Johansson S <[e-mail]>]

Hi. 
This is the RTT bias question that has been beating this email list for more
than a year by now.

I imagine that, as Prague is work in progress, then the original authors of
this mail thread could have considered to try out the different options that
address the RTT bias. Or at least consider to re-run the experiment instead
of digging down in long discussions on what is default and not. Prague is
work in progress after all, I don't think that this is unreasonable to ask
and it could have saved us a few roundtrips in in this mailthread ?

Besides this, I was of the impression that the congestion control discussion
would fit better in ICCRG?. 
And as RTT bias is not just an L4S problem then I guess it would me more
fruitful to contribute to work that tries to address it.
/Ingemar

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Lars Eggert
> Sent: den 17 november 2020 09:16
> To: Jonathan Morton <[e-mail]>
> Cc: tsvwg IETF list <[e-mail]>
> Subject: Re: [tsvwg] new tests of L4S RTT fairness and intra-flow latency
> 
> 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