The congestion-notification conflict

Posted Mar 23, 2019 6:50 UTC (Sat) by flussence (guest, #85566)
Parent article: The congestion-notification conflict

I really like the cleverness of SCE. It's basically pulse-density modulation encoding, simple enough anyone can understand it. More importantly, downstreams can understand it without a full protocol stack dissector, which the other scheme seems to require. Isn't the whole point of modern networking techniques to get heavy lifting *out* of the hot path?

to post comments

The congestion-notification conflict

Posted Mar 24, 2019 19:57 UTC (Sun) by sourcejedi (guest, #45153) [Link] (3 responses)

"Details of how to implement SCE awareness at the transport layer will
be left to additional Internet Drafts yet to be submitted."

That is, SCE still wants support in the "transport layer" - such as TCP - to effectively echo back the SCE markings to the sender. Just like TCP with "classic ECN" (RFC 3168), or DCTCP. Otherwise, how would the sender of the packet notice that it needed to slow down?

I don't know why SCE was posted as an IETF draft without referencing "Accurate ECN". "Accurate ECN" aka AccECN, is an experimental TCP draft, which it says is required to implement L4S for TCP. It has been worked on since 2016. "Accurate ECN" was discussed on the bufferbloat.net lists during that time.

I think the AccECN TCP option is generic enough that SCE *could* use it unchanged. Although there is some limitation. The AccECN TCP option is optional and some middleboxes strip it (or block it? something like that anyway). AccECN has a fallback, which I think is only able to echo the ECN CE codepoint. L4S will still be able to work in the fallback mode. SCE congestion signals (ECN ECT(1) codepoint) would not get though in the fallback mode.

"Accurate ECN" also says it can be used to implement the "classic ECN" response to congestion. (I.e. 1 signal per RTT, which the sender treats as a if a packet was dropped, i.e. halves its transmission rate. If I understand correctly). I don't think it explains exactly how this is possible, but it is in good faith and I guess it is as simple as it sounds.

SCE does suggest that instead of echoing the SCE signal to the sender, it is also possible to handle it "entirely by the receiver". The submitted draft-00 suggests the reciever could tweak the receive window. OTOH, when this was politely challenged, Dave Taht said "I kind of wish we'd cut that from the draft".

https://lists.bufferbloat.net/pipermail/bloat/2019-March/...

The congestion-notification conflict

Posted Mar 29, 2019 0:56 UTC (Fri) by flussence (guest, #85566) [Link] (2 responses)

Correct me if I'm wrong here, as I understand it:

• SCE adds information in the IP header that higher layers in the network stack may use to back off from congestion (like BBR/FQ?)
• In L4S the higher layers already have the congestion information through some means, those set the bit in the IP layer as an extension signal, and it's up to receivers to understand that bit and introspect the rest of the packet to enqueue it properly?

The congestion-notification conflict

Posted Mar 29, 2019 21:32 UTC (Fri) by moeller0 (guest, #131181) [Link]

So my take on this is, SCE proposed to use a hitherto effectively unused codepoint in the 2bit ECN bitfield to send a pulsemodulated signal about the queueing load at a bottleneck equipped with an SCE aware AQM. It will still use RFC compliant tcp-friendly signals, CE marking or packetdrops, upon reaching full congestion so that all endpoints SCE-aware, ECN-CE-aware and plain old drop aware get as good a signal out of the bottleneck as they are willing to accept.

L4S now proposed to use the same codepoint to let flows promise the AQM that they will respond differently to CE marks than TCP-friendly flows. Specifically these flows promise not to interpret a CE mark as a strong signal to scale back their sending rate, but will look at the ratio of unmarked an CE-marked packets to get a pulsemodulated signal of the AQMs load/congestion state.
The challenge is that an AQM needs to know how flows are going to react to CE-marks to send the appropriate signal to each flow, otherwise the flows responding milder to CEs will suppress the ones with a strong response.

So in both cases the idea is to send a graded congestion signal so the endpoints can try to respond with more finesse than current TCPs with the binary congestion signal can. The main difference is how backward compatibility is handled. IMHO the SCE approach seems cleaner an more evolutionary than trying to press the ECT(1) codepoint into service as an identifier, as in the L4S approach endpoints never know whether a CE mark comes from an L4S AQM or from a traditional one due to the fact that ECT(1) will only identify packets that have not yet encountered congestion unambiguously...

The congestion-notification conflict

Posted Mar 29, 2019 22:25 UTC (Fri) by sourcejedi (guest, #45153) [Link]

I don't understand your description of L4S, or where it is coming from.

In both L4S and SCE, routers only operate on the IP header. They do not inspect or alter the IP payload, including TCP headers. The "higher layers" only run on the endpoints. L4S does not violate the normal layering rules in that sense.