Re: [tcpm] Summary of updates in draft-ietf-tcpm-accurate-ecn-17

Yoshifumi Nishida <nsd.ietf@gmail.com> Sun, 20 March 2022 09:50 UTC

Return-Path: <nsd.ietf@gmail.com>
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 9B0EF3A115A for <tcpm@ietfa.amsl.com>; Sun, 20 Mar 2022 02:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 qjWYG7CYLiKY for <tcpm@ietfa.amsl.com>; Sun, 20 Mar 2022 02:50:41 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 C74EB3A114C for <tcpm@ietf.org>; Sun, 20 Mar 2022 02:50:40 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id j18so7516704wrd.6 for <tcpm@ietf.org>; Sun, 20 Mar 2022 02:50:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jMakE7jWFBw6m2aey4LgMs/oDwzLjI+rK6VFIQvPMYQ=; b=ODJapQkA0s6vvzymi4y9msyZSylawGnPnMHR1F8dwvheGAI/RnQRa66FOJmnAU9whc 82sch5vdH0G8LeW0gQWTIw1sWogUcRvvPDqETexIxvnz1s9THbhKCUI4/3Iprsp9TQGq /7zdGeEjKCRyvvxSl/19m7EuOFbuzsPujnsJCXu3G6JzktkQnTpqBLGl3Es0gOGNwEsu ZYPDxQ/ckZdabW77jeYZna3YVExmpxEYu0f+6olOyKVAP8/yWM7rifxokGK5o6Kfb7eT u/ElqoAsq6+Y+J3o83oE1C6ymrD4WTzPM9KtnSMek2wUeMr0Z3ivzNW3hTdl72pnQfQT jVGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jMakE7jWFBw6m2aey4LgMs/oDwzLjI+rK6VFIQvPMYQ=; b=HNeQjzwQ7W1JF5qn4quRDgNyuMssG+kxDoME2ay8lMUutjIpVBLt1e55w554FMiPTN N6WqKSfvyA/GUSi5HJ2IQjBvbRuPNX2B29GB5AknFEegkQqOCLb0L00PNxGpn1n2trlq 3vU3UYqEkqtY+qayJvpuEIYztux93NPkKUh3UOR9t6Ga8gFRY8HsLwu88cMWfV+vnAn2 lsKeoiAIm1vX/JqolytcXL1mbvWovwMhNilLHufaKw0GvkkQDlVdhcygN/HKYtVnrcBA SEZPQEyWJlVcwUc4iB0uSSHBcuqGsHRBBcAg4dXhWLg9g8lXyXIieK9CPUWIpiGmtXOK PUOA==
X-Gm-Message-State: AOAM531CsFzZ0lEbbQANSM3ljOb74zcTVE1axfU/M4HP0APUoTHhgZkP ihzoC1s5dxujq0Xo5vw5GP2gFrpy4p4TPSfLSkim2BMiS/U=
X-Google-Smtp-Source: ABdhPJzYYjZpYZYQwJ7v9am1waxi53cUHuWYl2zw0HpEJytsFDWRw9tL5cMpTvKqXiz6A+De5uxYArSJD6LsqAMvAQI=
X-Received: by 2002:adf:fbcf:0:b0:204:61b:2c4b with SMTP id d15-20020adffbcf000000b00204061b2c4bmr3321167wrs.125.1647769838873; Sun, 20 Mar 2022 02:50:38 -0700 (PDT)
MIME-Version: 1.0
References: <164669506897.29288.5626108129531513971@ietfa.amsl.com> <2603fe69-5d17-f23b-53cb-b69690673f7d@bobbriscoe.net>
In-Reply-To: <2603fe69-5d17-f23b-53cb-b69690673f7d@bobbriscoe.net>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Sun, 20 Mar 2022 02:50:27 -0700
Message-ID: <CAAK044TktHx7pKmv1F=BbFaqdfAdjpE_YT=FJf_yfi1AeFHRAg@mail.gmail.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eaf05905daa34f74"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/rWD3L53_g-tt-CgOzPEYi7IosSA>
Subject: Re: [tcpm] Summary of updates in draft-ietf-tcpm-accurate-ecn-17
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Mar 2022 09:50:46 -0000

Hi Bob,

   - 'that acknowledges new data' -> 'if any byte counter has incremented
   since the last ACK' {*includes new markings on retransmssions*}

Does this mean when you retransmit a packet, the acc option in the packet
should be updated to contain the latest info?
If we do this, wouldn't it be hard for the receivers to tell which packet
contains the most recent info when there's reordering?
--
Yoshi

On Mon, Mar 7, 2022 at 3:26 PM Bob Briscoe <ietf@bobbriscoe.net> wrote:

> tcpm-ers,
>
> The AccECN draft has just been updated to roll up all the changes over the
> last month since draft-16 (3 Feb 22).
>     https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn
> All the changes have already been discussed on this list, but they are
> enumerated below for convenience. The last normative change below about ACK
> filtering has been discussed before, but the precise wording hasn't been
> posted to the list until now.
>
> As always, the full diff can be accessed from the datatracker (via the
> above link).
>
> Normative (Changes intended to make a technical difference are *in bold*)
>
>    - §3.1.1
>    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-3.1.1>:
>    Negotiation during the TCP handshake
>    Reordered the requirements for feeding back the incoming IP-ECN field
>    on the SYN-ACK to make more sense {no technical change, just clearer}
>    - §3.2
>    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-3.2>:
>    AccECN Feedback
>    made "MUST increment byte counters" conditional on support for sending
>    of the AccECN TCP Option
>    - §3.2.2.3
>    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-3.2.2.3>:
>    Testing for Mangling of the IP/ECN Field
>    If continuous CE-marking is detected, Data Sende:
>       - SHOULD NOT send ECN-capable packets and *then SHOULD NOT respond
>       to any ECN feedback* {added second part of this requirement}
>       - *Throughout, it MUST remain in the AccECN feedback mode*
>       {additional requirement}
>       - and it MUST continue to feed back any ECN markings on arriving
>       packets (in its role as Data Receiver) {just reworded a bit}
>    - §3.2.2.5.1
>    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-3.2.2.5.1>:
>    Data Receiver Safety Procedures
>    Increment-Triggered ACKs:
>    - Clarified that the condition about 'new data' means 'newly delivered
>       data' {no difference in meaning, just clearer}
>       - Changed to 'In either case, *'n' MUST be no greater than 7*.'
>       (was 6)
>    - §3.2.3.3
>    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-3.2.3.3>:
>    Usage of the AccECN TCP Option
>    Condition for 'SHOULD include an AccECN TCP Option on every scheduled
>    ACK':
>       - 'that acknowledges new data' -> 'if any byte counter has
>       incremented since the last ACK' {*includes new markings on
>       retransmssions*}
>    - §3.3.3
>    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-3.3.3>:
>    Requirements for TCP ACK Filtering
>       - 'SHOULD preserve the correct operation of AccECN feedback' {*previously
>       it described how this SHOULD be done, now it just gives the high level
>       requirement*}
>
>
> Technical
>
>    - §3.2.1
>    <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html#section-3.2.1>:
>    Initialization of Feedback Counters
>    Made initialization of ECT(1) feedback counter r.e1b the same as
>    r.e0b, now that we have the two different TCP Option orders.
>
>
> Editorial
>
>    - Made other parts of the spec consistent with the above changes
>    - Called out the updates to other RFCs in the abstract
>    - Increased depth of table of contents to 4 (was 3)
>    - Added titles to all tables (xml2rfc now adds a 'Table xx' caption to
>    the HTML rendering whether or not there is a caption title, and even if
>    suppress-title=true i enabled).
>    - Other minor edits
>
>
>
> Bob
>
> On 07/03/2022 23:17, internet-drafts@ietf.org 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           : More Accurate ECN Feedback in TCP
>         Authors         : Bob Briscoe
>                           Mirja Kühlewind
>                           Richard Scheffenegger
> 	Filename        : draft-ietf-tcpm-accurate-ecn-17.txt
> 	Pages           : 60
> 	Date            : 2022-03-07
>
> Abstract:
>    Explicit Congestion Notification (ECN) is a mechanism where network
>    nodes can mark IP packets instead of dropping them to indicate
>    incipient congestion to the end-points.  Receivers with an ECN-
>    capable transport protocol feed back this information to the sender.
>    ECN was originally specified for TCP in such a way that only one
>    feedback signal can be transmitted per Round-Trip Time (RTT).  Recent
>    new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP
>    (DCTCP) or Low Latency Low Loss Scalable Throughput (L4S) need more
>    accurate ECN feedback information whenever more than one marking is
>    received in one RTT.  This document updates the original ECN
>    specification to specify a scheme to provide more than one feedback
>    signal per RTT in the TCP header.  Given TCP header space is scarce,
>    it allocates a reserved header bit previously assigned to the ECN-
>    Nonce.  It also overloads the two existing ECN flags in the TCP
>    header.  The resulting extra space is exploited to feed back the IP-
>    ECN field received during the 3-way handshake as well.  Supplementary
>    feedback information can optionally be provided in a new TCP option,
>    which is never used on the TCP SYN.  The document also specifies the
>    treatment of this updated TCP wire protocol by middleboxes, updating
>    BCP 69 with respect to ACK filtering.
>
>
> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/
>
> There is also an HTML version available at:https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-17.html
>
> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-17
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> tcpm mailing listtcpm@ietf.orghttps://www.ietf.org/mailman/listinfo/tcpm
>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>