Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-13.txt
Yoshifumi Nishida <nsd.ietf@gmail.com> Fri, 06 November 2020 10:28 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 DDD4F3A104A for <tcpm@ietfa.amsl.com>; Fri, 6 Nov 2020 02:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 tOQnO_SD6xTF for <tcpm@ietfa.amsl.com>; Fri, 6 Nov 2020 02:28:19 -0800 (PST)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 9EA183A1049 for <tcpm@ietf.org>; Fri, 6 Nov 2020 02:28:19 -0800 (PST)
Received: by mail-qv1-xf2d.google.com with SMTP id d1so213370qvl.6 for <tcpm@ietf.org>; Fri, 06 Nov 2020 02:28:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o8SJlRcjeJdOIba3giJmbM7rYWge/Fa3+IBChZNVf/w=; b=lZaYwj/JEFo0tR5LI/uHeRustWgxM2whsLNy5GT1z9XJ/QjOYJdVfxVMJhAeY86d7Y uEebY/BGZuDELPenwBMWfVvH7QDnqYMUG4rlxBvqV3shC2a/kKTOSptdxs3RFHRwoItJ ue5NhBZOGGG19/RUo+NISrcfvTiz38LEjjtSMERLDxLTd0Op8hnHCYbMXy1jA5lVjabV D6ah+HIeYu5bKtKdIEvmCvx73LYh9MGUogyuSFkY9yfi4d0U/dMx+IfM+rvZxh6MiNrk nmfGL0XiHs8vzuIbzCTaz+faSvQVAyt6O5u7evixwzb55HEkcjkhZ/ciM9tCTkFAEU6v SqwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o8SJlRcjeJdOIba3giJmbM7rYWge/Fa3+IBChZNVf/w=; b=KXoUokwr05J2xl5+TnSCJh3SCP8vag9hEbBcKbjPCkyOC3qu+nZAND+9Nv+qTCr4uQ jfMegY+6Ft4/MB3lgm31W3b+9XafQo7Uf17n66jwYArGCoshLJyU9LajrfYzJzzch0+l lXtOCuScLMVwZ9DWd0FZXitAYP9OjJKCsaMOZcCgbNOBTKhjP5gHimtWf3+50JwKoKhs RuIqNsKEssPMlS0m2SB/dVBFEt+xhlJtOtHlTLsaywgQEYGVDzWq02p9zjHdCr170C95 OdKCXn3jiuSEhXNkZ273bxzA+llCzlfiwORbbuKoyKZjwAIlK1covXBHgNDOopYGJpSS aYdg==
X-Gm-Message-State: AOAM530hKOuL7sArSuVE0WYZ0uGzOckBdj+AyVGMzjtIG2hyzGg2rMQf LEi0IjAP94M4gW0CmSdxTmdjGa6JfRi0dzxfBVU=
X-Google-Smtp-Source: ABdhPJwhshT309X8mFFe4lSxt8enjMUOjR2AZx/QkZ5EKa2MWrcxha0JiPYMca26Oj2CyiQluaDi54wDzjwsUqEp7xw=
X-Received: by 2002:a0c:e0c9:: with SMTP id x9mr828662qvk.56.1604658497230; Fri, 06 Nov 2020 02:28:17 -0800 (PST)
MIME-Version: 1.0
References: <160388925181.18695.7892567372446756190@ietfa.amsl.com> <4017c549-ac6d-d633-6432-20a6a8a9a342@bobbriscoe.net> <3c8de57b23994824b6c51cf5d7fba7ec@hs-esslingen.de> <5dd8f210-2fe2-bd9b-5e69-4a87016f5416@bobbriscoe.net> <dae037f1-1b39-2a79-1f78-0ddc13e54507@bobbriscoe.net> <CAAK044SkeTcSshPRxZgxniCDzek+9YuyUYpkNsFPe+=ExoAvJA@mail.gmail.com> <FFA9CFA4-48E2-4432-8DFC-BF9EA08FBAB6@ericsson.com>
In-Reply-To: <FFA9CFA4-48E2-4432-8DFC-BF9EA08FBAB6@ericsson.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Fri, 06 Nov 2020 02:28:06 -0800
Message-ID: <CAAK044TM=rB7mVv7=O8pdyZR6xNT642PaCgXFyAbDD_fvtZZ3A@mail.gmail.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com>, "tcpm@ietf.org" <tcpm@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary="000000000000b69a9f05b36dabe6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/5Yty2BEzAUZbsxRXEKDwMIhrt54>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-13.txt
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: Fri, 06 Nov 2020 10:28:23 -0000
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? Also, even though traffic flows one direction, I think you might want to send back SACK options, etc. 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. Thanks, -- Yoshi On Fri, Nov 6, 2020 at 1:30 AM Mirja Kuehlewind < mirja.kuehlewind@ericsson.com> 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 <tcpm-bounces@ietf.org> on behalf of Yoshifumi Nishida < > nsd.ietf@gmail.com> > *Date: *Friday, 6. November 2020 at 09:54 > *To: *Bob Briscoe <ietf@bobbriscoe.net> > *Cc: *"Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com>, " > tcpm@ietf.org" <tcpm@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net> > *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 <ietf@bobbriscoe.net> 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 <tcpm-bounces@ietf.org> On Behalf Of Bob Briscoe > >>> Sent: Wednesday, October 28, 2020 2:04 PM > >>> To: tcpm@ietf.org > >>> Cc: Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>; Mirja > >>> Kuehlewind <ietf@kuehlewind.net> > >>> 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, 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-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 > >>>> tcpm@ietf.org > >>>> 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 > >>> tcpm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tcpm > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> 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 > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > >
- [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-1… internet-drafts
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Bob Briscoe
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Scharf, Michael
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Bob Briscoe
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Bob Briscoe
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Scharf, Michael
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Yoshifumi Nishida
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Mirja Kuehlewind
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Yoshifumi Nishida
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Bob Briscoe
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Gorry Fairhurst
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Bob Briscoe
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Yoshifumi Nishida
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Gorry Fairhurst
- Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-e… Bob Briscoe