Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

[Jonathan Morton <[e-mail]>]

> On 10 Mar, 2020, at 8:47 pm, Bob Briscoe <[e-mail]> wrote:
> 
>   This specification does not rule out the logical OR approach of RFC3168.
> .  So a tunnel egress MAY CE-mark a reassembled packet if any of
>    the fragments are CE-marked (and none are Not-ECT).  However, this
>    approach could result in reduced link utilization, or bias against
>    flows that are fragmented relative to those that are not.

As I have stated in the past on this subject, I disagree with this characterisation.  It misconstrues the meaning of CE and the definition of steady state involving it, both for conventional congestion control and for the high-fidelity version.  It also leads to a more complex reassembly implementation being "preferred" than is necessary, which may deter implementors.

For conventional congestion control, the steady state is defined in terms of the time interval (during which cwnd growth occurs) between RTTs containing at least one CE mark (and/or packet loss).  It is necessary for a single CE mark to be delivered promptly, ie. attached to the same packet as the marked fragment belonged to, in order to minimise growth overshoot and keep the control loop properly closed.  The control loop is not sensitive to the "proportion of bytes marked", only that a mark was encountered at a particular time.  It is well known, moreover, that adding delay to a control loop destabilises it - but this is exactly what an attempt to maintain the proportion of marked bytes would do.

For DCTCP-style congestion control, the steady state is defined in terms of the number of CE marks received per RTT.  Fragmentation does not change the RTT, only the number of packets passing a middlebox located on the tunnel path.  It would be reasonable to design an AQM expecting DCTCP traffic so that it produces exactly the correct number of CE marks per RTT at a particular queue depth.  But if the number of marks is effectively halved by a reassembly process that attempts to preserve the number of marked bytes, that queue will continue to grow past that designed ideal point.  We can therefore conclude that DCTCP is also insensitive to the proportion of marked bytes, and this is not a property worth preserving; rather, the total number of marked packets should be preserved.

Finally, I observe that Codel performs marking on a time schedule, not on a proportion of packets passing through.  This is entirely consistent with the above observations about transport behaviour, and further confirms the need to preserve the number of marked packets, not the proportion of marked bytes or packets.

The existing language in RFC-3168 succeeds in preserving the number of CE marks applied to a flow.  Any deficiencies we should consider are in relation to handling the distinction between ECT(1) and ECT(0), as this is what newly becomes significant with both the L4S and SCE proposals.

 - Jonathan Morton