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

[Steven Blake <[e-mail]>]

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-the-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