Re: [tsvwg] L4S vs SCE

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

Hi Roland,

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

Indeed, this is the problem that has constrained the use of delay based CCs. It gets pushed away by the loss/ECN based congestion controls. But this same effect is exactly the biggest disadvantage of flows responding to SCE. It also gets pushed away by flows that do not respond to this SCE signal.

That the network is able to separate the old and new flows is exactly the power of using the codepoint like L4S. We can create a delay-isolated queue but still can use the ECN signal to:
1: give an estimate what is the fair rate to use compared to other flows
2: give a target for a queue filling level independent of the path delay and possible variations on it

These 2 features are exactly answering explicitly what delay based CC's have to otherwise implicitly have to agree on or find out:
1: how can we make sure that one delay based CC is not pushing away the other delay based CC (what is the delay (variation) based protocol to use for determining the throughput conversion point)
2a: what is the delay target it should use (e.g. on top of the minimum RTT you experienced)
2b: what is delay caused by queuing, and should trigger reduction of throughput, and what is delay caused by scheduling or packet aggregation mechanisms that should not be taken into account (and is useless to reduce throughput for).

I see the immediate/accurate ECN signal as the missing explicit signal to further improve the delay based CCs on those 2 aspects, and I also see delay based CCs the technology to improve the ECN-only DCTCP-style CC.

So it is not a matter of opposition, but it is the combination that gives the power!

Regards,
Koen.


-----Original Message-----
From: Roland Bless <[e-mail]> 
Sent: Thursday, November 21, 2019 2:32 AM
To: Bob Briscoe <[e-mail]>
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>; Ingemar Johansson S <[e-mail]>; Kyle Rose <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [tsvwg] L4S vs SCE

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