The Some Congestion Experienced ECN CodepointBufferbloat.netKökkönranta 21PITKÄJÄRVI31520FINLAND+358 44 927 2377chromatix99@gmail.comTekLibre20600 Aldercroft Heights RdLos Gatos95033USACa+18312059740dave@taht.net
InternetTransport Working GroupThis memo reclassifies ECT(1) to be an early notification of
congestion on ECT(0) marked packets, which can be used by AQM
algorithms and transports as an earlier signal of congestion than
CE. It is a simple, transparent, and backward compatible upgrade to
existing IETF-approved AQMs, RFC3168, and nearly all congestion
control algorithms.The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in .This memo reclassifies ECT(1) to be an early notification of
congestion on ECT(0) marked packets, which can be used by AQM
algorithms and transports as an earlier signal of congestion than
CE ("Congestion Experienced").This memo limits its scope to the redefinition of the ECT(1)
codepoint as SCE, "Some Congestion Experienced", with a few brief
illustrations of how it may be used. defines the lower two bits of the (former) TOS byte in the IPv4/6 header as the ECN field. This may take four values: Not-ECT, ECT(0), ECT(1) or CE.Binary Keyword References------------------------------------------------------------Research has shown that the ECT(1) codepoint goes essentially unused,
with the "Nonce Sum" extension to ECN having not been implemented in
practice and thus subsequently obsoleted by (section
3). Additionally, known compliant senders do not emit
ECT(1), and compliant middleboxes do not alter the field to ECT(1),
while compliant receivers all interpret ECT(1) identically to ECT(0).
These are useful properties which represent an opportunity for
improvement.Experience gained with 7 years of deployment in the field
suggests that it remains difficult to maintain the desired 100% link
utilisation, whilst simultaneously strictly minimising induced delay
due to excess queue depth - irrespective of whether ECN is in use.
This leads to a reluctance amongst hardware vendors to implement the
most effective AQM schemes because their headline benchmarks are
throughput-based.The underlying cause is the very sharp "multiplicative decrease"
reaction required of transport protocols to congestion signalling
(whether that be packet loss or CE marks), which tends to leave the
congestion window significantly smaller than the ideal BDP when
triggered at only slightly above the ideal value. The availability of
this sharp response is required to assure network stability (AIMD
principle), but there is presently no standardised and
backwards-compatible means of providing a less drastic signal.As consensus has arisen that some form of ECN signaling should be an
earlier signal than drop, this Internet Draft changes the meaning of
ECT(1) to be SCE, meaning "Some Congestion Experienced". The above
ECN-field codepoint table then becomes:Binary Keyword References------------------------------------------------------------This permits middleboxes implementing AQM to signal incipient
congestion, below the threshold required to justify setting CE, by
converting some proportion of ECT codepoints to SCE ("SCE marking").
Existing compliant receivers MUST transparently ignore this new
signal, and both existing and SCE-aware middleboxes MAY convert SCE to
CE in the same circumstances as for ECT, thus ensuring backwards
compatibility with ECN endpoints.Permitted ECN codepoint packet transitions by middleboxes are:In other words, for ECN-aware flows, the ECN marking of an individual
packet MAY be increased by a middlebox to signal congestion, but MUST
NOT be decreased, and packets SHALL NOT be altered to appear to be
ECN-aware if they were not originally, nor vice versa. Note however
that SCE is numerically less than ECT, but semantically greater, and
the latter definition applies for this rule.New SCE-aware receivers and transport protocols SHALL continue to apply
the interpretation of the CE codepoint, that is, to signal
the sender to back off send rate to the same extent as if a packet
loss were detected. This maintains compatibility with existing
middleboxes, senders and receivers.New SCE-aware receivers and transport protocols SHOULD interpret the SCE
codepoint as an indication of mild congestion, and respond accordingly by
applying send rates intermediate between those resulting from a continuous
sequence of ECT codepoints, and those resulting from a CE codepoint. The
ratio of ECT and SCE codepoints received indicates the relative severity
of such congestion, such that 100% SCE is very close to the threshold of
CE marking, 100% ECT indicates that the bottleneck link may not be fully
utilised, and a 1:1 balance of ECT and SCE codepoints indicates that the
present send rate is a good match to the bottleneck link.Details of how to implement SCE awareness at the transport layer will
be left to additional Internet Drafts yet to be submitted.To maximise the benefit of SCE, middleboxes SHOULD produce SCE markings
sooner than they produce CE markings, when the level of congestion increases.Consider a TCP transport implementing CUBIC congestion control. This
presently exhibits exponential cwnd growth during slow-start,
polynomial cwnd growth in steady-state, and multiplicative decrease
upon detecting a single CE marking or packet loss in one RTT cycle.With SCE awareness, it might exit slow-start upon detecting a single
SCE marking, switch from polynomial to Reno-linear cwnd growth when
the SCE:ECT ratio exceeds 1:2, halt cwnd growth entirely when it
exceeds 1:1, and implement a Reno-linear decline when it exceeds 2:1,
in addition to retaining the sharp 40% decrease on detecting CE.In ideal circumstances, the above behaviour would result in the send
rate stabilising at a level which produces between 50% and 66% SCE
marking at some bottleneck on the path. The middlebox performing
this marking can thus control the send rate smoothly to an ideal value,
maximising throughput with minimum average queue length.SCE can potentially be handled entirely by the receiver and be
entirely independent of any of the dozens of compliant
congestion control algorithms, for example by manipulating the TCP
receive window in a similar manner to the sender's congestion window.Alternatively, some mechanism may be defined to feed back SCE signals
to the sender explicitly. Details of this are left to future I-Ds.New transports under development such as QUIC SHOULD implement a
multi-bit, sub-RTT, and finer grained signal back to the sender based on SCE.There are no IANA considerations.There are no security considerations.Many thanks to John Gilmore, the members of the ecn-sane project and the cake@lists.bufferbloat.net mailing list, and the former IETF AQM working group.