From nobody Tue Feb 4 13:41:36 2020 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A411200F5; Tue, 4 Feb 2020 13:41:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <158085249512.15828.9596417593771521005@ietfa.amsl.com> Date: Tue, 04 Feb 2020 13:41:35 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 21:41:35 -0000 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 : Requirements for Time-Based Loss Detection Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-10.txt Pages : 10 Date : 2020-02-04 Abstract: Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, protocols ultimately can only count on the passage of time without delivery confirmation to declare a packet "lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations. This document provides high-level requirements for time-based loss detectors appropriate for general use in the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-10 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rto-consider-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-10 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/ From nobody Wed Feb 5 11:56:00 2020 Return-Path: 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 84CB11208A7 for ; Wed, 5 Feb 2020 11:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 akoepZ3WZ3K3 for ; Wed, 5 Feb 2020 11:55:56 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B870512083D for ; Wed, 5 Feb 2020 11:55:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 640E42C4025 for ; Wed, 5 Feb 2020 11:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QUZB+uG0ctVP for ; Wed, 5 Feb 2020 11:55:54 -0800 (PST) Received: from lawyers.icir.org (envoy.ICIR.org [192.150.187.30]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id CA6822C4016 for ; Wed, 5 Feb 2020 11:55:54 -0800 (PST) Received: from [192.168.1.244] (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7221A225315A for ; Wed, 5 Feb 2020 14:55:54 -0500 (EST) From: "Mark Allman" To: tcpm@ietf.org Date: Wed, 05 Feb 2020 14:55:54 -0500 X-Mailer: MailMate (1.13.1r5671) Message-ID: <214CF409-AC4B-42AC-9387-80D3DA4E320D@icir.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [tcpm] rev 10 of rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 19:55:59 -0000 Folks- I submitted version -10 of rto-consider yesterday. The updates in this version stem from the comments offered by Gorry & Jana at and after the last IETF meeting (thanks!). In particular, the substantive changes relative to pre-IETF106 are: - Gorry's list of fairly minor issues from the last meeting have been addressed. - Section 2 on the document's context and its relationship with other IETF documents has been hacked on pretty good, based on chatting with Gorry. I don't want to speak for Gorry, but he has seen these words and based on his feedback I believe his issue has been addressed. - Jana has long nudged me to subtly change the document's thrust from "retransmission" to "loss detection". I.e., the timer's fundamental job is not to retransmit, but to determine when a segment has been lost. And, the response to a detected loss may not always be to retransmit the segment (e.g., it could be to make congestion control decisions). I have made this change. Two notes: (1) This doesn't at all change any of the technical requirements given in the document. For instance, the document still says time-based loss detection SHOULD be based on the feedback time and the variance in the feedback time, just as it previously said retransmissions SHOULD be based on the FT and the variance in the FT. (2) The change the specific words in countless places in the document where the term "retransmission" was used and now the document frames the discussion in terms of "loss detection". So, the diffs are therefore ugly. (The good news is that you can eschew the diffs and just read the thing because it's still a short document.) It'd be great if folks could take a look at the document and send along any comments. I know the chairs previously said they'd like to get a WGLC going soon (which is why they sought reviews from Jana & Gorry). I'd like that, too. Thanks! allman -- https://www.icir.org/mallman/ @mallman_icsi From nobody Mon Feb 10 08:06:27 2020 Return-Path: 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 15FEA120170 for ; Mon, 10 Feb 2020 03:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AHYyCgL6ERal for ; Mon, 10 Feb 2020 03:32:15 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 79484120180 for ; Mon, 10 Feb 2020 03:32:15 -0800 (PST) Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:42:110:2106:f729:edf0:981e]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 838FD1B001AB; Mon, 10 Feb 2020 11:32:12 +0000 (GMT) To: Mark Allman , tcpm@ietf.org References: <214CF409-AC4B-42AC-9387-80D3DA4E320D@icir.org> From: Gorry Fairhurst Message-ID: <09810aaa-6ee0-7144-a1fd-f2c1a6ae53c9@erg.abdn.ac.uk> Date: Mon, 10 Feb 2020 11:32:10 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <214CF409-AC4B-42AC-9387-80D3DA4E320D@icir.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] rev 10 of rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 11:32:18 -0000 On 05/02/2020 19:55, Mark Allman wrote: > Folks- > > I submitted version -10 of rto-consider yesterday. The updates in > this version stem from the comments offered by Gorry & Jana at and > after the last IETF meeting (thanks!). In particular, the > substantive changes relative to pre-IETF106 are: > > - Gorry's list of fairly minor issues from the last meeting have > been addressed. > > - Section 2 on the document's context and its relationship with > other IETF documents has been hacked on pretty good, based on > chatting with Gorry. I don't want to speak for Gorry, but he > has seen these words and based on his feedback I believe his > issue has been addressed. > > - Jana has long nudged me to subtly change the document's thrust > from "retransmission" to "loss detection". I.e., the timer's > fundamental job is not to retransmit, but to determine when a > segment has been lost. And, the response to a detected loss may > not always be to retransmit the segment (e.g., it could be to > make congestion control decisions). I have made this change. > Two notes: > > (1) This doesn't at all change any of the technical requirements > given in the document. For instance, the document still > says time-based loss detection SHOULD be based on the > feedback time and the variance in the feedback time, just as > it previously said retransmissions SHOULD be based on the FT > and the variance in the FT. > > (2) The change the specific words in countless places in the > document where the term "retransmission" was used and now > the document frames the discussion in terms of "loss > detection". So, the diffs are therefore ugly. (The good > news is that you can eschew the diffs and just read the > thing because it's still a short document.) > > It'd be great if folks could take a look at the document and send > along any comments. I know the chairs previously said they'd like > to get a WGLC going soon (which is why they sought reviews from Jana > & Gorry). I'd like that, too. > > Thanks! > > allman > > > -- > https://www.icir.org/mallman/ > @mallman_icsi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm That seems a good summary Mark, thanks for taking on board my comments! Gorry From nobody Tue Feb 11 14:53:02 2020 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7748E120847; Tue, 11 Feb 2020 14:53:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <158146158037.20043.3218096522600291865@ietfa.amsl.com> Date: Tue, 11 Feb 2020 14:53:00 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-15.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 22:53:00 -0000 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 : 0-RTT TCP Convert Protocol Authors : Olivier Bonaventure Mohamed Boucadair Sri Gundavelli SungHoon Seo Benjamin Hesmans Filename : draft-ietf-tcpm-converters-15.txt Pages : 53 Date : 2020-02-11 Abstract: This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the TCP Convert Protocol (Convert). This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels, whatsoever). This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-converters-15 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-15 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/ From nobody Tue Feb 11 22:29:33 2020 Return-Path: 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 95675120882 for ; Tue, 11 Feb 2020 22:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 xyKxwaLItYUk for ; Tue, 11 Feb 2020 22:29:28 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C599120879 for ; Tue, 11 Feb 2020 22:29:28 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 48HV9L0f6YzytY; Wed, 12 Feb 2020 07:29:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1581488966; bh=qi5x/u2WVtUKQ7JhO7i+MFAzwbdaXd1eIkL5BFVEVP0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=d5LfMXRTE/jtgRRkdYVGtMqOGZXbtzi61pnhqm9FBm4DMUpRiF+ncMpxjiKeFL3+L xC7pOvM5mmlX8htSZHhmlU29vCh4ljGefFLzFRbRIFFbtzXEmGbX3KZYBYS4dYaA1T ukyiWbnoNALTbDFGazk1w//wtxz4Uzg3AGIfs6g80hN5R5dKUMPhconU3CYOpzXSus N2yl1Mfv+HZcVKNi+7MjdvjV0/1Ia3uvYn8xHZXB/Oel9tH0Li4+kcuTv9g7fpmbmH ifpxYO18F0ZY/mpTLoqRtllHeu1KrDJFf3s0X+1vREOjV8iVOYOJJMoJEhU7j9Id+F SA+B6UPc6FlUQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 48HV9K6t0jzFpWt; Wed, 12 Feb 2020 07:29:25 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 12 Feb 2020 07:29:25 +0100 From: To: "tcpm@ietf.org" , =?iso-8859-1?Q?_Mirja_K=FChlewind_=28IETF=29_?= Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-15.txt Thread-Index: AQHV4S4I7ZackcevMUi3ZJ5ZCosMMagXFVKw Date: Wed, 12 Feb 2020 06:29:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031437937@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158146158037.20043.3218096522600291865@ietfa.amsl.com> In-Reply-To: <158146158037.20043.3218096522600291865@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-15.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 06:29:32 -0000 Hi all, We updated the draft to address Mirja's review. The main changes are as fol= low:=20 * Clarify the behavior for handling errors and terminating connections * Move many of the annexes to the core text (SOCKS, address preservation/sh= aring, implementation design choice) * Withdraw the IANA request for a specific port * Add guidelines for IANA expert review * and some other edits to enhance the readability of the document. Cheers, Olivier & Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mardi 11 f=E9vrier 2020 23:53 > =C0=A0: i-d-announce@ietf.org > Cc=A0: tcpm@ietf.org > Objet=A0: [tcpm] I-D Action: draft-ietf-tcpm-converters-15.txt >=20 >=20 > 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. >=20 > Title : 0-RTT TCP Convert Protocol > Authors : Olivier Bonaventure > Mohamed Boucadair > Sri Gundavelli > SungHoon Seo > Benjamin Hesmans > Filename : draft-ietf-tcpm-converters-15.txt > Pages : 53 > Date : 2020-02-11 >=20 > Abstract: > This document specifies an application proxy, called Transport > Converter, to assist the deployment of TCP extensions such as > Multipath TCP. A Transport Converter may provide conversion > service > for one or more TCP extensions. The conversion service is provided > by means of the TCP Convert Protocol (Convert). >=20 > This protocol provides 0-RTT (Zero Round-Trip Time) conversion > service since no extra delay is induced by the protocol compared to > connections that are not proxied. Also, the Convert Protocol does > not require any encapsulation (no tunnels, whatsoever). >=20 > This specification assumes an explicit model, where the Transport > Converter is explicitly configured on hosts. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-converters-15 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-15 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-15 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Feb 12 06:30:41 2020 Return-Path: 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 951B412001E for ; Wed, 12 Feb 2020 06:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 zy6hUzColSVf for ; Wed, 12 Feb 2020 06:30:36 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840C512003E for ; Wed, 12 Feb 2020 06:30:35 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Wed, 12 Feb 2020 16:30:11 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:message-id:mime-version:content-type; s=dkim20130528; bh=d/MdeWM/LNvWSK5kMfQYJFq8XQZK1BwpgK/aCbdglug=; b= RCSDCjZiylbh22rpvay3Z4Aagu5JWg+MiKiCbVeb9i6lKorICYwb+NQE4kyJ8LI8 /5jgEo6oohFrAbF7X076AwsTVcYGuc0ZAd4P4DwkYNWsWwZQfl/jP48ZitDzKpmB Bk3VANtK5BLdCkwgPo8XIPdm+gbJUoXLuuaiqse++ek= Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Wed, 12 Feb 2020 16:30:11 +0200 id 00000000005A017D.000000005E440BF3.00005E65 Date: Wed, 12 Feb 2020 16:30:11 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: tcpm@ietf.org cc: Bob Briscoe , Mirja Kuehlewind , Richard Scheffenegger Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Archived-At: Subject: [tcpm] draft-ietf-tcpm-accurate-ecn-09 review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 14:30:40 -0000 Hi, Here is a list of comments/suggestions for the Accurate ECN draft. In general I find it odd that the draft only addresses ACK reordering in Appendix as it's very important for the robustness of the counters (ensuring they are never decreasing). I think it would be helpful from implementer point-of-view to have a table about all detectable failure conditions and how to respond to each. Technical challenges and issues CEP init CEP initialization seems problematic as it varies depending on the feedback but if there are more than one value that was fed back, the endpoints do not know what the other end received. Initializing to the same value always is one possibility, otherwise the end point needs to keep track if it sent and CE feedback and act according to that, the other end will catch up once ACE feedback starts. Even more complex approach would count the number of CEs but I'm not sure if there would be any advantage from that (and the initial value could overflow right at the start). Change-triggered ACKs A change-triggered ACK is not enough for the other end to reconstruct the ECN sequence because AccECN option in that particular ACK will (almost always) update two counters by-definition. Therefore, the AccECN option should be included into the change-triggered ACK and into _the next ACK_ after that. The latter will unambiguously indicate which of the byte counters is currently increasing. I'd also put AccECN option into every segment that changes ACE field to better allow using CEB to detect / rule out ACE overflows (the algorithm given in Appendix). Estimation hopefully get it right but ceb is most crucial to receive when there is congestion (and the TCP header will be changing anyway in this case because of the ACE field update). 24-bit counter updates If an endpoint estimates the counter, unsigned delta update cannot backtrack a counter when the estimation got it wrong (due to ACK loss or ACK reordering). The delta should be treated as 24-bit signed value to allow corrections to down direction. A long run of ECN field may overflow the byte counter if the AccECN option is not sent often enough. The option should sent like every 2^22 received as then the currently increasing counter cannot overflow before the option gets scheduled again. Mostly editorial things Sect 2.2 "The LSBs of each of the three byte counters are carried in the AccECN Option." I found the double "of" structure somewhat hard to read. Also, the use of "LSBs" here is somewhat problematic because it was slightly earlier defined as "(three) least significant bits" and here nothing indicates that now it is 24 bits with the option. Sect 2.3 cyling -> cycling "The Data Receiver is required not to delay sending an ACK to such an extent that the ACE field would cycle." ...there's a "Yoda English" tone in the "required not" which is likely opposite of what you intend to say here. Sect 3.1.1. "The following exceptional cases need some explanation: ECN Nonce: ..." The "exceptional cases" sounds as it would somehow relate to the cases in the table 2 (but it does not). To further confusion, "ECN Nonce" really appears in the table too. At minimum, it would be useful the swap the "ECN Nonce" and "Simul. open" cases to break the strong ECN Nonce connection. But perhaps also the introductory wording could be better too to distance it from the table 2 cases. Sect 3.1.2. "An AccECN host (client or server) MUST ignore the three remaining reserved TCP header flags on all packets." Is this appropriate to do, as now non-AccECN related RFCs claiming those bits would have to update this RFC, AFAICT? Sect 3.2.2. Table 3 does not show how to set the client should set the ACE field, despite the preceeding paragraph clearly assuming it does. Either Table 3 needs to be adjusted or another table added which just contains a straightforward SYN/ACK ECN field value -> reflector bits mapping. Sect 5. Doesn't mention reordering at all? "to ensure that any blocking of anomalous values is always at least under reversible policy control." ...I failed to understand what this fragment tried to say. Appendix A.1. "On the arrival of an AccECN Option, the Data Sender uses the TCP acknowledgement number and any SACK options to calculate newlyAckedB," SACK required? "If newlyAckedB is negative it means that a more up to date ACK has already been processed, so this ACK has been superseded and the Data Sender has to ignore the AccECN Option." By definition, "newlyAckedB" cannot be negative! "if (newlyAckedB >= 0) {" newlyAckedB == 0 is problematic when there's ACK reordering? There's better condition in other algorithm which takes advantage of timestamps (when) present later in the Appendices. "d.ceb = (ECEB + DIVOPT - (s.ceb % DIVOPT)) % DIVOPT" "+ DIVOPT" and the first "% DIVOPT" look superflucious to me given modular arithmetic is being used here. Appendix A.2.2. "s = d.ceb/d.cep" Leads to divide by zero (both are defined as unsigned integers). There should be a special case to handle the zero d.cep correctly rather than assuming there suddenly are floats with infinity representation in use in running code (in the later example, "s=infinite" is assumed to be calculatable w/o an DBZ exception). In the illustration, MSS/2 in Y-axis is really MSS/SAFETY_FACTOR, should it be mentioned somehow? I'd drop the number grouping commas from small values "1,460" and "10,200", etc (it's also used inconsistently). The ~33M values (in A.1) is probably the only one where the commas add some value for the reader. Appendix A.3. "However it would be simpler to merely maintain a counter packets_in_flight for the number of packets in flight (including control packets), which it could update once per RTT." I'm not convinced that this is very simple either. Given that flightsize is maintained more frequently than once per RTT which likely leads to some tricky corner cases when their values are out of sync. Appendix A.5. 2nd para, last sentence: "transmissions" -> "retransmissions"? -- i. From nobody Thu Feb 13 09:38:05 2020 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F790120058; Thu, 13 Feb 2020 09:38:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <158161548327.20540.10776937500861455326@ietfa.amsl.com> Date: Thu, 13 Feb 2020 09:38:03 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-16.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 17:38:03 -0000 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 : 0-RTT TCP Convert Protocol Authors : Olivier Bonaventure Mohamed Boucadair Sri Gundavelli SungHoon Seo Benjamin Hesmans Filename : draft-ietf-tcpm-converters-16.txt Pages : 53 Date : 2020-02-13 Abstract: This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the TCP Convert Protocol (Convert). This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels, whatsoever). This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-converters-16 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-16 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/ From nobody Thu Feb 13 09:44:24 2020 Return-Path: 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 D7FFD1200C3 for ; Thu, 13 Feb 2020 09:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 p1kYOxawf-WB for ; Thu, 13 Feb 2020 09:44:21 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0FD9120058 for ; Thu, 13 Feb 2020 09:44:20 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 48JP5b1H23z3928 for ; Thu, 13 Feb 2020 18:44:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1581615859; bh=fNVmBC9qY2/9HHfBbMhObfvnz3cJ2yKyhrVjwya83Cc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=rvD4C2BYIxtrYeMcuXqCWBWebV9i5gv4SHku3IPuORd+VGz9712BCtWFeyao7IoQ7 ezBcOMZ0NQAyKsjKxWNA2m3CH9An1umUkatvurf4sD5P/uZFcnhf4m6VXDR3XhUkOT mSq57NyzbFWeKV7ahIEq3UzHzUuJA9IOATIHdsbJtUqrsiDasSxcJjIMLcNWSkioUi ggv9tpkXv3tYCYlucIToZFo0/gVVhIGYNfvNN2lZ+JordPUHIuWoK32dRb22bLQFgI nSFXFoAUqqm4oNvz05bFhglVnMxrMj8VkxC9xGlfEAQrMNE2Vv12OJv8WUoVjnQSvG D17RffHKXRG1A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 48JP5b0Z5pzCqkX for ; Thu, 13 Feb 2020 18:44:19 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM44.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 13 Feb 2020 18:44:18 +0100 From: To: "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-16.txt Thread-Index: AQHV4pRgFB0YNzg4sEuhnNz/CLjYb6gZZMNQ Date: Thu, 13 Feb 2020 17:44:17 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031438995@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158161548327.20540.10776937500861455326@ietfa.amsl.com> In-Reply-To: <158161548327.20540.10776937500861455326@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-16.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 17:44:23 -0000 Hi all,=20 This is a minor rev to prepare the document for the IETF LC. We removed the= text about creating a mailing list for design expert review as per a sugge= stion from Mirja. Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: jeudi 13 f=E9vrier 2020 18:38 > =C0=A0: i-d-announce@ietf.org > Cc=A0: tcpm@ietf.org > Objet=A0: [tcpm] I-D Action: draft-ietf-tcpm-converters-16.txt >=20 >=20 > 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. >=20 > Title : 0-RTT TCP Convert Protocol > Authors : Olivier Bonaventure > Mohamed Boucadair > Sri Gundavelli > SungHoon Seo > Benjamin Hesmans > Filename : draft-ietf-tcpm-converters-16.txt > Pages : 53 > Date : 2020-02-13 >=20 > Abstract: > This document specifies an application proxy, called Transport > Converter, to assist the deployment of TCP extensions such as > Multipath TCP. A Transport Converter may provide conversion > service > for one or more TCP extensions. The conversion service is provided > by means of the TCP Convert Protocol (Convert). >=20 > This protocol provides 0-RTT (Zero Round-Trip Time) conversion > service since no extra delay is induced by the protocol compared to > connections that are not proxied. Also, the Convert Protocol does > not require any encapsulation (no tunnels, whatsoever). >=20 > This specification assumes an explicit model, where the Transport > Converter is explicitly configured on hosts. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-converters-16 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-16 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-16 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Feb 13 10:13:00 2020 Return-Path: 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 8B74F120180 for ; Thu, 13 Feb 2020 10:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 iciguQC10Z7L for ; Thu, 13 Feb 2020 10:12:56 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F5E1201A3 for ; Thu, 13 Feb 2020 10:12:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id B896225A28 for ; Thu, 13 Feb 2020 19:12:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1581617574; bh=4rDvDAmrj16KHjRUeo2oNmF3Bz/N+C6u7yBpB5LERR4=; h=From:To:Subject:Date:From; b=dR5+lkjkFlOQI9v28WnjczlLG1MSTMVLm9qVIZPWHoVIW7rXozwGmCsIM1j3BR0Da JwQ/T0I+vi7rDoFuRvTMCtJMeWLsEcpbcLc7L8UsWxi/fw5WY3PwpCSZaQbz5qdeJd ryrKsh742Fy4cdDxdm8cSjYJFJx5SvDJ78xp1X1Q= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6fK5LcSh6Vo for ; Thu, 13 Feb 2020 19:12:53 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Thu, 13 Feb 2020 19:12:53 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.214]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Thu, 13 Feb 2020 19:12:53 +0100 From: "Scharf, Michael" To: tcpm IETF list Thread-Topic: Latest changes to draft-ietf-tcpm-converters Thread-Index: AdXimRD4+wi41hiqQjacbk0bxxW+KQ== Date: Thu, 13 Feb 2020 18:12:52 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D940D4E@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Latest changes to draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 18:12:59 -0000 Hi all, The AD review has resulted in a number of changes. Nonetheless, the suggest= ion is to directly head to IETF last call in order to finish this document. If somebody insists in a second WGLC in TCPM to review these changes, pleas= e speak up *now* (i.e., within the next two days). By default I will assume= that a second WGLC in TCPM is not needed for this EXP document, as the lat= est changes can also be discussed as part of an IETF last call. Thanks Michael (as document shepherd) -----Original Message----- From: tcpm On Behalf Of mohamed.boucadair@orange.co= m Sent: Thursday, February 13, 2020 6:44 PM To: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-16.txt Hi all,=20 This is a minor rev to prepare the document for the IETF LC. We removed the= text about creating a mailing list for design expert review as per a sugge= stion from Mirja. Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: jeudi 13 f=E9vrier 2020 18:38 > =C0=A0: i-d-announce@ietf.org > Cc=A0: tcpm@ietf.org > Objet=A0: [tcpm] I-D Action: draft-ietf-tcpm-converters-16.txt >=20 >=20 > 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. >=20 > Title : 0-RTT TCP Convert Protocol > Authors : Olivier Bonaventure > Mohamed Boucadair > Sri Gundavelli > SungHoon Seo > Benjamin Hesmans > Filename : draft-ietf-tcpm-converters-16.txt > Pages : 53 > Date : 2020-02-13 >=20 > Abstract: > This document specifies an application proxy, called Transport > Converter, to assist the deployment of TCP extensions such as > Multipath TCP. A Transport Converter may provide conversion > service > for one or more TCP extensions. The conversion service is provided > by means of the TCP Convert Protocol (Convert). >=20 > This protocol provides 0-RTT (Zero Round-Trip Time) conversion > service since no extra delay is induced by the protocol compared to > connections that are not proxied. Also, the Convert Protocol does > not require any encapsulation (no tunnels, whatsoever). >=20 > This specification assumes an explicit model, where the Transport > Converter is explicitly configured on hosts. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-converters-16 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-16 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-16 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 From nobody Thu Feb 13 10:54:20 2020 Return-Path: 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 8E03D1201AA; Thu, 13 Feb 2020 10:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 r4F2Fs0R4Cpx; Thu, 13 Feb 2020 10:54:15 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 16AE91201CE; Thu, 13 Feb 2020 10:54:15 -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:From:References:To:Subject:Sender: Reply-To:Cc: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=4gtMwg2cU/LuJMGo/29Ja5HqPLVGDC4wcboJPrjWQss=; b=TqHp79plcVdcN2CIN1TUT6X/GJ sLr6UY02kFGAxHfAp5m+J6nM1uDP8B8D0KA8xb5IaCKxMPeTKRA+poZrIS2heT2aWNwvRSAlkrsJQ OIEjOFb9wZcSMLZF7xp91vpzsc1ElYDo5rAGkvI43+jQQcEFnSgt8X2kHK3Ru6nQhQ3ZU13H5vh44 /e3Grjodd6kIvztIYxQtE/qB7jdqzbOuS8/F+iD/F06R/ccq4fwqYIcsESyD+8dyw0KvJFGZR6V7Q wWqDfmKKP6sIECM1T9Tuo9pZmOMqMohyOSh+5V06Dzkq9d8f5c5Nnnfv28KbmUkY2jPl7P/g9+1I7 LnOFmMzg==; Received: from [31.185.128.125] (port=38744 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j2Jcr-0007Ra-4L; Thu, 13 Feb 2020 18:54:13 +0000 To: "Scheffenegger, Richard" , "tcpm@ietf.org" , draft-ietf-tcpm-generalized-ecn@ietf.org References: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> From: Bob Briscoe Message-ID: <22b78b59-9203-ff08-e888-e7911726cf00@bobbriscoe.net> Date: Thu, 13 Feb 2020 18:54:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com 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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] ECN++ X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 18:54:18 -0000 Richard, On 10/01/2020 00:08, Scheffenegger, Richard wrote: > Marcelo, Bob, > > I just noted that there is a slight oversight in FreeBSD currently, > which results in all session that are simultaneously ECN-enabled and > SACK-permitted to effectively send out retransmissions with the ECT0 > codepoint. > > Strictly speaking, this is in violation of RFC3168, but might also be a > good (nearly a decade long) validation of the performance of ECN++ for > all types of data segments (new and retransmitted ones), although at a > low and implicit exposure... [BB] Let's hope someone has captured some relevant data. > > > On that note, since I think ECN++ is quite valuable (with a number of > published research finding this change to be crucial), perhaps you can > summarize the outstanding issues (other than more reviewers required; I > admit I still haven't gone through all the delta between -04 and -05). [BB] I don't think there are any outstanding issues. I have some word-smithing in my ToDo list, in the light of the most recently agreed change regarding ECT on SYN. But no new technical controversy, AFAICT. Bob > > Best regards, >   Richard > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Feb 13 10:55:33 2020 Return-Path: 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 BEA6E1201AA; Thu, 13 Feb 2020 10:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 4nnD7G-jpTCU; Thu, 13 Feb 2020 10:55:28 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 D23061201DE; Thu, 13 Feb 2020 10:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding: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=hQtogS8zje0nPBg/vswsjbnooG2ubYh3/v/WlwNx+lk=; b=xUQdAtUfRR+PGubKKNpDp9J3T /JPFgcSTmZlWAe/UdPATN3s11H8h5TGfeS7DGkX5FBHvcH3xib1FC+IF/iFSMJbNdkG9Ju8Yr1fdo ixqUIgEocN7zXa6DBzRT7nLimlvWb6RTGOQ8q/A01ii7LFnCJtmUs++AfVgjGA5CXk7Q5M5ObAmju GvEvvubDWTYxroKl4pzFtge6XhmiNUZ4a+yOZJIwRBsHW5noG6QJpn0TtkTHn6m9vZTCjBTHVl/el iy7Q+L/JOuZT9DEMI2dezQ09r77/LarehI5B4hjUut7Kmubp9FrxzZSXJqRFhX/GACfpRmgUB52Xq 6HifN5pXw==; Received: from [31.185.128.125] (port=38748 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j2Je2-0007aL-8Z; Thu, 13 Feb 2020 18:55:26 +0000 To: "Scheffenegger, Richard" , "tcpm@ietf.org" , draft-ietf-tcpm-generalized-ecn@ietf.org, FreeBSD Transport , Neal Cardwell , Christoph Paasch , Vidhi Goel , Rodney Grimes , Michael Tuexen References: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> From: Bob Briscoe Message-ID: Date: Thu, 13 Feb 2020 18:55:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> Content-Type: multipart/alternative; boundary="------------A2846A054008F1DBA6755C06" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com 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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] ECN++ X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 18:55:30 -0000 This is a multi-part message in MIME format. --------------A2846A054008F1DBA6755C06 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Richard, On 15/01/2020 20:42, Scheffenegger, Richard wrote: > > Hi, > > Yet another interesting observation – as fbsd currently doesn’t refrain > from marking SACK-retransmission to be not-ECT, you can actually end up > getting a CE mark on a retransmission across a ECN-enabled congestion > point. > > Obviously this is better than loss… > > What happens next is, that fbsd "honors" that ECE mark, since it is in > loss-recovery, not congestion-recovery. It adjusts the recovery_point to > the current snd_max (rightmost sent segment), and adjusts ssthresh and > cwnd by multiplicative decrease factor... > > Furthermore, it appears that it also resets the traversal of the SACK > scoreboard (incidential a "good" thing, as a few earlier retransmissions > also got dropped, not marked, and are being resent without an RTO). > > But in the context of ECN++, what would be the expected response here? [BB] Quoting 3.2.7.  Retransmissions (Send) https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-3.2.7 If the TCP sender receives feedback that a retransmitted packet was CE-marked, it will react as it would to any feedback of CE-marking on a data packet. In the ECN++ draft, we tried not to be too prescriptive or inventive about congestion behaviour. The draft is intended to focus on the sender's wire protocol behaviour, and refer to the default congestion response but not require it, so that other congestion control schemes can specify different responses without having to update the ECN++ draft. Bob > > I assume, that with the exception of the fresh traversal of the SACK > scoreboard, the above steps seem sensible. > > Any thoughts on this interesting interaction between ECE (during SACK > loss recovery)? > > Best regards, >    Richard > > > > Am 10.01.2020 um 01:08 schrieb Scheffenegger, Richard: >> Marcelo, Bob, >> >> I just noted that there is a slight oversight in FreeBSD currently, >> which results in all session that are simultaneously ECN-enabled and >> SACK-permitted to effectively send out retransmissions with the ECT0 >> codepoint. >> >> Strictly speaking, this is in violation of RFC3168, but might also be a >> good (nearly a decade long) validation of the performance of ECN++ for >> all types of data segments (new and retransmitted ones), although at a >> low and implicit exposure... >> >> >> On that note, since I think ECN++ is quite valuable (with a number of >> published research finding this change to be crucial), perhaps you can >> summarize the outstanding issues (other than more reviewers required; I >> admit I still haven't gone through all the delta between -04 and -05). >> >> Best regards, >>    Richard >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------A2846A054008F1DBA6755C06 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Richard,

On 15/01/2020 20:42, Scheffenegger, Richard wrote:

Hi,

Yet another interesting observation – as fbsd currently doesn’t refrain
from marking SACK-retransmission to be not-ECT, you can actually end up
getting a CE mark on a retransmission across a ECN-enabled congestion point.

Obviously this is better than loss…

What happens next is, that fbsd "honors" that ECE mark, since it is in
loss-recovery, not congestion-recovery. It adjusts the recovery_point to
the current snd_max (rightmost sent segment), and adjusts ssthresh and
cwnd by multiplicative decrease factor...

Furthermore, it appears that it also resets the traversal of the SACK
scoreboard (incidential a "good" thing, as a few earlier retransmissions
also got dropped, not marked, and are being resent without an RTO).

But in the context of ECN++, what would be the expected response here?
[BB] Quoting 3.2.7.  Retransmissions (Send)
https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-3.2.7
   If the TCP sender receives feedback that a retransmitted packet was
   CE-marked, it will react as it would to any feedback of CE-marking on
   a data packet.
In the ECN++ draft, we tried not to be too prescriptive or inventive about congestion behaviour. The draft is intended to focus on the sender's wire protocol behaviour, and refer to the default congestion response but not require it, so that other congestion control schemes can specify different responses without having to update the ECN++ draft.


Bob

I assume, that with the exception of the fresh traversal of the SACK
scoreboard, the above steps seem sensible.

Any thoughts on this interesting interaction between ECE (during SACK
loss recovery)?

Best regards,
   Richard



Am 10.01.2020 um 01:08 schrieb Scheffenegger, Richard:
Marcelo, Bob,

I just noted that there is a slight oversight in FreeBSD currently,
which results in all session that are simultaneously ECN-enabled and
SACK-permitted to effectively send out retransmissions with the ECT0
codepoint.

Strictly speaking, this is in violation of RFC3168, but might also be a
good (nearly a decade long) validation of the performance of ECN++ for
all types of data segments (new and retransmitted ones), although at a
low and implicit exposure...


On that note, since I think ECN++ is quite valuable (with a number of
published research finding this change to be crucial), perhaps you can
summarize the outstanding issues (other than more reviewers required; I
admit I still haven't gone through all the delta between -04 and -05).

Best regards,
   Richard

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm 


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------A2846A054008F1DBA6755C06-- From nobody Thu Feb 13 10:58:36 2020 Return-Path: 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 0ECA11201DE; Thu, 13 Feb 2020 10:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 S1Wi-e1Uoah8; Thu, 13 Feb 2020 10:58:30 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 6048D1201CE; Thu, 13 Feb 2020 10:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding: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=/7Uikwm73EsTQoem4YYnNf7IDiYSApCzvc/6wppE8VE=; b=H79qVytCvdyyQaSR5rJON2TON WCpOFuN/bYZFlx/65sYhvmlo8ZaSPJMg6Xe8xjB2qv37IVO0OOs3eRl2jkQRCNOytaAAMddNi5DB0 SZ7bbljkHlqQhRj2qwK8BqWbF4Ic9Ors4VLgyT947eES9tizLFzujpNYt/dfrCET9FWTA1MYu2yaH HXA6kuG/+dpva/30PRkyRUK3wzy7nQ9WnNO8MxUgEcK4uLBIMDrbA5uZQQpi7QkviEJVL5yDfMZ+0 ypuG668Ys8EAelMF9ec/bElzD/dQNUJEjGMKozYLGYHiMd+ZeAGz0mWAAzEmV6Z8dXxu/dcpCxkjk XwhWVDWSg==; Received: from [31.185.128.125] (port=38756 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j2Jgx-0007xV-7p; Thu, 13 Feb 2020 18:58:27 +0000 To: "Scheffenegger, Richard" , "tcpm@ietf.org" , draft-ietf-tcpm-generalized-ecn@ietf.org, FreeBSD Transport , Neal Cardwell , Christoph Paasch , Vidhi Goel , Rodney Grimes , Michael Tuexen References: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> From: Bob Briscoe Message-ID: <80dd5b8c-c45c-8777-da61-812a563d4b9f@bobbriscoe.net> Date: Thu, 13 Feb 2020 18:58:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------85323A2925F403298598B5BE" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com 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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] ECN++ X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 18:58:34 -0000 This is a multi-part message in MIME format. --------------85323A2925F403298598B5BE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Richard, Interesting. See inline tagged [BB]... On 25/01/2020 10:41, Scheffenegger, Richard wrote: > Hi Group, Marcelo, Bob, > > > Another update in this context, which IMHO may be discussed as an actual > change of mechanism with ECN++. > > I was looking into the very poor interaction of ECN between a Linux > client and a BSD server, with request-response workload. That is, where > each side sends out less than MSS data, before the application waits for > the other side to respond to this. > > Neal pointed out this statement in RFC3168: > >    ...the TCP sender sets the CWR flag in >    the TCP header of the first new data packet sent after the window >    reduction.  ... >    When the TCP data sender is ready to set the CWR bit after reducing >    the congestion window, it SHOULD set the CWR bit only on the first >    new data packet that it transmits. > > However, BSD is sending out the CWR as soon as possible - while Linux > interprets the SHOULD overly strictly (IMHO) and ignores CWR unless it > is received with (new) data. [BB] Assuming the word '(new)' is optional, I think you're implying that BSD would set CWR on a pure ACK if that were its first packet after it received ECE feedback. Does BSD also set CWR on the first data packet after that (if any)? I think RFC3168 expects CWR only on data packets - so that the sender of the CWR can distinguish between ECE that the receiver sends before vs after the receiver got the CWR (by whether the ackno of the ECE covers the CWR data packet or not). Consider 4 data packet exchanges of A>B, B>A, B>A, A>B with CWR on pure ACKs.     A>>>B Data#1     A<<>>B ACK#101 *CWR*                             ...potentially quiet for a time...     A<<>>B ACK#102                             ...potentially quiet for a time...     A>>>B Data#2 *CWR* ACK#102     A<< > But binding the CWR flag to a new data segment delays the ECN signaling > loop artificially (for long runs of unidirectional transmitted data), > and it is not clear what the benefit there would be, as the CWR flag is > not retransmitted anyway (thus not bound to a point in the sequence > number space). [BB] Surely long runs of unidirectional transmitted data don't exhibit this problem, 'cos there's plenty of new data to carry the CWR. Or have I misunderstood? In fact, the problem I see with RFC3168 is the opposite case. It seems there was an assumption that a data sender would be continually sending data, so that, once ECE feedback appeared at the sender, it would conveniently always have some data to send, on which CWR could be carried. For instance, in the sequence above, host A might not send Data#2 for ages or perhaps never (a typical case if 'A' is a client requesting a large object). In the intervening time, B might send far more than the two packets shown. If 'A' does not set CWR on pure ACKs, all B's data packets would have to carry ECE, perhaps for many hours, until A has some more data to send (if ever). Nontheless, I think ECE continuing for hours is fine within the logic of RFC3168. While A isn't sending anything, it only reduces cwnd once, and it's not measuring any round trips, so it's not increasing cwnd either. Can you describe your case more precisely, so I can understand what caused the performance hit? > > I therefore propose a change in the Generalized ECN draft, to lift the > above restriction (while it is "only" a SHOULD, this is one more example > of an overly strict receiving-side implementation), and no longer > artificially delay the CWR signal - to become also more useful for > passive measurements. [BB] I'm not yet convinced that this CWR behaviour is anything to do with the ECN++ draft. But that might be because I've misunderstood your description. As I said above, it might be possible to rectify omissions with an erratum to RFC3168. more... > > > Richard > > For those interested: The effect of ignoring the CWR on non-new-data > segments by Linux is, that the ECE flag is left latched. Thus BSD > continues window-after-window with cwnd reductions, [BB] If it's not sending new data, how does the BSD host consider that windows are starting or completing? Bob > and due to another > bug where the ECN-induced reduction has no lower bound, eventually cwnd > ends up at 0 Byte and is only increased to 1 Byte by a Timer - until by > pure chance, the CWR is sent together with 1 new byte of data. But in > the preceeding minutes, the session only saw progress by less than 1 > byte / RTT... > > > Am 15.01.2020 um 21:42 schrieb Scheffenegger, Richard: >> >> Hi, >> >> Yet another interesting observation – as fbsd currently doesn’t refrain >> from marking SACK-retransmission to be not-ECT, you can actually end up >> getting a CE mark on a retransmission across a ECN-enabled congestion >> point. >> >> Obviously this is better than loss… >> >> What happens next is, that fbsd "honors" that ECE mark, since it is in >> loss-recovery, not congestion-recovery. It adjusts the recovery_point to >> the current snd_max (rightmost sent segment), and adjusts ssthresh and >> cwnd by multiplicative decrease factor... >> >> Furthermore, it appears that it also resets the traversal of the SACK >> scoreboard (incidential a "good" thing, as a few earlier retransmissions >> also got dropped, not marked, and are being resent without an RTO). >> >> But in the context of ECN++, what would be the expected response here? >> >> I assume, that with the exception of the fresh traversal of the SACK >> scoreboard, the above steps seem sensible. >> >> Any thoughts on this interesting interaction between ECE (during SACK >> loss recovery)? >> >> Best regards, >>     Richard >> >> >> >> Am 10.01.2020 um 01:08 schrieb Scheffenegger, Richard: >>> Marcelo, Bob, >>> >>> I just noted that there is a slight oversight in FreeBSD currently, >>> which results in all session that are simultaneously ECN-enabled and >>> SACK-permitted to effectively send out retransmissions with the ECT0 >>> codepoint. >>> >>> Strictly speaking, this is in violation of RFC3168, but might also be a >>> good (nearly a decade long) validation of the performance of ECN++ for >>> all types of data segments (new and retransmitted ones), although at a >>> low and implicit exposure... >>> >>> On that note, since I think ECN++ is quite valuable (with a number of >>> published research finding this change to be crucial), perhaps you can >>> summarize the outstanding issues (other than more reviewers required; I >>> admit I still haven't gone through all the delta between -04 and -05). >>> >>> Best regards, >>>    Richard >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------85323A2925F403298598B5BE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Richard,

Interesting.
See inline tagged [BB]...

On 25/01/2020 10:41, Scheffenegger, Richard wrote:
Hi Group, Marcelo, Bob,


Another update in this context, which IMHO may be discussed as an actual
change of mechanism with ECN++.

I was looking into the very poor interaction of ECN between a Linux
client and a BSD server, with request-response workload. That is, where
each side sends out less than MSS data, before the application waits for
the other side to respond to this.

Neal pointed out this statement in RFC3168:

   ...the TCP sender sets the CWR flag in
   the TCP header of the first new data packet sent after the window
   reduction.  ...
   When the TCP data sender is ready to set the CWR bit after reducing
   the congestion window, it SHOULD set the CWR bit only on the first
   new data packet that it transmits.

However, BSD is sending out the CWR as soon as possible - while Linux
interprets the SHOULD overly strictly (IMHO) and ignores CWR unless it
is received with (new) data.
[BB] Assuming the word '(new)' is optional, I think you're implying that BSD would set CWR on a pure ACK if that were its first packet after it received ECE feedback. Does BSD also set CWR on the first data packet after that (if any)?

I think RFC3168 expects CWR only on data packets - so that the sender of the CWR can distinguish between ECE that the receiver sends before vs after the receiver got the CWR (by whether the ackno of the ECE covers the CWR data packet or not).

Consider 4 data packet exchanges of A>B, B>A, B>A, A>B with CWR on pure ACKs.

    A>>>B Data#1 <CE in transit>
    A<<<B ACK#1 ECE
                            ...potentially quiet for a time...
    A<<<B Data#101 ECE ACK#1
    A>>>B ACK#101 CWR
                            ...potentially quiet for a time...
    A<<<B Data#102 ECE ACK#1
    A>>>B ACK#102
                            ...potentially quiet for a time...
    A>>>B Data#2 CWR ACK#102
    A<<<B ACK#2

'A' doesn't know whether the ECE on Data#102 was sent before or after B received the CWR on A's pure ACK, so 'A' doesn't know whether to reduce its window again or not.

I can't find anything in RFC3168 that explicitly spells out when the sender considers ECE to be in a new round. It jumps straight to describing the exceptional case of a CWR packet being dropped, and omits the 'normal' case of it being delivered.

This seems to be missing - perhaps it ought to be added by an erratum.


But binding the CWR flag to a new data segment delays the ECN signaling
loop artificially (for long runs of unidirectional transmitted data),
and it is not clear what the benefit there would be, as the CWR flag is
not retransmitted anyway (thus not bound to a point in the sequence
number space).
[BB] Surely long runs of unidirectional transmitted data don't exhibit this problem, 'cos there's plenty of new data to carry the CWR. Or have I misunderstood?

In fact, the problem I see with RFC3168 is the opposite case. It seems there was an assumption that a data sender would be continually sending data, so that, once ECE feedback appeared at the sender, it would conveniently always have some data to send, on which CWR could be carried.

For instance, in the sequence above, host A might not send Data#2 for ages or perhaps never (a typical case if 'A' is a client requesting a large object). In the intervening time, B might send far more than the two packets shown. If 'A' does not set CWR on pure ACKs, all B's data packets would have to carry ECE, perhaps for many hours, until A has some more data to send (if ever).

Nontheless, I think ECE continuing for hours is fine within the logic of RFC3168. While A isn't sending anything, it only reduces cwnd once, and it's not measuring any round trips, so it's not increasing cwnd either.

Can you describe your case more precisely, so I can understand what caused the performance hit?



I therefore propose a change in the Generalized ECN draft, to lift the
above restriction (while it is "only" a SHOULD, this is one more example
of an overly strict receiving-side implementation), and no longer
artificially delay the CWR signal - to become also more useful for
passive measurements.
[BB] I'm not yet convinced that this CWR behaviour is anything to do with the ECN++ draft. But that might be because I've misunderstood your description. As I said above, it might be possible to rectify omissions with an erratum to RFC3168.

more...



Richard

For those interested: The effect of ignoring the CWR on non-new-data
segments by Linux is, that the ECE flag is left latched. Thus BSD
continues window-after-window with cwnd reductions,
[BB] If it's not sending new data, how does the BSD host consider that windows are starting or completing?


Bob


and due to another
bug where the ECN-induced reduction has no lower bound, eventually cwnd
ends up at 0 Byte and is only increased to 1 Byte by a Timer - until by
pure chance, the CWR is sent together with 1 new byte of data. But in
the preceeding minutes, the session only saw progress by less than 1
byte / RTT...


Am 15.01.2020 um 21:42 schrieb Scheffenegger, Richard:

Hi,

Yet another interesting observation – as fbsd currently doesn’t refrain
from marking SACK-retransmission to be not-ECT, you can actually end up
getting a CE mark on a retransmission across a ECN-enabled congestion
point.

Obviously this is better than loss…

What happens next is, that fbsd "honors" that ECE mark, since it is in
loss-recovery, not congestion-recovery. It adjusts the recovery_point to
the current snd_max (rightmost sent segment), and adjusts ssthresh and
cwnd by multiplicative decrease factor...

Furthermore, it appears that it also resets the traversal of the SACK
scoreboard (incidential a "good" thing, as a few earlier retransmissions
also got dropped, not marked, and are being resent without an RTO).

But in the context of ECN++, what would be the expected response here?

I assume, that with the exception of the fresh traversal of the SACK
scoreboard, the above steps seem sensible.

Any thoughts on this interesting interaction between ECE (during SACK
loss recovery)?

Best regards,
    Richard



Am 10.01.2020 um 01:08 schrieb Scheffenegger, Richard:
Marcelo, Bob,

I just noted that there is a slight oversight in FreeBSD currently,
which results in all session that are simultaneously ECN-enabled and
SACK-permitted to effectively send out retransmissions with the ECT0
codepoint.

Strictly speaking, this is in violation of RFC3168, but might also be a
good (nearly a decade long) validation of the performance of ECN++ for
all types of data segments (new and retransmitted ones), although at a
low and implicit exposure...

On that note, since I think ECN++ is quite valuable (with a number of
published research finding this change to be crucial), perhaps you can
summarize the outstanding issues (other than more reviewers required; I
admit I still haven't gone through all the delta between -04 and -05).

Best regards,
   Richard

_______________________________________________
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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------85323A2925F403298598B5BE-- From nobody Fri Feb 14 04:22:43 2020 Return-Path: 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 20DBE120827 for ; Fri, 14 Feb 2020 04:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 wrhhp_PHCi6X for ; Fri, 14 Feb 2020 04:22:37 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815CD1200DE for ; Fri, 14 Feb 2020 04:22:36 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Fri, 14 Feb 2020 14:22:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:subject:message-id:mime-version:content-type; s= dkim20130528; bh=eWzQpJMdfcIZLM1cSo8nZIGv8TG3aQ6OZzXP0ZF46o0=; b= iY7q4qU0xN5zJGwvLGoBU4T5EoD8sqe+xkK8kymNZY+WfX91G4bm7jl4Epq3Egxk ISqqLg+Gqme3j8WGqtrMaLWnunKg1mDrZrdQAB6BfaGKLLW+qawUsuli2ZuTJIyG Y6V0svlSMRaAvnj0THfqkOLzpc3kf2QIkUetjLRvQqo= Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Fri, 14 Feb 2020 14:22:30 +0200 id 00000000005A0170.000000005E469106.00002BC5 Date: Fri, 14 Feb 2020 14:22:30 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: tcpm@ietf.org, Yuchung Cheng , Neal Cardwell , nanditad@google.com, priyarjha@google.com Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Archived-At: Subject: [tcpm] Review of draft-ietf-tcpm-rack-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 12:22:41 -0000 In general, I find the draft quite good shape already, it's quite easy to read and follow (that is, except the TLP sections that are specifically mentioned below). Here's the list of issues I came across: Sect 6.1 "RACK.pkts_sacked" lacks the empty line separator. Sect 7.2 "This heuristic would fail to update RACK stats if the packet is spuriously retransmitted because of a recent minimum RTT decrease (e.g. path change)." This defies my logic as RTT decrease should not result in spurious retransmissions but help to avoid them. "Note that extensions that require additional TCP features (e.g. DSACK) would work if the feature functions simply return false." Please rephrase this. I suspect you meant that if some functions relate to TCP features that are not available, the given code still works as long as the functions related to such features return false when the TCP feature is not available but that surely isn't what the sentence currently says. Sect 7.2 Step 5 "For timely loss detection, the sender MAY install a "reordering settling" timer set to fire at the earliest moment at which it is safe to conclude that some packet is lost. The earliest moment is the time it takes to expire the reordering window of the earliest unacked packet in flight." vs RACK_detect_loss(): ... timeout = max(remaining, timeout) Which way it is, "some" or "all"? The use of max() in RACK_detect_lost() seems to indicate that the timeout will be set according to the longest time, that is, the latest moment rather than earliest moments. Which is the intented behavior here? (I can there might be merits in both approaches). In general, I didn't like the presentation order here as this form looks the most obvious to me: now >= Packet.xmit_ts + RACK.reo_wnd + (RACK.ack_ts - RACK.xmit_ts) ...and I find the derivation of it just complicating things rather than helping but that's perhaps just my opinion. "It is also useful when the timestamp clock granularity is close to or longer than the actual round trip time." Given that some things based on timestamps will obviously stop working if the clock is slower than one tick per RTT I found this fragment a bit odd. RFC 7323 says "the clock SHOULD tick at least once per window's worth of data". I can understand though that a host might find clock tick granularity challenging due to extensive RTT range but on the same I'd not want such a "too slow clock" behavior to be endorsed as if it would be just normal. That is, I'm not against RACK handling also this case nicely but it would be nice to somehow downplay the normalness tone in it with something along the lines of "This check is also useful if the recommended one tick per RTT cannot be achieved due to timestamp clock granularity." Is RACK_detect_lost() supposed to detect also lost rexmits? How? The rexmit code itself is not in the draft so it's hard to evaluate how the Packet booleans are supposed to work in the first place. I'm not saying the rexmit code should be included but currently it surely looks like any rexmitted packet just remains .lost = TRUE and .retransmitted = TRUE state until RTO? Sect 7.4 "PTO" just appears out of nowhere (and is not even written open in the first instance). "2. ... in step (2) of the algorithm." "step (2)" is forward-refing, it would naturally refer back to "Step 2: Update RACK stats" so it makes very little sense as is. Sect 7.5 Separator missing for PTO: and TLPRxtOut: Sect 7.5.1 "3. Upon receiving a SACK that selectively acknowledges data that was last sent before the segment with SEG.SEQ=SND.UNA was last (re)transmitted" This is hard to understand, perhaps rephrase it somehow? "But choosing PTO to be exactly an SRTT is likely to generate spurious probes given that network delay variance and even end-system timings can easily push an ACK to be above an SRTT. We chose PTO to be the next integral multiple of SRTT. Similarly, network delay variations and end-system processing latencies and timer granularities can easily delay ACKs beyond 2*SRTT, so senders SHOULD add at least 2ms to a computed PTO value (and MAY add more if the sending host OS timer granularity is more coarse than 1ms)." Does this later paragraph depend on some assumptions (such as very low RTT?) as I don't otherwise understand why you say what you say in the given order. First you said x & y can push ACK over SRTT so we pick 2* but then you say the same things can push over 2*SRTT too? WCDelAckT to terminology? Sect 7.5.2 TLP_send_probe(): - Perhaps set TLPRxtOut somewhere? - Add "Arm RTO" to the end? "In the case where there is only one original outstanding segment of data (N=1), the same logic (trivially) applies: an ACK for a single outstanding segment tells the sender the N-1=0 segments preceding that segment were lost. Furthermore, whether there are N>1 or N=1 outstanding segments," If this distinction is useful to make at all, maybe just simply say: "Applies also in case N=1." Sect 7.6 "SND.NXT at the time the episode started." Isn't this TLPHighRxt, why not use it here? Sect 7.6.2 "Upon sending a TLP probe that is a retransmission, the sender sets TLPRxtOut to true and TLPHighRxt to SND.NXT." This should appear in TLP_send_probe(). "Detecting recoveries accomplished by loss probes" Did you want to start another section here? "Step 1: Track ACKs ..." until what point? (It's told on later but this question comes into mind when reading the draft in order). Sect 7.4 - 7.6.2 In general, this particular part of the draft seems to require some further editing. After reading it all through, I feel most bits are present but the text is very hard to follow. I think the presentation order needs significant work. There are random bits here and there that are explained only later. Also, algorithm lacks some parts discussed only in the text but variable like items should definitely be included to the algorithm. Sect 8.4 "RACK is compatible with and does not interfere with the the standard RTO [RFC6298], RTO-restart [RFC7765], F-RTO [RFC5682] and Eifel algorithms [RFC3522]. ... It neither changes the RTO timer calculation nor detects spurious timeouts." For F-RTO, also send order is significant. Sect 8.5 SHOULDs PRR (and also placed to normative references) that is only experimental and RACK aims to standards track. I feel that PRR is disjoint enough anyway, which I think was also your intention when maintaining the decoupling CC and RACK, that it's bit odd to take this strong stance on PRR (indepedent of the stds track vs experimental thing). "due to congestion window validation." Does this refer to CWV as in RFC? Or some other mechanism in which case you shouldn't use the same term here. I find the described scenario somewhat unconvincing becase the description ends with: "... The ending congestion window after recovery also impacts subsequent data transfer." ...First there wasn't enough data to fill cwnd of 20 packets and then suddenly transferring that non-existing data is impacted. References QUIC-LR is very old ref and even the filename has changed a few times from draft-tsvwg-... Nits "runt" made the sentence incomprehendable for me, I had to look up that word (and only second source was descriptive enough that I think I could understand the meaning, and I'd guessed wrong because I thought there was some special intent here because of the quotes). is dicussed -> is discussed RACT.RTT -> RACK.rtt First "TSO" -> TCP Segmentation Offload (TSO) grainularity -> granularity higher-sequenc -> higher-sequence -- i. From nobody Fri Feb 14 06:49:29 2020 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D01120041; Fri, 14 Feb 2020 06:49:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: tcpm@ietf.org, Michael Scharf , michael.scharf@hs-esslingen.de, ietf@kuehlewind.net, draft-ietf-tcpm-converters@ietf.org, tcpm-chairs@ietf.org Content-Transfer-Encoding: 7bit Reply-To: last-call@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158169176500.16207.2996121621784504167.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2020 06:49:25 -0800 Archived-At: Subject: [tcpm] Last Call: (0-RTT TCP Convert Protocol) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 14:49:26 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - '0-RTT TCP Convert Protocol' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-02-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the TCP Convert Protocol (Convert). This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels, whatsoever). This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3616/ From nobody Fri Feb 14 11:27:05 2020 Return-Path: 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 73C51120B33 for ; Fri, 14 Feb 2020 11:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 uCq9ChoLCUPM for ; Fri, 14 Feb 2020 11:26:57 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 0B8B9120A3A for ; Fri, 14 Feb 2020 11:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:Subject:From:Sender:Reply-To: Content-Transfer-Encoding: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=2XftWMX4uOHKAL28cZWrisE96IeKCZuBk30Ul6PXvfI=; b=AUhaqp3/gGBzZD32lBsrwT5/v NzqBZtuFKppyQRUkceaUM42w8u5DM05H0KOB9uDuWpO2mEV3TdorCJ7ky6ktC20KaZPZKdRgVUdTD UlhKwRoOKKSMiwiTmpvN5O8Ho5CHbqiPWFt5M9rcoBxNVrJS+fN6/92gzytJH7DOTbB8rkRXLEuRv ByVlyHxL6sFB6s+Wb7/252iKdInGGa8CQfHBO0uE9ZROlTeIAHiF4ffnF5+hsmp6y2koPUU093qd5 2jO5+rbVFPll2UkMft/rmClh4bYLjofvIWo+ehIpxzUVjmSSvP7mOpdMKUdyHziy3ZdTfO47eckDi txR1XqzxQ==; Received: from [31.185.128.125] (port=60840 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j2gc1-0001yE-4l; Fri, 14 Feb 2020 19:26:53 +0000 From: Bob Briscoe To: =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= , Mirja Kuehlewind , Richard Scheffenegger Cc: tcpm@ietf.org References: Message-ID: Date: Fri, 14 Feb 2020 19:26:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FCB25285D740AC592CC2F4B2" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com 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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09 review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 19:27:03 -0000 This is a multi-part message in MIME format. --------------FCB25285D740AC592CC2F4B2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Ilpo, (and Mirja, there's some questions directed at you (or Richard) near the end), Thank you for this careful in-depth review. Inline... On 12/02/2020 14:30, Ilpo Järvinen wrote: > Hi, > > Here is a list of comments/suggestions for the Accurate ECN draft. > > > In general > > I find it odd that the draft only addresses ACK reordering in Appendix > as it's very important for the robustness of the counters (ensuring > they are never decreasing). > > I think it would be helpful from implementer point-of-view to have > a table about all detectable failure conditions and how to respond to > each. [BB] That would be useful. Given I believe you've now implemented the full spec, and come up with numerous corner cases, would you be willing to help to produce this table? > > Technical challenges and issues > > > CEP init > > CEP initialization seems problematic as it varies depending on the > feedback but if there are more than one value that was fed back, > the endpoints do not know what the other end received. Initializing > to the same value always is one possibility, otherwise the end point > needs to keep track if it sent and CE feedback and act according to > that, the other end will catch up once ACE feedback starts. Even more > complex approach would count the number of CEs but I'm not sure if > there would be any advantage from that (and the initial value could > overflow right at the start). [BB] I think I might have already mentioned on this list that from draft-10 onwards we (the co-authors) already wanted to change to require that this counter does always initialize to one value. This was primarily motivated by thinking about how to introduce future extensions by using different initial values. We then realized we shouldn't unnecessarily burn more than one value from the start. Also, this info was already delivered reliably during the 3WHS, so incrementing the ACE counter was redundant (and we had to check and handle the possibility that the two redundant values were inconsistent). I have already written the text for this change in our candidate for draft-10. I have also rationalized the draft, to bring together initialization of sender and receiver counters into one section (previously the section was only for sender counters, and initialization of receiver counters was elsewhere). > Change-triggered ACKs > > A change-triggered ACK is not enough for the other end to reconstruct > the ECN sequence because AccECN option in that particular ACK will > (almost always) update two counters by-definition. Therefore, the > AccECN option should be included into the change-triggered ACK and > into _the next ACK_ after that. The latter will unambiguously indicate > which of the byte counters is currently increasing. > > I'd also put AccECN option into every segment that changes ACE > field to better allow using CEB to detect / rule out ACE overflows > (the algorithm given in Appendix). Estimation hopefully get it > right but ceb is most crucial to receive when there is congestion > (and the TCP header will be changing anyway in this case because > of the ACE field update). [BB] Both these suggestions sound reasonable, altho they will lead to more frequent AccECN Options (for those implementations that choose to use options). I'll write these into draft-10 unless anyone objects. > > 24-bit counter updates > > If an endpoint estimates the counter, unsigned delta update cannot > backtrack a counter when the estimation got it wrong (due to ACK > loss or ACK reordering). The delta should be treated as 24-bit > signed value to allow corrections to down direction. [BB] That seems easy to fix. However, I can't see that the appendix states that the delta is unsigned. If you're talking about Appx A.1, it only says the counter is unsigned. It doesn't mention what the delta is. Or are you concerned about this sentence and the pseudocode under it: Otherwise, the Data Sender calculates the minimum difference d.ceb between the ECEB field and its local s.ceb counter, using modulo arithmetic as follows: which doesn't mention that d.ceb is unsigned. Perhaps you are concerned about ambiguity, given different programming languages define modulo arithmetic with signed types differently? > A long run of ECN field may overflow the byte counter if the > AccECN option is not sent often enough. The option should sent like every > 2^22 received as then the currently increasing counter cannot overflow > before the option gets scheduled again. '[BB] Again, this seems like a simple fix. To be clear, are you saying this should be added to the list of rules in 3.2.8 for when a Data Receiver includes an Option on an ACK? > > Mostly editorial things > > Sect 2.2 > > "The LSBs of each of the three byte counters are carried in > the AccECN Option." > > I found the double "of" structure somewhat hard to read. > Also, the use of "LSBs" here is somewhat problematic because > it was slightly earlier defined as "(three) least significant > bits" and here nothing indicates that now it is 24 bits with > the option. [BB] OK. Changed to "The 24 LSBs of each byte counter are carried in the AccECN Option" To be frank, I think "The 24 LSBs of each of the three byte counter are carried in the AccECN Option" would be better, but if you (as a non-native English speaker) tripped over it, I'm not going to argue. > Sect 2.3 > cyling -> cycling > > "The Data > Receiver is required not to delay sending an ACK to such an extent > that the ACE field would cycle." > ...there's a "Yoda English" tone in the "required not" which > is likely opposite of what you intend to say here. [BB] Changed to "The Data Receiver is not allowed to delay sending an ACK to such an extent that the ACE field would cycle." > Sect 3.1.1. > > "The following exceptional cases need some explanation: > > ECN Nonce: ..." > > The "exceptional cases" sounds as it would somehow relate to the > cases in the table 2 (but it does not). To further confusion,using > "ECN Nonce" really appears in the table too. At minimum, it would > be useful the swap the "ECN Nonce" and "Simul. open" cases to break > the strong ECN Nonce connection. But perhaps also the introductory > wording could be better too to distance it from the table 2 cases. [BB] OK. I've moved this Nonce wording to the end of the words about block 2. And I've introduced the Simul. open rule with "The following additional rule does not fit the structure of the table, but complements it:" > Sect 3.1.2. > > "An AccECN host (client or server) MUST ignore the three remaining > reserved TCP header flags on all packets." > > Is this appropriate to do, as now non-AccECN related RFCs claiming > those bits would have to update this RFC, AFAICT? [BB] Reworded non-normatively: For the avoidance of doubt, the behaviour described in the present specification applies whether or not the three remaining reserved TCP header flags are zero. > Sect 3.2.2. > > Table 3 does not show how to set the client should set the ACE field, > despite the preceeding paragraph clearly assuming it does. Either > Table 3 needs to be adjusted or another table added which just contains > a straightforward SYN/ACK ECN field value -> reflector bits mapping. [BB] Good point. I've kept the table (which is for reading the field and only for writing it by implication). But I've changed the first sentence to: There is only one exception to this rule: On the final ACK of the 3-way handshake (3WHS), a TCP client (A) in AccECN mode MUST feed back which of the 4 possible values of the IP-ECN field were on the SYN/ACK using the same binary encoding as that used on the SYN/ACK (see Table 2). Table 3 shows the meaning of each possible value... Do you think this reference to Table 2 is clear enough? Or do you think we ought to produce a small 4x2 table repeating the relevant 4 codes? > Sect 5. > > Doesn't mention reordering at all? [BB] Added the following at the end of the Resilience bullet: And if data or ACKs are reordered, stale congestion information can be identified and ignored. And at the end of the bullet listing 3 ways in which AccECN is not resilient to reordering:       Following ACK reordering, the Data Sender can       reconstruct the order in which feedback was sent, but not until       all the missing feedback has arrived. Did you have anything else specific in mind? > "to ensure that any blocking of anomalous values is > always at least under reversible policy control." > ...I failed to understand what this fragment tried to say. [BB] OK, I admit that's rather impenetrable wording. How about: Then, the designers of security devices can understand which currently unused values might appear in future. So, even if they choose to treat such values as anomalous while they are not widely used, any blocking will at least be under policy control not hard-coded. Then, if previously unused values start to appear on the Internet (or in standards), such policies could be quickly reversed. > > Appendix A.1. > > "On the arrival of an AccECN Option, the Data Sender uses the TCP > acknowledgement number and any SACK options to calculate newlyAckedB," > SACK required? [BB] Surely the words 'and any' makes it clear that SACK is not required. Do you mean that you believe this is impossible without SACK? > "If > newlyAckedB is negative it means that a more up to date ACK has > already been processed, so this ACK has been superseded and the Data > Sender has to ignore the AccECN Option." > By definition, "newlyAckedB" cannot be negative! [BB] OK, this block of text is used twice. I agree it's confusing. Would "if there are no newly ACKd octets" be acceptable? Then in the pseudocode,     "if (newlyAckedB){" This doesn't include the ACK reordering case (see next). > "if (newlyAckedB >= 0) {" > newlyAckedB == 0 is problematic when there's ACK reordering? There's better > condition in other algorithm which takes advantage of timestamps (when) > present later in the Appendices. [BB] I'm not sure what you want me to do here. Note also that we need to say something for the case when timestamps are not available. > "d.ceb = (ECEB + DIVOPT - (s.ceb % DIVOPT)) % DIVOPT" > "+ DIVOPT" and the first "% DIVOPT" look superflucious to me given > modular arithmetic is being used here. [BB] With many compilers (e.g. C99), the value of d.ceb using the example decimal values given just below that statement (s.ceb = 33,554,433; ECEB = 1461, DIVOPT = 2^24) would be non-positive without the first "% DIVOPT", but non-negative with it. The first % DIVOPT ensures that the value in the inner parenthesis is <=DIVOPT so the result of the subtraction is non-negative, which is what you want, in case the field wraps. Incidentally, once you can rely on d.ceb being non-negative, you can produce optimized code like this:     #define DIV_MASK DIVOPT-1     d.ceb = (ECEB + DIVOPT - (s.ceb & DIVOPT_MASK)) & DIVOPT_MASK I'm pretty sure a compiler would not be able to do this for you, 'cos it would have to prove to itself that the subtraction is always non-negative, which would be a rather clever compiler. While researching this answer, I've discovered that the draft ought to define % as the remainder operator, not the modulo operator. I learned that, with a remainder operator the sign of the result of a%b is the same as the sign of 'a'. While with a modulo operator the sign of the result is the same as 'b'. > Appendix A.2.2. > > "s = d.ceb/d.cep" > Leads to divide by zero (both are defined as unsigned > integers). There should be a special case to handle the zero d.cep > correctly rather than assuming there suddenly are floats with infinity > representation in use in running code (in the later example, > "s=infinite" is assumed to be calculatable w/o an DBZ exception). [BB] The purpose of this pseudocode was to explain, because s represents the apparent prevailing segment size, which is shown in the explanatory plot a little later. I've added comments to tell implementers how to write their code:        s = d.ceb/d.cep        % The next line alone would avoid DBZ        if (s <= MSS) {        % if (d.ceb <= MSS * d.cep) { > > In the illustration, MSS/2 in Y-axis is really MSS/SAFETY_FACTOR, > should it be mentioned somehow? [BB] I've changed it in the illustration to MSS/SAFETY_FACTOR > > I'd drop the number grouping commas from small values "1,460" and > "10,200", etc (it's also used inconsistently). The ~33M values > (in A.1) is probably the only one where the commas add some value > for the reader. [BB] Done. > > Appendix A.3. > > "However it would be simpler to > merely maintain a counter packets_in_flight for the number of packets > in flight (including control packets), which it could update once per > RTT." > I'm not convinced that this is very simple either. Given that flightsize > is maintained more frequently than once per RTT which likely leads to some > tricky corner cases when their values are out of sync. [BB] I think you're right. This is more than a editorial nit. Nonetheless, I think Mirja implemented this then wrote this section. Nonetheless, I think you based your implementation on Olivier's which was based on Mirja's. So if this Estimation algo was not already in your code, that probably means I'm wrong. Mirja? > > Appendix A.5. > > 2nd para, last sentence: "transmissions" -> "retransmissions"? [BB] Done > > [BB] Thank you v much, Ilpo, for these detailed comments. Bob -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------FCB25285D740AC592CC2F4B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ilpo, (and Mirja, there's some questions directed at you (or Richard) near the end),

Thank you for this careful in-depth review. Inline...

On 12/02/2020 14:30, Ilpo Järvinen wrote:
Hi,

Here is a list of comments/suggestions for the Accurate ECN draft.


In general

I find it odd that the draft only addresses ACK reordering in Appendix
as it's very important for the robustness of the counters (ensuring
they are never decreasing).

I think it would be helpful from implementer point-of-view to have
a table about all detectable failure conditions and how to respond to 
each.
[BB] That would be useful. Given I believe you've now implemented the full spec, and come up with numerous corner cases, would you be willing to help to produce this table?

Technical challenges and issues


CEP init

CEP initialization seems problematic as it varies depending on the
feedback but if there are more than one value that was fed back,
the endpoints do not know what the other end received. Initializing
to the same value always is one possibility, otherwise the end point
needs to keep track if it sent and CE feedback and act according to
that, the other end will catch up once ACE feedback starts. Even more
complex approach would count the number of CEs but I'm not sure if
there would be any advantage from that (and the initial value could
overflow right at the start).
[BB] I think I might have already mentioned on this list that from draft-10 onwards we (the co-authors) already wanted to change to require that this counter does always initialize to one value. This was primarily motivated by thinking about how to introduce future extensions by using different initial values. We then realized we shouldn't unnecessarily burn more than one value from the start. Also, this info was already delivered reliably during the 3WHS, so incrementing the ACE counter was redundant (and we had to check and handle the possibility that the two redundant values were inconsistent).

I have already written the text for this change in our candidate for draft-10. I have also rationalized the draft, to bring together initialization of sender and receiver counters into one section (previously the section was only for sender counters, and initialization of receiver counters was elsewhere).

Change-triggered ACKs

A change-triggered ACK is not enough for the other end to reconstruct
the ECN sequence because AccECN option in that particular ACK will
(almost always) update two counters by-definition. Therefore, the
AccECN option should be included into the change-triggered ACK and
into _the next ACK_ after that. The latter will unambiguously indicate
which of the byte counters is currently increasing.

I'd also put AccECN option into every segment that changes ACE
field to better allow using CEB to detect / rule out ACE overflows
(the algorithm given in Appendix). Estimation hopefully get it
right but ceb is most crucial to receive when there is congestion
(and the TCP header will be changing anyway in this case because
of the ACE field update).
[BB] Both these suggestions sound reasonable, altho they will lead to more frequent AccECN Options (for those implementations that choose to use options). I'll write these into draft-10 unless anyone objects.

24-bit counter updates

If an endpoint estimates the counter, unsigned delta update cannot
backtrack a counter when the estimation got it wrong (due to ACK
loss or ACK reordering). The delta should be treated as 24-bit
signed value to allow corrections to down direction.
[BB] That seems easy to fix. However, I can't see that the appendix states that the delta is unsigned. If you're talking about Appx A.1, it only says the counter is unsigned. It doesn't mention what the delta is. Or are you concerned about this sentence and the pseudocode under it:
   Otherwise, the Data Sender
   calculates the minimum difference d.ceb between the ECEB field and
   its local s.ceb counter, using modulo arithmetic as follows:
which doesn't mention that d.ceb is unsigned. Perhaps you are concerned about ambiguity, given different programming languages define modulo arithmetic with signed types differently?


A long run of ECN field may overflow the byte counter if the
AccECN option is not sent often enough. The option should sent like every 
2^22 received as then the currently increasing counter cannot overflow 
before the option gets scheduled again.
'[BB] Again, this seems like a simple fix. To be clear, are you saying this should be added to the list of rules in 3.2.8 for when a Data Receiver includes an Option on an ACK?


Mostly editorial things

Sect 2.2

"The LSBs of each of the three byte counters are carried in
the AccECN Option."

I found the double "of" structure somewhat hard to read.
Also, the use of "LSBs" here is somewhat problematic because
it was slightly earlier defined as "(three) least significant
bits" and here nothing indicates that now it is 24 bits with
the option.
[BB] OK. Changed to "The 24 LSBs of each byte counter are carried in the AccECN Option"
To be frank, I think "The 24 LSBs of each of the three byte counter are carried in the AccECN Option" would be better, but if you (as a non-native English speaker) tripped over it, I'm not going to argue.

Sect 2.3
cyling -> cycling

  "The Data
   Receiver is required not to delay sending an ACK to such an extent
   that the ACE field would cycle."
...there's a "Yoda English" tone in the "required not" which
is likely opposite of what you intend to say here.
[BB] Changed to "The Data Receiver is not allowed to delay sending an ACK to such an extent that the ACE field would cycle."

Sect 3.1.1.

"The following exceptional cases need some explanation:

ECN Nonce: ..."

The "exceptional cases" sounds as it would somehow relate to the
cases in the table 2 (but it does not). To further confusion,using 
"ECN Nonce" really appears in the table too. At minimum, it would
be useful the swap the "ECN Nonce" and "Simul. open" cases to break
the strong ECN Nonce connection. But perhaps also the introductory
wording could be better too to distance it from the table 2 cases.
[BB] OK. I've moved this Nonce wording to the end of the words about block 2.
And I've introduced the Simul. open rule with "The following additional rule does not fit the structure of the table, but complements it:"

Sect 3.1.2.

   "An AccECN host (client or server) MUST ignore the three remaining
   reserved TCP header flags on all packets."
   
Is this appropriate to do, as now non-AccECN related RFCs claiming
those bits would have to update this RFC, AFAICT?
[BB] Reworded non-normatively:
   For the avoidance of doubt, the behaviour described in the present 
   specification applies whether or not the three remaining reserved 
   TCP header flags are zero.
 
Sect 3.2.2.

Table 3 does not show how to set the client should set the ACE field,
despite the preceeding paragraph clearly assuming it does. Either
Table 3 needs to be adjusted or another table added which just contains
a straightforward SYN/ACK ECN field value -> reflector bits mapping.
[BB] Good point. I've kept the table (which is for reading the field and only for writing it by implication). But I've changed the first sentence to:
   There is only one exception to this rule: On the final ACK of the
   3-way handshake (3WHS), a TCP client (A) in AccECN mode MUST feed
   back which of the 4 possible values of the IP-ECN field were on the
   SYN/ACK using the same binary encoding as that used on the SYN/ACK
   (see Table 2).

   Table 3 shows the meaning of each possible value...
Do you think this reference to Table 2 is clear enough? Or do you think we ought to produce a small 4x2 table repeating the relevant 4 codes?

Sect 5.

Doesn't mention reordering at all?
[BB] Added the following at the end of the Resilience bullet:
      And if data or
      ACKs are reordered, stale congestion information can be identified
      and ignored.

And at the end of the bullet listing 3 ways in which AccECN is not resilient to reordering:

      Following ACK reordering, the Data Sender can
      reconstruct the order in which feedback was sent, but not until
      all the missing feedback has arrived.

Did you have anything else specific in mind?

      "to ensure that any blocking of anomalous values is
      always at least under reversible policy control."
...I failed to understand what this fragment tried to say.
[BB] OK, I admit that's rather impenetrable wording. How about:

      Then, the designers of security devices can
      understand which currently unused values might appear in future.
      So, even if they choose to treat such values as anomalous while
      they are not widely used, any blocking will at least be under
      policy control not hard-coded.  Then, if previously unused values
      start to appear on the Internet (or in standards), such policies
      could be quickly reversed.

Appendix A.1.

   "On the arrival of an AccECN Option, the Data Sender uses the TCP
   acknowledgement number and any SACK options to calculate newlyAckedB,"
SACK required?
[BB] Surely the words 'and any' makes it clear that SACK is not required. Do you mean that you believe this is impossible without SACK? 

   "If
   newlyAckedB is negative it means that a more up to date ACK has
   already been processed, so this ACK has been superseded and the Data
   Sender has to ignore the AccECN Option."
By definition, "newlyAckedB" cannot be negative!
[BB] OK, this block of text is used twice. I agree it's confusing.

Would "if there are no newly ACKd octets" be acceptable? Then in the pseudocode,
    "if (newlyAckedB) {"
This doesn't include the ACK reordering case (see next).
   "if (newlyAckedB >= 0) {"
newlyAckedB == 0 is problematic when there's ACK reordering? There's better
condition in other algorithm which takes advantage of timestamps (when)
present later in the Appendices.
[BB] I'm not sure what you want me to do here.
Note also that we need to say something for the case when timestamps are not available.

   "d.ceb = (ECEB + DIVOPT - (s.ceb % DIVOPT)) % DIVOPT"
"+ DIVOPT" and the first "% DIVOPT" look superflucious to me given
modular arithmetic is being used here.
[BB] With many compilers (e.g. C99), the value of d.ceb using the example decimal values given just below that statement (s.ceb = 33,554,433; ECEB = 1461, DIVOPT = 2^24) would be non-positive without the first "% DIVOPT", but non-negative with it.

The first % DIVOPT ensures that the value in the inner parenthesis is <=DIVOPT so the result of the subtraction is non-negative, which is what you want, in case the field wraps.

Incidentally, once you can rely on d.ceb being non-negative, you can produce optimized code like this:    
    #define DIV_MASK DIVOPT-1
    d.ceb = (ECEB + DIVOPT - (s.ceb & DIVOPT_MASK)) & DIVOPT_MASK
I'm pretty sure a compiler would not be able to do this for you, 'cos it would have to prove to itself that the subtraction is always non-negative, which would be a rather clever compiler.

While researching this answer, I've discovered that the draft ought to define % as the remainder operator, not the modulo operator. I learned that, with a remainder operator the sign of the result of a%b is the same as the sign of 'a'. While with a modulo operator the sign of the result is the same as 'b'.


Appendix A.2.2.

   "s = d.ceb/d.cep"
Leads to divide by zero (both are defined as unsigned
integers). There should be a special case to handle the zero d.cep
correctly rather than assuming there suddenly are floats with infinity
representation in use in running code (in the later example,
"s=infinite" is assumed to be calculatable w/o an DBZ exception).
[BB] The purpose of this pseudocode was to explain, because s represents the apparent prevailing segment size, which is shown in the explanatory plot a little later. I've added comments to tell implementers how to write their code:

       s = d.ceb/d.cep        % The next line alone would avoid DBZ
       if (s <= MSS) {        % if (d.ceb <= MSS * d.cep) {



In the illustration, MSS/2 in Y-axis is really MSS/SAFETY_FACTOR,
should it be mentioned somehow?
[BB] I've changed it in the illustration to MSS/SAFETY_FACTOR


I'd drop the number grouping commas from small values "1,460" and
"10,200", etc (it's also used inconsistently). The ~33M values
(in A.1) is probably the only one where the commas add some value
for the reader.
[BB] Done.


Appendix A.3.

    "However it would be simpler to
    merely maintain a counter packets_in_flight for the number of packets
    in flight (including control packets), which it could update once per
    RTT."
I'm not convinced that this is very simple either. Given that flightsize
is maintained more frequently than once per RTT which likely leads to some
tricky corner cases when their values are out of sync.
[BB] I think you're right. This is more than a editorial nit. Nonetheless, I think Mirja implemented this then wrote this section. Nonetheless, I think you based your implementation on Olivier's which was based on Mirja's. So if this Estimation algo was not already in your code, that probably means I'm wrong.

Mirja?



Appendix A.5.

2nd para, last sentence: "transmissions" -> "retransmissions"?
[BB] Done
[BB] Thank you v much, Ilpo, for these detailed comments.


Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------FCB25285D740AC592CC2F4B2-- From nobody Sat Feb 15 08:15:38 2020 Return-Path: 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 195B1120B6B; Fri, 14 Feb 2020 11:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.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 XWKYRH590kJW; Fri, 14 Feb 2020 11:06:29 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2064.outbound.protection.outlook.com [40.107.94.64]) (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 7658F120B49; Fri, 14 Feb 2020 11:06:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZmRixYn3MdTZWFxueKjTtrhc+yTHtjqdRtmU3pbqJenvjVilqL17JKvceCtR99adYudMShTnnpwjXdREVEhp8f18gH1lo7XTaT8PVwUNLCc1bTljsoKLhzvicTWNPv8aqJo++69rqyB4MOtSSu2RBLP3DvI1po+jxQJZqpfiG0XDtKJZX9TeSW3pUZ3v6zsb633vuMKw5E4SPnWXHk9WUgdfISj5xmJ7oX2O907/jK6XEOk+Mkhx5bLy5z89jnLFwhPyCKX43znaYF4UjTAQXDOr89oAQH7JXK1kowwoAXZrGegsnrFinVjJAhjiAZZ86/QuSiBZerePNs3s3rM/UQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vrvzrfzlu6omdFLh/V0MOtzGu8rZ/csfHb7xDV0KSlk=; b=atedNZwaZYv/yAMr9YA80R55WWaakuoB8Of+Mxe9D/o7qBytvPaFxgyiQD24ItuDPgEhqC/vi/FsHKk0DZbC3ksZPcgoO0YSV0dmgRvi0NswRcCF1GCEzT3Qiw8yAcmhcNr2h13WSHr7EgNtl5b7QgbiH4jw+wRDEHgfCWNAslQLsAgLWz/PZVXmj28LRtRIVTy3MIsE+VRS5EVsYxuMQdqhOd/FeXaWx6YHvCkUAkZttDqZAvQHlIHmax6gPzNysHv1JCU41/MBKAEVgy1K87kHb9HEH7de4xfSXM/HSclHjFTM1gR65TjrnzcQcbYYBlHcF8YMFWTg6dWCWCcpcQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=netapp.com; dmarc=pass action=none header.from=netapp.com; dkim=pass header.d=netapp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vrvzrfzlu6omdFLh/V0MOtzGu8rZ/csfHb7xDV0KSlk=; b=eNvOHJS3mNlWOG7++OhA3fCU+fmqSWRNwWFVjq77BFph2i2M8hAcP4WA9y5cmy29g6HtR240v4/vfa64disR6qFjngSQdos0kle5s4DmXSvpnfbzLjshDOMYfDrq5H51rI7Y0BymML8I7d2+A1UlzCEyPTz/4wdtrOPFGEGdPR4= Received: from SN4PR0601MB3728.namprd06.prod.outlook.com (10.167.151.152) by SN4PR0601MB3741.namprd06.prod.outlook.com (10.167.129.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.25; Fri, 14 Feb 2020 19:06:28 +0000 Received: from SN4PR0601MB3728.namprd06.prod.outlook.com ([fe80::3d15:42e8:38bb:2cdd]) by SN4PR0601MB3728.namprd06.prod.outlook.com ([fe80::3d15:42e8:38bb:2cdd%7]) with mapi id 15.20.2729.025; Fri, 14 Feb 2020 19:06:28 +0000 From: "Scheffenegger, Richard" To: Bob Briscoe , "Scheffenegger, Richard" , "tcpm@ietf.org" , "draft-ietf-tcpm-generalized-ecn@ietf.org" , FreeBSD Transport , Neal Cardwell , Christoph Paasch , Vidhi Goel , Rodney Grimes , Michael Tuexen Thread-Topic: [tcpm] ECN++ Thread-Index: AQHV2bRfByuos9fgzkKP2BkJR9Ecy6f7JIgAgB5nMoCAAYmhwA== Date: Fri, 14 Feb 2020 19:06:27 +0000 Message-ID: References: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> <80dd5b8c-c45c-8777-da61-812a563d4b9f@bobbriscoe.net> In-Reply-To: <80dd5b8c-c45c-8777-da61-812a563d4b9f@bobbriscoe.net> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Richard.Scheffenegger@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 55ce9b09-2af5-4c6a-efb4-08d7b180fe84 x-ms-traffictypediagnostic: SN4PR0601MB3741: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03137AC81E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(376002)(346002)(396003)(199004)(189003)(7416002)(5660300002)(2906002)(8936002)(55016002)(52536014)(81156014)(9686003)(8676002)(81166006)(478600001)(64756008)(66446008)(76116006)(66556008)(86362001)(66476007)(7696005)(53546011)(110136005)(6506007)(26005)(186003)(33656002)(66946007)(71200400001)(316002)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN4PR0601MB3741; H:SN4PR0601MB3728.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Z3O5GCdTdOc3F/DH5LURJtEGhFbYVDmTPetagTbwmVXV7KoNbvQbVcWj/MmvN/3NfsXriF2BBkUUT/2HX/E5rjCuNJMlG2iSXwtfFXpHkIc0kLyCRBQkMFrTdygq23JuisGn1DAUsejRmRXlo+vJ/3M1U06jwfBE2OvNiFprFU2kKLedYxKgMnlpWhHUPartN6V7UA1rK8eq2A/8V8Ydhwi9iMP8RDWRMUh49Vps70qkSKQEplcbjT4FX5CXInXShDIeIe7dMUrUq4o3NoDdhteWz0Vc+nWrsj778MKzfVy2cALEpOfD/uK6vDItCidvLSXWzBxv8TlzsYilWDKq4/oXcFsN13KbN1+BIxmOrhTFgWLXDBx095OM5LLl0YDp1TayiU6hcZIcXmPqada2sEGWBT7lE0e2CG1Jb7d5hBDW2v1tmOMseZiQWw4jDuc4gqhbf3nsXAdD2vUBUSRV5fB39MkOwjL7fpWXF8fl8Z2meJglFCW4bSKKfl3rckFN x-ms-exchange-antispam-messagedata: x3sfS544XvDR3+bte8NpvJJzYNr6V0R+dU09iJFgqeIzBO52y3LzFMIi2XYZ1KoCq2F1oAta3Uxsf0Okxet6zkCWgaRAWsSKBkdSYonSiKGgzyWDLn4sWZlGj2XQ0N16VnrFU59Rz3a4a9g5g2q7yA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: netapp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 55ce9b09-2af5-4c6a-efb4-08d7b180fe84 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2020 19:06:27.9340 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: S6SlJKkFedrKKYBR/DL7hce1Js7dcnepXew0MqvEaw9SKZ69z5RnJf53KGs3IDSDBBYUEFfTf34Oipwj8ypqSg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0601MB3741 Archived-At: X-Mailman-Approved-At: Sat, 15 Feb 2020 08:15:37 -0800 Subject: Re: [tcpm] ECN++ X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 19:06:41 -0000 SGkgQm9iLA0KDQoNCj4gSW50ZXJlc3RpbmcuDQo+IFNlZSBpbmxpbmUgdGFnZ2VkIFtCQl0uLi4N Cj4NCj4+IE9uIDI1LzAxLzIwMjAgMTA6NDEsIFNjaGVmZmVuZWdnZXIsIFJpY2hhcmQgd3JvdGU6 DQo+PiBIaSBHcm91cCwgTWFyY2VsbywgQm9iLA0KPj4NCj4+DQo+PiBBbm90aGVyIHVwZGF0ZSBp biB0aGlzIGNvbnRleHQsIHdoaWNoIElNSE8gbWF5IGJlIGRpc2N1c3NlZCBhcyBhbiANCj4+IGFj dHVhbCBjaGFuZ2Ugb2YgbWVjaGFuaXNtIHdpdGggRUNOKysuDQo+Pg0KPj4gSSB3YXMgbG9va2lu ZyBpbnRvIHRoZSB2ZXJ5IHBvb3IgaW50ZXJhY3Rpb24gb2YgRUNOIGJldHdlZW4gYSBMaW51eCAN Cj4+IGNsaWVudCBhbmQgYSBCU0Qgc2VydmVyLCB3aXRoIHJlcXVlc3QtcmVzcG9uc2Ugd29ya2xv YWQuIFRoYXQgaXMsIA0KPj4gd2hlcmUgZWFjaCBzaWRlIHNlbmRzIG91dCBsZXNzIHRoYW4gTVNT IGRhdGEsIGJlZm9yZSB0aGUgYXBwbGljYXRpb24gDQo+PiB3YWl0cyBmb3IgdGhlIG90aGVyIHNp ZGUgdG8gcmVzcG9uZCB0byB0aGlzLg0KPj4NCj4+IE5lYWwgcG9pbnRlZCBvdXQgdGhpcyBzdGF0 ZW1lbnQgaW4gUkZDMzE2ODoNCj4+DQo+PiAgICAuLi50aGUgVENQIHNlbmRlciBzZXRzIHRoZSBD V1IgZmxhZyBpbg0KPj4gICAgdGhlIFRDUCBoZWFkZXIgb2YgdGhlIGZpcnN0IG5ldyBkYXRhIHBh Y2tldCBzZW50IGFmdGVyIHRoZSB3aW5kb3cNCj4+ICAgIHJlZHVjdGlvbi4gIC4uLg0KPj4gICAg V2hlbiB0aGUgVENQIGRhdGEgc2VuZGVyIGlzIHJlYWR5IHRvIHNldCB0aGUgQ1dSIGJpdCBhZnRl ciByZWR1Y2luZw0KPj4gICAgdGhlIGNvbmdlc3Rpb24gd2luZG93LCBpdCBTSE9VTEQgc2V0IHRo ZSBDV1IgYml0IG9ubHkgb24gdGhlIGZpcnN0DQo+PiAgICBuZXcgZGF0YSBwYWNrZXQgdGhhdCBp dCB0cmFuc21pdHMuDQo+Pg0KPj4gSG93ZXZlciwgQlNEIGlzIHNlbmRpbmcgb3V0IHRoZSBDV1Ig YXMgc29vbiBhcyBwb3NzaWJsZSAtIHdoaWxlIExpbnV4IA0KPj4gaW50ZXJwcmV0cyB0aGUgU0hP VUxEIG92ZXJseSBzdHJpY3RseSAoSU1ITykgYW5kIGlnbm9yZXMgQ1dSIHVubGVzcyBpdCANCj4+ IGlzIHJlY2VpdmVkIHdpdGggKG5ldykgZGF0YS4NCj4NCj4gW0JCXSBBc3N1bWluZyB0aGUgd29y ZCAnKG5ldyknIGlzIG9wdGlvbmFsLCBJIHRoaW5rIHlvdSdyZSBpbXBseWluZyB0aGF0IA0KPiBC U0Qgd291bGQgc2V0IENXUiBvbiBhIHB1cmUgQUNLIGlmIHRoYXQgd2VyZSBpdHMgZmlyc3QgcGFj a2V0IGFmdGVyIGl0IA0KPiByZWNlaXZlZCBFQ0UgZmVlZGJhY2suIERvZXMgQlNEIGFsc28gc2V0 IENXUiBvbiB0aGUgZmlyc3QgZGF0YSBwYWNrZXQNCj4gYWZ0ZXIgdGhhdCAoaWYgYW55KT8NCg0K Q3VycmVudGx5LCBGQlNEIGlzIHNlbmRpbmcgQ1dSIHdpdGggdGhlIG5leHQgcGFja2V0IChwdXJl IEFDSywgV2luZG93IA0KUHJvYmUsIFJldHJhbnNtaXNzaW9uIG9yIE5ldyBEYXRhKS4gQnV0IHRo aXMgc2hvdWxkIGJlIGZpeGVkIHNvb24oaXNoKS4NCg0KSSB1c2VkIHRoZSBicmFja2V0IGJlY2F1 c2UgUkZDMzE2OCBpcyB2ZXJ5IGNsZWFyLCB0aGF0IENXUiBzaG91bGQgKm9ubHkqIA0KYmUgc2Vu dCB3aXRoIG5ldyBkYXRhLCBidXQgTGludXggd291bGQgYWxzbyBhY2NlcHQgaXQgb24gYW55IHBh Y2tldCB3aXRoIA0KZGF0YSAodGhpcyBpbmNsdWRlcyByZXRyYW5zbWlzc2lvbnMgYW5kIHdpbmRv dyBwcm9iZXMpLg0KDQoNCj4gSSB0aGluayBSRkMzMTY4IGV4cGVjdHMgQ1dSIG9ubHkgb24gZGF0 YSBwYWNrZXRzIC0gc28gdGhhdCB0aGUgc2VuZGVyIA0KPiBvZiB0aGUgQ1dSIGNhbiBkaXN0aW5n dWlzaCBiZXR3ZWVuIEVDRSB0aGF0IHRoZSByZWNlaXZlciBzZW5kcyBiZWZvcmUgDQo+IHZzIGFm dGVyIHRoZSByZWNlaXZlciBnb3QgdGhlIENXUiAoYnkgd2hldGhlciB0aGUgYWNrbm8gb2YgdGhl IEVDRSANCj4gY292ZXJzIHRoZSBDV1IgZGF0YSBwYWNrZXQgb3Igbm90KS4NCg0KWWVzLCBlZmZl Y3RpdmVseSwgQ1dSIGlzIGJvdW5kIHRvIHNuZF9tYXgrMSBpbiB0aGUgc2VxdWVuY2Ugc3BhY2Ug b24gDQp0aGUgZmlyc3QgdHJhbnNtaXNzaW9uIHdpdGggUkZDMzE2OC4gVW5mb3J0dW5hdGVseSwg aXQncyBub3Qgc3RhdGVkIHRoYXQgDQpjbGVhcmx5Lg0KDQo+IENvbnNpZGVyIDQgZGF0YSBwYWNr ZXQgZXhjaGFuZ2VzIG9mIEE+QiwgQj5BLCBCPkEsIEE+QiB3aXRoIENXUiANCj4gb24gcHVyZSBB Q0tzLg0KPg0KPiAgICAgQT4+PkIgRGF0YSMxIDxDRSBpbiB0cmFuc2l0Pg0KPiAgICAgQTw8PEIg QUNLIzEgRUNFDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuLi5wb3RlbnRpYWxseSBx dWlldCBmb3IgYSB0aW1lLi4uDQo+ICAgICBBPDw8QiBEYXRhIzEwMSBFQ0UgQUNLIzENCj4gICAg IEE+Pj5CIEFDSyMxMDEgKkNXUioNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLnBv dGVudGlhbGx5IHF1aWV0IGZvciBhIHRpbWUuLi4NCj4gICAgIEE8PDxCIERhdGEjMTAyIEVDRSBB Q0sjMQ0KPiAgICAgQT4+PkIgQUNLIzEwMg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Li4ucG90ZW50aWFsbHkgcXVpZXQgZm9yIGEgdGltZS4uLg0KPiAgICAgQT4+PkIgRGF0YSMyICpD V1IqIEFDSyMxMDINCj4gICAgIEE8PDxCIEFDSyMyDQo+DQo+ICdBJyBkb2Vzbid0IGtub3cgd2hl dGhlciB0aGUgRUNFIG9uIERhdGEjMTAyIHdhcyBzZW50IGJlZm9yZSBvciANCj4gYWZ0ZXIgQiBy ZWNlaXZlZCB0aGUgQ1dSIG9uIEEncyBwdXJlIEFDSywgc28gJ0EnIGRvZXNuJ3Qga25vdyANCj4g d2hldGhlciB0byByZWR1Y2UgaXRzIHdpbmRvdyBhZ2FpbiBvciBub3QuDQo+DQo+IEkgY2FuJ3Qg ZmluZCBhbnl0aGluZyBpbiBSRkMzMTY4IHRoYXQgZXhwbGljaXRseSBzcGVsbHMgb3V0IHdoZW4g dGhlIHNlbmRlciANCj4gY29uc2lkZXJzIEVDRSB0byBiZSBpbiBhIG5ldyByb3VuZC4gSXQganVt cHMgc3RyYWlnaHQgdG8gZGVzY3JpYmluZyB0aGUgDQo+IGV4Y2VwdGlvbmFsIGNhc2Ugb2YgYSBD V1IgcGFja2V0IGJlaW5nIGRyb3BwZWQsIGFuZCBvbWl0cyB0aGUgJ25vcm1hbCcgDQo+IGNhc2Ug b2YgaXQgYmVpbmcgZGVsaXZlcmVkLg0KDQpXZWxsLCBpZiB0aGUgRUNFIGRvIG5vdCBzdG9wIHdp dGggdGhlIEFDSyBjb3ZlcmluZyB0aGUgKGZvcm1lcikgc25kX21heCsxLA0KdGhlIENXUiBtYXkg aGF2ZSBiZWVuIGxvc3QgKG9yIGRlbGl2ZXJlZCB3aXRoIGEgQ0UgbWFyaykuIEluIGVpdGhlciBj YXNlLCANCmFub3RoZXIgY29uZ2VzdGlvbiByZXNwb25zZSBpcyBhcHByb3ByaWF0ZS4NCg0KPiBU aGlzIHNlZW1zIHRvIGJlIG1pc3NpbmcgLSBwZXJoYXBzIGl0IG91Z2h0IHRvIGJlIGFkZGVkIGJ5 IGFuIGVycmF0dW0uDQo+DQo+Pg0KPj4gQnV0IGJpbmRpbmcgdGhlIENXUiBmbGFnIHRvIGEgbmV3 IGRhdGEgc2VnbWVudCBkZWxheXMgdGhlIEVDTiANCj4+IHNpZ25hbGluZyBsb29wIGFydGlmaWNp YWxseSAoZm9yIGxvbmcgcnVucyBvZiB1bmlkaXJlY3Rpb25hbCANCj4+IHRyYW5zbWl0dGVkIGRh dGEpLCBhbmQgaXQgaXMgbm90IGNsZWFyIHdoYXQgdGhlIGJlbmVmaXQgdGhlcmUgd291bGQgDQo+ PiBiZSwgYXMgdGhlIENXUiBmbGFnIGlzIG5vdCByZXRyYW5zbWl0dGVkIGFueXdheSAodGh1cyBu b3QgYm91bmQgdG8gYSANCj4+IHBvaW50IGluIHRoZSBzZXF1ZW5jZSBudW1iZXIgc3BhY2UpLg0K Pg0KPiBbQkJdIFN1cmVseSBsb25nIHJ1bnMgb2YgdW5pZGlyZWN0aW9uYWwgdHJhbnNtaXR0ZWQg ZGF0YSBkb24ndCBleGhpYml0IA0KPiB0aGlzIHByb2JsZW0sICdjb3MgdGhlcmUncyBwbGVudHkg b2YgbmV3IGRhdGEgdG8gY2FycnkgdGhlIENXUi4gT3IgDQo+IGhhdmUgSSBtaXN1bmRlcnN0b29k Pw0KDQpUcmFuc2FjdGlvbmFsIGRhdGEgaGFzIGZyZXF1ZW50IGNoYW5nZXMgaW4gZGF0YSBkaXJl Y3Rpb24uIEJ1dCB0aGF0IGJlaGF2aW9yDQooZGVsYXlpbmcgQ1dSIHRvIG9ubHkgc2VuZCBpdCB3 aXRoIG5ldyBkYXRhKSBJTUhPIG1ha2VzIEVDTiB1bnVzYWJsZSBmb3IgQWNrDQpNb2RlcmF0aW9u IChBY2tDQykuIEp1c3Qgd29uZGVyaW5nLCBpZiBhIGRpZmZlcmVudCB3YXkgb2YgdHJhY2tpbmcg dGhlIHBhY2tldHMNCkluIGZsaWdodCBkdXJpbmcgYSB3aW5kb3cgd291bGQgYWxsb3cgdGhlIGlt bWVkaWF0ZSB0cmFuc21pc3Npb24gb2YgQ1dSIA0Kd2l0aCBFQ04rKywgdG8gbWFrZSBFQ04gdXNl ZnVsIGZvciBBY2sgTW9kZXJhdGlvbiBvciBvdGhlciBmdXR1cmUgcHVycG9zZXMuDQoNCj4gSW4g ZmFjdCwgdGhlIHByb2JsZW0gSSBzZWUgd2l0aCBSRkMzMTY4IGlzIHRoZSBvcHBvc2l0ZSBjYXNl LiBJdCBzZWVtcw0KPiB0aGVyZSB3YXMgYW4gYXNzdW1wdGlvbiB0aGF0IGEgZGF0YSBzZW5kZXIg d291bGQgYmUgY29udGludWFsbHkgc2VuZGluZw0KPiBkYXRhLCBzbyB0aGF0LCBvbmNlIEVDRSBm ZWVkYmFjayBhcHBlYXJlZCBhdCB0aGUgc2VuZGVyLCBpdCB3b3VsZCBjb252ZW5pZW50bHkNCj4g YWx3YXlzIGhhdmUgc29tZSBkYXRhIHRvIHNlbmQsIG9uIHdoaWNoIENXUiBjb3VsZCBiZSBjYXJy aWVkLg0KDQpDb3JyZWN0LiBXaXRoIHRyYW5zYWN0aW9uYWwgZGF0YSwgdGhpcyBhc3N1bXB0aW9u IGJyZWFrcyBhbmQgbG9uZyBmbGlnaHRzIG9mIA0KUGFja2V0cyB3aWxsIGNvbnRpbnVvdXNseSBo YXZlIEVDRSBzZXQuDQoNCj4gRm9yIGluc3RhbmNlLCBpbiB0aGUgc2VxdWVuY2UgYWJvdmUsIGhv c3QgQSBtaWdodCBub3Qgc2VuZCBEYXRhIzIgZm9yIGFnZXMgDQo+IG9yIHBlcmhhcHMgbmV2ZXIg KGEgdHlwaWNhbCBjYXNlIGlmICdBJyBpcyBhIGNsaWVudCByZXF1ZXN0aW5nIGEgbGFyZ2Ugb2Jq ZWN0KS4gSW4NCj4gdGhlIGludGVydmVuaW5nIHRpbWUsIEIgbWlnaHQgc2VuZCBmYXIgbW9yZSB0 aGFuIHRoZSB0d28gcGFja2V0cyBzaG93bi4gSWYgJ0EnDQo+IGRvZXMgbm90IHNldCBDV1Igb24g cHVyZSBBQ0tzLCBhbGwgQidzIGRhdGEgcGFja2V0cyB3b3VsZCBoYXZlIHRvIGNhcnJ5IEVDRSwg DQo+IHBlcmhhcHMgZm9yIG1hbnkgaG91cnMsIHVudGlsIEEgaGFzIHNvbWUgbW9yZSBkYXRhIHRv IHNlbmQgKGlmIGV2ZXIpLg0KPg0KPiBOb250aGVsZXNzLCBJIHRoaW5rIEVDRSBjb250aW51aW5n IGZvciBob3VycyBpcyBmaW5lIHdpdGhpbiB0aGUgbG9naWMgb2YgUkZDMzE2OC4gDQo+IFdoaWxl IEEgaXNuJ3Qgc2VuZGluZyBhbnl0aGluZywgaXQgb25seSByZWR1Y2VzIGN3bmQgb25jZSwgYW5k IGl0J3Mgbm90IA0KPiBtZWFzdXJpbmcgYW55IHJvdW5kIHRyaXBzLCBzbyBpdCdzIG5vdCBpbmNy ZWFzaW5nIGN3bmQgZWl0aGVyLg0KPg0KPiBDYW4geW91IGRlc2NyaWJlIHlvdXIgY2FzZSBtb3Jl IHByZWNpc2VseSwgc28gSSBjYW4gdW5kZXJzdGFuZCB3aGF0IGNhdXNlZCANCj4gdGhlIHBlcmZv cm1hbmNlIGhpdD8NCg0KVGhlIHByb2JsZW0gY29tZXMgZnJvbSBGQlNEIHNlbmRpbmcgQ1dSICh0 eXBpY2FsbHkpIG9uIHB1cmUgQUNLcyAtIHdoZXJlDQpMaW51eCBpZ25vcmVzIHRoZSBDV1IgYW5k IGtlZXBzIEVDRSBzZXQ7IFRodXMgRkJTRCBvYnNlcnZlcyAibmV3IiBFQ0UgaW4gdGhlIA0KRm9s bG93aW5nIHdpbmRvdywgcmVzdWx0aW5nIGluIGFub3RoZXIgY29uZ2VzdGlvbiByZXNwb25zZSAt IHdoaWxlIG5vIGZ1cnRoZXINCkNFIG1hcmsgd2FzIGFjdHVhbGx5IHByZXNlbnQuDQoNClRoaXMg bGVhZHMgdG8gYSByYWNlIHRvIHRoZSBib3R0b20gZm9yIEZCU0QsIHdoZXJlIGN3bmQgY29udGlv bm91c2x5IHNocmlua3MgDQooZHVlIHRvIGFub3RoZXIgYnVnLCBkb3duIHRvIGEgc2l6ZSBvZiAw IFt6ZXJvXSkuIEV2ZW50dWFsbHksIEZCU0QgY2xvY2tzIG91dA0KMSBieXRlIGV2ZXJ5IDQgc2Vj b25kcyB3aXRoIGEgdGltZXIgbm9ybWFsbHkgdXNlZCBmb3IgV2luZG93IFByb2JlcyAoYnV0DQpV bmxpa2UgV2luZG93IFByb2JlcywgdGhhdCBvbmUgYnl0ZSBpcyBhY3R1YWxseSBuZXcgZGF0YSku DQoNCkV2ZW50dWFsbHkgQ1dSIG1heSBiZSBzZW50IHdpdGggYSBkYXRhIHBhY2tldCAodGhhdCAx LWJ5dGUgcHJvYmUpLCBhY2NlcHRlZA0KQnkgTGludXgsIEVDRSB1bmxhdGNoZWQsIGFuZCBjd25k IGNhbiBzdGFydCBncm93aW5nIGFnYWluLiBCdXQgdGhhdCBldmVudCBtYXkNCkhhcHBlbiBvbmx5 IG1hbnkgbWludXRlcyBpbnRvIGVudGVyaW5nIHRoaXMgc2l0dWF0aW9uIChnb3QgYSB0cmFjZSwg d2hlcmUgdGhpcyANCmVmZmVjdCBsYXN0ZWQgbmVhcmx5IDEwIG1pbnV0ZXMpLg0KDQpPYnZpb3Vz bHksIHRoZSByZXZlcnNlIGRhdGEgZGlyZWN0aW9uIGRvZXNu4oCZdCBzdWZmZXIgdGhlIHNhbWUg cHJvYmxlbSwgbm9yIGRvZXMNCmEgdHlwaWNhbCBGQlNELUZCU0QgRUNOIHNlc3Npb24gc3VmZmVy IHRoYXQgZmF0ZSAoZXZlbiB0aG91Z2ggQ1dSIGFyZSBzZW50IG1vc3RseQ0Kb24gcHVyZSBBQ0tz KQ0KDQo+Pg0KPj4gSSB0aGVyZWZvcmUgcHJvcG9zZSBhIGNoYW5nZSBpbiB0aGUgR2VuZXJhbGl6 ZWQgRUNOIGRyYWZ0LCB0byBsaWZ0IHRoZSANCj4+IGFib3ZlIHJlc3RyaWN0aW9uICh3aGlsZSBp dCBpcyAib25seSIgYSBTSE9VTEQsIHRoaXMgaXMgb25lIG1vcmUgDQo+PiBleGFtcGxlIG9mIGFu IG92ZXJseSBzdHJpY3QgcmVjZWl2aW5nLXNpZGUgaW1wbGVtZW50YXRpb24pLCBhbmQgbm8gDQo+ PiBsb25nZXIgYXJ0aWZpY2lhbGx5IGRlbGF5IHRoZSBDV1Igc2lnbmFsIC0gdG8gYmVjb21lIGFs c28gbW9yZSB1c2VmdWwgDQo+PiBmb3IgcGFzc2l2ZSBtZWFzdXJlbWVudHMuDQo+DQo+IFtCQl0g SSdtIG5vdCB5ZXQgY29udmluY2VkIHRoYXQgdGhpcyBDV1IgYmVoYXZpb3VyIGlzIGFueXRoaW5n IHRvIGRvIHdpdGggDQo+IHRoZSBFQ04rKyBkcmFmdC4gQnV0IHRoYXQgbWlnaHQgYmUgYmVjYXVz ZSBJJ3ZlIG1pc3VuZGVyc3Rvb2QgeW91ciANCj4gZGVzY3JpcHRpb24uIEFzIEkgc2FpZCBhYm92 ZSwgaXQgbWlnaHQgYmUgcG9zc2libGUgdG8gcmVjdGlmeSBvbWlzc2lvbnMgDQo+IHdpdGggYW4g ZXJyYXR1bSB0byBSRkMzMTY4Lg0KDQpJbiBSRkMzMTY4LCBib3RoIEVDVC1jb2RlcG9pbnRzIGFu ZCB0aGUgQ1dSIGZsYWcgYXJlIGRlZmluZWQgdG8gb25seSBiZSBzZXQgb24NCm5ldyBkYXRhIHNl Z21lbnRzLg0KDQpUaHVzIHNldHRpbmcgYm90aCBjYW4gYmUgc2ltcGxpZmllZCBpbnRvIGEgc2lu Z2xlIGJyYW5jaDsgR2V0dGluZyB0aGUgQ1dSIGluZGljYXRpb24NClNsaWdodGx5IGZhc3RlciAo bm90IGJpbmRpbmcgaXQgdG8gc25kX21heCsxKSwgdGhhdCBpcywgZXZlbiB3aXRoIHRoZSBuZXh0 IHB1cmUgYWNrLCBwcm9iZQ0KT3IgcmV0cmFuc21pc3Npb24sIHdvdWxkIHBvc3NpYmx5IHByb3Zp ZGUgYSBmYXN0ZXIgZmVlZGJhY2sgKHBhc3NpdmUgbWVhc3VyZW1lbnQNCk9mIHRoZSB3aW5kb3cp LCBhbmQgY291bGQgZW5hYmxlIHRoZSB1c2Ugb2YgRUNOIHNpZ25hbHMgZm9yIEFDSyBtb2RlcmF0 aW9uLg0KDQpUaGUgZHJhd2JhY2sgd291bGQgYmUgYWRkaXRpb25hbCBjb25nZXN0aW9uIHJlc3Bv bnNlcywgaWYgdGhlIHBhY2tldCBjYXJyeWluZyB0aGUgQ1dSDQpJcyBkcm9wcGVkIChjb25nZXN0 aW9uIG9uIHRoZSBwYXRoIGNhcnJ5aW5nIHRoZSBwdXJlIEFDS3MpLiBCdXQgSUlSQywgcmVhY3Rp bmcgdG8gY29uZ2VzdGlvbg0KT24gdGhlIChyZWxhdGl2ZWx5KSBsb3cgYmFuZHdpZHRoIHJldmVy c2UgZGlyZWN0aW9uIGJ5IG1vZGVyYXRpbmcgdGhlIHRyYW5zbWlzc2lvbiBzcGVlZCANCihvciBh c2tpbmcgZm9yIGZld2VyIEFDS3MpIG1heSBiZSBub3QgdG9vIGluYXBwcm9wcmlhdGUuLi4NCg0K DQo+bW9yZS4uLg0KDQo+PiBGb3IgdGhvc2UgaW50ZXJlc3RlZDogVGhlIGVmZmVjdCBvZiBpZ25v cmluZyB0aGUgQ1dSIG9uIG5vbi1uZXctZGF0YSANCj4+IHNlZ21lbnRzIGJ5IExpbnV4IGlzLCB0 aGF0IHRoZSBFQ0UgZmxhZyBpcyBsZWZ0IGxhdGNoZWQuIFRodXMgQlNEIA0KPj4gY29udGludWVz IHdpbmRvdy1hZnRlci13aW5kb3cgd2l0aCBjd25kIHJlZHVjdGlvbnMsDQo+DQo+IFtCQl0gSWYg aXQncyBub3Qgc2VuZGluZyBuZXcgZGF0YSwgaG93IGRvZXMgdGhlIEJTRCBob3N0IGNvbnNpZGVy IHRoYXQgDQo+IHdpbmRvd3MgYXJlIHN0YXJ0aW5nIG9yIGNvbXBsZXRpbmc/DQoNCkl0IHN0aWxs IHRyYWNrcyBzbmRfcmVjb3ZlciAoc25kX21heCB3aGVuIHRoZSBmaXJzdCBFQ0UgaXMgcmVjZWl2 ZWQpLiBJIGhhdmUgbm90DQpMb29rZWQgaW50byB0aGlzIGluIGRldGFpbCB5ZXQsIHRob3VnaC4g SXQgbWF5IGV2ZW4gcmVkdWNlIGN3bmQgd2hpbGUgYmVpbmcNClRoZSBwYXNzaXZlIHJlY2VpdmVy Li4uDQoNCj4gQm9iDQoNCg== From nobody Sat Feb 15 08:15:42 2020 Return-Path: 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 85443120052; Sat, 15 Feb 2020 01:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 w9JYOmbQ6TTK; Sat, 15 Feb 2020 01:19:15 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 0841812001E; Sat, 15 Feb 2020 01:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding: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=WAKj0XuPjAxJgnhEtazf9HuL/VD6fy4cCCfMWDHqopQ=; b=gimkRqu9PvGoJyGfNc7AiBys0 eMqGbIsul6UnHJkO8JHiArQq9rsWyMuZ2rcaox8TWM+1aDvN9YkwYLiqaiZuqV8W9GqmKf397CPoN iirkEHk/Fdq3aVXdDqKUMlXSE4WGln8UKxC3kIdGfmoEnq4FXdb/VW7KpgZNlxQb9Gg5T7Pa75nYo d4Lw+PUJKaphQ/3rB2SogQsKCs7iX/HYXZTky5tWCG5pyCsJHszoZ/iFjgH6qL2vAxlwfir+ycsf9 y+/ncKMOJMlOnCVP/2ZBq9Lbb4BGrpjDaVt+ZplRbxlT8Uq9ygfzQEyvgP8ZCXvPzs4G5qRbmN+SE WBNYbsf+w==; Received: from [31.185.128.125] (port=43600 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j2tar-0004HL-Au; Sat, 15 Feb 2020 09:18:33 +0000 To: "Scheffenegger, Richard" , "Scheffenegger, Richard" , "tcpm@ietf.org" , "draft-ietf-tcpm-generalized-ecn@ietf.org" , FreeBSD Transport , Neal Cardwell , Christoph Paasch , Vidhi Goel , Rodney Grimes , Michael Tuexen References: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> <3cd59a2f-d926-769c-175e-91938b962463@gmx.at> <80dd5b8c-c45c-8777-da61-812a563d4b9f@bobbriscoe.net> From: Bob Briscoe Message-ID: <9fad08c4-4fdf-d73c-2a29-9519b74a5d12@bobbriscoe.net> Date: Sat, 15 Feb 2020 09:18:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------36C48E96EA77FE20F4F2B925" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com 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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: X-Mailman-Approved-At: Sat, 15 Feb 2020 08:15:37 -0800 Subject: Re: [tcpm] ECN++ X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 09:19:20 -0000 This is a multi-part message in MIME format. --------------36C48E96EA77FE20F4F2B925 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Richard, (pls cc tsvwg as the WG equally responsible for TCP ECN maintenance, if you think appropriate) On 14/02/2020 19:06, Scheffenegger, Richard wrote: > Hi Bob, > > >> Interesting. >> See inline tagged [BB]... >> >>> On 25/01/2020 10:41, Scheffenegger, Richard wrote: >>> Hi Group, Marcelo, Bob, >>> >>> >>> Another update in this context, which IMHO may be discussed as an >>> actual change of mechanism with ECN++. >>> >>> I was looking into the very poor interaction of ECN between a Linux >>> client and a BSD server, with request-response workload. That is, >>> where each side sends out less than MSS data, before the application >>> waits for the other side to respond to this. >>> >>> Neal pointed out this statement in RFC3168: >>> >>> ...the TCP sender sets the CWR flag in >>> the TCP header of the first new data packet sent after the window >>> reduction. ... >>> When the TCP data sender is ready to set the CWR bit after reducing >>> the congestion window, it SHOULD set the CWR bit only on the first >>> new data packet that it transmits. >>> >>> However, BSD is sending out the CWR as soon as possible - while Linux >>> interprets the SHOULD overly strictly (IMHO) and ignores CWR unless it >>> is received with (new) data. >> [BB] Assuming the word '(new)' is optional, I think you're implying that >> BSD would set CWR on a pure ACK if that were its first packet after it >> received ECE feedback. Does BSD also set CWR on the first data packet >> after that (if any)? > Currently, FBSD is sending CWR with the next packet (pure ACK, Window > Probe, Retransmission or New Data). But this should be fixed soon(ish). > > I used the bracket because RFC3168 is very clear, that CWR should *only* > be sent with new data, but Linux would also accept it on any packet with > data (this includes retransmissions and window probes). > > >> I think RFC3168 expects CWR only on data packets - so that the sender >> of the CWR can distinguish between ECE that the receiver sends before >> vs after the receiver got the CWR (by whether the ackno of the ECE >> covers the CWR data packet or not). > Yes, effectively, CWR is bound to snd_max+1 in the sequence space on > the first transmission with RFC3168. Unfortunately, it's not stated that > clearly. > >> Consider 4 data packet exchanges of A>B, B>A, B>A, A>B with CWR >> on pure ACKs. >> >> A>>>B Data#1 >> A<<> ...potentially quiet for a time... >> A<<> A>>>B ACK#101 *CWR* >> ...potentially quiet for a time... >> A<<> A>>>B ACK#102 >> ...potentially quiet for a time... >> A>>>B Data#2 *CWR* ACK#102 >> A<<> >> 'A' doesn't know whether the ECE on Data#102 was sent before or >> after B received the CWR on A's pure ACK, so 'A' doesn't know >> whether to reduce its window again or not. >> >> I can't find anything in RFC3168 that explicitly spells out when the sender >> considers ECE to be in a new round. It jumps straight to describing the >> exceptional case of a CWR packet being dropped, and omits the 'normal' >> case of it being delivered. > Well, if the ECE do not stop with the ACK covering the (former) snd_max+1, > the CWR may have been lost (or delivered with a CE mark). [BB] Which end are you talking about? As sender or as receiver? Which stage in the sequence are you talking about? Can you be more specific relative to the above example, where there are two transactions in a row initiated from B without any data from A in between. I deliberately constructed this so that A will not be able to tell whether B sent the ECE on its second volley (Data#102) before or after B received the CWR on A's pure ACK of B's first volley (Data#101). My purpose was to prove that, if A sends CWR on a pure ACK, it makes itself unable to tell whether to reduce its window in response to any ECE it receives subsequently, because it cannot tell whether they are new or repeats. Therefore, RFC3168 must have meant 'the TCP sender MUST set the CWR flag in the TCP header of the first new data packet...' when it said: "the TCP sender sets the CWR flag in the TCP header of the first new data packet sent after the window reduction." I suspect no-one thought to preclude the opposite, i.e. to say 'The sender MUST NOT set CWR on packets without new data'. Instead, it went straight to clarifying whether '/first/ new data' needed to be mandatory. "it SHOULD set the CWR bit only on the first new data packet that it transmits" I reviewed RFC3168 at the time, as did many others, but no-one noticed these omissions. > In either case, > another congestion response is appropriate. [BB] Surely not, if the CWR was on a pure ACK? > >> This seems to be missing - perhaps it ought to be added by an erratum. >> >>> But binding the CWR flag to a new data segment delays the ECN >>> signaling loop artificially (for long runs of unidirectional >>> transmitted data), and it is not clear what the benefit there would >>> be, as the CWR flag is not retransmitted anyway (thus not bound to a >>> point in the sequence number space). >> [BB] Surely long runs of unidirectional transmitted data don't exhibit >> this problem, 'cos there's plenty of new data to carry the CWR. Or >> have I misunderstood? > Transactional data has frequent changes in data direction. But that behavior > (delaying CWR to only send it with new data) IMHO makes ECN unusable for Ack > Moderation (AckCC). Just wondering, if a different way of tracking the packets > In flight during a window would allow the immediate transmission of CWR > with ECN++, to make ECN useful for Ack Moderation or other future purposes. [BB] CWR is only used if RFC3168 feedback has been negotiated. The WG consensus was that we shouldn't put ECT on pure ACKs if RFC3168 feedback has been negotiated; only if AccECN had been negotiated. So, once you have AccECN and ECN++, you can do what you are wanting, 'cos AccECN allows both the data receiver to set ECT on pure ACKs and the data sender to count CEs on arriving pure ACKs. The data sender then includes this count in the ACE counter it feeds back on subsequent packets it sends (probably data packets, but could be on pure ACKs as well when data is bi-directional). See https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-3.2.3.2.1 (normative) which refers to https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-4.4.1 (informative) > >> In fact, the problem I see with RFC3168 is the opposite case. It seems >> there was an assumption that a data sender would be continually sending >> data, so that, once ECE feedback appeared at the sender, it would conveniently >> always have some data to send, on which CWR could be carried. > Correct. With transactional data, this assumption breaks and long flights of > Packets will continuously have ECE set. [BB] I have a terminology blockage here. I interpret 'long flights of packets' to be a long-running flow - the opposite of 'transactional data'. But you seem to be using 'long flights of data' to describe 'transactional data'. Not sure what the disconnect is. > >> For instance, in the sequence above, host A might not send Data#2 for ages >> or perhaps never (a typical case if 'A' is a client requesting a large object). In >> the intervening time, B might send far more than the two packets shown. If 'A' >> does not set CWR on pure ACKs, all B's data packets would have to carry ECE, >> perhaps for many hours, until A has some more data to send (if ever). >> >> Nontheless, I think ECE continuing for hours is fine within the logic of RFC3168. >> While A isn't sending anything, it only reduces cwnd once, and it's not >> measuring any round trips, so it's not increasing cwnd either. >> >> Can you describe your case more precisely, so I can understand what caused >> the performance hit? > The problem comes from FBSD sending CWR (typically) on pure ACKs - where > Linux ignores the CWR and keeps ECE set; Thus FBSD observes "new" ECE in the > Following window, resulting in another congestion response - while no further > CE mark was actually present. [BB] I think you are solely talking about the case where sending of each transactional data volley strictly alternates between A and B. I am trying to get you to think about a case where one end sends more than one volley in succession, in order to show that setting CWR on a pure ACK creates problems. That's why I asked, how does an FBSD receiver (or Linux receiver for that matter) know what a 'following window' is if it's only sending pure ACKs? They all have the same seqno and they don't get ACK'd. So the pure receiver can't know what an RTT is. I also asked whether, if the FBSD host (that has been receiving data) does send some data between its pure ACKs, does it repeat the CWR on the data even tho it already set it on an earlier pure ACK? > > This leads to a race to the bottom for FBSD, where cwnd contionously shrinks > (due to another bug, down to a size of 0 [zero]). Eventually, FBSD clocks out > 1 byte every 4 seconds with a timer normally used for Window Probes (but > Unlike Window Probes, that one byte is actually new data). > > Eventually CWR may be sent with a data packet (that 1-byte probe), accepted > By Linux, ECE unlatched, and cwnd can start growing again. But that event may > Happen only many minutes into entering this situation (got a trace, where this > effect lasted nearly 10 minutes). > > Obviously, the reverse data direction doesn’t suffer the same problem, nor does > a typical FBSD-FBSD ECN session suffer that fate (even though CWR are sent mostly > on pure ACKs) > >>> I therefore propose a change in the Generalized ECN draft, to lift the >>> above restriction (while it is "only" a SHOULD, this is one more >>> example of an overly strict receiving-side implementation), and no >>> longer artificially delay the CWR signal - to become also more useful >>> for passive measurements. >> [BB] I'm not yet convinced that this CWR behaviour is anything to do with >> the ECN++ draft. But that might be because I've misunderstood your >> description. As I said above, it might be possible to rectify omissions >> with an erratum to RFC3168. > In RFC3168, both ECT-codepoints and the CWR flag are defined to only be set on > new data segments. [BB] Not strictly true for the CWR flag, as discussed earlier, this part of RFC3168 seems not to have been fully tied up. > > Thus setting both can be simplified into a single branch; Getting the CWR indication > Slightly faster (not binding it to snd_max+1), that is, even with the next pure ack, probe > Or retransmission, would possibly provide a faster feedback (passive measurement > Of the window), and could enable the use of ECN signals for ACK moderation. > > The drawback would be additional congestion responses, if the packet carrying the CWR > Is dropped (congestion on the path carrying the pure ACKs). But IIRC, reacting to congestion > On the (relatively) low bandwidth reverse direction by moderating the transmission speed > (or asking for fewer ACKs) may be not too inappropriate... [BB] I don't believe the CWR mechanism is suitable for faster congestion notification or for Ack CC. The way it's designed is tied in so much to reliable delivery that it actually breaks if you send it unreliably on pure ACKs (as I've tried to prove, and as you have discovered). > > >> more... >>> For those interested: The effect of ignoring the CWR on non-new-data >>> segments by Linux is, that the ECE flag is left latched. Thus BSD >>> continues window-after-window with cwnd reductions, >> [BB] If it's not sending new data, how does the BSD host consider that >> windows are starting or completing? > It still tracks snd_recover (snd_max when the first ECE is received). I have not > Looked into this in detail yet, though. It may even reduce cwnd while being > The passive receiver... [BB] (repeating what I've said already) I don't see how it can know what an RTT is when its continually sending pure ACKs with the same seqno. Cheers Bob > >> Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------36C48E96EA77FE20F4F2B925 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Richard, (pls cc tsvwg as the WG equally responsible for TCP ECN maintenance, if you think appropriate)

On 14/02/2020 19:06, Scheffenegger, Richard wrote:
Hi Bob,



Interesting.
See inline tagged [BB]...


On 25/01/2020 10:41, Scheffenegger, Richard wrote:
Hi Group, Marcelo, Bob,


Another update in this context, which IMHO may be discussed as an 
actual change of mechanism with ECN++.

I was looking into the very poor interaction of ECN between a Linux 
client and a BSD server, with request-response workload. That is, 
where each side sends out less than MSS data, before the application 
waits for the other side to respond to this.

Neal pointed out this statement in RFC3168:

   ...the TCP sender sets the CWR flag in
   the TCP header of the first new data packet sent after the window
   reduction.  ...
   When the TCP data sender is ready to set the CWR bit after reducing
   the congestion window, it SHOULD set the CWR bit only on the first
   new data packet that it transmits.

However, BSD is sending out the CWR as soon as possible - while Linux 
interprets the SHOULD overly strictly (IMHO) and ignores CWR unless it 
is received with (new) data.

[BB] Assuming the word '(new)' is optional, I think you're implying that 
BSD would set CWR on a pure ACK if that were its first packet after it 
received ECE feedback. Does BSD also set CWR on the first data packet
after that (if any)?

Currently, FBSD is sending CWR with the next packet (pure ACK, Window 
Probe, Retransmission or New Data). But this should be fixed soon(ish).

I used the bracket because RFC3168 is very clear, that CWR should *only* 
be sent with new data, but Linux would also accept it on any packet with 
data (this includes retransmissions and window probes).



I think RFC3168 expects CWR only on data packets - so that the sender 
of the CWR can distinguish between ECE that the receiver sends before 
vs after the receiver got the CWR (by whether the ackno of the ECE 
covers the CWR data packet or not).

Yes, effectively, CWR is bound to snd_max+1 in the sequence space on 
the first transmission with RFC3168. Unfortunately, it's not stated that 
clearly.


Consider 4 data packet exchanges of A>B, B>A, B>A, A>B with CWR 
on pure ACKs.

    A>>>B Data#1 <CE in transit>
    A<<<B ACK#1 ECE
                            ...potentially quiet for a time...
    A<<<B Data#101 ECE ACK#1
    A>>>B ACK#101 *CWR*
                            ...potentially quiet for a time...
    A<<<B Data#102 ECE ACK#1
    A>>>B ACK#102
                            ...potentially quiet for a time...
    A>>>B Data#2 *CWR* ACK#102
    A<<<B ACK#2

'A' doesn't know whether the ECE on Data#102 was sent before or 
after B received the CWR on A's pure ACK, so 'A' doesn't know 
whether to reduce its window again or not.

I can't find anything in RFC3168 that explicitly spells out when the sender 
considers ECE to be in a new round. It jumps straight to describing the 
exceptional case of a CWR packet being dropped, and omits the 'normal' 
case of it being delivered.

Well, if the ECE do not stop with the ACK covering the (former) snd_max+1,
the CWR may have been lost (or delivered with a CE mark).
[BB] Which end are you talking about? As sender or as receiver? Which stage in the sequence are you talking about? Can you be more specific relative to the above example, where there are two transactions in a row initiated from B without any data from A in between. I deliberately constructed this so that A will not be able to tell whether B sent the ECE on its second volley (Data#102) before or after B received the CWR on A's pure ACK of B's first volley (Data#101).

My purpose was to prove that, if A sends CWR on a pure ACK, it makes itself unable to tell whether to reduce its window in response to any ECE it receives subsequently, because it cannot tell whether they are new or repeats. Therefore, RFC3168 must have meant 'the TCP sender MUST set the CWR flag in the TCP header of the first new data packet...' when it said:
   "the TCP sender sets the CWR flag in
   the TCP header of the first new data packet sent after the window
   reduction."
I suspect no-one thought to preclude the opposite, i.e. to say 'The sender MUST NOT set CWR on packets without new data'. Instead, it went straight to clarifying whether '/first/ new data' needed to be mandatory.
   "it SHOULD set the CWR bit only on the first
   new data packet that it transmits"
I reviewed RFC3168 at the time, as did many others, but no-one noticed these omissions.

In either case, 
another congestion response is appropriate.
[BB] Surely not, if the CWR was on a pure ACK?



This seems to be missing - perhaps it ought to be added by an erratum.


But binding the CWR flag to a new data segment delays the ECN 
signaling loop artificially (for long runs of unidirectional 
transmitted data), and it is not clear what the benefit there would 
be, as the CWR flag is not retransmitted anyway (thus not bound to a 
point in the sequence number space).

[BB] Surely long runs of unidirectional transmitted data don't exhibit 
this problem, 'cos there's plenty of new data to carry the CWR. Or 
have I misunderstood?

Transactional data has frequent changes in data direction. But that behavior
(delaying CWR to only send it with new data) IMHO makes ECN unusable for Ack
Moderation (AckCC). Just wondering, if a different way of tracking the packets
In flight during a window would allow the immediate transmission of CWR 
with ECN++, to make ECN useful for Ack Moderation or other future purposes.
[BB] CWR is only used if RFC3168 feedback has been negotiated.
The WG consensus was that we shouldn't put ECT on pure ACKs if RFC3168 feedback has been negotiated; only if AccECN had been negotiated.

So, once you have AccECN and ECN++, you can do what you are wanting, 'cos AccECN allows both the data receiver to set ECT on pure ACKs and the data sender to count CEs on arriving pure ACKs. The data sender then includes this count in the ACE counter it feeds back on subsequent packets it sends (probably data packets, but could be on pure ACKs as well when data is bi-directional).

See
https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-3.2.3.2.1 (normative)
which refers to
https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-4.4.1 (informative)




In fact, the problem I see with RFC3168 is the opposite case. It seems
there was an assumption that a data sender would be continually sending
data, so that, once ECE feedback appeared at the sender, it would conveniently
always have some data to send, on which CWR could be carried.

Correct. With transactional data, this assumption breaks and long flights of 
Packets will continuously have ECE set.
[BB] I have a terminology blockage here. I interpret 'long flights of packets' to be a long-running flow - the opposite of 'transactional data'. But you seem to be using 'long flights of data' to describe 'transactional data'. Not sure what the disconnect is.



For instance, in the sequence above, host A might not send Data#2 for ages 
or perhaps never (a typical case if 'A' is a client requesting a large object). In
the intervening time, B might send far more than the two packets shown. If 'A'
does not set CWR on pure ACKs, all B's data packets would have to carry ECE, 
perhaps for many hours, until A has some more data to send (if ever).

Nontheless, I think ECE continuing for hours is fine within the logic of RFC3168. 
While A isn't sending anything, it only reduces cwnd once, and it's not 
measuring any round trips, so it's not increasing cwnd either.

Can you describe your case more precisely, so I can understand what caused 
the performance hit?

The problem comes from FBSD sending CWR (typically) on pure ACKs - where
Linux ignores the CWR and keeps ECE set; Thus FBSD observes "new" ECE in the 
Following window, resulting in another congestion response - while no further
CE mark was actually present.
[BB] I think you are solely talking about the case where sending of each transactional data volley strictly alternates between A and B.

I am trying to get you to think about a case where one end sends more than one volley in succession, in order to show that setting CWR on a pure ACK creates problems. That's why I asked, how does an FBSD receiver (or Linux receiver for that matter) know what a 'following window' is if it's only sending pure ACKs? They all have the same seqno and they don't get ACK'd. So the pure receiver can't know what an RTT is.

I also asked whether, if the FBSD host (that has been receiving data) does send some data between its pure ACKs, does it repeat the CWR on the data even tho it already set it on an earlier pure ACK? 


This leads to a race to the bottom for FBSD, where cwnd contionously shrinks 
(due to another bug, down to a size of 0 [zero]). Eventually, FBSD clocks out
1 byte every 4 seconds with a timer normally used for Window Probes (but
Unlike Window Probes, that one byte is actually new data).

Eventually CWR may be sent with a data packet (that 1-byte probe), accepted
By Linux, ECE unlatched, and cwnd can start growing again. But that event may
Happen only many minutes into entering this situation (got a trace, where this 
effect lasted nearly 10 minutes).

Obviously, the reverse data direction doesn’t suffer the same problem, nor does
a typical FBSD-FBSD ECN session suffer that fate (even though CWR are sent mostly
on pure ACKs)


I therefore propose a change in the Generalized ECN draft, to lift the 
above restriction (while it is "only" a SHOULD, this is one more 
example of an overly strict receiving-side implementation), and no 
longer artificially delay the CWR signal - to become also more useful 
for passive measurements.

[BB] I'm not yet convinced that this CWR behaviour is anything to do with 
the ECN++ draft. But that might be because I've misunderstood your 
description. As I said above, it might be possible to rectify omissions 
with an erratum to RFC3168.

In RFC3168, both ECT-codepoints and the CWR flag are defined to only be set on
new data segments.
[BB] Not strictly true for the CWR flag, as discussed earlier, this part of RFC3168 seems not to have been fully tied up.



Thus setting both can be simplified into a single branch; Getting the CWR indication
Slightly faster (not binding it to snd_max+1), that is, even with the next pure ack, probe
Or retransmission, would possibly provide a faster feedback (passive measurement
Of the window), and could enable the use of ECN signals for ACK moderation.

The drawback would be additional congestion responses, if the packet carrying the CWR
Is dropped (congestion on the path carrying the pure ACKs). But IIRC, reacting to congestion
On the (relatively) low bandwidth reverse direction by moderating the transmission speed 
(or asking for fewer ACKs) may be not too inappropriate...
[BB] I don't believe the CWR mechanism is suitable for faster congestion notification or for Ack CC. The way it's designed is tied in so much to reliable delivery that it actually breaks if you send it unreliably on pure ACKs (as I've tried to prove, and as you have discovered). 




more...


      

        

          
For those interested: The effect of ignoring the CWR on non-new-data 
segments by Linux is, that the ECE flag is left latched. Thus BSD 
continues window-after-window with cwnd reductions,


        

        
[BB] If it's not sending new data, how does the BSD host consider that 
windows are starting or completing?


      

      
It still tracks snd_recover (snd_max when the first ECE is received). I have not
Looked into this in detail yet, though. It may even reduce cwnd while being
The passive receiver...

    

    [BB] (repeating what I've said already) I don't see how it can know
    what an RTT is when its continually sending pure ACKs with the same
    seqno.

    

    Cheers

    

    

    Bob

    

      



      

        
Bob


      

      

    

    

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

  


--------------36C48E96EA77FE20F4F2B925--


From nobody Sat Feb 15 18:20:42 2020
Return-Path: 
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 9708D1200D7 for ; Sat, 15 Feb 2020 18:20:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 b4YWPznhubLJ for ; Sat, 15 Feb 2020 18:20:38 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 84765120033 for ; Sat, 15 Feb 2020 18:20:38 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id p9so13805459wmc.2 for ; Sat, 15 Feb 2020 18:20:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=UAWtOyNI0tkk2tw3cvpmcaUJa8CGSMR2d4ZbpT8jYt4=; b=Gg1C5nJjmWwao3xmH4/ZsB7xrUQmXGyKaiECb9WlsaxL9M2Qi0LtFMqHGYKY8eIeqK kSxmf1cdrylVmUXs0Ta7ZDBKRSnZi2chHcGNjah7OCgTMMIGXe1VtAPgdoxhVik5znXi apIlPNszWZnMZAKKjgBAFSE7kp4QDolZ0JE7D0uniQ4vY8MoK5E6cJpuIMBWnmuDovje 89GefPYu6sIUaPfCs4anvaohLEAAvy9yjUuAk1TC8Q85/V3My0ry8oHclMSWCGhbW1jI YltLE5FLLmIeuiu2+MMNrfcx4iyuMQ7dScCannV6U48ALRJ2fLJhfp6SvNIHbUFLqlS8 9zsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UAWtOyNI0tkk2tw3cvpmcaUJa8CGSMR2d4ZbpT8jYt4=; b=TchFLbevKzB3RBNhIG9Q8SKMTRXMBSXxZea53wkf1lEqv9qmSrRTfiBdLt+R2It6+B 7yfML26Mo3GbEYZVYeF9W3iZYuy/cQo7MGEJOnHCBvsVZZys3okBMEJehUFISL6Qa4hI e/Hv41995FXgNPsCcUPvUpGMEd1QW32tRIUrg0xBTvrRPjPYCSw7Ueih2FQGid/x0Wrl 02axKHsvXKtz1F+FvktMJ/P6gIjG74rJs4dAegt0dTS6homZBtRflV/d73g6Uxd5dgBM LTGS6O/zbp27HMxM2IG72AGnkgww09yyW9893wsDVVQ7ZGVjAMZafYKFEX3Fi8D/rgXH mVdA==
X-Gm-Message-State: APjAAAXKiFcsYqnXIPY/pQhbqn2PflwgXbWNcki8C3Ev8CmZyq7TE1zA iIt/D4NsEgwqfb1pRTi+bz6r2N+p+AL6fzNEwgmfCw==
X-Google-Smtp-Source: APXvYqyg2rcVS4V81cltU4sPbT+sRM0ZEKVV2P6D9nb6rdE7T3qq/uRKyIz1TvNyjf834jjPH6mo8KIaxkPu/Y3CrQ4=
X-Received: by 2002:a1c:451:: with SMTP id 78mr12851410wme.125.1581819636707;  Sat, 15 Feb 2020 18:20:36 -0800 (PST)
MIME-Version: 1.0
From: Martin Duke 
Date: Sat, 15 Feb 2020 18:20:24 -0800
Message-ID: 
To: "tcpm@ietf.org Extensions" 
Content-Type: multipart/alternative; boundary="0000000000008b7574059ea81566"
Archived-At: 
Subject: [tcpm] Review: draft-balasubramanian-tcpm-hystartplusplus-01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 16 Feb 2020 02:20:41 -0000

--0000000000008b7574059ea81566
Content-Type: text/plain; charset="UTF-8"

Hi Praveen,

Thanks for writing this up. It's great to hear what's actually happening
out there with major implementations.

1. I think this draft has a somewhat uncomfortable relationship with ABC
(RFC 3465), which for some reason is still Experimental. In each
description of Slow Start (Sec 1 and 3.2) you say one MSS per ack, which is
the non-ABC Reno behavior. But then the actual LSS algorithm uses bytes
counted.

Note that for a non-ABC implementation that also uses HyStart++, this means
an LSS_DIVISOR as low as 0.5 can cause LSS to be *more* aggressive than
regular slow start if the receiver acks every other packet. In the non-RFC
but common case where ACKs are aggregated even more aggressively, LSS can
be more aggressive than slow start for arbitrarily low divisor values. I'm
not sure the design has to change, but there ought to be some discussion of
these considerations.

2. in section 3.2, you set the ssthresh to cwnd upon entering LSS. But then
later you say "HyStart++ ends when cwnd exceeds ssthresh..." which by
definition is immediately. I think you mean the normal Reno/Cubic ssthresh;
perhaps it would be better to invent a new name for the value that is used
in computing K.

Similarly, I don't believe MIN_SSTHRESH has any relationship to the
conventional ssthresh (i.e. it is not a minimum) and therefore should also
be renamed.

3. Section 3.3 could use some further considerations for setting these
parameters. In particular, values of LSS_DIVISOR > 1 will be more
aggressive than slow start, at least for low values of cwnd/ssthresh.
Depending on the result of #1 above, the warning may need to be for a lower
value.

4. Though not necessary to make this draft worthwhile, some data from
Microsoft's deployment showing the value of this would be helpful. If I
were to try to sell this feature to our customers, they would probably want
to see that it was providing benefits to large traffic generators rather
than backing off for the good of the internet. In particular, I wonder
whether Reno/Cubic is fair to Hystart++ as regular slow start would seem to
cause LSS to cut the throttle.

Nits:
- Please spell out SMSS before using it.
- Title of 3.3: s/Constant/Constants
- 3.3. You are little sloppy with units. MIN_SSTHRESH is clearly measured
in bytes in Sec 3.2 but is reported in segments in this section.

--0000000000008b7574059ea81566
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Hi Praveen,

Thanks for writing this up. =
It's great to hear what's actually happening out there with major i=
mplementations.

1. I think this draft has a somewh=
at uncomfortable relationship with ABC (RFC 3465), which for some reason is=
 still Experimental. In each description of Slow Start (Sec 1 and 3.2) you =
say one MSS per ack, which is the non-ABC Reno behavior. But then the actua=
l LSS algorithm uses bytes counted.

Note that for =
a non-ABC implementation that also uses HyStart++, this means an LSS_DIVISO=
R as low as 0.5 can cause LSS to be *more* aggressive than regular slow sta=
rt if the receiver acks every other packet. In the non-RFC but common case =
where ACKs are aggregated even more aggressively, LSS can be more aggressiv=
e than slow start for arbitrarily low divisor values. I'm not sure the =
design has to change, but there ought to be some discussion of these consid=
erations.

2. in section 3.2, you set the ssth=
resh to cwnd upon entering LSS. But then later you say "HyStart++ ends=
 when cwnd exceeds ssthresh..." which by definition is immediately. I =
think you mean the normal Reno/Cubic ssthresh; perhaps it would be better t=
o invent a new name for the value that is used in computing K.
Similarly, I don't believe MIN_SSTHRESH has any relationsh=
ip to the conventional ssthresh (i.e. it is not a minimum) and therefore sh=
ould also be renamed.

3. Section 3.3 could u=
se some further considerations for setting these parameters. In particular,=
 values of LSS_DIVISOR > 1 will be more aggressive than slow start, at l=
east for low values of cwnd/ssthresh. Depending on the result of #1 above, =
the warning may need to be for a lower value.

4. Though not necessary to make this draft worthwhile, some data fro=
m Microsoft's deployment showing the value of this would be helpful. If=
 I were to try to sell this feature to our customers, they would probably w=
ant to see that it was providing benefits to large traffic generators rathe=
r than backing off for the good of the internet. In particular, I wonder wh=
ether Reno/Cubic is fair to Hystart++ as regular slow start would seem to c=
ause LSS to cut the throttle.

Nits:
=
- Please spell out SMSS before using it.
- Title of 3.=
3: s/Constant/Constants
- 3.3. You are little sloppy with units. =
MIN_SSTHRESH is clearly measured in bytes in Sec 3.2 but is reported in seg=
ments in this section.



--0000000000008b7574059ea81566--


From nobody Mon Feb 17 18:32:30 2020
Return-Path: 
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 E8E09120110 for ; Mon, 17 Feb 2020 05:00:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 vC2SbwLU3coa for ; Mon, 17 Feb 2020 05:00:57 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 D8CDE1200B9 for ; Mon, 17 Feb 2020 05:00:56 -0800 (PST)
Received: from [129.192.10.2] (helo=[164.48.40.174]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j3g17-0003FA-Kj; Mon, 17 Feb 2020 14:00:53 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind 
In-Reply-To: 
Date: Mon, 17 Feb 2020 14:00:52 +0100
Cc: =?utf-8?Q?Ilpo_J=C3=A4rvinen?= , Richard Scheffenegger , tcpm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8BE676F6-8E30-4E87-9466-8C3A385D34B3@kuehlewind.net>
References:  
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581944457;e7f272f9;
X-HE-SMSGID: 1j3g17-0003FA-Kj
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09 review
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2020 13:00:59 -0000

Hi Bob, hi Ilpo,

Thanks for the review!!

Just quickly replying to this one:

> On 14. Feb 2020, at 20:26, Bob Briscoe  wrote:
>=20
>>=20
>>=20
>> Appendix A.3.
>>=20
>>     "However it would be simpler to
>>     merely maintain a counter packets_in_flight for the number of =
packets
>>     in flight (including control packets), which it could update once =
per
>>     RTT."
>> I'm not convinced that this is very simple either. Given that =
flightsize
>> is maintained more frequently than once per RTT which likely leads to =
some
>> tricky corner cases when their values are out of sync.
>>=20
> [BB] I think you're right. This is more than a editorial nit. =
Nonetheless, I think Mirja implemented this then wrote this section. =
Nonetheless, I think you based your implementation on Olivier's which =
was based on Mirja's. So if this Estimation algo was not already in your =
code, that probably means I'm wrong.
>=20
> Mirja?


No this was not implemented because this is only necessary for new =
congestion controls that need this value (like DCCP) but I didn=E2=80=99t =
went that far in my implementation.

The =E2=80=9Csimple=E2=80=9D idea here was to just reset the counter =
once per RTT as usually you only need to adapt your window once per RTT =
anyway. I guess that would be more clear if we replace this:

S/which it could update once per RTT/which is rest one per RTT/

Mirja





From nobody Mon Feb 17 18:35:50 2020
Return-Path: 
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 19AE9120852 for ; Mon, 17 Feb 2020 06:52:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 5MtqdDwi_KWS for ; Mon, 17 Feb 2020 06:52:39 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 EFB6212004C for ; Mon, 17 Feb 2020 06:52:38 -0800 (PST)
Received: from [129.192.10.3] (helo=[10.149.0.124]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j3hlF-0002hW-42; Mon, 17 Feb 2020 15:52:37 +0100
From: Mirja Kuehlewind 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: 
Date: Mon, 17 Feb 2020 15:52:36 +0100
To: tcpm IETF list 
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581951159;1d55946a;
X-HE-SMSGID: 1j3hlF-0002hW-42
Archived-At: 
Subject: [tcpm] Sync up call
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2020 14:52:41 -0000

Hi Yoshi, hi Michael, hi Michael,

Based on previous discussions we had and given I will hand-over this =
group to Martin after the next meeting, I would like to discuss a couple =
things with you. I thought might be just easier to have a call, however, =
I realised that schedule with both Yoshi and Martin could be =
challenging=E2=80=A6=20

So I guess time-wise the only suitable slow is 6:00 =
PST/15:00CET/23:00JST=E2=80=A6?

Or did you move, Yoshi? I vaguely remember that you told me =
something=E2=80=A6?

Others, would you be available in that time slot, any day this or next =
week?


I think it would be good if we could discuss the following things:

1) Adding something about MPTCP to the charter: The plan is to close the =
MPTCP working group before Vancouver (as soon as the final discussion =
about a minor change in the bis doc has concluded). I think tcpm is =
already implicitly also charter to take up minor extension and =
maintenance of MPTCP (as MPTCP itself is an extension of TCP). However, =
it would be good to mention this explicitly in the charter to make this =
more clear to outside folks. Maybe we can quickly discuss how to add =
that and then make a text proposal to be discussed with the MPTCP chairs =
and the tcpm group=E2=80=A6?

2) We already started by email a discussion about how to speed up the =
working group process. One outcome of that discussion was also that I =
think the group was positive about lowering the bar for PS. I would like =
to discuss/brainstorm more ideas. I know that part of the problem is =
that reviews are missing, however, there might be more things the chairs =
could try to foster reviews, and/or consider also a lower bar on =
required reviews. I think this is especially important as the speed is =
higher in the QUIC group and we should make sure that people just =
don=E2=80=99t lose interest in maintaining TCP.

3) Chairing: As you might have seen, I have added Ian Swett as new IPPM =
chair. Originally I was planning to add Martin Duke to IPPM but that =
didn=E2=80=99t work out=E2=80=A6 However, given the current load the =
plan stands that we should reduce down to two chairs again. So we should =
make a plan for that. On the long term it would still be good to figure =
out if there could be some chair rotation in tcpm as that would also be =
a good opportunity to train up new people. This is less urgent now, but =
it would also be good to make a plan for that together with Martin.

Mirja





From nobody Mon Feb 17 18:36:02 2020
Return-Path: 
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 64F3D12084C for ; Mon, 17 Feb 2020 06:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 hpb4tTMXUmXc for ; Mon, 17 Feb 2020 06:56:00 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 C028012004C for ; Mon, 17 Feb 2020 06:56:00 -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:From:References:Cc:To: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=1OUox6RsE2zyO/I9c40L+tya2L1+Ork2nR+6/CBdGig=; b=Br9R9bMTyKvMWQMRapuQti7thL J1KBKRzstghkiK2Tys0HVOmGapK6C4jdCUzpPbPMj4ZeBDTXkEZ/rsMadr/+8IJ0IBgD0jbbSg1bx ivAKCj5Y/H12xXW+MHrY3/EHjuNIud5UTVDRkkuA7aK9IVB0VJGcoKcS2jeuy7k4sC0koXGB39MVg Shn/bMLwoMvLx2V9ncG261LG9ThMmXWB+jrBzyGoYC6JWt1hUEmfALG2d3Jvkq+NALtn9hvKvTo6i e7d0gMcKgYuQ7Pv8LUbOZYdl5/44Bfko7h0tpwOWp7WdpDI0RphHDCe3/215jKg3J4g7lpC5qmNxz GHU5/2/w==;
Received: from [31.185.128.125] (port=55828 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j3hoU-0003WR-C3; Mon, 17 Feb 2020 14:55:58 +0000
To: Mirja Kuehlewind 
Cc: =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= , Richard Scheffenegger , tcpm@ietf.org
References:   <8BE676F6-8E30-4E87-9466-8C3A385D34B3@kuehlewind.net>
From: Bob Briscoe 
Message-ID: 
Date: Mon, 17 Feb 2020 14:55:57 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <8BE676F6-8E30-4E87-9466-8C3A385D34B3@kuehlewind.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09 review
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2020 14:56:07 -0000

Mirja,

On 17/02/2020 13:00, Mirja Kuehlewind wrote:
> Hi Bob, hi Ilpo,
>
> Thanks for the review!!
>
> Just quickly replying to this one:
>
>> On 14. Feb 2020, at 20:26, Bob Briscoe  wrote:
>>
>>>
>>> Appendix A.3.
>>>
>>>      "However it would be simpler to
>>>      merely maintain a counter packets_in_flight for the number of packets
>>>      in flight (including control packets), which it could update once per
>>>      RTT."
>>> I'm not convinced that this is very simple either. Given that flightsize
>>> is maintained more frequently than once per RTT which likely leads to some
>>> tricky corner cases when their values are out of sync.
>>>
>> [BB] I think you're right. This is more than a editorial nit. Nonetheless, I think Mirja implemented this then wrote this section. Nonetheless, I think you based your implementation on Olivier's which was based on Mirja's. So if this Estimation algo was not already in your code, that probably means I'm wrong.
>>
>> Mirja?
>
> No this was not implemented because this is only necessary for new congestion controls that need this value (like DCCP) but I didn’t went that far in my implementation.
>
> The “simple” idea here was to just reset the counter once per RTT as usually you only need to adapt your window once per RTT anyway. I guess that would be more clear if we replace this:
>
> S/which it could update once per RTT/which is rest one per RTT/
First, adding some letters  presumed missing (being liberal in what I 
receive ;)

S/which it could update once per RTT/which is reset once per RTT/

I think the unstated problem here is that it's easy to count all packets 
into flight, but it's hard to count them all out, because control 
packets don't get ACK'd.

Resetting each RTT would certainly solve that, but it would mean you 
have to store one counter being built up now, and another to hold the 
value that the previous round reached. Also, I'm not sure a number that 
is 1 RTT out of date would be so useful for estimating bytes from 
packets, because TCP flows aren't necessarily continuous and predictable.

I guess, to Ilpo's point that flightsize is updated more often than once 
per RTT, your answer is that the avg pkt size could only be calculated 
at the time in each RTT just before packets_in_flight is reset.

I think we need to flag that this Appendix is more tentative than the 
others, given the problem is a bit arm-wavey, and the solution is too.



Bob

>
> Mirja
>
>
>
>

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


From nobody Mon Feb 17 18:39:19 2020
Return-Path: 
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 EE44C120861 for ; Mon, 17 Feb 2020 08:00:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 eoWG6552t8ip for ; Mon, 17 Feb 2020 08:00:17 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 80D58120853 for ; Mon, 17 Feb 2020 08:00:17 -0800 (PST)
Received: from [129.192.10.3] (helo=[10.149.0.124]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j3iob-0004wM-EH; Mon, 17 Feb 2020 17:00:09 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind 
In-Reply-To: 
Date: Mon, 17 Feb 2020 17:00:08 +0100
Cc: =?utf-8?Q?Ilpo_J=C3=A4rvinen?= , Richard Scheffenegger , tcpm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <8BE676F6-8E30-4E87-9466-8C3A385D34B3@kuehlewind.net> 
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581955217;ebc3fe95;
X-HE-SMSGID: 1j3iob-0004wM-EH
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09 review
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2020 16:00:25 -0000

Hi Bob,

See below.

> On 17. Feb 2020, at 15:55, Bob Briscoe  wrote:
>=20
> Mirja,
>=20
> On 17/02/2020 13:00, Mirja Kuehlewind wrote:
>> Hi Bob, hi Ilpo,
>>=20
>> Thanks for the review!!
>>=20
>> Just quickly replying to this one:
>>=20
>>> On 14. Feb 2020, at 20:26, Bob Briscoe  wrote:
>>>=20
>>>>=20
>>>> Appendix A.3.
>>>>=20
>>>>     "However it would be simpler to
>>>>     merely maintain a counter packets_in_flight for the number of =
packets
>>>>     in flight (including control packets), which it could update =
once per
>>>>     RTT."
>>>> I'm not convinced that this is very simple either. Given that =
flightsize
>>>> is maintained more frequently than once per RTT which likely leads =
to some
>>>> tricky corner cases when their values are out of sync.
>>>>=20
>>> [BB] I think you're right. This is more than a editorial nit. =
Nonetheless, I think Mirja implemented this then wrote this section. =
Nonetheless, I think you based your implementation on Olivier's which =
was based on Mirja's. So if this Estimation algo was not already in your =
code, that probably means I'm wrong.
>>>=20
>>> Mirja?
>>=20
>> No this was not implemented because this is only necessary for new =
congestion controls that need this value (like DCCP) but I didn=E2=80=99t =
went that far in my implementation.
>>=20
>> The =E2=80=9Csimple=E2=80=9D idea here was to just reset the counter =
once per RTT as usually you only need to adapt your window once per RTT =
anyway. I guess that would be more clear if we replace this:
>>=20
>> S/which it could update once per RTT/which is rest one per RTT/
> First, adding some letters  presumed missing (being liberal in what I =
receive ;)
>=20
> S/which it could update once per RTT/which is reset once per RTT/

Believe it or not but my keyboard is somehow broken and the e and c are =
particularly bad (as well as the j which is why I recently signed an =
email with Mira instead of Mirja=E2=80=A6) Need to fix that!

>=20
> I think the unstated problem here is that it's easy to count all =
packets into flight, but it's hard to count them all out, because =
control packets don't get ACK=E2=80=99d.
>=20
> Resetting each RTT would certainly solve that, but it would mean you =
have to store one counter being built up now, and another to hold the =
value that the previous round reached. Also, I'm not sure a number that =
is 1 RTT out of date would be so useful for estimating bytes from =
packets, because TCP flows aren't necessarily continuous and =
predictable.

The idea is to not have a moving counter but simply do the calculation =
one per RTT for the last RTT and then reset. That does make sense if you =
e.g. need this information to adjust your cwnd once per RTT and you =
align those two events.

I know updating the congestion window becomes/is also more a continuous =
process rather than a once-per RTT action in most implementation, =
however, this algorithm was supposed to provide a simple/simplified =
alternative.

>=20
> I guess, to Ilpo's point that flightsize is updated more often than =
once per RTT, your answer is that the avg pkt size could only be =
calculated at the time in each RTT just before packets_in_flight is =
reset.

Yes.
>=20
> I think we need to flag that this Appendix is more tentative than the =
others, given the problem is a bit arm-wavey, and the solution is too.

Not sure if a would say arm-wavey but yes it's only a rough estimates =
but it really depends what your congestion controller needs and does and =
already tracks.

Mirja



>=20
>=20
>=20
> Bob
>=20
>>=20
>> Mirja
>>=20
>>=20
>>=20
>>=20
>=20
> --=20
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>=20
>=20


From nobody Mon Feb 17 18:39:40 2020
Return-Path: 
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 DCCA2120850 for ; Mon, 17 Feb 2020 08:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 qG0CPxCLzj7d for ; Mon, 17 Feb 2020 08:02:34 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 E14B212083E for ; Mon, 17 Feb 2020 08:02:33 -0800 (PST)
Received: from [129.192.10.3] (helo=[10.149.0.124]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j3iqs-0007Xp-N0; Mon, 17 Feb 2020 17:02:30 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind 
In-Reply-To: 
Date: Mon, 17 Feb 2020 17:02:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: tcpm IETF list 
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581955354;d83458d5;
X-HE-SMSGID: 1j3iqs-0007Xp-N0
Archived-At: 
Subject: Re: [tcpm] Sync up call
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2020 16:02:37 -0000

Hi all,

Sorry this went to the wrong alias; was intended for the chairs only.

However, now you know what=E2=80=99s going on behind the scenes :-)

Mirja



> On 17. Feb 2020, at 15:52, Mirja Kuehlewind  =
wrote:
>=20
> Hi Yoshi, hi Michael, hi Michael,
>=20
> Based on previous discussions we had and given I will hand-over this =
group to Martin after the next meeting, I would like to discuss a couple =
things with you. I thought might be just easier to have a call, however, =
I realised that schedule with both Yoshi and Martin could be =
challenging=E2=80=A6=20
>=20
> So I guess time-wise the only suitable slow is 6:00 =
PST/15:00CET/23:00JST=E2=80=A6?
>=20
> Or did you move, Yoshi? I vaguely remember that you told me =
something=E2=80=A6?
>=20
> Others, would you be available in that time slot, any day this or next =
week?
>=20
>=20
> I think it would be good if we could discuss the following things:
>=20
> 1) Adding something about MPTCP to the charter: The plan is to close =
the MPTCP working group before Vancouver (as soon as the final =
discussion about a minor change in the bis doc has concluded). I think =
tcpm is already implicitly also charter to take up minor extension and =
maintenance of MPTCP (as MPTCP itself is an extension of TCP). However, =
it would be good to mention this explicitly in the charter to make this =
more clear to outside folks. Maybe we can quickly discuss how to add =
that and then make a text proposal to be discussed with the MPTCP chairs =
and the tcpm group=E2=80=A6?
>=20
> 2) We already started by email a discussion about how to speed up the =
working group process. One outcome of that discussion was also that I =
think the group was positive about lowering the bar for PS. I would like =
to discuss/brainstorm more ideas. I know that part of the problem is =
that reviews are missing, however, there might be more things the chairs =
could try to foster reviews, and/or consider also a lower bar on =
required reviews. I think this is especially important as the speed is =
higher in the QUIC group and we should make sure that people just =
don=E2=80=99t lose interest in maintaining TCP.
>=20
> 3) Chairing: As you might have seen, I have added Ian Swett as new =
IPPM chair. Originally I was planning to add Martin Duke to IPPM but =
that didn=E2=80=99t work out=E2=80=A6 However, given the current load =
the plan stands that we should reduce down to two chairs again. So we =
should make a plan for that. On the long term it would still be good to =
figure out if there could be some chair rotation in tcpm as that would =
also be a good opportunity to train up new people. This is less urgent =
now, but it would also be good to make a plan for that together with =
Martin.
>=20
> Mirja
>=20
>=20
>=20
>=20


From nobody Mon Feb 17 18:40:28 2020
Return-Path: 
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 40A5812089E for ; Mon, 17 Feb 2020 08:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Ivd8cmH3WtOR for ; Mon, 17 Feb 2020 08:26:40 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 EC8FA120897 for ; Mon, 17 Feb 2020 08:26:39 -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:From:References:Cc:To: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=hy9JAk0Kls83t9D7QA90z0Acmu+YL6d8V/kOES7n8NU=; b=qQrHDsSPaxCBfpYVgTfBQuGeYp 2t2zX58YczJr/mzA0cUmprqIn1ojFTPUXVAm11myrMuJIcjCEG79RaWMK4/ezhPyvh2cfruV+My0e 9rHCHBzIO/xSEzg1v2s0gqBRfEz820mSTYL6aU9o4MHM9ViNAnWJm+xpNNWIrRceVPsRMoNA0AdEt jejrf6ibG9ERY6UdySn9mcCruSbNJrYsRE/0t/hWyDKOnib0jJnzBObA1t3dgZ4N9kgawx4HHGcSH dOAlOJiROlav2xwes+nIFmqni11BYRTXG8f+OaYIFYz8mHzcanS5LebV78/hqHh3N/Vz2ruXW0EFP Oc5PMEVg==;
Received: from [31.185.128.125] (port=56070 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j3jEB-0007Sa-MM; Mon, 17 Feb 2020 16:26:35 +0000
To: Mirja Kuehlewind 
Cc: =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= , Richard Scheffenegger , tcpm@ietf.org
References:   <8BE676F6-8E30-4E87-9466-8C3A385D34B3@kuehlewind.net>  
From: Bob Briscoe 
Message-ID: <7f757981-fdef-7b87-dadc-ca10883472e0@bobbriscoe.net>
Date: Mon, 17 Feb 2020 16:26:32 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09 review
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2020 16:26:44 -0000

On 17/02/2020 16:00, Mirja Kuehlewind wrote:
> Hi Bob,
>
> See below.
>
>> On 17. Feb 2020, at 15:55, Bob Briscoe  wrote:
>>
>> Mirja,
>>
>> On 17/02/2020 13:00, Mirja Kuehlewind wrote:
>>> Hi Bob, hi Ilpo,
>>>
>>> Thanks for the review!!
>>>
>>> Just quickly replying to this one:
>>>
>>>> On 14. Feb 2020, at 20:26, Bob Briscoe  wrote:
>>>>
>>>>> Appendix A.3.
>>>>>
>>>>>      "However it would be simpler to
>>>>>      merely maintain a counter packets_in_flight for the number of packets
>>>>>      in flight (including control packets), which it could update once per
>>>>>      RTT."
>>>>> I'm not convinced that this is very simple either. Given that flightsize
>>>>> is maintained more frequently than once per RTT which likely leads to some
>>>>> tricky corner cases when their values are out of sync.
>>>>>
>>>> [BB] I think you're right. This is more than a editorial nit. Nonetheless, I think Mirja implemented this then wrote this section. Nonetheless, I think you based your implementation on Olivier's which was based on Mirja's. So if this Estimation algo was not already in your code, that probably means I'm wrong.
>>>>
>>>> Mirja?
>>> No this was not implemented because this is only necessary for new congestion controls that need this value (like DCCP) but I didn’t went that far in my implementation.
>>>
>>> The “simple” idea here was to just reset the counter once per RTT as usually you only need to adapt your window once per RTT anyway. I guess that would be more clear if we replace this:
>>>
>>> S/which it could update once per RTT/which is rest one per RTT/
>> First, adding some letters  presumed missing (being liberal in what I receive ;)
>>
>> S/which it could update once per RTT/which is reset once per RTT/
> Believe it or not but my keyboard is somehow broken and the e and c are particularly bad (as well as the j which is why I recently signed an email with Mira instead of Mirja…) Need to fix that!
>
>> I think the unstated problem here is that it's easy to count all packets into flight, but it's hard to count them all out, because control packets don't get ACK’d.
>>
>> Resetting each RTT would certainly solve that, but it would mean you have to store one counter being built up now, and another to hold the value that the previous round reached. Also, I'm not sure a number that is 1 RTT out of date would be so useful for estimating bytes from packets, because TCP flows aren't necessarily continuous and predictable.
> The idea is to not have a moving counter but simply do the calculation one per RTT for the last RTT and then reset. That does make sense if you e.g. need this information to adjust your cwnd once per RTT and you align those two events.
>
> I know updating the congestion window becomes/is also more a continuous process rather than a once-per RTT action in most implementation, however, this algorithm was supposed to provide a simple/simplified alternative.
>
>> I guess, to Ilpo's point that flightsize is updated more often than once per RTT, your answer is that the avg pkt size could only be calculated at the time in each RTT just before packets_in_flight is reset.
> Yes.
>> I think we need to flag that this Appendix is more tentative than the others, given the problem is a bit arm-wavey, and the solution is too.
> Not sure if a would say arm-wavey but yes it's only a rough estimates but it really depends what your congestion controller needs and does and already tracks.
At the end of the first para, I've added:

"Some possible ways to calculate s_ave are outlined below. The precise 
details will depend on why an estimate of marked bytes is needed."


Bob

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

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


From nobody Mon Feb 17 18:40:39 2020
Return-Path: 
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 0994C120816 for ; Mon, 17 Feb 2020 08:36:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 ByNh1FIDoan0 for ; Mon, 17 Feb 2020 08:36:49 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 796DD12011D for ; Mon, 17 Feb 2020 08:36:49 -0800 (PST)
Received: from [129.192.10.3] (helo=[10.149.0.124]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j3jO2-00048G-Uh; Mon, 17 Feb 2020 17:36:46 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind 
In-Reply-To: <7f757981-fdef-7b87-dadc-ca10883472e0@bobbriscoe.net>
Date: Mon, 17 Feb 2020 17:36:46 +0100
Cc: =?utf-8?Q?Ilpo_J=C3=A4rvinen?= , Richard Scheffenegger , tcpm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <32BBF81B-E85C-4E0A-98AF-1DED1D8BB23F@kuehlewind.net>
References:   <8BE676F6-8E30-4E87-9466-8C3A385D34B3@kuehlewind.net>   <7f757981-fdef-7b87-dadc-ca10883472e0@bobbriscoe.net>
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581957409;c141ad08;
X-HE-SMSGID: 1j3jO2-00048G-Uh
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09 review
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2020 16:36:53 -0000

That works!

> On 17. Feb 2020, at 17:26, Bob Briscoe  wrote:
>=20
>=20
>=20
> On 17/02/2020 16:00, Mirja Kuehlewind wrote:
>> Hi Bob,
>>=20
>> See below.
>>=20
>>> On 17. Feb 2020, at 15:55, Bob Briscoe  wrote:
>>>=20
>>> Mirja,
>>>=20
>>> On 17/02/2020 13:00, Mirja Kuehlewind wrote:
>>>> Hi Bob, hi Ilpo,
>>>>=20
>>>> Thanks for the review!!
>>>>=20
>>>> Just quickly replying to this one:
>>>>=20
>>>>> On 14. Feb 2020, at 20:26, Bob Briscoe  =
wrote:
>>>>>=20
>>>>>> Appendix A.3.
>>>>>>=20
>>>>>>     "However it would be simpler to
>>>>>>     merely maintain a counter packets_in_flight for the number of =
packets
>>>>>>     in flight (including control packets), which it could update =
once per
>>>>>>     RTT."
>>>>>> I'm not convinced that this is very simple either. Given that =
flightsize
>>>>>> is maintained more frequently than once per RTT which likely =
leads to some
>>>>>> tricky corner cases when their values are out of sync.
>>>>>>=20
>>>>> [BB] I think you're right. This is more than a editorial nit. =
Nonetheless, I think Mirja implemented this then wrote this section. =
Nonetheless, I think you based your implementation on Olivier's which =
was based on Mirja's. So if this Estimation algo was not already in your =
code, that probably means I'm wrong.
>>>>>=20
>>>>> Mirja?
>>>> No this was not implemented because this is only necessary for new =
congestion controls that need this value (like DCCP) but I didn=E2=80=99t =
went that far in my implementation.
>>>>=20
>>>> The =E2=80=9Csimple=E2=80=9D idea here was to just reset the =
counter once per RTT as usually you only need to adapt your window once =
per RTT anyway. I guess that would be more clear if we replace this:
>>>>=20
>>>> S/which it could update once per RTT/which is rest one per RTT/
>>> First, adding some letters  presumed missing (being liberal in what =
I receive ;)
>>>=20
>>> S/which it could update once per RTT/which is reset once per RTT/
>> Believe it or not but my keyboard is somehow broken and the e and c =
are particularly bad (as well as the j which is why I recently signed an =
email with Mira instead of Mirja=E2=80=A6) Need to fix that!
>>=20
>>> I think the unstated problem here is that it's easy to count all =
packets into flight, but it's hard to count them all out, because =
control packets don't get ACK=E2=80=99d.
>>>=20
>>> Resetting each RTT would certainly solve that, but it would mean you =
have to store one counter being built up now, and another to hold the =
value that the previous round reached. Also, I'm not sure a number that =
is 1 RTT out of date would be so useful for estimating bytes from =
packets, because TCP flows aren't necessarily continuous and =
predictable.
>> The idea is to not have a moving counter but simply do the =
calculation one per RTT for the last RTT and then reset. That does make =
sense if you e.g. need this information to adjust your cwnd once per RTT =
and you align those two events.
>>=20
>> I know updating the congestion window becomes/is also more a =
continuous process rather than a once-per RTT action in most =
implementation, however, this algorithm was supposed to provide a =
simple/simplified alternative.
>>=20
>>> I guess, to Ilpo's point that flightsize is updated more often than =
once per RTT, your answer is that the avg pkt size could only be =
calculated at the time in each RTT just before packets_in_flight is =
reset.
>> Yes.
>>> I think we need to flag that this Appendix is more tentative than =
the others, given the problem is a bit arm-wavey, and the solution is =
too.
>> Not sure if a would say arm-wavey but yes it's only a rough estimates =
but it really depends what your congestion controller needs and does and =
already tracks.
> At the end of the first para, I've added:
>=20
> "Some possible ways to calculate s_ave are outlined below. The precise =
details will depend on why an estimate of marked bytes is needed."
>=20
>=20
> Bob
>=20
>>=20
>> Mirja
>>=20
>>=20
>>=20
>>>=20
>>>=20
>>> Bob
>>>=20
>>>> Mirja
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>> --=20
>>> ________________________________________________________________
>>> Bob Briscoe                               http://bobbriscoe.net/
>>>=20
>>>=20
>=20
> --=20
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>=20
>=20


From nobody Mon Feb 17 18:41:53 2020
Return-Path: 
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 28FC7120912 for ; Mon, 17 Feb 2020 09:03:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 W7P136ZtESc9 for ; Mon, 17 Feb 2020 09:03:35 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B982E1208F8 for ; Mon, 17 Feb 2020 09:03:34 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id E7D8C25A14; Mon, 17 Feb 2020 18:03:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1581959011; bh=BJ0qzvfGBReVvbvgY6lbCMHLzbxT/kjNti31+98WZjo=; h=From:To:Subject:Date:From; b=Mt3EwoJGNgbgY2bnFAqJkC0ZxLCI0WemMc22enlboEK14hlDpH99gucJyOeyJ/Msf gw07kFQfqKbwWqRXmjEQDwokKGiXoR2ZLPItXoWYy+3+T7DJeZ2EJNkN7X9tgjCalI ILy1mVPycjozVnofvFGIVEjOo8Hb+zlOF4QApQh0=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fgBR0QWWo7Z; Mon, 17 Feb 2020 18:03:31 +0100 (CET)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 17 Feb 2020 18:03:31 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.214]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 17 Feb 2020 18:03:31 +0100
From: "Scharf, Michael" 
To: Mirja Kuehlewind , tcpm IETF list 
Thread-Topic: Lowering the bar in TCPM (was: RE: [tcpm] Sync up call)
Thread-Index: AdXlsqkRjfvrGwgTRmmk57qWSQeo4Q==
Date: Mon, 17 Feb 2020 17:03:29 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D9545D1@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] Lowering the bar in TCPM (was: RE:  Sync up call)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2020 17:03:44 -0000

V2hpbGUgdGhlIG9yaWdpbmFsIGUtbWFpbCB0aGF0IHdhcyBub3QgbWVhbnQgdG8gYmUgcHVibGlj
LCBJIHRoaW5rIHRoZSBUQ1BNIGNvbW11bml0eSBjb3VsZCB1c2UgdGhpcyBvcHBvcnR1bml0eSB0
byBjb21tZW50IG9uIHRoZSBxdWVzdGlvbiB3aGV0aGVyIHRvIGxvd2VyIHRoZSBiYXIgZm9yIHJl
dmlld3MgaW4gVENQTSwgb3Igd2hldGhlciB0aGVyZSBhcmUgb3RoZXIgaWRlYXMgaG93IHRvIHB1
Ymxpc2ggVENQTSBkb2N1bWVudHMgZmFzdGVyLiANCg0KTWljaGFlbA0K


From nobody Mon Feb 17 18:44:28 2020
Return-Path: 
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 91D9812008F for ; Mon, 17 Feb 2020 10:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level: 
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 4qJTbov5dRQk for ; Mon, 17 Feb 2020 10:21:05 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 ABD6B120089 for ; Mon, 17 Feb 2020 10:21:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type: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=LCmj31/Un1Jq+35+E3h3Ivqk+HYBhnw58bzraA1oTD0=; b=UvPLmI802TlvM3LPLGrYzCFas X8aiwOkh+XSjPAU10pnWUw4Y8AVy6XBlr5k2Ky82+eQa40fjxJNalga6Ht/jQId85mLuYjdHCAZjb IpxZvCQ42yKHT/SK+3BjeRFnPxB9BFs603kANuViChOBDZlXEUj/FSw3k+nS8ttEP0E1mbLM1k+Z6 6B9sXg1gsHqWxHiMFwQUupaDbFDZuGr4qpo2+6ITpccVRAwmQq9Oe5SmYcrZUI7L0Bk3h8NfsclU2 sRhISzIS2wAhdTQE4ZaiYEtO8XLmMdDZS7mQYWOYV0pvdstqUGWyIPSy/aQuc+W5vCY8uQe96klgf Vuux6Q4Gw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:63256 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j3l0s-002E7i-Ok; Mon, 17 Feb 2020 13:21:03 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch 
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D9545D1@rznt8114.rznt.rzdir.fht-esslingen.de>
Date: Mon, 17 Feb 2020 10:20:56 -0800
Cc: Mirja Kuehlewind , tcpm IETF list 
Content-Transfer-Encoding: quoted-printable
Message-Id: <641A00A4-B41F-4179-A0FB-5D3408D429C3@strayalpha.com>
References: <6EC6417807D9754DA64F3087E2E2E03E2D9545D1@rznt8114.rznt.rzdir.fht-esslingen.de>
To: "Scharf, Michael" 
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
Subject: Re: [tcpm] Lowering the bar in TCPM (was: RE:  Sync up call)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Feb 2020 18:21:09 -0000

Before we consider lowering the bar - how about some *HOMEWORK*?

What=E2=80=99s the evidence of a problem, e.g., compared either to other =
WGs that manage core Internet protocols (e.g., intarea) or over the =
history of TSVWG?

Joe

> On Feb 17, 2020, at 9:03 AM, Scharf, Michael =
 wrote:
>=20
> While the original e-mail that was not meant to be public, I think the =
TCPM community could use this opportunity to comment on the question =
whether to lower the bar for reviews in TCPM, or whether there are other =
ideas how to publish TCPM documents faster.=20
>=20
> Michael
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Tue Feb 18 08:11:03 2020
Return-Path: 
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 E0672120815; Tue, 18 Feb 2020 08:10:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level: 
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 nF63H_wG-IxA; Tue, 18 Feb 2020 08:10:53 -0800 (PST)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 10B601200E0; Tue, 18 Feb 2020 08:10:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1582042252; x=1613578252; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=iDoUlsI9RWLXLWmmMLwXHSELoIrrdPAwg01cEiOPLA8=; b=vKnylhfc9y+GT+J/mMdbNtuPNXk4Wcn7iGeF0xC+KKG8uEyUTpJMJBWI ZUQFoCZrR56GTe5Jh4RZQrICNPXYtbKFSLz3MwTjHZaDPRpdkoU9yrnIP G/JFnowGM3/uxdygUm7oh6lSM8CBk/ZbBaZmzZh7VtK9cgrIEN9dV4XM6 vCDxZRobCf762OLv5vLdDtgagUKoQZRoiB3sRVhzM/tw8+pjB65eLGJeQ k9x/E6RKqU10GK6hJP28VDu5bR7LngouVdf19h2XqineLTJSD5u8vuSZy kmGgQ6W1L9DmBki1W6a2u3SsINOoGMU1b74CnQ7a3UJUH4GfoF1RilI8z A==;
IronPort-SDR: SpdgZWJYfL0tugtGzYQFDhiO/y0NXCjQxYA5IjiW3ohNwkHcw99Dh/YNb5I5vKT/E0akruysWV ybtSHP2gEwYQ==
Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2020 17:10:49 +0100
IronPort-SDR: R5X8parCu76hHzHOmHqpu5CDkBRlILvzebiwuJAArWBVa/Mhuc9IuAOTZXYSWHsevZroo4h/dv ucq4PO7LHAQdd7J87MKfmoiJisSkCA+x0=
X-IronPort-AV: E=Sophos;i="5.70,456,1574118000"; d="scan'208";a="50212050"
X-MGA-submission: =?us-ascii?q?MDFTuwF+GEKZEIAErx0xV7gKWuM0RBGLKPBHHu?= =?us-ascii?q?LYCadKNC4xoB6YNgW/BfAq983/AKTKkI0onV9jlCjq04sm4anZi5pjFy?= =?us-ascii?q?R02ETlTRivngeyoWoIFZjMqQOlQXQJX78xf9x7/8Gm8HM3CAd7a1oNK2?= =?us-ascii?q?i7j7cCXCdpy76WSBqXgJNy9w=3D=3D?=
Received: from he105867.emea1.cds.t-internal.com ([10.169.119.44]) by qde0ps.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 18 Feb 2020 17:09:47 +0100
Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE105867.emea1.cds.t-internal.com (10.169.119.44) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Feb 2020 17:09:47 +0100
Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 18 Feb 2020 17:09:47 +0100
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.21) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Feb 2020 17:09:47 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JS4VhHbtYehM8PT43WGFgNa3p/2E3NW7Or5bhzqPXaE/0J5CoFYAIfhS9fkoz0y6nBtGJAQ4TqRMHhVKtzKN0LMsGWNUkwDYSFlg9+FNDDx8TpguP4HntLtfLiHUAp2ZcJKJ1aK0LZNNHt0M2haR4R5NtYcvG0wMPYnBs/JAlxQ7otbI8t2OtdujVF3Viw8wLUlYq+SCep26JIhbYjmcE6ltvEk//2dJ3V/S0ldvuanzvzpPHoe+n1RZ2ZwZOB5RES8+SgUEBO/Ott5GHGAO0SvkpzPwfCygXzNZc78sRNgXsetpHo6GMsIivnsPFvOdDG0zPcod+32Adj9RgshWUQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iDoUlsI9RWLXLWmmMLwXHSELoIrrdPAwg01cEiOPLA8=; b=PRzYVqwrW2emq4J8aVQrebE3vPlHVJ8PUDI45xA7fxH9DPBZYoPeWFMrfsxf1BMHL9vwyog5husVEdWwGNzO0yG9gjw6ncf9+BfS+CqZNbVzpkv6PavVDlgaQ06SrZIob95e1kWQSNmoo/tOAaZV6V2FrI3wOxiDCCb/6Ic17riD/MDUPmnoFMLwAhWPjhdxsXlYa5g/Nyxx7Qiz3QbQ+bWTQ1H3MKtn+k6S6N801GBSdUFMvDywJ7uoxID/olHk2ACiYdh66T6StKfEDTelXNOCl+YeBgKUkv8lKYE8t51aw7OsqoYa41nHvUz8khSnASBZoz6TtFE1l1Y7F5SmMQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from LEJPR01MB0668.DEUPRD01.PROD.OUTLOOK.DE (10.158.140.136) by LEJPR01MB0875.DEUPRD01.PROD.OUTLOOK.DE (10.158.143.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.27; Tue, 18 Feb 2020 16:09:45 +0000
Received: from LEJPR01MB0668.DEUPRD01.PROD.OUTLOOK.DE ([fe80::5db7:bcde:416d:c264]) by LEJPR01MB0668.DEUPRD01.PROD.OUTLOOK.DE ([fe80::5db7:bcde:416d:c264%8]) with mapi id 15.20.2707.035; Tue, 18 Feb 2020 16:09:45 +0000
From: 
To: 
CC: , , , 
Thread-Topic: [hackathon] Evaluate MPTCP RobE at IETF107 hackathon
Thread-Index: AdXmcziGDRW63vL7RKSs5c8WW7zaaw==
Date: Tue, 18 Feb 2020 16:09:45 +0000
Message-ID: 
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Markus.Amend@telekom.de; 
x-originating-ip: [164.19.3.189]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 63bd034b-bfeb-4399-1589-08d7b48cf89a
x-ms-traffictypediagnostic: LEJPR01MB0875:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 031763BCAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(396003)(346002)(136003)(189003)(199004)(966005)(86362001)(8676002)(478600001)(55016002)(2906002)(76116006)(54906003)(9686003)(33656002)(4326008)(64756008)(71200400001)(81166006)(81156014)(186003)(26005)(316002)(8936002)(7696005)(66946007)(5660300002)(6916009)(66476007)(4744005)(66556008)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0875; H:LEJPR01MB0668.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: vgsEk0Xvhlmu0Dw2G1x0R/mEAItj5DnDIWJNfQvNje9s7r43K9ncmqZwPr5iZM0a5TStu9/7ZVOVBkmxa6//s3HE2+s3J2rX00J5fhKzLCsbz+hbC+YPlN0UKw4Gc1WxwUnWII8ihTWTIQNldF92ogKAM8aRJsu3GImRa1qUdqDDr+zbeYVUnIhC/Kh91vfZmCGlMRZMWik70abDQggs4sjSgiGGsM49ZEo9us7dBx1ASYihEJByvR1VBAbt0QoaUTmXCzkkMMAHYPLo5ZBP6dbIMUt8oLlSNIvUwo6m5FBc/6zkgUNZ/DYHQondzBKM6isx3DFriavQy1GCiBC09BkarMujms+M0NCa1ky49tybNKhDOyAOGvhvwllN03qf/9/TA/S5VvR4qXPzk7a9G9WNYOavgeU6E6lXTZXP/+3USEvq1pu4+cq5hYz78k+jt6zvrc8eXwgVYH8eO1Po0K9HhPk3bxaWBLZaypQIClWpHDTYeGO5MfHJI+dgdyOd+3hNsJlp/3aBMvsvuu8jiw==
x-ms-exchange-antispam-messagedata: tzMFqZMndhsp8nD81AZBjCJ24DrnZdgw89RlZq5LQwHgnTVWAJrUABXa7U7MbgrLJBO1uuP34qDX6xqj+fwgLMFiH5L+Z5Q0NmFBUKxZClddz6eunLD6r+lJr3J8kBVAVkTElxyXJRWYybiKnfvNRg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 63bd034b-bfeb-4399-1589-08d7b48cf89a
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2020 16:09:45.4703 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ogeo+VlrvHrnN/KnnmgDqhxQrslVvFzCutU3X47iWmM4GDPVIdcWI9G5c3bojhPAw5vhZLhA17lOu3fp4SLC8g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0875
X-TM-SNTS-SMTP: FEAF04C746FABA3EFAB72E4D27755E351AB3AB4A5A41BC3489EA81EDD18CA3552000:8
X-OriginatorOrg: telekom.de
Archived-At: 
Subject: [tcpm] [hackathon] Evaluate MPTCP RobE at IETF107 hackathon
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2020 16:10:55 -0000

Dear all,

I kindly ask anyone who is keen in improving further MPTCP to join us at th=
e IETF 107 hackathon. We focus on improving MPTCP's handshake procedure to =
become robust against link outages on the initially selected path for conne=
ction establishment. This feature we call MPTCP Robust session Establishmen=
t (RobE) which is drafted in [1].

During the Hackathon we provide a testbed [2] for evaluating the different =
solutions from [1] RobE_TIMER, RobE_SIM, RobE_eSIM and RobE_IPS for compari=
ng it with the existing MPTCP [3][4] and its reference implementation [5].

If this matches your interest please don't hesitate to contact Jiao  or me .

Thanks.

BR

Jiao & Markus

[1] https://tools.ietf.org/html/draft-amend-mptcp-robe
[2] https://trac.ietf.org/trac/ietf/meeting/wiki/107hackathon/mptcp-robe/te=
stbed
[3] https://tools.ietf.org/html/rfc6824
[4] https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis
[5] https://github.com/multipath-tcp/mptcp




From nobody Wed Feb 19 01:57:00 2020
Return-Path: 
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 A0743120104; Wed, 19 Feb 2020 01:56:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 19fjZ50BEuQM; Wed, 19 Feb 2020 01:56:53 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 4E2DE1200B5; Wed, 19 Feb 2020 01:56:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:Cc:References:To:Subject:From:Sender:Reply-To: Content-Transfer-Encoding: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=vT/gyHz+bFaL8W3XBPWv3Gwv2NiCGsAkM842EfdiWPI=; b=FhZulsYhj/ajWCIM9p6yj0F35 GJ3YwfpvrovOa6vMUjkuYkCZE4PtudOHtf5bSKEFV18e+TJN5hoFeLbDJMN6pf3FNwGX4YzB5Tpoa XMCMEkMjschydeKJO4TfSYo3toX1e8gEJdA18JmQEdQx5hH35+x/W8dQod0C+XZBWRpY/gec1werH 0MJh4prObFvX+gnlbRpdVtejtaeAP5pUdGcv35CaiR+Dew4eIo68Mqu/QF3EwnkcPqW9q17KXkaX9 gq2VoxAGLfikZRJ6BDYtWtWB8DUZOYsXl8Z3+eOdC1CFXQK/wjEiq4J3ULACIj+u4cGwY3dOVTPWc ZgnUbvaOg==;
Received: from [31.185.128.125] (port=43824 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j4M64-0004VG-UT; Wed, 19 Feb 2020 09:56:49 +0000
From: Bob Briscoe 
To: "Scheffenegger, Richard" 
References: <6f6f4c2f-b72f-b7fb-55aa-c6985862d061@gmx.at> <3cd59a2f-d926-769c-175e-91938b962463@gmx.at>  <80dd5b8c-c45c-8777-da61-812a563d4b9f@bobbriscoe.net> 
Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-generalized-ecn@ietf.org" , FreeBSD Transport 
Message-ID: <7956ee17-7c68-727d-8254-8cd60551a86e@bobbriscoe.net>
Date: Wed, 19 Feb 2020 09:56:48 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------08A2A025B232F8B78A7F7D5A"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] ECN++
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 09:56:58 -0000

This is a multi-part message in MIME format.
--------------08A2A025B232F8B78A7F7D5A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Richard,
(pls cc tsvwg as the WG equally responsible for TCP ECN maintenance, if 
you think appropriate,
I've cut everyone except lists off the distro, 'cos posts were getting 
rejected )

Inline...

On 14/02/2020 19:06, Scheffenegger, Richard wrote:
> Hi Bob,
>
>
>> Interesting.
>> See inline tagged [BB]...
>>
>>> On 25/01/2020 10:41, Scheffenegger, Richard wrote:
>>> Hi Group, Marcelo, Bob,
>>>
>>>
>>> Another update in this context, which IMHO may be discussed as an
>>> actual change of mechanism with ECN++.
>>>
>>> I was looking into the very poor interaction of ECN between a Linux
>>> client and a BSD server, with request-response workload. That is,
>>> where each side sends out less than MSS data, before the application
>>> waits for the other side to respond to this.
>>>
>>> Neal pointed out this statement in RFC3168:
>>>
>>>     ...the TCP sender sets the CWR flag in
>>>     the TCP header of the first new data packet sent after the window
>>>     reduction.  ...
>>>     When the TCP data sender is ready to set the CWR bit after reducing
>>>     the congestion window, it SHOULD set the CWR bit only on the first
>>>     new data packet that it transmits.
>>>
>>> However, BSD is sending out the CWR as soon as possible - while Linux
>>> interprets the SHOULD overly strictly (IMHO) and ignores CWR unless it
>>> is received with (new) data.
>> [BB] Assuming the word '(new)' is optional, I think you're implying that
>> BSD would set CWR on a pure ACK if that were its first packet after it
>> received ECE feedback. Does BSD also set CWR on the first data packet
>> after that (if any)?
> Currently, FBSD is sending CWR with the next packet (pure ACK, Window
> Probe, Retransmission or New Data). But this should be fixed soon(ish).
>
> I used the bracket because RFC3168 is very clear, that CWR should *only*
> be sent with new data, but Linux would also accept it on any packet with
> data (this includes retransmissions and window probes).
>
>
>> I think RFC3168 expects CWR only on data packets - so that the sender
>> of the CWR can distinguish between ECE that the receiver sends before
>> vs after the receiver got the CWR (by whether the ackno of the ECE
>> covers the CWR data packet or not).
> Yes, effectively, CWR is bound to snd_max+1 in the sequence space on
> the first transmission with RFC3168. Unfortunately, it's not stated that
> clearly.
>
>> Consider 4 data packet exchanges of A>B, B>A, B>A, A>B with CWR
>> on pure ACKs.
>>
>>      A>>>B Data#1 
>>      A<<>                              ...potentially quiet for a time...
>>      A<<>      A>>>B ACK#101 *CWR*
>>                              ...potentially quiet for a time...
>>      A<<>      A>>>B ACK#102
>>                              ...potentially quiet for a time...
>>      A>>>B Data#2 *CWR* ACK#102
>>      A<<>
>> 'A' doesn't know whether the ECE on Data#102 was sent before or
>> after B received the CWR on A's pure ACK, so 'A' doesn't know
>> whether to reduce its window again or not.
>>
>> I can't find anything in RFC3168 that explicitly spells out when the sender
>> considers ECE to be in a new round. It jumps straight to describing the
>> exceptional case of a CWR packet being dropped, and omits the 'normal'
>> case of it being delivered.
> Well, if the ECE do not stop with the ACK covering the (former) snd_max+1,
> the CWR may have been lost (or delivered with a CE mark).
[BB] Which end are you talking about? As sender or as receiver? Which 
stage in the sequence are you talking about? Can you be more specific 
relative to the above example, where there are two transactions in a row 
initiated from B without any data from A in between. I deliberately 
constructed this so that A will not be able to tell whether B sent the 
ECE on its second volley (Data#102) before or after B received the CWR 
on A's pure ACK of B's first volley (Data#101).

My purpose was to prove that, if A sends CWR on a pure ACK, it makes 
itself unable to tell whether to reduce its window in response to any 
ECE it receives subsequently, because it cannot tell whether they are 
new or repeats. Therefore, RFC3168 must have meant 'the TCP sender MUST 
set the CWR flag in the TCP header of the first new data packet...' when 
it said:

    "the TCP sender sets the CWR flag in
    the TCP header of the first new data packet sent after the window
    reduction."

I suspect no-one thought to preclude the opposite, i.e. to say 'The 
sender MUST NOT set CWR on packets without new data'. Instead, it went 
straight to clarifying whether '/first/ new data' needed to be mandatory.

    "it SHOULD set the CWR bit only on the first
    new data packet that it transmits"

I reviewed RFC3168 at the time, as did many others, but no-one noticed 
these omissions.

> In either case,
> another congestion response is appropriate.
[BB] Surely not, if the CWR was on a pure ACK?

>> This seems to be missing - perhaps it ought to be added by an erratum.
>>
>>> But binding the CWR flag to a new data segment delays the ECN
>>> signaling loop artificially (for long runs of unidirectional
>>> transmitted data), and it is not clear what the benefit there would
>>> be, as the CWR flag is not retransmitted anyway (thus not bound to a
>>> point in the sequence number space).
>> [BB] Surely long runs of unidirectional transmitted data don't exhibit
>> this problem, 'cos there's plenty of new data to carry the CWR. Or
>> have I misunderstood?
> Transactional data has frequent changes in data direction. But that behavior
> (delaying CWR to only send it with new data) IMHO makes ECN unusable for Ack
> Moderation (AckCC). Just wondering, if a different way of tracking the packets
> In flight during a window would allow the immediate transmission of CWR
> with ECN++, to make ECN useful for Ack Moderation or other future purposes.
[BB] CWR is only used if RFC3168 feedback has been negotiated.
The WG consensus was that we shouldn't put ECT on pure ACKs if RFC3168 
feedback has been negotiated; only if AccECN had been negotiated.

So, once you have AccECN and ECN++, you can do what you are wanting, 
'cos AccECN allows both the data receiver to set ECT on pure ACKs and 
the data sender to count CEs on arriving pure ACKs. The data sender then 
includes this count in the ACE counter it feeds back on subsequent 
packets it sends (probably data packets, but could be on pure ACKs as 
well when data is bi-directional).

See
https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-3.2.3.2.1 
(normative)
which refers to
https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-4.4.1 
(informative)


>> In fact, the problem I see with RFC3168 is the opposite case. It seems
>> there was an assumption that a data sender would be continually sending
>> data, so that, once ECE feedback appeared at the sender, it would conveniently
>> always have some data to send, on which CWR could be carried.
> Correct. With transactional data, this assumption breaks and long flights of
> Packets will continuously have ECE set.
[BB] I have a terminology blockage here. I interpret 'long flights of 
packets' to be a long-running flow - the opposite of 'transactional 
data'. But you seem to be using 'long flights of data' to describe 
'transactional data'. Not sure what the disconnect is.

>> For instance, in the sequence above, host A might not send Data#2 for ages
>> or perhaps never (a typical case if 'A' is a client requesting a large object). In
>> the intervening time, B might send far more than the two packets shown. If 'A'
>> does not set CWR on pure ACKs, all B's data packets would have to carry ECE,
>> perhaps for many hours, until A has some more data to send (if ever).
>>
>> Nontheless, I think ECE continuing for hours is fine within the logic of RFC3168.
>> While A isn't sending anything, it only reduces cwnd once, and it's not
>> measuring any round trips, so it's not increasing cwnd either.
>>
>> Can you describe your case more precisely, so I can understand what caused
>> the performance hit?
> The problem comes from FBSD sending CWR (typically) on pure ACKs - where
> Linux ignores the CWR and keeps ECE set; Thus FBSD observes "new" ECE in the
> Following window, resulting in another congestion response - while no further
> CE mark was actually present.
[BB] I think you are solely talking about the case where sending of each 
transactional data volley strictly alternates between A and B.

I am trying to get you to think about a case where one end sends more 
than one volley in succession, in order to show that setting CWR on a 
pure ACK creates problems. That's why I asked, how does an FBSD receiver 
(or Linux receiver for that matter) know what a 'following window' is if 
it's only sending pure ACKs? They all have the same seqno and they don't 
get ACK'd. So the pure receiver can't know what an RTT is.

I also asked whether, if the FBSD host (that has been receiving data) 
does send some data between its pure ACKs, does it repeat the CWR on the 
data even tho it already set it on an earlier pure ACK?

> This leads to a race to the bottom for FBSD, where cwnd contionously shrinks
> (due to another bug, down to a size of 0 [zero]). Eventually, FBSD clocks out
> 1 byte every 4 seconds with a timer normally used for Window Probes (but
> Unlike Window Probes, that one byte is actually new data).
>
> Eventually CWR may be sent with a data packet (that 1-byte probe), accepted
> By Linux, ECE unlatched, and cwnd can start growing again. But that event may
> Happen only many minutes into entering this situation (got a trace, where this
> effect lasted nearly 10 minutes).
>
> Obviously, the reverse data direction doesn’t suffer the same problem, nor does
> a typical FBSD-FBSD ECN session suffer that fate (even though CWR are sent mostly
> on pure ACKs)
>
>>> I therefore propose a change in the Generalized ECN draft, to lift the
>>> above restriction (while it is "only" a SHOULD, this is one more
>>> example of an overly strict receiving-side implementation), and no
>>> longer artificially delay the CWR signal - to become also more useful
>>> for passive measurements.
>> [BB] I'm not yet convinced that this CWR behaviour is anything to do with
>> the ECN++ draft. But that might be because I've misunderstood your
>> description. As I said above, it might be possible to rectify omissions
>> with an erratum to RFC3168.
> In RFC3168, both ECT-codepoints and the CWR flag are defined to only be set on
> new data segments.
[BB] Not strictly true for the CWR flag, as discussed earlier, this part 
of RFC3168 seems not to have been fully tied up.


> Thus setting both can be simplified into a single branch; Getting the CWR indication
> Slightly faster (not binding it to snd_max+1), that is, even with the next pure ack, probe
> Or retransmission, would possibly provide a faster feedback (passive measurement
> Of the window), and could enable the use of ECN signals for ACK moderation.
>
> The drawback would be additional congestion responses, if the packet carrying the CWR
> Is dropped (congestion on the path carrying the pure ACKs). But IIRC, reacting to congestion
> On the (relatively) low bandwidth reverse direction by moderating the transmission speed
> (or asking for fewer ACKs) may be not too inappropriate...
[BB] I don't believe the CWR mechanism is suitable for faster congestion 
notification or for Ack CC. The way it's designed is tied in so much to 
reliable delivery that it actually breaks if you send it unreliably on 
pure ACKs (as I've tried to prove, and as you have discovered).

>
>> more...
>>> For those interested: The effect of ignoring the CWR on non-new-data
>>> segments by Linux is, that the ECE flag is left latched. Thus BSD
>>> continues window-after-window with cwnd reductions,
>> [BB] If it's not sending new data, how does the BSD host consider that
>> windows are starting or completing?
> It still tracks snd_recover (snd_max when the first ECE is received). I have not
> Looked into this in detail yet, though. It may even reduce cwnd while being
> The passive receiver...
[BB] (repeating what I've said already) I don't see how it can know what 
an RTT is when its continually sending pure ACKs with the same seqno.

Cheers


Bob
>> Bob


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


--------------08A2A025B232F8B78A7F7D5A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Richard, 

    (pls cc tsvwg as the WG equally responsible for TCP ECN maintenance,
    if you think appropriate, 

    I've cut everyone except lists off the distro, 'cos posts were
    getting rejected )

    

    Inline...

    

    
On 14/02/2020 19:06, Scheffenegger,
      Richard wrote:

    

    

      
Hi Bob,




      

        
Interesting.
See inline tagged [BB]...



        

          
On 25/01/2020 10:41, Scheffenegger, Richard wrote:
Hi Group, Marcelo, Bob,


Another update in this context, which IMHO may be discussed as an 
actual change of mechanism with ECN++.

I was looking into the very poor interaction of ECN between a Linux 
client and a BSD server, with request-response workload. That is, 
where each side sends out less than MSS data, before the application 
waits for the other side to respond to this.

Neal pointed out this statement in RFC3168:

   ...the TCP sender sets the CWR flag in
   the TCP header of the first new data packet sent after the window
   reduction.  ...
   When the TCP data sender is ready to set the CWR bit after reducing
   the congestion window, it SHOULD set the CWR bit only on the first
   new data packet that it transmits.

However, BSD is sending out the CWR as soon as possible - while Linux 
interprets the SHOULD overly strictly (IMHO) and ignores CWR unless it 
is received with (new) data.


        

        
[BB] Assuming the word '(new)' is optional, I think you're implying that 
BSD would set CWR on a pure ACK if that were its first packet after it 
received ECE feedback. Does BSD also set CWR on the first data packet
after that (if any)?


      

      
Currently, FBSD is sending CWR with the next packet (pure ACK, Window 
Probe, Retransmission or New Data). But this should be fixed soon(ish).

I used the bracket because RFC3168 is very clear, that CWR should *only* 
be sent with new data, but Linux would also accept it on any packet with 
data (this includes retransmissions and window probes).




      

        
I think RFC3168 expects CWR only on data packets - so that the sender 
of the CWR can distinguish between ECE that the receiver sends before 
vs after the receiver got the CWR (by whether the ackno of the ECE 
covers the CWR data packet or not).


      

      
Yes, effectively, CWR is bound to snd_max+1 in the sequence space on 
the first transmission with RFC3168. Unfortunately, it's not stated that 
clearly.



      

        
Consider 4 data packet exchanges of A>B, B>A, B>A, A>B with CWR 
on pure ACKs.

    A>>>B Data#1 <CE in transit>
    A<<<B ACK#1 ECE
                            ...potentially quiet for a time...
    A<<<B Data#101 ECE ACK#1
    A>>>B ACK#101 *CWR*
                            ...potentially quiet for a time...
    A<<<B Data#102 ECE ACK#1
    A>>>B ACK#102
                            ...potentially quiet for a time...
    A>>>B Data#2 *CWR* ACK#102
    A<<<B ACK#2

'A' doesn't know whether the ECE on Data#102 was sent before or 
after B received the CWR on A's pure ACK, so 'A' doesn't know 
whether to reduce its window again or not.

I can't find anything in RFC3168 that explicitly spells out when the sender 
considers ECE to be in a new round. It jumps straight to describing the 
exceptional case of a CWR packet being dropped, and omits the 'normal' 
case of it being delivered.


      

      
Well, if the ECE do not stop with the ACK covering the (former) snd_max+1,
the CWR may have been lost (or delivered with a CE mark). 

    

    [BB] Which end are you talking about? As sender or as receiver?
    Which stage in the sequence are you talking about? Can you be more
    specific relative to the above example, where there are two
    transactions in a row initiated from B without any data from A in
    between. I deliberately constructed this so that A will not be able
    to tell whether B sent the ECE on its second volley (Data#102)
    before or after B received the CWR on A's pure ACK of B's first
    volley (Data#101). 

    

    My purpose was to prove that, if A sends CWR on a pure ACK, it makes
    itself unable to tell whether to reduce its window in response to
    any ECE it receives subsequently, because it cannot tell whether
    they are new or repeats. Therefore, RFC3168 must have meant 'the TCP
    sender MUST set the CWR flag in the TCP header of the first new data
    packet...' when it said:

    
   "the TCP sender sets the CWR flag in
   the TCP header of the first new data packet sent after the window
   reduction."


    I suspect no-one thought to preclude the opposite, i.e. to say 'The
    sender MUST NOT set CWR on packets without new data'. Instead, it
    went straight to clarifying whether '/first/ new data' needed to be
    mandatory.

    
   "it SHOULD set the CWR bit only on the first
   new data packet that it transmits"

    I reviewed RFC3168 at the time, as did many others, but no-one
    noticed these omissions.

    

    

      
In either case, 
another congestion response is appropriate.

    

    [BB] Surely not, if the CWR was on a pure ACK?

    

    

      

      

        
This seems to be missing - perhaps it ought to be added by an erratum.



        

          
But binding the CWR flag to a new data segment delays the ECN 
signaling loop artificially (for long runs of unidirectional 
transmitted data), and it is not clear what the benefit there would 
be, as the CWR flag is not retransmitted anyway (thus not bound to a 
point in the sequence number space).


        

        
[BB] Surely long runs of unidirectional transmitted data don't exhibit 
this problem, 'cos there's plenty of new data to carry the CWR. Or 
have I misunderstood?


      

      
Transactional data has frequent changes in data direction. But that behavior
(delaying CWR to only send it with new data) IMHO makes ECN unusable for Ack
Moderation (AckCC). Just wondering, if a different way of tracking the packets
In flight during a window would allow the immediate transmission of CWR 
with ECN++, to make ECN useful for Ack Moderation or other future purposes.

    

    [BB] CWR is only used if RFC3168 feedback has been negotiated.

    The WG consensus was that we shouldn't put ECT on pure ACKs if
    RFC3168 feedback has been negotiated; only if AccECN had been
    negotiated. 

    

    So, once you have AccECN and ECN++, you can do what you are wanting,
    'cos AccECN allows both the data receiver to set ECT on pure ACKs
    and the data sender to count CEs on arriving pure ACKs. The data
    sender then includes this count in the ACE counter it feeds back on
    subsequent packets it sends (probably data packets, but could be on
    pure ACKs as well when data is bi-directional).

    

    See

    https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-3.2.3.2.1
    (normative)

    which refers to

    https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-4.4.1
    (informative)

    

    

    

      

      

        
In fact, the problem I see with RFC3168 is the opposite case. It seems
there was an assumption that a data sender would be continually sending
data, so that, once ECE feedback appeared at the sender, it would conveniently
always have some data to send, on which CWR could be carried.


      

      
Correct. With transactional data, this assumption breaks and long flights of 
Packets will continuously have ECE set.

    

    [BB] I have a terminology blockage here. I interpret 'long flights
    of packets' to be a long-running flow - the opposite of
    'transactional data'. But you seem to be using 'long flights of
    data' to describe 'transactional data'. Not sure what the disconnect
    is.

    

    

      

      

        
For instance, in the sequence above, host A might not send Data#2 for ages 
or perhaps never (a typical case if 'A' is a client requesting a large object). In
the intervening time, B might send far more than the two packets shown. If 'A'
does not set CWR on pure ACKs, all B's data packets would have to carry ECE, 
perhaps for many hours, until A has some more data to send (if ever).

Nontheless, I think ECE continuing for hours is fine within the logic of RFC3168. 
While A isn't sending anything, it only reduces cwnd once, and it's not 
measuring any round trips, so it's not increasing cwnd either.

Can you describe your case more precisely, so I can understand what caused 
the performance hit?


      

      
The problem comes from FBSD sending CWR (typically) on pure ACKs - where
Linux ignores the CWR and keeps ECE set; Thus FBSD observes "new" ECE in the 
Following window, resulting in another congestion response - while no further
CE mark was actually present.

    

    [BB] I think you are solely talking about the case where sending of
    each transactional data volley strictly alternates between A and B.

    

    I am trying to get you to think about a case where one end sends
    more than one volley in succession, in order to show that setting
    CWR on a pure ACK creates problems. That's why I asked, how does an
    FBSD receiver (or Linux receiver for that matter) know what a
    'following window' is if it's only sending pure ACKs? They all have
    the same seqno and they don't get ACK'd. So the pure receiver can't
    know what an RTT is.

    

    I also asked whether, if the FBSD host (that has been receiving
    data) does send some data between its pure ACKs, does it repeat the
    CWR on the data even tho it already set it on an earlier pure ACK? 

    

    

      
This leads to a race to the bottom for FBSD, where cwnd contionously shrinks 
(due to another bug, down to a size of 0 [zero]). Eventually, FBSD clocks out
1 byte every 4 seconds with a timer normally used for Window Probes (but
Unlike Window Probes, that one byte is actually new data).

Eventually CWR may be sent with a data packet (that 1-byte probe), accepted
By Linux, ECE unlatched, and cwnd can start growing again. But that event may
Happen only many minutes into entering this situation (got a trace, where this 
effect lasted nearly 10 minutes).

Obviously, the reverse data direction doesn’t suffer the same problem, nor does
a typical FBSD-FBSD ECN session suffer that fate (even though CWR are sent mostly
on pure ACKs)



      

        

          
I therefore propose a change in the Generalized ECN draft, to lift the 
above restriction (while it is "only" a SHOULD, this is one more 
example of an overly strict receiving-side implementation), and no 
longer artificially delay the CWR signal - to become also more useful 
for passive measurements.


        

        
[BB] I'm not yet convinced that this CWR behaviour is anything to do with 
the ECN++ draft. But that might be because I've misunderstood your 
description. As I said above, it might be possible to rectify omissions 
with an erratum to RFC3168.


      

      
In RFC3168, both ECT-codepoints and the CWR flag are defined to only be set on
new data segments.

    

    [BB] Not strictly true for the CWR flag, as discussed earlier, this
    part of RFC3168 seems not to have been fully tied up.

    

    

    

      
Thus setting both can be simplified into a single branch; Getting the CWR indication
Slightly faster (not binding it to snd_max+1), that is, even with the next pure ack, probe
Or retransmission, would possibly provide a faster feedback (passive measurement
Of the window), and could enable the use of ECN signals for ACK moderation.

The drawback would be additional congestion responses, if the packet carrying the CWR
Is dropped (congestion on the path carrying the pure ACKs). But IIRC, reacting to congestion
On the (relatively) low bandwidth reverse direction by moderating the transmission speed 
(or asking for fewer ACKs) may be not too inappropriate...

    

    [BB] I don't believe the CWR mechanism is suitable for faster
    congestion notification or for Ack CC. The way it's designed is tied
    in so much to reliable delivery that it actually breaks if you send
    it unreliably on pure ACKs (as I've tried to prove, and as you have
    discovered). 

    

    

      



      

        
more...


      

      

        

          
For those interested: The effect of ignoring the CWR on non-new-data 
segments by Linux is, that the ECE flag is left latched. Thus BSD 
continues window-after-window with cwnd reductions,


        

        
[BB] If it's not sending new data, how does the BSD host consider that 
windows are starting or completing?


      

      
It still tracks snd_recover (snd_max when the first ECE is received). I have not
Looked into this in detail yet, though. It may even reduce cwnd while being
The passive receiver...

    

    [BB] (repeating what I've said already) I don't see how it can know
    what an RTT is when its continually sending pure ACKs with the same
    seqno.

    

    Cheers

    

    

    Bob

    

      

      

        
Bob


      

    

    

    

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

  


--------------08A2A025B232F8B78A7F7D5A--


From nobody Wed Feb 19 03:10:26 2020
Return-Path: 
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 D99FB12003E for ; Wed, 19 Feb 2020 03:10:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi
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 a6_ZDZAyPWJD for ; Wed, 19 Feb 2020 03:10:20 -0800 (PST)
Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C229120132 for ; Wed, 19 Feb 2020 03:10:19 -0800 (PST)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Wed, 19 Feb 2020 13:09:51 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=xgmpc7 gqE/j19/biH5OjQKqvpLkKJaShM88zl6OrYpo=; b=evHQnu67kP96veg8GqOYD0 2ycNnl3c4qv8xl1obHdBQiSKJu0BivE+Bnr6MII1NiBDeJXOMCEwT/lDdkYeyluX 1eSMY3Coe8Jor+4AzBPR50Z2I5xZ7py35RjevZNsI3sBoflg3FnezJcbmh3PAHvE ZyaSa+3mW5k6U/v6I3X68=
Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Wed, 19 Feb 2020 13:09:51 +0200 id 00000000005A00B9.000000005E4D177F.000011A0
Date: Wed, 19 Feb 2020 13:09:51 +0200 (EET)
From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" 
X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi
To: Bob Briscoe 
cc: Mirja Kuehlewind , Richard Scheffenegger , tcpm@ietf.org
In-Reply-To: 
Message-ID: 
References:  
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_script-4536-1582110591-0001-2"
Content-ID: 
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09 review
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Feb 2020 11:10:24 -0000

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_script-4536-1582110591-0001-2
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-ID: 

On Fri, 14 Feb 2020, Bob Briscoe wrote:

> On 12/02/2020 14:30, Ilpo J=E4rvinen wrote:
>=20
> I find it odd that the draft only addresses ACK reordering in Appendix
> as it's very important for the robustness of the counters (ensuring
> they are never decreasing).
>=20
> I think it would be helpful from implementer point-of-view to have
> a table about all detectable failure conditions and how to respond to=20
> each.
>=20
> [BB] That would be useful. Given I believe you've now implemented the f=
ull
> spec, and come up with numerous corner cases, would you be willing to h=
elp
> to produce this table?

I can try to.

> 24-bit counter updates
>=20
> If an endpoint estimates the counter, unsigned delta update cannot
> backtrack a counter when the estimation got it wrong (due to ACK
> loss or ACK reordering). The delta should be treated as 24-bit
> signed value to allow corrections to down direction.
>=20
> [BB] That seems easy to fix. However, I can't see that the appendix sta=
tes
> that the delta is unsigned. If you're talking about Appx A.1, it only s=
ays
> the counter is unsigned. It doesn't mention what the delta is. Or are y=
ou
> concerned about this sentence and the pseudocode under it:
>=20
>    Otherwise, the Data Sender
>    calculates the minimum difference d.ceb between the ECEB field and
>    its local s.ceb counter, using modulo arithmetic as follows:
> which doesn't mention that d.ceb is unsigned. Perhaps you are concerned
> about ambiguity, given different programming languages define modulo
> arithmetic with signed types differently?

It does not mention it which is part of the problem. ...That, however,=20
doesn't make it ambiguous because only one interpretation makes sense=20
given that the d.cep uses the very same formula. That d.cep uses unsigned=20
delta, no?

Language dependent issues is another can of worms I wouldn't even want
to consider opening here.

> A long run of ECN field may overflow the byte counter if the
> AccECN option is not sent often enough. The option should sent like eve=
ry=20
> 2^22 received as then the currently increasing counter cannot overflow=20
> before the option gets scheduled again.
>=20
> '[BB] Again, this seems like a simple fix. To be clear, are you saying =
this
> should be added to the list of rules in 3.2.8 for when a Data Receiver
> includes an Option on an ACK?

Yes, I think that's the most appropriate place for them. Something along=20
the lines of:

=09      ...
              Option if r.ec0b or r.ec1b has incremented;

              It SHOULD, ho=
wever,
              send an AccECN TCP Option at least once for every 2^22 byte=
s
              received to prevent overflowing the currently incrementing =
byte
              counter during continual repetition.
              

              It SHOULD al=
ways
              ...
=20

> Sect 3.2.2.
>=20
> Table 3 does not show how to set the client should set the ACE field,
> despite the preceeding paragraph clearly assuming it does. Either
> Table 3 needs to be adjusted or another table added which just contains
> a straightforward SYN/ACK ECN field value -> reflector bits mapping.
>=20
> [BB] Good point. I've kept the table (which is for reading the field an=
d
> only for writing it by implication). But I've changed the first sentenc=
e to:
>
>    There is only one exception to this rule: On the final ACK of the
>    3-way handshake (3WHS), a TCP client (A) in AccECN mode MUST feed
>    back which of the 4 possible values of the IP-ECN field were on the
>    SYN/ACK using the same binary encoding as that used on the SYN/ACK
>    (see Table 2).
>
>    Table 3 shows the meaning of each possible value...=20
> Do you think this reference to Table 2 is clear enough? Or do you think =
we
> ought to produce a small 4x2 table repeating the relevant 4 codes?

I was going to write that extra table is not necessary but it looks like=20
both Table 2 and 3 are tricky to use for this purpose because it needs
to be interpreted right-to-left order to get the message (IP-ECN field is=20
in the last or in 2nd column, and what to do is in the column left of=20
it). And that's in addition to the problem with extra rows that are=20
confusing at least in Table 3 (Table 2 could have an additional
separator between the first 4 rows and the rest though which might make
it slightly easier to comprehend which subset is relevant).

> Sect 5.
>=20
> Doesn't mention reordering at all?
>=20
> [BB] Added the following at the end of the Resilience bullet:
>=20
>       And if data or
>       ACKs are reordered, stale congestion information can be identifie=
d
>       and ignored.
>=20
> And at the end of the bullet listing 3 ways in which AccECN is not resi=
lient
> to reordering:
>=20
> =A0=A0=A0=A0=A0 Following ACK reordering, the Data Sender can
> =A0=A0=A0=A0=A0 reconstruct the order in which feedback was sent, but n=
ot until
> =A0=A0=A0=A0=A0 all the missing feedback has arrived.
>=20
> Did you have anything else specific in mind?

Nothing specific but I'd have found it worrying if nothing would have=20
been there (if I'd have no earlier AccECN bg) giving an impression that=20
reordering was not even thought of and yet it seems obvious that it
will break a delta if not considered.

>       "to ensure that any blocking of anomalous values is
>       always at least under reversible policy control."
> ...I failed to understand what this fragment tried to say.
>=20
> [BB] OK, I admit that's rather impenetrable wording. How about:
>=20
>       Then, the designers of security devices can
>       understand which currently unused values might appear in future.
>       So, even if they choose to treat such values as anomalous while
>       they are not widely used, any blocking will at least be under
>       policy control not hard-coded.  Then, if previously unused values
>       start to appear on the Internet (or in standards), such policies
>       could be quickly reversed.

I can understand it now :-).

> Appendix A.1.
>=20
>    "On the arrival of an AccECN Option, the Data Sender uses the TCP
>    acknowledgement number and any SACK options to calculate newlyAckedB=
,"
> SACK required?
>=20
> [BB] Surely the words 'and any' makes it clear that SACK is not require=
d. Do
> you mean that you believe this is impossible without SACK?

No, that's not my intent. ...But now my follow up comment is that the=20
resulting newlyAckedB is different depending on whether SACK is enabled o=
r=20
not. Therefore, newlyAckedB is less precise without SACK and it does caus=
e=20
some ACKs not being able to update AccECN state when timestamps are not=20
available (the appendix doesn't given any resolution to it nor reassures=20
that it's still OK).=20

>    "If
>    newlyAckedB is negative it means that a more up to date ACK has
>    already been processed, so this ACK has been superseded and the Data
>    Sender has to ignore the AccECN Option."
> By definition, "newlyAckedB" cannot be negative!
>=20
> [BB] OK, this block of text is used twice. I agree it's confusing.
>=20
> Would "if there are no newly ACKd octets" be acceptable? Then in the
> pseudocode,
> =A0=A0=A0 "if (newlyAckedB) {"
>=20
> This doesn't include the ACK reordering case (see next).
>=20
>    "if (newlyAckedB >=3D 0) {"
> newlyAckedB =3D=3D 0 is problematic when there's ACK reordering? There'=
s better
> condition in other algorithm which takes advantage of timestamps (when)
> present later in the Appendices.
>=20
> [BB] I'm not sure what you want me to do here.
> Note also that we need to say something for the case when timestamps ar=
e not
> available.

This particular fragment did not contain the timestamp related checks=20
the other similar copy has. If timestamps are not enabled, then only > 0=20
should be allowed although I think that the counters themselves could be=20
used to prove the ACK ordering in that case (as they should be always=20
increasing sans the wraps).

Perhaps it would be useful to define a helper for these check and use tha=
t=20
in both places?

>    "d.ceb =3D (ECEB + DIVOPT - (s.ceb % DIVOPT)) % DIVOPT"
> "+ DIVOPT" and the first "% DIVOPT" look superflucious to me given
> modular arithmetic is being used here.
>=20
> [BB] With many compilers (e.g. C99), the value of d.ceb using the examp=
le
> decimal values given just below that statement (s.ceb =3D 33,554,433; E=
CEB =3D
> 1461, DIVOPT =3D 2^24) would be non-positive without the first "% DIVOP=
T", but
> non-negative with it.
>=20
> The first % DIVOPT ensures that the value in the inner parenthesis is
> <=3DDIVOPT so the result of the subtraction is non-negative, which is w=
hat you
> want, in case the field wraps.
>=20
> Incidentally, once you can rely on d.ceb being non-negative, you can pr=
oduce
> optimized code like this: =A0=A0=A0
> =A0=A0=A0 #define DIV_MASK DIVOPT-1
> =A0=A0=A0 d.ceb =3D (ECEB + DIVOPT - (s.ceb & DIVOPT_MASK)) & DIVOPT_MA=
SK
> I'm pretty sure a compiler would not be able to do this for you, 'cos i=
t
> would have to prove to itself that the subtraction is always non-negati=
ve,
> which would be a rather clever compiler.

So this +DIVOPT term is there just to allow a compiler optimization??
Even if it proves that, it's still far more complicated than necessary
for a real implementation (with 2's complement). I'm actually surprised=20
the reasoning because I thought the formula is like that to specify it=20
"accurately" but now it turns out it looks that complex because of=20
premature optimization.

For real (2's complement) implementations, it's much more straightforward=20
to do:
  delta =3D sign_extend_from24bits((ECEB - s.ceb) & DIVOPT_MASK)=20

> While researching this answer, I've discovered that the draft ought to
> define % as the remainder operator, not the modulo operator. I learned =
that,
> with a remainder operator the sign of the result of a%b is the same as =
the
> sign of 'a'. While with a modulo operator the sign of the result is the =
same
> as 'b'.

Remainder won't work with the d.cep that needs to be unsigned and it=20
uses the very same formula (with %).

> Appendix A.3.
>=20
>     "However it would be simpler to
>     merely maintain a counter packets_in_flight for the number of packe=
ts
>     in flight (including control packets), which it could update once p=
er
>     RTT."
> I'm not convinced that this is very simple either. Given that flightsiz=
e
> is maintained more frequently than once per RTT which likely leads to s=
ome
> tricky corner cases when their values are out of sync.
>=20
> [BB] I think you're right. This is more than a editorial nit. Nonethele=
ss, I
> think Mirja implemented this then wrote this section. Nonetheless, I th=
ink
> you based your implementation on Olivier's which was based on Mirja's. =
So if
> this Estimation algo was not already in your code, that probably means =
I'm
> wrong.

Since nothing in Linux really depends on the byte counters currently,=20
this is not implemented by me. In Linux, the problem tends to be a revers=
e
of what A.3 tries to do because linux CC runs in packets rather than byte=
s=20
(except for very limited subsets such as pacing where bytes come into=20
play too).


--=20
 i.
--=_script-4536-1582110591-0001-2--


From nobody Wed Feb 26 00:25:18 2020
Return-Path: 
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 4519C3A1080; Wed, 26 Feb 2020 00:25:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.787
X-Spam-Level: 
X-Spam-Status: No, score=-0.787 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, RCVD_IN_RP_RNBL=1.31, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 uYeSOGmQhLke; Wed, 26 Feb 2020 00:25:10 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6FF3A107D; Wed, 26 Feb 2020 00:25:09 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 3382525A16; Wed, 26 Feb 2020 09:25:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1582705508; bh=88gWBGxtPO/PwzJQtkYDnKodiD8rKd8SkPM7PST2gUo=; h=From:To:CC:Subject:Date:From; b=iFgBg7cwa6gQSrAW22aDLMMsInWPLSlin5PIXZ8WuPcEwGMUP7Sut6W8eVJwtt44s CzhTvY0u8REX8zP5yNIQe/EmGCqpoAuiirg9mY+hzQpY+rw3vM94mlFc1LMptt11eu Hc0HIk7xxB4XQ5OoBLfMno3J9rEcefuLu6rks58Q=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpH6wIDOAagO; Wed, 26 Feb 2020 09:25:04 +0100 (CET)
Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 26 Feb 2020 09:25:04 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.209]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Wed, 26 Feb 2020 09:25:03 +0100
From: "Scharf, Michael" 
To: tcpm IETF list 
CC: "multipathtcp@ietf.org" , "tcpm-chairs@ietf.org" 
Thread-Topic: TCPM rechartering to add MPTCP maintenance
Thread-Index: AdXsfiYbdxTCvkRaSHGznmUWO5g9GQ==
Date: Wed, 26 Feb 2020 08:25:02 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D99CD22@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] TCPM rechartering to add MPTCP maintenance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2020 08:25:13 -0000

Hi all,

As TCPM shall in future maintain MPTCP, we propose a small addition to the =
TCPM charter.

The chairs and the responsible ADs believe that MPTCP maintenance and minor=
 MPTCP enhancements would formally be possible with the current TCPM charte=
r text, as MPTCP is a TCP extension. Yet, our preference is to state explic=
itly that MPTCP maintenance is in scope of TCPM, in particular also to make=
 this transparent to people outside the IETF.

Therefore, we propose the following small addition to the current TCPM char=
ter (the addition is flagged by  and the current TCPM charter is=
 fully copied as reference):


TCP is currently the Internet's predominant transport protocol. TCPM
is the working group within the IETF that handles small TCP changes,
i.e., minor extensions to TCP algorithms and protocol mechanisms.
The TCPM WG serves several purposes:=20

* The WG mostly focuses on maintenance issues (e.g., bug fixes) and
modest changes to the protocol, algorithms, and interfaces that
maintain TCP's utility.

* The WG is a venue for moving current TCP specifications along the
standards track (as community energy is available for such efforts).=20


* The WG maintains Multipath TCP (MPTCP) and is a home for minor
MPTCP enhancements including updates to the existing multipath
congestion control.


* The focus of the working group is TCP. In cases where small
changes are directly applicable to other transports (e.g., SCTP or
DCCP), the mappings to other transports may be specified alongside
that for TCP, but other significant additions and changes to other
transports are not in scope.

TCPM also provides a venue for standardization of incremental
enhancements of TCP's standard congestion control. In addition,
TCPM may document alternative TCP congestion control algorithms
that are known to be widely deployed, and that are considered
safe for large-scale deployment in the Internet. Changes of algorithms
may require additional review by the IRTF Congestion Control
Research Group (ICCRG). Fundamental changes to TCP or its congestion
control algorithms (e.g., departure from loss-based congestion
control) will be handled by other working groups or will require
rechartering.

TCP's congestion control algorithms are the model followed by
alternate transports (e.g., SCTP or DCCP), which are standardized in
other working groups, such as the Transport Area WG (tsvwg). In the
past, the IETF has worked on several documents about algorithms that
are specified for multiple protocols (e.g., TCP and SCTP) in the
same document. Which WG shepherds such documents will be determined
on a case-by-case basis. In any case, the TCPM WG will remain in
close contact with other relevant WGs working on these protocols to
ensure openness and stringent review from all angles.

New TCPM milestones that fall within the scope specified within the
charter can be added after consensus on acceptance in the working
group and approval by the responsible Area Director.


We do not plan any other changes to the TCPM charter, i.e., any MPTCP-relat=
ed work would follow the process explained in the last sentence of the char=
ter.

Even if this is only one additional sentence, any re-chartering requires IE=
SG approval. The current plan is to get IESG approval for the new TCPM char=
ter prior to IETF 107. Obviously, the first step is to reach consensus insi=
de TCPM.

I add the MPTCP WG list in CC. Yet, any discussion of the TCPM charter shou=
ld take place at tcpm@ietf.org.

Please review the charter proposal, and please let us know any comments ASA=
P.

Best regards

Michael


From nobody Wed Feb 26 01:39:05 2020
Return-Path: 
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 58E0E3A1192; Wed, 26 Feb 2020 01:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 hVtG5pzqWWXT; Wed, 26 Feb 2020 01:38:58 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA9F3A1193; Wed, 26 Feb 2020 01:38:57 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5D34C1B00193; Wed, 26 Feb 2020 09:38:51 +0000 (GMT)
To: "Scharf, Michael" , tcpm IETF list 
Cc: "multipathtcp@ietf.org" , "tcpm-chairs@ietf.org" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D99CD22@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Gorry Fairhurst 
Message-ID: <540ca6c0-3a72-2ca1-e9fa-e914ad1ee259@erg.abdn.ac.uk>
Date: Wed, 26 Feb 2020 09:38:50 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D99CD22@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: 
Subject: Re: [tcpm] TCPM rechartering to add MPTCP maintenance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2020 09:39:00 -0000

See below:

On 26/02/2020 08:25, Scharf, Michael wrote:
> Hi all,
>
> As TCPM shall in future maintain MPTCP, we propose a small addition to the TCPM charter.
>
> The chairs and the responsible ADs believe that MPTCP maintenance and minor MPTCP enhancements would formally be possible with the current TCPM charter text, as MPTCP is a TCP extension. Yet, our preference is to state explicitly that MPTCP maintenance is in scope of TCPM, in particular also to make this transparent to people outside the IETF.
>
> Therefore, we propose the following small addition to the current TCPM charter (the addition is flagged by  and the current TCPM charter is fully copied as reference):
>
> 
> TCP is currently the Internet's predominant transport protocol. TCPM
> is the working group within the IETF that handles small TCP changes,
> i.e., minor extensions to TCP algorithms and protocol mechanisms.
> The TCPM WG serves several purposes:
>
> * The WG mostly focuses on maintenance issues (e.g., bug fixes) and
> modest changes to the protocol, algorithms, and interfaces that
> maintain TCP's utility.
>
> * The WG is a venue for moving current TCP specifications along the
> standards track (as community energy is available for such efforts).
>
> 
> * The WG maintains Multipath TCP (MPTCP) and is a home for minor
> MPTCP enhancements including updates to the existing multipath
> congestion control.
> 
I think this seems appropriate. (Deciding on new work will require the 
same judgement as other protocol work for non-TCP transports and so the 
new Charter text works for me.)
> * The focus of the working group is TCP. In cases where small
> changes are directly applicable to other transports (e.g., SCTP or
> DCCP), the mappings to other transports may be specified alongside
> that for TCP, but other significant additions and changes to other
> transports are not in scope.
>
> TCPM also provides a venue for standardization of incremental
> enhancements of TCP's standard congestion control. In addition,
> TCPM may document alternative TCP congestion control algorithms
> that are known to be widely deployed, and that are considered
> safe for large-scale deployment in the Internet. Changes of algorithms
> may require additional review by the IRTF Congestion Control
> Research Group (ICCRG). Fundamental changes to TCP or its congestion
> control algorithms (e.g., departure from loss-based congestion
> control) will be handled by other working groups or will require
> rechartering.
>
> TCP's congestion control algorithms are the model followed by
> alternate

[GF] can we change /alternate/ to /other IETF/ ... I always though that 
word was a slightly odd choice to me.

> transports (e.g., SCTP or DCCP), which are standardized in
> other working groups, such as the Transport Area WG (tsvwg). In the
> past, the IETF has worked on several documents about algorithms that
> are specified for multiple protocols (e.g., TCP and SCTP) in the
> same document. Which WG shepherds such documents will be determined
> on a case-by-case basis. In any case, the TCPM WG will remain in
> close contact with other relevant WGs working on these protocols to
> ensure openness and stringent review from all angles.
>
> New TCPM milestones that fall within the scope specified within the
> charter can be added after consensus on acceptance in the working
> group and approval by the responsible Area Director.
> 
>
> We do not plan any other changes to the TCPM charter, i.e., any MPTCP-related work would follow the process explained in the last sentence of the charter.
>
> Even if this is only one additional sentence, any re-chartering requires IESG approval. The current plan is to get IESG approval for the new TCPM charter prior to IETF 107. Obviously, the first step is to reach consensus inside TCPM.
>
> I add the MPTCP WG list in CC. Yet, any discussion of the TCPM charter should take place at tcpm@ietf.org.
>
> Please review the charter proposal, and please let us know any comments ASAP.
>
> Best regards
>
> Michael
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
Gorry


From nobody Wed Feb 26 02:12:42 2020
Return-Path: 
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 592223A121B; Wed, 26 Feb 2020 02:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.787
X-Spam-Level: 
X-Spam-Status: No, score=-0.787 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, RCVD_IN_RP_RNBL=1.31, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 9BG1vezBc_hs; Wed, 26 Feb 2020 02:12:36 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7421B3A1219; Wed, 26 Feb 2020 02:12:36 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 9EC2D25A18; Wed, 26 Feb 2020 11:12:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1582711954; bh=EEASRGXYiGdgYzDQQLLe6q707wyJnQmn4llwbE1Rjjc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Apb36tjzFyyFlLTZrxRMNmDab0om8nuXQQfXgQEFczB7itAFP9R62xzC+LOaPsmu6 fbBUlWrQFuLhDwOGnpr6MrNeK9MuJEHlZhJjqViX2ZS8wbUBFbJ/SQbq7rtZLgdGNX lbmrUTT2IYTdyzzGJpUWz2/eBAWQK6BDiLZD5c+s=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbQexD8BT1gI; Wed, 26 Feb 2020 11:12:34 +0100 (CET)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 26 Feb 2020 11:12:34 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.209]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Wed, 26 Feb 2020 11:12:33 +0100
From: "Scharf, Michael" 
To: Gorry Fairhurst , tcpm IETF list 
CC: "tcpm-chairs@ietf.org" 
Thread-Topic: [tcpm] TCPM rechartering to add MPTCP maintenance
Thread-Index: AdXsfiYbdxTCvkRaSHGznmUWO5g9GQAAgT4AAAMlG+A=
Date: Wed, 26 Feb 2020 10:12:33 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D99CFFB@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D99CD22@rznt8114.rznt.rzdir.fht-esslingen.de> <540ca6c0-3a72-2ca1-e9fa-e914ad1ee259@erg.abdn.ac.uk>
In-Reply-To: <540ca6c0-3a72-2ca1-e9fa-e914ad1ee259@erg.abdn.ac.uk>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] TCPM rechartering to add MPTCP maintenance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2020 10:12:40 -0000

W3RjcG0gb25seV0NCg0KPiA+IFRDUCdzIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG1zIGFy
ZSB0aGUgbW9kZWwgZm9sbG93ZWQgYnkNCj4gPiBhbHRlcm5hdGUNCj4gDQo+IFtHRl0gY2FuIHdl
IGNoYW5nZSAvYWx0ZXJuYXRlLyB0byAvb3RoZXIgSUVURi8gLi4uIEkgYWx3YXlzIHRob3VnaCB0
aGF0DQo+IHdvcmQgd2FzIGEgc2xpZ2h0bHkgb2RkIGNob2ljZSB0byBtZS4NCg0KRm9yIHdoYXQg
aXQgaXMgd29ydGgsIGFjY29yZGluZyB0byBkYXRhdHJhY2tlciB0aGUgVENQTSBjaGFydGVyIGhh
cyB1c2VkIHRoZSB0ZXJtICJhbHRlcm5hdGUgdHJhbnNwb3J0cyIgYXQgbGVhc3Qgc2luY2UgMjAw
NC4uLiBBbnl3YXksIHllcywgSSBhZ3JlZSB0aGF0IHdlIGNvdWxkIHJlcGxhY2UgdGhhdCB3b3Jk
Lg0KDQo+ID4gdHJhbnNwb3J0cyAoZS5nLiwgU0NUUCBvciBEQ0NQKSwgd2hpY2ggYXJlIHN0YW5k
YXJkaXplZCBpbg0KPiA+IG90aGVyIHdvcmtpbmcgZ3JvdXBzLCBzdWNoIGFzIHRoZSBUcmFuc3Bv
cnQgQXJlYSBXRyAodHN2d2cpLiBJbiB0aGUNCj4gPiBwYXN0LCB0aGUgSUVURiBoYXMgd29ya2Vk
IG9uIHNldmVyYWwgZG9jdW1lbnRzIGFib3V0IGFsZ29yaXRobXMgdGhhdA0KPiA+IGFyZSBzcGVj
aWZpZWQgZm9yIG11bHRpcGxlIHByb3RvY29scyAoZS5nLiwgVENQIGFuZCBTQ1RQKSBpbiB0aGUN
Cj4gPiBzYW1lIGRvY3VtZW50LiBXaGljaCBXRyBzaGVwaGVyZHMgc3VjaCBkb2N1bWVudHMgd2ls
bCBiZSBkZXRlcm1pbmVkDQo+ID4gb24gYSBjYXNlLWJ5LWNhc2UgYmFzaXMuIEluIGFueSBjYXNl
LCB0aGUgVENQTSBXRyB3aWxsIHJlbWFpbiBpbg0KPiA+IGNsb3NlIGNvbnRhY3Qgd2l0aCBvdGhl
ciByZWxldmFudCBXR3Mgd29ya2luZyBvbiB0aGVzZSBwcm90b2NvbHMgdG8NCj4gPiBlbnN1cmUg
b3Blbm5lc3MgYW5kIHN0cmluZ2VudCByZXZpZXcgZnJvbSBhbGwgYW5nbGVzLg0KDQpNaWNoYWVs
DQo=


From nobody Wed Feb 26 10:21:05 2020
Return-Path: 
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 D233E3A1051 for ; Wed, 26 Feb 2020 10:21:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=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=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 YW9m-0JziqRk for ; Wed, 26 Feb 2020 10:20:59 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 57FD03A105A for ; Wed, 26 Feb 2020 10:20:59 -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:From:References:To:Subject:Sender: Reply-To:Cc: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=2NsExhSELxcb6u2Q59Ii/49OXCnf6LtXp/21NjbBRGE=; b=dRGmd2wDdQHOV8kCQvkSLB0tkx ECOXQ12fpbCsxq9dhINn/MHwIvOGyeHKpZk+osQYrfI6H2jtBJOa4umT/2sBHp0NVud+FmX+QW4Gd 8Xzufydbbb1jZPLxRWVau+M4ZD3hyUdrcMzEbvTLokmjd4dw5aOv+LR0ciSPlIZBi6aLsSAI7vOKZ 6QdarPdRk/yK2H9rUd1TdneCcNGUIcbM5h7hkTzH3xkJsYSXwF5as7c9P9Zmx9Qf/FZxQCw1fXXsR VrP+8fRxBVt+ZEkZBoL8G3OSRkT/KcU4fBDS67lcXoQynkTW8o2AtIX9yji3mCuJvDSJC0YniidZX mM2+oS8g==;
Received: from [31.185.128.125] (port=44006 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j71In-0006QC-5i; Wed, 26 Feb 2020 18:20:57 +0000
To: "Scheffenegger, Richard" , tcpm@ietf.org
References:  <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net>   <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net>  <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net>  <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net> <538AD737-107E-44D7-A305-7B99BEA9F0CE@kuehlewind.net> <21a45367-89fd-303b-f0e8-c51303de3760@bobbriscoe.net> <29AA3850-D1AA-4CED-BCAC-8F4C6A94A9C3@kuehlewind.net>  <1199c56d-720c-46a6-4b47-4393a9c1469a@gmx.at>
From: Bob Briscoe 
Message-ID: <2cc23b7f-01f6-c01d-06f8-9b57ce86145f@bobbriscoe.net>
Date: Wed, 26 Feb 2020 18:20:56 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <1199c56d-720c-46a6-4b47-4393a9c1469a@gmx.at>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] A possible simplification for AccECN servers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Feb 2020 18:21:02 -0000

Richard,

I'm responding to your email now, 'cos I'm just finalizing a rev of the 
AccECN draft. See inline...

On 12/12/2019 16:28, Scheffenegger, Richard wrote:
>
>
> Am 12.12.2019 um 15:53 schrieb Bob Briscoe:
>> You were saying we should just refer to RFC3168 in this case. I am
>> saying we should not refer to RFC3168 for the wire protocol aspect.
>> Rather we should specify the wire protocol part in the AccECN spec,
>> because we can specify more tightly than RFC3168 that only a 001 SYN/ACK
>> causes the client to fall back to classic ECN, whereas it would be an
>> X01 SYN/ACK if we referred to 3168.
>>
>> This was originally just a very minor disagreement about not referring
>> off to another spec, but it got detached from its original context by
>> the way the responses were posted.
>>
>> Here's suggested text. Changes from -09 are in green:
>>
>>     | AccECN | Nonce  | 1   1   1  | 1   0   1 
>> |(Reserved)              |
>>     | AccECN | ECN    | 1   1   1  | 0   0   1 | classic 
>> ECN            |
>>     | AccECN | No ECN | 1   1   1  | 0   0   0 | Not 
>> ECN                |
>>
>>
>>     2.  The second block shows the cases where the TCP client (A)
>>         supports AccECN but the TCP server (B) supports some earlier
>>         variant of TCP feedback, indicated in its SYN/ACK. Therefore, as
>>         soon as an AccECN-capable TCP client (A) receives the SYN/ACK
>>         shown it MUST set both its half connections into the feedback
>>         mode shown in the rightmost column.If it has set itself into 
>> classic ECN feedback mode it MUST then comply
>> with [RFC3168].
>>
>>
>> Note that I've referred to RFC3168 for the behaviour after the wire
>> protocol negotiation, but that's something I've been tightening up
>> separately from this conversation.
>>
>> Note that in the Nonce row, now that it's historic, I realized we
>> should've changed "classic ECN" to "(Reserved)", so as not to burn that
>> codepoint.
>
>
> A further comments here: Since Nonce is historic, should it even be
> mentioned as a possible server behavior at all, in this table?
[BB] All bit patterns are possible, whether or not there is a current 
RFC describing them. I always prefer to give a full truth table, to be 
clear what a machine does when it receives one of these bit patterns 
that might be used in the future.

Further, I think it's best to express this as in the snippet of table 2 
above, but also add to "Note 2" to say that the server response called 
'Nonce' in the table is now historic. I.e. the resulting mode is 
'Reserved', but the the pattern of bits from the server resembles that 
of the historic nonce behaviour.

>
> While the initial nonce sum was set to 1, and supposed to be included in
> the SYN,ACK, a mangling of IP ECN bits could conceivable have masked
> this (and a L4S sender, setting ECT1 on the SYN, would elicit the same
> SYN,ACK response from both a RFC3168 server, as well as a RFC3540 Nonce
> server...)
[BB] I don't think any of this is right. RFC3540 required the initial 
nonce sum to be 1. So NS on the SYN/ACK and 3rd ACK was always meant to 
be 1 (see end of S.5 in RFC3540).

At that time, the IP-ECN field of the SYN and SYN/ACK were meant to be 
Not-ECT, so no-one would even have thought of incrementing the nonce sum 
during the handshake, whether the IP-ECN field was different due to 
mangling, L4S or whatever.

>
> To be clear - I'd swap out the "Nonce" server to "Resrvd" or "Future"
> (or SCE :) )...
As above. Yes, 'Reserved' for the mode, but still 'Nonce' for host B, 
but add to the note to say "The server response called 'Nonce' in the 
table is now historic."



Bob
>
> Richard
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

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


From nobody Thu Feb 27 01:16:41 2020
Return-Path: 
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 ECF4C3A161D; Thu, 27 Feb 2020 01:16:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, 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=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 A4cS-1p1tJQC; Thu, 27 Feb 2020 01:16:38 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 23A193A161E; Thu, 27 Feb 2020 01:16:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding: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=tlpx5lznfdK1KXG9MO/+T7nHZErfTxEtVLF1ykuVFCA=; b=VxMnCifVULIAKwQ/dzmAZ5WFe eN4cy5YuCSZY/gu3r8RrikRABGoFc0xJiQjzQGqwMtE0g1rmx5RhoN79/zGYzJJRfebCng/dobx5O 47ABftx/GpjQwZk6daGZ4YMkRCVuEm5no2XldWorQovIQ6pFSbGKZfo+5+pI2BABKmcNL2bOMlwhi 8Lb5aOzzkLWwaGabwrJQVChpN3ifOJkaVkLgtpR4kuoE06CeKg1HT35qAXwNK/WVmGtVc3x15Eq04 HvuHRDepdPIVWQuR+7rvlW9XihdPbkRp8HUNsmzPTR8hCybpqSRnrDp4lb6N2rFBW1V8oOD4Jz3SC z91d6t5xg==;
Received: from [31.185.128.125] (port=45668 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j7FHX-0003nU-Vz; Thu, 27 Feb 2020 09:16:36 +0000
To: Yoshifumi Nishida , "tcpm@ietf.org Extensions" 
Cc: tcpm-chairs@ietf.org
References:  
From: Bob Briscoe 
Message-ID: <60ce5dd7-d5b7-0878-18da-ddcce48c9561@bobbriscoe.net>
Date: Thu, 27 Feb 2020 09:16:34 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------32BB910A9A35ADBB47106790"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] intended status of draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Feb 2020 09:16:40 -0000

This is a multi-part message in MIME format.
--------------32BB910A9A35ADBB47106790
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Yoshi, all,

I am preparing a revision (...-10) with all the recent queued up changes 
except those needed to change from EXP to PS. Then I shall follow that 
with a second revision (...-11) for the change from EXP to PS.

Reason: To enable implementers to separate out changes in the diffs 
resulting from IETF procedure.


Bob

On 24/01/2020 08:06, Yoshifumi Nishida wrote:
> Hi everyone,
>
> Sorry for taking long time. After several discussions among the 
> chairs, we've concluded the rough consensus of the WG is that this 
> document should target PS..
>
> As tcpm is a relatively small community, it's sometimes not easy to 
> assess the consensus in the group.
> However, as far as we've checked, most of people don't have issues on 
> publishing it as a PS doc.
>
> This will mean the updated version of this draft will require further 
> detailed reviews since the current version was written for an 
> experimental doc. This might take extra time compared to publishing an 
> EXP draft.
> In addition, there are possibilities that other ECN proposals will be 
> published in the future (and they can be PS as well). This draft 
> should be carefully reviewed not to prevent such activities.
>
> Thanks,
> --
> Yoshi on behalf of tcpm co-chairs
>
>
> On Fri, Dec 13, 2019 at 1:17 AM Yoshifumi Nishida  > wrote:
>
>     Hi folks,
>
>     We would like to get feedback for the intended status
>     of draft-ietf-tcpm-accurate-ecn.
>     The current intended status of this draft is experimental, but
>     we've seen some voices that PS is more preferable for the draft
>     during Singapore meeting and on the ML. So, we would like to check
>     the consensus on it.
>
>     There are some on-going related discussions such as flag
>     registration policy, SCE, ECN++, etc, however, we believe the
>     intended status discussions is independent from them and can
>     proceed it separately.. (If you have concerns on it, please share
>     your opinion here)
>
>     We appreciate your feedback.
>
>     Thanks,
>     --
>     Yoshi on behalf of tcpm co-chairs.
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

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


--------------32BB910A9A35ADBB47106790
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Yoshi, all,

    

    I am preparing a revision (...-10) with all the recent queued up
    changes except those needed to change from EXP to PS. Then I shall
    follow that with a second revision (...-11) for the change from EXP
    to PS.

    

    Reason: To enable implementers to separate out changes in the diffs
    resulting from IETF procedure.

    

    

    Bob

    

    
On 24/01/2020 08:06, Yoshifumi Nishida
      wrote:

    

    

      
      

        
Hi everyone,

        


        

        

          
Sorry for taking long time. After several discussions
            among the chairs, we've concluded the rough consensus of the
            WG is that this document should target PS..

          


          

          

            
As tcpm is a relatively small community, it's sometimes
              not easy to assess the consensus in the group.

            
However, as far as we've checked, most of people don't
              have issues on publishing it as a PS doc.

          

          


          

          
This will mean the updated version of this draft will
            require further detailed reviews since the current version
            was written for an experimental doc. This might take extra
            time compared to publishing an EXP draft.

          
In addition, there are possibilities that other ECN
            proposals will be published in the future (and they can be
            PS as well). This draft should be carefully reviewed not to
            prevent such activities.

          


          

          
Thanks,

          
--

          
Yoshi on behalf of tcpm co-chairs

        

        


        

        

        

          
On Fri, Dec 13, 2019 at 1:17
            AM Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:

          

          

            

              
Hi folks,

              


                

                  

                    
We would like to get feedback for the intended
                      status of draft-ietf-tcpm-accurate-ecn. 

                  

                

                
The current intended status of this draft is
                  experimental, but we've seen some voices that PS is
                  more preferable for the draft during Singapore meeting
                  and on the ML. So, we would like to check the
                  consensus on it.

                


                

                
There are some on-going related discussions such as
                  flag registration policy, SCE, ECN++, etc, however, we
                  believe the intended status discussions is independent
                  from them and can proceed it separately.. (If you have
                  concerns on it, please share your opinion here)

                


                

                
We appreciate your feedback.

                


                

                
Thanks,

                
--

                
Yoshi on behalf of tcpm co-chairs.

                


                

                


                

              

            

          

        

      

      

      

      
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


    

    

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

  


--------------32BB910A9A35ADBB47106790--


From nobody Fri Feb 28 06:23:36 2020
Return-Path: 
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 DB5053A18BA for ; Fri, 28 Feb 2020 06:23:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001,  URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi
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 odD4YJSGRScF for ; Fri, 28 Feb 2020 06:23:32 -0800 (PST)
Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FC13A18B3 for ; Fri, 28 Feb 2020 06:23:30 -0800 (PST)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Fri, 28 Feb 2020 16:23:06 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:message-id:mime-version:content-type; s=dkim20130528; bh=bVd/UXjHxpBxPp3yqfJjcANxpPUy7bzCKvrGGzScQ50=; b= HITMVvdyfYlc0Wkqn5fVxcCuicSnDgqMGHRXJmZdEqTH1ubHCVDBYYYcfffLeimi UhLp5XmfBXipTtYEZUtAT2ZoNAJnwcj7qYWRqmu7fJRUtvMUSC4/kyiNvoCjoBn+ txkKyVeRnr0TAT7+yBIl9m+WkDkcXrPd9hg/9Oj9grE=
Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Fri, 28 Feb 2020 16:23:06 +0200 id 000000000004011B.000000005E59224A.00006483
Date: Fri, 28 Feb 2020 16:23:06 +0200 (EET)
From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" 
X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi
To: tcpm@ietf.org
cc: Bob Briscoe , ietf@kuehlewind.net, Richard.Scheffenegger@netapp.com
Message-ID: 
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: 
Subject: [tcpm] AccECN option and "greedy" SACK option
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2020 14:23:34 -0000

Hi,

I'd propose this SACK condition is made less demanding:

     "If option space is limited on a particular ACK, the Data
      Receiver MUST give precedence to SACK information about loss. "

SACK is a "greedy" TCP option aiming to filling the entire TCP option 
space, it may block AccECN option through almost entire recovery. 
Typically the SACK blocks just repeat the same information over and over 
again.

I'd say at least two SACK blocks should be left which allows DSACK
to function and leaves some redundancy for ordinary SACKs. For 
implementations that limit AccECN option to only some of the segments,
the space is available for SACK in the meantime anyway.


-- 
 i.


From nobody Fri Feb 28 07:05:31 2020
Return-Path: 
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 106D43A1969; Fri, 28 Feb 2020 07:05:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tcpm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <158290232292.22340.2731216585912856112@ietfa.amsl.com>
Date: Fri, 28 Feb 2020 07:05:23 -0800
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-17.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2020 15:05:24 -0000

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           : 0-RTT TCP Convert Protocol
        Authors         : Olivier Bonaventure
                          Mohamed Boucadair
                          Sri Gundavelli
                          SungHoon Seo
                          Benjamin Hesmans
	Filename        : draft-ietf-tcpm-converters-17.txt
	Pages           : 53
	Date            : 2020-02-28

Abstract:
   This document specifies an application proxy, called Transport
   Converter, to assist the deployment of TCP extensions such as
   Multipath TCP.  A Transport Converter may provide conversion service
   for one or more TCP extensions.  The conversion service is provided
   by means of the TCP Convert Protocol (Convert).

   This protocol provides 0-RTT (Zero Round-Trip Time) conversion
   service since no extra delay is induced by the protocol compared to
   connections that are not proxied.  Also, the Convert Protocol does
   not require any encapsulation (no tunnels, whatsoever).

   This specification assumes an explicit model, where the Transport
   Converter is explicitly configured on hosts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-converters-17
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-17


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/



From nobody Fri Feb 28 08:34:53 2020
Return-Path: 
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 EEE4A3A0B0A for ; Fri, 28 Feb 2020 08:34:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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=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 xcVJ23JvqkVb for ; Fri, 28 Feb 2020 08:34:45 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 6B7843A0BA1 for ; Fri, 28 Feb 2020 08:34:40 -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:From:References:Cc:To: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=yq5gdhEmd+dPaJFqQ4jpkcZNEcHsdkg96eMzUQEwHME=; b=H5UfBdUKTu9P+KEKQv1esjVxp3 M8dzkbJIQf90tVyM9G0XAnrkjix4j5qFpiYY4u1j0bniD7ituOpnyWSQj6Mst0WdNoG8qvfGq0OKN jMZJTWJt9aGfuLt5JCMQJ03dupphe1sXaAaOiepG8K2MHjW/Gde2hxSYPVEa37wggPWjfZUUW59fN oHg9WINjB0f/1eZQry7fr0w3Y4bG5ZDPKAOtKspl2lFX/mKshBao5M6SAOhxvyYguV3vxn9xAdWOH wL26Aa/Dy8aZb+4BbBqxowlRi3uK3H4yT0xsnwb6au4eREDr2Vg4uBqa20IXi6/A3H7JwP0xiJEXa zUvpDm8Q==;
Received: from [31.185.128.125] (port=51914 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j7iaz-00039U-Ub; Fri, 28 Feb 2020 16:34:38 +0000
To: =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= , tcpm@ietf.org
Cc: ietf@kuehlewind.net, Richard.Scheffenegger@netapp.com
References: 
From: Bob Briscoe 
Message-ID: 
Date: Fri, 28 Feb 2020 16:34:36 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tcpm] AccECN option and "greedy" SACK option
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2020 16:34:50 -0000

Ilpo,

On 28/02/2020 14:23, Ilpo Järvinen wrote:
> Hi,
>
> I'd propose this SACK condition is made less demanding:
>
>       "If option space is limited on a particular ACK, the Data
>        Receiver MUST give precedence to SACK information about loss. "
>
> SACK is a "greedy" TCP option aiming to filling the entire TCP option
> space, it may block AccECN option through almost entire recovery.
> Typically the SACK blocks just repeat the same information over and over
> again.
>
> I'd say at least two SACK blocks should be left which allows DSACK
> to function and leaves some redundancy for ordinary SACKs. For
> implementations that limit AccECN option to only some of the segments,
> the space is available for SACK in the meantime anyway.
>
I agree that giving SACK unconditional precedence is unnecessarily 
draconian. How about changing the text to:

       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 10 octets), because loss
       feedback is more critical.

For the convenience of the list, the AccECN Option is not used on every 
packet, but if it is, it consists of 1,2 or 3 fields each of 3 octets 
plus the 2 octet kind and length. It's rarely essential to send all 3 
fields immediately, so 8 octets is the most likely total size that could 
be contending for option space.


Bob


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


From nobody Fri Feb 28 14:35:37 2020
Return-Path: 
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 668763A1F4E; Fri, 28 Feb 2020 14:34:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: tcpm@ietf.org, ietf@kuehlewind.net
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158292929840.19931.7210473510009466762@ietfa.amsl.com>
Date: Fri, 28 Feb 2020 14:34:58 -0800
Archived-At: 
Subject: [tcpm] tcpm - Requested session has been scheduled for IETF 107
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Feb 2020 22:35:06 -0000

Dear Yoshifumi Nishida,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


    tcpm Session 1 (2:00 requested)
    Monday, 23 March 2020, Morning Session I 1000-1200
    Room Name: Regency E size: 150
    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/107/sessions/tcpm.ics

Request Information:


---------------------------------------------------------
Working Group Name: TCP Maintenance and Minor Extensions
Area Name: Transport Area
Session Requester: Yoshifumi Nishida

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 60
Conflicts to Avoid: 
 Chair Conflict: mptcp
 Technology Overlap: tsvwg quic taps tsvarea iccrg panrg maprg



People who must be present:
  Yoshifumi Nishida
  Michael Tuexen
  Michael Scharf
  Mirja Kuehlewind

Resources Requested:

Special Requests:
  If possible, please allocate the meeting during Monday-Wednesday. (Monday or  Tuesday would be more preferable)
---------------------------------------------------------



From nobody Fri Feb 28 20:54:29 2020
Return-Path: 
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A283A0774; Fri, 28 Feb 2020 20:54:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tcpm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <158295206775.19833.5259326161038162793@ietfa.amsl.com>
Date: Fri, 28 Feb 2020 20:54:27 -0800
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-02.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Feb 2020 04:54:28 -0000

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           : TCP Control Block Interdependence
        Authors         : Joe Touch
                          Michael Welzl
                          Safiqul Islam
	Filename        : draft-ietf-tcpm-2140bis-02.txt
	Pages           : 32
	Date            : 2020-02-28

Abstract:
   This memo provides guidance to TCP implementers that are intended to
   help improve convergence to steady-state operation without affecting
   interoperability. It updates and replaces RFC 2140's description of
   interdependent TCP control blocks and the ways that part of TCP
   state can be shared among similar concurrent or consecutive
   connections. TCP state includes a combination of parameters, such as
   connection state, current round-trip time estimates, congestion
   control information, and process information. Most of this state is
   maintained on a per-connection basis in the TCP Control Block (TCB),
   but implementations can (and do) share certain TCB information
   across connections to the same host. Such sharing is intended to
   improve overall transient transport performance, while maintaining
   backward-compatibility with existing implementations. The sharing
   described herein is limited to only the TCB initialization and so
   has no effect on the long-term behavior of TCP after a connection
   has been established.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-02
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-2140bis-02


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/



From nobody Sat Feb 29 14:59:25 2020
Return-Path: 
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 18A4C3A1541; Sat, 29 Feb 2020 14:59:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.101
X-Spam-Level: ***
X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 6M29vsHtTSCg; Sat, 29 Feb 2020 14:59:15 -0800 (PST)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 CDDCB3A1540; Sat, 29 Feb 2020 14:59:14 -0800 (PST)
Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1j8B4g-0002j0-1f; Sat, 29 Feb 2020 23:59:10 +0100
Received: from ti0182q160-5615.bb.online.no ([84.202.72.50] helo=[10.0.0.12]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1j8B4d-0005Wn-Gp; Sat, 29 Feb 2020 23:59:09 +0100
From: Michael Welzl 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_0BA85062-2DC1-40F8-8328-8941374D4110"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sat, 29 Feb 2020 23:59:05 +0100
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D8FD745@rznt8114.rznt.rzdir.fht-esslingen.de>
Cc: "draft-ietf-tcpm-2140bis@ietf.org" , tcpm IETF list 
To: "Scharf, Michael" 
References: <6EC6417807D9754DA64F3087E2E2E03E2D8FD745@rznt8114.rznt.rzdir.fht-esslingen.de>
X-Mailer: Apple Mail (2.3445.104.11)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 84.202.72.50 is neither permitted nor denied by domain of ifi.uio.no) client-ip=84.202.72.50;  envelope-from=michawe@ifi.uio.no; helo=[10.0.0.12]; 
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: EF88EFCCDF155F41A53EA2D1AA530F3FD864B837
Archived-At: 
Subject: Re: [tcpm] draft-ietf-tcpm-2140bis-01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Feb 2020 22:59:22 -0000

--Apple-Mail=_0BA85062-2DC1-40F8-8328-8941374D4110
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Michael,

We have now addressed your comments (please see below).

> Begin forwarded message:
>=20
> From: "Scharf, Michael" >
> Subject: draft-ietf-tcpm-2140bis-01
> Date: 30 January 2020 at 01:28:50 CET
> To: "draft-ietf-tcpm-2140bis@ietf.org =
" =
>, tcpm IETF list =
>
> Resent-From: >
> Resent-To: >, =
>, >
>=20
> Hi,
> =20
> I have read the most recent version of 2140bis. As usually, my =
comments are posted with chair hat off.
> =20
> I encourage others to also read the document.
> =20
> Issues / comments:
> =20
> The document structure follows in many cases exactly RFC 2140, even if =
content has changed. In some cases, this confuses me. For instance, the =
Section =E2=80=9EAn Ensample of Temporal Sharing=E2=80=9C in RFC 2140 =
indeed contained an implementation example. Section 6 of RFC 2140bis is =
generic. This raises at least two questions f=C3=BCr Section 6 and =
similarly for Section 7:
> Is the title for the section still appropriate?

Good catch, thanks! It isn't. Fixed it to "Temporal Sharing" (and =
"Ensemble Sharing" in case of Section 7).


> Is some additional explanation needed e.g. on page 6 that an =
implementation can decide to implement only subsets of the table on page =
6, as an early heads-up?

We don't make a recommendations for implementers but just present the =
possibilities with their pro's and con's; hence the text points at =
sections 8 and 9 for compatibility issues and implications of sharing =
the information. Thus, we believe that's the most appropriate type of =
"early heads-up".


> Sections 6, 7, 8, 9 and 10 are longer than the original 2140. I wonder =
if subsections would be useful to better structure them. At least I find =
some of the long text blocks hard to read and it is not always apparent =
how a given paragraph fits into the overall storyline. I suspect that =
the document would be easier to parse with some more structuring (e.g., =
subsections).

We inserted sub-headings in Sections 6, 7, 8 and 9. This was great =
advice indeed! This should be much clearer now, especially sections 6 =
and 7.


> The internal structure of Section 8 is hard to understand. For =
instance, ECMP and LAG are discussed twice. Also, this section discusses =
quite a number of different aspects, including fairness, challenges with =
ECMP/LAG, interactions with fast recovery and NAT. I suggest to either =
add early an explanation what is meant by =E2=80=9Ecompatibility=E2=80=9C,=
 or to use sub-sections to make clear what topics are in scope (see =
above).

We have re-organized the text here a bit, removing a redundant statement =
about ECMP and LAG, and inserted sub-headings in Section 8.


> The separation of topics between Section 8 and 9 is not fully clear to =
me (different to RFC 2140 =E2=80=93 prior to deployment these sections =
had a relatively clear meaning). For instance, both sections discuss =
traffic with possibly short flows (e.g., http). I think the existing =
content could be reorganized by copy&paste in sections with a =
well-defined focus. Example section titles could be:
> Fairness issues
> Impact on applications and performance
> Interactions with network mechanism
> Discussion of design aspects and alternatives
> =E2=80=A6 (or other terms =E2=80=93 I just post this list to =
illustrate that alternatives could exist)


8 are issues local to the TCB sharing function; 9 are interactions with =
other architecture and protocol issues. Although the sum of the two =
sections could be completely revised, we don't currently see a benefit.


> The table on page 15 is a bit dated. I hope that we could update that, =
say, during a WGLC

We believe that the best approach is to copy+paste this table into an =
email and send it to the mailing list for checking. We'll do this.


> Section 12: I am not sure if I fully understand the attack vectors =
section. For instance, how would an attack like =E2=80=9Ean application =
can open a connection and set its window size to zero, denying service =
to any other subsequent connection between those hosts.=E2=80=9C work if =
the receive window is not shared?

We agree, this was wrong; we removed this line.


> In addition, I wonder if privacy needs to be discussed, e.g., whether =
user tracking or fingerprinting is possible by the methods discussed in =
the document.

Added a paragraph to the security section addressing this. We believe =
the mixing mitigates the effect of reuse.


> Section 14: I would classify more references as =E2=80=9Enormative=E2=80=
=9C (e.g., RFC 793)

Done (RFC 793, 1122, the PMTUD RFCs and the TFO RFC)


> Appendix C.3: I really wonder why not to specify the algorithm with =
(optional) persistence across reboots

Because it's the same as temporal sharing, just with different averaging =
and information decay.


> =20
> Editorial nits:
> =20
> Please ensure that capitalization of all headlines is consistent =
(e.g., title of Apendix A)

Done


> Same for all table captions (e.g., caption =E2=80=9EOption info=E2=80=9C=
)

Done.


> Section 2: I am not sure about this wording: s/permitted by TCP =
implementers/permitted by TCP standards/ ???

Done (replaced as you suggest).


> In the table on Section 5, =E2=80=9Eround-trip time and variance=E2=80=9C=
 appears twice, is this a bug or a feature? (Same as in RFC 2140)

It's a bug. Removed.


> Page 7 refers to Appendix B. If that appendix shall indeed be removed =
prior to publication, that reference also needs to be removed. Maybe =
that sentence should be flagged for removal, too?!

Done.


> On page 7 and 8, I believe that the position of the tables could be =
rearranged so that they are not rendered back-to-back. Both tables seem =
partly unrelated and the current position may be a bit confusing. Same =
issue later on page 10. (Alternatively, the tables could be numbered to =
make clear that they are separate.)

Fixed: the tables are now clearer due to the new subheadings.


> On page 8, the order of the entries in the table and the order of =
their explanation is not well aligned. This may be a matter of personal =
taste, but I would expect a somewhat similar order.

Fixed.


> Page 8/9: =E2=80=9EThe method for merging old and current values needs =
to attempt to reduce the transient for new connections.=E2=80=9C I am =
not sure if I fully understand what is meant by this (albeit I suspect a =
certain meaning).

Clarified.


> Page 9: The table in the upper part of the page is not explained. I =
think it would make sense to have at least one sentence to introduce it.

This is fixed by the newly introduced subheadings which clarify that =
some tables are for initialization and some for cache updates.


> Page 11: The position of the table confuses me.

Fixed.


Best Regards,
Joe, Michael and Safiqul=

--Apple-Mail=_0BA85062-2DC1-40F8-8328-8941374D4110
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Michael,

We have now =
addressed your comments (please see below).

Begin forwarded message:

From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
Subject: draft-ietf-tcpm-2140bis-01
Date: 30 January 2020 at 01:28:50 CET
To: "draft-ietf-tcpm-2140bis@ietf.org" <draft-ietf-tcpm-2140bis@ietf.org>, tcpm IETF list =
<tcpm@ietf.org>
Resent-From: <alias-bounces@ietf.org>
Resent-To: <touch@strayalpha.com>, <michawe@ifi.uio.no>, =
<safiquli@ifi.uio.no>

Hi,
 
I have read the most recent version =
of 2140bis. As usually, my comments are posted with chair hat =
off.
 
I =
encourage others to also read the document.
 
Issues / comments:
 
  • The document structure follows =
in many cases exactly RFC 2140, even if content has changed. In some =
cases, this confuses me. For instance, the Section =E2=80=9EAn Ensample =
of Temporal Sharing=E2=80=9C in RFC 2140 indeed contained an =
implementation example. Section 6 of RFC 2140bis is generic. This raises =
at least two questions f=C3=BCr Section 6 and similarly for Section =
7:
  1. Is the title for the section still =
appropriate?

Good catch, thanks! It isn't. Fixed it =
to "Temporal Sharing" (and "Ensemble Sharing" in case of Section =
7).


  1. Is some additional =
explanation needed e.g. on page 6 that an implementation can decide to =
implement only subsets of the table on page 6, as an early =
heads-up?

We don't make a =
recommendations for implementers but just present the possibilities with =
their pro's and con's; hence the text points at sections 8 and 9 for =
compatibility issues and implications of sharing the information. Thus, =
we believe that's the most appropriate type of "early =
heads-up".


  • Sections 6, 7, 8, 9 and 10 are =
longer than the original 2140. I wonder if subsections would be useful =
to better structure them. At least I find some of the long text blocks =
hard to read and it is not always apparent how a given paragraph fits =
into the overall storyline. I suspect that the document would be easier =
to parse with some more structuring (e.g., =
subsections).

We inserted sub-headings in Sections 6, =
7, 8 and 9. This was great advice indeed! This should be much clearer =
now, especially sections 6 and 7.


  • The internal =
structure of Section 8 is hard to understand. For instance, ECMP and LAG =
are discussed twice. Also, this section discusses quite a number of =
different aspects, including fairness, challenges with ECMP/LAG, =
interactions with fast recovery and NAT. I suggest to either add early =
an explanation what is meant by =E2=80=9Ecompatibility=E2=80=9C, or to =
use sub-sections to make clear what topics are in scope (see =
above).

We have re-organized the text here a =
bit, removing a redundant statement about ECMP and LAG, and inserted =
sub-headings in Section 8.


  • The separation of topics =
between Section 8 and 9 is not fully clear to me (different to RFC 2140 =
=E2=80=93 prior to deployment these sections had a relatively clear =
meaning). For instance, both sections discuss traffic with possibly =
short flows (e.g., http). I think the existing content could be =
reorganized by copy&paste in sections with a well-defined focus. =
Example section titles could be:
    • Fairness issues
    • Impact on applications and =
performance
    • Interactions with =
network mechanism
    • Discussion of design aspects and =
alternatives
    • =E2=80=A6 (or other terms =E2=80=93 I just =
post this list to illustrate that alternatives could =
exist)


8 =
are issues local to the TCB sharing function; 9 are interactions with =
other architecture and protocol issues. Although the sum of the two =
sections could be completely revised, we don't currently see a =
benefit.


  • The table on page 15 is a bit =
dated. I hope that we could update that, say, during a =
WGLC

We believe that the best approach is to =
copy+paste this table into an email and send it to the mailing list for =
checking. We'll do this.


  • Section 12: I am not sure if I =
fully understand the attack vectors section. For instance, how would an =
attack like =E2=80=9Ean application can open a connection and set its =
window size to zero, denying service to any other subsequent connection =
between those hosts.=E2=80=9C work if the receive window is not =
shared?

We agree, this was wrong; we removed =
this line.


  • In addition, I wonder if =
privacy needs to be discussed, e.g., whether user tracking or =
fingerprinting is possible by the methods discussed in the =
document.

Added a paragraph to =
the security section addressing this. We believe the mixing mitigates =
the effect of reuse.


  • Section 14: I would classify more references as =
=E2=80=9Enormative=E2=80=9C (e.g., RFC =
793)

Done (RFC 793, 1122, the PMTUD RFCs and =
the TFO RFC)


  • Appendix C.3: I really wonder =
why not to specify the algorithm with (optional) persistence across =
reboots

Because it's the same as temporal =
sharing, just with different averaging and information decay.


 
Editorial =
nits:
 
  • Please ensure that =
capitalization of all headlines is consistent (e.g., title of Apendix =
A)

Done


  • Same for all table =
captions (e.g., caption =E2=80=9EOption =
info=E2=80=9C)

Done.


  • Section 2: I am not =
sure about this wording: s/permitted by TCP implementers/permitted by =
TCP standards/ ???

Done (replaced as you =
suggest).


  • In the table on Section 5, =
=E2=80=9Eround-trip time and variance=E2=80=9C appears twice, is this a =
bug or a feature? (Same as in RFC =
2140)

It's a bug. Removed.


  • Page 7 =
refers to Appendix B. If that appendix shall indeed be removed prior to =
publication, that reference also needs to be removed. Maybe that =
sentence should be flagged for removal, =
too?!

Done.


  • On page 7 and 8, I =
believe that the position of the tables could be rearranged so that they =
are not rendered back-to-back. Both tables seem partly unrelated and the =
current position may be a bit confusing. Same issue later on page 10. =
(Alternatively, the tables could be numbered to make clear that they are =
separate.)

Fixed: the tables are now clearer due =
to the new subheadings.


  • On page 8, the order of the =
entries in the table and the order of their explanation is not well =
aligned. This may be a matter of personal taste, but I would expect a =
somewhat similar order.

Fixed.


  • Page 8/9: =
=E2=80=9EThe method for merging old and current values needs to attempt =
to reduce the transient for new connections.=E2=80=9C I am not sure if I =
fully understand what is meant by this (albeit I suspect a certain =
meaning).

Clarified.


  • Page 9: The table in the upper =
part of the page is not explained. I think it would make sense to have =
at least one sentence to introduce =
it.

This is fixed by the newly introduced =
subheadings which clarify that some tables are for initialization and =
some for cache updates.


  • Page 11: The position of the =
table confuses me.

Fixed.


Best Regards,
Joe, Michael and =
Safiqul
=

--Apple-Mail=_0BA85062-2DC1-40F8-8328-8941374D4110--