Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A16612704B for ; Wed, 13 Dec 2017 10:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXMUGr3rci8e for ; Wed, 13 Dec 2017 10:11:39 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B251200C1 for ; Wed, 13 Dec 2017 10:11:38 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id h28so1474583ybj.5 for ; Wed, 13 Dec 2017 10:11:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iPZ6rKDziS0PIXexURKKdDmhx3DzzdC4GIE3oKFyupQ=; b=mRr7otJkpv8Obk+wgo+5QZ8WooQqkPYDLNdsOqQ0Lkf86lCw0ms3dz38JXjGQ53aYr x97AOU/+fQK+ZljD/49i8mq+mtUsfIB5OTPWtHzUG1dO0E9w8ZSOo/43lIfPGR28Bgex cMn6XDV22mJDWHxyNYxtTeOKIAI3TwpkWn3q6375Tz/0nRWWEs9LNwtmcEfl3ChlPXnY ++WhQ/xBrZxMCt2pyNNwADnPeWoirIPZ+ivmPJmkdnLGfdrNXv88c2hG4yHfJWm4Or+7 vNFZCy+wIX9gFv7Ixd7T5ywtOFAvjSrvJCu8HaSr6vXL9xL9xmj2E31ooWvHx1gpLEQa 0HlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=iPZ6rKDziS0PIXexURKKdDmhx3DzzdC4GIE3oKFyupQ=; b=VxSNbzh/1Fa6BS7GWvCL/yuGI5R/437HdMrZFqIElEOTDWxSa/9rwmNXC8cj5R7T7O HX13k3kYjEg2uzgJPDhpN6V/V1vOyq0tVBY+gzilPNkLoQzxiIfvfX1ogtS0LidcUxC7 mmBnKFqUsllX8CLDrepFG3lNyxDZ4iEfDj7c7i0YlhJxrnCXJM0SKinb4PR3v2wjqV5c +v3oRHZ2L1DqiS2W3MMmSlabrh+qeBWHsGFDvs4PwLnNE81VAppwx+L0QJYoQdcpGxza 7PIYB9tZ2aAZWTWPzI8l5BZrsVSSIiJoQaD+yZsHCAPMkSvrrcwgrRWAqDeouJBYneey 2hpw== X-Gm-Message-State: AKGB3mLG6hKweY9cQMMf8U8vJuA1V/N9V2gSAvElkPNphJQzt9Try1Tq ZoQ9GvY3AoevrpGBUVKE60upHbpxU5UF4rNZi1gfQ9zR X-Google-Smtp-Source: ACJfBot0nB75hIxufAhE9jixMEl+g6Bq08pQsguCbNY3bqmcCWcwCcJ/ADO1xXp9tpX6weaUWarHImOKdzkA8AB1T7w= X-Received: by 10.129.34.9 with SMTP id i9mr2288842ywi.283.1513188697394; Wed, 13 Dec 2017 10:11:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.248.3 with HTTP; Wed, 13 Dec 2017 10:11:36 -0800 (PST) In-Reply-To: <151303323793.20401.1192020346334587892@ietfa.amsl.com> References: <151303323793.20401.1192020346334587892@ietfa.amsl.com> From: Naeem Khademi Date: Wed, 13 Dec 2017 19:11:36 +0100 Message-ID: To: tcpm@ietf.org Content-Type: multipart/alternative; boundary="001a113dbea6c957a105603cb28b" Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-alternativebackoff-ecn-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 18:11:42 -0000 --001a113dbea6c957a105603cb28b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 - Response to L. Stewart: https://www.ietf.org/mail-arch ive/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, 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=3Ddraft-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 =E2=80=A6 Thanks, --David *From:* Black, David *Sent:* Wednesday, November 15, 2017 9:46 AM *To:* tcpm@ietf.org *Cc:* Black, David *Subject:* Comments on draft-ietf-tcpm-alternativebackoff-ecn-03 I volunteered to review this draft in Prague, so in classic =E2=80=9Cjust b= efore the deadline=E2=80=9D 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 ] 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 =E2=80=93 both the scope of AQMs considered and th= e 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 ]). This text has several problems including: - it=E2=80=99s not clear what the update is - =E2=80=9Callows=E2=80=9D is too weak a verb - =E2=80=9CRECOMMENDS=E2=80=9D 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 ]) 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 =E2=80=93 it=E2=80=99s not clear whether =E2=80=9C= cwnd =3D ssthresh=E2=80=9D 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 ]. The specification is currently being updated to allow for specifications that do not follow this rule [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 ]. That requirement has been relaxed by RFC YYYY [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 deploym= ent. *[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 ] [RFC7567 ]) for ECN-marking of packets carrying the ECN Capable Transport, ECT(0), codepoint [RFC3168 ]. I don=E2=80=99t understand the parenthetical =E2=80=9C(except to =E2=80=A6)= =E2=80=9D text =E2=80=93 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 +1 (508) 293-7953 <+1%20508-293-7953> Mobile: +1 (978) 394-7754 <+1%20978-394-7754> David.Black@dell.com ---------------------------------------------------------------- --001a113dbea6c957a105603cb28b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 comment= s we received during the TCPM session in Singapore.=C2=A0

  • Response to R. Bless: https://www.ietf.org/mail-ar= chive/web/tcpm/current/msg11125.html
  • Response to = L. Stewart: https://www.ietf.org/mail-archive/web/= tcpm/current/msg11124.html
  • Response to D. Black: at th= e very bottom of this email!=C2=A0

    • 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

    <= br>
    On Tue, Dec 12, 2017 at 12:00 AM, <= internet-drafts@ietf.org> wrote:

    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    This draft is a work item of the TCP Maintenance and Minor Extensions WG of= the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= TCP Alternative Backoff with ECN (ABE)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Naee= m Khademi
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael Welzl
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Grenville Armitage
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Godred Fairhurst
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tcpm-alternativebackoff-ecn-05.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 13
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-12-11

    Abstract:
    =C2=A0 =C2=A0Recent Active Queue Management (AQM) mechanisms allow for burs= t
    =C2=A0 =C2=A0tolerance while enforcing short queues to minimise the time th= at
    =C2=A0 =C2=A0packets spend enqueued at a bottleneck.=C2=A0 This can cause n= oticeable
    =C2=A0 =C2=A0performance degradation for TCP connections traversing such a<= br> =C2=A0 =C2=A0bottleneck, especially if there are only a few flows or their<= br> =C2=A0 =C2=A0bandwidth-delay-product is large.=C2=A0 An Explicit Congestion=
    =C2=A0 =C2=A0Notification (ECN) signal indicates that an AQM mechanism is u= sed at
    =C2=A0 =C2=A0the bottleneck, and therefore the bottleneck network queue is = likely
    =C2=A0 =C2=A0to be short.=C2=A0 This document therefore proposes an update = to RFC3168,
    =C2=A0 =C2=A0which changes the TCP sender-side ECN reaction in congestion =C2=A0 =C2=A0avoidance to reduce the Congestion Window (cwnd) by a smaller = amount
    =C2=A0 =C2=A0than the congestion control algorithm's reaction to inferr= ed packet
    =C2=A0 =C2=A0loss.


    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/dr<= wbr>aft-ietf-tcpm-alternativebackoff-ecn-05
    https://datatracker.i= etf.org/doc/html/draft-ietf-tcpm-alternativebackoff-ecn-05
    A diff from the previous version is available at:
    https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-tcpm-alternativebackoff-ecn-05


    Please note that it may take a couple of minutes from the time of submissio= n
    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/
    = =C2=A0

    ----------------= ----------------------- David's black review and response --------= -------------------------------=C2=A0
    ------------------------------------------------------= -----------------------------------------------------------------= ----------

    =C2=A0

    Thanks, --David

    =C2=A0

    From:=C2=A0Black, David= =C2=A0
    Sent:=C2=A0Wednesday, November 15, 2017 9:46 AM
    To:<= /b>=C2=A0tcpm@ietf.org
    Cc:=C2=A0Black, D= avid <david.bla= ck@emc.com>
    Subject:=C2=A0Comments on=C2=A0draft-ietf-tcpm-alternativebackoff-ecn-03

    =C2=A0

    I volunteered to rev= iew this=C2=A0draft=C2=A0in Prague, so in classic =E2=80=9Cjust before the deadline=E2=80= =9D=C2=A0IETF= =C2=A0style, here are some comments.

    =C2=A0

    The=C2=A0draft=C2=A0is applicable to use of AQM = in general, but seems to limit its focus/analysis to modern AQM mechanisms = such as PIE and CoDel.=C2=A0 Some broader discussion of older AQM mechanism= s 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:= 

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =C2=A0=C2=A0 ([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 =E2=80=93 both the scope of AQMs consi= dered and the specific language about RED.

    [Authors&g= t;] 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 t= hat 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 tha= t ABE would be problematic with AQM algorithms that do NOT try to keep the = average queue length particularly small.


    =

    --Section 3:

    =C2=A0
    <= pre style=3D"white-space:pre-wrap;margin:0in 0in 0.0001pt;font-size:10pt;fo= nt-family:"Courier New"">=C2=A0=C2=A0 This specification describe= s an update to the congestion control
    =C2=A0=C2=A0 algorithm of an ECN-capable TCP transport protocol.=C2=A0 I=
t allows a TCP
    =C2=
=A0=C2=A0 stack to update the TCP sender response when it receives feedback=

    =C2=A0=C2=A0 indica=
ting reception of a CE-marked packet.=C2=A0 It RECOMMENDS that a TCP=

    =C2=A0=C2=A0 sender multip=
lies the slow start threshold (ssthresh) by 0.8 times of
    =C2=A0=C2=A0 the FlightSize (with its =
minimum value set to 2 * SMSS) and reduces
    =C2=A0=C2=A0 the cwnd in congestion avoidance follow=
ing reception of a TCP segment
    =C2=A0=C2=A0 that sets the ECN-Echo flag (defined in [RFC3168]). <=
/u>
    =
=C2=A0
    T=
his text has several problems including:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - it=E2=80=99s not clea=
r what the update is
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - =E2=80=9Callows=E2=80=9D is too weak a ver=
b
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 - =E2=80=9CRECOMMENDS=E2=80=9D is not an RFC 2119 keyword
    [Da=
vid>] Still the case, although the original text has been slightly edite=
d in -04.=C2=A0
    <=
span class=3D"gmail-m_-3685518265920168058gmail-im" style=3D"font-size:12.8=
px">
    Attempted rewrite, in=
cluding additional editorial changes:
    =C2=A0
    =C2=A0=C2=A0 This specification updates the congestio=
n control
    =C2=A0=C2=
=A0 algorithm of an EC=
N-capable TCP transport protocol by changing the
    =

    =C2=A0=C2=A0 the TCP sender response to=
 feedback from the TCP receiver that
    =C2=A0=C2=A0 indicates reception of a CE-marked packet, i.=
e., receipt of a packet
    =C2=A0=C2=A0 with the ECN-Echo flag (defined in [RFC3168]) set.=C2=A0 The updated
    =C2=A0=C2=A0 TCP send=
er response specification is that the slow
    =C2=A0=C2=A0 start threshold (ssthresh) SHOULD be mu=
ltiplied by 0.8 times
    =C2=A0=C2=A0 va=
lue of 2 * SMSS if necessary.=C2=A0 The TCP sender also reduces the =

    =C2=A0=C2=A0=C2=A0the cwnd=
 value to that new ssthresh value.

    =C2=A0[Auth=
ors>] Thanks a lot for this, we used your text but changed it a tiny bit=
=C2=A0(ssthresh isn't multipled by 0.8*FlightSize but set to it, and we sa=
y=C2=A0", with a lower bound of 2 * SMSS applied to the result") bec=
ause that seemed=C2=A0even clearer to us.

    In Section 4.3, the text is not clear that the sa=
me cwnd reduction applies to both=C2=A0ECN=C2=A0and packet loss.
    <=
p class=3D"gmail-m_-3685518265920168058gmail-MsoNormal" style=3D"font-size:=
12.8px">[David>] Still the ca=
se =E2=80=93 it=E2=80=99s not clear whether =E2=80=9Ccwnd =3D ssthresh=E2=
=80=9D applies to both preceding assignments or just the immediately preced=
ing 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.
    =C2=A0
    Section 5:
    =C2=A0
    OLD
    =C2=A0=C2=A0 The currently published ECN specification requires that the=

    =C2=A0=C2=A0 conges=
tion control response to a CE-marked packet is the same as the
    =C2=A0=C2=A0 response to a dropp=
ed packet [RFC3168].=C2=A0 The specification is
    =C2=A0=C2=A0 currently being updated to al=
low for specifications that do not
    =C2=A0=C2=A0 follow this rule [I-D.ECN-exp].=C2=A0 The present specification defines
    <= pre style=3D"white-space:pre-wrap;margin:0in 0in 0.0001pt;font-size:10pt;fo= nt-family:"Courier New"">=C2=A0=C2=A0 such an experiment and has = thus been assigned an Experimental status
    =C2=A0=C2=A0 before being proposed as a Standards-Tra=
ck update.

    NEW

    =C2=A0=
=C2=A0 The original EC=
N specification, RFC 3168 [RFC3168], required that the=

    =C2=A0=C2=A0 congestion control r=
esponse to a CE-marked packet be the same as the
    =C2=A0=C2=A0 response to a dropped packet [RFC3=
168].=C2=A0 That requirement has been
    =C2=A0=C2=A0 relaxed by RFC YYYY [I-D.ECN-exp] to enable experimentation with different<=
/u>
    =C2=A0=C2=A0 congestion contro=
l responses.=C2=A0 The present specification is one such
    =C2=A0=C2=A0 experiment; if the experi=
ment succeeds, the changed congestion control
    =C2=A0=C2=A0 response will be published in a stan=
dards track RFC to encourage deployment.
    [David>] Fixed in -04 w/differ=
ent text.
    =C2=A0
    In:
    =C2=A0=

    =C2=A0=C2=A0 To evaluate the benefi=
t, this experiment therefore requires support
    =C2=A0=C2=A0 in AQM routers (except to enable an =
ECN-marking mec=
hanism [RFC3168]
    =
=C2=A0=C2=A0 [RFC7567]) for ECN-marking of packets carrying the ECN Capable
    =C2=A0=C2=A0 Transport, ECT(0), codepoint [RFC3168<=
/a>].
    =C2=A0
    I don=E2=80=99t understand the parenthetical =E2=80=9C(except =
to =E2=80=A6)=E2=80=9D text =E2=80=93 can that just be deleted?
    [David>] Still a concern in -04.
    [Authors>] Done
    =C2=A0
    Thanks, --David
    ------------------------=
----------------------------------------
    David L. Black, Distingui=
shed Engineer
    Dell EMC, 176 South St., Hopkinton, MA=C2=A0=C2=A001748
    <=
p class=3D"gmail-m_-3685518265920168058gmail-MsoNormal">+1 (508) 293-7953=C2=A0=C2=A0=C2=A0 Mobile:=C2=A0+1 (978) 394-7754
    =

    David.Black@dell.com<=
/u>
    -----------=
-----------------------------------------------------
    <=
/div>
    --001a113dbea6c957a105603cb28b--