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

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

Hi all,

The RTT-independence was implemented, available and demonstrated several meetings ago already and as presented working very well according to our tests. The following parameters are now set as default, so can be tested out of the box:

All Prague flows with an RTT below 25ms will now converge to the same rate, independent of their real base RTT. This means that flows with a bigger RTT than 25 ms will never have to compete against smaller than 25ms RTT flows. 

Now the defaults are set, I'm looking forward to independent evaluations.

Hope this helps??
Koen.


-----Original Message-----
From: tsvwg <[e-mail]> On Behalf Of Lars Eggert
Sent: Tuesday, November 17, 2020 1:33 PM
To: Ingemar Johansson S <[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-17, at 13:46, Ingemar Johansson S <[e-mail]> wrote:
> 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 ?

I've long ago given up trying to follow the blow-by-blow of this overall discussion. And maybe that means I've disqualified myself from having an opinion. But I don't quite know what to make of your statement.

If "Prague" (I guess you mean a TCP variant taking advantage of L4S?) is a "work in progress", why are we then pushing towards finalizing the L4S part of the overall scheme?

Maybe I'm naive here, but I always thought the queuing scheme and a TCP variant for it would necessarily go together. That TCP variant might be an initial design that maybe doesn't take full advantage of all the benefits the queueing scheme might offer, but surely it should demonstrate some significant benefit without significant downsides?

And we can of course have a discussion on whether RTT unfairness (or any other property or lack of one) is a significant downside or not, but I don't think we've had that discussion?

Basically, I'm trying to re-engage here for a bit to see if there is *any* hope for this entire area of work, if I should just ignore it again or even start arguing we should abandon it all, given how wedged the discussion between the camps has been for a long time.

Thanks,
Lars