Re: [tcpm] I-D Action: draft-ietf-tcpm-alternativebackoff-ecn-05.txt

[Naeem Khademi <[e-mail]>]

Hi tcpm chairs, all

We have now incorporated all the changes requested by the three reviewers
volunteered to review the draft in the IETF Prague. The current draft *(-05)
*addresses D. Black's review comments in addition to the comments we
received during the TCPM session in Singapore.


   - Response to R. Bless: https://www.ietf.org/mail-arch
   ive/web/tcpm/current/msg11125.html
   <https://www.ietf.org/mail-archive/web/tcpm/current/msg11125.html>
   - Response to L. Stewart: https://www.ietf.org/mail-arch
   ive/web/tcpm/current/msg11124.html
   <https://www.ietf.org/mail-archive/web/tcpm/current/msg11124.html>
   - Response to D. Black: at the very bottom of this email!


If the chairs and reviewers are happy with the current shape of the draft,
we'd be happy to ask the chairs to initiate a WGLC.

Cheers,
Naeem


On Tue, Dec 12, 2017 at 12:00 AM, <[e-mail]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the TCP Maintenance and Minor Extensions WG
> of the IETF.
>
>         Title           : TCP Alternative Backoff with ECN (ABE)
>         Authors         : Naeem Khademi
>                           Michael Welzl
>                           Grenville Armitage
>                           Godred Fairhurst
>         Filename        : draft-ietf-tcpm-alternativebackoff-ecn-05.txt
>         Pages           : 13
>         Date            : 2017-12-11
>
> Abstract:
>    Recent Active Queue Management (AQM) mechanisms allow for burst
>    tolerance while enforcing short queues to minimise the time that
>    packets spend enqueued at a bottleneck.  This can cause noticeable
>    performance degradation for TCP connections traversing such a
>    bottleneck, especially if there are only a few flows or their
>    bandwidth-delay-product is large.  An Explicit Congestion
>    Notification (ECN) signal indicates that an AQM mechanism is used at
>    the bottleneck, and therefore the bottleneck network queue is likely
>    to be short.  This document therefore proposes an update to RFC3168,
>    which changes the TCP sender-side ECN reaction in congestion
>    avoidance to reduce the Congestion Window (cwnd) by a smaller amount
>    than the congestion control algorithm's reaction to inferred packet
>    loss.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-05
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-altern
> ativebackoff-ecn-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-alternativ
> ebackoff-ecn-05
>
>
> 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/



*--------------------------------------- David's black review and response
--------------------------------------- *

*---------------------------------------------------------------------------------------------------------------------------------*

Updating to -04 inline …



Thanks, --David



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



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.

*[David>] Still the case – both the scope of AQMs considered and the
specific language about RED.*


*[Authors>] We changed the sentence about RED; as for being applicable to
use with AQMs in general, the way we discuss PIE and CoDel is by way of
mentioning that mechanisms "such as these" try to keep the queue small.
This is really the context and justification for ABE. In the part
describing the experiment, we have added a sentence to explain why we don't
think that ABE would be problematic with AQM algorithms that do NOT try to
keep the average queue length particularly small.*


--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

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

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.


 *[Authors>] Thanks a lot for this, we used your text but changed it a tiny
bit **(ssthresh isn't multipled by 0.8*FlightSize but set to it, and we
say **", with a lower bound of 2 * SMSS applied to the result") because
that seemed **even clearer to us.*


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.*


*[Authors>] It should only be the immediately preceding one. We believe
that this misunderstanding was caused by the bad indentation - we changed
the indentation and believe that this looks clear enough now.*



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.

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



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?

*[David>] Still a concern in -04.*


*[Authors>] Done*



Thanks, --David

----------------------------------------------------------------

David L. Black, Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

[phone] <+1%20508-293-7953>    Mobile: [phone]
<+1%20978-394-7754>

[e-mail]

----------------------------------------------------------------