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

Bob Briscoe <ietf@bobbriscoe.net> Tue, 03 November 2020 00:08 UTC

Return-Path: <ietf@bobbriscoe.net>
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 47C333A093D for <tcpm@ietfa.amsl.com>; Mon, 2 Nov 2020 16:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Level:
X-Spam-Status: No, score=-2.347 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, NICE_REPLY_A=-0.247, 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=bobbriscoe.net
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 Hs-WDIbndgUA for <tcpm@ietfa.amsl.com>; Mon, 2 Nov 2020 16:08:07 -0800 (PST)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6733A12DE for <tcpm@ietf.org>; Mon, 2 Nov 2020 16:06:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BNPOAfTBRUezYaFF6xQmwaTScgvodAwa9t397POu92Q=; b=awB90lB6yi514TI6XFp97LHLzk KscPyuby++02WgM+hzd4O6kSxVyHwJrDekWL8WcA2GtWHtLzn+yO3fthEycPJzNzczZPNM4svi8i7 SNSnawCZLkHtksm33ewAqvA1F/kMICS1En0wYOSZxX9nplNpMbiOwDX5jgDGlCHeFPMsf8ac2SvPg skjKJC6v+8jvbk/XtVWNxxAFbpPlKqsY+EW9XFA3mpme9EDfAXb3RKiv+5/0PIV8oI8v+KqkuZV0t dxHF566S0ai4cayd+E0OZa+ntI9dnBauLulBF9HAGbKwW/Q3oyFMtlUsUs2vKkwr1X38xfinIsDk/ BFldGQgA==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:39504 helo=[192.168.1.3]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1kZjpl-00FIBL-Gl; Tue, 03 Nov 2020 00:05:58 +0000
From: Bob Briscoe <ietf@bobbriscoe.net>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "tcpm@ietf.org" <tcpm@ietf.org>
Cc: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com>, Mirja Kuehlewind <ietf@kuehlewind.net>
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>
Message-ID: <dae037f1-1b39-2a79-1f78-0ddc13e54507@bobbriscoe.net>
Date: Tue, 03 Nov 2020 00:05:56 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <5dd8f210-2fe2-bd9b-5e69-4a87016f5416@bobbriscoe.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/RF7gOZW3tLSNBVl_yUkoJBME_9w>
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: Tue, 03 Nov 2020 00:08:10 -0000

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/