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

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

Hi

I see Prague as work on a congestion control algorithm that can exploit L4S.
Other work is done on e.g. BBRv2 that can use L4S as well, and then we have
SCReAM that is likely to be updated to make better use of L4S. Like with
other congestion control I don't foresee a one size fits all here, for
instance realtime media has different dynamics than bulk transfers
I see all these algorithms as work in progress and I don't see it explicit
in the charter that there must be a fully functional L4S capable congestion
control available. 
I see that the Prague work addresses many of the issues, among then the RTT
unfairness issue. It is still not perfect I guess but all this is a matter
of brain cycles in --> results out. Prague is an initial design and I
imagine that it will be improved over time. Also I see it likely that L4S
capable CCs can draw attention among academics in the future but for that to
happen we need to move forward to give the signal that we move forward, to
make it worthwhile to engage in the work. 

The RTT unfainess.. I believe that it has been discussed to death by now. To
be honest I don't believe that additional discussion will do anything more
than consume energy. Feel free to disagree.

/Ingemar

> -----Original Message-----
> From: Lars Eggert <[e-mail]>
> Sent: den 17 november 2020 13:33
> To: Ingemar Johansson S <[e-mail]>
> Cc: Jonathan Morton <[e-mail]>; 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