Re: [tsvwg] L4S vs SCE

[Pete Heist <[e-mail]>]

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