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

[Sebastian Moeller <[e-mail]>]

Hi Koen,


> On Mar 26, 2021, at 13:12, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> 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.

	[SM] Sure, we also probably have no doubts that world peace would be great to hav, as well as a generic cure for cancer. But wishing alone will not make that a reality.


> 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).

	[SM] OR because it might be simply impossible to reach a better state than what little is achieved in TCP Prague today. The onus is on you to demonstrate that this new signaling works as advertised. Declaring all non AQM-parts as somebody else's problem does not instill confidence in me.



> Saying this, the outcome of the survey was also that many have implementations or plans.

	[SM] Great, but until any of those get realized and surpass TCP Prague's performance we have to accept that TCP Pragure might be as good as it gets.

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

	[SM] Well, if you show data that confirms that BBR-L4S surpasses TCP Prague both in meeting L4S' requirements as well as performance I happily discuss that data. But until that point TCP Prague is all you have to show for... Well, that is not fair, I guess one outcome of L4S so far has been, pure DCTCP truly is not suited for the internet, even with an isolating AQM.


> With the 2 publicly available implementations (Prague and BBRv2) joined together we cover all performance features.

	[SM] Your challenge is to meet all protocol requirements, performance promises and safety grantees in a single implementation. Splitting these into two protocols is not going to help, so I would expect you to focus on getting on reference protocol up and running first.


> 
> I see the experiment mainly as a "DEPLOYMENT" facilitator, not a performance experiment.

	[SM] That is what I feared. L4S is clearly neither safe nor functional for the existing internet, and instead of using a staged approach to run an experiment first whether your goals and promises will actually hold for normal internet conditions, where path RTT between different flows easily differs by multiple dozen or even 100ms, you want to mass deploy what you have right now. Knowing full well, that after a mass deployment getting any changes into the deployed instances is an uphill fight.
What makes you so sure that the network bits of L4S are truly ready for prime-time as they are, that you are willing to forego the additional round of changes after your baby had actual contact with the real internet?



> Only the need for a minimum window and Classic ECN bottleneck detection needs real live experience (what is the prevalence,

	[SM] I disagree. L4S still requires testing under those realistic conditions that I have been describing for some years now.

> its impact and what are the best control/detection mechanisms) and those would need to be further developed during the first deployment wave.

	[SM] Sorry, these should exist before the first deployment wave, what you have right now, is "thoughts and prayers" instead of robust control and detection mechanisms.


> I don't see the point of having an experiment in controlled (DiffServ) segments, as this could be done in labs too.

	[SM] No, I agree that L4S has not exhausted the development that can be done with the results from lab experiments. What exactly do you want to experiment with when your only question seems to be, on how many hosts can we deploy this? I will spell this out explicitly, deployment is not en experiment, at least not in any scientific meaning of the word experiment. A real experiment can contain deployment sure, but what is the hypothesis you want to test here?


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

	[SM] But you have for years now, objected to any changes to the broken designs and implementations of L4S, why is that going to change in the near future?


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

	[SM] The operation word is "could", this is close to wishful thinking, not engineering, IMHO.


> 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).

	[SM] I consider current L4S design and implementation to be comically and yet catastrophically broken, I object to deploying it as it is right now, and especially without any robust containments in place. 

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

	[SM] Or L4S can simply be changed according to the ample feed-back you received to actually stand a better chance to achieve its lofty goals and promises. The point is, some of us have actual operational experience in getting latency lowering technology out to interested users in the field, an experience which guided some of the free advice and feed-back that L4S so far mainly decided to ignore.


Best Regards
	Sebastian

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