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

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

Hi

I see in a parallel thread that Koen mentioned the default RTT bias
compensation is changed in Prague so I understand that it is now possible to
rerun the tests that spawned this thread. I guess this should be able to
show if the RTT bias issue to solved to an acceptable degree (whatever that
may be).  

Also I recall that Bob presented material that outlined the RTT unfairness
many moons ago (pre-Corona), don't recall that it caused too much commotion.
So I guess more involvement is from others (not just pro/against L4S folks)
to sort this out otherwise we will just have another lengthy mail thread
that leads nowhere.

/Ingemar  

> -----Original Message-----
> From: Lars Eggert <[e-mail]>
> Sent: den 17 november 2020 14:38
> 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 15:25, Ingemar Johansson S
> <[e-mail]> wrote:
> > 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
> 
> thanks for explaining! I agree.
> 
> > 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.
> 
> Here, I disagree. IMO an existence proof of a CC scheme that derives some
> benefits from L4S in at least some realistic/common scenarios without
> suffering from issues is *key* - why else would we do even do L4S (or any
> other queueing scheme)? How would we even know that we got the queuing
> part right?
> 
> > 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 future may bring advanced CC schemes that optimize their use of L4S,
> delivering large benefits without suffering from any issues. But, it also
may
> not. An existence proof of a CC scheme that managed to deliver some
> benefits for some key scenarios *now* without regressions in others would
> go a long way to convince me that such advanced schemes are on the
horizon.
> 
> > 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.
> 
> 
> Maybe it's been too long, but I can't recall the WG having anything like
> agreement on the question whether less RTT fairness compared to "standard"
> TCP is OK or not. And I don't have a strong opinion here. What we do need
> though is agreement in the WG what kind of regressions/changes in behavior
> from current TCP we're OK with for this new variant of TCP, and which ones
> we're not. Have we had that discussion?
> 
> Thanks,
> Lars