Re: [tcpm] AccECN: summary text about omitting unchanged fields

["Scheffenegger, Richard" <[e-mail]>]

Should the guidance perhaps be even more direct, that pure control
segments without data, and without other options than TSopt SHOULD
include the complete AccECN Option in full?

(The concern really is about using up TCP option space which may be used
in a more acutely critical way for SACK or MPTCP, as well as shortening
the data size carried by a full-size segment).

BTW, the Option Sender (data receiver) code I created first fills all
the otherwise needed TCP options, and then stuffs the remainder of the
available TCP option space by a AccECN option as large as possible
(preferring the variant, where the changed fields are coming first).

So, it does NOT try not to infringe on the segment's data space, but
rather send out as full as possible AccECN options all the time.

Best regards,
   Richard


Am 29.07.2022 um 20:28 schrieb Neal Cardwell:
> Re:
> https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-20.html
> <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-20.html>
>
> and this passage:
>
> [EXISTING:]
> "Whenever a Data Receiver sends an AccECN Option, the rules in Section
> 3.2.3.3 allow it to omit unchanged fields from the tail of the option,
> to help cope with option space limitations, as long as it preserves the
> order of the remaining fields and includes any field that has changed."
>
> I'm a little concerned that some readers might see this passage, and not
> actually follow the hyperlinked reference and read Section 3.2.3.3, and
> might use the summary in this sentence to conclude that it's OK "to omit
> unchanged fields from the tail of the option, to help cope with option
> space limitations, as long as it preserves the order of the remaining
> fields and includes any field that has changed." But if a data receiver
> receives only 1 CE-marked data packet, and then the single ACK carrying
> an increment of r.ceb is lost, then following that policy could cause
> the data receiver to never again send the r.ceb field (because r.ceb was
> never again incremented), and thus could cause the data sender to not
> receive notification of a CE congestion event. This would defeat the
> whole purpose of Accurate ECN.
>
> To reduce the risk of this mis-reading, I'd suggest shortening this
> forward reference to Section 3.2.3.3 to something like:
>
> [SUGGESTED:]
> "When a Data Receiver sends an AccECN Option it is allowed in certain
> circumstances to omit fields from the tail of the option, but when doing
> so MUST follow the rules in Section 3.2.3.3.  When omitting fields the
> Data Receiver MUST preserve the order of the remaining fields. Omitting
> fields helps cope with option space limitations."
>
> Hopefully consolidating into  Section 3.2.3.3 the rules about when
> omitting fields is allowed would help avoid misunderstandings that might
> compromise the accuracy of Accurate ECN.
>
> best regards,
> neal
>
>
> On Mon, Jul 25, 2022 at 10:47 AM Bob Briscoe <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     tcpm,
>
>     Minor diffs from 19 to 20; Summary:
>     1, Section 3.2.3. The AccECN Option
>     https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-20#section-3.2.3
>     <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-20#section-3.2.3>
>           As promised, we've added a stronger motivation for the
>     RECOMMENDations for partial implementations.
>     2. Section 7 IANA Considerations:
>     https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-20#section-7
>     <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-20#section-7>
>           Added the ExIDs of the two options used by experimental
>     implementations.
>
>
>     Bob
>
>
>     On 25/07/2022 15:21, [e-mail]
>     <mailto:[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           : More Accurate ECN Feedback in TCP
>      >          Authors         : Bob Briscoe
>      >                            Mirja Kühlewind
>      >                            Richard Scheffenegger
>      >    Filename        : draft-ietf-tcpm-accurate-ecn-20.txt
>      >    Pages           : 61
>      >    Date            : 2022-07-25
>      >
>      > 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/
>     <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-20.html
>     <https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-20.html>
>      >
>      > A diff from the previous version is available at:
>      > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-20
>     <https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-20>
>      >
>      >
>      > Internet-Drafts are also available by rsync at
>     rsync.ietf.org::internet-drafts
>      >
>      >
>      > _______________________________________________
>      > tcpm mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/tcpm
>     <https://www.ietf.org/mailman/listinfo/tcpm>
>
>     --
>     ________________________________________________________________
>     Bob Briscoe http://bobbriscoe.net/ <http://bobbriscoe.net/>
>
>     _______________________________________________
>     tcpm mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tcpm
>     <https://www.ietf.org/mailman/listinfo/tcpm>
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm