Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-13.txt

["Scharf, Michael" <[e-mail]>]

> Michael,
> 
> 1/ I just posted a draft-13 that has the two AccECN TCP Option orders.
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-13
> 
> As agreed, it keys the two option orders on two different Option Kinds,
> which I've requested in the IANA section (TBD0 and TBD1). This replaces
> using the initial values of the fields. I've reverted all the
> complicated text about:
> * varying the initial field values dependent on option order,
> * having to keep consistent order throughout a connection,
> * and choosing which order from each end.
> All of which is irrelevant now.
> 
> It is much simpler (I guess we all knew that). Thank you.

Yep, and simplicity is IMHO a big plus. This approach is IMHO much better than the previous proposal of keeping state. I'd like to repeat that I would also be fine with other alternative solutions, as long as they are not overly complex.

Anyway, this new text works for me. 

Michael

 
> As mentioned, I found my other ToDo list:
> 2/ We also introduced considerably more guidance on middlebox handling,
> esp. ACK filtering and Segmentation Offload. There was enough extra text
> to be worth breaking that section into subsections.
> 
> The guidance on ACK filtering for connections with AccECN negotiated
> updates the (non-)guidance in RFC3449 (BCP69 which said ACK filtering in
> the presence of ECN was a research issue). But there is still no
> guidance for ECN connections when AccECN has not been negotiated.
> 
> 3/ I also added a SHOULD requirement I had on my ToDo list: Each Data
> Sender SHOULD disable ECT in one direction if all the feedback for three
> or four rounds from the start is CE. That's already done in Linux, and
> in the TCP in iOS and MacOS at least.
> 
> 
> 
> Bob
> 
> 
> 
> 
> 
> On 28/10/2020 17:17, Bob Briscoe wrote:
> > Michael,
> >
> > On 28/10/2020 15:55, Scharf, Michael wrote:
> >> Hi Bob,
> >>
> >> What is the future plan regarding the option encoding proposed by the
> >> authors?
> >>
> >> This has been discussed in past meetings and on the list, for
> >> instance:
> >> https://mailarchive.ietf.org/arch/msg/tcpm/zo-
> 1OR0nRfhHocX8yvTvpC4BNMo/
> >>
> >> I have explained several times my pushback against the encoding
> >> currently described in the document, most notably the requirement to
> >> keep state in the endpoints to decode the format of a TCP option. I
> >> have not changed my mind.
> >>
> >> I have also mentioned that, for instance, two option codepoints would
> >> IMHO be a better engineering approach ("KISS principle"). That would
> >> be a very simple change to the content to the document. Needless to
> >> say that there are other alternatives for marshalling parameters in
> >> an unambigous way.
> >
> > [BB] Whoops. In my head I had already shifted to your scheme with
> > two-option kinds. But I see that, in the draft,  I haven't. Whoops -
> > that was a bug in my ToDo list processing. Sorry about that. I'll
> > submit another draft before the deadline with that scheme replacing
> > the current one.
> >
> > I've just found some other entries in my ToDo list for this draft
> > which I missed as well. I'll include them too.
> >
> > Sorry again.
> >
> >
> > Bob
> >
> >>
> >> There have been other related comments, e.g. from Ilpo.
> >>
> >> Best regards
> >>
> >> Michael (with no hat)
> >>
> >>> -----Original Message-----
> >>> From: tcpm <[e-mail]> On Behalf Of Bob Briscoe
> >>> Sent: Wednesday, October 28, 2020 2:04 PM
> >>> To: [e-mail]
> >>> Cc: Scheffenegger, Richard <[e-mail]>;
> Mirja
> >>> Kuehlewind <[e-mail]>
> >>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-12.txt
> >>>
> >>> TCPM folks,
> >>>
> >>> Back in May'20, it was decided to hold back the AccECN (and the ECN++)
> >>> drafts for a while until the position on L4S in tsvwg was clearer.
> >>> There
> >>> is no formal dependency on the L4S drafts in tsvwg, but it made sense
> >>> not to burn codepoints without more certainty.
> >>>
> >>> I've just refreshed the AccECN and the ECN++ drafts, which had expired.
> >>>
> >>> I included the following minor changes to AccECN, which you can see via
> >>> the diff link below, but in summary:
> >>> * moved wrongly categorized "action if unwilling to provide f/b" to the
> >>> group of bullets relevant to the receiver
> >>> * removed refs to long-expired ecn-fallback draft
> >>> * fixed table 1 after xml2rfc changed formatting
> >>>
> >>> Thanks to those who pointed these out.
> >>>
> >>> No changes to ECN++ other than update of some refs.
> >>>
> >>> Cheers
> >>>
> >>>
> >>> Bob
> >>>
> >>> On 28/10/2020 12:47, [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-12.txt
> >>>>     Pages           : 58
> >>>>     Date            : 2020-10-28
> >>>>
> >>>> 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 is 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 specifies 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, that was
> >>>>      previously used for the ECN-Nonce which has now been declared
> >>>>      historic.  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 IETF datatracker status page for this draft is:
> >>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/
> >>>>
> >>>> There are also htmlized versions available at:
> >>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-12
> >>>> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-12
> >>>>
> >>>> A diff from the previous version is available at:
> >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-12
> >>>>
> >>>>
> >>>> 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/
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> tcpm mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/tcpm
> >>> --
> >>>
> __________________________________________________________
> ______
> >>> Bob Briscoe http://bobbriscoe.net/
> >>>                  PRIVILEGED AND CONFIDENTIAL
> >>>
> >>> _______________________________________________
> >>> tcpm mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/tcpm
> >> _______________________________________________
> >> tcpm mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >
> 
> --
> __________________________________________________________
> ______
> Bob Briscoe                               http://bobbriscoe.net/