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

[Lars Eggert <[e-mail]>]

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