[tsvwg] RTT unfairness (was RE: new tests of L4S RTT fairness and intra-flow latency)

["Black, David" <[e-mail]>]

Lars,
[writing as an individual]

> > The RTT unfairness.. 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?

Not really, for at least a couple of reasons that I can see:

- TSVWG is not the "home" WG for TCP-related work or transport protocol work in general.
- RTT fairness and other transport protocol aspects have entered discussion here as goals of ECN-related work, L4S in particular.

On RTT fairness, here's what was set out as a goal for L4S congestion control (draft-ietf-tsvwg-ecn-l4s-id, Section 4.3):

   o  A scalable congestion control MUST eliminate RTT bias as much as
      possible in the range between the minimum likely RTT and typical
      RTTs expected in the intended deployment scenario (see Appendix A.1.5 for rationale).

It's not at all clear how to determine whether a congestion control meets that requirement.

That's one of six bullets setting out requirements that a congestion control has to meet in order to use the L4S ECT(1) codepoint.

Thanks, --David

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Lars Eggert
> Sent: Tuesday, November 17, 2020 8:38 AM
> To: Ingemar Johansson S
> Cc: tsvwg IETF list
> 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