[Ecn-sane] IETF 110 quick summary

[Jonathan Morton]

> On 9 Mar, 2021, at 8:44 pm, Holland, Jake <jholland at akamai.com> wrote:
> 
> …classic ECN traffic will not respond as quickly as L4S…

I know it wasn't you making this claim, Jake, but I have to point out that it's completely false.  Classic ECN transports actually respond *more* quickly to a CE mark than L4S transports.

Let's walk through the processes.


RFC-3168 TCP:

A single CE mark is applied to a data segment.
The receiver immediately sends an ACK with ECE set, and keeps ECE set on all further ACKs until a CWR cancels it.
The sender gets the ECE, reduces the cwnd immediately, and sends the next data segment with CWR set to confirm it.
Proportional Rate Reduction may be used to spread out the reduction in actual in-flight data.  This takes at most one RTT.

From the queue's perspective, one RTT (the minimum possible) elapses before the arrival rate from the sender halves (due to PRR).  After two RTTs maximum, the in-flight data has reached a new, substantially lower value than the original.


L4S TCP (Prague):

A single CE mark is applied to a data segment.
The receiver updates the CE mark counter in the next ACK.
The sender sees the new counter value, and feeds it into a low-pass filter which operates on discrete time intervals.
When the filter is next processed, on average a single CE mark results in half a segment being removed from the cwnd.  Half the time, this results in no externally visible change to the data in flight.  The other half, it is a very slight response.

From the queue's perspective, one RTT plus (on average) half the filter window passes before any possible response reaches it, and half the time it's no response anyway, the other half a single segment reduction.  Meanwhile, at least one segment has been added to the cwnd in the RTT-plus time since the mark was applied (due to Reno-style growth).


I do not see how TCP Prague's response can be described as "faster" than that of standard TCP.

 - Jonathan Morton