Re: [tsvwg] L4S vs SCE

[Sebastian Moeller <[e-mail]>]

> On Nov 20, 2019, at 21:20, Pete Heist <[e-mail]> wrote:
> 
> 
>> On Nov 21, 2019, at 2:34 AM, Bob Briscoe <[e-mail]> wrote:
>> 
>> Roland,
>> 
>> On 20/11/2019 21:22, Roland Bless wrote:
>>> Yes, but as I also expressed my concerns w.r.t. the L4S codepoint earlier, at the cost of binding this to a quite fixed set of L4S 
>>> behaviors and "burning" the last ECT codepoint. Personally, I like concepts with a little bit more potential to be useful for future 
>>> development (evolvability) of congestion controls, e.g., BBRv2 and LoLa could also benefit from an SCE-like marking...
>> 
>> My whole purpose in solving the problem of deploying scalable CCs over the Internet was to re-juvenate evolution (to widen the range of applications that could be supported by different transport behaviours, particularly for real-time with low latency and high throughput at the same time). One of the main things that has stopped CCs evolving so far is the need for friendliness with the Reno behaviour that was not scaling over the years. 
>> 
>> If SCE is primarily supported in FQ AQMs, that will constrain flows to be capped at the rate that FQ gives them. How is that doing anything other than massively constraining future evolution of CCs, especially real-time ones? See Per-Flow Scheduling and the End-to-End Argument. I don't need to tell you that the e2e argument is all about giving end systems the power to innovate without permission.
> 
> In my opinion, what would enable future innovation in CCs is a signaling mechanism that is completely safe by design, without the need for protection mechanisms, allowing alternatives to be explored without a risk-benefit analysis.

	[SM] At the very least if protection mechanisms are employed, they need to to be robust and reliable, without nasty corner-cases... if the rest of the internet's safe operation is contingent on protection/isolation, it seems prudent to put time and effort to make sure isolation is as strict as technical possible...


Sebastian