Re: [tsvwg] L4S vs SCE

[Bob Briscoe <[e-mail]>]

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


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.


As another example, "MUST reduce or eliminate RTT bias" is deliberately 
expressed with wriggle room, but with enough strength to address the 
harm issues.

These are all up for review. If you care about evolvability, this is 
where your focus should be.



Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/