Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-13.txt

From: [email-masked]
Date: Mon, 22 Feb 2021 14:01:03 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.

        Title           : Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay (L4S)
        Authors         : Koen De Schepper
                          Bob Briscoe
	Filename        : draft-ietf-tsvwg-ecn-l4s-id-13.txt
	Pages           : 58
	Date            : 2021-02-22

Abstract:
   This specification defines the identifier to be used on IP packets
   for a new network service called low latency, low loss and scalable
   throughput (L4S).  L4S uses an Explicit Congestion Notification (ECN)
   scheme that is similar to the original (or 'Classic') ECN approach.
   'Classic' ECN marking was required to be equivalent to a drop, both
   when applied in the network and when responded to by a transport.
   Unlike 'Classic' ECN marking, for packets carrying the L4S
   identifier, the network applies marking more immediately and more
   aggressively than drop, and the transport response to each mark is
   reduced and smoothed relative to that for drop.  The two changes
   counterbalance each other so that the throughput of an L4S flow will
   be roughly the same as a non-L4S flow under the same conditions.
   Nonetheless, the much more frequent control signals and the finer
   responses to them result in much more fine-grained adjustments, so
   that ultra-low and consistently low queuing delay (typically sub-
   millisecond on average) becomes possible for L4S traffic without
   compromising link utilization.  Thus even capacity-seeking (TCP-like)
   traffic can have high bandwidth and very low delay at the same time,
   even during periods of high traffic load.

   The L4S identifier defined in this document distinguishes L4S from
   'Classic' (e.g. TCP-Reno-friendly) traffic.  It gives an incremental
   migration path so that suitably modified network bottlenecks can
   distinguish and isolate existing traffic that still follows the
   Classic behaviour, to prevent it degrading the low queuing delay and
   low loss of L4S traffic.  This specification defines the rules that
   L4S transports and network elements need to follow to ensure they
   neither harm each other's performance nor that of Classic traffic.
   Examples of new active queue management (AQM) marking algorithms and
   examples of new transports (whether TCP-like or real-time) are
   specified separately.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-13
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-l4s-id-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Asad Sajjad Ahmed <[email-masked]>
Date: Thu, 25 Feb 2021 21:06:02 +0100

Bob,

Thanks for updating and for have put in a lot of effort into this draft. 
I have a minor comment regarding the cwnd reduction over ECN when cwnd 
is already very low:

Current draft gives a formal requirement: 

§4.3: 
     "A scalable congestion control SHOULD remain responsive to
      congestion when typical RTTs over the public Internet are
      significantly smaller because they are no longer inflated by
      queuing delay.  It would be preferable for the minimum window of a
      scalable congestion control to be lower than the 2 segment minimum
      of TCP Reno [RFC5681] but this is not set as a formal requirement
      for L4S experiments (see Appendix A.1.6 for rationale)."

§A.1.6: 
    "However, the requirement in Section 4.3 is worded as a "SHOULD"
     because the existence of a minimum window is not all bad.  When
     competing with an unresponsive flow, a minimum window naturally
     protects the flow from starvation by at least keeping some data
     flowing."

But, this contradict with RFC3168 (PS):

§6.1.2:
    "[...] Therefore, the sending TCP MUST reset the
     retransmit timer on receiving the ECN-Echo packet when the congestion
     window is one.  The sending TCP will then be able to send a new
     packet only when the retransmit timer expires."

The contradiction here is "SHOULD" vs. "MUST". Also TCP CC, as given out by 
RFC5681, does NOT mandate a minimum transmission rate. TCP's loss recovery at 
low cwnd relies on RTO to recover lost segments and TCP using ECN is supposed 
to mimic this behavior [floyd98]. Otherwise, you risk starving the Not-ECT set 
of flow, driving up the queue and increasing the marking probability by going 
unresponsive at cwnd of two segments. This is about harm toward other traffic 
so it make no sense to relax a formal "MUST". Of couse, it is desireable
that the AQM take action and evict packets from non-responsive flows, but
this is not true for all AQM, one example being CoDel.

But, the minimum cwnd of 2 does not originate from L4S, but has been
the current practice for a very long time at least under the Linux TCP stack.
This, obviously, also needs to be addressed.

Asad

[floyd98] http://www.icir.org/floyd/papers/ecnsims.pdf (§8)

-- 
Asad