[tcpm] Fwd: Loose ends tied up in draft-ietf-tcpm-accurate-ecn-19 (AccECN)

Yoshi,

The only other loose end AFAICS, is the SECDIR review on the datatracker 
that says "Has issues".
The reviewer admitted he was not a TCP expert and didn't actually 
address the question you asked to be answered, other than remarking that 
there was a ToDo in the text waiting for a decision on the covert 
channel question (which was awaiting the SECDIR review!).

We addressed everything else he said at the time, and made the ToDo into 
an explanation for why the design choice had been made, given this was 
not a new covert channel.
https://datatracker.ietf.org/doc/review-ietf-tcpm-accurate-ecn-14-secdir-early-kelly-2021-04-15/

I don't think this warrants "Has issues".
It surely ought to be tagged "needs (another) SECDIR review".

Bob

-------- Forwarded Message --------
Subject: 	Loose ends tied up in draft-ietf-tcpm-accurate-ecn-19 (AccECN)
Date: 	Mon, 11 Jul 2022 16:10:06 +0100
From: 	Bob Briscoe <ietf@bobbriscoe.net>
To: 	Yoshifumi Nishida <nsd.ietf@gmail.com>, tcpm IETF list <tcpm@ietf.org>

@Yoshi, this completes all the changes I believe have been requested or 
are needed.

@tcpm, Summary of changes (see diff linked below for full details)

      ==Normative Changes==

3.3.3. 
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-19#section-3.3.3> 
Requirements for TCP ACK Filtering

  * RFC3449 already says ACK filtering nodes have to ensure they don't
    interfere with the correction operation of ECN feedback.
      o Altho' RFC3449 references RFC3168, given AccECN updates RFC3168,
        the requirement can beassumed to apply to both RFC3168 and
        AccECN f/.
      o So no need to update RFC3449 and altered text accordingly.
  * Also stated worst-case wrap.
  * All as discussed in the thread "RFC3449 and AccECN
    <https://mailarchive.ietf.org/arch/msg/tcpm/hD9W-STuLv3Km04x0Cy1obgjApA/>"

      ==Normative/ Technical Changes==

3.2.3. 
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-19#section-3.2.3> 
The AccECN Option

  * If partial implementation, recommended at least implementing sending
    of AccECN Option, even if not the receive logic (switched round from
    previous version).
  * All as discussed in the thread "Partial implementation of AccECN
    Option logic
    <https://mailarchive.ietf.org/arch/msg/tcpm/0uJumvVAu4i88fmbT7wKlrpP5B0/>"
    and as proposed at the IETF-113 tcpm meeting

      ==Editorial==

Altered order of "3.2.2.3. 
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-19#section-3.2.2.3>  
Testing for Mangling of the IP/ECN Field" to better reflect the order 
the implementation uses (suggested by Ilpo).

Bob

On 11/07/2022 15:40, 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-19.txt
>    Pages           : 61
>    Date            : 2022-07-11
>
> 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.
>
>
> 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-19.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-19
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/