Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

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

Hi Steve, (and others that think this "experiment" should be about proving performance of L4S CCs)

The survey confirmed that none of the CC developers doubt that a frequent L4S-CE (being equal to SCE) signal is useful and will improve all kinds of CCs. That the current Prague implementation is not fully up to its optimal performance level yet is because there is not much incentive for the real beneficiaries to work on that (can't be used anyway, as no L4S networks are available). Saying this, the outcome of the survey was also that many have implementations or plans. We all tent to forget that also BBRv2 is a very promising (partial) implementation that supports L4S, where only TCP-Prague seems to attract attention. With the 2 publicly available implementations (Prague and BBRv2) joined together we cover all performance features.

I see the experiment mainly as a "DEPLOYMENT" facilitator, not a performance experiment. Only the need for a minimum window and Classic ECN bottleneck detection needs real live experience (what is the prevalence, its impact and what are the best control/detection mechanisms) and those would need to be further developed during the first deployment wave. I don't see the point of having an experiment in controlled (DiffServ) segments, as this could be done in labs too. If we have this many parties involved, we need to create an open ecosystem (or call it platform) where the solutions can be developed, like it is common practice today. Innovations in CC could up to now only happen from a one-party-only: "sender endpoint CC constrained by Classic CCs, better AQM for Classic CCs". L4S could provide an uncluttered platform for a multi-party innovation in the transport area. I think we should see it like that, and that justifies the "experimental" draft status, but we should go for real open deployments from day one, with as less extra hurdles added to this (ref other mails about end-to-end DiffServ).

If in IETF TSVWG we can't create these coordinated platforms, we will keep on discussing forever (it seems), while the Internet world will happily and freely (though sub-optimally) progress on actions from individual parties.

Regards,
Koen.


-----Original Message-----
From: Steven Blake <[e-mail]> 
Sent: Friday, March 26, 2021 3:13 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>
Cc: [e-mail]
Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

On Thu, 2021-03-25 at 17:54 +0000, De Schepper, Koen (Nokia -
BE/Antwerp) wrote:
> If using DiffServ is considered as a widely deployable technique on 
> the internet, then we should simply use DiffServ as the "input" L4S 
> identifier and use SCE as the congestion "output". I don't think we 
> need more complex experimental schemes, especially if they end up 
> needing a final DiffServ codepoint anyway even after the experiment 
> (like in Jonathan's proposal).
> 
> As such it would be the perfect marriage of both L4S and SCE. So an 
> AQM can only mark SCE if it has the DiffServ L4S-id and can protect 
> and isolate the L4S-SCE flows from flows not responding to the SCE 
> marks (in a DualQ or FQ, or any other scheme detecting presence of 
> non-L4S flows).
> 
> This was one of the options that was considered before and which would 
> be the simplest solution involving DiffServ.
> 
> The question was and still is if DiffServ "is" the perfect wedding 
> proposal for Internet wide traffic. How many more hurdles do we need 
> for deploying scalable and smooth congestion control (which is I 
> assume the common goal of both L4S and SCE).

Why are you discussing deployment? I thought this exercise was about enabling experiments? 

> Main question is: Is the risk (pushing away Classic flows on a
> RFC3168 ECN bottleneck after tens of seconds) worth the extra 
> deployment obstacles (practically making its deployment as constrained 
> as an end-to-end managed service).

Worth it to whom? A general principle is that people conducting experiments shouldn't impose burdens on third parties.

> If the answer is yes, then we should define a DiffServ codepoint that 
> identify L4S and only use SCE for those. If the risk is assumed 
> minimal and comparable with other experimental CCs (see ICCRG
> https://datatracker.ietf.org/meeting/109/materials/slides-109-iccrg-th
> e-great-internet-tcp-congestion-control-census-00
> ), then we live with the (small?/controlled?) impact.
> 
> I understood the latter had the biggest support in the input/output 
> vote during the previous interim. I think if L4S flows are not used 
> for long time downloads (non-application-limited flows), the impact is 
> minimal and a 3168 detection and fallback would never be needed.
> It also was known that Classic bottleneck detection would be a 
> challenge, but I think Asad/Bob showed that a (maybe not 100% perfect, 
> but already) very good implementation is possible if needed for the 
> problem conditions that are known then. These could be used 
> (experimented with) when using L4S for downloads.
> 
> So bottom-line question: Who believes an end-to-end DiffServ solution 
> is realistically deployable???

This should not be an issue if and until L4S experiments prove that it is a beneficial technology to deploy.

> Second sub question: who believes L4S is a bigger risk than all other 
> CCs "experiments" on the Internet??

No one can offer an informed opinion until there is experimental data.
The existing simulation data is not promising, to put it mildly.


Regards,

// Steve