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

[Sebastian Moeller <[e-mail]>]

Hi Steven,


> On Mar 26, 2021, at 03:13, Steven Blake <[e-mail]> wrote:
> 
> 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 tfor details.o 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.

	[SM] I think Pete's data, while from an artificial testbed and not from a live production network, counts as more than a mere simulation, but the conclusion "not promising" still holds.See https://github.com/heistp/l4s-tests#rtt-unfairness 

Best Regards
	Sebastian



> 
> 
> Regards,
> 
> // Steve
> 
>