Subject: [tcpm] Comments on draft-ietf-tcpm-alternativebackoff-ecn-03

From: "Black, David" <[email-masked]>
Date: Wed, 15 Nov 2017 14:45:40 +0000

I volunteered to review this draft in Prague, so in classic "just before the deadline" IETF style, here are some comments.

The draft is applicable to use of AQM in general, but seems to limit its focus/analysis to modern AQM mechanisms such as PIE and CoDel.  Some broader discussion of older AQM mechanisms would be a good idea, although it may not be necessary to go all the way back to RED.
As part of that, this text at the end of Section 4.1:

           ([RFC7567<https://tools.ietf.org/html/rfc7567>] notes the current status of RED as an AQM method.)
should be strengthened to indicate that current usage of RED is limited.

--Section 3:

   This specification describes an update to the congestion control

   algorithm of an ECN-capable TCP transport protocol.  It allows a TCP

   stack to update the TCP sender response when it receives feedback

   indicating reception of a CE-marked packet.  It RECOMMENDS that a TCP

   sender multiplies the slow start threshold (ssthresh) by 0.8 times of

   the FlightSize (with its minimum value set to 2 * SMSS) and reduces

   the cwnd in congestion avoidance following reception of a TCP segment

   that sets the ECN-Echo flag (defined in [RFC3168<https://tools.ietf.org/html/rfc3168>]).

This text has several problems including:
               - it's not clear what the update is
               - "allows" is too weak a verb
               - "RECOMMENDS" is not an RFC 2119 keyword

Attempted rewrite, including additional editorial changes:

   This specification updates the congestion control

   algorithm of an ECN-capable TCP transport protocol by changing the

   the TCP sender response to feedback from the TCP receiver that

   indicates reception of a CE-marked packet, i.e., receipt of a packet

   with the ECN-Echo flag (defined in [RFC3168<https://tools.ietf.org/html/rfc3168>]) set.  The updated

   TCP sender response specification is that the slow

   start threshold (ssthresh) SHOULD be multiplied by 0.8 times

   the FlightSize with the result increased to the minimum ssthresh

   value of 2 * SMSS if necessary.  The TCP sender also reduces the

   the cwnd value to that new ssthresh value.

In Section 4.3, the text is not clear that the same cwnd reduction applies to both ECN and packet loss.

Section 5:

OLD

   The currently published ECN specification requires that the

   congestion control response to a CE-marked packet is the same as the

   response to a dropped packet [RFC3168<https://tools.ietf.org/html/rfc3168>].  The specification is

   currently being updated to allow for specifications that do not

   follow this rule [I-D.ECN-exp<https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-03#ref-I-D.ECN-exp>].  The present specification defines

   such an experiment and has thus been assigned an Experimental status

   before being proposed as a Standards-Track update.
NEW

   The original ECN specification, RFC 3168 [RFC3168], required that the

   congestion control response to a CE-marked packet be the same as the

   response to a dropped packet [RFC3168<https://tools.ietf.org/html/rfc3168>].  That requirement has been

   relaxed by RFC YYYY [I-D.ECN-exp<https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-03#ref-I-D.ECN-exp>] to enable experimentation with different

   congestion control responses.  The present specification is one such

   experiment; if the experiment succeeds, the changed congestion control

   response will be published in a standards track RFC to encourage deployment.

In:

   To evaluate the benefit, this experiment therefore requires support

   in AQM routers (except to enable an ECN-marking mechanism [RFC3168<https://tools.ietf.org/html/rfc3168>]

   [RFC7567<https://tools.ietf.org/html/rfc7567>]) for ECN-marking of packets carrying the ECN Capable

   Transport, ECT(0), codepoint [RFC3168<https://tools.ietf.org/html/rfc3168>].

I don't understand the parenthetical "(except to ...)" text - can that just be deleted?

Thanks, --David
----------------------------------------------------------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953    Mobile: +1 (978) 394-7754
[email-masked]<mailto:[email-masked]>
----------------------------------------------------------------

---

From: "Black, David" <[email-masked]>
Date: Thu, 16 Nov 2017 01:15:59 +0000

Updating to -04 inline ...

Thanks, --David

From: Black, David
Sent: Wednesday, November 15, 2017 9:46 AM
To: [email-masked]
Cc: Black, David <[email-masked]>
Subject: Comments on draft-ietf-tcpm-alternativebackoff-ecn-03

           ([RFC7567<https://tools.ietf.org/html/rfc7567>] notes the current status of RED as an AQM method.)
should be strengthened to indicate that current usage of RED is limited.
[David>] Still the case - both the scope of AQMs considered and the specific language about RED.

--Section 3:

[David>] Still the case, although the original text has been slightly edited in -04.

In Section 4.3, the text is not clear that the same cwnd reduction applies to both ECN and packet loss.
[David>] Still the case - it's not clear whether "cwnd = ssthresh" applies to both preceding assignments or just the immediately preceding one.

Section 5:

OLD

[David>] Fixed in -04 w/different text.

In:

I don't understand the parenthetical "(except to ...)" text - can that just be deleted?
[David>] Still a concern in -04.

Thanks, --David