Re: [tsvwg] L4S vs SCE

[Roland Bless <[e-mail]>]

Hi Bob,

see inline.

On 21.11.19 at 19:34 Bob Briscoe wrote:
> 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.

FWIW, our delay-based approach has deployment problems at the
other end of the spectrum: it gets suppressed by loss-based CCs...
(and we don't want to sacrifice our low delay goal).

> 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

I was solely referring to the marking behavior of SCE, not a particular
implementation based on FQ-AQMs.

> other than massively constraining future evolution of CCs, especially
> real-time ones? See Per-Flow Scheduling and the End-to-End Argument
> <http://bobbriscoe.net/projects/latency/per-flow_tr.pdf>. I don't need
> to tell you that the e2e argument is all about giving end systems the
> power to innovate without permission.

> Anyway, what are you imagining would stop CCs evolving alongside other
> scalable CCs? In much the same way CCs have always evolved. With L4S you
> have a clean slate that seems just like a FIFO with a shallow ECN-only
> immediate AQM. And other flows are causing you hardly any delay and very
> rarely any loss. Think of all the things you can do with that. Go
> evolve, Roland!

I already said that the Dual Queue AQM is nice, but comes with the
problem due to its built-in dropping law. Other CCs may react differently
and BBR was one example of newer CCs that did not work in the L4S queue
without further adaptation.
 > The key thing here is the wording of the Prague requirements
> <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-08#section-4>.
> We have a session in the 'Prague' side-meeting tomorrow to review them
> (and I encourage this on this list too).
> 
> Later down the line, if the L4S experiment is successful, there will be
> an opportunity to review these requirements if a standards track doc
> replaces the experimental (it is easier to relax CC requirements than
> tighten them). So, for the expt track, the requirements are designed to
> protect competing flows from harm in a tighter way than you might find
> in RFC5033 or similar.
> 
> 
> Nonetheless, even the 1/p isn't tightly spec'd, quoting:
> 
>    The inverse proportionality requirement above is worded
>    as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility
>    when defining these specifications.

Yes, but something has to be implemented (in hardware) and therefore it
is fixed for some time and it should be consistent along a path, so I
don't see a viable path for evolvement of this coupling law...

Regards
 Roland