Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-13.txt
Yoshifumi Nishida <nsd.ietf@gmail.com> Fri, 06 November 2020 08:54 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 272193A0EF6 for <tcpm@ietfa.amsl.com>; Fri, 6 Nov 2020 00:54:14 -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 krbximcJgEGD for <tcpm@ietfa.amsl.com>; Fri, 6 Nov 2020 00:54:10 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 CEF1D3A0EF5 for <tcpm@ietf.org>; Fri, 6 Nov 2020 00:54:09 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id t5so288531qtp.2 for <tcpm@ietf.org>; Fri, 06 Nov 2020 00:54:09 -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=E+KBs/aVKYAUOmaBCN1jimxAyQUEOwPabXUMqwSov3E=; b=TMizsD3Bv1hS84Idf18cPFBgh6+WSGIfKRnCkC/pig4MjKBl3TICqUABn5cITB/s8Y w5ogLi8ZRENnzWDZ3/HvnuqETnwGCgx3+Mz8zqqBz1iVx4QZ2bVrQjvil0JUKl5pNIg7 lp+ncb8zctEslBfWGuQJ/fVawzlX4V65/ceDiRXxjqSe2Sghreg8aFRUSdUnO+VcqTG3 lOUu8qs6xm2TvYA+eLdpedU6S65pnSreWR1VoSOjcYkP2l7ncS9CNNnWcdo8CbxH4iu6 ZPLe3iDtpRHezAWDv6dEkQpxWEgorhwhw1uPS6Bg00k1aa/SY16k78y2kkUunkLWvF7F 4UAw==
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=E+KBs/aVKYAUOmaBCN1jimxAyQUEOwPabXUMqwSov3E=; b=mW/0S4O7NyA368CyFazrMudzu1RZBUnJP2UkzqJYp6ABvAql02KXZV6kOBRQbCwG85 Fd4wrvrww/t06O1OyKq5aia0z623TVGcQtIGJyA53XlqCj9KvjT+ol6mD6zK8mzur7zC j/l7uX0w5aVunmgp591gMGChD02E9iLpUqfpMwxGu3EXfLGW9p8FFxq0jVmuKcMom8yp kCagFmHzI/PPPo8tkTyscZCG7C1YeP5cXv2w9ch17tI0xySAPBuyKlLuxeV5U2m4wirE eStLNTEAGgMZkda3pZSkbd+nXc6yr34g6sd5KcrH3F5TkZMhGqu6pqpkfgKRDu6MC0HQ xxQA==
X-Gm-Message-State: AOAM531I7zf8m0TyyNygg9lUQ9dUd1JUuf9LjpBOfVqxmocPldmge2Sm EDb3nOtAfu+8M6cRwO3kvqIgd+KBAPInAUQW2oI=
X-Google-Smtp-Source: ABdhPJx1zk2FvpMSNqvSmTbftOhmV7JUNn1ybRFqR9dpFNc8o9iwQLPP+SLzWF1R4R/TwgmIDKqj/AM/AUkdpBxJ7rU=
X-Received: by 2002:ac8:5a8c:: with SMTP id c12mr548104qtc.310.1604652848823; Fri, 06 Nov 2020 00:54:08 -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>
In-Reply-To: <dae037f1-1b39-2a79-1f78-0ddc13e54507@bobbriscoe.net>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Fri, 06 Nov 2020 00:53:57 -0800
Message-ID: <CAAK044SkeTcSshPRxZgxniCDzek+9YuyUYpkNsFPe+=ExoAvJA@mail.gmail.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "tcpm@ietf.org" <tcpm@ietf.org>, "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com>, Mirja Kuehlewind <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary="0000000000000ac13005b36c5b65"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/7EDwVj367gSDPh6JygHkKmHCQy0>
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 08:54:14 -0000
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/ > >>> 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/ > > _______________________________________________ > 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