Subject: [tsvwg] SCE can not give benefits to SCE senders on networks without FQ

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 24 Apr 2020 16:53:39 +0000

Hi all,

In discussions with other people I still see that some believe that you can deploy an(other) ECN response without an(other) input indication. If that would be the case ECN RFC3168 would have worked with one bit, not?

Lets call such an ECN sender a hidden-ECN sender, because it hides itself from the network.

Imagine if RFC3168 would have been defined as such a hidden-ECN, with only an output from the network to the end-system... so only one bit would be needed with value 0 being non-CE and 1 being CE. ECT (ECN capable traffic) would be removed at all in this case. How would you design a network for such hidden-ECN flows if you would want to have at least equal or better performance for this hidden-ECN senders? The latter is important if you want to have an incentive for end-systems to use your new ECN design, right!

As the network does not know if the flow is ECN or not, it still needs to drop all packets to make sure that flows not supporting ECN also back off. On the other hand, senders supporting the hidden-ECN would need to respond to drop as other flows by reducing your window to half, because you don't know if the network supports your hidden-ECN. So bottom line is that the hidden-ECN senders would still have as much loss as others, and additionally will see extra CE marks that reduces their throughput if they would use those, right??? Would you want to use this hidden-ECN as a sender??? Would you enable such a hidden-ECN in your network??? I wouldn't. This is the reason why RFC3168 ECN was designed with 2 bits. It was very important that a packet could tell the network: "hey, you can mark me 'INSTEAD' of dropping me".

This is also why L4S uses an extra input to tell the network: "hey you can mark me on a lower threshold if you protect me from the delay of other flows". This is also the reason why SCE cannot support the protection for the newer ECN behavior without per L4 flow isolation. Unfortunately a third bit is not available to let the network know if it is a classic CE or a protected-and-more-frequent-shallow-CE. With the Classic-CE-Fallback code (admitting that maybe some bug-fixing (thanks Pete) and further tuning is needed, but the results I saw are already very good with a simple to implement heuristic, more to come) this can be detected by the end-system, without the network needing to do per L4-flow isolation. Additionally L4S flows with Classic-CE-Fallback can benefit from Classic ECN bottlenecks too, and be at least as good as Classic ECN senders. In the future no-one needs to use ECT(0), as ECT(1) is at least as good, and after time ECT(0) can be freed and reused for new experiments...

Hoping this helps everyone to support L4S on Monday, and realize that the hidden-SCE is a not an option.

Thanks,
Koen.

---

From: Jonathan Morton <[email-masked]>
Date: Fri, 24 Apr 2020 21:28:45 +0300

> On 24 Apr, 2020, at 7:53 pm, De Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 

Summarising your argument:  "AQMs cannot distinguish SCE transports from RFC-3168 transports, therefore SCE is bad."

Summarising our argument:  "Transports cannot distinguish L4S AQMs' CE marks from RFC-3168 AQMs' CE marks, therefore L4S is bad."

I do actually agree that ideally, we would be able to provide both input and output signals for the network's benefit, but that is not the hand we have been dealt.  I hope we can raise the tone of this discussion above that level, and take into account what the effects of different uses of the limited codepoint space actually are.

Our rationale for identifying SCE transports with ECT(0), identically to RFC-3168 transports, is that as far as an RFC-3168 AQM is concerned, we are an ECN Capable Transport conforming to RFC-3168.  Only AQMs that implement SCE need to be aware of the distinction and implement measures to avoid unfairness, measures that are now well-understood.  As a happy side-effect, these measures improve RTT independence for all traffic passing through such a node, even if they do not actively enforce throughput fairness as FQ does.

By using the remaining codepoint as a classifier, L4S is relying on the network understanding that classifier.  But existing networks do not understand it, whether they implement ECN or not.  Where your analogy with ECN deployment breaks down is that while an ECN mark is easily distinguishable from a packet drop at the transport layer, its meaning for the purpose of congestion control is the same.  That is why RFC-3168 states that AQMs should drop packets that they would have marked, if only they were ECN Capable.  But L4S results in CE carrying two meanings, depending on what type of AQM produced it, and it is *not* immediately obvious to the transport which one did.

Instead, the L4S transport has to guess.  If it guesses wrong, the results are pretty bad unless the network implements some active countermeasures - which most networks, today, do not.  Our tests have found some cases where it does guess wrong, and where the current implementation actively drives the network into congestion collapse.  That, we think, is a problem.

An SCE transport does not have to guess.  It knows explicitly whether it is seeing a conventional Multiplicative Decrease signal or a high-fidelity one.  The responsibility is on the network node deciding to generate SCE signals to do so in a way that avoids unfairness.  Reliable methods to do so are well known, and we have demonstrated their effectiveness with SCE, though we hope to further improve performance in time.  But note also the nature of the unfairness when it is not corrected: SCE is the one that gives way.  Therefore, the SCE transport does not harm the network, even when something goes wrong.

I do hope this helps to inform the discussion at Monday's meeting.  I'm sure it will be quite lively, but let's at least keep it civil and factual.

 - Jonathan Morton