From nobody Sun Aug 2 18:10: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 0A00B3A0E8B for ; Sun, 2 Aug 2020 18:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 pA0HXVV4xZkz for ; Sun, 2 Aug 2020 18:09:57 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 76C823A0E89 for ; Sun, 2 Aug 2020 18:09:57 -0700 (PDT) Received: from lhreml722-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 912213775DF7B5FA6BD7 for ; Mon, 3 Aug 2020 02:09:54 +0100 (IST) Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 3 Aug 2020 02:09:54 +0100 Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 3 Aug 2020 02:09:53 +0100 Received: from DGGEMM534-MBS.china.huawei.com ([169.254.7.65]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0487.000; Mon, 3 Aug 2020 09:09:45 +0800 From: Kangjiao To: Christoph Paasch CC: Olivier Bonaventure , "tcpm@ietf.org Extensions" , Liangqiandeng Thread-Topic: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 Thread-Index: AQHWXb+HJHOpbU0oSkKL2jMMYvRPV6kP1fbAgAHYVoCAAryHoP//kUKAgACdjyCAACNOAIABi44AgAImzSCAAr1cAIAKe00Q Date: Mon, 3 Aug 2020 01:09:45 +0000 Message-ID: <719A2C1D4AC73847B6E1BF21DF1545EAE5CB1629@dggemm534-mbs.china.huawei.com> References: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9A9BC@dggemm534-mbs.china.huawei.com> <213AD4B1-4F88-4389-93CE-242916C06DC8@apple.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5C9AA60@dggemm534-mbs.china.huawei.com> <20200723144058.GQ73500@MacBook-Pro-64.local> <719A2C1D4AC73847B6E1BF21DF1545EAE5C9DC89@dggemm534-mbs.china.huawei.com> <20200727165822.GB73500@MacBook-Pro-64.local> In-Reply-To: <20200727165822.GB73500@MacBook-Pro-64.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.102.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 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, 03 Aug 2020 01:09:59 -0000 Hello Christoph, Currently we have no pseudo-code example for you. We are planning to implem= ent and test it in our system but I cannot promise the timeline for this de= velopment because of some undetermined factors. Before that, I think we can discuss and clarify all related use cases/requi= rements to it for further solution and protocol design. >From our side, adjusting the weights and preferences on the subflows may be= not enough to ensure that all traffic is transmitted along the specified n= etwork interface as the analysis in previous mails. Sincerely, Jiao -----Original Message----- From: Christoph Paasch [mailto:cpaasch@apple.com]=20 Sent: Tuesday, July 28, 2020 12:58 AM To: Kangjiao Cc: Olivier Bonaventure ; tcpm@ietf.org E= xtensions ; Liangqiandeng Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by= -server-00 On 07/25/20 - 15:18, Kangjiao wrote: > The scenarios in this draft are not for traffic handover when=20 > encountering network failure. It is applied when one peer has an=20 > explicit plan on traffic switching. For example, for network migration=20 > or expansion on server, operator wants to adjust the traffic on these net= works in advance. > This is an actual case. >=20 > We think packet scheduler knows on which subflow the next packet will=20 > be sent. > So it may be a good choice to deploy the logic of accurate traffic=20 > switching on this component. I would love to understand more on how one would implement such kind of a l= ogic. Do you have a pseudo-code example? I have a hard time imagining how t= he scheduling estimates the amount of traffic it would have sent on subflow= A and rather sends it on subflow B, because to drive this decision-making = it needs an estimate of RTT, congestion-window,... of subflow A which it on= ly can get by actually scheduling traffic on A. While at a macro-level an operator can do its traffic-engineering and decid= e what proportion of traffic should be sent on one vs the other path, I don= 't see how this translates into the same method at the micro-level where sc= heduling happens on a packet-by-packet basis and is hugely driven by conges= tion-control and RTT. Thus, to achieve such traffic-engineering for the operator it looks to me l= ike it translates rather to adjusting the weights and preferences on the su= bflows. Thanks, Christoph >=20 > Sincerely, > Jiao >=20 > -----Original Message----- > From: Olivier Bonaventure [mailto:olivier.bonaventure@tessares.net] > Sent: Friday, July 24, 2020 10:17 PM > To: Christoph Paasch > Cc: Kangjiao ; tcpm@ietf.org Extensions=20 > ; Liangqiandeng > Subject: Re: [tcpm] comments on=20 > draft-kang-tcpm-accurate-data-scheduling-by-server-00 >=20 > Hello, >=20 >=20 > > > > > > From my perspective, I think following are two different requirements= : > > > > > > 1. Making all the traffic towards S2 (for this case, MP_PRIO may=20 > > > be > > > enough) > > > > > > 2. Making traffic only from to the destination=20 > > > IP_S2, which means diverting traffic that should be scheduled to=20 > > > to one subflow belonging to the target network=20 > > > interface (it is "on-demand scheduling", for this case, MP_PRIO is=20 > > > not enough) > > > > What is the use-case for such a scheme? >=20 > Understanding the requirements from the applications would really help in= this discussion. This could also serve as input for Multipath QUIC where t= he middlebox problems that are mentioned in the draft do not exist. >=20 > > I don't see how a multipath scheduler could assign the traffic that "wo= uld" > > have been sent to to a different subflow. Because for that=20 > > he would need to know what *would* have been sent on which=20 > > he can only know once he actually sends traffic on that subflow as=20 > > that will be driving the congestion-window which will allow to send mor= e (or less) traffic on . >=20 > Another point that needs to be taken into account is that when client=20 > moves, the network conditions change dynamically and the server view=20 > might differ from the wireless conditions on the client. In this case,=20 > it is difficult for the server to precisely decide where it wants to=20 > receive data. See http://multipath-tcp.org/multimob/ >=20 > Olivier >=20 > -- >=20 >=20 > Disclaimer: https://www.tessares.net/mail-disclaimer/ > >=20 >=20 From nobody Mon Aug 3 01:04:46 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 7EA263A0C62 for ; Mon, 3 Aug 2020 01:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 dZwj7Crfn52M for ; Mon, 3 Aug 2020 01:04:44 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 664C23A0C61 for ; Mon, 3 Aug 2020 01:04:44 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id c19so3266925wmd.1 for ; Mon, 03 Aug 2020 01:04:44 -0700 (PDT) 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=QM+DmgYOXVymzymMwcz+ajU3K6rtL67KqDGD7Yeo6cg=; b=pZIqqbbGuA3HOfvkykTfTC3toms4q5AByapV2hynsHx9kN5HFYYQr1RtAJJXJPbvEg azvDdhd5wiI04S0nrLXCWT35ZnYBp30WVKWiJPAPf/JMqUSV59xH7WIw7TsYnXnPUW+I yd5fxKTZeVqroK/VgB1URYfnEWWSs0pQbXYZhWgbthg/pGD6vxTb3LqA935U0274eIaZ yezf+Bwv2fga5vBTpVnrE8GQIQyeke5EtQMoRZAbvHZs/p+2D5MH+XZnJ5eDziRU2rlC P8UVeDJpqO57eKdzqPp4Yl9/56CmIavoR2gfIzflAsMW4rHPSt2sFzdX/mYay6TKSQFI JpKw== 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=QM+DmgYOXVymzymMwcz+ajU3K6rtL67KqDGD7Yeo6cg=; b=m0970DfZ2CGCGyb6CuFILAu0EP1z1bxdsIRxm7x6VvcWW0sGqeGglcUOOxeL2SCmWy YmNIAFq9KT/jw55DR1V96gj9bANlFTqAN4gTEYhJTgwXa5mjXq40yM41mn8mzdZi0kbW 9ceggBFyYe19/anD1pB+NwTNowDtshaPNj4S/eEaIL0eoSrkJCJwrDCjUJI0ID0yi+j6 SmuQouj5x5o5fCRpjfTfkNuImOUUfw5wZNb46GMXShrBzFTNN2WpWf1JZxvxlYoyoAqT ycW70HeAnhHV9Q265tKNsJkr3t/mHZaqSBIsmQkwnfnI+cb9/HSPiwInMhd5aPXjCnYP AOIQ== X-Gm-Message-State: AOAM533mvuqOgyMVi0Nftdd6xKTW6CBgDANKHxaoMhxgHfSFuVbAsIQ3 FFtNr/8YjpmDdM9BcUkT6YO0oFfA31E3V6SVhwQ7q9Py X-Google-Smtp-Source: ABdhPJxSH/yUhNs7mi/n3RYvcI0jdcEWqth8AJr9ZwO0Hk4LQL/ZBUKj1Nuceu0zFhdjD28oBFJHuYJ62UiraFRvHH4= X-Received: by 2002:a1c:7918:: with SMTP id l24mr14156120wme.132.1596441882684; Mon, 03 Aug 2020 01:04:42 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Mon, 3 Aug 2020 01:04:32 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000526f9f05abf4972e" Archived-At: Subject: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 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, 03 Aug 2020 08:04:45 -0000 --000000000000526f9f05abf4972e Content-Type: text/plain; charset="UTF-8" Hi, The chairs has been discussing how to proceed draft-scharf-tcpm-yang-tcp-06 after the WG meeting. The results of the hum were a bit weak to see clear consensus although there was slightly strong hum for adoption. Also, there seems to be some confusions during the adoption call. (I'm sorry for the clumsiness of using the tool) In order for this, we would like to seek the additional feedback from the community on the following points. 1: If you want to add your hum to the call because you didn't at the meeting for some reasons or if you want to change your hum, please let the chairs know. 2: if you hummed for not adopting the draft, please share your opinion. This will be a very helpful input for us. We'll appreciate your cooperation. Thanks, -- Yoshi --000000000000526f9f05abf4972e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The chairs has=C2=A0been discussing = how to proceed draft-scharf-tcpm-yang-tcp-06 after the WG meeting.
The results of the hum were a bit weak to see clear consensus although th= ere was slightly strong hum for adoption.=C2=A0
Also, there seems= to be some confusions during the adoption call. (I'm sorry for the clu= msiness of using the tool)
In order for this, we would like to se= ek the additional=C2=A0feedback from the community on the following points.=

1: If you want to add your hum to the call b= ecause you didn't at the meeting for some reasons or if you want to cha= nge your hum, please let the chairs know.
2: if you hummed for no= t adopting the=C2=A0draft, please share your opinion. This will be a very h= elpful input for us.=C2=A0

We'll appreci= ate your cooperation.
Thanks,
--
=
Yoshi
--000000000000526f9f05abf4972e-- From nobody Tue Aug 4 10:42:11 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 A2B5B3A0DE8; Tue, 4 Aug 2020 10:42:01 -0700 (PDT) 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: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Cc: tcpm-chairs@ietf.org, rfc-editor@rfc-editor.org, draft-ietf-tcpm-rto-consider@ietf.org, The IESG , Yoshifumi Nishida , tcpm@ietf.org, martin.h.duke@gmail.com, nsd.ietf@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159656292164.27511.10806317886949588389@ietfa.amsl.com> Date: Tue, 04 Aug 2020 10:42:01 -0700 Archived-At: Subject: [tcpm] Protocol Action: 'Requirements for Time-Based Loss Detection' to Best Current Practice (draft-ietf-tcpm-rto-consider-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: Tue, 04 Aug 2020 17:42:02 -0000 The IESG has approved the following document: - 'Requirements for Time-Based Loss Detection' (draft-ietf-tcpm-rto-consider-17.txt) as Best Current Practice This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Martin Duke and Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ Technical Summary This document provides high-level guidance to design last resort time-based loss detection schemes for general use on the Internet, which can be applied to not only TCP, but also other transport protocols and applications that need their own loss detection mechanisms. This Best Current Practice document describes generic principles to update existing loss detection algorithms or to develop new ones, which may be especially useful to non- specialist implementers of applications running directly over UDP or DTLS, which therefore require custom loss detection. Working Group Summary This draft has been around for 10 years, and is in tcpm for historical reasons. It has received significant review from both tsvwg and iccrg, where relevant expertise is present. There was also a WGLC in tsvwg. Document Quality This is not a protocol, but a series of design considerations. Standardized loss detection algorithms in TCP, SCTP, and QUIC are compliant with the requirements here and widely implemented. The described principles are uncontroversial in the transport community, and most WG description was focused on correct wording of those principles. Ethan Blanton, Sally Floyd, Jana Iyengar, Shawn Ostermann, and Vern Paxson provided particularly important contributions over the years. Personnel Yoshifumi Nishida is the document shepherd. Martin Duke is responsible Area Director. There are no IANA actions. From nobody Thu Aug 6 11:04:58 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 84A8C3A0D6D; Thu, 6 Aug 2020 11:04:56 -0700 (PDT) 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: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <159673709647.13922.11176551547193000805@ietfa.amsl.com> Date: Thu, 06 Aug 2020 11:04:56 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-18.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, 06 Aug 2020 18:04:57 -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 : Transmission Control Protocol Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-18.txt Pages : 106 Date : 2020-08-06 Abstract: This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122, and should be considered as a replacement for the portions of that document dealing with TCP requirements. It updates RFC 5961 due to a small clarification in reset handling while in the SYN-RECEIVED state. RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-18 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-18 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 Aug 6 11:07:51 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 555CF3A0D7D for ; Thu, 6 Aug 2020 11:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.949, 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=mti-systems-com.20150623.gappssmtp.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 SzDeYT8GFyrW for ; Thu, 6 Aug 2020 11:07:48 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 D100C3A0D7C for ; Thu, 6 Aug 2020 11:07:48 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id l64so38987318qkb.8 for ; Thu, 06 Aug 2020 11:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=+TtIAf+q067Q8Vzc6ed49+s8uEuEKEXYDO4rHYUV/5A=; b=RL1pbLhScd9EKAjIvuiM2+E6v7/vDkGW2PUDL9/WCTNaYFrLbUb+W7OlCRpl4JnO1f vv93uL3HqCaBNuhHzUKfOlajttJzjFVNNt3aaHmMCLix0zH7OyYONHgw5Y9kVU109/8m ukjl5/um4LYWD/cwDTH49rtUUNinq0FKHYUBpllvPxro8iUSP8jbYCNaNYCjIV53Qghy kh27/85WSfUQ+OckNFAnLLJx9UI5qKvoZmsByQ1a+AsR3eFKwUq/jE4zyDlUeVs1TJS5 Xuq8V8cvmDiIW9QsFI4V3RHs7gAWzeVcpGpc9LMTnWh1YCJNp1WcFnwrf0tdoMajLzX8 AaXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=+TtIAf+q067Q8Vzc6ed49+s8uEuEKEXYDO4rHYUV/5A=; b=CW80u6/cCPZIiBT9b2XsY/uVT2y9/RgaT2kC1WgfQsvzhUi9h/muxyf61Hip+ms6v0 VDXPzXQn6kCa6aKRQzk6fAL4SwZzpdJhnOOWMb8sfUjlyjj6bcyOvVsczuLfFECpbawn /mAD/cIJRz+hqhoLyUT78idssmlUFaSklx2sGxtbBASzjDLtj7oxlYX0A9XG2acOZ82h Bu0vWw+rbhoXvPxosn8Px50rfPJ/kzanOYM7ZgnpJ58xRJTDwg1td2cHd2VevlYluZ4z FadjSbR5ipJhu1yyaXLSzQa6LyjWjJVcFRUANUA74giygE7+17lVna7g526qTNJ+TJkB wEfg== X-Gm-Message-State: AOAM531e301M6bzNwsdCoipQTQx/Db9TAEz2L4lyNwKf9ob5HeejCyNR ziMJWOdfnxuXto376i0W89UILwr3X7kY9g== X-Google-Smtp-Source: ABdhPJw/fzwNs+oq8Z+0ruuKud8q5t5/ycNQ6dNrWcjL259ydHteOemYK9dbU18ikvM8yb995Jd6mw== X-Received: by 2002:a05:620a:1285:: with SMTP id w5mr9299205qki.21.1596737267633; Thu, 06 Aug 2020 11:07:47 -0700 (PDT) Received: from [192.168.1.6] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id x7sm4465546qkn.53.2020.08.06.11.07.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Aug 2020 11:07:46 -0700 (PDT) To: tcpm@ietf.org References: <159673709647.13922.11176551547193000805@ietfa.amsl.com> From: Wesley Eddy Message-ID: Date: Thu, 6 Aug 2020 14:07:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <159673709647.13922.11176551547193000805@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-18.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, 06 Aug 2020 18:07:50 -0000 This update basically just has a small update to use "Bit Offset" versus "Bit" (per Richard's comment in the IETF 108 virtual meeting) within the IANA considerations. On 8/6/2020 2:04 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. > > Title : Transmission Control Protocol Specification > Author : Wesley M. Eddy > Filename : draft-ietf-tcpm-rfc793bis-18.txt > Pages : 106 > Date : 2020-08-06 > > Abstract: > This document specifies the Internet's Transmission Control Protocol > (TCP). TCP is an important transport layer protocol in the Internet > stack, and has continuously evolved over decades of use and growth of > the Internet. Over this time, a number of changes have been made to > TCP as it was specified in RFC 793, though these have only been > documented in a piecemeal fashion. This document collects and brings > those changes together with the protocol specification from RFC 793. > This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429, > 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122, > and should be considered as a replacement for the portions of that > document dealing with TCP requirements. It updates RFC 5961 due to a > small clarification in reset handling while in the SYN-RECEIVED > state. > > RFC EDITOR NOTE: If approved for publication as an RFC, this should > be marked additionally as "STD: 7" and replace RFC 793 in that role. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-18 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-18 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-18 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Aug 7 13:58: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 0C2EC3A07E5 for ; Fri, 7 Aug 2020 13:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 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_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 GvLz_A8OEzAv for ; Fri, 7 Aug 2020 13:58:36 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 E1DEA3A0931 for ; Fri, 7 Aug 2020 13:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-Id:To:References:Subject:Date: Mime-Version:Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=R3THkPF5j/bt/rvhAaJpjUmbX6Otkj4/iSeQdWqdcAc=; b=qTHGqBO51vDJLDwhlKq8kUSO3z 99qCLF5UUTWeH2R2+Lzp2rOhbliRMzNsHiPtVO/pjI9xiYXRJ2mCqn2gfZM8CKYl43d+FhSZh4xGn XBwYAGzzoQrgmCGC+jd3EQY188s0gUh87pssQ5mOG0taSn1DYRA+PYCyH0UuvK0RwYqEYUhH2IuEo lE7XcfRYb8sPWbDnwxwxWNy0RB7GzS/OGNewScxi4jbSVEWKRF4Tv61uKxw44LLZATcVE4X7TiMV/ 5FtpBUKCmYVK28pNsBsNQE4NMNCPh5aItiPEMqs2htvH5Yc8GQipDJskeeY3wKaqXq0pzgI8JyxLN 4RLrS2Kw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50566 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k49RH-0000QG-Jl; Fri, 07 Aug 2020 16:58:12 -0400 From: Joseph Touch Content-Type: multipart/alternative; boundary="Apple-Mail=_2E5F048C-F4B9-425D-B779-FDD121EF6A25" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Fri, 7 Aug 2020 13:58:06 -0700 References: <159683377318.3227.14154558038766132242@ietfa.amsl.com> To: tcpm IETF list Message-Id: <86FB753B-5AD4-44C7-80BA-6BA373D59B66@strayalpha.com> X-Mailer: Apple Mail (2.3608.120.23.2.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: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-ao-test-vectors-01.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: Fri, 07 Aug 2020 20:58:39 -0000 --Apple-Mail=_2E5F048C-F4B9-425D-B779-FDD121EF6A25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Update posted with a correction to the derived keys and MACs, based on = an error detected during testing involving details described in the = update to Sec 9.2. Joe > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-touch-tcpm-ao-test-vectors-01.txt > Date: August 7, 2020 at 1:56:13 PM PDT > To: "Joseph Touch" , "Juhamatti Kuusisaari" = , "Joe Touch" >=20 >=20 > A new version of I-D, draft-touch-tcpm-ao-test-vectors-01.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. >=20 > Name: draft-touch-tcpm-ao-test-vectors > Revision: 01 > Title: TCP-AO Test Vectors > Document date: 2020-08-05 > Group: Individual Submission > Pages: 17 > URL: = https://www.ietf.org/internet-drafts/draft-touch-tcpm-ao-test-vectors-01.t= xt > Status: = https://datatracker.ietf.org/doc/draft-touch-tcpm-ao-test-vectors/ > Htmlized: = https://tools.ietf.org/html/draft-touch-tcpm-ao-test-vectors-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-touch-tcpm-ao-test-vectors > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tcpm-ao-test-vectors-01 >=20 > Abstract: > This document provides test vectors to validate implementations of > the two mandatory authentication algorithms specified for the TCP > Authentication Option over both IPv4 and IPv6. This includes > validation of the key derivation function (KDF) based on a set of > test connection parameters as well as validation of the message > authentication code (MAC). Vectors are provided for both currently > required pairs of KDF and MAC algorithms: one based on SHA-1 and the > other on AES-128. The vectors also validate both whole TCP segments > as well as segments whose options are excluded for NAT traversal. >=20 >=20 >=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 > The IETF Secretariat >=20 >=20 --Apple-Mail=_2E5F048C-F4B9-425D-B779-FDD121EF6A25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Update posted with a correction to the derived keys and MACs, = based on an error detected during testing involving details described in = the update to Sec 9.2.

Joe

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-touch-tcpm-ao-test-vectors-01.txt
Date: = August 7, 2020 at 1:56:13 PM = PDT
To: = "Joseph Touch" <touch@strayalpha.com>, "Juhamatti Kuusisaari" <jkuusisaari@infinera.com>, "Joe Touch" <touch@strayalpha.com>


A new version = of I-D, draft-touch-tcpm-ao-test-vectors-01.txt
has been = successfully submitted by Joe Touch and posted to the
IETF = repository.

Name: = draft-touch-tcpm-ao-test-vectors
Revision: 01
Title:= = TCP-AO Test Vectors
Document date: = 2020-08-05
Group: Individual Submission
Pages:= = 17
URL: =            https://www.ietf.org/internet-drafts/draft-touch-tcpm-ao-test-v= ectors-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-touch-tcpm-ao-test-vecto= rs/
Htmlized:       https://tools.ietf.org/html/draft-touch-tcpm-ao-test-vectors-01=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-tcpm-ao-test-= vectors
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tcpm-ao-test-ve= ctors-01

Abstract:
=   This document provides test vectors to validate = implementations of
  the two mandatory = authentication algorithms specified for the TCP
=   Authentication Option over both IPv4 and IPv6. This = includes
  validation of the key derivation = function (KDF) based on a set of
  test = connection parameters as well as validation of the message
=   authentication code (MAC). Vectors are provided for both = currently
  required pairs of KDF and MAC = algorithms: one based on SHA-1 and the
  other = on AES-128. The vectors also validate both whole TCP segments
  as well as segments whose options are excluded = for NAT traversal.




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.

The IETF = Secretariat



= --Apple-Mail=_2E5F048C-F4B9-425D-B779-FDD121EF6A25-- From nobody Mon Aug 10 02:37:34 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 D48CC3A149B; Mon, 10 Aug 2020 02:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 tP830_Qlzss8; Mon, 10 Aug 2020 02:37:24 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 901973A147B; Mon, 10 Aug 2020 02:37:19 -0700 (PDT) Received: from lhreml718-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A7D68CE4F510C173C1ED; Mon, 10 Aug 2020 10:37:17 +0100 (IST) Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 10 Aug 2020 10:37:17 +0100 Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 10 Aug 2020 10:37:17 +0100 Received: from DGGEMM514-MBX.china.huawei.com ([169.254.2.74]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0487.000; Mon, 10 Aug 2020 17:37:06 +0800 From: Kangjiao To: "tcpm@ietf.org Extensions" CC: "multipathtcp@ietf.org" , Liangqiandeng Thread-Topic: [tcpm] FW: New Version Notification for draft-kang-tcpm-fault-management-in-mptcp-session-00.txt Thread-Index: AdZu+SKFoFRKtFs3Qja+TbLin4ztww== Date: Mon, 10 Aug 2020 09:37:06 +0000 Message-ID: <719A2C1D4AC73847B6E1BF21DF1545EAE5CC0FD4@dggemm514-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.102.89] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [tcpm] FW: New Version Notification for draft-kang-tcpm-fault-management-in-mptcp-session-00.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: Mon, 10 Aug 2020 09:37:33 -0000 RGVhciBhbGwsDQoNCldlIHVwbG9hZGVkIGEgZHJhZnQgdG8gcHJvcG9zZSBhIHNvbHV0aW9uIHRv IGNvbnZleSBzdWJmbG93IGZhaWx1cmUgaW5mb3JtYXRpb24gYmV0d2VlbiBjbGllbnQgYW5kIHNl cnZlciBkdXJpbmcgYSBNUFRDUCBzZXNzaW9uIC4gSXQgaXMgZGlmZmVyZW50IGZyb20gTVBfVENQ UlNUIGJlY2F1c2UgaXQgaXMgYXBwbGllZCBpbiB0aGUgY2FzZSBvZiBhYm5vcm1hbCB0ZXJtaW5h dGlvbiBvZiBvbmUgb25nb2luZyBzdWJmbG93LiANCg0KWW91ciBzdWdnZXN0aW9uIGFuZCBjb21t ZW50cyBhcmUgd2VsY29tZS4gDQoNClRoYW5rcw0KSmlhbw0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgQXVndXN0IDEwLCAyMDIwIDI6MTMgUE0N ClRvOiBLYW5namlhbyA8a2FuZ2ppYW9AaHVhd2VpLmNvbT47IExpYW5ncWlhbmRlbmcgPGxpYW5n cWlhbmRlbmdAaHVhd2VpLmNvbT47IExpYW5ncWlhbmRlbmcgPGxpYW5ncWlhbmRlbmdAaHVhd2Vp LmNvbT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQta2FuZy10 Y3BtLWZhdWx0LW1hbmFnZW1lbnQtaW4tbXB0Y3Atc2Vzc2lvbi0wMC50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQta2FuZy10Y3BtLWZhdWx0LW1hbmFnZW1lbnQtaW4tbXB0Y3At c2Vzc2lvbi0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmlhbyBL YW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWth bmctdGNwbS1mYXVsdC1tYW5hZ2VtZW50LWluLW1wdGNwLXNlc3Npb24NClJldmlzaW9uOgkwMA0K VGl0bGU6CQlGYXVsdCBNYW5hZ2VtZW50IE1lY2hhbmlzbSBpbiBNUFRDUCBTZXNzaW9uDQpEb2N1 bWVudCBkYXRlOgkyMDIwLTA4LTA5DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFn ZXM6CQk2DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWthbmctdGNwbS1mYXVsdC1tYW5hZ2VtZW50LWluLW1wdGNwLXNlc3Npb24tMDAu dHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQta2FuZy10Y3BtLWZhdWx0LW1hbmFnZW1lbnQtaW4tbXB0Y3Atc2Vzc2lvbi8NCkh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta2FuZy10Y3BtLWZhdWx0 LW1hbmFnZW1lbnQtaW4tbXB0Y3Atc2Vzc2lvbi0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQta2FuZy10Y3BtLWZhdWx0LW1hbmFn ZW1lbnQtaW4tbXB0Y3Atc2Vzc2lvbg0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBw cmVzZW50cyBhIG1lY2hhbmlzbSBmb3IgZmF1bHQgbWFuYWdlbWVudCBkdXJpbmcgYQ0KICAgTVBU Q1Agc2Vzc2lvbi4gIEl0IGlzIHVzZWQgdG8gY29udmV5IHN1YmZsb3cgZmFpbHVyZSBpbmZvcm1h dGlvbiBmcm9tDQogICBjbGllbnQgdG8gc2VydmVyIGJ5IG90aGVyIHN1YmZsb3cgcnVubmluZyBu b3JtYWxseS4gIEl0IGluY2x1ZGVzOiAxKQ0KICAgYSBuZXcgRmF1bHQgQW5ub3VuY2UgT3B0aW9u IGZvciBkZXNjcmliaW5nIHN1YmZsb3cgZmFpbHVyZSwgMikNCiAgIGltcGxlbWVudGF0aW9uIGFu ZCBpbnRlcm9wZXJhYmlsaXR5IG9mIHRoaXMgb3B0aW9uIGR1cmluZyBhIE1QVENQDQogICBzZXNz aW9uIHdoZW4gb25lIHN1YmZsb3cgc3VmZmVycyBhIGZhaWx1cmUuICBJbiBmYWN0LCB0aGUgc2Vy dmVyIGlzDQogICBhYmxlIHRvIGRldGVybWluZSBuZXR3b3JrIHByb2JsZW1zIGFjY3VyYXRlbHkg YmFzZWQgb24gdGhlc2UgZmF1bHQNCiAgIGluZm9ybWF0aW9uIHJlcG9ydGVkIGZyb20gbXVsdGlw bGUgY2xpZW50cyBmb3IgdGhlaXIgY29ubmVjdGlvbnMuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg0K From nobody Mon Aug 17 10:04: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 D3E753A1114 for ; Mon, 17 Aug 2020 10:04:00 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 0zoSqc0qXN19 for ; Mon, 17 Aug 2020 10:03:59 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 1A8513A1232 for ; Mon, 17 Aug 2020 10:03:58 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id t14so14496397wmi.3 for ; Mon, 17 Aug 2020 10:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9mIxSmZrDkap3oJLSMzC1NlZWUS6nsx69Bk12FaLy/A=; b=URwpNZeABmKyeEIu4ryEOp199j4tHq30SWffuct7N5aMQ1SpeqS5sJi6NOKufBtPnl B26m+uLssnuh/vIinrSZxrRItd198PbPllfE2LsvCORnr8UyfFcWZwAMOc3y++h//k3H XJndI6cKkhC4NFr7+nYG+NAcNqcn5QoAAHpG8cEwLWFBpfFF+JWK20/IBfj9gVATKoGk JxDjCRirROVVQYXdBZQJA5Kgo+oZ6LaF9tVd3YzmNJ2q9jBZKPpX/7EkhLQQ5Fpo0yrQ U3Bk6fFBtSVPwjKvub8kPhUzs1lpjhcy+2leXSBDr3UvmON/ax1918bycrPuakB5+w7M CdmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9mIxSmZrDkap3oJLSMzC1NlZWUS6nsx69Bk12FaLy/A=; b=nvgyXhKB9w3EGGEYNU/c9wMXdAw3SI4BzpHnG2/xnOUS2jILdDQwHKvdvBpHRKWxLe wrjBODb2A3BoPaHaDgHmww6bK/yqOvDo4f7iLR7HUtGDVVlI/b1QeY5JNbetKyrnpKm7 STXaK8Z+nGhI5R8FS5shJUuQ2OLyQH4uKXBYyePjrH12AFeNnf6YbNbJ1m4wdc/kxo/N 3RB4WOT/ITGrfPChTx00nBfow34zcZJBdZRBQimckgxgsaPl2SBeDXyMHGwjqfzG17YE fnPfBDkOQ5bZ+9hHzEr+fsc1IOeWxu21u7uE5iLsjgdwhaLxwWkZh1bQH23WSEuoy01q rulg== X-Gm-Message-State: AOAM532R/BSKM7MBQXfWlQ8hg4Y8VmhphcTvRkL2pVEe1eNRrNS1L7d9 a3OYLxinL2wWhJQ0x+eO/lXMNGyVzmLNxHfZLzxeqRCU X-Google-Smtp-Source: ABdhPJzRztdeR+fflHBnzaK7BvIZSiAL2GZVstr2XDmjjFMVJOiZOFUGyGdl+qBcaLsymSUfqa9b6lbQpc6mzGQpruE= X-Received: by 2002:a1c:7e12:: with SMTP id z18mr15121236wmc.188.1597683837262; Mon, 17 Aug 2020 10:03:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Mon, 17 Aug 2020 10:03:46 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000009635d505ad15c1c6" Archived-At: Subject: Re: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 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 Aug 2020 17:04:01 -0000 --0000000000009635d505ad15c1c6 Content-Type: text/plain; charset="UTF-8" Hi folks, We appreciate your feedback on this. -- tcpm co-chairs On Mon, Aug 3, 2020 at 1:04 AM Yoshifumi Nishida wrote: > Hi, > > The chairs has been discussing how to proceed > draft-scharf-tcpm-yang-tcp-06 after the WG meeting. > The results of the hum were a bit weak to see clear consensus although > there was slightly strong hum for adoption. > Also, there seems to be some confusions during the adoption call. (I'm > sorry for the clumsiness of using the tool) > In order for this, we would like to seek the additional feedback from the > community on the following points. > > 1: If you want to add your hum to the call because you didn't at the > meeting for some reasons or if you want to change your hum, please let the > chairs know. > 2: if you hummed for not adopting the draft, please share your opinion. > This will be a very helpful input for us. > > We'll appreciate your cooperation. > Thanks, > -- > Yoshi > --0000000000009635d505ad15c1c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,
We appreciate your feedback on th= is.
--
tcpm co-chairs

On Mon, Aug 3, 2020 at 1:04 AM Yos= hifumi Nishida <nsd.ietf@gmail.com= > wrote:
=
Hi,

The chairs has=C2=A0been discussing = how to proceed draft-scharf-tcpm-yang-tcp-06 after the WG meeting.
The results of the hum were a bit weak to see clear consensus although th= ere was slightly strong hum for adoption.=C2=A0
Also, there seems= to be some confusions during the adoption call. (I'm sorry for the clu= msiness of using the tool)
In order for this, we would like to se= ek the additional=C2=A0feedback from the community on the following points.=

1: If you want to add your hum to the call b= ecause you didn't at the meeting for some reasons or if you want to cha= nge your hum, please let the chairs know.
2: if you hummed for no= t adopting the=C2=A0draft, please share your opinion. This will be a very h= elpful input for us.=C2=A0

We'll appreci= ate your cooperation.
Thanks,
--
=
Yoshi
--0000000000009635d505ad15c1c6-- From nobody Tue Aug 18 01:32:45 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 CB1473A076F for ; Tue, 18 Aug 2020 01:32:43 -0700 (PDT) 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 (1024-bit key) header.d=eggert.org 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 9AePjlyx5qBk for ; Tue, 18 Aug 2020 01:32:42 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 8429D3A076C for ; Tue, 18 Aug 2020 01:32:42 -0700 (PDT) Received: from [IPv6:2a00:ac00:4000:400:2c31:68fb:d90c:71dc] (unknown [IPv6:2a00:ac00:4000:400:2c31:68fb:d90c:71dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id C9D9766818C; Tue, 18 Aug 2020 11:32:07 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1597739528; bh=TB1J/LutNdwzX37Sgc5FnyxypYKgj6Tbdpy2oJt4WhU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=aSeXzNbmd8LLbCZynVcDtdC7ssEKm0JLGmZQDKDYRDDyJ9wI9qH2QfWJ9WEv8dvGz 8bfxz/J6BnYp5El4jvmUEB/btwjuyJ6wZPTx9kMir9dIr3DxeqEJDO1Sb9lUCQyhRs K0dq6oSuDI3Bub258lAaVd+kcExqCSlt/RlWGDpA= From: Lars Eggert Message-Id: <36DD050C-4457-4151-ABF2-8C77685C4135@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_AB5EDB8B-B00C-4B99-959A-53F21AF2E1A7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 18 Aug 2020 11:32:05 +0300 In-Reply-To: Cc: "tcpm@ietf.org Extensions" To: Yoshifumi Nishida References: X-MailScanner-ID: C9D9766818C.A4E58 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 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 Aug 2020 08:32:44 -0000 --Apple-Mail=_AB5EDB8B-B00C-4B99-959A-53F21AF2E1A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2020-8-3, at 11:04, Yoshifumi Nishida wrote: > 2: if you hummed for not adopting the draft, please share your = opinion. This will be a very helpful input for us. I shared my opinion on this in the past, and it hasn't changed. Lars --Apple-Mail=_AB5EDB8B-B00C-4B99-959A-53F21AF2E1A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl87kgUACgkQVLXDCb9w wVe57RAAwQnMm3FEf89J0jIL4jEMo+qg1O6n4IlxfKwW872cTVn/jxTXBIv1lDa4 gBJWDGubiP58Nm8B1wZFizvyITEadVjlD6yr5wPAgZX46KOy5FY7fXaU2+XVY61M Tb+MlPcpL4j3LAf9NVMzX6CJcFHt7US87kFJppWzdZrnUlrfoCvZkzYjxXrChNIw G0y1e1hHrV6oiFJnAmq1lTFwegU/yJRGOl4b6x/fjD/TAEc/Cnxy/k83WQB4AJIS iQBc1RGVgH5JGIY9TQoahG8lkiEH0/cCfjM5tBfJrFRayi1jjxMCJ8XQ+Z3f25r3 anTEw01P4bzk8ovajRS/qMGXBk8dP0fc7QBig/BdciumiqUIcsbHcIzXY2U2U9kM O/0Oi6EFtas1OjbTymD/mYNScgBxPDiDjhcbqk1Likuj5QLF5Zq6bT2AX6mWp9nW th68Xw62cvX0v/tx6/Tn07Hy9pB8Xvz+949NQ7CCc1v1AqJqOvtjiZcfnoTtRyFj XsieAKNFMXJpUoEIkAvFHMZcu/T4OYiNR3r2k1EHUbTeYpwQ4SIRb53JHVn3fHyt qSqcVFMuwUNOsJS4A2lrVXC4m8Q0qqv0j2WwFRl8dafg132VQLF0UbYCRMGKIYxx DWERUROKYoyxiKpkYS8UVqvkphD3Hnh6jPxdzCX9qBOygdpO/cg= =EwzW -----END PGP SIGNATURE----- --Apple-Mail=_AB5EDB8B-B00C-4B99-959A-53F21AF2E1A7-- From nobody Tue Aug 18 06:42:56 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 C54283A0A50 for ; Tue, 18 Aug 2020 06:42:47 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 TS0kQBXcBCWm for ; Tue, 18 Aug 2020 06:42:45 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0DD3A0A52 for ; Tue, 18 Aug 2020 06:42:45 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 581561B000A6; Tue, 18 Aug 2020 14:42:41 +0100 (BST) To: Yuchung Cheng , tcpm IETF list References: From: Gorry Fairhurst Message-ID: <227bfb55-a2b4-37f0-9802-ddc76b22fa91@erg.abdn.ac.uk> Date: Tue, 18 Aug 2020 14:42:40 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: [tcpm] A review for draft-ietf-tcpm-rack-09 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 Aug 2020 13:42:55 -0000 I have read draft-ietf-tcpm-rack-09 in preparation for TCPM to publish this document, and do have some comments. I note that this new rev is much easier to read this time, so thanks for the significant work to produce a clear spec, and I see also that you have already addressed my major concerns - thanks. (I'll separately catch a set of minor editorial notes on this rev). (1) I don’t understand this clause: “  3.  The RACK reordering window SHOULD leverage that to adaptively estimate the duration of reordering events, if the receiver uses  Duplicate Selective Acknowledgement (DSACK) [RFC2883].” - What does “leverage that” actually mean? - Might it mean something like: can be increased if the sender receives a Duplicate Selective Acknowledgement (DSACK) [RFC2883], that suggests the window is too small, and has resulted in spurious retransmission." … or does it mean something different? (2) I did not understand this part in Section 3.3: “However, the fact that the initial reordering window is low, and the    reordering window's adaptive growth is bounded, means that there will    continue to be a cost to reordering to disincentivize excessive    network reordering over highly disjoint paths.  For such networks    there are good alternative solutions, such as MPTCP.“ - Is this intended to read as /reordering that disincentivizes excessive/ - If that was intended, the spec appears to be for a single path, MPTCP would still view this path with reordering as a single path, so I do not understand how MPTCP helps unless the awareness of the disjoint paths is somehow known at the endpoints? Please explain. - (You’d need a REF for MPTCP if you keep this senetnce and the explanation). (3)  Question in Section 7.4.2. /If the TLP    sender does not receive such an indication, then it SHOULD assume    that either the original data segment or the TLP retransmission were    lost, for congestion control purposes./ - Why is this not a MUST? - Under what conditions would it be safe to ignore a SHOULD? (4) in Section 6.2. I was also left with a potential concern about “min_RTT” with respect to “a simple global minimum of all RTT measurements from the connection”.  This method results in a significant path change from low to high RTT exhibiting an invalid RTT. Even a simple windowed min-filtered estimate - mentioned here - would avoid this effect on reordering detection. - I’d prefer adding a short sentence  so people know why the updates to min_RTT might be useful. (5) In section 8.1, I expected more discussion of the potential disadvantages (even if the authors seem to suggest these are not significant) : * I still was left without understanding whether there is an impact from a path with a varying RTT (perhaps one that uses a link layer retransmission or access technology). My feeling is that if there is excessive variation the method could go wrong when the RTT increases, but I wonder if this is usually captured by inflating the SRTT and that more excessive variation is not common. I think this case should be discussed briefly. * As I read it, RACK can also send more retransmissions after there has been loss, where it is making spurious retransmissions - from timer events, or as a result of multiple segments from a single TSO segment being retransmitted. While it seems to be argued these are not significant, it could none the less a disadvantage in some scenarios, and should be captured in section 8.1. * Also there seem cases where RACK allows TCP to continue to increase the congestion window upon receiving ACKs after loss, making the sender more aggressive. This is noted in 8.3, but I think should be listed in the disadvantages in 8.1. (6) Section 8.4 talks about ACK loss or a delayed ACK without a DSACK, but does not mention Stretch ACKs, which have also been experienced, and need some form of mention! (7) Why isn't TCP-NCR (RFC4653) at least mentioned and discussed in the intro? Gorry From nobody Tue Aug 18 06:45:01 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 7621D3A0A3D for ; Tue, 18 Aug 2020 06:45:00 -0700 (PDT) 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 JLtQKs2XwntG for ; Tue, 18 Aug 2020 06:44:58 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id EAC083A0A38 for ; Tue, 18 Aug 2020 06:44:57 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 47BA71B000A6; Tue, 18 Aug 2020 14:44:54 +0100 (BST) From: Gorry Fairhurst To: tcpm IETF list , "ycheng@google.com >> Yuchung Cheng" Message-ID: Date: Tue, 18 Aug 2020 14:44:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: [tcpm] Editorial comments for draft-ietf-tcpm-rack-09: 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 Aug 2020 13:45:01 -0000 I have previsously sent a few comments on draft-ietf-tcpm-rack-09  and this email contains only issues that I think are likely editorial, but I hope will help in prep of the next rev. Best wishes, Gorry --- “Heavy congestion or traffic policers can cause retransmissions to be lost again.” - I think this is probably clear, but it might be easier if it said: “Heavy congestion or traffic policers can cause the retransmitted packets to again be lost.” — “To mitigate the issue, [RFC4653] adjusts DupThresh to half of the inflight size to tolerate higher degree of reordering.” - Maybe should insert /the/ or /a/ before /higher/? — “and widely-deployed SACK options” - could you please insert a REF to relevant SACK RFCs. — “one alternative is to    dynamically adapt DupThresh based on the FlightSize (e.g. adjusts    DUPTRESH to half of the FlightSize).” - should the latter part be “(e.g., the sender adjusts the DUPTRESH to half of the FlightSize).” — “The RACK reordering window adapts to the measured duration of    reordering events, within reasonable and specific bounds in order to    disincentivize excessive reordering. “ - for the avoidance of possible misreading, could we remove /in order/, since this would still seem ti read correctly and prevent someone thinking about ordering issues. — In section 3.3.2. I see some sub-items numbered within a numbered list, which is confusing - could bullets be used for the two sub items.? The list also appears to resume with “1.” again - is this correct? — “The rationale is that spurious retransmissions for short flows are not expected to produce excessive network traffic additionally. “ - Does this read correctly? should it be /excessive additional network traffic/ — Figure 1 could benefit from a caption? — I wasn’t confused by: “For cases where the reordering degree is larger    than the default DupThresh of 3 packets” - but elsewhere the DupThresh is discussed in terms of segments! — /keeps a SACK scoreboard information/ - should this be: - /keeps SACK scoreboard information/ — Section 5 interchanges segments and packets, I was not confused. Maybe you could just add one sentence at the start that explains this? —— /before resetting RACK.reo_wnd/ - add a period at the end of the line. — /updates its states that tracks / - should be: /updates the states that track / - or /state/. — / Therefore, RACK    persists the inflated RACK.reo_wnd for only 16 loss recoveries/ - could be: / Therefore, RACK    persists using the inflated RACK.reo_wnd to recover up to 16 losses/ — /(e.g,/ should be /(e.g.,/ — /This segment is chosen in order to deal with the    retransmission ambiguity problem in TCP./ -  could we also remove /in order/, since this would still seem oi read correctly and prevent someone thinking about ordering issues. — /waits for the RACK reordering window expire,/ - insert /to/ before /expire/. — /just as it would    with any other ack/ - should this be /ACK/? — /MUST not be retransmitted until congestion control deems this appropriate./ - seems to be /MUST NOT/. --- /even if the congestion window is full./ - could this be: - /even if the congestion window is fully used./ --- 8.5 mentions Sprout - which to me seems a spurious and unecessary reference? However, I really think the WG should have mentioned the previously proposed reordering protection in TCP-NCR (RFC4653) From nobody Tue Aug 18 07:45:06 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 C46483A0B87 for ; Tue, 18 Aug 2020 07:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.212, SPF_HELO_NONE=0.001, SPF_NONE=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 XB3NkeEPErsb for ; Tue, 18 Aug 2020 07:45:02 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5D33A0B8B for ; Tue, 18 Aug 2020 07:45:02 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 07IEiqXu065474; Tue, 18 Aug 2020 07:44:52 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net) Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 07IEiqLm065473; Tue, 18 Aug 2020 07:44:52 -0700 (PDT) (envelope-from ietf) From: "Rodney W. Grimes" Message-Id: <202008181444.07IEiqLm065473@gndrsh.dnsmgr.net> In-Reply-To: To: Gorry Fairhurst Date: Tue, 18 Aug 2020 07:44:52 -0700 (PDT) CC: tcpm IETF list , "ycheng@google.com >> Yuchung Cheng" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] Editorial comments for draft-ietf-tcpm-rack-09: 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 Aug 2020 14:45:04 -0000 Gorry, draft authros, Sorry to respond to a response to a draft. One small comment inline marked [rwg] that I feel would even further clean up the language. Regards, Rod Grimes > I have previsously sent a few comments on draft-ietf-tcpm-rack-09? and > this email contains only issues that I think are likely editorial, but I > hope will help in prep of the next rev. > > Best wishes, > > Gorry > > --- > > ?Heavy congestion or traffic policers can cause retransmissions to be > lost again.? > - I think this is probably clear, but it might be easier if it said: > ?Heavy congestion or traffic policers can cause the retransmitted > packets to again be lost.? [rwg] To me the word "again" in either of these versions does not add any information as this information is implied by the fact the "retransmitted packets" are the subject of the sentence. Propose: "Heavy congestion or traffic policers can cause the retransmitted packets to be lost." > ? > ?To mitigate the issue, [RFC4653] adjusts DupThresh to half of the > inflight size to tolerate higher degree of reordering.? > - Maybe should insert /the/ or /a/ before /higher/? > ? > ?and widely-deployed SACK options? > - could you please insert a REF to relevant SACK RFCs. > ? > ?one alternative is to > ?? dynamically adapt DupThresh based on the FlightSize (e.g. adjusts > ?? DUPTRESH to half of the FlightSize).? > - should the latter part be ?(e.g., the sender adjusts the DUPTRESH to > half of the FlightSize).? > ? > ?The RACK reordering window adapts to the measured duration of > ?? reordering events, within reasonable and specific bounds in order to > ?? disincentivize excessive reordering. ? > - for the avoidance of possible misreading, could we remove /in order/, > since this would still seem ti read correctly and prevent someone > thinking about ordering issues. > ? > In section 3.3.2. I see some sub-items numbered within a numbered list, > which is confusing - could bullets be used for the two sub items.? The > list also appears to resume with ?1.? again - is this correct? > ? > ?The rationale is that spurious retransmissions for short flows are not > expected to produce excessive network traffic additionally. ? > - Does this read correctly? should it be /excessive additional network > traffic/ > ? > > Figure 1 could benefit from a caption? > ? > I wasn?t confused by: > ?For cases where the reordering degree is larger > ?? than the default DupThresh of 3 packets? > - but elsewhere the DupThresh is discussed in terms of segments! > ? > /keeps a SACK scoreboard information/ > - should this be: > - /keeps SACK scoreboard information/ > ? > Section 5 interchanges segments and packets, I was not confused. Maybe > you could just add one sentence at the start that explains this? > ?? > /before resetting RACK.reo_wnd/ > - add a period at the end of the line. > ? > /updates its states that tracks / > - should be: > /updates the states that track / > - or /state/. > ? > / Therefore, RACK > ?? persists the inflated RACK.reo_wnd for only 16 loss recoveries/ > - could be: / Therefore, RACK > ?? persists using the inflated RACK.reo_wnd to recover up to 16 losses/ > ? > > /(e.g,/ > should be > /(e.g.,/ > ? > /This segment is chosen in order to deal with the > ?? retransmission ambiguity problem in TCP./ > -? could we also remove /in order/, since this would still seem oi read > correctly and prevent someone thinking about ordering issues. > ? > /waits for the RACK reordering window expire,/ > - insert /to/ before /expire/. > ? > /just as it would > ?? with any other ack/ > - should this be /ACK/? > ? > /MUST not be retransmitted until congestion control deems this appropriate./ > - seems to be /MUST NOT/. > --- > > /even if the congestion window is full./ > - could this be: > - /even if the congestion window is fully used./ > --- > > 8.5 mentions Sprout - which to me seems a spurious and unecessary > reference? However, I really think the WG should have mentioned the > previously proposed reordering protection in TCP-NCR (RFC4653) > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > -- Rod Grimes rgrimes@freebsd.org From nobody Tue Aug 18 13:29:06 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 BE0B63A0BA0 for ; Tue, 18 Aug 2020 13:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.589 X-Spam-Level: X-Spam-Status: No, score=-17.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 306xCGpaRERV for ; Tue, 18 Aug 2020 13:29:02 -0700 (PDT) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 991043A0B9F for ; Tue, 18 Aug 2020 13:29:02 -0700 (PDT) Received: by mail-vk1-xa2f.google.com with SMTP id 186so4628361vkx.4 for ; Tue, 18 Aug 2020 13:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LqirUNnrjlyE88Jp2mKNbZ0VgqIS7pTXeuQG3ZpC3Bo=; b=rdDRKfBcIQ07V8xYbSi/akyssYINSetOZjCDwqQSMrNYrU8IfMheUfroVGVpPkF+LT HuI+GY7iLenkPBclgateBLPbWHkGYVpdmvuwM3WebX/q/kXQniHkUH/PMLD1hl3M7FaS c5ZuJuT+PzqOwF21Xj2tR0p0O5/G/9us4zCbocydNw47sgm8QEHkfsppxuciALALkikE 8qe78Mci69DHphL7WuRgsbRqBnJr8INSXCGGGO9ksvab0+urXS6hQSSYyALMeJDHaU8U TvOVRP3q4/5soIPERx275FfJp560stuO1NxA7mkElIt/eipTpvAS7degN6JsAH5ulZfC ehtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LqirUNnrjlyE88Jp2mKNbZ0VgqIS7pTXeuQG3ZpC3Bo=; b=nIbUVU32q6pees9vrARrMk+BTLyBDgc007d55QiTzygKC+iBVfQ29hmtDxJAFVHdNt hTmsSWLjcmQ9rvlahuc6vD3EnKzn4/fJ6p8OdszGgoyOPGJTwvXKEB0BIUWymA/4CXcB /MEE3lJNjK2//ZBxx49JD06rticSKEazEHgiL+kFPL1LQFDJRTNwZ7USN93/RbhZfO+p bNxe+D3cYk/GXPoSoCuJoOXFXJ3gZIueQBgdwnVOxr2ASwxUW7lABiDlvWs3q+OS/dxU 1Eq5xisLm/P6LQ9uCU42oQ9boiZkE+3+flXo8UFwP/0RGSSkKzueXuxpwkqWgyVO5GqH VdkQ== X-Gm-Message-State: AOAM531TpYe2DCXRzYmnX3sbs+RYQ4Vqr3vmhH34ANBvGWSPa+uA7Nrh SNm4N/ZukcTkHuAqngYXtTkxZtEBwOa0dhtqTKOjVUFcUtKPEA== X-Google-Smtp-Source: ABdhPJygZ7ZxT1Y9MacEzIEkT+bqT/VTYbgGFod0PkmaI0IYWAPfPGabnaFYuXOExud22NiRMJV0XgyG5ZsXo7l0us4= X-Received: by 2002:ac5:c925:: with SMTP id u5mr12534682vkl.68.1597782541064; Tue, 18 Aug 2020 13:29:01 -0700 (PDT) MIME-Version: 1.0 References: <227bfb55-a2b4-37f0-9802-ddc76b22fa91@erg.abdn.ac.uk> In-Reply-To: <227bfb55-a2b4-37f0-9802-ddc76b22fa91@erg.abdn.ac.uk> From: Yuchung Cheng Date: Tue, 18 Aug 2020 13:28:24 -0700 Message-ID: To: Gorry Fairhurst Cc: tcpm IETF list Content-Type: multipart/alternative; boundary="000000000000ca41f005ad2cbc6e" Archived-At: Subject: Re: [tcpm] A review for draft-ietf-tcpm-rack-09 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 Aug 2020 20:29:05 -0000 --000000000000ca41f005ad2cbc6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2020 at 6:42 AM Gorry Fairhurst wrote: > I have read draft-ietf-tcpm-rack-09 in preparation for TCPM to publish > this document, and do have some comments. I note that this new rev is > much easier to read this time, so thanks for the significant work to > produce a clear spec, and I see also that you have already addressed my > major concerns - thanks. (I'll separately catch a set of minor editorial > notes on this rev). > Thank you for the review! > > (1) I don=E2=80=99t understand this clause: > =E2=80=9C 3. The RACK reordering window SHOULD leverage that to adaptiv= ely > estimate the duration of reordering events, if the receiver uses > Duplicate Selective Acknowledgement (DSACK) [RFC2883].=E2=80=9D > - What does =E2=80=9Cleverage that=E2=80=9D actually mean? > - Might it mean something like: can be increased if the sender receives > a Duplicate Selective Acknowledgement (DSACK) [RFC2883], that suggests > the window is too small, and has resulted in spurious retransmission." = =E2=80=A6 > or does it mean something different? > It means exactly what you said :-) Here is the latest rev based on Theresa' suggestion: "The RACK reordering window SHOULD adaptively increase if the sender receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883], suggesting the window is too small which causes spurious retransmission." Let me know if that's better? > > (2) I did not understand this part in Section 3.3: > =E2=80=9CHowever, the fact that the initial reordering window is low, and= the > reordering window's adaptive growth is bounded, means that there will > continue to be a cost to reordering to disincentivize excessive > network reordering over highly disjoint paths. For such networks > there are good alternative solutions, such as MPTCP.=E2=80=9C > - Is this intended to read as /reordering that disincentivizes excessive/ > - If that was intended, the spec appears to be for a single path, MPTCP > would still view this path with reordering as a single path, so I do not > understand how MPTCP helps unless the awareness of the disjoint paths is > somehow known at the endpoints? Please explain. > > - (You=E2=80=99d need a REF for MPTCP if you keep this senetnce and the > explanation). > Yes that's the intention. Will removing the last sentence (about MPTCP) help? > > (3) > Question in Section 7.4.2. > /If the TLP > sender does not receive such an indication, then it SHOULD assume > that either the original data segment or the TLP retransmission were > lost, for congestion control purposes./ > - Why is this not a MUST? > - Under what conditions would it be safe to ignore a SHOULD? > We use SHOULD because the ACK could be lost instead of the data, so if the sender has some mechanism to detect ACK losses well, it may be safe not to assume data was lost. But I agree this is over-thinking the corner cases so how about If the TLP sender does not receive such an indication, then it *MUST* assume that either the original data segment, or the TLP retransmission were lost*, or their ACKs* are lost for congestion control purposes. > > (4) in Section 6.2. I was also left with a potential concern about > =E2=80=9Cmin_RTT=E2=80=9D with respect to =E2=80=9Ca simple global minimu= m of all RTT > measurements from the connection=E2=80=9D. This method results in a sign= ificant > path change from low to high RTT exhibiting an invalid RTT. Even a > simple windowed min-filtered estimate - mentioned here - would avoid > this effect on reordering detection. > > - I=E2=80=99d prefer adding a short sentence so people know why the upda= tes to > min_RTT might be useful. > Good point. (some) windowed-filter is definitely prefered. how about: The sender SHOULD track a windowed min-filtered estimate of recent RTT measurements to adapt migrating to significant longer paths, compared to a simple global minimum of all RTT measurements. > > (5) In section 8.1, I expected more discussion of the potential > disadvantages (even if the authors seem to suggest these are not > significant) : > > * I still was left without understanding whether there is an impact from > a path with a varying RTT (perhaps one that uses a link layer > retransmission or access technology). My feeling is that if there is > excessive variation the method could go wrong when the RTT increases, > but I wonder if this is usually captured by inflating the SRTT and that > more excessive variation is not common. I think this case should be > discussed briefly. > AFAIU the scenario you are referring is when the link-layer retransmitted packets took a much longer > current SRTT to be delivered. Then RACK reordering window (and its SRTT-bound) requires DSACK and new RTT measurement to raise to capture this variation. Depending on the RTT variation, it may take multiple round trips to adapt to. The idea is for short flows, RACK may not be able to cope with it (and we welcome any simple idea to improve that). For long flows, RACK should eventually adapt to these high varying RTT. Hence we've tested RACK with high varying degree of reordering (in time) in synthetic benchmarks. In production experiments, we have not found such high variation too common tho: the wireless radio does not alter its transmission rate too often or change its retry count dynamically. But of course, we try to avoid any mention of "empirical case frequency" :-) It that addresses your question, we can add some words in the reordering design rationale about this. > * As I read it, RACK can also send more retransmissions after there has > been loss, where it is making spurious retransmissions - from timer > events, or as a result of multiple segments from a single TSO segment > being retransmitted. While it seems to be argued these are not > significant, it could none the less a disadvantage in some scenarios, > and should be captured in section 8.1. > The first case spurious RACK timer expiration is possible. So we can append to the end of 8.1 with "Another disadvantage is the reordering timer may expire prematurely (like any other retransmission timer) to cause higher spurious retransmission especially if DSACK is not supported". However RACK should not cause extra spurious retransmission with TSO (vs non-TSO) as a loss detection algorithm. Perhaps some text in TSO was not clear on this? > > * Also there seem cases where RACK allows TCP to continue to increase > the congestion window upon receiving ACKs after loss, making the sender > more aggressive. This is noted in 8.3, but I think should be listed in > the disadvantages in 8.1. > Section 8.3 clearly states RACK can make C.C. more aggressive. Disadvantage or not depends on how one looks at it. IMO really beyond the scope of this doc. > > (6) Section 8.4 talks about ACK loss or a delayed ACK without a DSACK, > but does not mention Stretch ACKs, which have also been experienced, and > need some form of mention! > There are two kinds of stretched ACKs I knew of: (a) ACKs delayed by the receiver in hope to accumulate more. (b) ACKs "compressed" or decimated by the receiver or middle-boxes. It's the former (a) that affects RACK so we use delayed ACK in the general delayed stretched ACK form. > > (7) Why isn't TCP-NCR (RFC4653) at least mentioned and discussed in the > intro? > It is briefly mentioned in https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-2.2 and discussed a bit more in https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-8.2 > Gorry > > > --000000000000ca41f005ad2cbc6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 18, 2020 at 6:42 AM Gorry= Fairhurst <gorry@erg.abdn.ac.uk= > wrote:
= I have read draft-ietf-tcpm-rack-09 in preparation for TCPM to publish
this document, and do have some comments. I note that this new rev is
much easier to read this time, so thanks for the significant work to
produce a clear spec, and I see also that you have already addressed my major concerns - thanks. (I'll separately catch a set of minor editoria= l
notes on this rev).
Thank you for the review!
=C2=A0

(1) I don=E2=80=99t understand this clause:
=E2=80=9C=C2=A0 3.=C2=A0 The RACK reordering window SHOULD leverage that to= adaptively
estimate the duration of reordering events, if the receiver uses=C2=A0
Duplicate Selective Acknowledgement (DSACK) [RFC2883].=E2=80=9D
- What does =E2=80=9Cleverage that=E2=80=9D actually mean?
- Might it mean something like: can be increased if the sender receives a Duplicate Selective Acknowledgement (DSACK) [RFC2883], that suggests
the window is too small, and has resulted in spurious retransmission."= =E2=80=A6
or does it mean something different?
It means exactly = what you said :-)

Here is the latest rev based on = Theresa' suggestion:
"The RACK reordering window SHOULD adap= tively increase if the sender receives the Duplicate Selective Acknowledgem= ent (DSACK) [RFC2883], suggesting the window is too small which causes spur= ious retransmission."

Let me know if t= hat's better?


=C2= =A0

(2) I did not understand this part in Section 3.3:
=E2=80=9CHowever, the fact that the initial reordering window is low, and t= he
=C2=A0=C2=A0=C2=A0 reordering window's adaptive growth is bounded, mean= s that there will
=C2=A0=C2=A0=C2=A0 continue to be a cost to reordering to disincentivize ex= cessive
=C2=A0=C2=A0=C2=A0 network reordering over highly disjoint paths.=C2=A0 For= such networks
=C2=A0=C2=A0=C2=A0 there are good alternative solutions, such as MPTCP.=E2= =80=9C
- Is this intended to read as /reordering that disincentivizes excessive/ - If that was intended, the spec appears to be for a single path, MPTCP would still view this path with reordering as a single path, so I do not understand how MPTCP helps unless the awareness of the disjoint paths is somehow known at the endpoints? Please explain.

- (You=E2=80=99d need a REF for MPTCP if you keep this senetnce and the explanation).
Yes that's the intention. Will remov= ing the last sentence (about MPTCP) help?
=C2=A0

(3)
=C2=A0=C2=A0Question in Section 7.4.2.
/If the TLP
=C2=A0=C2=A0=C2=A0 sender does not receive such an indication, then it SHOU= LD assume
=C2=A0=C2=A0=C2=A0 that either the original data segment or the TLP retrans= mission were
=C2=A0=C2=A0=C2=A0 lost, for congestion control purposes./
- Why is this not a MUST?
- Under what conditions would it be safe to ignore a SHOULD?
We use SHOULD because the ACK could be lost instead of the data, so = if the sender has some mechanism to detect ACK losses well, it may be safe = not to assume data was lost.

But I agree this is o= ver-thinking the corner cases so how about

If the TLP sender does not receive such an in= dication, then it MUST assume that either the original data segment,= or the TLP retransmission were lost, or their ACKs are lost for con= gestion control purposes.

=C2=A0

(4) in Section 6.2. I was also left with a potential concern about
=E2=80=9Cmin_RTT=E2=80=9D with respect to =E2=80=9Ca simple global minimum = of all RTT
measurements from the connection=E2=80=9D.=C2=A0 This method results in a s= ignificant
path change from low to high RTT exhibiting an invalid RTT. Even a
simple windowed min-filtered estimate - mentioned here - would avoid
this effect on reordering detection.

- I=E2=80=99d prefer adding a short sentence=C2=A0 so people know why the u= pdates to
min_RTT might be useful.
Good point. (some) windowed-f= ilter is definitely prefered. how about:

The sender SHOULD track a windowed min-filtered estimate of recent RTT measurements to adapt= migrating to significant longer paths, compared to a simple global minimum= of all RTT measurements.


=C2=A0

(5) In section 8.1, I expected more discussion of the potential
disadvantages (even if the authors seem to suggest these are not
significant) :

* I still was left without understanding whether there is an impact from a path with a varying RTT (perhaps one that uses a link layer
retransmission or access technology). My feeling is that if there is
excessive variation the method could go wrong when the RTT increases,
but I wonder if this is usually captured by inflating the SRTT and that more excessive variation is not common. I think this case should be
discussed briefly.
AFAIU the scenario you are referrin= g is when the link-layer retransmitted packets took a much longer > curr= ent SRTT to be delivered. Then RACK reordering window (and its=C2=A0SRTT-bo= und) requires=C2=A0DSACK and new RTT measurement to raise to capture this v= ariation. Depending on the RTT variation, it may take multiple round trips = to adapt to. The idea is for short flows, RACK may not be able to cope with= it (and we welcome any simple idea to improve that). For long flows, RACK = should eventually adapt to these high varying RTT. Hence we've tested R= ACK with high varying degree of reordering (in time) in synthetic benchmark= s. In production experiments, we have not found such high variation too com= mon tho: the wireless radio does not alter its transmission rate too often = or change its retry count dynamically. But of course, we try to avoid any m= ention of "empirical case frequency" :-)

It that addresses your question, we can add some words in the reordering d= esign rationale about this.


* As I read it, RACK can also send more retransmissions after there has been loss, where it is making spurious retransmissions - from timer
events, or as a result of multiple segments from a single TSO segment
being retransmitted. While it seems to be argued these are not
significant, it could none the less a disadvantage in some scenarios,
and should be captured in section 8.1.
The first case = spurious RACK timer expiration is possible. So we can append to the end of = 8.1 with
"Another disadvantage is the reordering timer may e= xpire prematurely (like any other retransmission timer) to cause higher spu= rious retransmission especially if DSACK is not supported".
=
However RACK should not cause extra spurious retransmission = with TSO (vs non-TSO) as a loss detection algorithm. Perhaps some text in T= SO was not clear on this?=C2=A0
=C2=A0

* Also there seem cases where RACK allows TCP to continue to increase
the congestion window upon receiving ACKs after loss, making the sender more aggressive. This is noted in 8.3, but I think should be listed in
the disadvantages in 8.1.
Section 8.3 clearly states R= ACK can make C.C. more aggressive. Disadvantage or not depends on how one l= ooks at=C2=A0 it. IMO really beyond the scope of this doc.
=C2=A0=

(6) Section 8.4 talks about ACK loss or a delayed ACK without a DSACK,
but does not mention Stretch ACKs, which have also been experienced, and need some form of mention!
There are two kinds of stre= tched=C2=A0ACKs I knew of: (a) ACKs delayed by the receiver in hope to accu= mulate more.=C2=A0 (b) ACKs "compressed" or decimated by the rece= iver or middle-boxes. It's the former (a) that affects RACK so we use d= elayed ACK in the general delayed stretched ACK form.
=C2=A0

(7) Why isn't TCP-NCR (RFC4653) at least mentioned and discussed in the=
intro?


Gorry


--000000000000ca41f005ad2cbc6e-- From nobody Wed Aug 19 00:27:06 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 259613A10C2 for ; Wed, 19 Aug 2020 00:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 c06aWym4XahT for ; Wed, 19 Aug 2020 00:27:01 -0700 (PDT) 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 5D34E3A10C1 for ; Wed, 19 Aug 2020 00:27:01 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id D2C2D1B000E5; Wed, 19 Aug 2020 08:26:56 +0100 (BST) To: Yuchung Cheng Cc: tcpm IETF list References: <227bfb55-a2b4-37f0-9802-ddc76b22fa91@erg.abdn.ac.uk> From: Gorry Fairhurst Message-ID: Date: Wed, 19 Aug 2020 08:26:55 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6C4FB28C15D806C61DB35DC9" Content-Language: en-GB Archived-At: Subject: Re: [tcpm] A review for draft-ietf-tcpm-rack-09 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 Aug 2020 07:27:04 -0000 This is a multi-part message in MIME format. --------------6C4FB28C15D806C61DB35DC9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit See below. On 18/08/2020 21:28, Yuchung Cheng wrote: > > > On Tue, Aug 18, 2020 at 6:42 AM Gorry Fairhurst > wrote: > > I have read draft-ietf-tcpm-rack-09 in preparation for TCPM to > publish > this document, and do have some comments. I note that this new rev is > much easier to read this time, so thanks for the significant work to > produce a clear spec, and I see also that you have already > addressed my > major concerns - thanks. (I'll separately catch a set of minor > editorial > notes on this rev). > > Thank you for the review! > > > (1) I don’t understand this clause: > “  3.  The RACK reordering window SHOULD leverage that to adaptively > estimate the duration of reordering events, if the receiver uses > Duplicate Selective Acknowledgement (DSACK) [RFC2883].” > - What does “leverage that” actually mean? > - Might it mean something like: can be increased if the sender > receives > a Duplicate Selective Acknowledgement (DSACK) [RFC2883], that > suggests > the window is too small, and has resulted in spurious > retransmission." … > or does it mean something different? > > It means exactly what you said :-) > > Here is the latest rev based on Theresa' suggestion: > "The RACK reordering window SHOULD adaptively increase if the sender > receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883], > suggesting the window is too small which causes spurious retransmission." > > Let me know if that's better? > WFM. > > > (2) I did not understand this part in Section 3.3: > “However, the fact that the initial reordering window is low, and the >     reordering window's adaptive growth is bounded, means that > there will >     continue to be a cost to reordering to disincentivize excessive >     network reordering over highly disjoint paths.  For such networks >     there are good alternative solutions, such as MPTCP.“ > - Is this intended to read as /reordering that disincentivizes > excessive/ > - If that was intended, the spec appears to be for a single path, > MPTCP > would still view this path with reordering as a single path, so I > do not > understand how MPTCP helps unless the awareness of the disjoint > paths is > somehow known at the endpoints? Please explain. > > - (You’d need a REF for MPTCP if you keep this senetnce and the > explanation). > > Yes that's the intention. Will removing the last sentence (about > MPTCP) help? > That would be an easy fix that would WFM. > > (3) >   Question in Section 7.4.2. > /If the TLP >     sender does not receive such an indication, then it SHOULD assume >     that either the original data segment or the TLP > retransmission were >     lost, for congestion control purposes./ > - Why is this not a MUST? > - Under what conditions would it be safe to ignore a SHOULD? > > We use SHOULD because the ACK could be lost instead of the data, so if > the sender has some mechanism to detect ACK losses well, it may be > safe not to assume data was lost. > > But I agree this is over-thinking the corner cases so how about > > If the TLP sender does not receive such an indication, then it *MUST* > assume that either the original data segment, or the TLP > retransmission were lost*, or their ACKs* are lost for congestion > control purposes. > I think the new text reads as safer to me. > > (4) in Section 6.2. I was also left with a potential concern about > “min_RTT” with respect to “a simple global minimum of all RTT > measurements from the connection”.  This method results in a > significant > path change from low to high RTT exhibiting an invalid RTT. Even a > simple windowed min-filtered estimate - mentioned here - would avoid > this effect on reordering detection. > > - I’d prefer adding a short sentence  so people know why the > updates to > min_RTT might be useful. > > Good point. (some) windowed-filter is definitely prefered. how about: > > The sender SHOULD tracka windowed min-filtered estimate of recent RTT > measurements to adapt migrating to significant longer paths, compared > to a simple global minimum of all RTT measurements. > > I like that proposed text. I don't think teh method has to be sophisticated, but some method seems the right thing to do. > > > (5) In section 8.1, I expected more discussion of the potential > disadvantages (even if the authors seem to suggest these are not > significant) : > > * I still was left without understanding whether there is an > impact from > a path with a varying RTT (perhaps one that uses a link layer > retransmission or access technology). My feeling is that if there is > excessive variation the method could go wrong when the RTT increases, > but I wonder if this is usually captured by inflating the SRTT and > that > more excessive variation is not common. I think this case should be > discussed briefly. > > AFAIU the scenario you are referring is when the link-layer > retransmitted packets took a much longer > current SRTT to be delivered. Yes. > Then RACK reordering window (and its SRTT-bound) requires DSACK and > new RTT measurement to raise to capture this variation. Depending on > the RTT variation, it may take multiple round trips to adapt to. The > idea is for short flows, RACK may not be able to cope with it (and we > welcome any simple idea to improve that). Understood. > For long flows, RACK should eventually adapt to these high varying > RTT. Hence we've tested RACK with high varying degree of reordering > (in time) in synthetic benchmarks. In production experiments, we have > not found such high variation too common tho: the wireless radio does > not alter its transmission rate too often or change its retry count > dynamically. But of course, we try to avoid any mention of "empirical > case frequency" :-) > > It that addresses your question, we can add some words in the > reordering design rationale about this. > I think a few words would help - just so that if the corner case is encountered people understand there was a tradeoff. > > > * As I read it, RACK can also send more retransmissions after > there has > been loss, where it is making spurious retransmissions - from timer > events, or as a result of multiple segments from a single TSO segment > being retransmitted. While it seems to be argued these are not > significant, it could none the less a disadvantage in some scenarios, > and should be captured in section 8.1. > > The first case spurious RACK timer expiration is possible. So we can > append to the end of 8.1 with > "Another disadvantage is the reordering timer may expire prematurely > (like any other retransmission timer) to cause higher spurious > retransmission especially if DSACK is not supported". > That would be fine for me. > However RACK should not cause extra spurious retransmission with TSO > (vs non-TSO) as a loss detection algorithm. Perhaps some text in TSO > was not clear on this? > > > * Also there seem cases where RACK allows TCP to continue to increase > the congestion window upon receiving ACKs after loss, making the > sender > more aggressive. This is noted in 8.3, but I think should be > listed in > the disadvantages in 8.1. > > Section 8.3 clearly states RACK can make C.C. more aggressive. > Disadvantage or not depends on how one looks at it. IMO really beyond > the scope of this doc. :-) Indeed, how you view this will depend on what is regarded as best. I think it's kind of obvious there might be CC implications, maybe there is no need to discuss that. > > (6) Section 8.4 talks about ACK loss or a delayed ACK without a > DSACK, > but does not mention Stretch ACKs, which have also been > experienced, and > need some form of mention! > > There are two kinds of stretched ACKs I knew of: (a) ACKs delayed by > the receiver in hope to accumulate more.  (b) ACKs "compressed" or > decimated by the receiver or middle-boxes. > It's the former (a) that affects RACK so we use delayed ACK in the > general delayed stretched ACK form. So, on this I think any stretch ACK caused by ACK delay, loss in the network, or intentional dropping has the same effect of extending the period it takes for the endpoint to observe the ACK. The typical stretch ACK intervals seem to me to be a few packets, so I am not sure typically this creates an issue for RACK, but if ACK delay is mentioned I don't understand why stretch ACKs from other cases are also not equally mentioned? > > > (7) Why isn't TCP-NCR (RFC4653) at least mentioned and discussed > in the > intro? > > It is briefly mentioned in > https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-2.2 and > discussed a bit more in > https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-8.2 > The existing discussion is fine (thanks), I did not see the RFC listed in the References! > > > Gorry > > Best wishes, Gorry --------------6C4FB28C15D806C61DB35DC9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

See below.

On 18/08/2020 21:28, Yuchung Cheng wrote:


On Tue, Aug 18, 2020 at 6:42 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
I have read draft-ietf-tcpm-rack-09 in preparation for TCPM to publish
this document, and do have some comments. I note that this new rev is
much easier to read this time, so thanks for the significant work to
produce a clear spec, and I see also that you have already addressed my
major concerns - thanks. (I'll separately catch a set of minor editorial
notes on this rev).
Thank you for the review!
 

(1) I don’t understand this clause:
“  3.  The RACK reordering window SHOULD leverage that to adaptively
estimate the duration of reordering events, if the receiver uses 
Duplicate Selective Acknowledgement (DSACK) [RFC2883].”
- What does “leverage that” actually mean?
- Might it mean something like: can be increased if the sender receives
a Duplicate Selective Acknowledgement (DSACK) [RFC2883], that suggests
the window is too small, and has resulted in spurious retransmission." …
or does it mean something different?
It means exactly what you said :-)

Here is the latest rev based on Theresa' suggestion:
"The RACK reordering window SHOULD adaptively increase if the sender receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883], suggesting the window is too small which causes spurious retransmission."

Let me know if that's better?

WFM.

 

(2) I did not understand this part in Section 3.3:
“However, the fact that the initial reordering window is low, and the
    reordering window's adaptive growth is bounded, means that there will
    continue to be a cost to reordering to disincentivize excessive
    network reordering over highly disjoint paths.  For such networks
    there are good alternative solutions, such as MPTCP.“
- Is this intended to read as /reordering that disincentivizes excessive/
- If that was intended, the spec appears to be for a single path, MPTCP
would still view this path with reordering as a single path, so I do not
understand how MPTCP helps unless the awareness of the disjoint paths is
somehow known at the endpoints? Please explain.

- (You’d need a REF for MPTCP if you keep this senetnce and the
explanation).
Yes that's the intention. Will removing the last sentence (about MPTCP) help?
 

That would be an easy fix that would WFM.


(3)
  Question in Section 7.4.2.
/If the TLP
    sender does not receive such an indication, then it SHOULD assume
    that either the original data segment or the TLP retransmission were
    lost, for congestion control purposes./
- Why is this not a MUST?
- Under what conditions would it be safe to ignore a SHOULD?
We use SHOULD because the ACK could be lost instead of the data, so if the sender has some mechanism to detect ACK losses well, it may be safe not to assume data was lost.

But I agree this is over-thinking the corner cases so how about

If the TLP sender does not receive such an indication, then it MUST assume that either the original data segment, or the TLP retransmission were lost, or their ACKs are lost for congestion control purposes.

 

I think the new text reads as safer to me.


(4) in Section 6.2. I was also left with a potential concern about
“min_RTT” with respect to “a simple global minimum of all RTT
measurements from the connection”.  This method results in a significant
path change from low to high RTT exhibiting an invalid RTT. Even a
simple windowed min-filtered estimate - mentioned here - would avoid
this effect on reordering detection.

- I’d prefer adding a short sentence  so people know why the updates to
min_RTT might be useful.
Good point. (some) windowed-filter is definitely prefered. how about:

The sender SHOULD track a windowed min-filtered estimate of recent RTT measurements to adapt migrating to significant longer paths, compared to a simple global minimum of all RTT measurements.


I like that proposed text. I don't think teh method has to be sophisticated, but some method seems the right thing to do.

(5) In section 8.1, I expected more discussion of the potential
disadvantages (even if the authors seem to suggest these are not
significant) :

* I still was left without understanding whether there is an impact from
a path with a varying RTT (perhaps one that uses a link layer
retransmission or access technology). My feeling is that if there is
excessive variation the method could go wrong when the RTT increases,
but I wonder if this is usually captured by inflating the SRTT and that
more excessive variation is not common. I think this case should be
discussed briefly.
AFAIU the scenario you are referring is when the link-layer retransmitted packets took a much longer > current SRTT to be delivered.
Yes.
Then RACK reordering window (and its SRTT-bound) requires DSACK and new RTT measurement to raise to capture this variation. Depending on the RTT variation, it may take multiple round trips to adapt to. The idea is for short flows, RACK may not be able to cope with it (and we welcome any simple idea to improve that).
Understood.
For long flows, RACK should eventually adapt to these high varying RTT. Hence we've tested RACK with high varying degree of reordering (in time) in synthetic benchmarks. In production experiments, we have not found such high variation too common tho: the wireless radio does not alter its transmission rate too often or change its retry count dynamically. But of course, we try to avoid any mention of "empirical case frequency" :-)

It that addresses your question, we can add some words in the reordering design rationale about this.

I think a few words would help - just so that if the corner case is encountered people understand there was a tradeoff.

* As I read it, RACK can also send more retransmissions after there has
been loss, where it is making spurious retransmissions - from timer
events, or as a result of multiple segments from a single TSO segment
being retransmitted. While it seems to be argued these are not
significant, it could none the less a disadvantage in some scenarios,
and should be captured in section 8.1.
The first case spurious RACK timer expiration is possible. So we can append to the end of 8.1 with
"Another disadvantage is the reordering timer may expire prematurely (like any other retransmission timer) to cause higher spurious retransmission especially if DSACK is not supported".

That would be fine for me.
However RACK should not cause extra spurious retransmission with TSO (vs non-TSO) as a loss detection algorithm. Perhaps some text in TSO was not clear on this? 
 

* Also there seem cases where RACK allows TCP to continue to increase
the congestion window upon receiving ACKs after loss, making the sender
more aggressive. This is noted in 8.3, but I think should be listed in
the disadvantages in 8.1.
Section 8.3 clearly states RACK can make C.C. more aggressive. Disadvantage or not depends on how one looks at  it. IMO really beyond the scope of this doc.
 

:-)

Indeed, how you view this will depend on what is regarded as best. I think it's kind of obvious there might be CC implications, maybe there is no need to discuss that.


(6) Section 8.4 talks about ACK loss or a delayed ACK without a DSACK,
but does not mention Stretch ACKs, which have also been experienced, and
need some form of mention!
There are two kinds of stretched ACKs I knew of: (a) ACKs delayed by the receiver in hope to accumulate more.  (b) ACKs "compressed" or decimated by the receiver or middle-boxes.
It's the former (a) that affects RACK so we use delayed ACK in the general delayed stretched ACK form.
 
So, on this I think any stretch ACK caused by ACK delay, loss in the network, or intentional dropping has the same effect of extending the period it takes for the endpoint to observe the ACK. The typical stretch ACK intervals seem to me to be a few packets, so I am not sure typically this creates an issue for RACK, but if ACK delay is mentioned I don't understand why stretch ACKs from other cases are also not equally mentioned?

(7) Why isn't TCP-NCR (RFC4653) at least mentioned and discussed in the
intro?

The existing discussion is fine (thanks), I did not see the RFC listed in the References!

Gorry


Best wishes,

Gorry

--------------6C4FB28C15D806C61DB35DC9-- From nobody Wed Aug 19 15:21:08 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 829343A0D4E for ; Wed, 19 Aug 2020 15:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 yLquLVDddcc6 for ; Wed, 19 Aug 2020 15:21:03 -0700 (PDT) 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 8CA1B3A0D3E for ; Wed, 19 Aug 2020 15:21:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 565C125A14; Thu, 20 Aug 2020 00:21:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1597875661; bh=NWPI2uLVxbWyQi5ytIBwuR4gb30wW1K6veTWJlphCpQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=domvhdAWvr+TPASLVigTtnpt+sCGXYJCnMzPfEI7vg7QUmyFh5wezIOZcPDp8QQ0g 8DUSUkg3QhTZcKYuOCHS7sf+EwSBjptPdVjL8eAno0Bp7kaZiROkQvq0LSVAqP0AA0 DEmtaG2C9IYn97tM/7Er2ym4Ma9Y1wSqoFxrApmo= 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 NESSr6HVrERb; Thu, 20 Aug 2020 00:21:00 +0200 (CEST) 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; Thu, 20 Aug 2020 00:21:00 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.74]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Thu, 20 Aug 2020 00:21:00 +0200 From: "Scharf, Michael" To: Lars Eggert , Yoshifumi Nishida CC: "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 Thread-Index: AQHWaWzLjfgW/VQy5kO/gyv3uqZiX6k9f7qAgAKVKTA= Date: Wed, 19 Aug 2020 22:20:59 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DD2AB4B@rznt8114.rznt.rzdir.fht-esslingen.de> References: <36DD050C-4457-4151-ABF2-8C77685C4135@eggert.org> In-Reply-To: <36DD050C-4457-4151-ABF2-8C77685C4135@eggert.org> 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: Re: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 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 Aug 2020 22:21:06 -0000 Hi Lars, > -----Original Message----- > From: tcpm On Behalf Of Lars Eggert > Sent: Tuesday, August 18, 2020 10:32 AM > To: Yoshifumi Nishida > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 >=20 > Hi, >=20 > On 2020-8-3, at 11:04, Yoshifumi Nishida wrote: > > 2: if you hummed for not adopting the draft, please share your opinion. > This will be a very helpful input for us. >=20 > I shared my opinion on this in the past, and it hasn't changed. ... but the document has changed significantly since the past discussions, = amongst others to address your pushback. Can you be a bit more specific regarding your concerns, specifically consid= ering draft-scharf-tcpm-yang-tcp-06? The latest version -06 is quite short and has a narrow scope to address the= most obvious use cases for a TCP YANG model, most notably TCP-AO in IDR. O= ther than that, -06 basically just documents how the information in the TCP= MIB can be modeled in YANG. The TCP MIB is used by several TCP implementat= ions as basis for basic stats (as discussed previously). And I guess it is = IETF consensus that YANG is a better alternative for data models. As usual,= a document proposed for WG adoption is not final, but the authors believe = that the model in draft-scharf-tcpm-yang-tcp-06 is already in a decent shap= e. As a result, it is a bit difficult to understand why such a narrow-scoped d= ocument should not be doable with reasonable effort in TCPM. Michael (as author) =20 From nobody Wed Aug 19 18:18: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 7CDE13A0FF7 for ; Wed, 19 Aug 2020 18:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.589 X-Spam-Level: X-Spam-Status: No, score=-17.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 dUHiZ5oc4StJ for ; Wed, 19 Aug 2020 18:18:37 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 7C6223A0FF9 for ; Wed, 19 Aug 2020 18:18:37 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id v20so102154ual.4 for ; Wed, 19 Aug 2020 18:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gm7phkrmcuYb6qJI3eenQ2VMs2k4wD9kaWG1Vp+jd0g=; b=ua+QvMhsRFNQQxxmPQCuxv4zofXibZEth9cppPNdSyGvdKW5cQ0SihxTMpRzZWbknE S1djzKDSh+ww4qcTOjItq+JNMESQPBa0WVNzBRjjv6A3CN0w8DKg0UtJq+yeGWEtj5wY vVgoOO0Dn6GwGKQurzi9WO6ws3eolRW5NOKEABoXG0WoYlNluaVq1j4wsza2rEGfrePf j1KYMfv6vKZAy+iZUV+yop3zScOaoXXATiJCG52wzMzlPxl7hsG2NoQFAD/TUAOew9bW pPq7rE0Z4D7MPqyPdQXpehwFduorT2uPcT7bk2ogZxVNPWlokKdD1YWjwwpaHBeY78zl BUsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gm7phkrmcuYb6qJI3eenQ2VMs2k4wD9kaWG1Vp+jd0g=; b=rV8gS/pB64zQeT6i4FWh+Q90k/2zG2/XihnM7kNpjivdc7Eqro3+pzz7DUueKDokRo Mk8/9B4ksT6at6VDHowo9/UfDNJFvxDUxDDH7HQHrDA3x+69u0kELi0eTL7d1kKlSaMb EwBkxnVcV6qDhv+OSFkMeNZeLdLIhLwM7PwXr3cCOGGyvoi7MtR1hgR5NnzQjnieOv4x WKC/3K5rQ6qC17Fd6Gz6evPYcnE2ccFogB+CDC8CQmVH7yXSbQ2V/KLN6JEWUHVCQKAn 739GeugYw15F/SpEIEuWzxqhf2kuYHuSWgDw8o69NIO/y6txXx/R44ozOTjxMQrdMN1O PySw== X-Gm-Message-State: AOAM53034jfzJ/Fy5nzeQJ4yFVpq6sdwvbw4mfVwF1Hd00aWE+2KuJ/Z SeSWXKqZB6Ea2fGBs6nwcRNC/IgjWeA/yCzfb3b2oFGGyiLolA== X-Google-Smtp-Source: ABdhPJxlOqcX6leYNtkpTCGokI2GtTGGNFsgS/q9p17R9THXh0GGYFZYscFSxbzmXPMDtdOqWw9Q3yqtEQnFZZcS9SY= X-Received: by 2002:ab0:4828:: with SMTP id b37mr265797uad.83.1597886315999; Wed, 19 Aug 2020 18:18:35 -0700 (PDT) MIME-Version: 1.0 References: <227bfb55-a2b4-37f0-9802-ddc76b22fa91@erg.abdn.ac.uk> In-Reply-To: From: Yuchung Cheng Date: Wed, 19 Aug 2020 18:17:59 -0700 Message-ID: To: Gorry Fairhurst Cc: tcpm IETF list Content-Type: multipart/alternative; boundary="000000000000422d4b05ad44e68e" Archived-At: Subject: Re: [tcpm] A review for draft-ietf-tcpm-rack-09 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, 20 Aug 2020 01:18:41 -0000 --000000000000422d4b05ad44e68e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 19, 2020 at 12:27 AM Gorry Fairhurst wrote: > See below. > On 18/08/2020 21:28, Yuchung Cheng wrote: > > > > On Tue, Aug 18, 2020 at 6:42 AM Gorry Fairhurst > wrote: > >> I have read draft-ietf-tcpm-rack-09 in preparation for TCPM to publish >> this document, and do have some comments. I note that this new rev is >> much easier to read this time, so thanks for the significant work to >> produce a clear spec, and I see also that you have already addressed my >> major concerns - thanks. (I'll separately catch a set of minor editorial >> notes on this rev). >> > Thank you for the review! > > >> >> (1) I don=E2=80=99t understand this clause: >> =E2=80=9C 3. The RACK reordering window SHOULD leverage that to adapti= vely >> estimate the duration of reordering events, if the receiver uses >> Duplicate Selective Acknowledgement (DSACK) [RFC2883].=E2=80=9D >> - What does =E2=80=9Cleverage that=E2=80=9D actually mean? >> - Might it mean something like: can be increased if the sender receives >> a Duplicate Selective Acknowledgement (DSACK) [RFC2883], that suggests >> the window is too small, and has resulted in spurious retransmission." = =E2=80=A6 >> or does it mean something different? >> > It means exactly what you said :-) > > Here is the latest rev based on Theresa' suggestion: > "The RACK reordering window SHOULD adaptively increase if the sender > receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883], > suggesting the window is too small which causes spurious retransmission." > > Let me know if that's better? > > WFM. > > > > >> >> (2) I did not understand this part in Section 3.3: >> =E2=80=9CHowever, the fact that the initial reordering window is low, an= d the >> reordering window's adaptive growth is bounded, means that there wil= l >> continue to be a cost to reordering to disincentivize excessive >> network reordering over highly disjoint paths. For such networks >> there are good alternative solutions, such as MPTCP.=E2=80=9C >> - Is this intended to read as /reordering that disincentivizes excessive= / >> - If that was intended, the spec appears to be for a single path, MPTCP >> would still view this path with reordering as a single path, so I do not >> understand how MPTCP helps unless the awareness of the disjoint paths is >> somehow known at the endpoints? Please explain. >> >> - (You=E2=80=99d need a REF for MPTCP if you keep this senetnce and the >> explanation). >> > Yes that's the intention. Will removing the last sentence (about MPTCP) > help? > > > That would be an easy fix that would WFM. > > >> (3) >> Question in Section 7.4.2. >> /If the TLP >> sender does not receive such an indication, then it SHOULD assume >> that either the original data segment or the TLP retransmission were >> lost, for congestion control purposes./ >> - Why is this not a MUST? >> - Under what conditions would it be safe to ignore a SHOULD? >> > We use SHOULD because the ACK could be lost instead of the data, so if th= e > sender has some mechanism to detect ACK losses well, it may be safe not t= o > assume data was lost. > > But I agree this is over-thinking the corner cases so how about > > If the TLP sender does not receive such an indication, then it *MUST* > assume that either the original data segment, or the TLP retransmission > were lost*, or their ACKs* are lost for congestion control purposes. > > > I think the new text reads as safer to me. > > >> (4) in Section 6.2. I was also left with a potential concern about >> =E2=80=9Cmin_RTT=E2=80=9D with respect to =E2=80=9Ca simple global minim= um of all RTT >> measurements from the connection=E2=80=9D. This method results in a sig= nificant >> path change from low to high RTT exhibiting an invalid RTT. Even a >> simple windowed min-filtered estimate - mentioned here - would avoid >> this effect on reordering detection. >> >> - I=E2=80=99d prefer adding a short sentence so people know why the upd= ates to >> min_RTT might be useful. >> > Good point. (some) windowed-filter is definitely prefered. how about: > > The sender SHOULD track a windowed min-filtered estimate of recent RTT > measurements to adapt migrating to significant longer paths, compared to = a > simple global minimum of all RTT measurements. > > > I like that proposed text. I don't think teh method has to be > sophisticated, but some method seems the right thing to do. > > >> (5) In section 8.1, I expected more discussion of the potential >> disadvantages (even if the authors seem to suggest these are not >> significant) : >> >> * I still was left without understanding whether there is an impact from >> a path with a varying RTT (perhaps one that uses a link layer >> retransmission or access technology). My feeling is that if there is >> excessive variation the method could go wrong when the RTT increases, >> but I wonder if this is usually captured by inflating the SRTT and that >> more excessive variation is not common. I think this case should be >> discussed briefly. >> > AFAIU the scenario you are referring is when the link-layer retransmitted > packets took a much longer > current SRTT to be delivered. > > Yes. > > Then RACK reordering window (and its SRTT-bound) requires DSACK and new > RTT measurement to raise to capture this variation. Depending on the RTT > variation, it may take multiple round trips to adapt to. The idea is for > short flows, RACK may not be able to cope with it (and we welcome any > simple idea to improve that). > > Understood. > > For long flows, RACK should eventually adapt to these high varying RTT. > Hence we've tested RACK with high varying degree of reordering (in time) = in > synthetic benchmarks. In production experiments, we have not found such > high variation too common tho: the wireless radio does not alter its > transmission rate too often or change its retry count dynamically. But of > course, we try to avoid any mention of "empirical case frequency" :-) > > It that addresses your question, we can add some words in the reordering > design rationale about this. > > I think a few words would help - just so that if the corner case is > encountered people understand there was a tradeoff. > Sure -- how about adding this right after the reordering window rules in the 'reordering window adaptation section' ... 2. The RACK reordering window SHOULD adaptively increase if the sender receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883], suggesting the window is too small which causes spurious retransmission. 3. The RACK reordering window MUST be bounded and this bound SHOULD be SRTT= . *The rule 2 and 3 combined are required to adapt reordering caused by extended link layer recovery time described earlier. Then the reordering window (and its SRTT-bound) requires DSACK and new RTT measurement to increase. Depending on the RTT variation, it may take multiple round trips to adapt. *For short flows, the low initial reordering window is key to recover quickly by risking spurious retransmissions. The rationale is that spurious retransmissions for short flows are not expected to produce excessive network traffic additionally. For long flows the design tolerates reordering within a round trip. This handles reordering caused by path divergence in small time scales (reordering within the round-trip time of the shortest path). > >> * As I read it, RACK can also send more retransmissions after there has >> been loss, where it is making spurious retransmissions - from timer >> events, or as a result of multiple segments from a single TSO segment >> being retransmitted. While it seems to be argued these are not >> significant, it could none the less a disadvantage in some scenarios, >> and should be captured in section 8.1. >> > The first case spurious RACK timer expiration is possible. So we can > append to the end of 8.1 with > "Another disadvantage is the reordering timer may expire prematurely (lik= e > any other retransmission timer) to cause higher spurious retransmission > especially if DSACK is not supported". > > That would be fine for me. > > However RACK should not cause extra spurious retransmission with TSO (vs > non-TSO) as a loss detection algorithm. Perhaps some text in TSO was not > clear on this? > > >> >> * Also there seem cases where RACK allows TCP to continue to increase >> the congestion window upon receiving ACKs after loss, making the sender >> more aggressive. This is noted in 8.3, but I think should be listed in >> the disadvantages in 8.1. >> > Section 8.3 clearly states RACK can make C.C. more aggressive. > Disadvantage or not depends on how one looks at it. IMO really beyond th= e > scope of this doc. > > > :-) > > Indeed, how you view this will depend on what is regarded as best. I thin= k > it's kind of obvious there might be CC implications, maybe there is no ne= ed > to discuss that. > > >> (6) Section 8.4 talks about ACK loss or a delayed ACK without a DSACK, >> but does not mention Stretch ACKs, which have also been experienced, and >> need some form of mention! >> > There are two kinds of stretched ACKs I knew of: (a) ACKs delayed by the > receiver in hope to accumulate more. (b) ACKs "compressed" or decimated = by > the receiver or middle-boxes. > > It's the former (a) that affects RACK so we use delayed ACK in the genera= l > delayed stretched ACK form. > > > So, on this I think any stretch ACK caused by ACK delay, loss in the > network, or intentional dropping has the same effect of extending the > period it takes for the endpoint to observe the ACK. The typical stretch > ACK intervals seem to me to be a few packets, so I am not sure typically > this creates an issue for RACK, but if ACK delay is mentioned I don't > understand why stretch ACKs from other cases are also not equally mention= ed? > ok thanks for clarification. I propose we change to Delayed *or stretched ACKs *complicate the detection of repairs done by TLP, since with such ACKs the sender *takes longer time to receive fewer ACKs *than would normally be expected. >> (7) Why isn't TCP-NCR (RFC4653) at least mentioned and discussed in the >> intro? >> > It is briefly mentioned in > https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-2.2 and > discussed a bit more in > https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-8.2 > > The existing discussion is fine (thanks), I did not see the RFC listed in > the References! > Thanks for catching that. Will fix it. and double check if there're missing refs. Probably another bug in our google-doc to rfc xml conversion script..= . > >> Gorry >> >> >> Best wishes, > > Gorry > --000000000000422d4b05ad44e68e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 19, 2020 at 12:27 AM Gorr= y Fairhurst <g= orry@erg.abdn.ac.uk> wrote:
=20 =20 =20

See below.

On 18/08/2020 21:28, Yuchung Cheng wrote:
=20


On Tue, Aug 18, 2020 at 6:4= 2 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
I have read draft-ietf-tcpm-rack-09 in preparation for TCPM to publish
this document, and do have some comments. I note that this new rev is
much easier to read this time, so thanks for the significant work to
produce a clear spec, and I see also that you have already addressed my
major concerns - thanks. (I'll separately catch a set of minor editorial
notes on this rev).
Thank you for the review!
=C2=A0

(1) I don=E2=80=99t understand this clause:
=E2=80=9C=C2=A0 3.=C2=A0 The RACK reordering window SHOULD leve= rage that to adaptively
estimate the duration of reordering events, if the receiver uses=C2=A0
Duplicate Selective Acknowledgement (DSACK) [RFC2883].=E2=80=9D=
- What does =E2=80=9Cleverage that=E2=80=9D actually mean?
- Might it mean something like: can be increased if the sender receives
a Duplicate Selective Acknowledgement (DSACK) [RFC2883], that suggests
the window is too small, and has resulted in spurious retransmission." =E2=80=A6
or does it mean something different?
It means exactly what you said :-)

Here is the latest rev based on Theresa' suggestion:
"The RACK reordering window SHOULD adaptively increase if t= he sender receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883= ], suggesting the window is too small which causes spurious retransmission.= "

Let me know if that's better?

WFM.

=C2=A0

(2) I did not understand this part in Section 3.3:
=E2=80=9CHowever, the fact that the initial reordering window i= s low, and the
=C2=A0=C2=A0=C2=A0 reordering window's adaptive growth is b= ounded, means that there will
=C2=A0=C2=A0=C2=A0 continue to be a cost to reordering to disin= centivize excessive
=C2=A0=C2=A0=C2=A0 network reordering over highly disjoint path= s.=C2=A0 For such networks
=C2=A0=C2=A0=C2=A0 there are good alternative solutions, such a= s MPTCP.=E2=80=9C
- Is this intended to read as /reordering that disincentivizes excessive/
- If that was intended, the spec appears to be for a single path, MPTCP
would still view this path with reordering as a single path, so I do not
understand how MPTCP helps unless the awareness of the disjoint paths is
somehow known at the endpoints? Please explain.

- (You=E2=80=99d need a REF for MPTCP if you keep this senetnce= and the
explanation).
Yes that's the intention. Will removing the last sentenc= e (about MPTCP) help?
=C2=A0

That would be an easy fix that would WFM.


(3)
=C2=A0=C2=A0Question in Section 7.4.2.
/If the TLP
=C2=A0=C2=A0=C2=A0 sender does not receive such an indication, = then it SHOULD assume
=C2=A0=C2=A0=C2=A0 that either the original data segment or the= TLP retransmission were
=C2=A0=C2=A0=C2=A0 lost, for congestion control purposes./
- Why is this not a MUST?
- Under what conditions would it be safe to ignore a SHOULD?
We use SHOULD because the ACK could be lost instead of the data, so if the sender has some mechanism to detect ACK losses well, it may be safe not to assume data was lost.

But I agree this is over-thinking the corner cases so how about

If the TLP = sender does not receive such an indication, then it MUST assume that= either the original data segment, or the TLP retransmission were lost, = or their ACKs are lost for congestion control purposes.

=C2=A0

I think the new text reads as safer to me.


(4) in Section 6.2. I was also left with a potential concern about
=E2=80=9Cmin_RTT=E2=80=9D with respect to =E2=80=9Ca simple glo= bal minimum of all RTT
measurements from the connection=E2=80=9D.=C2=A0 This method re= sults in a significant
path change from low to high RTT exhibiting an invalid RTT. Even a
simple windowed min-filtered estimate - mentioned here - would avoid
this effect on reordering detection.

- I=E2=80=99d prefer adding a short sentence=C2=A0 so people kn= ow why the updates to
min_RTT might be useful.
Good point. (some) windowed-filter is definitely prefered. how about:

The sender SHOULD track a windowed min-filtered estimate of recent RTT= measurements to adapt migrating to significant longer paths, compared to a= simple global minimum of all RTT measurements.


I like that proposed text. I don't think teh method has to be sophisticated, but some method seems the right thing to do.

(5) In section 8.1, I expected more discussion of the potential
disadvantages (even if the authors seem to suggest these are not
significant) :

* I still was left without understanding whether there is an impact from
a path with a varying RTT (perhaps one that uses a link layer
retransmission or access technology). My feeling is that if there is
excessive variation the method could go wrong when the RTT increases,
but I wonder if this is usually captured by inflating the SRTT and that
more excessive variation is not common. I think this case should be
discussed briefly.
AFAIU the scenario you are referring is when the link-layer retransmitted packets took a much longer > current SRTT to be delivered.
Yes.
Then RACK reordering window (and its=C2=A0SRTT-bound) requires=C2=A0DSACK and new RTT measurement to raise to capture this variation. Depending on the RTT variation, it may take multiple round trips to adapt to. The idea is for short flows, RACK may not be able to cope with it (and we welcome any simple idea to improve that).
Understood.
For long flows, RACK should eventually adapt to these high varying RTT. Hence we've tested RACK with high varying degree of reordering (in time) in synthetic benchmarks. In production experiments, we have not found such high variation too common tho: the wireless radio does not alter its transmission rate too often or change its retry count dynamically. But of course, we try to avoid any mention of "empirical case frequency" :-)

It that addresses your question, we can add some words in the reordering design rationale about this.

I think a few words would help - just so that if the corner case is encountered people understand there was a tradeoff.

Sure -- how about adding this right after the reord= ering window rules in the 'reordering window adaptation section'

...
2. The RACK reordering window SHOULD adaptively in= crease if the sender receives the Duplicate Selective Acknowledgement (DSAC= K) [RFC2883], suggesting the window is too small which causes spurious retr= ansmission.

3. The RACK reordering window MUST be bounded and this bound SHOULD be SR= TT.

<new> The rule 2 and 3 com= bined are required to adapt reordering caused by extended link layer recove= ry time described earlier. Then the reordering window (and its=C2=A0SRTT-bo= und) requires=C2=A0DSACK and new RTT measurement to increase. Depend= ing on the RTT variation, it may take multiple round trips to adapt. </new>For short flows,= the low initial reordering window is key to recover quickly by risking spu= rious retransmissions. The rationale is that spurious retransmissions for s= hort flows are not expected to produce excessive network traffic additional= ly. For long flows the design tolerates reordering within a round trip. Thi= s handles reordering caused by path divergence in small time scales (reorde= ring within the round-trip time of the shortest path).
=C2=A0

* As I read it, RACK can also send more retransmissions after there has
been loss, where it is making spurious retransmissions - from timer
events, or as a result of multiple segments from a single TSO segment
being retransmitted. While it seems to be argued these are not
significant, it could none the less a disadvantage in some scenarios,
and should be captured in section 8.1.
The first case spurious RACK timer expiration is possible. So we can append to the end of 8.1 with
"Another disadvantage is the reordering timer may expir= e prematurely (like any other retransmission timer) to cause higher spurious retransmission especially if DSACK is not supported".

That would be fine for me.
However RACK should not cause extra spurious retransmission with TSO (vs non-TSO) as a loss detection algorithm. Perhaps some text in TSO was not clear on this?=C2= =A0
=C2=A0

* Also there seem cases where RACK allows TCP to continue to increase
the congestion window upon receiving ACKs after loss, making the sender
more aggressive. This is noted in 8.3, but I think should be listed in
the disadvantages in 8.1.
Section 8.3 clearly states RACK can make C.C. more aggressive. Disadvantage or not depends on how one looks at=C2= =A0 it. IMO really beyond the scope of this doc.
=C2=A0

:-)

Indeed, how you view this will depend on what is regarded as best. I think it's kind of obvious there might be CC implications= , maybe there is no need to discuss that.


(6) Section 8.4 talks about ACK loss or a delayed ACK without a DSACK,
but does not mention Stretch ACKs, which have also been experienced, and
need some form of mention!
There are two kinds of stretched=C2=A0ACKs I knew of: (a) AC= Ks delayed by the receiver in hope to accumulate more.=C2=A0 (b) ACKs "compressed" or decimated by the receiver or middle-boxes.
It's the former (a) that affects RACK so we use delayed ACK in the general delayed stretched ACK form.
=C2=A0
So, on this I think any stretch ACK caused by ACK delay, loss in the network, or intentional dropping has the same effect of extending the period it takes for the endpoint to observe the ACK. The typical stretch ACK intervals seem to me to be a few packets, so I am not sure typically this creates an issue for RACK, but if ACK delay is mentioned I don't understand why stretch ACKs from other cases are also not equally mentioned?
ok thanks for cl= arification. I propose we change to

Delayed or str= etched ACKs complicate the detection of repairs done by TLP, since with= such ACKs the sender takes longer time to receive fewer ACKs than w= ould normally be expected.

<= span style=3D"font-size:9pt;font-family:Verdana;color:rgb(0,0,0);background= -color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm= al;vertical-align:baseline;white-space:pre-wrap">

(7) Why isn't TCP-NCR (RFC4653) at least mentioned and discussed in the
intro?

The existing discussion is fine (thanks), I did not see the RFC listed in the References!
Thanks for catchin= g that. Will fix it. and double check if there're missing refs. Probabl= y another bug in our google-doc to rfc xml conversion script...

Gorry


Best wishes,

Gorry

--000000000000422d4b05ad44e68e-- From nobody Thu Aug 20 00:28: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 2198B3A096B for ; Thu, 20 Aug 2020 00:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 GSBYEhNoK7_k for ; Thu, 20 Aug 2020 00:28:37 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF0F3A08B6 for ; Thu, 20 Aug 2020 00:28:36 -0700 (PDT) Received: from Gs-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 936841B000DF; Thu, 20 Aug 2020 08:28:32 +0100 (BST) To: Yuchung Cheng Cc: tcpm IETF list References: <227bfb55-a2b4-37f0-9802-ddc76b22fa91@erg.abdn.ac.uk> From: Gorry Fairhurst Message-ID: Date: Thu, 20 Aug 2020 08:28:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------30A4A919E9279A13245C1CFE" Content-Language: en-GB Archived-At: Subject: Re: [tcpm] A review for draft-ietf-tcpm-rack-09 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, 20 Aug 2020 07:28:41 -0000 This is a multi-part message in MIME format. --------------30A4A919E9279A13245C1CFE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Please see again below, it looks like this answered my questions. On 20/08/2020 02:17, Yuchung Cheng wrote: > > > On Wed, Aug 19, 2020 at 12:27 AM Gorry Fairhurst > wrote: > > See below. > > On 18/08/2020 21:28, Yuchung Cheng wrote: >> >> >> On Tue, Aug 18, 2020 at 6:42 AM Gorry Fairhurst >> > wrote: >> >> I have read draft-ietf-tcpm-rack-09 in preparation for TCPM >> to publish >> this document, and do have some comments. I note that this >> new rev is >> much easier to read this time, so thanks for the significant >> work to >> produce a clear spec, and I see also that you have already >> addressed my >> major concerns - thanks. (I'll separately catch a set of >> minor editorial >> notes on this rev). >> >> Thank you for the review! >> >> >> (1) I don’t understand this clause: >> “  3.  The RACK reordering window SHOULD leverage that to >> adaptively >> estimate the duration of reordering events, if the receiver uses >> Duplicate Selective Acknowledgement (DSACK) [RFC2883].” >> - What does “leverage that” actually mean? >> - Might it mean something like: can be increased if the >> sender receives >> a Duplicate Selective Acknowledgement (DSACK) [RFC2883], that >> suggests >> the window is too small, and has resulted in spurious >> retransmission." … >> or does it mean something different? >> >> It means exactly what you said :-) >> >> Here is the latest rev based on Theresa' suggestion: >> "The RACK reordering window SHOULD adaptively increase if the >> sender receives the Duplicate Selective Acknowledgement (DSACK) >> [RFC2883], suggesting the window is too small which causes >> spurious retransmission." >> >> Let me know if that's better? >> > WFM. >> >> >> (2) I did not understand this part in Section 3.3: >> “However, the fact that the initial reordering window is low, >> and the >>     reordering window's adaptive growth is bounded, means >> that there will >>     continue to be a cost to reordering to disincentivize >> excessive >>     network reordering over highly disjoint paths.  For such >> networks >>     there are good alternative solutions, such as MPTCP.“ >> - Is this intended to read as /reordering that >> disincentivizes excessive/ >> - If that was intended, the spec appears to be for a single >> path, MPTCP >> would still view this path with reordering as a single path, >> so I do not >> understand how MPTCP helps unless the awareness of the >> disjoint paths is >> somehow known at the endpoints? Please explain. >> >> - (You’d need a REF for MPTCP if you keep this senetnce and the >> explanation). >> >> Yes that's the intention. Will removing the last sentence (about >> MPTCP) help? >> > That would be an easy fix that would WFM. > >> >> (3) >>   Question in Section 7.4.2. >> /If the TLP >>     sender does not receive such an indication, then it >> SHOULD assume >>     that either the original data segment or the TLP >> retransmission were >>     lost, for congestion control purposes./ >> - Why is this not a MUST? >> - Under what conditions would it be safe to ignore a SHOULD? >> >> We use SHOULD because the ACK could be lost instead of the data, >> so if the sender has some mechanism to detect ACK losses well, it >> may be safe not to assume data was lost. >> >> But I agree this is over-thinking the corner cases so how about >> >> If the TLP sender does not receive such an indication, then it >> *MUST* assume that either the original data segment, or the TLP >> retransmission were lost*, or their ACKs* are lost for congestion >> control purposes. >> > I think the new text reads as safer to me. > >> >> (4) in Section 6.2. I was also left with a potential concern >> about >> “min_RTT” with respect to “a simple global minimum of all RTT >> measurements from the connection”.  This method results in a >> significant >> path change from low to high RTT exhibiting an invalid RTT. >> Even a >> simple windowed min-filtered estimate - mentioned here - >> would avoid >> this effect on reordering detection. >> >> - I’d prefer adding a short sentence  so people know why the >> updates to >> min_RTT might be useful. >> >> Good point. (some) windowed-filter is definitely prefered. how about: >> >> The sender SHOULD tracka windowed min-filtered estimate of recent >> RTT measurements to adapt migrating to significant longer paths, >> compared to a simple global minimum of all RTT measurements. >> >> > I like that proposed text. I don't think teh method has to be > sophisticated, but some method seems the right thing to do. >> >> >> (5) In section 8.1, I expected more discussion of the potential >> disadvantages (even if the authors seem to suggest these are not >> significant) : >> >> * I still was left without understanding whether there is an >> impact from >> a path with a varying RTT (perhaps one that uses a link layer >> retransmission or access technology). My feeling is that if >> there is >> excessive variation the method could go wrong when the RTT >> increases, >> but I wonder if this is usually captured by inflating the >> SRTT and that >> more excessive variation is not common. I think this case >> should be >> discussed briefly. >> >> AFAIU the scenario you are referring is when the link-layer >> retransmitted packets took a much longer > current SRTT to be >> delivered. > Yes. >> Then RACK reordering window (and its SRTT-bound) requires DSACK >> and new RTT measurement to raise to capture this variation. >> Depending on the RTT variation, it may take multiple round trips >> to adapt to. The idea is for short flows, RACK may not be able to >> cope with it (and we welcome any simple idea to improve that). > Understood. >> For long flows, RACK should eventually adapt to these high >> varying RTT. Hence we've tested RACK with high varying degree of >> reordering (in time) in synthetic benchmarks. In production >> experiments, we have not found such high variation too common >> tho: the wireless radio does not alter its transmission rate too >> often or change its retry count dynamically. But of course, we >> try to avoid any mention of "empirical case frequency" :-) >> >> It that addresses your question, we can add some words in the >> reordering design rationale about this. >> > I think a few words would help - just so that if the corner case > is encountered people understand there was a tradeoff. > > > Sure -- how about adding this right after the reordering window rules > in the 'reordering window adaptation section' > > ... > 2. The RACK reordering window SHOULD adaptively increase if the sender > receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883], > suggesting the window is too small which causes spurious retransmission. > 3. The RACK reordering window MUST be bounded and this bound SHOULD be > SRTT. > > *The rule 2 and 3 combined are required to adapt reordering > caused by extended link layer recovery time described earlier. Then > the reordering window (and its SRTT-bound) requires DSACK and new RTT > measurement to increase. Depending on the RTT variation, it may take > multiple round trips to adapt. * > For short flows, the low initial reordering window is key to recover > quickly by risking spurious retransmissions. The rationale is that > spurious retransmissions for short flows are not expected to produce > excessive network traffic additionally. For long flows the design > tolerates reordering within a round trip. This handles reordering > caused by path divergence in small time scales (reordering within the > round-trip time of the shortest path). > I think you have experience here, so I'd expect you to write the correct thing. From my side this looks like it addresses my comment. > >> >> * As I read it, RACK can also send more retransmissions after >> there has >> been loss, where it is making spurious retransmissions - from >> timer >> events, or as a result of multiple segments from a single TSO >> segment >> being retransmitted. While it seems to be argued these are not >> significant, it could none the less a disadvantage in some >> scenarios, >> and should be captured in section 8.1. >> >> The first case spurious RACK timer expiration is possible. So we >> can append to the end of 8.1 with >> "Another disadvantage is the reordering timer may expire >> prematurely (like any other retransmission timer) to cause higher >> spurious retransmission especially if DSACK is not supported". >> > That would be fine for me. >> However RACK should not cause extra spurious retransmission with >> TSO (vs non-TSO) as a loss detection algorithm. Perhaps some text >> in TSO was not clear on this? >> >> >> * Also there seem cases where RACK allows TCP to continue to >> increase >> the congestion window upon receiving ACKs after loss, making >> the sender >> more aggressive. This is noted in 8.3, but I think should be >> listed in >> the disadvantages in 8.1. >> >> Section 8.3 clearly states RACK can make C.C. more aggressive. >> Disadvantage or not depends on how one looks at  it. IMO really >> beyond the scope of this doc. > > :-) > > Indeed, how you view this will depend on what is regarded as best. > I think it's kind of obvious there might be CC implications, maybe > there is no need to discuss that. > >> >> (6) Section 8.4 talks about ACK loss or a delayed ACK without >> a DSACK, >> but does not mention Stretch ACKs, which have also been >> experienced, and >> need some form of mention! >> >> There are two kinds of stretched ACKs I knew of: (a) ACKs delayed >> by the receiver in hope to accumulate more.  (b) ACKs >> "compressed" or decimated by the receiver or middle-boxes. >> It's the former (a) that affects RACK so we use delayed ACK in >> the general delayed stretched ACK form. > So, on this I think any stretch ACK caused by ACK delay, loss in > the network, or intentional dropping has the same effect of > extending the period it takes for the endpoint to observe the ACK. > The typical stretch ACK intervals seem to me to be a few packets, > so I am not sure typically this creates an issue for RACK, but if > ACK delay is mentioned I don't understand why stretch ACKs from > other cases are also not equally mentioned? > > ok thanks for clarification. I propose we change to > > Delayed *or stretched ACKs *complicate the detection of repairs done > by TLP, since with such ACKs the sender *takes longer time to receive > fewer ACKs *than would normally be expected. This seems to address my comment :-). > >> >> (7) Why isn't TCP-NCR (RFC4653) at least mentioned and >> discussed in the >> intro? >> >> It is briefly mentioned in >> https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-2.2 and >> discussed a bit more in >> https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-8.2 >> > The existing discussion is fine (thanks), I did not see the RFC > listed in the References! > > Thanks for catching that. Will fix it. and double check if there're > missing refs. Probably another bug in our google-doc to rfc xml > conversion script... > >> >> Gorry >> >> > Best wishes, > > Gorry > Thanks, Gorry -- G. Fairhurst, School of Engineering --------------30A4A919E9279A13245C1CFE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Please see again below, it looks like this answered my questions.

On 20/08/2020 02:17, Yuchung Cheng wrote:


On Wed, Aug 19, 2020 at 12:27 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:

See below.

On 18/08/2020 21:28, Yuchung Cheng wrote:


On Tue, Aug 18, 2020 at 6:42 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
I have read draft-ietf-tcpm-rack-09 in preparation for TCPM to publish
this document, and do have some comments. I note that this new rev is
much easier to read this time, so thanks for the significant work to
produce a clear spec, and I see also that you have already addressed my
major concerns - thanks. (I'll separately catch a set of minor editorial
notes on this rev).
Thank you for the review!
 

(1) I don’t understand this clause:
“  3.  The RACK reordering window SHOULD leverage that to adaptively
estimate the duration of reordering events, if the receiver uses 
Duplicate Selective Acknowledgement (DSACK) [RFC2883].”
- What does “leverage that” actually mean?
- Might it mean something like: can be increased if the sender receives
a Duplicate Selective Acknowledgement (DSACK) [RFC2883], that suggests
the window is too small, and has resulted in spurious retransmission." …
or does it mean something different?
It means exactly what you said :-)

Here is the latest rev based on Theresa' suggestion:
"The RACK reordering window SHOULD adaptively increase if the sender receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883], suggesting the window is too small which causes spurious retransmission."

Let me know if that's better?

WFM.

 

(2) I did not understand this part in Section 3.3:
“However, the fact that the initial reordering window is low, and the
    reordering window's adaptive growth is bounded, means that there will
    continue to be a cost to reordering to disincentivize excessive
    network reordering over highly disjoint paths.  For such networks
    there are good alternative solutions, such as MPTCP.“
- Is this intended to read as /reordering that disincentivizes excessive/
- If that was intended, the spec appears to be for a single path, MPTCP
would still view this path with reordering as a single path, so I do not
understand how MPTCP helps unless the awareness of the disjoint paths is
somehow known at the endpoints? Please explain.

- (You’d need a REF for MPTCP if you keep this senetnce and the
explanation).
Yes that's the intention. Will removing the last sentence (about MPTCP) help?
 

That would be an easy fix that would WFM.


(3)
  Question in Section 7.4.2.
/If the TLP
    sender does not receive such an indication, then it SHOULD assume
    that either the original data segment or the TLP retransmission were
    lost, for congestion control purposes./
- Why is this not a MUST?
- Under what conditions would it be safe to ignore a SHOULD?
We use SHOULD because the ACK could be lost instead of the data, so if the sender has some mechanism to detect ACK losses well, it may be safe not to assume data was lost.

But I agree this is over-thinking the corner cases so how about

If the TLP sender does not receive such an indication, then it MUST assume that either the original data segment, or the TLP retransmission were lost, or their ACKs are lost for congestion control purposes.

 

I think the new text reads as safer to me.


(4) in Section 6.2. I was also left with a potential concern about
“min_RTT” with respect to “a simple global minimum of all RTT
measurements from the connection”.  This method results in a significant
path change from low to high RTT exhibiting an invalid RTT. Even a
simple windowed min-filtered estimate - mentioned here - would avoid
this effect on reordering detection.

- I’d prefer adding a short sentence  so people know why the updates to
min_RTT might be useful.
Good point. (some) windowed-filter is definitely prefered. how about:

The sender SHOULD track a windowed min-filtered estimate of recent RTT measurements to adapt migrating to significant longer paths, compared to a simple global minimum of all RTT measurements.


I like that proposed text. I don't think teh method has to be sophisticated, but some method seems the right thing to do.

(5) In section 8.1, I expected more discussion of the potential
disadvantages (even if the authors seem to suggest these are not
significant) :

* I still was left without understanding whether there is an impact from
a path with a varying RTT (perhaps one that uses a link layer
retransmission or access technology). My feeling is that if there is
excessive variation the method could go wrong when the RTT increases,
but I wonder if this is usually captured by inflating the SRTT and that
more excessive variation is not common. I think this case should be
discussed briefly.
AFAIU the scenario you are referring is when the link-layer retransmitted packets took a much longer > current SRTT to be delivered.
Yes.
Then RACK reordering window (and its SRTT-bound) requires DSACK and new RTT measurement to raise to capture this variation. Depending on the RTT variation, it may take multiple round trips to adapt to. The idea is for short flows, RACK may not be able to cope with it (and we welcome any simple idea to improve that).
Understood.
For long flows, RACK should eventually adapt to these high varying RTT. Hence we've tested RACK with high varying degree of reordering (in time) in synthetic benchmarks. In production experiments, we have not found such high variation too common tho: the wireless radio does not alter its transmission rate too often or change its retry count dynamically. But of course, we try to avoid any mention of "empirical case frequency" :-)

It that addresses your question, we can add some words in the reordering design rationale about this.

I think a few words would help - just so that if the corner case is encountered people understand there was a tradeoff.

Sure -- how about adding this right after the reordering window rules in the 'reordering window adaptation section'

...
2. The RACK reordering window SHOULD adaptively increase if the sender receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883], suggesting the window is too small which causes spurious retransmission.
3. The RACK reordering window MUST be bounded and this bound SHOULD be SRTT.

<new> The rule 2 and 3 combined are required to adapt reordering caused by extended link layer recovery time described earlier. Then the reordering window (and its SRTT-bound) requires DSACK and new RTT measurement to increase. Depending on the RTT variation, it may take multiple round trips to adapt. </new>

For short flows, the low initial reordering window is key to recover quickly by risking spurious retransmissions. The rationale is that spurious retransmissions for short flows are not expected to produce excessive network traffic additionally. For long flows the design tolerates reordering within a round trip. This handles reordering caused by path divergence in small time scales (reordering within the round-trip time of the shortest path).
 
I think you have experience here, so I'd expect you to write the correct thing. From my side this looks like it addresses my comment.

* As I read it, RACK can also send more retransmissions after there has
been loss, where it is making spurious retransmissions - from timer
events, or as a result of multiple segments from a single TSO segment
being retransmitted. While it seems to be argued these are not
significant, it could none the less a disadvantage in some scenarios,
and should be captured in section 8.1.
The first case spurious RACK timer expiration is possible. So we can append to the end of 8.1 with
"Another disadvantage is the reordering timer may expire prematurely (like any other retransmission timer) to cause higher spurious retransmission especially if DSACK is not supported".

That would be fine for me.
However RACK should not cause extra spurious retransmission with TSO (vs non-TSO) as a loss detection algorithm. Perhaps some text in TSO was not clear on this? 
 

* Also there seem cases where RACK allows TCP to continue to increase
the congestion window upon receiving ACKs after loss, making the sender
more aggressive. This is noted in 8.3, but I think should be listed in
the disadvantages in 8.1.
Section 8.3 clearly states RACK can make C.C. more aggressive. Disadvantage or not depends on how one looks at  it. IMO really beyond the scope of this doc.
 

:-)

Indeed, how you view this will depend on what is regarded as best. I think it's kind of obvious there might be CC implications, maybe there is no need to discuss that.


(6) Section 8.4 talks about ACK loss or a delayed ACK without a DSACK,
but does not mention Stretch ACKs, which have also been experienced, and
need some form of mention!
There are two kinds of stretched ACKs I knew of: (a) ACKs delayed by the receiver in hope to accumulate more.  (b) ACKs "compressed" or decimated by the receiver or middle-boxes.
It's the former (a) that affects RACK so we use delayed ACK in the general delayed stretched ACK form.
 
So, on this I think any stretch ACK caused by ACK delay, loss in the network, or intentional dropping has the same effect of extending the period it takes for the endpoint to observe the ACK. The typical stretch ACK intervals seem to me to be a few packets, so I am not sure typically this creates an issue for RACK, but if ACK delay is mentioned I don't understand why stretch ACKs from other cases are also not equally mentioned?
ok thanks for clarification. I propose we change to

Delayed or stretched ACKs complicate the detection of repairs done by TLP, since with such ACKs the sender takes longer time to receive fewer ACKs than would normally be expected.
This seems to address my comment :-).

(7) Why isn't TCP-NCR (RFC4653) at least mentioned and discussed in the
intro?

The existing discussion is fine (thanks), I did not see the RFC listed in the References!
Thanks for catching that. Will fix it. and double check if there're missing refs. Probably another bug in our google-doc to rfc xml conversion script...

Gorry


Best wishes,

Gorry

Thanks,

Gorry

-- 
G. Fairhurst, School of Engineering
--------------30A4A919E9279A13245C1CFE-- From nobody Thu Aug 20 13:08: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 306953A13EB for ; Thu, 20 Aug 2020 13:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 guXeGLipOE8x for ; Thu, 20 Aug 2020 13:08:31 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 4FBE23A13E9 for ; Thu, 20 Aug 2020 13:08:31 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id u15so952682uau.10 for ; Thu, 20 Aug 2020 13:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qhRou3qf3Wux7u/lUsRk3stFDW+03PIbHyXZzLdP3zE=; b=WaOi2sfHXBoGVU/7qrVhzsPjh+wih8cDEUI0kp4wWYUUf2AUSbm8nAlgT3LeQqpZ/K +l283mRFR0JBxnvz3IdQp6YRTB89TkR/h/TcxGRb1DfU2sUCQr6YSoErYYyYd0h0Xx3B Qc2z5cl2x7XmEwArD699EDICgA4C1fHWNDRmsg3G0uGo95CD84uO1la5rJNUWe5yPH49 VcQ8fUBsEQhFaU2zIjKdnrsiDBWZAvRq3WW0qDsbAC8pRbGK+ceAtmB44LQBoJLdc4KQ WYDhCUjJpmy7X9eB7BmPX7KA0uZ8sZPNDFt16EKf69dgqUzIc7tYEAGTlbVgIfYeXv7Y qdqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qhRou3qf3Wux7u/lUsRk3stFDW+03PIbHyXZzLdP3zE=; b=FBQKFrYateKhCWBW0a4FoO1MA+vW1bGqqUggIrfWcpw3mClrCdDR8nnK3MWD4rEA8F 9PpIZr0XefWUN94+vozMiMycfCQdvOwa3Zjf9izFRe2pRwZeam5EyG2pjFgoM+xGax8e 4as8dTxB3yOiU+6TZ4dIWMokqvzXnVExE0GdmN8vTIHFQAO2rjIA+NFPDDOgQArF+3x+ h7t3vvRnPYwK9CpSVTPPC+G73rlHgybQ4M6nzWPkFt0ZIwBXg8lRLIL6CMVXXzQLtkLG KT/R+f4moUpEpSHBnTr1/jf9qFwOcFFXsWOwQOGP43TaNfGeKCvzWprsE3hz3Khvh6CR ciOQ== X-Gm-Message-State: AOAM533fIkB+HAMG1I0qD9Zo/suMc4yprEUFd2frf+J46/hxVzfTo8NX z92pFXhLO4sq5mzbO1SxGI/WliDbKAP0rS9d0rbBKXXVVow= X-Google-Smtp-Source: ABdhPJxK4378Hvc/c3F1CNdg9oacFaz6soD/nr2qcybL59lwApwMIDDcaKkNfhXSSsHsiQilRHL2adAuubXBw+usaMw= X-Received: by 2002:ab0:164f:: with SMTP id l15mr290022uae.112.1597954109999; Thu, 20 Aug 2020 13:08:29 -0700 (PDT) MIME-Version: 1.0 References: <202008181444.07IEiqLm065473@gndrsh.dnsmgr.net> In-Reply-To: <202008181444.07IEiqLm065473@gndrsh.dnsmgr.net> From: Yuchung Cheng Date: Thu, 20 Aug 2020 13:07:53 -0700 Message-ID: To: "Rodney W. Grimes" Cc: Gorry Fairhurst , tcpm IETF list Content-Type: multipart/alternative; boundary="00000000000018847205ad54af96" Archived-At: Subject: Re: [tcpm] Editorial comments for draft-ietf-tcpm-rack-09: 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, 20 Aug 2020 20:08:34 -0000 --00000000000018847205ad54af96 Content-Type: text/plain; charset="UTF-8" Thank you Rodney and Gorry, We'll incorporate all your suggestions except two things: 1. RACK reordering can persist up to 16 loss recovery episodes, not 16 packet losses. This is an important difference because a loss recovery episode (i.e. from a Fast or RTO recovery started till all the holes at the SND.NXT when it started are repaired) can have arbitrary amount of packet losses depending on the congestion window. 2. Sprout reference is to acknowledge a similar idea proposed from private communication with another reviewer. On Tue, Aug 18, 2020 at 7:45 AM Rodney W. Grimes wrote: > Gorry, draft authros, > Sorry to respond to a response to a draft. > One small comment inline marked [rwg] that I feel would > even further clean up the language. > > Regards, > Rod Grimes > > > I have previsously sent a few comments on draft-ietf-tcpm-rack-09? and > > this email contains only issues that I think are likely editorial, but I > > hope will help in prep of the next rev. > > > > Best wishes, > > > > Gorry > > > > --- > > > > ?Heavy congestion or traffic policers can cause retransmissions to be > > lost again.? > > - I think this is probably clear, but it might be easier if it said: > > ?Heavy congestion or traffic policers can cause the retransmitted > > packets to again be lost.? > > [rwg] To me the word "again" in either of these versions does not > add any information as this information is implied by the fact the > "retransmitted packets" are the subject of the sentence. > > Propose: "Heavy congestion or traffic policers can cause the > retransmitted packets to be lost." > > > ? > > ?To mitigate the issue, [RFC4653] adjusts DupThresh to half of the > > inflight size to tolerate higher degree of reordering.? > > - Maybe should insert /the/ or /a/ before /higher/? > > ? > > ?and widely-deployed SACK options? > > - could you please insert a REF to relevant SACK RFCs. > > ? > > ?one alternative is to > > ?? dynamically adapt DupThresh based on the FlightSize (e.g. adjusts > > ?? DUPTRESH to half of the FlightSize).? > > - should the latter part be ?(e.g., the sender adjusts the DUPTRESH to > > half of the FlightSize).? > > ? > > ?The RACK reordering window adapts to the measured duration of > > ?? reordering events, within reasonable and specific bounds in order to > > ?? disincentivize excessive reordering. ? > > - for the avoidance of possible misreading, could we remove /in order/, > > since this would still seem ti read correctly and prevent someone > > thinking about ordering issues. > > ? > > In section 3.3.2. I see some sub-items numbered within a numbered list, > > which is confusing - could bullets be used for the two sub items.? The > > list also appears to resume with ?1.? again - is this correct? > > ? > > ?The rationale is that spurious retransmissions for short flows are not > > expected to produce excessive network traffic additionally. ? > > - Does this read correctly? should it be /excessive additional network > > traffic/ > > ? > > > > Figure 1 could benefit from a caption? > > ? > > I wasn?t confused by: > > ?For cases where the reordering degree is larger > > ?? than the default DupThresh of 3 packets? > > - but elsewhere the DupThresh is discussed in terms of segments! > > ? > > /keeps a SACK scoreboard information/ > > - should this be: > > - /keeps SACK scoreboard information/ > > ? > > Section 5 interchanges segments and packets, I was not confused. Maybe > > you could just add one sentence at the start that explains this? > > ?? > > /before resetting RACK.reo_wnd/ > > - add a period at the end of the line. > > ? > > /updates its states that tracks / > > - should be: > > /updates the states that track / > > - or /state/. > > ? > > / Therefore, RACK > > ?? persists the inflated RACK.reo_wnd for only 16 loss recoveries/ > > - could be: / Therefore, RACK > > ?? persists using the inflated RACK.reo_wnd to recover up to 16 losses/ > > ? > > > > /(e.g,/ > > should be > > /(e.g.,/ > > ? > > /This segment is chosen in order to deal with the > > ?? retransmission ambiguity problem in TCP./ > > -? could we also remove /in order/, since this would still seem oi read > > correctly and prevent someone thinking about ordering issues. > > ? > > /waits for the RACK reordering window expire,/ > > - insert /to/ before /expire/. > > ? > > /just as it would > > ?? with any other ack/ > > - should this be /ACK/? > > ? > > /MUST not be retransmitted until congestion control deems this > appropriate./ > > - seems to be /MUST NOT/. > > --- > > > > /even if the congestion window is full./ > > - could this be: > > - /even if the congestion window is fully used./ > > --- > > > > 8.5 mentions Sprout - which to me seems a spurious and unecessary > > reference? However, I really think the WG should have mentioned the > > previously proposed reordering protection in TCP-NCR (RFC4653) > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > -- > Rod Grimes > rgrimes@freebsd.org > --00000000000018847205ad54af96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Rodney and Gorry,

We'll i= ncorporate=C2=A0all your suggestions except two things:
1. RACK r= eordering can=C2=A0persist=C2=A0up to 16 loss recovery episodes, not 16 pac= ket losses. This is an important difference because a loss recovery episode= (i.e. from a Fast or RTO recovery started till all the holes at the SND.NX= T=C2=A0when it started are repaired) can have arbitrary amount of packet lo= sses depending on the congestion window.

2. Sprout= reference is to acknowledge a similar idea proposed from private=C2=A0comm= unication with another reviewer.


On Tue, Aug 18, 2020= at 7:45 AM Rodney W. Grimes <= ietf@gndrsh.dnsmgr.net> wrote:
Gorry, draft authros,
=C2=A0 Sorry to respond to a response to a draft.
=C2=A0 One small comment inline marked [rwg] that I feel would
=C2=A0 even further clean up the language.

Regards,
Rod Grimes

> I have previsously sent a few comments on draft-ietf-tcpm-rack-09? and=
> this email contains only issues that I think are likely editorial, but= I
> hope will help in prep of the next rev.
>
> Best wishes,
>
> Gorry
>
> ---
>
> ?Heavy congestion or traffic policers can cause retransmissions to be =
> lost again.?
> - I think this is probably clear, but it might be easier if it said: > ?Heavy congestion or traffic policers can cause the retransmitted
> packets to again be lost.?

=C2=A0[rwg] To me the word "again" in either of these versions do= es not
=C2=A0add any information as this information is implied by the fact the =C2=A0"retransmitted packets" are the subject of the sentence.
=C2=A0Propose:=C2=A0 "Heavy congestion or traffic policers can cause t= he
=C2=A0retransmitted packets to be lost."

> ?
> ?To mitigate the issue, [RFC4653] adjusts DupThresh to half of the > inflight size to tolerate higher degree of reordering.?
> - Maybe should insert /the/ or /a/ before /higher/?
> ?
> ?and widely-deployed SACK options?
> - could you please insert a REF to relevant SACK RFCs.
> ?
> ?one alternative is to
>=C2=A0 ?? dynamically adapt DupThresh based on the FlightSize (e.g. adj= usts
>=C2=A0 ?? DUPTRESH to half of the FlightSize).?
> - should the latter part be ?(e.g., the sender adjusts the DUPTRESH to=
> half of the FlightSize).?
> ?
> ?The RACK reordering window adapts to the measured duration of
>=C2=A0 ?? reordering events, within reasonable and specific bounds in o= rder to
>=C2=A0 ?? disincentivize excessive reordering. ?
> - for the avoidance of possible misreading, could we remove /in order/= ,
> since this would still seem ti read correctly and prevent someone
> thinking about ordering issues.
> ?
> In section 3.3.2. I see some sub-items numbered within a numbered list= ,
> which is confusing - could bullets be used for the two sub items.? The=
> list also appears to resume with ?1.? again - is this correct?
> ?
> ?The rationale is that spurious retransmissions for short flows are no= t
> expected to produce excessive network traffic additionally. ?
> - Does this read correctly? should it be /excessive additional network=
> traffic/
> ?
>
> Figure 1 could benefit from a caption?
> ?
> I wasn?t confused by:
> ?For cases where the reordering degree is larger
>=C2=A0 ?? than the default DupThresh of 3 packets?
> - but elsewhere the DupThresh is discussed in terms of segments!
> ?
> /keeps a SACK scoreboard information/
> - should this be:
> - /keeps SACK scoreboard information/
> ?
> Section 5 interchanges segments and packets, I was not confused. Maybe=
> you could just add one sentence at the start that explains this?
> ??
> /before resetting RACK.reo_wnd/
> - add a period at the end of the line.
> ?
> /updates its states that tracks /
> - should be:
> /updates the states that track /
> - or /state/.
> ?
> / Therefore, RACK
>=C2=A0 ?? persists the inflated RACK.reo_wnd for only 16 loss recoverie= s/
> - could be: / Therefore, RACK
>=C2=A0 ?? persists using the inflated RACK.reo_wnd to recover up to 16 = losses/
> ?
>
> /(e.g,/
> should be
> /(e.g.,/
> ?
> /This segment is chosen in order to deal with the
>=C2=A0 ?? retransmission ambiguity problem in TCP./
> -? could we also remove /in order/, since this would still seem oi rea= d
> correctly and prevent someone thinking about ordering issues.
> ?
> /waits for the RACK reordering window expire,/
> - insert /to/ before /expire/.
> ?
> /just as it would
>=C2=A0 ?? with any other ack/
> - should this be /ACK/?
> ?
> /MUST not be retransmitted until congestion control deems this appropr= iate./
> - seems to be /MUST NOT/.
> ---
>
> /even if the congestion window is full./
> - could this be:
> - /even if the congestion window is fully used./
> ---
>
> 8.5 mentions Sprout - which to me seems a spurious and unecessary
> reference? However, I really think the WG should have mentioned the > previously proposed reordering protection in TCP-NCR (RFC4653)
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
>
>

--
Rod Grimes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgrimes@freebsd.org
--00000000000018847205ad54af96-- From nobody Sat Aug 22 10:17:59 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 999C03A09BA; Sat, 22 Aug 2020 10:17:44 -0700 (PDT) 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: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <159811666456.32459.8196462226942343302@ietfa.amsl.com> Date: Sat, 22 Aug 2020 10:17:44 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-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: Sat, 22 Aug 2020 17:17:45 -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 : The RACK-TLP loss detection algorithm for TCP Authors : Yuchung Cheng Neal Cardwell Nandita Dukkipati Priyaranjan Jha Filename : draft-ietf-tcpm-rack-10.txt Pages : 30 Date : 2020-08-22 Abstract: This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgements (SACK) [RFC2018] and has two parts: RACK ("Recent ACKnowledgment") starts fast recovery quickly using time-based inferences derived from ACK feedback. TLP ("Tail Loss Probe") leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used DUPACK threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DUPACK threshold approach in [RFC5681][RFC6675]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rack-10 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-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 Sat Aug 22 10:22: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 C58433A09C0 for ; Sat, 22 Aug 2020 10:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 M_UJSk6tmM6j for ; Sat, 22 Aug 2020 10:22:16 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 9C3623A09BE for ; Sat, 22 Aug 2020 10:22:16 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id j7so1108253vkk.12 for ; Sat, 22 Aug 2020 10:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HQQu+Y9y2PFsG4qF8j1I3qrHCS1k648npBhLLICActc=; b=Yyw8Hhkp4dZ/TotTp+27w03HWe0/5XLWufnElmcB4q5pD4IfBpQge3aRD/tygBPXWU XyOf8KfUPaYiAy4ldtmq+eCf999Eo4jkauji4X6szaNeyjETddNHzryUgYylhDu160xk p+iIyMIgK/3HP93vP16ioUBnp+BAJkf8oatB/bv4itcFASeuKOi6vfFiWXfrcvZPU/P6 S1cjvM7j+TSjXsRmZyDRvptHipiCWvrp8fouHWN3qaSICxNypbpkRCFxxwdKWTzDLiu7 jNY/vDrPcuVzlkkAp5PxUA+zTLqxw6OaO3RoCfpvSJHr0fE/2pAxJt6BNiMpn4bfy81j GX4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HQQu+Y9y2PFsG4qF8j1I3qrHCS1k648npBhLLICActc=; b=GnQw3wSqqFIv98EIA9QXqID9pwhjm5AE/oltNVcOxyVXzyHEY4xFhoSQWAdMflzUVD M8/Mf+xcmy/ZaTeZT2Ufs6uMv2ar7+v4eL0rtR26EuBATRnmOO7PUsxaMa/2cTxSZd2o uIy7Ue4qskjLj7ex1wnz2D+BLH59qY7dpTcarXQqY3vZ6aylNWa0UtdMMqZINxsufkbr EPjgLgsf8CUoXoTvEwZJZu+3Hf9otpcuvZ+YULbP7wVB4rQB88kIR6vcxunJHA1rfKvG fwk7Ln8XkvPIEJA/8SBl/zk69sP1N7F6V273TapFhvBxANMWM3CZvqbkFdcMzsW5pk0v hv5A== X-Gm-Message-State: AOAM530Bx+13EcHxzEnSoWr5CNJWNmIUA18VAYSU8puw4j5bngpQhN7F wdAgrsRZo0T4HX7p3u+bj99HQ9yN/DocPvlhhOeP5RxKFbA= X-Google-Smtp-Source: ABdhPJx3DP+uYqJEIAC9loPlWsL4+lC7fA2RTX++K7IXJJL52OWenE+hsy0cssU86eAzN6mbQ4SL/JfKjZbEtFmZalE= X-Received: by 2002:a1f:a0c3:: with SMTP id j186mr4821327vke.76.1598116935071; Sat, 22 Aug 2020 10:22:15 -0700 (PDT) MIME-Version: 1.0 References: <159811666456.32459.8196462226942343302@ietfa.amsl.com> In-Reply-To: <159811666456.32459.8196462226942343302@ietfa.amsl.com> From: Yuchung Cheng Date: Sat, 22 Aug 2020 10:21:39 -0700 Message-ID: To: "tcpm@ietf.org Extensions" , Michael Tuexen , Martin Duke Content-Type: multipart/alternative; boundary="00000000000039e28605ad7a9833" Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rack-10.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: Sat, 22 Aug 2020 17:22:19 -0000 --00000000000039e28605ad7a9833 Content-Type: text/plain; charset="UTF-8" This latest version contains the editorial changes to address the recent excellent reviews from Theresa an Gorry and citation fixes. No change to the algorithm. On Sat, Aug 22, 2020 at 10:18 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the TCP Maintenance and Minor Extensions WG > of the IETF. > > Title : The RACK-TLP loss detection algorithm for TCP > Authors : Yuchung Cheng > Neal Cardwell > Nandita Dukkipati > Priyaranjan Jha > Filename : draft-ietf-tcpm-rack-10.txt > Pages : 30 > Date : 2020-08-22 > > Abstract: > This document presents the RACK-TLP loss detection algorithm for TCP. > RACK-TLP uses per-segment transmit timestamps and selective > acknowledgements (SACK) [RFC2018] and has two parts: RACK ("Recent > ACKnowledgment") starts fast recovery quickly using time-based > inferences derived from ACK feedback. TLP ("Tail Loss Probe") > leverages RACK and sends a probe packet to trigger ACK feedback to > avoid retransmission timeout (RTO) events. Compared to the widely > used DUPACK threshold approach, RACK-TLP detects losses more > efficiently when there are application-limited flights of data, lost > retransmissions, or data packet reordering events. It is intended to > be an alternative to the DUPACK threshold approach in > [RFC5681][RFC6675]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tcpm-rack-10 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-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/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00000000000039e28605ad7a9833 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This latest version contains the editorial changes to addr= ess the recent excellent reviews from Theresa an Gorry and citation fixes. = No change to the algorithm.



On Sat, Aug 22, 20= 20 at 10:18 AM <internet-dra= fts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the TCP Maintenance and Minor Extensions WG of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The RACK-TLP loss detection algorithm for TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Yuch= ung Cheng
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Neal Cardwell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nandita Dukkipati
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Priyaranjan Jha
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tcpm-rack-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-08-22

Abstract:
=C2=A0 =C2=A0This document presents the RACK-TLP loss detection algorithm f= or TCP.
=C2=A0 =C2=A0RACK-TLP uses per-segment transmit timestamps and selective =C2=A0 =C2=A0acknowledgements (SACK) [RFC2018] and has two parts: RACK (&qu= ot;Recent
=C2=A0 =C2=A0ACKnowledgment") starts fast recovery quickly using time-= based
=C2=A0 =C2=A0inferences derived from ACK feedback.=C2=A0 TLP ("Tail Lo= ss Probe")
=C2=A0 =C2=A0leverages RACK and sends a probe packet to trigger ACK feedbac= k to
=C2=A0 =C2=A0avoid retransmission timeout (RTO) events.=C2=A0 Compared to t= he widely
=C2=A0 =C2=A0used DUPACK threshold approach, RACK-TLP detects losses more =C2=A0 =C2=A0efficiently when there are application-limited flights of data= , lost
=C2=A0 =C2=A0retransmissions, or data packet reordering events.=C2=A0 It is= intended to
=C2=A0 =C2=A0be an alternative to the DUPACK threshold approach in
=C2=A0 =C2=A0[RFC5681][RFC6675].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tc= pm-rack/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-rack-= 10
https://datatracker.ietf.org/doc/html/d= raft-ietf-tcpm-rack-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-tcpm-rack-10


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--00000000000039e28605ad7a9833-- From nobody Thu Aug 27 01:16:57 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 074143A0E55 for ; Thu, 27 Aug 2020 01:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 sPRG7bWU5e2q for ; Thu, 27 Aug 2020 01:16:54 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C22C3A0E54 for ; Thu, 27 Aug 2020 01:16:54 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4BcbDN31rrz11Vp; Thu, 27 Aug 2020 10:16:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1598516212; bh=QzQI2/vQFwRIIISJr4SJOyuqBRQH0j4sWFb2/KTPxLI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=L34hYlgmKrnrp0KGcAmkv9ZSpfSf0SDwPreTFEPSv7kNgYRyuoj7QfqlZXrQ/lXOV 9ieXNdVzC35Q78FpBwJOSsU6RaqQBcti0lvIk+3otH8QbyNAfHa4JnFPqT5z6iHudw xpCcepFL9pqQUyusUlZZHFRhd4hXUoOq8fyr5I3aj/sqvofD9rxrX9iLmNS48kH406 8DMNcyftOFA8q8GXoj9b7ShHccgqg6EuLKwybgTXWIhMAKGqktNPRzQfsywFHE3roy hPdg9S+b7/lPw9RCZGb3it/cD3MMb7LPdK0yMsD05pHDeWw3g4iVSrP6AW2HTjSF0/ kioCbgH9LHWhw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 4BcbDN20p1zDqD0; Thu, 27 Aug 2020 10:16:52 +0200 (CEST) From: To: Yoshifumi Nishida , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 Thread-Index: AQHWdLhvclqiXp6SRUmghYppfRUedalLqSyw Date: Thu, 27 Aug 2020 08:16:51 +0000 Message-ID: <15680_1598516212_5F476BF4_15680_405_1_787AE7BB302AE849A7480A190F8B9330315259F8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330315259F8OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 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 Aug 2020 08:16:56 -0000 --_000_787AE7BB302AE849A7480A190F8B9330315259F8OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGlzIGlzIGEgdXNlZnVsIGRvY3VtZW50LiBJIHN1cHBvcnQgaXQuDQoNCk1p Y2hhZWwsIHBsZWFzZSB1cGRhdGUgdGhlIHRyZWUgZGlhZ3JhbSB0byBsaXN0IGFsbCB0aGUgZGF0 YSBub2Rlcy4gVGhhbmtzLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiB0Y3BtIFttYWlsdG86dGNw bS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFlvc2hpZnVtaSBOaXNoaWRhDQpFbnZv ecOpIDogbHVuZGkgMTcgYW/Du3QgMjAyMCAxOTowNA0Kw4AgOiB0Y3BtQGlldGYub3JnIEV4dGVu c2lvbnMgPHRjcG1AaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbdGNwbV0gV0cgaXRlbSBhZG9wdGlv biBmb3IgZHJhZnQtc2NoYXJmLXRjcG0teWFuZy10Y3AtMDYNCg0KSGkgZm9sa3MsDQpXZSBhcHBy ZWNpYXRlIHlvdXIgZmVlZGJhY2sgb24gdGhpcy4NCi0tDQp0Y3BtIGNvLWNoYWlycw0KDQpPbiBN b24sIEF1ZyAzLCAyMDIwIGF0IDE6MDQgQU0gWW9zaGlmdW1pIE5pc2hpZGEgPG5zZC5pZXRmQGdt YWlsLmNvbTxtYWlsdG86bnNkLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpIaSwNCg0KVGhlIGNo YWlycyBoYXMgYmVlbiBkaXNjdXNzaW5nIGhvdyB0byBwcm9jZWVkIGRyYWZ0LXNjaGFyZi10Y3Bt LXlhbmctdGNwLTA2IGFmdGVyIHRoZSBXRyBtZWV0aW5nLg0KVGhlIHJlc3VsdHMgb2YgdGhlIGh1 bSB3ZXJlIGEgYml0IHdlYWsgdG8gc2VlIGNsZWFyIGNvbnNlbnN1cyBhbHRob3VnaCB0aGVyZSB3 YXMgc2xpZ2h0bHkgc3Ryb25nIGh1bSBmb3IgYWRvcHRpb24uDQpBbHNvLCB0aGVyZSBzZWVtcyB0 byBiZSBzb21lIGNvbmZ1c2lvbnMgZHVyaW5nIHRoZSBhZG9wdGlvbiBjYWxsLiAoSSdtIHNvcnJ5 IGZvciB0aGUgY2x1bXNpbmVzcyBvZiB1c2luZyB0aGUgdG9vbCkNCkluIG9yZGVyIGZvciB0aGlz LCB3ZSB3b3VsZCBsaWtlIHRvIHNlZWsgdGhlIGFkZGl0aW9uYWwgZmVlZGJhY2sgZnJvbSB0aGUg Y29tbXVuaXR5IG9uIHRoZSBmb2xsb3dpbmcgcG9pbnRzLg0KDQoxOiBJZiB5b3Ugd2FudCB0byBh ZGQgeW91ciBodW0gdG8gdGhlIGNhbGwgYmVjYXVzZSB5b3UgZGlkbid0IGF0IHRoZSBtZWV0aW5n IGZvciBzb21lIHJlYXNvbnMgb3IgaWYgeW91IHdhbnQgdG8gY2hhbmdlIHlvdXIgaHVtLCBwbGVh c2UgbGV0IHRoZSBjaGFpcnMga25vdy4NCjI6IGlmIHlvdSBodW1tZWQgZm9yIG5vdCBhZG9wdGlu ZyB0aGUgZHJhZnQsIHBsZWFzZSBzaGFyZSB5b3VyIG9waW5pb24uIFRoaXMgd2lsbCBiZSBhIHZl cnkgaGVscGZ1bCBpbnB1dCBmb3IgdXMuDQoNCldlJ2xsIGFwcHJlY2lhdGUgeW91ciBjb29wZXJh dGlvbi4NClRoYW5rcywNCi0tDQpZb3NoaQ0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_787AE7BB302AE849A7480A190F8B9330315259F8OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5v cm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQg NzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgYWxsLA0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBpcyBhIHVzZWZ1bCBkb2N1bWVudC4gSSBzdXBw b3J0IGl0LiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+TWljaGFlbCwgcGxlYXNlIHVwZGF0ZSB0aGUgdHJlZSBkaWFncmFtIHRvIGxpc3QgYWxs IHRoZSBkYXRhIG5vZGVzLiBUaGFua3MuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHRjcG0gW21haWx0bzp0Y3BtLWJv PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+dW5jZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRl PC9iPiBZb3NoaWZ1bWkgTmlzaGlkYTxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBsdW5kaSAx NyBhb8O7dCAyMDIwIDE5OjA0PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiB0Y3BtQGlldGYub3JnIEV4 dGVuc2lvbnMgJmx0O3RjcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBS ZTogW3RjcG1dIFdHIGl0ZW0gYWRvcHRpb24gZm9yIGRyYWZ0LXNjaGFyZi10Y3BtLXlhbmctdGNw LTA2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBmb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldlIGFwcHJlY2lhdGUgeW91ciBmZWVkYmFjayBvbiB0aGlzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRjcG0gY28tY2hhaXJz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEF1 ZyAzLCAyMDIwIGF0IDE6MDQgQU0gWW9zaGlmdW1pIE5pc2hpZGEgJmx0OzxhIGhyZWY9Im1haWx0 bzpuc2QuaWV0ZkBnbWFpbC5jb20iPm5zZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgY2hhaXJzIGhhcyZuYnNwO2JlZW4gZGlzY3Vzc2luZyBob3cgdG8gcHJvY2VlZCBkcmFmdC1z Y2hhcmYtdGNwbS15YW5nLXRjcC0wNiBhZnRlciB0aGUgV0cgbWVldGluZy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZXN1bHRzIG9mIHRo ZSBodW0gd2VyZSBhIGJpdCB3ZWFrIHRvIHNlZSBjbGVhciBjb25zZW5zdXMgYWx0aG91Z2ggdGhl cmUgd2FzIHNsaWdodGx5IHN0cm9uZyBodW0gZm9yIGFkb3B0aW9uLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgdGhlcmUgc2Vl bXMgdG8gYmUgc29tZSBjb25mdXNpb25zIGR1cmluZyB0aGUgYWRvcHRpb24gY2FsbC4gKEknbSBz b3JyeSBmb3IgdGhlIGNsdW1zaW5lc3Mgb2YgdXNpbmcgdGhlIHRvb2wpPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBvcmRlciBmb3IgdGhpcywg d2Ugd291bGQgbGlrZSB0byBzZWVrIHRoZSBhZGRpdGlvbmFsJm5ic3A7ZmVlZGJhY2sgZnJvbSB0 aGUgY29tbXVuaXR5IG9uIHRoZSBmb2xsb3dpbmcgcG9pbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MTogSWYgeW91IHdhbnQg dG8gYWRkIHlvdXIgaHVtIHRvIHRoZSBjYWxsIGJlY2F1c2UgeW91IGRpZG4ndCBhdCB0aGUgbWVl dGluZyBmb3Igc29tZSByZWFzb25zIG9yIGlmIHlvdSB3YW50IHRvIGNoYW5nZSB5b3VyIGh1bSwg cGxlYXNlIGxldCB0aGUgY2hhaXJzIGtub3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yOiBpZiB5b3UgaHVtbWVkIGZvciBub3QgYWRvcHRpbmcg dGhlJm5ic3A7ZHJhZnQsIHBsZWFzZSBzaGFyZSB5b3VyIG9waW5pb24uIFRoaXMgd2lsbCBiZSBh IHZlcnkgaGVscGZ1bCBpbnB1dCBmb3IgdXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UnbGwgYXBwcmVjaWF0ZSB5 b3VyIGNvb3BlcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+WW9zaGk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo YW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B9330315259F8OPEXCAUBMA2corp_-- From nobody Thu Aug 27 23: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 0A8133A15AA for ; Thu, 27 Aug 2020 23:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpOCHb0x2Xld for ; Thu, 27 Aug 2020 23:41:51 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 57D063A15A8 for ; Thu, 27 Aug 2020 23:41:51 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id c19so173387wmd.1 for ; Thu, 27 Aug 2020 23:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fGSutUIJEifVCw1z+dkGWD0rOvR6teKe4LKSicF8bgQ=; b=eeSsNsAfuA9OMe15TnO8xcEv+FP/pBZARmdBmMWXOhYGqYpjjzWSLDHs9y/ZX6mBZr Mv49Iy/Y1hedvaP5xBRmcSSlpHq7DJEygm5ZtpZRjrayZmhFgVzRFZ3XnhFZwBL+o+eP ZH5gcP6dFrY3Fr3J+KVylmPWm/K772A6g0Fjc/7fcFlSU/SDQZ8xzuQeJaU0iENbWKl2 cndj2tPOBT7sOpKjoZLelsOoxZNY0H/wVpkW7gMokKwqFWWCNOunMtwqJ07EpwfY0NqW r3kE8vrj8iKeHPd3F1y24vifF/OR9+ueMi3cXV72d/qN+rvWgE+gMXWXwJeeiSFh3LM5 0r2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fGSutUIJEifVCw1z+dkGWD0rOvR6teKe4LKSicF8bgQ=; b=nvdEPdFtqwNtzBY0yNWhAnPSq16LGZ1R3wSVAAlG4uF42B5PKswo6x6EPfcT2w+M2Q rSOW1aqw/CJrrCNr5aSKCvbOaf321Su1QlTlC3bALtWHYP7yNmraQHzOzC6cQjEjwqCA mYLEJ8zZlUxtFmm64W9zfKMNClV9K5bLKKZOIiEAghT4VcrYAF6In+TWpuaS75bjuBa4 VQ2UQUaU8NAUvZAYIq7vB8vrfG7YwnssLjDBRIWfKazdsIkh1ybBQhX3oyuC0tkIQ1jY TxT/OPTv7+07Rn5eTjfgm61aITVT0FbOURLNHdJTT11jYlOJgn1T/fciarsviWX+bKm+ RfQQ== X-Gm-Message-State: AOAM531mPlkA/TlUZ1vn2phA4M5CqMyGfHyB/ia5O/6xZYrBLYbjWOBN SV0QLdqXrqeYiiE7/UAghAqSmJg+pJuWw4BVHIDzYKSq X-Google-Smtp-Source: ABdhPJzxG+yrvOOu/pvuWcIkGCVzNYk9H3oRcLyxXmT+AWZaMfQjtrw9kO8GXKjNL9d48vRpsi5cthxY95OjGeA1gwU= X-Received: by 2002:a05:600c:410b:: with SMTP id j11mr103180wmi.38.1598596909658; Thu, 27 Aug 2020 23:41:49 -0700 (PDT) MIME-Version: 1.0 References: <15680_1598516212_5F476BF4_15680_405_1_787AE7BB302AE849A7480A190F8B9330315259F8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <15680_1598516212_5F476BF4_15680_405_1_787AE7BB302AE849A7480A190F8B9330315259F8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Yoshifumi Nishida Date: Thu, 27 Aug 2020 23:41:38 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000f073b405adea5806" Archived-At: Subject: Re: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 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 Aug 2020 06:41:53 -0000 --000000000000f073b405adea5806 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, Thank you for the input. We'll wait a bit more and will make a decision. -- Yoshi On Thu, Aug 27, 2020 at 1:16 AM wrote: > Hi all, > > > > This is a useful document. I support it. > > > > Michael, please update the tree diagram to list all the data nodes. > Thanks. > > > > Cheers, > > Med > > > > *De :* tcpm [mailto:tcpm-bounces@ietf.org] *De la part de* Yoshifumi > Nishida > *Envoy=C3=A9 :* lundi 17 ao=C3=BBt 2020 19:04 > *=C3=80 :* tcpm@ietf.org Extensions > *Objet :* Re: [tcpm] WG item adoption for draft-scharf-tcpm-yang-tcp-06 > > > > Hi folks, > > We appreciate your feedback on this. > > -- > > tcpm co-chairs > > > > On Mon, Aug 3, 2020 at 1:04 AM Yoshifumi Nishida > wrote: > > Hi, > > > > The chairs has been discussing how to proceed > draft-scharf-tcpm-yang-tcp-06 after the WG meeting. > > The results of the hum were a bit weak to see clear consensus although > there was slightly strong hum for adoption. > > Also, there seems to be some confusions during the adoption call. (I'm > sorry for the clumsiness of using the tool) > > In order for this, we would like to seek the additional feedback from the > community on the following points. > > > > 1: If you want to add your hum to the call because you didn't at the > meeting for some reasons or if you want to change your hum, please let th= e > chairs know. > > 2: if you hummed for not adopting the draft, please share your opinion. > This will be a very helpful input for us. > > > > We'll appreciate your cooperation. > > Thanks, > > -- > > Yoshi > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --000000000000f073b405adea5806 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0Hi Med,

Thank you for = the input.
We'll wait a bit more and will make a decision.
--
Yoshi

On Thu, Aug 27, 2020 at 1:16 AM <mohamed.boucadair@orange.com> wro= te:

Hi all,

=C2=A0

This is a useful document. I supp= ort it. =C2=A0

=C2=A0

Michael, please update the tree d= iagram to list all the data nodes. Thanks.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yoshifumi Nishida
Envoy=C3=A9=C2=A0: lundi 17 ao=C3=BBt 2020 19:04
=C3=80=C2=A0: tcp= m@ietf.org Extensions <tcpm@ietf.org>
Objet=C2=A0: Re: [tcpm] WG item adoption for draft-scharf-tcpm-yang-= tcp-06

=C2=A0

Hi folks,

We appreciate your feedback on this.

--

tcpm co-chairs

=C2=A0

On Mon, Aug 3, 2020 at 1:04 AM Yoshifumi Nishida <= ;nsd.ietf@gmail.com= > wrote:

Hi,

=C2=A0

The chairs has=C2=A0been discussing how to proceed d= raft-scharf-tcpm-yang-tcp-06 after the WG meeting.

The results of the hum were a bit weak to see clear = consensus although there was slightly strong hum for adoption.=C2=A0=

Also, there seems to be some confusions during the a= doption call. (I'm sorry for the clumsiness of using the tool)

In order for this, we would like to seek the additio= nal=C2=A0feedback from the community on the following points.=

=C2=A0

1: If you want to add your hum to the call because y= ou didn't at the meeting for some reasons or if you want to change your= hum, please let the chairs know.

2: if you hummed for not adopting the=C2=A0draft, pl= ease share your opinion. This will be a very helpful input for us.=C2=A0=

=C2=A0

We'll appreciate your cooperation.=

Thanks,

--

Yoshi

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--000000000000f073b405adea5806--