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

[Bob Briscoe <[e-mail]>]

Yoshi,

On 06/11/2020 10:28, Yoshifumi Nishida wrote:
> Hi Mirja,
>
> It seems to me that we don't have much freedom for the frequency of 
> the feedback.
> The draft says:
>     MUST immediately send an ACK once 'n' CE marks have arrived since
> the previous ACK, where 'n' SHOULD be 2 and MUST be no greater than 6.
> Or, options are not applied to this?

[BB]
Section 3.2.2 about the ACE field, which is in the main TCP header feeds 
back the count of CE-marked *packets* .
Section 3.2.3 is about the AccECN TCP Option, which is optional and 
feeds back a count of *bytes* for each marking.

If there are any places in the draft where this isn't clear, we can fix 
them. But, in this case, the  text right under your quote says:

    These rules for when to send an ACK are designed to be complemented
    by those inSection 3.2.3.3  <https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-13#section-3.2.3.3>, which concern whether the AccECN TCP
    Option ought to be included on ACKs.


> Also, even though traffic flows one direction, I think you might want 
> to send back SACK options, etc.

Last para of the Introduction:

    It is recommended that the AccECN protocol is implemented alongside
    SACK [RFC2018  <https://tools.ietf.org/html/rfc2018>] and ...


Also, interactions with SACK are raised where necessary throughout the 
draft. In particular this one:

       If the smallest allowed AccECN Option would leave insufficient
       space for two SACK blocks on a particular ACK, the Data Receiver
       MUST give precedence to the SACK option (total 18 octets), because
       loss feedback is more critical.


> Another thought is bulk flow traffic tends to send full MSS packets. I 
> feel 1 byte granularity might not be very efficient.
> In any cases, I just thought saving option space won't be a bad thing 
> if it's not overly difficult.

[BB] If efficiency is needed, field(s) (or the whole option) can be omitted.
During the history of this draft we have proposed different ways to 
encode information more efficiently, but WG discussion decided that 
simple omission or inclusion of fields gives optional efficiency with 
minimal complexity.

I'm not saying the act of reducing the granularity of each field would 
be particularly complex.
Rather, complexity comes from the resulting ambiguity. Here's an example:
* The Linux code currently uses the byte counters to help disambiguate 
wrap of the 3-bit packet counter.
* If for instance the byte counters were truncated by 8 bits for 
efficiency, it would add many more ambiguous cases for this code to have 
to take into account.
* Such complexity introduces misunderstanding and bugs.

The design has gone round and round many times. We have tried to 
converge on the best tradeoffs.

Best Regards


Bob

> Thanks,
> --
> Yoshi
>
> On Fri, Nov 6, 2020 at 1:30 AM Mirja Kuehlewind 
> <[e-mail] <mailto:[e-mail]>> 
> wrote:
>
>     Hi Yoshi,
>
>     not sure if that really saves that much as you don’t need to send
>     the option with every packet, as such you can manage the overhead
>     dynamically as you can decide how often to send. Also in a
>     scenario where most of the traffic flows only in on direction the
>     AccECN is sent in the other direction.
>
>     Mirja
>
>     *From: *tcpm <[e-mail]
>     <mailto:[e-mail]>> on behalf of Yoshifumi Nishida
>     <[e-mail] <mailto:[e-mail]>>
>     *Date: *Friday, 6. November 2020 at 09:54
>     *To: *Bob Briscoe <[e-mail] <mailto:[e-mail]>>
>     *Cc: *"Scheffenegger, Richard" <[e-mail]
>     <mailto:[e-mail]>>, "[e-mail]
>     <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>,
>     Mirja Kuehlewind <[e-mail] <mailto:[e-mail]>>
>     *Subject: *Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-13.txt
>
>     Hi Bob,
>
>     Sorry for the late comments, I have a naive question about the
>     encoding schemes in the options.
>
>     The byte counters will be incremented by every byte the receiver
>     receives. But, do we really need this level of granularity?
>
>     I am thinking if we can byte-shift the counter values to some
>     extent, we might be able to save option space.
>
>     Thanks,
>
>     --
>
>     Yoshi
>
>     On Mon, Nov 2, 2020 at 4:09 PM Bob Briscoe <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         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.
>
>         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]
>         <mailto:[e-mail]>> On Behalf Of Bob Briscoe
>         >>> Sent: Wednesday, October 28, 2020 2:04 PM
>         >>> To: [e-mail] <mailto:[e-mail]>
>         >>> Cc: Scheffenegger, Richard
>         <[e-mail]
>         <mailto:[e-mail]>>; Mirja
>         >>> Kuehlewind <[e-mail] <mailto:[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]
>         <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-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 <http://tools.ietf.org>.
>         >>>>
>         >>>> Internet-Drafts are also available by anonymous FTP at:
>         >>>> ftp://ftp.ietf.org/internet-drafts/
>         >>>>
>         >>>>
>         >>>> _______________________________________________
>         >>>> tcpm mailing list
>         >>>> [e-mail] <mailto:[e-mail]>
>         >>>> https://www.ietf.org/mailman/listinfo/tcpm
>         >>> --
>         >>>
>         ________________________________________________________________
>         >>> Bob Briscoe http://bobbriscoe.net/
>         <https://protect2.fireeye.com/v1/url?k=94a9aab2-cb32939f-94a9ea29-8692dc8284cb-827b8e584d366b78&q=1&e=b9141f6c-0f70-4414-9212-82cae72b93fc&u=http%3A%2F%2Fbobbriscoe.net%2F>
>         >>>                  PRIVILEGED AND CONFIDENTIAL
>         >>>
>         >>> _______________________________________________
>         >>> tcpm mailing list
>         >>> [e-mail] <mailto:[e-mail]>
>         >>> https://www.ietf.org/mailman/listinfo/tcpm
>         >> _______________________________________________
>         >> tcpm mailing list
>         >> [e-mail] <mailto:[e-mail]>
>         >> https://www.ietf.org/mailman/listinfo/tcpm
>         >
>
>         -- 
>         ________________________________________________________________
>         Bob Briscoe http://bobbriscoe.net/
>         <https://protect2.fireeye.com/v1/url?k=1641fe24-49dac709-1641bebf-8692dc8284cb-0283475ef4fa8e27&q=1&e=b9141f6c-0f70-4414-9212-82cae72b93fc&u=http%3A%2F%2Fbobbriscoe.net%2F>
>
>         _______________________________________________
>         tcpm mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/tcpm
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/