From nobody Fri Jun 10 02:46:38 2016 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 C6AA112D15E; Fri, 10 Jun 2016 02:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dlx4KZaNpwQS; Fri, 10 Jun 2016 02:46:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A6DDC12D572; Fri, 10 Jun 2016 02:46:11 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 5AFB450A7A4DC; Fri, 10 Jun 2016 09:46:08 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5A9k9x8023665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2016 09:46:09 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5A9k8QR006484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jun 2016 11:46:08 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 10 Jun 2016 11:46:09 +0200 From: "Scharf, Michael (Nokia - DE)" To: "tcpm@ietf.org Extensions" Thread-Topic: [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] Thread-Index: AQHRwvuTZPf/LcUXxEO0TcQsUo2KSp/icv/w Date: Fri, 10 Jun 2016 09:46:08 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Carles Gomez Montenegro , "jon.crowcroft@cl.cam.ac.uk" , "lwip@ietf.org" Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 09:46:37 -0000 Heads-up Michael -----Original Message----- From: Lwip [mailto:lwip-bounces@ietf.org] On Behalf Of Carles Gomez Montene= gro Sent: Friday, June 10, 2016 11:36 AM To: lwip@ietf.org Cc: jon.crowcroft@cl.cam.ac.uk Subject: [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-con= strained-node-networks-00.txt] Dear LWIG WG, /** Apologies for possibly multiple similar e-mails... **/ We have just submitted the draft entitled 'TCP over Constrained-Node Networ= ks', which we believe may be of interest to the members of this group. We would like to kindly ask for feedback, specially on the basis of impleme= ntation experience. Thank you very much! Kind regards, The authors ---------------------------- Original Message ---------------------------- Subject: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt From: internet-drafts@ietf.org Date: Fri, June 10, 2016 10:38 am To: "Jon Crowcroft" "Carles Gomez" -------------------------------------------------------------------------- A new version of I-D, draft-gomez-core-tcp-constrained-node-networks-00.txt has been successfully submitted by Carles Gomez and posted to the IETF repo= sitory. Name: draft-gomez-core-tcp-constrained-node-networks Revision: 00 Title: TCP over Constrained-Node Networks Document date: 2016-06-10 Group: Individual Submission Pages: 9 URL: =20 https://www.ietf.org/internet-drafts/draft-gomez-core-tcp-constrained-node-= networks-00.txt Status: =20 https://datatracker.ietf.org/doc/draft-gomez-core-tcp-constrained-node-netw= orks/ Htmlized: =20 https://tools.ietf.org/html/draft-gomez-core-tcp-constrained-node-networks-= 00 Abstract: This document provides a profile for the Transmission Control Protocol (TCP) over Constrained-Node Networks (CNNs). The overarching goal is to offer simple measures to allow for lightweight TCP implementation and suitable operation in such environments. 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. The IETF Secretariat _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip From nobody Fri Jun 10 03:04:21 2016 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 DF8E412D15E; Fri, 10 Jun 2016 03:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 dnJB5XVL6Xdi; Fri, 10 Jun 2016 03:04:14 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7810B12D155; Fri, 10 Jun 2016 03:04:08 -0700 (PDT) Received: from mfilter39-d.gandi.net (mfilter39-d.gandi.net [217.70.178.170]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id DA448A80C0; Fri, 10 Jun 2016 12:04:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter39-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter39-d.gandi.net (mfilter39-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id gN317ALsvsB6; Fri, 10 Jun 2016 12:04:05 +0200 (CEST) X-Originating-IP: 134.102.90.80 Received: from eduroam-pool10-081.wlan.uni-bremen.de (eduroam-pool10-081.wlan.uni-bremen.de [134.102.90.80]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 14108A80DC; Fri, 10 Jun 2016 12:04:03 +0200 (CEST) Message-ID: <575A9092.9090604@tzi.org> Date: Fri, 10 Jun 2016 12:04:02 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Carles Gomez Montenegro References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" , "core@ietf.org WG" Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 10:04:18 -0000 Carles, thanks for submitting this. I think that this draft is truly best handled in LWIG. We don't *have* to profile TCP for CoAP-over-TCP; people are free to use whatever parts of TCP they think are useful. (And, of course, there are applications for CoAP-over-TCP that are in the backend.) On the other hand, it is useful to -- manage expectations: what can I expect that the *other* side will offer in TCP functionality -- give advice to implementers: what is useful to implement, what not -- collect implementation experience that is relevant for these two (One interesting effect I'm seeing is that people know how good TCP can be, which shapes their expectations, but then they are hurt by using really bad constrained TCP implementations... We certainly should be paying attention to this on the CoRE WG side.) My biggest comment is probably that for device-to-cloud, the level of TCP functions implemented will be asymmetric (full TCP on cloud side, possibly more limited on the device side) -- what is the effect of this asymmetry? Maybe there also needs to be more discussion on the role of the middlebox (after all, we are doing CoAP-over-TCP to devices for the sole reason to climb over middleboxes). Grüße, Carsten Scharf, Michael (Nokia - DE) wrote: > Heads-up > > Michael > > > -----Original Message----- > From: Lwip [mailto:lwip-bounces@ietf.org] On Behalf Of Carles Gomez Montenegro > Sent: Friday, June 10, 2016 11:36 AM > To: lwip@ietf.org > Cc: jon.crowcroft@cl.cam.ac.uk > Subject: [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] > > Dear LWIG WG, > > /** Apologies for possibly multiple similar e-mails... **/ > > We have just submitted the draft entitled 'TCP over Constrained-Node Networks', which we believe may be of interest to the members of this group. > > We would like to kindly ask for feedback, specially on the basis of implementation experience. > > Thank you very much! > > Kind regards, > > The authors > > > ---------------------------- Original Message ---------------------------- > Subject: New Version Notification for > draft-gomez-core-tcp-constrained-node-networks-00.txt > From: internet-drafts@ietf.org > Date: Fri, June 10, 2016 10:38 am > To: "Jon Crowcroft" > "Carles Gomez" > -------------------------------------------------------------------------- > > > A new version of I-D, draft-gomez-core-tcp-constrained-node-networks-00.txt > has been successfully submitted by Carles Gomez and posted to the IETF repository. > > Name: draft-gomez-core-tcp-constrained-node-networks > Revision: 00 > Title: TCP over Constrained-Node Networks > Document date: 2016-06-10 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-gomez-core-tcp-constrained-node-networks-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gomez-core-tcp-constrained-node-networks/ > Htmlized: > https://tools.ietf.org/html/draft-gomez-core-tcp-constrained-node-networks-00 > > > Abstract: > This document provides a profile for the Transmission Control > Protocol (TCP) over Constrained-Node Networks (CNNs). The > overarching goal is to offer simple measures to allow for lightweight > TCP implementation and suitable operation in such environments. > > > > > 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 > > > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri Jun 10 08:10:34 2016 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 E3CD812D5A4; Fri, 10 Jun 2016 08:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 fwLPjH9HSHXQ; Fri, 10 Jun 2016 08:10:25 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF5112D0F9; Fri, 10 Jun 2016 08:10:23 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id u5AFAIam025806; Fri, 10 Jun 2016 17:10:19 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id ED4AB1D53C1; Fri, 10 Jun 2016 17:10:17 +0200 (CEST) Received: from 131.111.5.14 by webmail.entel.upc.edu with HTTP; Fri, 10 Jun 2016 17:10:11 +0200 Message-ID: In-Reply-To: <575A9092.9090604@tzi.org> References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> Date: Fri, 10 Jun 2016 17:10:11 +0200 From: "Carles Gomez Montenegro" To: "Carsten Bormann" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Delayed for 78:04:03 by milter-greylist-4.4.3 (dash.upc.es [147.83.2.50]); Fri, 10 Jun 2016 17:10:19 +0200 (CEST) Archived-At: Cc: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" , "core@ietf.org WG" Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 15:10:28 -0000 Hi Carsten, Thanks a lot for your comments. While we work to address those, it would be really helpful if folks that have faced 'bad constrained TCP implementations', and/or have struggled with middlebox traversal can share their experience. Cheers, Carles > Carles, > > thanks for submitting this. > > I think that this draft is truly best handled in LWIG. > > We don't *have* to profile TCP for CoAP-over-TCP; people are free to use > whatever parts of TCP they think are useful. (And, of course, there are > applications for CoAP-over-TCP that are in the backend.) > > On the other hand, it is useful to > -- manage expectations: > what can I expect that the *other* side will offer in TCP functionality > -- give advice to implementers: > what is useful to implement, what not > -- collect implementation experience that is relevant for these two > > (One interesting effect I'm seeing is that people know how good TCP can > be, which shapes their expectations, but then they are hurt by using > really bad constrained TCP implementations... We certainly should be > paying attention to this on the CoRE WG side.) > > My biggest comment is probably that for device-to-cloud, the level of > TCP functions implemented will be asymmetric (full TCP on cloud side, > possibly more limited on the device side) -- what is the effect of this > asymmetry? > > Maybe there also needs to be more discussion on the role of the > middlebox (after all, we are doing CoAP-over-TCP to devices for the sole > reason to climb over middleboxes). > > Grüße, Carsten > > > Scharf, Michael (Nokia - DE) wrote: >> Heads-up >> >> Michael >> >> >> -----Original Message----- >> From: Lwip [mailto:lwip-bounces@ietf.org] On Behalf Of Carles Gomez >> Montenegro >> Sent: Friday, June 10, 2016 11:36 AM >> To: lwip@ietf.org >> Cc: jon.crowcroft@cl.cam.ac.uk >> Subject: [Lwip] [Fwd: New Version Notification for >> draft-gomez-core-tcp-constrained-node-networks-00.txt] >> >> Dear LWIG WG, >> >> /** Apologies for possibly multiple similar e-mails... **/ >> >> We have just submitted the draft entitled 'TCP over Constrained-Node >> Networks', which we believe may be of interest to the members of this >> group. >> >> We would like to kindly ask for feedback, specially on the basis of >> implementation experience. >> >> Thank you very much! >> >> Kind regards, >> >> The authors >> >> >> ---------------------------- Original Message >> ---------------------------- >> Subject: New Version Notification for >> draft-gomez-core-tcp-constrained-node-networks-00.txt >> From: internet-drafts@ietf.org >> Date: Fri, June 10, 2016 10:38 am >> To: "Jon Crowcroft" >> "Carles Gomez" >> -------------------------------------------------------------------------- >> >> >> A new version of I-D, >> draft-gomez-core-tcp-constrained-node-networks-00.txt >> has been successfully submitted by Carles Gomez and posted to the IETF >> repository. >> >> Name: draft-gomez-core-tcp-constrained-node-networks >> Revision: 00 >> Title: TCP over Constrained-Node Networks >> Document date: 2016-06-10 >> Group: Individual Submission >> Pages: 9 >> URL: >> https://www.ietf.org/internet-drafts/draft-gomez-core-tcp-constrained-node-networks-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-gomez-core-tcp-constrained-node-networks/ >> Htmlized: >> https://tools.ietf.org/html/draft-gomez-core-tcp-constrained-node-networks-00 >> >> >> Abstract: >> This document provides a profile for the Transmission Control >> Protocol (TCP) over Constrained-Node Networks (CNNs). The >> overarching goal is to offer simple measures to allow for lightweight >> TCP implementation and suitable operation in such environments. >> >> >> >> >> 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 >> >> >> >> _______________________________________________ >> Lwip mailing list >> Lwip@ietf.org >> https://www.ietf.org/mailman/listinfo/lwip >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > From nobody Sat Jun 11 00:23:31 2016 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 5D7DC12B056 for ; Sat, 11 Jun 2016 00:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 IH6r92N0JZep for ; Sat, 11 Jun 2016 00:23:29 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 06A3612D8C5 for ; Sat, 11 Jun 2016 00:23:28 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 443DA1B00188; Sat, 11 Jun 2016 08:35:47 +0100 (BST) Message-ID: <575BBC6C.6020805@erg.abdn.ac.uk> Date: Sat, 11 Jun 2016 08:23:24 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tcpm@ietf.org References: <575BBC10.3080905@abdn.ac.uk> In-Reply-To: <575BBC10.3080905@abdn.ac.uk> X-Forwarded-Message-Id: <575BBC10.3080905@abdn.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: mallman@icir.org Subject: [tcpm] Fwd: Some comments on draft-ietf-tcpm-rto-consider-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 07:23:31 -0000 This email is a review of the current revision of draft-ietf-tcpm-rto-consider-03. The review is split into three parts. Gorry ------------------ * Introduction/Scope. The Introduction in the current rev. seems to assume a lot of context, within the TCP community Id expect most of this is already clear, if the document is looking for applicability beyond that, I think these parts need more work. In particular the concept of a retransmission timeout mechanism" needs explained. Mark and I have recently exchanged some discussion off-list to see if it is possible to make a clearer explanation of what constitutes an RTO in protocols beyond TCP. I expect a new intro will provide the definitional help that I was looking for. ------------------ * Comments on the recommendations - Some of these comments relate I think to assumptions about TCP specifics, that could be generalised, or may be handed in the introduction. (1) "the RTO MUST be conservatively set to no less than 1 second." - If this is TCP or SCTP, then RTO is defined. If more is intended RTO needs to have been defined. - Note to TSVWG: This may implicate a need for a change in the pending revision of SCTP and if so, this change needs to be logged in the SCTP Errata ID. --- " For instance, consider a DNS request from a client to a resolver. When the request can be served from the resolver's cache the FT likely well approximates the network RTT between the client and resolver. However, on a cache miss the resolver will have to request the needed information from authoritative DNS servers, which will non-trivially increase the FT and therefore the FT between the client and resolver does not well match the network-based RTT between the two hosts." - If the transport is assumed as DNS/UDP, this needs to be said in the example, up until this point the ID only discusses TCP and clearly DNS/TCP does not have this concern. --- " (b) FT observations MUST be taken regularly." - The language below seems inappropriate in a MUST clause, I think this implies it is a SHOULD, and the exception conditions do need to be discussed, since the period isn't stated, how is this normative requirement to be interpreted? - Maybe this text needs clarification: The current wording requirement could be read to contradict RFC5405, that avoids against sending UDP probes and traffic when an application is idle. This needs more careful explanation. Even for TCP/SCTP, I would not advocate requiring keep-alive or heartbeat packets as suggested by "the requirement that the FT be sampled continuously throughout the lifetime of a connection." --- "For the purpose of this requirement, we state that FT samples SHOULD be taken at least once per RTT or as frequently as data is exchanged and ACKed if that happens less frequently than every RTT." and later: " Hence, this once-per-RTT sampling requirement is explicitly a "SHOULD" and not a "MUST". " However, we also recognize that it may not always be practical to take a FT sample this often in all cases." -I agree with the SHOULD from the perspective of TCP, some methods respond more slowly to congestion that TCP, and sample less often. How does this relate to the various repair mechanisms in RTP? (they also can have timers and retransmit) - are these counter examples where the SHOULD does not apply? --- (c) FT samples used in the computation of the RTO MUST NOT be ambiguous. - I read this requirement is on the samples. That's not correct. Maybe it should be more like: "An RTO algorithm MUST NOT use FT samples that are ambiguous when calculating the RTO." --- - I wonder if section 3 could also talk about other ways to measure RTTs when not sending data, such as keepalive and SCTP heartbeat messages. --- "The backoff may be removed after the successful transmission of non-retransmitted data." - The "may" appears to be protocol permission, can it be "MAY? --- " A maximum value MAY be placed on the RTO provided it is at least 60 seconds (a la [RFC6298])." - To me, there seem to be two requirements here: " A maximum value MAY be placed on the RTO. The maximum MUST NOT exceed 60 seconds (as in [RFC6298])." --- (4) "An exception is made to this rule if an IETF standardized mechanism is used to determine that a particular loss is due to a non-congestion event (e.g., packet corruption)." - NiT: I wonder if this can be mis-cited? There are as yet no specs in the space published in the RFC series. Could we be more careful on endorsing this work, and say perhaps that "exceptions could be made to this rule if an IETF standardized ... . --- "Additionally, RTO-triggered congestion control actions may be reversed when a standard mechanism determines that the cause of the loss was not congestion after all." - Examples from the RFC series exist, and would be good. E.g. Eifel or something else? - Is this the place to define "spurious", since this is used later. ---- " We note that research has shown the tension between the responsiveness and correctness of retransmission timeouts seems to be a fundamental tradeoff [AP99]." - I think this paper is about TCP, and I think the tension is clear for protocols like TCP. --- "While the implication of these deviations from the standard may be more spurious retransmits (per [AP99]), we are aware of no large scale problems caused by this change to the minimum RTO." - I'd like to argue that a lower RTO can reduce performance for paths where this RTO can be set below the RTT. Such paths do exist, and middleboxes sometimes split TCP connections to overcome this issue. I think at least the ID should note the issue, even if it claims that these paths are somehow accommodated within the guidance. ------------------ * Standards status and RFC 2119 recommendations. "nor limit future standardization of specific RTO mechanisms." - I'd need advice, but I thought BCPs did exactly this. Paraphrasing slightly, the purpose of the RFC5405 was to impose default constraints that future RFCs have to justify their choices against. That's limiting. The MUSTs are real requirements and the SHOULD strong desirables. The feedback we have to the RFC5405.bis is to stengthen more SHOULDs to MUSTs - I'm going to speak to my ADs before I agree to any of these. But if the IESG agree, then I think that is what BCP status is about. Scope (a) I dont disagree, unless the community explicity updates a spec a new BCP doesn't change old RFCs. Scope (v) - To me seems weird. Because it seems to set a "SHOULD" over the entire document, and that document contains MUSTs. I can't see how an RFC can have a "SHOULD-MUST", but likely the ADs can advise during WGLC. --- I worry the following can be cited elsewhere as compliance of a protocol or mechanism by the IETF, when really I think this is intended to define an acceptable RTO response. Some tightening of the language would seem appropriate: "RTO mechanisms that are not standardized but adhere to the requirements in the following section are deemed consistent with the standards. " - sounds dangerously wide when cited as text - I was presuming the document intended "are deemed consistent with the standards in the RTO behaviour" - or something, I presume you don't want people to cite this RFC saying their new protocol foo-bar is "consistent with IETF standards" because it does this. "an implementation is considered standards compliant" - I quibble again here on language, because I don't think this is true generally of the protocol, only true of their RTO response. --- "In other words, the requirements in this document can be viewed as specifying the default properties of an RTO mechanism." - This seems like an informational statement that could be cited as a contradiction to the RFC2119 text unless worded carefully? This sort of text needs AD advice if kept. "Specifications can more concretely nail down specifics within these defaults or work outside the defaults as necessary." - The same comment on the second half of this sentence. --- "That is, this document's stance is to not limit the community's ability to make exceptions to the requirements herein for particular cases." - If this is BCP, I think this needs to be tighter, I don't think any ID can expect to automatically make exceptions to a BCP, by simply saying "the WG decided differently" if you want that, then I think this document needs to be INFO (I'm not the Chair or AD for the document). If it's BCP, I'd expect the consensus to set the best current practice and the ADs to block new RFCs with at least a DISCUSS to work out why WG XXX was going against what has been IETF consensus. --- "However, implementations that fall within the defaults do not require explicit specifications to be considered consistent with the standards." - I could not parse this sentence, it sounds like it could be normative language without a keyword. --- Section 3: "We now list the requirements that SHOULD apply when designing retransmission timeout (RTO) mechanisms." - this seems to scope a "MUST" with a preceding "SHOULD". I question if this is allowed in a BCP. ------------------ From nobody Sun Jun 12 05:42:11 2016 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 4879612D674; Sun, 12 Jun 2016 05:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 u-v8JrmItN7Q; Sun, 12 Jun 2016 05:42:01 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (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 8071E12D672; Sun, 12 Jun 2016 05:42:01 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id v76so24152261qgv.3; Sun, 12 Jun 2016 05:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uvF+Wp2q8EQSLYu2Rig/pEcff2hAhbUH52n/wpSkWSo=; b=VWPZbDTCTC/vwCalisnC4g7m7XZalaL5dClw4ZfvwKne4H4kxmXRnPXiBiAT2caQ4C 0BdZtT3EMwNoL1m+0NgUaBrAFCYo5JUORBXv2vqLrEUns+GjD0DnWvV1QExWlOdntGxi cNBUOE10dc5x8VXl8GOsh5MgU1mE4sYyve6PxoexTHyPJJkCvhhgqYOZgVQZf7Fnn0Gt 6xieArHOYGMdJZQlVKahshWzVGEICh1H1Ih/N4Nf2WDY/rwRdCvxMZ8PX6dgduGNvIk5 rd03kGfKcnQosPOn3uuJjkzd0fKZ0RDShiup/1ebqoxmiGmfuJVaBVofxylnK9yD+lss iAPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uvF+Wp2q8EQSLYu2Rig/pEcff2hAhbUH52n/wpSkWSo=; b=OkCRCalgMTpiW3rDy82MXLE4Lc6kiaoBlYBkl5zSc9LlEBu/NnqXxluZGu0XA1ZHBv 6HCVq4DdRjE0Kl/q+KPt/eFf4rh/BPltxiU6oMh++yK/JJesHC/nKXNWMFQq1kWbjT// I6en5nDFR9+VDVb1Hq+LgX6yfdDuGY3DWLty6oNy7TUnjJ6dRPSBDz4FoW5X+RePSFab 06KD/w6HqxXeGpEN8uTK74dlpPr9VvqMlxnf4La4mZqbedrlDgqlr1KHUXhmfrriq1QH +Pj2ewrU9sS1BN29MpNcqCJb6VKJx+bV82uDVkQR6IQQ3wBqAVbMOYYsG8OSNTm8dIl7 GbVA== X-Gm-Message-State: ALyK8tK1iGn5V5w0daQxlJbet+ZHcIYkMjt3vcwfB/KDuedCb9kogtqMJbnaKkksOfixxcwpdvAcTIGZyqVMUQ== X-Received: by 10.140.203.213 with SMTP id y204mr10162306qha.45.1465735320461; Sun, 12 Jun 2016 05:42:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.160.87 with HTTP; Sun, 12 Jun 2016 05:41:59 -0700 (PDT) In-Reply-To: References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> From: Zhen Cao Date: Sun, 12 Jun 2016 20:41:59 +0800 Message-ID: To: Carles Gomez Montenegro Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" , "core@ietf.org WG" Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 12:42:04 -0000 Hi Carles, Nice draft. I always want to know the complains of TCP problems over Constrained link and device. In the very beginning of Lwig, the IETF79 bof, David Bormann gave an excellent talk about similar issues ( i try to search the IETF proceedings for the talk but failed coz they do not hold it for informative bof ). But we failed to collect these information from implementer or researchers like you further on. Thanks again for this always timely work. In this respect, I agree with Carsten that your draft being handled in lwig and a talk is welcome at Berlin meeting. Some quick comments for your draft. >3.2. Window Size > A TCP window size of one segment follows the same rationale as the > default setting for NSTART in [RFC7252], leading to equivalent > operation when CoAP is used over TCP. IMHO, it does not matter because if the application has only a short message to send, the de facto effective cwnd will be ONE. >3.3. RTO estimation > challenges of CNNs, in contrast with the RFC 6298 RTO. Therefore, as > per this document, CoCoA RTO SHOULD be used in TCP over CNNs. > Alternatively, implementors MAY choose the RTO estimation algorithm > defined in RFC 6298. One of the two RTO algorithms MUST be > implemented. Is the RTO estimation algorithm link-specific? For example, I knew you have some work on CoCoA over GPRS. Is it always better than the competitor? Cheers, Zhen On Fri, Jun 10, 2016 at 11:10 PM, Carles Gomez Montenegro wrote: > > Hi Carsten, > > Thanks a lot for your comments. > > While we work to address those, it would be really helpful if folks that > have faced 'bad constrained TCP implementations', and/or have struggled > with middlebox traversal can share their experience. > > Cheers, > > Carles > > > > Carles, > > > > thanks for submitting this. > > > > I think that this draft is truly best handled in LWIG. > > > > We don't *have* to profile TCP for CoAP-over-TCP; people are free to us= e > > whatever parts of TCP they think are useful. (And, of course, there ar= e > > applications for CoAP-over-TCP that are in the backend.) > > > > On the other hand, it is useful to > > -- manage expectations: > > what can I expect that the *other* side will offer in TCP functional= ity > > -- give advice to implementers: > > what is useful to implement, what not > > -- collect implementation experience that is relevant for these two > > > > (One interesting effect I'm seeing is that people know how good TCP can > > be, which shapes their expectations, but then they are hurt by using > > really bad constrained TCP implementations... We certainly should be > > paying attention to this on the CoRE WG side.) > > > > My biggest comment is probably that for device-to-cloud, the level of > > TCP functions implemented will be asymmetric (full TCP on cloud side, > > possibly more limited on the device side) -- what is the effect of this > > asymmetry? > > > > Maybe there also needs to be more discussion on the role of the > > middlebox (after all, we are doing CoAP-over-TCP to devices for the sol= e > > reason to climb over middleboxes). > > > > Gr=C3=83=C2=BC=C3=83=C5=B8e, Carsten > > > > > > Scharf, Michael (Nokia - DE) wrote: > >> Heads-up > >> > >> Michael > >> > >> > >> -----Original Message----- > >> From: Lwip [mailto:lwip-bounces@ietf.org] On Behalf Of Carles Gomez > >> Montenegro > >> Sent: Friday, June 10, 2016 11:36 AM > >> To: lwip@ietf.org > >> Cc: jon.crowcroft@cl.cam.ac.uk > >> Subject: [Lwip] [Fwd: New Version Notification for > >> draft-gomez-core-tcp-constrained-node-networks-00.txt] > >> > >> Dear LWIG WG, > >> > >> /** Apologies for possibly multiple similar e-mails... **/ > >> > >> We have just submitted the draft entitled 'TCP over Constrained-Node > >> Networks', which we believe may be of interest to the members of this > >> group. > >> > >> We would like to kindly ask for feedback, specially on the basis of > >> implementation experience. > >> > >> Thank you very much! > >> > >> Kind regards, > >> > >> The authors > >> > >> > >> ---------------------------- Original Message > >> ---------------------------- > >> Subject: New Version Notification for > >> draft-gomez-core-tcp-constrained-node-networks-00.txt > >> From: internet-drafts@ietf.org > >> Date: Fri, June 10, 2016 10:38 am > >> To: "Jon Crowcroft" > >> "Carles Gomez" > >> ----------------------------------------------------------------------= ---- > >> > >> > >> A new version of I-D, > >> draft-gomez-core-tcp-constrained-node-networks-00.txt > >> has been successfully submitted by Carles Gomez and posted to the IETF > >> repository. > >> > >> Name: draft-gomez-core-tcp-constrained-node-networks > >> Revision: 00 > >> Title: TCP over Constrained-Node Networks > >> Document date: 2016-06-10 > >> Group: Individual Submission > >> Pages: 9 > >> URL: > >> https://www.ietf.org/internet-drafts/draft-gomez-core-tcp-constrained-= node-networks-00.txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-gomez-core-tcp-constrained-node= -networks/ > >> Htmlized: > >> https://tools.ietf.org/html/draft-gomez-core-tcp-constrained-node-netw= orks-00 > >> > >> > >> Abstract: > >> This document provides a profile for the Transmission Control > >> Protocol (TCP) over Constrained-Node Networks (CNNs). The > >> overarching goal is to offer simple measures to allow for lightweig= ht > >> TCP implementation and suitable operation in such environments. > >> > >> > >> > >> > >> 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 > >> > >> > >> > >> _______________________________________________ > >> Lwip mailing list > >> Lwip@ietf.org > >> https://www.ietf.org/mailman/listinfo/lwip > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >> > > > > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip From nobody Sun Jun 12 18:54:02 2016 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 CECED12D736 for ; Sun, 12 Jun 2016 18:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 qnytbQcLZf0E for ; Sun, 12 Jun 2016 18:53:58 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F60812D162 for ; Sun, 12 Jun 2016 18:53:58 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 8148F19F431 for ; Mon, 13 Jun 2016 09:53:57 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.255.40.27]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id E4C1719F390; Mon, 13 Jun 2016 09:53:56 +0800 (HKT) Message-ID: From: "weigengyu" To: "Carles Gomez Montenegro" , "Carsten Bormann" References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> In-Reply-To: Date: Mon, 13 Jun 2016 09:53:54 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: lwip@ietf.org, tcpm@ietf.org, jon.crowcroft@cl.cam.ac.uk, core@ietf.org Subject: Re: [tcpm] [core] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 01:54:01 -0000 Hi Carles, I will give some comments as we have been doing both CoAP over Websocket and CoAP over TCP by extending Califorium. I agree Carsten that CoAP over TCP will be used in the cloud and may also be in less-constrained networks. It is hard to say that CoAP over TCP will be used in Constrained Networks. Rgards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carles Gomez Montenegro Sent: Friday, June 10, 2016 11:10 PM To: Carsten Bormann Cc: lwip@ietf.org ; tcpm@ietf.org Extensions ; jon.crowcroft@cl.cam.ac.uk ; core@ietf.org WG Subject: Re: [core] [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] Hi Carsten, Thanks a lot for your comments. While we work to address those, it would be really helpful if folks that have faced 'bad constrained TCP implementations', and/or have struggled with middlebox traversal can share their experience. Cheers, Carles > Carles, > > thanks for submitting this. > > I think that this draft is truly best handled in LWIG. > > We don't *have* to profile TCP for CoAP-over-TCP; people are free to use > whatever parts of TCP they think are useful. (And, of course, there are > applications for CoAP-over-TCP that are in the backend.) > > On the other hand, it is useful to > -- manage expectations: > what can I expect that the *other* side will offer in TCP functionality > -- give advice to implementers: > what is useful to implement, what not > -- collect implementation experience that is relevant for these two > > (One interesting effect I'm seeing is that people know how good TCP can > be, which shapes their expectations, but then they are hurt by using > really bad constrained TCP implementations... We certainly should be > paying attention to this on the CoRE WG side.) > > My biggest comment is probably that for device-to-cloud, the level of > TCP functions implemented will be asymmetric (full TCP on cloud side, > possibly more limited on the device side) -- what is the effect of this > asymmetry? > > Maybe there also needs to be more discussion on the role of the > middlebox (after all, we are doing CoAP-over-TCP to devices for the sole > reason to climb over middleboxes). > > Grüße, Carsten > > > Scharf, Michael (Nokia - DE) wrote: >> Heads-up >> >> Michael >> >> >> -----Original Message----- >> From: Lwip [mailto:lwip-bounces@ietf.org] On Behalf Of Carles Gomez >> Montenegro >> Sent: Friday, June 10, 2016 11:36 AM >> To: lwip@ietf.org >> Cc: jon.crowcroft@cl.cam.ac.uk >> Subject: [Lwip] [Fwd: New Version Notification for >> draft-gomez-core-tcp-constrained-node-networks-00.txt] >> >> Dear LWIG WG, >> >> /** Apologies for possibly multiple similar e-mails... **/ >> >> We have just submitted the draft entitled 'TCP over Constrained-Node >> Networks', which we believe may be of interest to the members of this >> group. >> >> We would like to kindly ask for feedback, specially on the basis of >> implementation experience. >> >> Thank you very much! >> >> Kind regards, >> >> The authors >> >> >> ---------------------------- Original Message >> ---------------------------- >> Subject: New Version Notification for >> draft-gomez-core-tcp-constrained-node-networks-00.txt >> From: internet-drafts@ietf.org >> Date: Fri, June 10, 2016 10:38 am >> To: "Jon Crowcroft" >> "Carles Gomez" >> -------------------------------------------------------------------------- >> >> >> A new version of I-D, >> draft-gomez-core-tcp-constrained-node-networks-00.txt >> has been successfully submitted by Carles Gomez and posted to the IETF >> repository. >> >> Name: draft-gomez-core-tcp-constrained-node-networks >> Revision: 00 >> Title: TCP over Constrained-Node Networks >> Document date: 2016-06-10 >> Group: Individual Submission >> Pages: 9 >> URL: >> https://www.ietf.org/internet-drafts/draft-gomez-core-tcp-constrained-node-networks-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-gomez-core-tcp-constrained-node-networks/ >> Htmlized: >> https://tools.ietf.org/html/draft-gomez-core-tcp-constrained-node-networks-00 >> >> >> Abstract: >> This document provides a profile for the Transmission Control >> Protocol (TCP) over Constrained-Node Networks (CNNs). The >> overarching goal is to offer simple measures to allow for lightweight >> TCP implementation and suitable operation in such environments. >> >> >> >> >> 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 >> >> >> >> _______________________________________________ >> Lwip mailing list >> Lwip@ietf.org >> https://www.ietf.org/mailman/listinfo/lwip >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Jun 13 02:57:28 2016 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 25C1712D1CB; Mon, 13 Jun 2016 02:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Yjn05tSJrAyN; Mon, 13 Jun 2016 02:57:23 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E7012B025; Mon, 13 Jun 2016 02:57:23 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id u5D9vCIt023582; Mon, 13 Jun 2016 11:57:13 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 1A2D41D53C1; Mon, 13 Jun 2016 11:57:12 +0200 (CEST) Received: from 131.111.5.14 by webmail.entel.upc.edu with HTTP; Mon, 13 Jun 2016 11:57:09 +0200 Message-ID: <9c715eeca71b9a647df289dbd40f2092.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> Date: Mon, 13 Jun 2016 11:57:09 +0200 From: "Carles Gomez Montenegro" To: "Zhen Cao" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Delayed for 72:29:29 by milter-greylist-4.4.3 (violet.upc.es [147.83.2.51]); Mon, 13 Jun 2016 11:57:14 +0200 (CEST) Archived-At: Cc: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" , "core@ietf.org WG" Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 09:57:26 -0000 Hi Zhen, Thanks a lot for your support and comments! Please find below some inline responses. > Hi Carles, > > Nice draft. I always want to know the complains of TCP problems over > Constrained link and device. In the very beginning of Lwig, the > IETF79 bof, David Bormann gave an excellent talk about similar issues > ( i try to search the IETF proceedings for the talk but failed coz > they do not hold it for informative bof ). But we failed to collect > these information from implementer or researchers like you further on. > Thanks again for this always timely work. > > In this respect, I agree with Carsten that your draft being handled in > lwig and a talk is welcome at Berlin meeting. Thanks a lot. We'll prepare a presentation for Berlin, and will also change the name of the draft to show 'lwig' instead of 'core'. > Some quick comments for your draft. > >>3.2. Window Size > >> A TCP window size of one segment follows the same rationale as the >> default setting for NSTART in [RFC7252], leading to equivalent >> operation when CoAP is used over TCP. > > IMHO, it does not matter because if the application has only a short > message to send, the de facto effective cwnd will be ONE. I understand that what you point out may happen in many cases... However, a device, in some cases, might want to send e.g. two (or more) packets back to back to the same destination. In those, the window size of one would make a difference. By the way, currently the phrasing in the draft is that a window size of one 'MUST' be used. This keeps a behavior equivalent to that of CoAP for confirmable messages in RFC 7252, and dramatically simplifies implementations. However, I wonder if some more freedom should be offered, and maybe the 'MUST' could become a 'SHOULD', at the expense of opening the door to greater complexity... I personally tend to prefer the first approach, but it would be great to receive more feedback on this! >>3.3. RTO estimation >> challenges of CNNs, in contrast with the RFC 6298 RTO. Therefore, as >> per this document, CoCoA RTO SHOULD be used in TCP over CNNs. >> Alternatively, implementors MAY choose the RTO estimation algorithm >> defined in RFC 6298. One of the two RTO algorithms MUST be >> implemented. > > Is the RTO estimation algorithm link-specific? For example, I knew you > have some work on CoCoA over GPRS. Is it always better than the > competitor? These are crucial questions. In our work with CoCoA (e.g. [1]), we have used: - GPRS/UMTS emulation - GPRS testbed experiments - IEEE 802.15.4 (with and without L2 reliability) simulation - IEEE 802.15.4 testbed experiments In fact, using different link layer setups has been fundamental to identify issues of the initial CoCoA version, and to properly fine-tune it. While in some specific experiments (i.e. combination of network topology, offered load, traffic pattern, etc.) an alternative algorithm has shown better performance, in the more recent versions of CoCoA: - CoCoA has never underperformed default CoAP (while alternative algorithms have in some scenarios). - CoCoA shows a performance at least similar to, often better than, that of default CoAP. We evaluated performance in terms of parameters such as throughput, retry ratio, settling time after a burst of messages, and fairness. Nevertheless, of course, we welcome more feedback from other evaluation scenarios! Cheers, Carles [1] Here is our most mature paper on the topic: https://www.researchgate.net/publication/297989374_CoAP_Congestion_Control_for_the_Internet_of_Things > Cheers, > Zhen From nobody Mon Jun 13 03:16:03 2016 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 955EB12D1E7; Mon, 13 Jun 2016 03:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 qxPSogW_K7P2; Mon, 13 Jun 2016 03:15:58 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3E312D0FC; Mon, 13 Jun 2016 03:15:58 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id u5DAFU2J001938; Mon, 13 Jun 2016 12:15:53 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 12A361D53C1; Mon, 13 Jun 2016 12:15:30 +0200 (CEST) Received: from 131.111.5.14 by webmail.entel.upc.edu with HTTP; Mon, 13 Jun 2016 12:15:27 +0200 Message-ID: In-Reply-To: References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> Date: Mon, 13 Jun 2016 12:15:27 +0200 From: "Carles Gomez Montenegro" To: "weigengyu" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.4.3 (violet.upc.es [147.83.2.51]); Mon, 13 Jun 2016 12:15:54 +0200 (CEST) Archived-At: Cc: lwip@ietf.org, tcpm@ietf.org, jon.crowcroft@cl.cam.ac.uk, core@ietf.org Subject: Re: [tcpm] [core] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 10:16:00 -0000 Hi Wei, > Hi Carles, > > I will give some comments as we have been doing both CoAP over Websocket > and > CoAP over TCP by extending Califorium. Thanks a lot! > I agree Carsten that CoAP over TCP will be used in the cloud and may also > be > in less-constrained networks. > It is hard to say that CoAP over TCP will be used in Constrained > Networks. There exist relevant examples such as: https://www.ietf.org/proceedings/87/slides/slides-87-lwig-6.pdf It could be that, within the constrained-node network space, TCP is used rather in class 2 devices. However, we would need to collect more data to be able to confirm this. On the other hand, in our opinion, the CoAP over TCP activity may increase the number of constrained devices using TCP (probably, in the 'constrained device' to 'cloud' scenario). Thanks again! Best regards, Carles > Rgards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----原始邮件----- > From: Carles Gomez Montenegro > Sent: Friday, June 10, 2016 11:10 PM > To: Carsten Bormann > Cc: lwip@ietf.org ; tcpm@ietf.org Extensions ; jon.crowcroft@cl.cam.ac.uk > ; > core@ietf.org WG > Subject: Re: [core] [tcpm] [Lwip] [Fwd: New Version Notification for > draft-gomez-core-tcp-constrained-node-networks-00.txt] > > Hi Carsten, > > Thanks a lot for your comments. > > While we work to address those, it would be really helpful if folks that > have faced 'bad constrained TCP implementations', and/or have struggled > with middlebox traversal can share their experience. > > Cheers, > > Carles > > >> Carles, >> >> thanks for submitting this. >> >> I think that this draft is truly best handled in LWIG. >> >> We don't *have* to profile TCP for CoAP-over-TCP; people are free to use >> whatever parts of TCP they think are useful. (And, of course, there are >> applications for CoAP-over-TCP that are in the backend.) >> >> On the other hand, it is useful to >> -- manage expectations: >> what can I expect that the *other* side will offer in TCP >> functionality >> -- give advice to implementers: >> what is useful to implement, what not >> -- collect implementation experience that is relevant for these two >> >> (One interesting effect I'm seeing is that people know how good TCP can >> be, which shapes their expectations, but then they are hurt by using >> really bad constrained TCP implementations... We certainly should be >> paying attention to this on the CoRE WG side.) >> >> My biggest comment is probably that for device-to-cloud, the level of >> TCP functions implemented will be asymmetric (full TCP on cloud side, >> possibly more limited on the device side) -- what is the effect of this >> asymmetry? >> >> Maybe there also needs to be more discussion on the role of the >> middlebox (after all, we are doing CoAP-over-TCP to devices for the sole >> reason to climb over middleboxes). >> >> Grüße, Carsten >> >> >> Scharf, Michael (Nokia - DE) wrote: >>> Heads-up >>> >>> Michael >>> >>> >>> -----Original Message----- >>> From: Lwip [mailto:lwip-bounces@ietf.org] On Behalf Of Carles Gomez >>> Montenegro >>> Sent: Friday, June 10, 2016 11:36 AM >>> To: lwip@ietf.org >>> Cc: jon.crowcroft@cl.cam.ac.uk >>> Subject: [Lwip] [Fwd: New Version Notification for >>> draft-gomez-core-tcp-constrained-node-networks-00.txt] >>> >>> Dear LWIG WG, >>> >>> /** Apologies for possibly multiple similar e-mails... **/ >>> >>> We have just submitted the draft entitled 'TCP over Constrained-Node >>> Networks', which we believe may be of interest to the members of this >>> group. >>> >>> We would like to kindly ask for feedback, specially on the basis of >>> implementation experience. >>> >>> Thank you very much! >>> >>> Kind regards, >>> >>> The authors >>> >>> >>> ---------------------------- Original Message >>> ---------------------------- >>> Subject: New Version Notification for >>> draft-gomez-core-tcp-constrained-node-networks-00.txt >>> From: internet-drafts@ietf.org >>> Date: Fri, June 10, 2016 10:38 am >>> To: "Jon Crowcroft" >>> "Carles Gomez" >>> -------------------------------------------------------------------------- >>> >>> >>> A new version of I-D, >>> draft-gomez-core-tcp-constrained-node-networks-00.txt >>> has been successfully submitted by Carles Gomez and posted to the IETF >>> repository. >>> >>> Name: draft-gomez-core-tcp-constrained-node-networks >>> Revision: 00 >>> Title: TCP over Constrained-Node Networks >>> Document date: 2016-06-10 >>> Group: Individual Submission >>> Pages: 9 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-gomez-core-tcp-constrained-node-networks-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-gomez-core-tcp-constrained-node-networks/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-gomez-core-tcp-constrained-node-networks-00 >>> >>> >>> Abstract: >>> This document provides a profile for the Transmission Control >>> Protocol (TCP) over Constrained-Node Networks (CNNs). The >>> overarching goal is to offer simple measures to allow for >>> lightweight >>> TCP implementation and suitable operation in such environments. >>> >>> >>> >>> >>> 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 >>> >>> >>> >>> _______________________________________________ >>> Lwip mailing list >>> Lwip@ietf.org >>> https://www.ietf.org/mailman/listinfo/lwip >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > From nobody Mon Jun 13 04:01:44 2016 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 65A0312D51F; Mon, 13 Jun 2016 04:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1hSucyyHeDd; Mon, 13 Jun 2016 04:01:36 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 9422612D539; Mon, 13 Jun 2016 04:01:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 658D6E11CD070; Mon, 13 Jun 2016 11:01:32 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5DB1Xax018802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jun 2016 11:01:34 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5DB1XqT027659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jun 2016 13:01:33 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 13 Jun 2016 13:01:21 +0200 From: "Scharf, Michael (Nokia - DE)" To: Carles Gomez Montenegro , Zhen Cao Thread-Topic: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] Thread-Index: AQHRxVoI/RTNimOLOUmdRy+CYZPf8J/nLTRw Date: Mon, 13 Jun 2016 11:01:21 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488D0A96@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> <9c715eeca71b9a647df289dbd40f2092.squirrel@webmail.entel.upc.edu> In-Reply-To: <9c715eeca71b9a647df289dbd40f2092.squirrel@webmail.entel.upc.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" , "core@ietf.org WG" Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 11:01:38 -0000 Just out-of-curiosity: In 1981, when the current TCP spec was published, en= d hosts had significant processing and memory limitations. Quite a bit of t= he TCP protocol mechanisms were designed to deal with senders and receivers= that have very small buffers, e.g., of the order of the maximum segment si= ze.RFC 793 is very carefully designed to deal with these constraints. And c= urrent TCP implementations are still backward compatible to RFC 793. When quickly scanning through this document, some observations (the list is= not comprehensive):=20 - TCP counts window sizes in bytes, which draft-gomez-core-tcp-constrained-= node-networks-00 seems to ignore.=20 - Out-of-my-head, nothing prevents a TCP sender from limiting the congestio= n window to a small window (e.g., one MSS). This basically turns TCP into a= stop-and-wait protocol. A TCP sender can unilaterally decide to limit its = congestion window if it wants to simplify its implementation. I am not sure= if RFC 2119 language is needed for that at all. - A TCP receiver can use the receive window to prevent the sender from send= ing data, e.g., if it can only deal with one MSS. It may be interesting to = look into whether advertising a maximum receive window e.g. of at most one = MSS would solve some of the problems discussed in the draft. - TCP options will only be enabled if supported on both ends and a standard= -compliant TCP stack only has to support the MSS option (more precisely, op= tion kinds 0, 1, and 2). An implementation that does not want to use any ad= ditional TCP features does not have to implement support any of those optio= ns. However, to be compatible with RFC 793 the option kinds 0, 1, and 2 hav= e to be parsed in SYNs and thus basic support for option parsing in SYNs is= required anyway. If the basic support for option parsing in SYNs is in pla= ce (which is not very complex code), it seems easy to process any other opt= ions that may be present in the SYN as well, and just ignore them. Thus, I = do not understand what added value a MUST has that "forbids" TCP options th= at may typically not be negotiated in the environments addressed by this do= cument. - If the receiver knows that TCP shall run in a stop-and-wait mode (e.g., b= ecause it advertises very small receive window), the delayed ACKs in TCP ma= y offer some opportunities for optimization, e.g., a receiver could want to= turn them off delayed ACKs when it advertises a very small receive window.= I believe the document could look into that space. - There are quite a number of differences between using TCP only inside a c= ontrolled environment, or using TCP with endpoints that are located in the = Internet. I would recommend that a document explicitly discusses both varia= nts, as design trade-offs could be different. And I would assume that one o= f the reasons for picking TCP would be to at least have the option of end-t= o-end transfers over the global Internet. - ... (there is more) In general, the TCPM list is followed by quite a number of different TCP im= plementers and there is some expertise on the original RFC 793 design decis= ions. If the intention of this document is e.g. to define up a minimum set = of TCP features required for a stop-and-wait operation and with very small = buffers, I'd assume that relevant expertise would be on the TCPM list. So, it might make sense to keep the TCPM list in the loop. Presenting the d= ocument in TCPM may also be an option the authors may want to think about. Michael From nobody Mon Jun 13 04:13:47 2016 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 2DDD212D542; Mon, 13 Jun 2016 04:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 NiZBqpGAtply; Mon, 13 Jun 2016 04:13:39 -0700 (PDT) Received: from mta0.cl.cam.ac.uk (mta0.cl.cam.ac.uk [128.232.25.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4D312B03D; Mon, 13 Jun 2016 04:13:38 -0700 (PDT) Received: from sandy.cl.cam.ac.uk ([128.232.64.182] ident=jac22) by mta0.cl.cam.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1bCPoG-00031L-Fx; Mon, 13 Jun 2016 12:13:36 +0100 From: Jon Crowcroft To: "Scharf, Michael (Nokia - DE)" In-reply-to: <655C07320163294895BBADA28372AF5D488D0A96@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> <9c715eeca71b9a647df289dbd40f2092.squirrel@webmail.entel.upc.edu> <655C07320163294895BBADA28372AF5D488D0A96@FR712WXCHMBA15.zeu.alcatel-lucent.com> Comments: In-reply-to "Scharf, Michael (Nokia - DE)" message dated "Mon, 13 Jun 2016 11:01:21 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23270.1465816416.1@sandy.cl.cam.ac.uk> Date: Mon, 13 Jun 2016 12:13:36 +0100 Message-Id: Archived-At: Cc: "tcpm@ietf.org Extensions" , "lwip@ietf.org" , "jon.crowcroft@cl.cam.ac.uk" , "core@ietf.org WG" , Carles Gomez Montenegro Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 11:13:41 -0000 > Just out-of-curiosity: In 1981, when the current TCP spec was published, > end hosts had significant processing and memory limitations. Quite a bit > of the TCP protocol mechanisms were designed to deal with senders and > receivers that have very small buffers, e.g., of the order of the maximum > segment size.RFC 793 is very carefully designed to deal with these > constraints. And current TCP implementations are still backward > compatible to RFC 793. right - a typical system we used in 1981 was a DEC LSI/11 which had 64Kbytes of RAM for the whole OS and network stack - so the actual buffer space for packets might be a couple of kbytes - the thing is tho, that over a LFN (remember also, the backbone speeds were 56kbps, and international links might have satellites with .72 seconds RTTs), a sender still might speculatively keep more packets "in flight" than the receiver buffer advertised, if the receive processing meant that the bottleneck was always "in the air" not at the receiver of course, in a lot of CORE environments, the RTT is small enough that i think you're right, and advertising an MSS receive window would result in the stop&wait behaviour - can easily try this even on a couple of laptops on a wifi net........ maybe... int clamp= 576; setsockopt(sock, SOL_SOCKET, TCP_WINDOW_CLAMP, (char *)& clamp, sizeof(clamp)); > > When quickly scanning through this document, some observations (the list > is not comprehensive): > > - TCP counts window sizes in bytes, which > draft-gomez-core-tcp-constrained-node-networks-00 seems to ignore. > > - Out-of-my-head, nothing prevents a TCP sender from limiting the > congestion window to a small window (e.g., one MSS). This basically turns > TCP into a stop-and-wait protocol. A TCP sender can unilaterally decide > to limit its congestion window if it wants to simplify its > implementation. I am not sure if RFC 2119 language is needed for that at > all. > > - A TCP receiver can use the receive window to prevent the sender from > sending data, e.g., if it can only deal with one MSS. It may be > interesting to look into whether advertising a maximum receive window > e.g. of at most one MSS would solve some of the problems discussed in the > draft. > > - TCP options will only be enabled if supported on both ends and a > standard-compliant TCP stack only has to support the MSS option (more > precisely, option kinds 0, 1, and 2). An implementation that does not > want to use any additional TCP features does not have to implement > support any of those options. However, to be compatible with RFC 793 the > option kinds 0, 1, and 2 have to be parsed in SYNs and thus basic support > for option parsing in SYNs is required anyway. If the basic support for > option parsing in SYNs is in place (which is not very complex code), it > seems easy to process any other options that may be present in the SYN as > well, and just ignore them. Thus, I do not understand what added value a > MUST has that "forbids" TCP options that may typically not be negotiated > in the environments addressed by this document. > > - If the receiver knows that TCP shall run in a stop-and-wait mode (e.g., > because it advertises very small receive window), the delayed ACKs in TCP > may offer some opportunities for optimization, e.g., a receiver could > want to turn them off delayed ACKs when it advertises a very small > receive window. I believe the document could look into that space. > > - There are quite a number of differences between using TCP only inside a > controlled environment, or using TCP with endpoints that are located in > the Internet. I would recommend that a document explicitly discusses both > variants, as design trade-offs could be different. And I would assume > that one of the reasons for picking TCP would be to at least have the > option of end-to-end transfers over the global Internet. > > - ... (there is more) > > In general, the TCPM list is followed by quite a number of different TCP > implementers and there is some expertise on the original RFC 793 design > decisions. If the intention of this document is e.g. to define up a > minimum set of TCP features required for a stop-and-wait operation and > with very small buffers, I'd assume that relevant expertise would be on > the TCPM list. > > So, it might make sense to keep the TCPM list in the loop. Presenting the > document in TCPM may also be an option the authors may want to think > about. > > Michael > > From nobody Tue Jun 14 02:06:42 2016 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 2C95912D122; Tue, 14 Jun 2016 02:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Err1Jk0CCoD; Tue, 14 Jun 2016 02:06:33 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9367312D119; Tue, 14 Jun 2016 02:06:30 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3AVVIQRRP4uVYUKmEhn6Ul6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0KfzyrarrMEGX3/hxlliBBdydsKIVzbqN+Pm4EUU7or+/81k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZv?= =?us-ascii?q?IaytQ8iJ35Xxh7v5osWbSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf?= =?us-ascii?q?9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t4XXskyJ?= =?us-ascii?q?ZgKV4nYHGkoRlxdaSy3C6g33WJr+qCyw/r520TOeMNb5Spg5Xyiv6+F2UBSuhS?= =?us-ascii?q?saYW0X6mbS3+V6jKNZqRTpjRx235Lda4GcLutvd+uJdNkaRGhIWIBbVyVdHoq3?= =?us-ascii?q?b4IVHvsIFfpTtM/2oF5Y/kj2PhWlGO66kmwAvXTxx6Bvlr15SQw=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DQAQBHx19X/wQXEqxcDoJigSR9s0qHa?= =?us-ascii?q?4F5FwEMhXMCHIFOFAEBAQEBAQEBgQuCMYIaAQEBAwEBAQEgSwkCBQcECQIHBgQ?= =?us-ascii?q?DAQEBASMEAwICAiUfCQgGCwgbiA0WjC+cNQEBAWWRMAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARyEfmeFD4QcOwmCYYJaBYV7ghKFY3OEYIUggViELIVohCVOhASIZo9?= =?us-ascii?q?yHoJvekNmAYhDgUQBAQE?= X-IPAS-Result: =?us-ascii?q?A2DQAQBHx19X/wQXEqxcDoJigSR9s0qHa4F5FwEMhXMCHIF?= =?us-ascii?q?OFAEBAQEBAQEBgQuCMYIaAQEBAwEBAQEgSwkCBQcECQIHBgQDAQEBASMEAwICA?= =?us-ascii?q?iUfCQgGCwgbiA0WjC+cNQEBAWWRMAEBAQEBAQEBAQEBAQEBAQEBAQEBARyEfme?= =?us-ascii?q?FD4QcOwmCYYJaBYV7ghKFY3OEYIUggViELIVohCVOhASIZo9yHoJvekNmAYhDg?= =?us-ascii?q?UQBAQE?= X-IronPort-AV: E=Sophos;i="5.26,470,1459794600"; d="scan'208";a="93855069" In-Reply-To: References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> To: "Carles Gomez Montenegro" MIME-Version: 1.0 X-KeepSent: 356AAF61:B3857BFE-65257FD2:0031F2E8; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Tue, 14 Jun 2016 14:36:26 +0530 X-MIMETrack: Serialize by Router on InKolM02/TCS(Release 9.0.1FP4HF528 | October 8, 2015) at 06/14/2016 14:36:27, Serialize complete at 06/14/2016 14:36:27 Content-Type: multipart/alternative; boundary="=_alternative 0032076465257FD2_=" Archived-At: Cc: "tcpm@ietf.org Extensions" , "lwip@ietf.org" , "jon.crowcroft@cl.cam.ac.uk" , "core@ietf.org WG" , core Subject: Re: [tcpm] [core] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jun 2016 09:06:36 -0000 This is a multipart message in MIME format. --=_alternative 0032076465257FD2_= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNlY3Rpb24gMy40IG9mIHRoZSBkcmFmdCBzdGF0ZXMgdGhlIGZvbGxvd2luZzoNCg0K Iml0IGlzIGVudmlzYWdlZCB0aGF0IGZ1cnRoZXIgc2VnbWVudCBleGNoYW5nZXMgd2lsbCB0YWtl IHBsYWNlIHdpdGhpbiBhbiANCmludGVydmFsIG9mIHR3byBob3VycyBzaW5jZSB0aGUgbGFzdCBz ZWdtZW50IGhhcyBiZWVuIHNlbnQiDQoNCkNvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiBhIGJpdCBh Ym91dCB0aGUgYmFzaXMgb2Ygc3VjaCBhIGRldGVybWluaXN0aWMgDQphc3N1bXB0aW9uPyBJZiB5 b3UgY291bGQgc2hhcmUgc29tZSBwb2ludGVycyB0byBhbnkgc3R1ZHkgcmVsYXRlZCB0byB0aGlz LiANClRoZXJlIGlzIFJGQyA1MzgyIHdoaWNoIGtpbmQgb2YgbWFuZGF0ZXMgdGhhdCB0aGUgdGlt ZSBvdXQgY2Fubm90IGJlIGxlc3MgDQp0aGFuIDEyNCBtaW51dGVzLiBEb2VzIGl0IGRyaXZlIHRo ZSBhYm92ZSBhc3N1bXB0aW9uPyBIb3dldmVyLCBub3Qgc3VyZSANCmhvdyBtYW55IGltcGxlbWVu dGF0aW9ucyBhZGhlcmVzIHRvIHRoZSB0aW1lIG1lbnRpb25lZCBpbiBSRkMgNTM4Mi4NCg0KSW4g dGhlIHJlY2VudCB0aW1lIEkgaGFkIGJlZW4gbG9va2luZyBhdCB0aGUgZGlmZmVyZW50IGVmZm9y dHMgdGhhdCBoYXMgDQpnb25lIGludG8gaW1wcm92aW5nIFRDUCBwZXJmb3JtYW5jZSBmcm9tIGRp ZmZlcmVudCBhc3BlY3RzIHVuZGVyIGRpZmZlcmVudCANCmNpcmN1bXN0YW5jZXMgc2luY2UgdGhl IGVhcmx5IGRheXMuIEdpdmVuIHRoZSBzaG9ydCB0cmFuc2FjdGlvbmFsIHR5cGUgb2YgDQpleGNo YW5nZXMsIHdvdWxkIGl0IGJlIGFsc28gd29ydGh3aGlsZSB0byBjb3VudCBleHBlcmltZW50YWwg UkZDcyBsaWtlIA0KIlRDUCBGYXN0IE9wZW4iIGFuZCBzZWUgaG93IENvQVAgcGVyZm9ybXMgb24g dG9wIG9mIGl0Pw0KDQpSZWdhcmRzDQpBYmhpamFuIEJoYXR0YWNoYXJ5eWENCkFzc29jaWF0ZSBD b25zdWx0YW50DQpTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYQ0KVGF0 YSBDb25zdWx0YW5jeSBTZXJ2aWNlcw0KTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNz LmNvbQ0KV2Vic2l0ZTogaHR0cDovL3d3dy50Y3MuY29tDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgSVQgU2Vydmlj ZXMNCiAgICAgICAgICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNvbHV0aW9ucw0KICAgICAgICAg ICAgICAgICAgICAgICAgQ29uc3VsdGluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KDQoNCg0KRnJvbTogICAiQ2FybGVzIEdvbWV6IE1vbnRlbmVncm8i IDxjYXJsZXNnb0BlbnRlbC51cGMuZWR1Pg0KVG86ICAgICAiQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Fi b0B0emkub3JnPg0KQ2M6ICAgICAibHdpcEBpZXRmLm9yZyIgPGx3aXBAaWV0Zi5vcmc+LCAidGNw bUBpZXRmLm9yZyBFeHRlbnNpb25zIiANCjx0Y3BtQGlldGYub3JnPiwgImpvbi5jcm93Y3JvZnRA Y2wuY2FtLmFjLnVrIiANCjxqb24uY3Jvd2Nyb2Z0QGNsLmNhbS5hYy51az4sICJjb3JlQGlldGYu b3JnIFdHIiA8Y29yZUBpZXRmLm9yZz4NCkRhdGU6ICAgMDYvMTAvMjAxNiAwODo0MCBQTQ0KU3Vi amVjdDogICAgICAgIFJlOiBbY29yZV0gW3RjcG1dIFtMd2lwXSBbRndkOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gDQpmb3IgZHJhZnQtZ29tZXotY29yZS10Y3AtY29uc3RyYWluZWQtbm9kZS1u ZXR3b3Jrcy0wMC50eHRdDQpTZW50IGJ5OiAgICAgICAgImNvcmUiIDxjb3JlLWJvdW5jZXNAaWV0 Zi5vcmc+DQoNCg0KDQpIaSBDYXJzdGVuLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVu dHMuDQoNCldoaWxlIHdlIHdvcmsgdG8gYWRkcmVzcyB0aG9zZSwgaXQgd291bGQgYmUgcmVhbGx5 IGhlbHBmdWwgaWYgZm9sa3MgdGhhdA0KaGF2ZSBmYWNlZCAnYmFkIGNvbnN0cmFpbmVkIFRDUCBp bXBsZW1lbnRhdGlvbnMnLCBhbmQvb3IgaGF2ZSBzdHJ1Z2dsZWQNCndpdGggbWlkZGxlYm94IHRy YXZlcnNhbCBjYW4gc2hhcmUgdGhlaXIgZXhwZXJpZW5jZS4NCg0KQ2hlZXJzLA0KDQpDYXJsZXMN Cg0KDQo+IENhcmxlcywNCj4NCj4gdGhhbmtzIGZvciBzdWJtaXR0aW5nIHRoaXMuDQo+DQo+IEkg dGhpbmsgdGhhdCB0aGlzIGRyYWZ0IGlzIHRydWx5IGJlc3QgaGFuZGxlZCBpbiBMV0lHLg0KPg0K PiBXZSBkb24ndCAqaGF2ZSogdG8gcHJvZmlsZSBUQ1AgZm9yIENvQVAtb3Zlci1UQ1A7IHBlb3Bs ZSBhcmUgZnJlZSB0byB1c2UNCj4gd2hhdGV2ZXIgcGFydHMgb2YgVENQIHRoZXkgdGhpbmsgYXJl IHVzZWZ1bC4gIChBbmQsIG9mIGNvdXJzZSwgdGhlcmUgYXJlDQo+IGFwcGxpY2F0aW9ucyBmb3Ig Q29BUC1vdmVyLVRDUCB0aGF0IGFyZSBpbiB0aGUgYmFja2VuZC4pDQo+DQo+IE9uIHRoZSBvdGhl ciBoYW5kLCBpdCBpcyB1c2VmdWwgdG8NCj4gLS0gbWFuYWdlIGV4cGVjdGF0aW9uczoNCj4gICAg d2hhdCBjYW4gSSBleHBlY3QgdGhhdCB0aGUgKm90aGVyKiBzaWRlIHdpbGwgb2ZmZXIgaW4gVENQ IA0KZnVuY3Rpb25hbGl0eQ0KPiAtLSBnaXZlIGFkdmljZSB0byBpbXBsZW1lbnRlcnM6DQo+ICAg IHdoYXQgaXMgdXNlZnVsIHRvIGltcGxlbWVudCwgd2hhdCBub3QNCj4gLS0gY29sbGVjdCBpbXBs ZW1lbnRhdGlvbiBleHBlcmllbmNlIHRoYXQgaXMgcmVsZXZhbnQgZm9yIHRoZXNlIHR3bw0KPg0K PiAoT25lIGludGVyZXN0aW5nIGVmZmVjdCBJJ20gc2VlaW5nIGlzIHRoYXQgcGVvcGxlIGtub3cg aG93IGdvb2QgVENQIGNhbg0KPiBiZSwgd2hpY2ggc2hhcGVzIHRoZWlyIGV4cGVjdGF0aW9ucywg YnV0IHRoZW4gdGhleSBhcmUgaHVydCBieSB1c2luZw0KPiByZWFsbHkgYmFkIGNvbnN0cmFpbmVk IFRDUCBpbXBsZW1lbnRhdGlvbnMuLi4gIFdlIGNlcnRhaW5seSBzaG91bGQgYmUNCj4gcGF5aW5n IGF0dGVudGlvbiB0byB0aGlzIG9uIHRoZSBDb1JFIFdHIHNpZGUuKQ0KPg0KPiBNeSBiaWdnZXN0 IGNvbW1lbnQgaXMgcHJvYmFibHkgdGhhdCBmb3IgZGV2aWNlLXRvLWNsb3VkLCB0aGUgbGV2ZWwg b2YNCj4gVENQIGZ1bmN0aW9ucyBpbXBsZW1lbnRlZCB3aWxsIGJlIGFzeW1tZXRyaWMgKGZ1bGwg VENQIG9uIGNsb3VkIHNpZGUsDQo+IHBvc3NpYmx5IG1vcmUgbGltaXRlZCBvbiB0aGUgZGV2aWNl IHNpZGUpIC0tIHdoYXQgaXMgdGhlIGVmZmVjdCBvZiB0aGlzDQo+IGFzeW1tZXRyeT8NCj4NCj4g TWF5YmUgdGhlcmUgYWxzbyBuZWVkcyB0byBiZSBtb3JlIGRpc2N1c3Npb24gb24gdGhlIHJvbGUg b2YgdGhlDQo+IG1pZGRsZWJveCAoYWZ0ZXIgYWxsLCB3ZSBhcmUgZG9pbmcgQ29BUC1vdmVyLVRD UCB0byBkZXZpY2VzIGZvciB0aGUgc29sZQ0KPiByZWFzb24gdG8gY2xpbWIgb3ZlciBtaWRkbGVi b3hlcykuDQo+DQo+IEdyw4PCvMODxbhlLCBDYXJzdGVuDQo+DQo+DQo+IFNjaGFyZiwgTWljaGFl bCAoTm9raWEgLSBERSkgd3JvdGU6DQo+PiBIZWFkcy11cA0KPj4NCj4+IE1pY2hhZWwNCj4+DQo+ Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEx3aXAgW21haWx0bzps d2lwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXJsZXMgR29tZXoNCj4+IE1vbnRl bmVncm8NCj4+IFNlbnQ6IEZyaWRheSwgSnVuZSAxMCwgMjAxNiAxMTozNiBBTQ0KPj4gVG86IGx3 aXBAaWV0Zi5vcmcNCj4+IENjOiBqb24uY3Jvd2Nyb2Z0QGNsLmNhbS5hYy51aw0KPj4gU3ViamVj dDogW0x3aXBdIFtGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+IGRyYWZ0LWdv bWV6LWNvcmUtdGNwLWNvbnN0cmFpbmVkLW5vZGUtbmV0d29ya3MtMDAudHh0XQ0KPj4NCj4+IERl YXIgTFdJRyBXRywNCj4+DQo+PiAvKiogQXBvbG9naWVzIGZvciBwb3NzaWJseSBtdWx0aXBsZSBz aW1pbGFyIGUtbWFpbHMuLi4gKiovDQo+Pg0KPj4gV2UgaGF2ZSBqdXN0IHN1Ym1pdHRlZCB0aGUg ZHJhZnQgZW50aXRsZWQgJ1RDUCBvdmVyIENvbnN0cmFpbmVkLU5vZGUNCj4+IE5ldHdvcmtzJywg d2hpY2ggd2UgYmVsaWV2ZSBtYXkgYmUgb2YgaW50ZXJlc3QgdG8gdGhlIG1lbWJlcnMgb2YgdGhp cw0KPj4gZ3JvdXAuDQo+Pg0KPj4gV2Ugd291bGQgbGlrZSB0byBraW5kbHkgYXNrIGZvciBmZWVk YmFjaywgc3BlY2lhbGx5IG9uIHRoZSBiYXNpcyBvZg0KPj4gaW1wbGVtZW50YXRpb24gZXhwZXJp ZW5jZS4NCj4+DQo+PiBUaGFuayB5b3UgdmVyeSBtdWNoIQ0KPj4NCj4+IEtpbmQgcmVnYXJkcywN Cj4+DQo+PiBUaGUgYXV0aG9ycw0KPj4NCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+IGRyYWZ0LWdvbWV6LWNv cmUtdGNwLWNvbnN0cmFpbmVkLW5vZGUtbmV0d29ya3MtMDAudHh0DQo+PiBGcm9tOiAgICBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+IERhdGU6ICAgIEZyaSwgSnVuZSAxMCwgMjAxNiAxMDoz OCBhbQ0KPj4gVG86ICAgICAgIkpvbiBDcm93Y3JvZnQiIDxqb24uY3Jvd2Nyb2Z0QGNsLmNhbS5h Yy51az4NCj4+ICAgICAgICAgICJDYXJsZXMgR29tZXoiIDxjYXJsZXNnb0BlbnRlbC51cGMuZWR1 Pg0KPj4gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+DQo+PiBBIG5ldyB2ZXJzaW9uIG9mIEkt RCwNCj4+IGRyYWZ0LWdvbWV6LWNvcmUtdGNwLWNvbnN0cmFpbmVkLW5vZGUtbmV0d29ya3MtMDAu dHh0DQo+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IENhcmxlcyBHb21leiBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+PiByZXBvc2l0b3J5Lg0KPj4NCj4+IE5hbWU6IGRyYWZ0 LWdvbWV6LWNvcmUtdGNwLWNvbnN0cmFpbmVkLW5vZGUtbmV0d29ya3MNCj4+IFJldmlzaW9uOiAg ICAgICAgICAgICAwMA0KPj4gVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBU Q1Agb3ZlciBDb25zdHJhaW5lZC1Ob2RlIA0KTmV0d29ya3MNCj4+IERvY3VtZW50IGRhdGU6ICAg ICAgICAgICAgICAgIDIwMTYtMDYtMTANCj4+IEdyb3VwOiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+PiBQYWdlczogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDkNCj4+IFVSTDoNCj4+IA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWdvbWV6LWNvcmUtdGNwLWNvbnN0cmFpbmVkLW5vZGUtbmV0d29y a3MtMDAudHh0DQoNCj4+IFN0YXR1czoNCj4+IA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZ29tZXotY29yZS10Y3AtY29uc3RyYWluZWQtbm9kZS1uZXR3b3Jrcy8NCg0K Pj4gSHRtbGl6ZWQ6DQo+PiANCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nb21l ei1jb3JlLXRjcC1jb25zdHJhaW5lZC1ub2RlLW5ldHdvcmtzLTAwDQoNCj4+DQo+Pg0KPj4gQWJz dHJhY3Q6DQo+PiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgcHJvZmlsZSBmb3IgdGhlIFRy YW5zbWlzc2lvbiBDb250cm9sDQo+PiAgICBQcm90b2NvbCAoVENQKSBvdmVyIENvbnN0cmFpbmVk LU5vZGUgTmV0d29ya3MgKENOTnMpLiAgVGhlDQo+PiAgICBvdmVyYXJjaGluZyBnb2FsIGlzIHRv IG9mZmVyIHNpbXBsZSBtZWFzdXJlcyB0byBhbGxvdyBmb3IgDQpsaWdodHdlaWdodA0KPj4gICAg VENQIGltcGxlbWVudGF0aW9uIGFuZCBzdWl0YWJsZSBvcGVyYXRpb24gaW4gc3VjaCBlbnZpcm9u bWVudHMuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+IHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPj4gdG9vbHMu aWV0Zi5vcmcuDQo+Pg0KPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+DQo+Pg0KPj4NCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBMd2lwIG1h aWxpbmcgbGlzdA0KPj4gTHdpcEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sd2lwDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IHRjcG0gbWFpbGluZyBsaXN0DQo+PiB0Y3BtQGlldGYub3Jn DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCj4+DQo+DQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUg bWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NvcmUNCg0KDQo9PT09PS0tLS0tPT09PT0tLS0tLT09PT09Ck5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbAptZXNzYWdlIGFuZC9vciBhdHRh Y2htZW50cyB0byBpdCBtYXkgY29udGFpbiAKY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24uIElmIHlvdSBhcmUgCm5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlz c2VtaW5hdGlvbiwgdXNlLCAKcmV2aWV3LCBkaXN0cmlidXRpb24sIHByaW50aW5nIG9yIGNvcHlp bmcgb2YgdGhlIAppbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSAK YW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IGFyZSBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiAKeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCAKcGxlYXNlIG5vdGlm eSB1cyBieSByZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCAKaW1tZWRpYXRlbHkgYW5kIHBl cm1hbmVudGx5IGRlbGV0ZSB0aGUgbWVzc2FnZSAKYW5kIGFueSBhdHRhY2htZW50cy4gVGhhbmsg eW91CgoK --=_alternative 0032076465257FD2_= MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U2VjdGlvbiAzLjQgb2YgdGhlIGRyYWZ0IHN0YXRl cyB0aGUNCmZvbGxvd2luZzo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZxdW90OzwvZm9udD48dHQ+PGZvbnQgc2l6ZT0zPml0IGlzDQplbnZpc2FnZWQg dGhhdCBmdXJ0aGVyIHNlZ21lbnQgZXhjaGFuZ2VzIHdpbGwgdGFrZSBwbGFjZSB3aXRoaW4gYW4g aW50ZXJ2YWwNCm9mIHR3byBob3VycyBzaW5jZSB0aGUgbGFzdCBzZWdtZW50IGhhcyBiZWVuIHNl bnQ8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Db3VsZCB5b3UgcGxl YXNlIGV4cGxhaW4gYSBiaXQgYWJvdXQNCnRoZSBiYXNpcyBvZiBzdWNoIGEgZGV0ZXJtaW5pc3Rp YyBhc3N1bXB0aW9uPyBJZiB5b3UgY291bGQgc2hhcmUgc29tZSBwb2ludGVycw0KdG8gYW55IHN0 dWR5IHJlbGF0ZWQgdG8gdGhpcy4gVGhlcmUgaXMgUkZDIDUzODIgd2hpY2gga2luZCBvZiBtYW5k YXRlcw0KdGhhdCB0aGUgdGltZSBvdXQgY2Fubm90IGJlIGxlc3MgdGhhbiAxMjQgbWludXRlcy4g RG9lcyBpdCBkcml2ZSB0aGUgYWJvdmUNCmFzc3VtcHRpb24/IEhvd2V2ZXIsIG5vdCBzdXJlIGhv dyBtYW55IGltcGxlbWVudGF0aW9ucyBhZGhlcmVzIHRvIHRoZSB0aW1lDQptZW50aW9uZWQgaW4g UkZDIDUzODIuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5JbiB0aGUgcmVjZW50IHRpbWUgSSBoYWQgYmVlbiBsb29raW5nDQphdCB0aGUgZGlmZmVyZW50 IGVmZm9ydHMgdGhhdCBoYXMgZ29uZSBpbnRvIGltcHJvdmluZyBUQ1AgcGVyZm9ybWFuY2UgZnJv bQ0KZGlmZmVyZW50IGFzcGVjdHMgdW5kZXIgZGlmZmVyZW50IGNpcmN1bXN0YW5jZXMgc2luY2Ug dGhlIGVhcmx5IGRheXMuIEdpdmVuDQp0aGUgc2hvcnQgdHJhbnNhY3Rpb25hbCB0eXBlIG9mIGV4 Y2hhbmdlcywgd291bGQgaXQgYmUgYWxzbyB3b3J0aHdoaWxlDQp0byBjb3VudCBleHBlcmltZW50 YWwgUkZDcyBsaWtlICZxdW90O1RDUCBGYXN0IE9wZW4mcXVvdDsgYW5kIHNlZSBob3cgQ29BUA0K cGVyZm9ybXMgb24gdG9wIG9mIGl0PzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+UmVnYXJkczxicj4NCkFiaGlqYW4gQmhhdHRhY2hhcnl5YTxicj4NCkFz c29jaWF0ZSBDb25zdWx0YW50PGJyPg0KU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0 YSwgSW5kaWE8YnI+DQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzPGJyPg0KTWFpbHRvOiBhYmhp amFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTxicj4NCldlYnNpdGU6IDwvZm9udD48YSBocmVmPWh0 dHA6Ly93d3cudGNzLmNvbS8+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly93 d3cudGNzLmNvbTwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRXhwZXJp ZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDb25zdWx0aW5nPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RnJv bTogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+JnF1b3Q7Q2FybGVzIEdvbWV6DQpNb250ZW5lZ3JvJnF1b3Q7ICZsdDtjYXJs ZXNnb0BlbnRlbC51cGMuZWR1Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5UbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Q2Fyc3RlbiBCb3JtYW5u JnF1b3Q7DQombHQ7Y2Fib0B0emkub3JnJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29s b3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5DYzogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bHdpcEBpZXRm Lm9yZyZxdW90Ow0KJmx0O2x3aXBAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDt0Y3BtQGlldGYub3JnIEV4 dGVuc2lvbnMmcXVvdDsgJmx0O3RjcG1AaWV0Zi5vcmcmZ3Q7LA0KJnF1b3Q7am9uLmNyb3djcm9m dEBjbC5jYW0uYWMudWsmcXVvdDsgJmx0O2pvbi5jcm93Y3JvZnRAY2wuY2FtLmFjLnVrJmd0OywN CiZxdW90O2NvcmVAaWV0Zi5vcmcgV0cmcXVvdDsgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkRhdGU6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjA2LzEwLzIwMTYgMDg6NDAgUE08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNv bG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDogJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtjb3Jl XSBbdGNwbV0NCltMd2lwXSBbRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWdvbWV6LWNvcmUtdGNwLWNvbnN0cmFpbmVkLW5vZGUtbmV0d29ya3MtMDAudHh0XTwvZm9udD4N Cjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5TZW50IGJ5 OiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mcXVvdDtjb3JlJnF1b3Q7DQombHQ7Y29yZS1ib3VuY2VzQGlldGYub3JnJmd0 OzwvZm9udD4NCjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+SGkgQ2Fyc3Rlbiw8YnI+DQo8YnI+DQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVu dHMuPGJyPg0KPGJyPg0KV2hpbGUgd2Ugd29yayB0byBhZGRyZXNzIHRob3NlLCBpdCB3b3VsZCBi ZSByZWFsbHkgaGVscGZ1bCBpZiBmb2xrcyB0aGF0PGJyPg0KaGF2ZSBmYWNlZCAnYmFkIGNvbnN0 cmFpbmVkIFRDUCBpbXBsZW1lbnRhdGlvbnMnLCBhbmQvb3IgaGF2ZSBzdHJ1Z2dsZWQ8YnI+DQp3 aXRoIG1pZGRsZWJveCB0cmF2ZXJzYWwgY2FuIHNoYXJlIHRoZWlyIGV4cGVyaWVuY2UuPGJyPg0K PGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCkNhcmxlczxicj4NCjxicj4NCjxicj4NCiZndDsgQ2Fy bGVzLDxicj4NCiZndDs8YnI+DQomZ3Q7IHRoYW5rcyBmb3Igc3VibWl0dGluZyB0aGlzLjxicj4N CiZndDs8YnI+DQomZ3Q7IEkgdGhpbmsgdGhhdCB0aGlzIGRyYWZ0IGlzIHRydWx5IGJlc3QgaGFu ZGxlZCBpbiBMV0lHLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGRvbid0ICpoYXZlKiB0byBwcm9m aWxlIFRDUCBmb3IgQ29BUC1vdmVyLVRDUDsgcGVvcGxlIGFyZSBmcmVlDQp0byB1c2U8YnI+DQom Z3Q7IHdoYXRldmVyIHBhcnRzIG9mIFRDUCB0aGV5IHRoaW5rIGFyZSB1c2VmdWwuICZuYnNwOyhB bmQsIG9mIGNvdXJzZSwNCnRoZXJlIGFyZTxicj4NCiZndDsgYXBwbGljYXRpb25zIGZvciBDb0FQ LW92ZXItVENQIHRoYXQgYXJlIGluIHRoZSBiYWNrZW5kLik8YnI+DQomZ3Q7PGJyPg0KJmd0OyBP biB0aGUgb3RoZXIgaGFuZCwgaXQgaXMgdXNlZnVsIHRvPGJyPg0KJmd0OyAtLSBtYW5hZ2UgZXhw ZWN0YXRpb25zOjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3doYXQgY2FuIEkgZXhwZWN0IHRoYXQg dGhlICpvdGhlciogc2lkZSB3aWxsIG9mZmVyIGluDQpUQ1AgZnVuY3Rpb25hbGl0eTxicj4NCiZn dDsgLS0gZ2l2ZSBhZHZpY2UgdG8gaW1wbGVtZW50ZXJzOjxicj4NCiZndDsgJm5ic3A7ICZuYnNw O3doYXQgaXMgdXNlZnVsIHRvIGltcGxlbWVudCwgd2hhdCBub3Q8YnI+DQomZ3Q7IC0tIGNvbGxl Y3QgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSB0aGF0IGlzIHJlbGV2YW50IGZvciB0aGVzZSB0 d288YnI+DQomZ3Q7PGJyPg0KJmd0OyAoT25lIGludGVyZXN0aW5nIGVmZmVjdCBJJ20gc2VlaW5n IGlzIHRoYXQgcGVvcGxlIGtub3cgaG93IGdvb2QgVENQDQpjYW48YnI+DQomZ3Q7IGJlLCB3aGlj aCBzaGFwZXMgdGhlaXIgZXhwZWN0YXRpb25zLCBidXQgdGhlbiB0aGV5IGFyZSBodXJ0IGJ5IHVz aW5nPGJyPg0KJmd0OyByZWFsbHkgYmFkIGNvbnN0cmFpbmVkIFRDUCBpbXBsZW1lbnRhdGlvbnMu Li4gJm5ic3A7V2UgY2VydGFpbmx5IHNob3VsZA0KYmU8YnI+DQomZ3Q7IHBheWluZyBhdHRlbnRp b24gdG8gdGhpcyBvbiB0aGUgQ29SRSBXRyBzaWRlLik8YnI+DQomZ3Q7PGJyPg0KJmd0OyBNeSBi aWdnZXN0IGNvbW1lbnQgaXMgcHJvYmFibHkgdGhhdCBmb3IgZGV2aWNlLXRvLWNsb3VkLCB0aGUg bGV2ZWwNCm9mPGJyPg0KJmd0OyBUQ1AgZnVuY3Rpb25zIGltcGxlbWVudGVkIHdpbGwgYmUgYXN5 bW1ldHJpYyAoZnVsbCBUQ1Agb24gY2xvdWQgc2lkZSw8YnI+DQomZ3Q7IHBvc3NpYmx5IG1vcmUg bGltaXRlZCBvbiB0aGUgZGV2aWNlIHNpZGUpIC0tIHdoYXQgaXMgdGhlIGVmZmVjdCBvZg0KdGhp czxicj4NCiZndDsgYXN5bW1ldHJ5Pzxicj4NCiZndDs8YnI+DQomZ3Q7IE1heWJlIHRoZXJlIGFs c28gbmVlZHMgdG8gYmUgbW9yZSBkaXNjdXNzaW9uIG9uIHRoZSByb2xlIG9mIHRoZTxicj4NCiZn dDsgbWlkZGxlYm94IChhZnRlciBhbGwsIHdlIGFyZSBkb2luZyBDb0FQLW92ZXItVENQIHRvIGRl dmljZXMgZm9yIHRoZQ0Kc29sZTxicj4NCiZndDsgcmVhc29uIHRvIGNsaW1iIG92ZXIgbWlkZGxl Ym94ZXMpLjxicj4NCiZndDs8YnI+DQomZ3Q7IEdyw4PCvMODxbhlLCBDYXJzdGVuPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFNjaGFyZiwgTWljaGFlbCAoTm9raWEgLSBERSkgd3JvdGU6 PGJyPg0KJmd0OyZndDsgSGVhZHMtdXA8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE1pY2hh ZWw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiBMd2lwIFs8L2ZvbnQ+PC90dD48YSBo cmVmPSJtYWlsdG86bHdpcC1ib3VuY2VzQGlldGYub3JnIj48dHQ+PGZvbnQgc2l6ZT0yPm1haWx0 bzpsd2lwLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj5d DQpPbiBCZWhhbGYgT2YgQ2FybGVzIEdvbWV6PGJyPg0KJmd0OyZndDsgTW9udGVuZWdybzxicj4N CiZndDsmZ3Q7IFNlbnQ6IEZyaWRheSwgSnVuZSAxMCwgMjAxNiAxMTozNiBBTTxicj4NCiZndDsm Z3Q7IFRvOiBsd2lwQGlldGYub3JnPGJyPg0KJmd0OyZndDsgQ2M6IGpvbi5jcm93Y3JvZnRAY2wu Y2FtLmFjLnVrPGJyPg0KJmd0OyZndDsgU3ViamVjdDogW0x3aXBdIFtGd2Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3I8YnI+DQomZ3Q7Jmd0OyBkcmFmdC1nb21lei1jb3JlLXRjcC1jb25z dHJhaW5lZC1ub2RlLW5ldHdvcmtzLTAwLnR4dF08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IERlYXIgTFdJRyBXRyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC8qKiBBcG9sb2dpZXMg Zm9yIHBvc3NpYmx5IG11bHRpcGxlIHNpbWlsYXIgZS1tYWlscy4uLiAqKi88YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IFdlIGhhdmUganVzdCBzdWJtaXR0ZWQgdGhlIGRyYWZ0IGVudGl0bGVk ICdUQ1Agb3ZlciBDb25zdHJhaW5lZC1Ob2RlPGJyPg0KJmd0OyZndDsgTmV0d29ya3MnLCB3aGlj aCB3ZSBiZWxpZXZlIG1heSBiZSBvZiBpbnRlcmVzdCB0byB0aGUgbWVtYmVycw0Kb2YgdGhpczxi cj4NCiZndDsmZ3Q7IGdyb3VwLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2Ugd291bGQg bGlrZSB0byBraW5kbHkgYXNrIGZvciBmZWVkYmFjaywgc3BlY2lhbGx5IG9uIHRoZSBiYXNpcw0K b2Y8YnI+DQomZ3Q7Jmd0OyBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlLjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgVGhhbmsgeW91IHZlcnkgbXVjaCE8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IEtpbmQgcmVnYXJkcyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBhdXRo b3JzPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZTxicj4NCiZndDsmZ3Q7IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yPGJyPg0KJmd0OyZndDsgZHJhZnQtZ29tZXotY29yZS10Y3AtY29uc3Ry YWluZWQtbm9kZS1uZXR3b3Jrcy0wMC50eHQ8YnI+DQomZ3Q7Jmd0OyBGcm9tOiAmbmJzcDsgJm5i c3A7aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPGJyPg0KJmd0OyZndDsgRGF0ZTogJm5ic3A7ICZu YnNwO0ZyaSwgSnVuZSAxMCwgMjAxNiAxMDozOCBhbTxicj4NCiZndDsmZ3Q7IFRvOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZxdW90O0pvbiBDcm93Y3JvZnQmcXVvdDsgJmx0O2pvbi5jcm93Y3JvZnRA Y2wuY2FtLmFjLnVrJmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmcXVvdDtDYXJsZXMgR29tZXomcXVvdDsgJmx0O2Nhcmxlc2dvQGVudGVsLnVwYy5l ZHUmZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsPGJyPg0KJmd0OyZn dDsgZHJhZnQtZ29tZXotY29yZS10Y3AtY29uc3RyYWluZWQtbm9kZS1uZXR3b3Jrcy0wMC50eHQ8 YnI+DQomZ3Q7Jmd0OyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IENhcmxlcyBH b21leiBhbmQgcG9zdGVkIHRvDQp0aGUgSUVURjxicj4NCiZndDsmZ3Q7IHJlcG9zaXRvcnkuPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBOYW1lOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtkcmFmdC1nb21lei1jb3JlLXRj cC1jb25zdHJhaW5lZC1ub2RlLW5ldHdvcmtzPGJyPg0KJmd0OyZndDsgUmV2aXNpb246ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IDAwPGJy Pg0KJmd0OyZndDsgVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO1RDUCBvdmVyIENvbnN0cmFpbmVkLU5vZGUgTmV0d29y a3M8YnI+DQomZ3Q7Jmd0OyBEb2N1bWVudCBkYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAyMDE2LTA2LTEwPGJyPg0KJmd0OyZndDsg R3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwO0luZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NCiZndDsmZ3Q7IFBhZ2VzOiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDs5PGJyPg0KJmd0OyZndDsgVVJMOjxicj4NCiZndDsmZ3Q7IDwvZm9udD48L3R0PjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nb21lei1jb3Jl LXRjcC1jb25zdHJhaW5lZC1ub2RlLW5ldHdvcmtzLTAwLnR4dCI+PHR0Pjxmb250IHNpemU9Mj5o dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZ29tZXotY29yZS10Y3At Y29uc3RyYWluZWQtbm9kZS1uZXR3b3Jrcy0wMC50eHQ8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250 IHNpemU9Mj48YnI+DQomZ3Q7Jmd0OyBTdGF0dXM6PGJyPg0KJmd0OyZndDsgPC9mb250PjwvdHQ+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ29tZXotY29y ZS10Y3AtY29uc3RyYWluZWQtbm9kZS1uZXR3b3Jrcy8iPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ29tZXotY29yZS10Y3AtY29uc3RyYWlu ZWQtbm9kZS1uZXR3b3Jrcy88L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQom Z3Q7Jmd0OyBIdG1saXplZDo8YnI+DQomZ3Q7Jmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ29tZXotY29yZS10Y3AtY29uc3RyYWluZWQt bm9kZS1uZXR3b3Jrcy0wMCI+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZ29tZXotY29yZS10Y3AtY29uc3RyYWluZWQtbm9kZS1uZXR3b3Jrcy0wMDwv Zm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7VGhp cyBkb2N1bWVudCBwcm92aWRlcyBhIHByb2ZpbGUgZm9yIHRoZSBUcmFuc21pc3Npb24NCkNvbnRy b2w8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7UHJvdG9jb2wgKFRDUCkgb3ZlciBDb25zdHJh aW5lZC1Ob2RlIE5ldHdvcmtzIChDTk5zKS4NCiZuYnNwO1RoZTxicj4NCiZndDsmZ3Q7ICZuYnNw OyAmbmJzcDtvdmVyYXJjaGluZyBnb2FsIGlzIHRvIG9mZmVyIHNpbXBsZSBtZWFzdXJlcyB0byBh bGxvdw0KZm9yIGxpZ2h0d2VpZ2h0PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO1RDUCBpbXBs ZW1lbnRhdGlvbiBhbmQgc3VpdGFibGUgb3BlcmF0aW9uIGluIHN1Y2gNCmVudmlyb25tZW50cy48 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lDQpvZjxicj4NCiZndDsmZ3Q7IHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdDxicj4NCiZndDsmZ3Q7 IHRvb2xzLmlldGYub3JnLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIElFVEYgU2Vj cmV0YXJpYXQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsmZ3Q7IEx3aXAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgTHdpcEBpZXRmLm9y Zzxicj4NCiZndDsmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sd2lwPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sd2lwPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+ PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IHRjcG0gbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyZndDsgdGNwbUBpZXRmLm9yZzxicj4NCiZndDsmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9 aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPjx0dD48Zm9udCBzaXpl PTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPC9mb250PjwvdHQ+ PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KPGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpjb3JlIG1haWxpbmcgbGlzdDxicj4NCmNvcmVAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48 YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZT48dHQ+PGZv bnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwvZm9u dD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPHA+ PT09PT0tLS0tLT09PT09LS0tLS09PT09PTxicj4KTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgZS1tYWlsPGJyPgptZXNzYWdlIGFuZC9vciBhdHRhY2htZW50cyB0byBp dCBtYXkgY29udGFpbiA8YnI+CmNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u LiBJZiB5b3UgYXJlIDxicj4Kbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNzZW1p bmF0aW9uLCB1c2UsIDxicj4KcmV2aWV3LCBkaXN0cmlidXRpb24sIHByaW50aW5nIG9yIGNvcHlp bmcgb2YgdGhlIDxicj4KaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1lc3Nh Z2UgPGJyPgphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQu IElmIDxicj4KeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCA8 YnI+CnBsZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIG9yIHRlbGVwaG9uZSBhbmQgPGJy PgppbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlIDxicj4KYW5k IGFueSBhdHRhY2htZW50cy4gVGhhbmsgeW91PC9wPgoKPHA+PC9wPg== --=_alternative 0032076465257FD2_=-- From nobody Wed Jun 15 11:16:43 2016 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 DF95912DAC4; Wed, 15 Jun 2016 11:16:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615181638.26074.30554.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 11:16:38 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 18:16:39 -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 of the IETF. Title : Retransmission Timeout Requirements Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-04.txt Pages : 10 Date : 2016-06-15 Abstract: Ensuring reliable communication often manifests in a timeout and retry mechanism. Each implementation of a retransmission timeout mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations. This document provides high-level requirements for retransmission timeout schemes appropriate for general use in the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. Terminology The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 15 11:20:49 2016 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 3683512DAE6; Wed, 15 Jun 2016 11:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZ_o7baesiGR; Wed, 15 Jun 2016 11:20:35 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3E812DADD; Wed, 15 Jun 2016 11:20:34 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5FIKS2G012768; Wed, 15 Jun 2016 11:20:29 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5C4144C3A4BF; Wed, 15 Jun 2016 14:21:06 -0400 (EDT) To: gorry@erg.abdn.ac.uk From: Mark Allman In-Reply-To: <575BBC10.3080905@abdn.ac.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Honky Tonk Woman X-URL-0: http://www.icir.org/mallman-files/Document93975.doc X-URL-1: http://www.icir.org/mallman-files/Document23723.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 15 Jun 2016 14:21:06 -0400 Message-ID: <52397.1466014866@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org, tsvwg@ietf.org Subject: Re: [tcpm] Some comments on draft-ietf-tcpm-rto-consider-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 18:20:42 -0000 --=-------459435943823349593450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Gorry! Responses to Gorry's lengthy feedback (thanks!) inline. Also, I have issued an -04 that takes into account this feedback and offline conversations with Gorry, David and others. It is available now: The whole draft has undergone some editing, but sections 1 & 2 could use some review. (Although the entire document is short, so if you can, please look it over.) https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ http://www.icir.org/mallman/pubs/All16a/ Comments, please! allman > * Introduction/Scope. Re-worked substantially. > * Comments on the recommendations >=20 > - Some of these comments relate I think to assumptions about TCP > specifics, that could be generalised, or may be handed in the > introduction. >=20 > (1) > "the > RTO MUST be conservatively set to no less than 1 second." > - If this is TCP or SCTP, then RTO is defined. If more is intended > RTO needs to have been defined. New intro defines it. > " For instance, consider a DNS request from a client to a > resolver. When the request can be served from the resolver's > cache the FT likely well approximates the network RTT between > the client and resolver. However, on a cache miss the resolver > will have to request the needed information from authoritative > DNS servers, which will non-trivially increase the FT and > therefore the FT between the client and resolver does not well > match the network-based RTT between the two hosts." >=20 > - If the transport is assumed as DNS/UDP, this needs to be said in > the example, up until this point the ID only discusses TCP and > clearly DNS/TCP does not have this concern. Yes, implicit assumption of UDP. Now explicit. Good catch. Thanks.=20 > " (b) FT observations MUST be taken regularly." I have re-factored the text a bit in -04. You might like it better. I think it reads better. Although the intent did not change. > - The language below seems inappropriate in a MUST clause, I think > this implies it is a SHOULD, and the exception conditions do need to > be discussed, since the period isn't stated, how is this normative > requirement to be interpreted? I guess I don't follow. I read this as "you MUST take FT samples regularly" and "regularly SHOULD be once / RTT (or as often as you exchange data if less frequently than once / RTT". I.e., the MUST and the SHOULD are about different things. I tried to make the words more clearly delineate this in -04. > - Maybe this text needs clarification: The current wording > requirement could be read to contradict RFC5405, that avoids against > sending UDP probes and traffic when an application is idle. This > needs more careful explanation. Even for TCP/SCTP, I would not > advocate requiring keep-alive or heartbeat packets as suggested by > "the requirement that the FT be sampled continuously throughout the > lifetime of a connection." See below (where you return to this issue). > "For the purpose of this > requirement, we state that FT samples SHOULD be taken at > least once per RTT or as frequently as data is exchanged and > ACKed if that happens less frequently than every RTT." > and later: > " Hence, this once-per-RTT sampling requirement is explicitly > a "SHOULD" and not a "MUST". >=20 > " However, we also recognize that it may not always be > practical to take a FT sample this often in all cases." >=20 > -I agree with the =E2=80=9CSHOULD=E2=80=9D from the perspective of TCP, s= ome methods > respond more slowly to congestion that TCP, and sample less > often. How does this relate to the various repair mechanisms in RTP? > (they also can have timers and retransmit) - are these counter > examples where the SHOULD does not apply? This isn't about how often we respond to congestion. That is orthogonal to this document. We are trying to schedule retransmissions. So, what we really want to know---and I think this is now better defined in the intro text you have seen---is how long we should await delivery confirmation before tripping a retransmit. That confirmation could be dictated by the network RTT. Or, be longer than that depending on protocol operation. That is why the document uses "FT" and not "RTT". So, I am not sure where you're going here with the congestion responses. > =E2=80=9C(c) FT samples used in the computation of the RTO MUST NOT be > ambiguous.=E2=80=9D >=20 > - I read this requirement is on the samples. That's not > correct. Maybe it should be > more like: > "An RTO algorithm MUST NOT use FT samples that are ambiguous when > calculating the RTO." I changed it to this in -04: (d) An RTO mechanism MUST NOT use ambiguous FT samples. ( (c) is now something else---see below---and so this changed to (d) ) > - I wonder if section 3 could also talk about other ways to measure > RTTs when not sending data, such as keepalive and SCTP heartbeat > messages. We don't always care about measuring RTTs. So, we have to be careful here, but I have added a 2(c) in section 3 on this topic. It says: (c) FT observations MAY be taken from non-data exchanges. Some protocols use keepalives, heartbeats or other messages to exchange control information. To the extent that the latency of these transactions mirrors data exchange, they can be leveraged to take FT samples within the RTO mechanism. Such samples can help protocols keep their RTO accurate during lulls in data transmission. However, given that these messages may not be subject to the same delays as data transmission, we do not take a general view on whether this is useful or not. > "The backoff may be removed > after the successful transmission of non-retransmitted data." >=20 > - The "may" appears to be protocol permission, can it be "MAY=E2=80=9D? I think this comes from 6298 wording---which I just checked and is not in protocol permission language. I think you're correct here. I have changed it in -04 to be more precise all the way around: The backoff SHOULD be removed after the successful repair of the lost data and subsequent transmission of non-retransmitted data. > " A maximum value MAY be placed on the RTO provided it is at least > 60 seconds (a la [RFC6298])." >=20 > - To me, there seem to be two requirements here: >=20 > " A maximum value MAY be placed on the RTO. The maximum MUST NOT exceed > 60 seconds (as in [RFC6298])." Sounds reasonable. And, especially so since you mis-understood it and translated it wrong! :) The version in -04 is ... A maximum value MAY be placed on the RTO. The maximum RTO MUST NOT be less than 60 seconds (a la [RFC6298]). > (4) "An exception is made to this rule if an IETF standardized > mechanism is used to determine that a particular loss is due to > a non-congestion event (e.g., packet corruption)." >=20 > - NiT: I wonder if this can be mis-cited? There are as yet no specs > in the space published in the RFC series. Could we be more careful > on endorsing this work, and say perhaps that "exceptions could be > made to this rule if an IETF standardized ... . Good call. I made this change. > "Additionally, > RTO-triggered congestion control actions may be reversed when a > standard mechanism determines that the cause of the loss was not > congestion after all." >=20 > - Examples from the RFC series exist, and would be good. E.g. Eifel > or something else? I added an "(e.g., [RFC5682])". Good call. > - Is this the place to define "spurious", since this is used later. Hm. I was trying to figure out how to cleanly wedge that in, but I couldn't find something I liked. Instead I tweaked the intro at the first use of "spurious". > " We note that research has shown the tension between the > responsiveness and correctness of retransmission timeouts seems to > be a fundamental tradeoff [AP99]." > - I think this paper is about TCP, and I think the tension is clear > for protocols like TCP. I added a note. > "While the implication of these deviations > from the standard may be more spurious retransmits (per [AP99]), we > are aware of no large scale problems caused by this change to the > minimum RTO." >=20 > - I'd like to argue that a lower RTO can reduce performance for > paths where this RTO can be set below the RTT. Such paths do exist, > and middleboxes sometimes split TCP connections to overcome this > issue. I think at least the ID should note the issue, even if it > claims that these paths are somehow accommodated within the > guidance. I do not quite understand this. I am not conjuring a case where the timeout could ever be less than the RTT.=20=20 A middlebox can split the TCP connection so we end up with two connections A<->M and M<->B. Are you considering the "RTT" to be A<->B and are then saying A can actually retransmit based on the A<->M delay? Sure. But, in this case I am not sure how A's TCP will ever know the A<->B "RTT". For non-TCP protocols that have a higher layer delivery confirmation mechanism that comes from B I could see this. However, in this case, I am not sure how we'd know to retransmit on A<->M timescales. Basically I am confused here. I am happy to address this if you can explain to me what you mean. > * Standards status and RFC 2119 recommendations. >=20 > "nor limit future standardization of specific RTO mechanisms." > - I'd need advice, but I thought BCPs did exactly this. Paraphrasing > slightly, the purpose of the RFC5405 was to impose default > constraints that future RFCs have to justify their choices > against. That's limiting. The MUSTs are real requirements and the > SHOULD strong desirables. The feedback we have to the RFC5405.bis is > to stengthen more SHOULDs to MUSTs - I'm going to speak to my ADs > before I agree to any of these. But if the IESG agree, then I think > that is what BCP status is about. >=20 > Scope (a) I don=E2=80=99t disagree, unless the community explicity update= s a > spec a new BCP doesn't change old RFCs. >=20 > Scope (v) - To me seems weird. Because it seems to set a "SHOULD" > over the entire document, and that document contains MUSTs. I can't > see how an RFC can have a "SHOULD-MUST", but likely the ADs can > advise during WGLC. (This has all been removed / changed in a big way. So, I am not commenting on it.) > I worry the following can be cited elsewhere as compliance of a > protocol or mechanism by the IETF, when really I think this is > intended to define an acceptable RTO response. Some tightening of > the language would seem appropriate: >=20 > "RTO mechanisms that are not standardized but adhere to the > requirements in the following section are deemed consistent with > the standards. " > - sounds dangerously wide when cited as text - I was presuming the > document intended "are deemed consistent with > the standards in the RTO behaviour" - or something, I presume you > don't want people to cite this RFC saying their new protocol foo-bar > is "consistent with IETF standards" because it does this. >=20 > "an implementation is considered standards compliant" > - I quibble again here on language, because I don't think this is > true generally of the protocol, only true of their RTO response. (This has all been removed / changed in a big way. So, I am not commenting on it.) > "In other words, the requirements in this document can be viewed as > specifying the default properties of an RTO mechanism." > - This seems like an informational statement that could be cited as > a contradiction to the RFC2119 text unless worded carefully? This > sort of text needs AD advice if kept. >=20 > "Specifications can more concretely nail down specifics within these > defaults or work outside the defaults as necessary." > - The same comment on the second half of this sentence. I removed the word "default" from the document. I think the last paragraph of the intro better addresses things now. > "That is, this document's > stance is to not limit the community's ability to make exceptions > to the requirements herein for particular cases." > - If this is BCP, I think this needs to be tighter, I don't think > any ID can expect to automatically make exceptions to a BCP, by > simply saying "the WG decided differently" if you want that, then I > think this document needs to be INFO (I'm not the Chair or AD for > the document). If it's BCP, I'd expect the consensus to set the best > current practice and the ADs to block new RFCs with at least a > DISCUSS to work out why WG XXX was going against what has been IETF > consensus. I don't think you can go info and make the same sort of requirements. I don't really disagree with what you say. I.e., I would expect that if this were a BCP that it would be taken into account when designing RTOs. And, if something wanted to be more aggressive or do something outside the requirements that this be done explicitly with the BCP text as context. I.e., I would expect that the WG would consider this and have an answer for why the deviation is OK far before it hits the IESG. > "However, > implementations that fall within the defaults do not require > explicit specifications to be considered consistent with the > standards." > - I could not parse this sentence, it sounds like it could be > normative language without a keyword. Text is gone in -04. > Section 3: >=20 > "We now list the requirements that SHOULD apply when designing > retransmission timeout (RTO) mechanisms." > - this seems to scope a "MUST" with a preceding "SHOULD". I question > if this is allowed in a BCP. I understand what is meant. But, it is not important enough in this instance to argue about, IMO, and so I nuked the SHOULD normative language from the beginning of section 3. --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldhnI8ACgkQWyrrWs4yIs5BvACggU2U8DRtvGil7m1+NQgL6nHA P2sAnRuE63zaJTFZE7hHmmjqaqKjSU36 =rVR8 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Jun 15 16:13:47 2016 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 6EC8212D0C8; Wed, 15 Jun 2016 16:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 AWXJqR-eKqwW; Wed, 15 Jun 2016 16:13:45 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 30F6E12D7F2; Wed, 15 Jun 2016 16:13:45 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5FNDhBN010622 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jun 2016 19:13:44 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5FNDhBN010622 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466032424; bh=jMRpurX7nmt4Gns5nx5+wvdtw00=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=L5FtVXPWjjapjZo7/SKgnZhq66GElxva+Kmx0mf9A/rsfaLowPy6VIdTbtWT3mfQW CbUUsm01mF5db8LAvqyNByxKgkDp9q3P6+REbl8w1uAd5oipUyBPWgNiY9RL8PuLIz 8LDMUXMYTQEPPrZ8ilR0IA6jKI0dvrM1HRSf5iHU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u5FNDhBN010622 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 15 Jun 2016 19:13:41 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5FNDeN9010712 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 15 Jun 2016 19:13:41 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0266.001; Wed, 15 Jun 2016 19:13:40 -0400 From: "Black, David" To: "tsvwg@ietf.org" , "tcpm@ietf.org" Thread-Topic: draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AdHHW4z/q0muU6tJRV2lEuM6JS3YNQ== Date: Wed, 15 Jun 2016 23:13:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.54] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" Subject: [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 23:13:46 -0000 First off, I want to thank Mark for all the work invested in the -04 versio= n of this draft - in particular, the new scope statements (S.1 - S.6) in Section= 2 are important clarifications of what this draft does and what it does not d= o, so I'm pleased to see them, thank you. As Mark noted, there have been some extensive offline conversations. The purpose of this email is to surface one focal point of those conversati= ons so that we can get to and record some form of agreement on the public lists= . This concerns (R.3) in Section 2 of the -04: (R.3) Alternatively, future RTO mechanism implementations may be made directly against the requirements in Section 3 without another protocol-specific specification. The focal point was ensuring that (R.3) does not conflict with (R.1) earlie= r in Section 2: (R.1) RTO mechanisms that are currently standardized are not updated=20 or obsoleted by this document. Implementations are free to use these existing specifications as they do now. IMHO, all the participants in the offline discussion agree that the first s= entence of (R.1) is 100% correct as stated (e.g., as this draft does not propose to update any RFCs). In 20/20 hindsight, the offline discussion was mostly about word choice and order in (R.3). I think (R.3) is ok as is in -04, but it contains a small ambiguity (does "= future" modify "RTO mechanism" or "implementations"?) that would benefit from a small editorial clarification to make it clear that "future" modifies "RTO mechanisms": (R.3) Alternatively, implementations of future RTO mechanisms may be made directly against the requirements in Section 3 without another protocol-specific specification. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0=20 ---------------------------------------------------- From nobody Thu Jun 16 05:06:55 2016 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 F287912D532; Thu, 16 Jun 2016 05:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFeVn9J9zCsT; Thu, 16 Jun 2016 05:06:53 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09FB112D520; Thu, 16 Jun 2016 05:06:53 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5GC6pou008942; Thu, 16 Jun 2016 05:06:51 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 467194C7C3DB; Thu, 16 Jun 2016 08:07:33 -0400 (EDT) To: "Black\, David" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Blue on Black X-URL-0: http://www.icir.org/mallman-files/Document81055.jpg X-URL-1: http://www.icir.org/mallman-files/Document50253.doc X-URL-2: http://www.icir.org/mallman-files/Document83738.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 16 Jun 2016 08:07:33 -0400 Message-ID: <28607.1466078853@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 12:06:54 -0000 --=-------459435943823349593450 Content-Type: text/plain > (R.3) Alternatively, implementations of future RTO mechanisms may be > made directly against the requirements in Section 3 without > another protocol-specific specification. I am fine with this wording and have made a note to use it in -05 (modulo any further comments that roll in, of course). Thanks, allman -- http://www.icir.org/mallman/ --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldiloIACgkQWyrrWs4yIs6rTACfVrBYISpS9qhUr/gOg2xf2u/S gjgAnisSXVHrz2sM/GEhaREkrEcUDB8E =KYe8 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 04:41:35 2016 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 D6A4612D10C; Fri, 17 Jun 2016 04:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 qX-wQQVCmueP; Fri, 17 Jun 2016 04:41:31 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC88E12D104; Fri, 17 Jun 2016 04:41:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F0CFFD9305; Fri, 17 Jun 2016 13:41:27 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id latcIjV43XMC; Fri, 17 Jun 2016 13:41:27 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AA67ED9304; Fri, 17 Jun 2016 13:41:27 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <28607.1466078853@lawyers.icir.org> Date: Fri, 17 Jun 2016 13:41:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <28607.1466078853@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Black, David" , "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 11:41:34 -0000 Hi Mark, witting as an individual contributor.=20 First of all, thanks for the update! I think it reads much better now. = There are 2-3 MUST and SHOULD which we could further discuss, but I = don=E2=80=99t think that is anything big and I=E2=80=99ll defer this to = later. I have a personal opinion on the point below (R-3). I think this point = is just not needed. I say this not because I don=E2=80=99t agree with = the statement but spelling this out in an RFC, to me, contradict the = point of the RFC. I know this point is important for you but let me = further explain.=20 To me I don=E2=80=99t have a problem if people do implement something = that is not standard conform. Especially in transport where there are a = lot of things that don=E2=80=99t have interoperability problem, to me = this is fully okay. Sometimes we in the IETF even pick up existing = implementation and document them as informational, because we believe = the implementation is good and having a stable reference will help = others to do the right thing.=20 However, when we make a recommend I think we should be clear. This is = especially helpful for implementators who do not really have a good = reason to do something different and just look for a general = recommendation.=20 Further I have to note that we do use the word SHOULD in cases where we = know that there are good reason to deviate from the proposed = recommendation. In such a case you could still claim to be standard = conform (for what it is worth) even when you don=E2=80=99t follow the = SHOULD. However basically saying whatever you do is confirm with this = specification, to me really contradicts the point of making a = recommendation. It=E2=80=99s simple if you follow all MUSTs and SHOULDs if case you = don=E2=80=99t have a good reason to do something else, you are conform = to the RFC, and otherwise you are simply not conform. That doesn=E2=80=99t= say that you always when you implement something have to follow RFCs. = That=E2=80=99s non-sense. Implementors are free to do what they want and = we can=E2=80=99t stop them; we can only give reasonable recommendations. My 2c... Mirja > Am 16.06.2016 um 14:07 schrieb Mark Allman : >=20 >=20 >> (R.3) Alternatively, implementations of future RTO mechanisms may = be >> made directly against the requirements in Section 3 without >> another protocol-specific specification. >=20 > I am fine with this wording and have made a note to use it in -05 > (modulo any further comments that roll in, of course). >=20 > Thanks, > allman >=20 >=20 > -- > http://www.icir.org/mallman/ >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jun 17 06:21:53 2016 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 D973C12D662; Fri, 17 Jun 2016 06:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id um_0JhTvoxTx; Fri, 17 Jun 2016 06:21:24 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED6212D5AF; Fri, 17 Jun 2016 06:21:23 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HDLKnl009791; Fri, 17 Jun 2016 06:21:20 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0874C4CDA854; Fri, 17 Jun 2016 09:22:07 -0400 (EDT) To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 09:22:07 -0400 Message-ID: <98229.1466169727@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "Black, David" , "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:21:43 -0000 --=-------459435943823349593450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > I have a personal opinion on the point below (R-3). I think this > point is just not needed. I say this not because I don=E2=80=99t agree > with the statement but spelling this out in an RFC, to me, > contradict the point of the RFC. On the one hand, I can understand that opinion. Why would we write the RFC if we weren't going to allow these things and so why do we have to say this? And, if people think this is unnecessary I am happy to nuke it. However, let me sketch the lay of the land as I see it .... It seems the meat in this document can be used for different purposes. And, we have seen opinions on each of these I think. The document could be used: (a) as input to future RTO specifications, (b) as input to future RTO implementations, or (c) as both (a) and (b) My take is (c). And, so (R.2) is meant to cover case (a), while (R.3) is meant to cover case (b). So, while I can see your point about not needing to say something obvious, I am worried that eliding (R.3) will leave us in one of two places: - In case (a) above. I.e., because (R.2) discusses only specifications and not implementations and so a natural reading may well be that this document is meant to only help future standardization efforts. - Or, in some ambiguous state where clearly (a) holds (via (R.2)), but it is not explicit that this covers implementations, too, even if we think that it does since the text does not explicitly say that. And, so we end up with confusion. Does that make sense? Am I worrying too much about explicitly including implementations? allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldj+X4ACgkQWyrrWs4yIs4vOQCeMFXg99BZIHiPVV9eHhHnRmAk HdAAnRyqQosnxBOss48aSyQRLyMa9sHE =2yd7 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 07:03:33 2016 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 E307712D610; Fri, 17 Jun 2016 07:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 6aTVvyc6MaJ1; Fri, 17 Jun 2016 07:03:29 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FC412D14F; Fri, 17 Jun 2016 07:03:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5371FD930E; Fri, 17 Jun 2016 16:03:28 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id z5cvWFpLrpzC; Fri, 17 Jun 2016 16:03:28 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E2AB0D9305; Fri, 17 Jun 2016 16:03:27 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <98229.1466169727@lawyers.icir.org> Date: Fri, 17 Jun 2016 16:03:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C6ECA08-B076-4D8D-B827-FBF5F6681EAA@tik.ee.ethz.ch> References: <98229.1466169727@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Black, David" , "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 14:03:32 -0000 Again, my personal view is that the statement is not needed, and I find = it rather confusing that helpful. Based my (limited) experience in = (Linux) implementors community I would like to add that even though they = are often not very active on ietf mailing lists and might not follow the = RFC in their implementation, they still read the draft. So simply = focusing on the actual recommendation in the doc (and the needed = statements how this doc related to other docs in the RFC series) is = sufficient for me and more clear. Mirja > Am 17.06.2016 um 15:22 schrieb Mark Allman : >=20 >=20 >> I have a personal opinion on the point below (R-3). I think this >> point is just not needed. I say this not because I don=E2=80=99t = agree >> with the statement but spelling this out in an RFC, to me, >> contradict the point of the RFC. >=20 > On the one hand, I can understand that opinion. Why would we write > the RFC if we weren't going to allow these things and so why do we > have to say this? And, if people think this is unnecessary I am > happy to nuke it. >=20 > However, let me sketch the lay of the land as I see it .... It > seems the meat in this document can be used for different purposes. > And, we have seen opinions on each of these I think. The document > could be used: >=20 > (a) as input to future RTO specifications, >=20 > (b) as input to future RTO implementations, or >=20 > (c) as both (a) and (b) >=20 > My take is (c). And, so (R.2) is meant to cover case (a), while > (R.3) is meant to cover case (b). >=20 > So, while I can see your point about not needing to say something > obvious, I am worried that eliding (R.3) will leave us in one of two > places: >=20 > - In case (a) above. I.e., because (R.2) discusses only > specifications and not implementations and so a natural reading > may well be that this document is meant to only help future > standardization efforts. >=20 > - Or, in some ambiguous state where clearly (a) holds (via (R.2)), > but it is not explicit that this covers implementations, too, > even if we think that it does since the text does not explicitly > say that. And, so we end up with confusion. >=20 > Does that make sense? Am I worrying too much about explicitly > including implementations? >=20 > allman >=20 >=20 >=20 From nobody Fri Jun 17 07:13:13 2016 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 06FBD12D62F; Fri, 17 Jun 2016 07:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1lz3ahcFRMb; Fri, 17 Jun 2016 07:13:07 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C238512D0FF; Fri, 17 Jun 2016 07:13:07 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HED5wG015928; Fri, 17 Jun 2016 07:13:05 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 106154CE758A; Fri, 17 Jun 2016 10:13:52 -0400 (EDT) To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= From: Mark Allman In-Reply-To: <3C6ECA08-B076-4D8D-B827-FBF5F6681EAA@tik.ee.ethz.ch> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document33151.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 10:13:52 -0400 Message-ID: <6766.1466172832@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "Black, David" , "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:13:09 -0000 --=-------459435943823349593450 Content-Type: text/plain I am mulling this. But, a question... > So simply focusing on the actual recommendation in the doc (and > the needed statements how this doc related to other docs in the > RFC series) is sufficient for me and more clear. I guess this is counter-intuitive to me as usually implicitness is a less direct path to clarity than explicitness. So, would you also then get rid of (R.2)? So, we use (R.1) to state how the doc relates to existing specs and then say nothing about the future (about either specs or implementations). To me that is at least a more consistent path than retaining (R.2) and removing (R.3). But, I am still mulling ... Thanks, allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkBZ0ACgkQWyrrWs4yIs5k3wCeIvJCrbIiKvo0PxG7CvZ+I02m lNsAn0cfLWZbDq3uDG00DrhCX6pspoPg =Y2/k -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 07:23:02 2016 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 84DF212D62F; Fri, 17 Jun 2016 07:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 gues2klBF0AH; Fri, 17 Jun 2016 07:22:59 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946C712D0FC; Fri, 17 Jun 2016 07:22:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E2515D9305; Fri, 17 Jun 2016 16:22:56 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yJZCo+LhDG6V; Fri, 17 Jun 2016 16:21:48 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A53F3D9304; Fri, 17 Jun 2016 16:21:48 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <6766.1466172832@lawyers.icir.org> Date: Fri, 17 Jun 2016 16:21:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1CDD4A4D-085F-4621-8D49-2629A24808B3@tik.ee.ethz.ch> References: <6766.1466172832@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Black, David" , "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 14:23:01 -0000 I find R-2 less problematic/confusing but also probably not needed. = Especially seeing the SHOULD in there seems slightly weird to me. To me = the better approach would be to simply use SHOULDs instead of (most of = the) MUSTs in the latter text in the doc; and potentially add more text = there that the SHOULD is a really strong SHOULD and there must be a good = reason to deviate. Mirja =20 > Am 17.06.2016 um 16:13 schrieb Mark Allman : >=20 >=20 > I am mulling this. But, a question... >=20 >> So simply focusing on the actual recommendation in the doc (and >> the needed statements how this doc related to other docs in the >> RFC series) is sufficient for me and more clear. >=20 > I guess this is counter-intuitive to me as usually implicitness is a > less direct path to clarity than explicitness. >=20 > So, would you also then get rid of (R.2)? So, we use (R.1) to state > how the doc relates to existing specs and then say nothing about the > future (about either specs or implementations). To me that is at > least a more consistent path than retaining (R.2) and removing > (R.3). >=20 > But, I am still mulling ... >=20 > Thanks, > allman >=20 >=20 >=20 From nobody Fri Jun 17 10:08:28 2016 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 594B312D7E5; Fri, 17 Jun 2016 10:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVUfwLQzel9f; Fri, 17 Jun 2016 10:08:26 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69BF12D8CE; Fri, 17 Jun 2016 10:08:18 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HH8GOE009339; Fri, 17 Jun 2016 10:08:16 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 58DE84D0102A; Fri, 17 Jun 2016 13:09:04 -0400 (EDT) To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= From: Mark Allman In-Reply-To: <1CDD4A4D-085F-4621-8D49-2629A24808B3@tik.ee.ethz.ch> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document65411.doc X-URL-1: http://www.icir.org/mallman-files/Document5190.docx X-URL-2: http://www.icir.org/mallman-files/Document36104.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 13:09:04 -0400 Message-ID: <30640.1466183344@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "Black, David" , "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 17:08:27 -0000 --=-------459435943823349593450 Content-Type: text/plain I like to re-state things to see if I understand what is being said. So, let me see if I understand what you're suggesting (in high level terms). (This is about the RTO document in specific, but more broadly would seem applicable to single-host algorithm specifications.) You are starting from the fact that implementers are not beholden to the RFCs in any tangible way. And, also the fact that we don't have any real recourse when the standards are not followed. So, since they don't feel constrained by the RFCs, we should approach RFCs in the same way and not worry about constraints as much as giving our best recommendations. We hope our strong recommendations are listened to and used. But, if they are not, they are not and there isn't anything we can do about them regardless of what we say people "MUST" do. I.e., the standards process should meet the implementers where they are. Is that roughly correct? (In the above I mean to have no opinion, just trying to understand your hit. I may subsequently have an opinion and if I can somehow get over my usual shyness I might then say it. :) ) allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkLq0ACgkQWyrrWs4yIs62jACfV/a/5+FNkTIW/OTz15/3GLXa MIwAnj0jVqftlOG3JogkqUb7zhpZz1+o =Ns0p -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 11:27:46 2016 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 2914412D995; Fri, 17 Jun 2016 11:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_vnTTojdwhj; Fri, 17 Jun 2016 11:27:39 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 B305812D98D; Fri, 17 Jun 2016 11:27:38 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 76CBF7BBBFA07; Fri, 17 Jun 2016 18:27:33 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5HIRarN030652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 18:27:36 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5HIRZDT026199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jun 2016 20:27:36 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 17 Jun 2016 20:27:35 +0200 From: "Scharf, Michael (Nokia - DE)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "mallman@icir.org" Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRyJs+daDP2nXoIEy1xGblSmRRlJ/tj0yAgABTZTA= Date: Fri, 17 Jun 2016 18:27:35 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DB3B5@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <98229.1466169727@lawyers.icir.org> <3C6ECA08-B076-4D8D-B827-FBF5F6681EAA@tik.ee.ethz.ch> In-Reply-To: <3C6ECA08-B076-4D8D-B827-FBF5F6681EAA@tik.ee.ethz.ch> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 18:27:41 -0000 V2l0aCBjaGFpciBoYXQgb2ZmLi4uDQoNCj4gQWdhaW4sIG15IHBlcnNvbmFsIHZpZXcgaXMgdGhh dCB0aGUgc3RhdGVtZW50IGlzIG5vdCBuZWVkZWQsIGFuZCBJIGZpbmQgaXQgcmF0aGVyIGNvbmZ1 c2luZyB0aGF0IGhlbHBmdWwuIEJhc2VkIG15IChsaW1pdGVkKSBleHBlcmllbmNlIGluIChMaW51 eCkgaW1wbGVtZW50b3JzIGNvbW11bml0eSBJIHdvdWxkIGxpa2UgdG8gYWRkIHRoYXQgZXZlbiB0 aG91Z2ggdGhleSBhcmUgb2Z0ZW4gbm90IHZlcnkgYWN0aXZlIG9uIGlldGYgbWFpbGluZyBsaXN0 cyBhbmQgbWlnaHQgbm90IGZvbGxvdyB0aGUgUkZDIGluIHRoZWlyIGltcGxlbWVudGF0aW9uLCB0 aGV5IHN0aWxsIHJlYWQgdGhlIGRyYWZ0LiBTbyBzaW1wbHkgZm9jdXNpbmcgb24gdGhlIGFjdHVh bCByZWNvbW1lbmRhdGlvbiBpbiB0aGUgZG9jIChhbmQgdGhlIG5lZWRlZCBzdGF0ZW1lbnRzIGhv dyB0aGlzIGRvYyByZWxhdGVkIHRvIG90aGVyIGRvY3MgaW4gdGhlIFJGQyBzZXJpZXMpIGlzIHN1 ZmZpY2llbnQgZm9yIG1lIGFuZCBtb3JlIGNsZWFyLg0KDQorMSBvbiByZW1vdmluZyAoUi4zKQ0K DQpJIGRvIE5PVCBzdXBwb3J0IHRoZSBjdXJyZW50IGxhbmd1YWdlIGluIChSLjMpLCBhcyB3ZWxs IGFzIHJlbGF0ZWQgd29yZGluZyBvbiAiaW1wbGVtZW50YXRpb25zIiBlbHNld2hlcmUgaW4gdGhl IGRvY3VtZW50Lg0KIA0KRm9yIFRDUCwgSSBhbSBjb25mdXNlZCBieSBob3cgdGhpcyB3b3JkaW5n IHJlbGF0ZXMgdG8gUkZDIDYyOTguIEZvciBUQ1AsIEkgZnVsbHkgYWdyZWUgdGhhdCBhbGxvd2lu ZyBtb3JlIGZsZXhpYmlsaXR5IGNvbXBhcmVkIHRvIFJGQyA2Mjk4IHdvdWxkIGJlIHVzZWZ1bCwg YW5kIGEgbmV3IFJGQyA2Mjk4YmlzIGNvdWxkIHJlZmVyZW5jZSBhIEJDUCBkcmFmdC1pZXRmLXRj cG0tcnRvLWNvbnNpZGVyLiBIb3dldmVyLCBJIGJlbGlldmUgdGhhdCBndWlkYW5jZSBmb3IgVENQ IGltcGxlbWVudGVycyBiZWxvbmdzIGludG8gYSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQgUkZD IDYyOThiaXMuIFRoZSBkb2N1bWVudCBkcmFmdC1pZXRmLXRjcG0tcnRvLWNvbnNpZGVyIHNob3Vs ZCBmb2N1cyBvbiBhIHNldCBvZiByZXF1aXJlbWVudHMgb25seS4gDQoNClNvcnJ5LCBJIHNob3Vs ZCBoYXZlIGNvbW1lbnRlZCBvbiB0aGF0IHByaW9yIHRvIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24g YnV0IEkgaGF2ZSBmb2N1c2VzIHNvIGZhciBvbiB0aGUgYWN0dWFsIHdvcmRpbmcgb2YgdGhlIHJl cXVpcmVtZW50cywgd2hpY2ggYXJlIG5vdCByZWFsbHkgY29udHJvdmVyc2lhbCAoYnV0IHNlZSB0 aGUgbm90ZSBiZWxvdykuDQoNCkkgd291bGQgYWRkIHRoYXQgSSBoYXZlIHNvbWUgZG91YnRzIG9u IHRoZSBNVVNUIGZvciBleHBvbmVudGlhbCBiYWNrb2ZmIGJ1dCBJIGhhdmUgdG8gZnVydGhlciB0 aGluayBhYm91dCB0aGlzLiBJIHBlcnNvbmFsbHkgYmVsaWV2ZSB0aGF0IGEgcmV0cmFuc21pc3Np b24gdGltZW91dCB0aGF0IG9ubHkgYmFja3Mgb2ZmIGFmdGVyIHNvbWUgYXR0ZW1wdHMgd291bGQg YWxzbyBiZSByZWFzb25hYmx5IHNhZmUuIEFsc28sIGEgdGltZXIgdGhhdCB3b3VsZCBleHBvbmVu dGlhbGx5IGJhY2sgb2ZmIGV2ZXJ5IHNlY29uZCBhdHRlbXB0IHdvdWxkIGFsc28gd29yayBJTUhP LiBJIHRoaW5rIHRoZSBjdXJyZW50IE1VU1QgdGhhdCBkaXNhbGxvd3MgdGhpcyBpcyBzbGlnaHRs eSB0b28gcmVzdHJpY3RpdmUgYnV0IEkgY291bGQgbm90IGNvbWUgdXAgd2l0aCBzb21ldGhpbmcg YmV0dGVyIHRvZGF5Lg0KDQpQbGVhc2UgZmluZCBiZWxvdyBteSByZXZpZXcgZm9yIC0wNCwgbXkg Y29tbWVudHMgYXJlIGxpc3RlZCB3aXRoIFttc10gYmVsb3cuIEkgaGF2ZSBwcm92aWRlZCBhbHRl cm5hdGl2ZSB3b3JkaW5nIGZvciBtb3N0IGNhc2VzIHRvIGF2b2lkIGFtYmlndWl0eS4NCg0KVGhh bmtzDQoNCk1pY2hhZWwNCg0KDQoNCioqKioqIHJldmlldyBvZiAtMDQgKioqKioNCg0KKiBUaXRs ZQ0KDQogIlJldHJhbnNtaXNzaW9uIFRpbWVvdXQgUmVxdWlyZW1lbnRzIg0KDQpbbXNdIEkgYW0g ZmluZSB3aXRoIHRoZSBuZXcgdGl0bGUuDQoNCiogQWJzdHJhY3QNCg0KW21zXSBPTEQNCg0KICAg IEVuc3VyaW5nIHJlbGlhYmxlIGNvbW11bmljYXRpb24gb2Z0ZW4gbWFuaWZlc3RzIGluIGEgdGlt ZW91dCBhbmQNCiAgICByZXRyeSBtZWNoYW5pc20uICBFYWNoIGltcGxlbWVudGF0aW9uIG9mIGEg cmV0cmFuc21pc3Npb24gdGltZW91dA0KICAgIG1lY2hhbmlzbSByZXByZXNlbnRzIGEgYmFsYW5j ZSBiZXR3ZWVuIGNvcnJlY3RuZXNzIGFuZCB0aW1lbGluZXNzDQogICAgYW5kIHRoZXJlZm9yZSBu byBpbXBsZW1lbnRhdGlvbiBzdWl0cyBhbGwgc2l0dWF0aW9ucy4gIFRoaXMgZG9jdW1lbnQNCiAg ICBwcm92aWRlcyBoaWdoLWxldmVsIHJlcXVpcmVtZW50cyBmb3IgcmV0cmFuc21pc3Npb24gdGlt ZW91dCBzY2hlbWVzDQogICAgYXBwcm9wcmlhdGUgZm9yIGdlbmVyYWwgdXNlIGluIHRoZSBJbnRl cm5ldC4gIFdpdGhpbiB0aGUNCiAgICByZXF1aXJlbWVudHMsIGltcGxlbWVudGF0aW9ucyBoYXZl IGxhdGl0dWRlIHRvIGRlZmluZSBwYXJ0aWN1bGFycw0KICAgIHRoYXQgYmVzdCBhZGRyZXNzIGVh Y2ggc2l0dWF0aW9uLg0KDQpbbXNdIE5FVw0KDQogICAgRW5zdXJpbmcgcmVsaWFibGUgY29tbXVu aWNhdGlvbiBvZnRlbiBtYW5pZmVzdHMgaW4gYSB0aW1lb3V0IGFuZA0KICAgIHJldHJ5IG1lY2hh bmlzbS4gIEVhY2ggcmV0cmFuc21pc3Npb24gdGltZW91dCBtZWNoYW5pc20gcmVwcmVzZW50cw0K ICAgIGEgYmFsYW5jZSBiZXR3ZWVuIGNvcnJlY3RuZXNzIGFuZCB0aW1lbGluZXNzLiBUaGlzIGRv Y3VtZW50DQogICAgcHJvdmlkZXMgaGlnaC1sZXZlbCByZXF1aXJlbWVudHMgZm9yIHJldHJhbnNt aXNzaW9uIHRpbWVvdXQgc2NoZW1lcw0KICAgIGFwcHJvcHJpYXRlIGZvciBnZW5lcmFsIHVzZSBp biB0aGUgSW50ZXJuZXQuDQoNCiogU2VjdGlvbiAxICAgSW50cm9kdWN0aW9uDQoNClttc10gT0xE DQoNCiAgICBUaGUgaW50ZW50IGlzIHRvIHByb3ZpZGUgYSBzYWZlDQogICAgZm91bmRhdGlvbiBv biB3aGljaCBpbXBsZW1lbnRhdGlvbnMgaGF2ZSB0aGUgZmxleGliaWxpdHkgdG8NCiAgICBpbnN0 YW50aWF0ZSBtZWNoYW5pc21zIHRoYXQgYmVzdCByZWFsaXplIHRoZWlyIHNwZWNpZmljIGdvYWxz Lg0KDQpbbXNdIE5FVw0KDQogICAgVGhlIGludGVudCBpcyB0byBwcm92aWRlIGEgZm91bmRhdGlv biBvZiByZXF1aXJlbWVudHMgZm9yIHJldHJhbnNtaXNzaW9uDQogICAgdGltZW91dCBtZWNoYW5p c21zIHRoYXQgYXJlIGNvbnNpZGVyZWQgc2FmZSBmb3IgdGhlIGdsb2JhbCBJbnRlcm5ldC4NCg0K KiBTZWN0aW9uIDIgICBTY29wZSAgICANCiAgICANClttc10gV2hpbGUgc29tZWhvdyBpbXBsaWNp dGx5IGNsZWFyIGZyb20gdGhlIGVhcmxpZXIgdXNlIG9mIHRoZSB3b3JkaW5nICJnbG9iYWwgSW50 ZXJuZXQiLCBJIGJlbGlldmUgdGhhdCBzaG91bGQgYmUgbWFkZSBtb3JlIGV4cGxpY2l0IGluIFNl Y3Rpb24gMi4gTm90ZSB0aGF0IElFVEYgcHJvdG9jb2xzIGFyZSB1c2VkIG5vdCBvbmx5IGluIHRo ZSBnbG9iYWwgSW50ZXJuZXQuIFRoaXMgY2FuIGJlIChTLjApIG9yIChTLjcpLg0KDQogICAgKFMu NykgVGhlIHJlcXVpcmVtZW50cyBmb2N1cyBvbiBjb21tdW5pY2F0aW9uIG92ZXIgdGhlIGdsb2Jh bCBJbnRlcm5ldC4NCiAgICAgICAgICBSZXRyYW5zbWlzc2lvbiB0aW1lb3V0IG1lY2hhbmlzbXMg aW4gY29udHJvbGxlZCBlbnZpcm9ubWVudHMgc2VwYXJhdGVkDQoJICAgIGZyb20gdGhlIGdsb2Jh bCBJbnRlcm5ldCBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAg ICAgICAgIEUuZy4sIHRoaXMgZG9jdW1lbnQgZG9lcyBhZGRyZXNzIHJldHJhbnNtaXNzaW9uIHRp bWVycyB1c2VkIGluIGNvbnRyb2xsZWQNCiAgICAgICAgICBlbnZpcm9ubWVudHMgc3VjaCBhcyBu dWNsZWFyIHBvd2VyIHBsYW50cywgYWlycGxhbmVzLCBmYWJyaWMgYXV0b21hdGlvbiwNCiAgICAg ICAgICBldGMuIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgYWRkcmVzcyByZXRyYW5zbWlzc2lvbiB0 aW1lcnMgaW4gcmVhbC10aW1lDQogICAgICAgICAgY29tbXVuaWNhdGlvbiBwcm90b2NvbHMgZm9y IHN1Y2ggZW52aXJvbm1lbnRzLg0KDQpbbXNdIE9MRA0KDQogICAgQWRkaXRpb25hbGx5LCB0aGUg Zm9sbG93aW5nIHN0YXRlbWVudHMgZGV0YWlsIHRoZSByZWxhdGlvbnNoaXAgb2YNCiAgICB0aGUg cmVxdWlyZW1lbnRzIGluIHRoaXMgZG9jdW1lbnQgdG8gb3RoZXIgc3BlY2lmaWNhdGlvbnMgYW5k DQogICAgaW1wbGVtZW50YXRpb25zOg0KDQogICAgKFIuMSkgUlRPIG1lY2hhbmlzbXMgdGhhdCBh cmUgY3VycmVudGx5IHN0YW5kYXJkaXplZCBhcmUgbm90IHVwZGF0ZWQgDQogICAgICAgICAgb3Ig b2Jzb2xldGVkIGJ5IHRoaXMgZG9jdW1lbnQuICBJbXBsZW1lbnRhdGlvbnMgYXJlIGZyZWUgdG8N CiAgICAgICAgICB1c2UgdGhlc2UgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMgYXMgdGhleSBkbyBu b3cuDQoNCiAgICAgICAgICBUaGlzIGhvbGRzIGV2ZW4gaW4gY2FzZXMgd2hlcmUgdGhlIGV4aXN0 aW5nIHNwZWNpZmljYXRpb24NCiAgICAgICAgICBkaWZmZXJzIGZyb20gdGhlIHJlcXVpcmVtZW50 cyBpbiB0aGlzIGRvY3VtZW50IChlLmcuLA0KICAgICAgICAgIFtSRkMzMjYxXSB1c2VzIGEgc21h bGxlciBpbml0aWFsIHRpbWVvdXQgdGhhbiB0aGlzIGRvY3VtZW50DQogICAgICAgICAgc3BlY2lm aWVzKS4gIEV4aXN0aW5nIHN0YW5kYXJkIHNwZWNpZmljYXRpb25zIGVuam95IHRoZWlyIG93bg0K ICAgICAgICAgIGNvbnNlbnN1cyB3aGljaCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGNoYW5nZS4N CiAgICANCiAgICAoUi4yKSBGdXR1cmUgc3RhbmRhcmRpemF0aW9uIGVmZm9ydHMgdGhhdCBzcGVj aWZ5IFJUTyBtZWNoYW5pc21zIA0KICAgICAgICAgIFNIT1VMRCBmb2xsb3cgdGhlIHJlcXVpcmVt ZW50cyBpbiB0aGlzIGRvY3VtZW50Lg0KICAgICAgICAgIFRoZXJlIG1heSBiZSByZWFzb25zIGZv ciBmdXR1cmUgUlRPIG1lY2hhbmlzbXMgdG8gZGV2aWF0ZSBmcm9tDQogICAgICAgICAgdGhlIHJl cXVpcmVtZW50cyBpbiBTZWN0aW9uIDMuICBJbiB0aGVzZSBjYXNlcywgd2UgZXhwZWN0IG9ubHkN CiAgICAgICAgICB0aGF0IHRoZSBzdGFuZGFyZHMgcHJvY2VzcyBkb2VzIHNvIGFmdGVyIHJlYXNv bmFibGUNCiAgICAgICAgICBkZWxpYmVyYXRpb24gYW5kIHdpdGggZ29vZCByZWFzb24uDQoNCiAg ICAoUi4zKSBBbHRlcm5hdGl2ZWx5LCBmdXR1cmUgUlRPIG1lY2hhbmlzbSBpbXBsZW1lbnRhdGlv bnMgbWF5IGJlDQogICAgICAgICAgbWFkZSBkaXJlY3RseSBhZ2FpbnN0IHRoZSByZXF1aXJlbWVu dHMgaW4gU2VjdGlvbiAzIHdpdGhvdXQNCiAgICAgICAgICBhbm90aGVyIHByb3RvY29sLXNwZWNp ZmljIHNwZWNpZmljYXRpb24uIA0KDQogICAgKFIuNCkgVGhlcmUgd2lsbCBubyBkb3VidCBiZSBj YXNlcyB3aGVyZSBhcHBseWluZyB0aGUgcmVxdWlyZW1lbnRzDQogICAgICAgICAgaW4gdGhpcyBk b2N1bWVudCBkaXJlY3RseSBpcyBub3QgcG9zc2libGUgZHVlIHRvIHRoZSBzdHJ1Y3R1cmUNCiAg ICAgICAgICBvciBvcGVyYXRpb24gb2YgYSBwcm90b2NvbC4gIEZvciBpbnN0YW5jZSwgYSBjYXNl IHdoZXJlIGENCiAgICAgICAgICB0aW1lb3V0IGlzIHVzZWQgdG8gZGV0ZWN0IGxvc3MsIGJ1dCB0 aGUgbG9zcyBpcyBub3QgcmVwYWlyZWQNCiAgICAgICAgICB3aXRoIGEgZGlyZWN0IHJldHJhbnNt aXNzaW9uIG9mIHRoZSBvcmlnaW5hbCBkYXRhLiAgSW4gdGhlc2UNCiAgICAgICAgICBzaXR1YXRp b25zLCBhbiBhbHRlcm5hdGUgc3BlY2lmaWNhdGlvbiBpcyByZXF1aXJlZC4gIFdlDQogICAgICAg ICAgZW5jb3VyYWdlIHN1Y2ggZnV0dXJlIGVmZm9ydHMgdG8gbGV2ZXJhZ2UgdGhlIHNwaXJpdCBv ZiB0aGUgDQogICAgICAgICAgcmVxdWlyZW1lbnRzIGluIHRoaXMgZG9jdW1lbnQgdG8gaW5mb3Jt IGFsdGVybmF0ZQ0KICAgICAgICAgIHNwZWNpZmljYXRpb25zLiANCg0KW21zXSBORVcNCg0KICAg IEFkZGl0aW9uYWxseSwgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRzIGRldGFpbCB0aGUgcmVsYXRp b25zaGlwIG9mDQogICAgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvY3VtZW50IHRvIG90aGVy IHNwZWNpZmljYXRpb25zOg0KDQogICAgKFIuMSkgUlRPIG1lY2hhbmlzbXMgdGhhdCBhcmUgY3Vy cmVudGx5IHN0YW5kYXJkaXplZCBhcmUgbm90IHVwZGF0ZWQgDQogICAgICAgICAgb3Igb2Jzb2xl dGVkIGJ5IHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgICBUaGlzIGhvbGRzIGV2ZW4gaW4gY2Fz ZXMgd2hlcmUgdGhlIGV4aXN0aW5nIHNwZWNpZmljYXRpb24NCiAgICAgICAgICBkaWZmZXJzIGZy b20gdGhlIHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvY3VtZW50IChlLmcuLA0KICAgICAgICAgIFtS RkMzMjYxXSB1c2VzIGEgc21hbGxlciBpbml0aWFsIHRpbWVvdXQgdGhhbiB0aGlzIGRvY3VtZW50 DQogICAgICAgICAgc3BlY2lmaWVzKS4gIEV4aXN0aW5nIHN0YW5kYXJkIHNwZWNpZmljYXRpb25z IGVuam95IHRoZWlyIG93bg0KICAgICAgICAgIGNvbnNlbnN1cyB3aGljaCB0aGlzIGRvY3VtZW50 IGRvZXMgbm90IGNoYW5nZS4NCiAgICANCiAgICAoUi4yKSBGdXR1cmUgc3RhbmRhcmRpemF0aW9u IGVmZm9ydHMgdGhhdCBzcGVjaWZ5IFJUTyBtZWNoYW5pc21zIA0KICAgICAgICAgIFNIT1VMRCBm b2xsb3cgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvY3VtZW50Lg0KICAgICAgICAgIFRoZXJl IG1heSBiZSByZWFzb25zIGZvciBmdXR1cmUgUlRPIG1lY2hhbmlzbXMgdG8gZGV2aWF0ZSBmcm9t DQogICAgICAgICAgdGhlIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDMuICBJbiB0aGVzZSBjYXNl cywgd2UgZXhwZWN0IG9ubHkNCiAgICAgICAgICB0aGF0IHRoZSBzdGFuZGFyZHMgcHJvY2VzcyBk b2VzIHNvIGFmdGVyIHJlYXNvbmFibGUNCiAgICAgICAgICBkZWxpYmVyYXRpb24gYW5kIHdpdGgg Z29vZCByZWFzb24uDQoNCiAgICAoUi4zKSBUaGVyZSB3aWxsIG5vIGRvdWJ0IGJlIGNhc2VzIHdo ZXJlIGFwcGx5aW5nIHRoZSByZXF1aXJlbWVudHMNCiAgICAgICAgICBpbiB0aGlzIGRvY3VtZW50 IGRpcmVjdGx5IGlzIG5vdCBwb3NzaWJsZSBkdWUgdG8gdGhlIHN0cnVjdHVyZQ0KICAgICAgICAg IG9yIG9wZXJhdGlvbiBvZiBhIHByb3RvY29sLiAgRm9yIGluc3RhbmNlLCBhIGNhc2Ugd2hlcmUg YQ0KICAgICAgICAgIHRpbWVvdXQgaXMgdXNlZCB0byBkZXRlY3QgbG9zcywgYnV0IHRoZSBsb3Nz IGlzIG5vdCByZXBhaXJlZA0KICAgICAgICAgIHdpdGggYSBkaXJlY3QgcmV0cmFuc21pc3Npb24g b2YgdGhlIG9yaWdpbmFsIGRhdGEuICBJbiB0aGVzZQ0KICAgICAgICAgIHNpdHVhdGlvbnMsIGFu IGFsdGVybmF0ZSBzcGVjaWZpY2F0aW9uIGlzIHJlcXVpcmVkLiAgV2UNCiAgICAgICAgICBlbmNv dXJhZ2Ugc3VjaCBmdXR1cmUgZWZmb3J0cyB0byBsZXZlcmFnZSB0aGUgc3Bpcml0IG9mIHRoZSAN CiAgICAgICAgICByZXF1aXJlbWVudHMgaW4gdGhpcyBkb2N1bWVudCB0byBpbmZvcm0gYWx0ZXJu YXRlDQogICAgICAgICAgc3BlY2lmaWNhdGlvbnMuDQoNClttc10gLi4uIGFsYmVpdCBJIHRoaW5r IGV2ZW4gbW9yZSBvZiB0aGlzIGNvdWxkIGJlIHJlbW92ZWQNCg0KKiBTZWN0aW9uIDQgICBEaXNj dXNzaW9uDQoNClttc10gT0xEDQoNCiAgICBGaW5hbGx5LCB3ZSBub3RlIHRoYXQgd2hpbGUgYWxs b3dpbmcgaW1wbGVtZW50YXRpb25zIHRvIGJlIG1vcmUNCiAgICBhZ2dyZXNzaXZlIG1heSBpbiBm YWN0IGluY3JlYXNlIHRoZSBudW1iZXIgb2YgbmVlZGxlc3MNCiAgICByZXRyYW5zbWlzc2lvbnMg dGhlIGFib3ZlIHJlcXVpcmVtZW50cyBmYWlsIHNhZmUgaW4gdGhhdCB0aGV5IGluc2lzdA0KICAg IG9uIGV4cG9uZW50aWFsIGJhY2tvZmYgb2YgdGhlIFJUTyBhbmQgYSB0cmFuc21pc3Npb24gcmF0 ZSByZWR1Y3Rpb24uDQogICAgVGhlcmVmb3JlLCBwcm92aWRpbmcgaW1wbGVtZW50ZXJzIG1vcmUg bGF0aXR1ZGUgdGhhbiB0aGV5IGhhdmUNCiAgICB0cmFkaXRpb25hbGx5IGJlZW4gZ2l2ZW4gaW4g SUVURiBzcGVjaWZpY2F0aW9ucyBvZiBSVE8gbWVjaGFuaXNtcw0KICAgIGRvZXMgbm90IHNvbWVo b3cgb3BlbiB0aGUgZmxvb2QgZ2F0ZXMgdG8gYWdncmVzc2l2ZSBiZWhhdmlvci4gIFNpbmNlDQog ICAgdGhlcmUgaXMgYSBkb3duc2lkZSB0byBiZWluZyBhZ2dyZXNzaXZlIHRoZSBpbmNlbnRpdmVz IGZvciBwcm9wZXINCiAgICBiZWhhdmlvciBhcmUgcmV0YWluZWQgaW4gdGhlIG1lY2hhbmlzbS4N Cg0KW21zXSBORVcgDQoNCiAgICBUaGUgYWJvdmUgcmVxdWlyZW1lbnRzIGFyZSBzYWZlIGZyb20g YSBuZXR3b3JrIHBlcnNwZWN0aXZlIGluIHRoYXQgdGhleSBpbnNpc3QNCiAgICBvbiBleHBvbmVu dGlhbCBiYWNrb2ZmIG9mIHRoZSBSVE8gYW5kIGEgdHJhbnNtaXNzaW9uIHJhdGUgcmVkdWN0aW9u Lg0KDQoqIFNlY3Rpb24gNSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQpbbXNdIFRoaXMgc2Vj dGlvbiBpcyBJTUhPIHRvbyBzaG9ydCBhbmQgYSByZWZlcmVuY2UganVzdCB0byBUQ1AgaXMgbm90 IHN1ZmZpY2llbnQgZm9yIGEgcHJvdG9jb2wgdGhhdCBzaGFsbCBiZSBwcm90b2NvbC1hZ25vc3Rp Yy4gSSBjYW5ub3QgcHJvdmlkZSBiZXR0ZXIgd29yZGluZyBvdXQtb2YtbXktaGVhZCBidXQgaGVy ZSBhcmUgYSBjb3VwbGUgb2YgdG9waWNzIHRoYXQgaGF2ZSB0byBiZSBjb3ZlcmVkIGluIHRoaXMg c2VjdGlvbjoNCg0KKDEpIEEgZGlzY3Vzc2lvbiBvZiB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25z IGlmIHJldHJhbnNtaXNzaW9uIHRpbWVvdXQgbWVjaGFuaXNtcyBkZXZpYXRlIGZyb20gc3RhbmRh cmRpemVkIHJldHJhbnNtaXNzaW9uIG1lY2hhbmlzbXMuIEZvciBpbnN0YW5jZSwgbm90IGNvbXBs eWluZyB0byBwcm90b2NvbCBzdGFuZGFyZHMgY291bGQgdHJpZ2dlciBhbm9tYWx5IGRldGVjdGlv biBzeXN0ZW1zIG9yIHRoaXMgY291bGQgYmUgY2xhc3NpZmllZCBhcyBhbiBhdHRhY2suDQoNCigy KSBBIGRpc2N1c3Npb24gdGhhdCBvcGVyYXRpb25hbCAic2FmZXR5IiBpbiBjb250cm9sbGVkIGVu dmlyb25tZW50cyBzZXBhcmF0ZWQgZnJvbSB0aGUgZ2xvYmFsIEludGVybmV0LCBzdWNoIGFzIG51 Y2xlYXIgcG93ZXIgcGxhbnRzLCBhaXJwbGFuZXMsIGZhYnJpYyBhdXRvbWF0aW9uLCBpcyBub3Qg YWRkcmVzc2VkIGJ5IHRoaXMgZG9jdW1lbnQuDQoNCigzKSBBIGRpc2N1c3Npb24gd2hldGhlciBy ZXRyYW5zbWlzc2lvbiB0aW1lb3V0IG1lY2hhbmlzbXMsIG9yIGRldmlhdGlvbnMgb2YgdGhlbSwg Y2FuIGJlIHVzZWQgZm9yIGZpbmdlci1wcmludGluZy4gKFRoaXMgbWF5IGJlIHZlcnkgZXhvdGlj IGJ1dCBpZiBhbiBpbXBsZW1lbnRhdGlvbiB1c2VzIGEgdmVyeSB1bmlxdWUgaW5pdGlhbCBSVE8g dGhhdCBjb3VsZCBoYXZlIHByaWNhY3kgaW1wbGljYXRpb25zLikNCg0KKDQpIC4uLiBwb3NzaWJs eSBtb3JlLCB3ZSBtYXkgbmVlZCBpbnB1dCBmcm9tIHNlY3VyaXR5IGV4cGVydHMNCg0KKioqKiog cmV2aWV3IG9mIC0wNCAqKioqKg0KDQo= From nobody Fri Jun 17 11:59:18 2016 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 BD59B12D9D8; Fri, 17 Jun 2016 11:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRZxQZgdzqy7; Fri, 17 Jun 2016 11:59:13 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2CF212D9C1; Fri, 17 Jun 2016 11:59:13 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HIxCVN021911; Fri, 17 Jun 2016 11:59:12 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D73644D156FE; Fri, 17 Jun 2016 14:59:59 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D488DB3B5@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document58786.jpg X-URL-1: http://www.icir.org/mallman-files/Document2527.html X-URL-2: http://www.icir.org/mallman-files/Document141.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 14:59:59 -0400 Message-ID: <67283.1466189999@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 18:59:15 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Just one quick one that is easy to answer ... > For TCP, I am confused by how this wording relates to RFC > 6298. This document does nothing to RFC6298. I.e., (R.1) RTO mechanisms that are currently standardized are not updated=20 or obsoleted by this document. Implementations are free to use these existing specifications as they do now. That is, RFC6298 remains as it is now. Implementers are free to use the algorithm as it sits in RFC6298. > For TCP, I fully agree that allowing more flexibility compared to > RFC 6298 would be useful, and a new RFC 6298bis could reference a > BCP draft-ietf-tcpm-rto-consider. However, I believe that guidance > for TCP implementers belongs into a standards track document RFC > 6298bis. The document draft-ietf-tcpm-rto-consider should focus on > a set of requirements only. I am not sure what you mean here. So, we'd use rto-consider as a set of requirements. And, then we'd generate a 6298bis that is less specific than 6298. So, e.g., instead of providing equations like this: RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'| SRTT <- (1 - alpha) * SRTT + alpha * R' RTO <- SRTT + max (G, K*RTTVAR) and their corresponding parameter values, we'd just fall back to some generic language like "use RTT samples and the variance of RTT samples per [rto-consider] to compute an RTO"? So, the document is then a fuzzy re-statement of the [rto-consider] requirements instead of a specific algorithm. Something like that? Or, do you just want a 6298bis that includes a statement at the top that says "this algorithm follows the requirements in [rto-consider]"? Or, something else? I can't envision how you view this as working.=20 allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkSK8ACgkQWyrrWs4yIs7fBQCeJLdFCcTMxuvOdzlMpLF8HfG6 pHIAnRTo9K18UfEOLNhkX72rsvvcjDWl =9CmG -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 12:12:52 2016 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 88D3712D9D8; Fri, 17 Jun 2016 12:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhQhRPhW422T; Fri, 17 Jun 2016 12:12:46 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 EE7FD12D82D; Fri, 17 Jun 2016 12:12:44 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 59D6982C523B9; Fri, 17 Jun 2016 19:12:39 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5HJCg53019304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 19:12:43 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5HJCc4e032572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jun 2016 21:12:40 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 17 Jun 2016 21:11:57 +0200 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRyMpxoDoEKDWkakuYZCmVs3o6/5/uBIuw Date: Fri, 17 Jun 2016 19:11:56 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DB571@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D488DB3B5@FR712WXCHMBA15.zeu.alcatel-lucent.com> <67283.1466189999@lawyers.icir.org> In-Reply-To: <67283.1466189999@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 19:12:48 -0000 > > For TCP, I fully agree that allowing more flexibility compared to RFC=20 > > 6298 would be useful, and a new RFC 6298bis could reference a BCP=20 > > draft-ietf-tcpm-rto-consider. However, I believe that guidance for TCP= =20 > > implementers belongs into a standards track document RFC 6298bis. The=20 > > document draft-ietf-tcpm-rto-consider should focus on a set of=20 > > requirements only. > I am not sure what you mean here. 6298bis would have a new (first) section with a MUST that applies the guide= lines in [rto-consider] specifically to the TCP protocol, mandating that al= l TCP implementations MUST use retransmission timeout mechanisms matching t= his minimum set of requirements. This is relatively straightforward given t= hat [rto-consider] is rather TCP-ish already. But for a number of requireme= nts the actual TCP terminology and technology could be used. And then the document would recommend with a MAY (or SHOULD) the algorithm = in 6298 as default. And I believe that such a proposed standard for TCP would be closer to what= implementations actually do.=20 (And I believe for SCTP it would also be a no-brainer to come up with somet= hing in TSVWG, but the SCTP experts would have comment on that.) Michael From nobody Fri Jun 17 12:41:10 2016 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 EAAC012DA39; Fri, 17 Jun 2016 12:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 Z5oJbsOiVpaE; Fri, 17 Jun 2016 12:41:04 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB7512DA32; Fri, 17 Jun 2016 12:41:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 571E3D930B; Fri, 17 Jun 2016 21:41:02 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id byeYKCTqtDZ7; Fri, 17 Jun 2016 21:41:02 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 089C7D9304; Fri, 17 Jun 2016 21:41:02 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <30640.1466183344@lawyers.icir.org> Date: Fri, 17 Jun 2016 21:41:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <409BB227-4760-49A9-A223-D1B30BDE08C3@tik.ee.ethz.ch> References: <30640.1466183344@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 19:41:06 -0000 Hi Mark, > Am 17.06.2016 um 19:09 schrieb Mark Allman : >=20 > You are starting from the fact that implementers are not beholden to > the RFCs in any tangible way. And, also the fact that we don't have > any real recourse when the standards are not followed. So, since > they don't feel constrained by the RFCs, we should approach RFCs in > the same way and not worry about constraints as much as giving our > best recommendations. We hope our strong recommendations are > listened to and used. But, if they are not, they are not and there > isn't anything we can do about them regardless of what we say people > "MUST" do. I.e., the standards process should meet the implementers > where they are. >=20 > Is that roughly correct? Roughly yes. I wouldn=E2=80=99t use the wording "implementers are not = beholden to the RFCs in any tangible way=E2=80=9C but anyway... Even though your statement was scoped to single-host algos, I don=E2=80=99= t want to let this stand in the room like this. Let me add a few things = (that are more general and probably not important for the discussion on = rto though).=20 First, this is slightly different if interoperability is required. But = even in this case, we can=E2=80=99t control what implementors are doing. = However, I would say there is a natural incentive in this case to follow = the spec because other it just won=E2=80=99t work.=20 Then I would also like to say that the consequence of this thinking is = not that RFCs are useless as anyway nobody will follow anyway. I know = that is not was you were saying or thinking I assume. I just want to = clearly state that there is an important role for RFCs to make = recommendation; as I said implementors read RFC (even if they don=E2=80=99= t follow). And finally, the other important aspect is that this liberal approach in = the Internet, where we of course depend to a certain extend on other = people doing things right/not too wrong, is that enables innovation in = the Internet and make the Internet to this great thing we have today. = E.g if someone invents a complete new service that uses the Internet = that might not fit our current recommendation. So this freedom is needed = and deliberate. With this more philosophical statement, I guess the only this that is = left to say is: Have a good weekend! Mirja From nobody Fri Jun 17 12:49:36 2016 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 6625912D0AE; Fri, 17 Jun 2016 12:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElhpoBKp0xJ1; Fri, 17 Jun 2016 12:49:32 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B8512DA37; Fri, 17 Jun 2016 12:49:32 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HJnV9Z028713; Fri, 17 Jun 2016 12:49:31 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 951844D161D6; Fri, 17 Jun 2016 15:50:18 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D488DB571@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document27509.jpg X-URL-1: http://www.icir.org/mallman-files/Document14512.html X-URL-2: http://www.icir.org/mallman-files/Document32703.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 15:50:18 -0400 Message-ID: <75094.1466193018@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 19:49:33 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > 6298bis would have a new (first) section with a MUST that applies > the guidelines in [rto-consider] specifically to the TCP protocol, > mandating that all TCP implementations MUST use retransmission > timeout mechanisms matching this minimum set of requirements. This > is relatively straightforward given that [rto-consider] is rather > TCP-ish already. But for a number of requirements the actual TCP > terminology and technology could be used.=20 >=20 > And then the document would recommend with a MAY (or SHOULD) the > algorithm in 6298 as default.=20 >=20 > And I believe that such a proposed standard for TCP would be > closer to what implementations actually do.=20=20 We have been around this before, but for the public record ... To me this is a bunch of work for, perhaps, epsilon gain. We state some high level requirements. But, then we have to re-state the high-level requirements after prepending a protocol name and only then can an implementation can actually leverage the requirements. Perhaps that forms a nice clean document progression. But, man, what a bunch of busy work that has no value add... Rather, I think this document can be directly applied to both future specifications and future implementations. I don't yet have a well-formed hit on whether we should directly state that in some fashion (as the doc---perhaps clumsily---tries to do now) or leave the requirements as our best thinking to be implicitly applied however folks see fit (my understanding of Mirja's hit). allman =2D- http://www.icir.org/mallman/ --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkVHcACgkQWyrrWs4yIs56BgCfZgbbSPMDlepII8/Y6U8ZMfcG pjkAn3bl03uoCFxE1EfPewcIaFq5wukv =U/wk -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 13:00:37 2016 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 D9EEC12D8A3; Fri, 17 Jun 2016 13:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7GoZNznodCE; Fri, 17 Jun 2016 13:00:33 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 7743012D8B1; Fri, 17 Jun 2016 13:00:33 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 73147F5AF9995; Fri, 17 Jun 2016 20:00:27 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5HK0VUt014552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 20:00:31 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5HK0Um5001559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jun 2016 22:00:30 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 17 Jun 2016 22:00:30 +0200 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRyJs+daDP2nXoIEy1xGblSmRRlJ/uEZAQ Date: Fri, 17 Jun 2016 20:00:29 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DB6E3@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <98229.1466169727@lawyers.icir.org> In-Reply-To: <98229.1466169727@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 20:00:35 -0000 PiBIb3dldmVyLCBsZXQgbWUgc2tldGNoIHRoZSBsYXkgb2YgdGhlIGxhbmQgYXMgSSBzZWUgaXQg Li4uLiAgIEl0DQo+IHNlZW1zIHRoZSBtZWF0IGluIHRoaXMgZG9jdW1lbnQgY2FuIGJlIHVzZWQg Zm9yIGRpZmZlcmVudCBwdXJwb3Nlcy4NCj4gQW5kLCB3ZSBoYXZlIHNlZW4gb3BpbmlvbnMgb24g ZWFjaCBvZiB0aGVzZSBJIHRoaW5rLiAgVGhlIGRvY3VtZW50IGNvdWxkIGJlIHVzZWQ6DQo+DQo+ ICAoYSkgYXMgaW5wdXQgdG8gZnV0dXJlIFJUTyBzcGVjaWZpY2F0aW9ucywNCj4NCj4gIChiKSBh cyBpbnB1dCB0byBmdXR1cmUgUlRPIGltcGxlbWVudGF0aW9ucywgb3INCj4NCj4gIChjKSBhcyBi b3RoIChhKSBhbmQgKGIpDQoNCkluIGNhc2UgdGhlcmUgd2FzIGFueSBhbWJpZ3VpdHk6IA0KDQpJ IGRvIE5PVCBzdXBwb3J0IChiKSBvciAoYykuDQoNClNwZWNpZmljYWxseSwgSSBkbyBub3QgdW5k ZXJzdGFuZCBob3cgW3J0by1jb25zaWRlcl0gY2FuIGZvcmVzZWUgdGhlIHJlcXVpcmVtZW50cyBv ZiBmdXR1cmUgcHJvdG9jb2xzIG5vdCBzdGFuZGFyZGl6ZWQgYnkgdGhlIElFVEYgcmlnaHQgbm93 LiBUaGUgSW50ZXJuZXQgaXMgc3ViamVjdCB0byBwZXJtYW5lbnQgY2hhbmdlLiBJIGNvbmNsdWRl IHRoYXQgdGhlIHJlcXVpcmVtZW50cyBvdXRsaW5lZCBpbiB0aGlzIGRvY3VtZW50IGNhbm5vdCBi ZSBjb25zaWRlcmVkICJzYWZlIiBmb3IgaW1wbGVtZW50YXRpb25zIG9mIHByb3RvY29scyBpbiBm dXR1cmUsIHVua25vd24gZW52aXJvbm1lbnRzLg0KDQpUaGUgYW5hbHlzaXMgd2hhdCBpcyAic2Fm ZSIgaGFzIHRvIGJlIGRvbmUgb24gYSBwZXIgcHJvdG9jb2wgYmFzaXMsIHdpdGhpbiB0aGUgc3Rh bmRhcmRpemF0aW9uIHByb2Nlc3Mgb2YgdGhhdCBwcm90b2NvbCwgdGFraW5nIFtydG8tY29uc2lk ZXJdIGFzIG9uZSBpbnB1dCByZWdhcmRpbmcgdGhlIHJlcXVpcmVtZW50cyBpbiB0aGUgZ2xvYmFs IEludGVybmV0IGF0IHRoZSB0aW1lIHdoZW4gdGhlIGRvY3VtZW50IHdhcyBwdWJsaXNoZWQuDQoN Ck1pY2hhZWwgKHdpdGggY2hhaXIgaGF0IG9mZikNCg0K From nobody Fri Jun 17 13:15:22 2016 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 AF38912DAB1; Fri, 17 Jun 2016 13:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQRz8kAuM6uS; Fri, 17 Jun 2016 13:15:20 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D46812DA61; Fri, 17 Jun 2016 13:15:20 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HKFJsS002100; Fri, 17 Jun 2016 13:15:19 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B5E734D16961; Fri, 17 Jun 2016 16:16:06 -0400 (EDT) To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= From: Mark Allman In-Reply-To: <409BB227-4760-49A9-A223-D1B30BDE08C3@tik.ee.ethz.ch> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 16:16:06 -0400 Message-ID: <78939.1466194566@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 20:15:22 -0000 --=-------459435943823349593450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > > You are starting from the fact that implementers are not beholden to > > the RFCs in any tangible way. And, also the fact that we don't have > > any real recourse when the standards are not followed. So, since > > they don't feel constrained by the RFCs, we should approach RFCs in > > the same way and not worry about constraints as much as giving our > > best recommendations. We hope our strong recommendations are > > listened to and used. But, if they are not, they are not and there > > isn't anything we can do about them regardless of what we say people > > "MUST" do. I.e., the standards process should meet the implementers > > where they are. > >=20 > > Is that roughly correct? >=20 > Roughly yes. OK. Then, I am going to mull this approach. I view three things on the table: - Mirja's approach: State the recommendations, but not explicitly what they apply to and as SHOULDs rather than MUSTs and then let people use them as they find useful. - Michael's approach: The requirements exist only to guide future specs. And, implementations are explicitly not to leverage these directly. - Mark's approach: Somewhere in the middle, I guess. State the recommendations, but also explicitly that they are for both future specs and future implementations. (Clearly closer to Mirja and Michael.) I am still thinking. Others can chime in. But, only if your name starts with "M"... because naming conventions are important. > First, this is slightly different if interoperability is > required. But even in this case, we can=E2=80=99t control what > implementors are doing. However, I would say there is a natural > incentive in this case to follow the spec because other it just > won=E2=80=99t work.=20=20 (Yep. This is why I scoped!) > Then I would also like to say that the consequence of this > thinking is not that RFCs are useless as anyway nobody will follow > anyway. I know that is not was you were saying or thinking I > assume. I just want to clearly state that there is an important > role for RFCs to make recommendation; as I said implementors read > RFC (even if they don=E2=80=99t follow). Well, OK. I understand what you're saying. But, what I am struggling with here is that if we make some MUSTs then we get a little something in return. That sets an expectation. And, if the FooBar implementation doesn't follow that expectation and it causes problems then there is a lever to say "well, gee, we said you needed to do something and you didn't". FooBar does not have to listen. We cannot make them do something different. But, we get a little lever. So, the question in my mind is whether we get the same sort of leverage with your looser notion of "just state the requirements" and "use SHOULDs". And, I am thinking not. I.e., we didn't say "do this" we said "do this unless you have a good reason" and FooBar might think they have a good reason (e.g., "helps my customers, so sorry about your's!"). We can still try to say "well, we strongly recommended ...", but we're in a bit lesser position. The thing I am trying to form an opinion on is "how much lesser". I.e., I have sort of convinced myself stronger statements are better. But, it might be that they are only epsilon better and so ultimately it doesn't much matter. Thanks, allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkWoYACgkQWyrrWs4yIs69swCbB3X7C+P9WeSeoeWEjBbN3ira yWYAnjvcGsRJnzao8clsiLRKl6lBF0rm =pIyO -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 13:17:37 2016 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 5459512DAB1; Fri, 17 Jun 2016 13:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfXBND5TMO7P; Fri, 17 Jun 2016 13:17:35 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E6512DAAE; Fri, 17 Jun 2016 13:17:35 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5HKHYbQ002410; Fri, 17 Jun 2016 13:17:34 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1A6764D169C8; Fri, 17 Jun 2016 16:18:22 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D488DB6E3@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document42183.doc X-URL-1: http://www.icir.org/mallman-files/Document76662.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 17 Jun 2016 16:18:22 -0400 Message-ID: <79277.1466194702@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 20:17:36 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Applying "the future will be different" stops all work. Period. allman > > However, let me sketch the lay of the land as I see it .... It > > seems the meat in this document can be used for different purposes. > > And, we have seen opinions on each of these I think. The document coul= d be used: > > > > (a) as input to future RTO specifications, > > > > (b) as input to future RTO implementations, or > > > > (c) as both (a) and (b) >=20 > In case there was any ambiguity:=20 >=20 > I do NOT support (b) or (c). >=20 > Specifically, I do not understand how [rto-consider] can foresee > the requirements of future protocols not standardized by the IETF > right now. The Internet is subject to permanent change. I conclude > that the requirements outlined in this document cannot be > considered "safe" for implementations of protocols in future, > unknown environments.=20 >=20 > The analysis what is "safe" has to be done on a per protocol > basis, within the standardization process of that protocol, taking > [rto-consider] as one input regarding the requirements in the > global Internet at the time when the document was published.=20 >=20 > Michael (with chair hat off) --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldkWw0ACgkQWyrrWs4yIs4p8gCfeUd0nOlz63OPHJXz8vWfbZod MHwAoJ9c0FdiFNieoFK8NtE1PUFViTnM =xzXq -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Jun 17 16:08:43 2016 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 6706512DC44; Fri, 17 Jun 2016 16:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6_kYc4bgCWH; Fri, 17 Jun 2016 16:08:37 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 13A8B12DBE2; Fri, 17 Jun 2016 16:08:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id AF45A114C51F6; Fri, 17 Jun 2016 23:08:30 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5HN8Y3h001195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 23:08:35 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5HN7PUT013210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 Jun 2016 01:08:31 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sat, 18 Jun 2016 01:07:56 +0200 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRyNF5oDoEKDWkakuYZCmVs3o6/5/uODGg Date: Fri, 17 Jun 2016 23:07:56 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DB993@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D488DB571@FR712WXCHMBA15.zeu.alcatel-lucent.com> <75094.1466193018@lawyers.icir.org> In-Reply-To: <75094.1466193018@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 23:08:39 -0000 > > 6298bis would have a new (first) section with a MUST that applies > > the guidelines in [rto-consider] specifically to the TCP protocol, > > mandating that all TCP implementations MUST use retransmission > > timeout mechanisms matching this minimum set of requirements. This > > is relatively straightforward given that [rto-consider] is rather > > TCP-ish already. But for a number of requirements the actual TCP > > terminology and technology could be used. > > > > And then the document would recommend with a MAY (or SHOULD) the > > algorithm in 6298 as default. > > > > And I believe that such a proposed standard for TCP would be > > closer to what implementations actually do. >=20 > We have been around this before, but for the public record ... >=20 > To me this is a bunch of work for, perhaps, epsilon gain. We state > some high level requirements. But, then we have to re-state the > high-level requirements after prepending a protocol name and only > then can an implementation can actually leverage the requirements. Implementers can read the requirements in rto-consider right now. What implementers cannot leverage right now is a statement about IETF conse= nsus that for any protocol standardized in the IETF, any RTO algorithm, in = all circumstances is always "safe" when it meets the requirements under the= constraints stated in the document. And specifically implementers of proto= cols other than TCP cannot rely on that because a document first has to pas= s IETF last call and IESG approval before the IETF can state that the guida= nce it is indeed "best current practice". > Perhaps that forms a nice clean document progression. But, man, > what a bunch of busy work that has no value add... If [rto-consider] is IETF consensus, IMHO a 6298bis document would be a no-= brainer in TCPM. Maybe I miss something, but that would be a candidate for = a WGLC directly on the -00 version, given that we already review [rto-consi= der]. One added value of 6298bis is that it applies the generic wording in = [rto-consider] specifically to the TCP. I believe that this is simpler to r= ead for a TCP implementer than to reverse-engineer protocol-agnostic wordin= g in a draft that gets longer and longer to be protocol-agnostic (and likel= y will have to be further extended when it hits IETF last call)? And, as a = side note, my formal concerns would be addressed, since TCPM would have a d= ocument we can e.g. proceed on standards track. So is your concern that nobody would invest cycles to author a 6298bis in T= CPM? Or something equivalent e.g. for SCTP? In summary, can we agree that if somebody volunteers to submit 6298bis, whi= ch references [rto-consider], my proposed wording for [rto-consider] actual= ly has some gain ("epsilon" or more). Thus, in summary my proposal just sor= ts out everything in TCPM? Or what is then missing in TCPM? Michael From nobody Fri Jun 17 16:25:51 2016 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 451AC12DC4C; Fri, 17 Jun 2016 16:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 A6IraUF4jmRD; Fri, 17 Jun 2016 16:25:47 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9791F12D63C; Fri, 17 Jun 2016 16:25:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E5777D9305; Sat, 18 Jun 2016 01:25:42 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iOQFaYhAMZhr; Sat, 18 Jun 2016 01:25:42 +0200 (MEST) Received: from [192.168.178.33] (p5DEC287C.dip0.t-ipconnect.de [93.236.40.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9DAA9D9304; Sat, 18 Jun 2016 01:25:42 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <78939.1466194566@lawyers.icir.org> Date: Sat, 18 Jun 2016 01:25:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <78939.1466194566@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 23:25:49 -0000 Hi Mark, just on this one point and then I go to sleep=E2=80=A6 > Am 17.06.2016 um 22:16 schrieb Mark Allman : >=20 > But, what I am struggling with here is that if we make some MUSTs > then we get a little something in return. That sets an expectation. > And, if the FooBar implementation doesn't follow that expectation > and it causes problems then there is a lever to say "well, gee, we > said you needed to do something and you didn't". FooBar does not > have to listen. We cannot make them do something different. But, > we get a little lever. So, the question in my mind is whether we > get the same sort of leverage with your looser notion of "just state > the requirements" and "use SHOULDs". And, I am thinking not. I.e., > we didn't say "do this" we said "do this unless you have a good > reason" and FooBar might think they have a good reason (e.g., "helps > my customers, so sorry about your's!"). We can still try to say > "well, we strongly recommended ...", but we're in a bit lesser > position. So SHOULD is the right usage here, because what you actually want to say = is, do it expect you have a good reason. Yes, not everybody knows how to = understand SHOULD correctly and there are even different opinion in the = IETF. And what a good reason is, is even harder to define. So from my = point the only practical solution is not using MUST but providing as = much explanation as possible on when the SHOULD might not need to be = follow and when it clearly should be followed. That=E2=80=99s often also = not easy, I know. But that's the only way to make your point, also for = people who are maybe less familiar with the language used in RFCs. Btw. = there is no requirement to use this normative language. Actually this is = only meant to help people understanding a document and its requirements = more quickly. But effectively the message should still be clear even if = the normative, upper-letter notation is ignored. Mirja= From nobody Mon Jun 20 07:44:00 2016 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 4A4FD12D10C; Mon, 20 Jun 2016 07:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWTXZ-hMHGcg; Mon, 20 Jun 2016 07:43:50 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AED112D08E; Mon, 20 Jun 2016 07:43:50 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5KEhmKf026171; Mon, 20 Jun 2016 07:43:48 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1472B4D4685C; Mon, 20 Jun 2016 10:44:56 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D488DB993@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Haircut X-URL-0: http://www.icir.org/mallman-files/Document57987.jpg X-URL-1: http://www.icir.org/mallman-files/Document52629.doc X-URL-2: http://www.icir.org/mallman-files/Document76540.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 20 Jun 2016 10:44:56 -0400 Message-ID: <16792.1466433896@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 14:43:51 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > If [rto-consider] is IETF consensus, IMHO a 6298bis document would > be a no-brainer in TCPM. But, it isn't necessary. RFC 6298 is a document about *one* algorithm. We could invent parallel algorithms. And, write an RFC that specifies each. RFC 6298 just happens to be the only RTO we have taken the bother to develop and write up. So, RFC 6298 (or a bis) doesn't have to convey all of our TCP RTO understanding. It is just one algorithm for doing it. So, yeah, we can write a preamble to RFC 6298 that says "this agrees with [rto-consider]", but that doesn't change the algorithm. It isn't a technical change at all. It is more words in service of what? A tidy---by some definition---document progression is all I can come up with. It doesn't advance things in any meaningful way. > One added value of 6298bis is that it applies the > generic wording in [rto-consider] specifically to the TCP. I > believe that this is simpler to read for a TCP implementer than to > reverse-engineer protocol-agnostic wording in a draft that gets > longer and longer to be protocol-agnostic (and likely will have to > be further extended when it hits IETF last call)? The whole thing hasn't really gotten much longer. And, it is still quite short. And, I don't think that someone steeped in TCP will have a difficult time reading the generic form of the requirements there now. These are not particularly foreign concepts we're talking about. > So is your concern that nobody would invest cycles to author a > 6298bis in TCPM? Or something equivalent e.g. for SCTP?=20 My concern is for doing work that just doesn't need to be done. How many times do you want to re-state the same thing? TCP, SCTP. What about UDP? I doubt you'll find the notions in 5405bis to be quite right because they apply the rto-consider requirements to all UDP-based protocols. And, so, I think all the same arguments you're making now would have to be applied there, too, and so we'll have to go and write N more of these things for N UDP-based apps. That's saying the same thing a lot. And, God forbid if we ever had to change something... The point is that except for document series tidiness I have seen no reason to make these requirements only apply to future specs---and not implementations---as you advocate. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldoAWcACgkQWyrrWs4yIs6/jwCfcRW8FOX2UDCZB6TVdiepNoGq JswAnAvxm+mXZs4r/eM1H5BV0D48K8WH =ow6K -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Jun 20 08:29:56 2016 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 E0B5312D1A3; Mon, 20 Jun 2016 08:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yEMi2xnnhQo; Mon, 20 Jun 2016 08:29:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 0D64612D1A7; Mon, 20 Jun 2016 08:29:53 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id DC3E3B38D58FA; Mon, 20 Jun 2016 15:29:47 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5KFTot6029151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 15:29:50 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5KFTovD013242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jun 2016 17:29:50 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 20 Jun 2016 17:29:50 +0200 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRywJPoDoEKDWkakuYZCmVs3o6/5/ybzxg Date: Mon, 20 Jun 2016 15:29:49 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DEC5B@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D488DB993@FR712WXCHMBA15.zeu.alcatel-lucent.com> <16792.1466433896@lawyers.icir.org> In-Reply-To: <16792.1466433896@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 15:29:55 -0000 > > If [rto-consider] is IETF consensus, IMHO a 6298bis document would be=20 > > a no-brainer in TCPM. > But, it isn't necessary. RFC 6298 is a document about *one* algorithm. This is not how I read RFC 6298. It already has a MUST in the abstract: This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. RFC 6298 does mention that other algorithms could exist, with the following= wording: In some situations, it may be beneficial for a TCP sender to be more conservative than the algorithms detailed in this document allow. However, a TCP MUST NOT be more aggressive than the following algorithms allow. This document obsoletes RFC 2988 [PA00]. But RFC 6298 does not have the notion of *one* algorithm. So, in my reading, [rto-consider] contradicts quite explicitly the standard= s track specification of TCP. What do I miss here? In my view RFC 6298 needs to be updated if TCPM believes that a TCP impleme= ntation fully compliant to IETF standards should be allowed to have other a= lgorithms. As mentioned already, I would support publishing a 6298bis for that purpose= . I believe that it is important that TCPM standards track documents are (1= ) consistent and (2) well aligned with the major TCP implementations. The following to me is a very straightforward and clean approach: * [rto-consider] provides the general protocol-agnostic requirements, as sp= ecified in the wording of my review * 5405bis applies it to UDP * 6298bis applies it TCP and cleanly updates 6298 on standards track * SCTP should be a low-hanging fruit as well * Other protocols owned by other working groups have to review [rto-conside= r] and come to an own consensus anyway And, possibly even more importantly, reading protocol-specific guidance sho= uld typically also be simpler for implementers since they don't have to gue= ss how to apply generic wording to the specific protocol semantics. In short, I am not aware of any relevant downside of that very clean approa= ch. Michael From nobody Mon Jun 20 09:30:47 2016 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 67F1812D759; Mon, 20 Jun 2016 09:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 oNBD5Y12JY11; Mon, 20 Jun 2016 09:30:41 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 D1BCA12D787; Mon, 20 Jun 2016 09:30:40 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5KGUZab008311 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jun 2016 12:30:37 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u5KGUZab008311 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1466440238; bh=Tj79K18VPFhccnWUtja4M8zFV1Q=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=I/VA47gkAwdP2mHH22Zieaw7cE3O+s+xtWRwJ964dquoJaBLk2jvvAuSL0EotcoIB asfj4/qz2lRdNRZM+mYAk4G0wa08drYH1kMVlLi/Lcu13bg7e30IxQghM8zlZE1t6U zFxp/MEp/slXGMuABYGtBV6cO7iDjXwGDjCVPdPw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u5KGUZab008311 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 20 Jun 2016 12:30:11 -0400 Received: from MXHUB302.corp.emc.com (MXHUB302.corp.emc.com [10.146.3.28]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5KGUIYG007717 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 20 Jun 2016 12:30:18 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB302.corp.emc.com ([10.146.3.28]) with mapi id 14.03.0266.001; Mon, 20 Jun 2016 12:30:17 -0400 From: "Black, David" To: "mallman@icir.org" , "Scharf, Michael (Nokia - DE)" Thread-Topic: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) Thread-Index: AQHRyKEIFD4HxyHbKEOjUwlosyFckZ/uPaKAgAAJDYCAAANXAIAACrgAgAA3OACABCp1AP//0Rlg Date: Mon, 20 Jun 2016 16:30:16 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D488DB993@FR712WXCHMBA15.zeu.alcatel-lucent.com> <16792.1466433896@lawyers.icir.org> In-Reply-To: <16792.1466433896@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 16:30:42 -0000 Addressing solely this UDP item ... > What about UDP? I doubt you'll find the notions in 5405bis to be quite > right because they apply the rto-consider requirements to all > UDP-based protocols. The desired structure here (IMHO) is that the TCPM rto-consider draft states the general principles, and the TSVWG rfc5405bis draft applies them to UDP. Then individual UDP-based protocol drafts are expected to follow the guidance in rfc5405bis, or explain why there are good reasons for doing otherwise. > And, so, I think all the same arguments you're > making now would have to be applied there, too, and so we'll have to > go and write N more of these things for N UDP-based apps. =20 Not exactly - any UDP-based protocol RFC-to-be is going to have to reference rfc5405bis, as I'd expect the TSV ADs to Discuss drafts that don't ;-). The resulting RTO considerations will show up in each main protocol draft, not a small separate stand-alone draft. In practice, we'll probably see more cross-area interaction to head off this class of issue before it hits the IESG. FWIW, draft-ietf-forces-inter= felfb is a recently-worked example in the area of congestion considerations, and I do want to thank the responsible RTG AD (Alia) for noticing that the congestion concerns could use a bit more attention, and encouraging the draft authors to address them in advance of the draft going to the IESG= . Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Mark Allman > Sent: Monday, June 20, 2016 10:45 AM > To: Scharf, Michael (Nokia - DE) > Cc: tcpm@ietf.org; tsvwg@ietf.org > Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rto-consider-04: (R.3) >=20 >=20 > > If [rto-consider] is IETF consensus, IMHO a 6298bis document would > > be a no-brainer in TCPM. >=20 > But, it isn't necessary. RFC 6298 is a document about *one* > algorithm. We could invent parallel algorithms. And, write an RFC > that specifies each. RFC 6298 just happens to be the only RTO we > have taken the bother to develop and write up. So, RFC 6298 (or a > bis) doesn't have to convey all of our TCP RTO understanding. It is > just one algorithm for doing it. >=20 > So, yeah, we can write a preamble to RFC 6298 that says "this agrees > with [rto-consider]", but that doesn't change the algorithm. It > isn't a technical change at all. It is more words in service of > what? A tidy---by some definition---document progression is all I > can come up with. It doesn't advance things in any meaningful way. >=20 > > One added value of 6298bis is that it applies the > > generic wording in [rto-consider] specifically to the TCP. I > > believe that this is simpler to read for a TCP implementer than to > > reverse-engineer protocol-agnostic wording in a draft that gets > > longer and longer to be protocol-agnostic (and likely will have to > > be further extended when it hits IETF last call)? >=20 > The whole thing hasn't really gotten much longer. And, it is still > quite short. And, I don't think that someone steeped in TCP will > have a difficult time reading the generic form of the requirements > there now. These are not particularly foreign concepts we're > talking about. >=20 > > So is your concern that nobody would invest cycles to author a > > 6298bis in TCPM? Or something equivalent e.g. for SCTP? >=20 > My concern is for doing work that just doesn't need to be done. How > many times do you want to re-state the same thing? TCP, SCTP. What > about UDP? I doubt you'll find the notions in 5405bis to be quite > right because they apply the rto-consider requirements to all > UDP-based protocols. And, so, I think all the same arguments you're > making now would have to be applied there, too, and so we'll have to > go and write N more of these things for N UDP-based apps. That's > saying the same thing a lot. And, God forbid if we ever had to > change something... >=20 > The point is that except for document series tidiness I have seen no > reason to make these requirements only apply to future specs---and > not implementations---as you advocate. >=20 > allman >=20 >=20 From nobody Mon Jun 20 09:53:02 2016 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 BA5E912D587; Mon, 20 Jun 2016 09:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE4PSCc8yXIb; Mon, 20 Jun 2016 09:52:56 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413A212D581; Mon, 20 Jun 2016 09:52:56 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u5KGqtfr012689; Mon, 20 Jun 2016 09:52:55 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9A4B14D48FDA; Mon, 20 Jun 2016 12:54:02 -0400 (EDT) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D488DEC5B@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Revolution X-URL-0: http://www.icir.org/mallman-files/Document95559.html X-URL-1: http://www.icir.org/mallman-files/Document90706.pdf X-URL-2: http://www.icir.org/mallman-files/Document60263.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 20 Jun 2016 12:54:02 -0400 Message-ID: <27581.1466441642@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rto-consider-04: (R.3) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 16:52:58 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > So, in my reading, [rto-consider] contradicts quite explicitly the > standards track specification of TCP. What do I miss here?=20 "Contradict" ... maybe. In the strict sense of the word. What it says is that we have learned things and figured out that only a subset of 6298 is necessary for network safety and so we can offer flexibility in the areas that are not as important for network safety. But, it doesn't alter or call into question the algorithm in 6298 and folks can readily use it as they always have. But, deviation from the precise details is also in some cases quite fine, as well. The usual thing we do is to learn and update things. We increase the initial cwnd recommendation (which obsoletes the previous recommendation). Or, we refine SACK-based loss recovery (which obsoletes the old scheme with new thinking). Or, whatnot. But, in this case we are saying simultaneously that (a) we can relax on the details and (b) the details of this one existing spec are still valid and fine. This is different than our Usual Case, I think. But, since we are not taking something and making it different or better this is not the Usual Case. We are saying is we have learned: - that there are a class of specific RTO mechanisms that are safe and fine, - that there is no one-size-fits-all in the class and=20 - that the class includes the old thing so we cannot simply replace it Instead of honing our view or changing our view we are broadening our view. And, this is (I guess) difficult. On the rest, I could reply. But, we know where each other stands at this point and you and I don't need to continue to circle. We simply disagree. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldoH6cACgkQWyrrWs4yIs5WsQCglNcNZhpS1P6B2WcmFh5s3Bm0 6+AAn2/wW56zV4l0l1EueZvq4S19jGC3 =BZFi -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Jun 20 10:08:35 2016 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 A4FEC12D587; Mon, 20 Jun 2016 10:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 ferFcv17eWKA; Mon, 20 Jun 2016 10:08:28 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8386B12D556; Mon, 20 Jun 2016 10:08:27 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id u5KH8MKl028135; Mon, 20 Jun 2016 19:08:22 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 538681D53C1; Mon, 20 Jun 2016 19:08:21 +0200 (CEST) Received: from 131.111.5.142 by webmail.entel.upc.edu with HTTP; Mon, 20 Jun 2016 19:08:57 +0200 Message-ID: <292ce8bf280356eadf53eaa5527d5182.squirrel@webmail.entel.upc.edu> In-Reply-To: <655C07320163294895BBADA28372AF5D488D0A96@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> <9c715eeca71b9a647df289dbd40f2092.squirrel@webmail.entel.upc.edu> <655C07320163294895BBADA28372AF5D488D0A96@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Mon, 20 Jun 2016 19:08:57 +0200 From: "Carles Gomez Montenegro" To: "Scharf, Michael (Nokia - DE)" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: ACL matched, not delayed by milter-greylist-4.4.3 (dash.upc.es [147.83.2.50]); Mon, 20 Jun 2016 19:08:22 +0200 (CEST) Archived-At: Cc: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 17:08:30 -0000 Dear Michael, Thank you very much for your detailed comments (and sorry for the late response). Please find below some inline responses: > Just out-of-curiosity: In 1981, when the current TCP spec was published, > end hosts had significant processing and memory limitations. Quite a bit > of the TCP protocol mechanisms were designed to deal with senders and > receivers that have very small buffers, e.g., of the order of the maximum > segment size.RFC 793 is very carefully designed to deal with these > constraints. And current TCP implementations are still backward compatible > to RFC 793. > > When quickly scanning through this document, some observations (the list > is not comprehensive): > > - TCP counts window sizes in bytes, which > draft-gomez-core-tcp-constrained-node-networks-00 seems to ignore. Agreed. We'll address this in the next draft revision. > - Out-of-my-head, nothing prevents a TCP sender from limiting the > congestion window to a small window (e.g., one MSS). This basically turns > TCP into a stop-and-wait protocol. A TCP sender can unilaterally decide to > limit its congestion window if it wants to simplify its implementation. I > am not sure if RFC 2119 language is needed for that at all. > > - A TCP receiver can use the receive window to prevent the sender from > sending data, e.g., if it can only deal with one MSS. It may be > interesting to look into whether advertising a maximum receive window e.g. > of at most one MSS would solve some of the problems discussed in the > draft. Right, one thing to provide details about in the document is which are the available ways to enable the intended stop-and-wait operation. > - TCP options will only be enabled if supported on both ends and a > standard-compliant TCP stack only has to support the MSS option (more > precisely, option kinds 0, 1, and 2). An implementation that does not want > to use any additional TCP features does not have to implement support any > of those options. However, to be compatible with RFC 793 the option kinds > 0, 1, and 2 have to be parsed in SYNs and thus basic support for option > parsing in SYNs is required anyway. If the basic support for option > parsing in SYNs is in place (which is not very complex code), it seems > easy to process any other options that may be present in the SYN as well, > and just ignore them. Thus, I do not understand what added value a MUST > has that "forbids" TCP options that may typically not be negotiated in the > environments addressed by this document. Section 3.6 can be definitely updated to clarify the need to support the MSS option (options 0, 1, and 2). On the other hand, the intent of the 'MUST NOT' was to make sure that implementation complexity/memory footprint is reduced by not supporting the options mentioned in the section. Nevertheless, we can phrase this goal in a different way, more aligned with your text above. > - If the receiver knows that TCP shall run in a stop-and-wait mode (e.g., > because it advertises very small receive window), the delayed ACKs in TCP > may offer some opportunities for optimization, e.g., a receiver could want > to turn them off delayed ACKs when it advertises a very small receive > window. I believe the document could look into that space. Agreed. > - There are quite a number of differences between using TCP only inside a > controlled environment, or using TCP with endpoints that are located in > the Internet. I would recommend that a document explicitly discusses both > variants, as design trade-offs could be different. And I would assume that > one of the reasons for picking TCP would be to at least have the option of > end-to-end transfers over the global Internet. The main reason motivating draft-ietf-core-coap-tcp-tls is the need to traverse middleboxes, so a primary scenario is communication between constrained devices (e.g. 'sensor nodes') and unconstrained devices over the global Internet (e.g. backend servers, etc.). I agree that the document needs to clarify and discuss the two main scenarios mentioned. > - ... (there is more) > > In general, the TCPM list is followed by quite a number of different TCP > implementers and there is some expertise on the original RFC 793 design > decisions. If the intention of this document is e.g. to define up a > minimum set of TCP features required for a stop-and-wait operation and > with very small buffers, I'd assume that relevant expertise would be on > the TCPM list. > > So, it might make sense to keep the TCPM list in the loop. Presenting the > document in TCPM may also be an option the authors may want to think > about. Thank you very much. Definitely, feedback from TCPM will be of great help and value. With regard to presenting the document, there is an unfortunate collision in Berlin, as I have requested a presentation slot (of another draft) for the 6lo WG meeting (which takes place simultaneously with tcpm). Not sure if this could be solved in some way... On the other hand, I'll (also) present this draft (draft-gomez-core-tcp...) in the lwig WG meeting. Cheers, Carles > Michael > > From nobody Mon Jun 20 10:16:03 2016 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 B570712D5AD; Mon, 20 Jun 2016 10:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8LHyF65HxE6; Mon, 20 Jun 2016 10:15:56 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 3813512D5B5; Mon, 20 Jun 2016 10:15:56 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 8A0CECC3F9C8E; Mon, 20 Jun 2016 17:15:50 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5KHFrUB017623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 17:15:53 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5KHFpIS021684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jun 2016 19:15:52 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 20 Jun 2016 19:15:52 +0200 From: "Scharf, Michael (Nokia - DE)" To: Carles Gomez Montenegro Thread-Topic: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] Thread-Index: AQHRxVoI/RTNimOLOUmdRy+CYZPf8J/nLTRwgAtTbYCAACIBMA== Date: Mon, 20 Jun 2016 17:15:51 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DF199@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> <9c715eeca71b9a647df289dbd40f2092.squirrel@webmail.entel.upc.edu> <655C07320163294895BBADA28372AF5D488D0A96@FR712WXCHMBA15.zeu.alcatel-lucent.com> <292ce8bf280356eadf53eaa5527d5182.squirrel@webmail.entel.upc.edu> In-Reply-To: <292ce8bf280356eadf53eaa5527d5182.squirrel@webmail.entel.upc.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 17:15:58 -0000 > With regard to presenting the document, there is an unfortunate collision= in Berlin, as I have requested a presentation slot (of another draft) for = the 6lo WG meeting (which takes place simultaneously with tcpm). Not sure i= f this could be solved in some way... On the other hand, I'll (also) presen= t this draft (draft-gomez-core-tcp...) in the lwig WG meeting. The TCPM chairs can chat with the 6lo chairs if this can be sorted out. Michael From nobody Mon Jun 20 11:20:36 2016 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 92C8D12D73A for ; Mon, 20 Jun 2016 11:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10DGQ2Jb2RgV for ; Mon, 20 Jun 2016 11:20:33 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 F3A6312D629 for ; Mon, 20 Jun 2016 11:20:32 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 35849FA4233B6; Mon, 20 Jun 2016 18:20:27 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5KIKUKd016620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 18:20:30 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5KIKTxS013145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jun 2016 20:20:29 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 20 Jun 2016 20:20:29 +0200 From: "Scharf, Michael (Nokia - DE)" To: "tcpm@ietf.org Extensions" Thread-Topic: Agenda requests for TCPM at IETF 96 Thread-Index: AdHLIGw1FQxuocbBS6C9XwLHugPpAg== Date: Mon, 20 Jun 2016 18:20:29 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488DF486@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Agenda requests for TCPM at IETF 96 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 18:20:34 -0000 Hi, It is time to start building the TCPM meeting agenda for Berlin meeting. *T= entatively* TCPM got the Monday morning slot. If you want to present something, please send a request to the TCPM chairs = with the following information: * Draft name / presentation title * Requested time * Speaker Please send requests as soon as possible, but latest by Thursday, July 7. Thanks! Michael, Pasi, Yoshifumi From nobody Mon Jun 20 13:02:35 2016 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 AE77112D953 for ; Mon, 20 Jun 2016 13:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] 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 VGqgN8kjdzXo for ; Mon, 20 Jun 2016 13:02:32 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 0D82F12D94B for ; Mon, 20 Jun 2016 13:02:32 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id h190so46667150ith.1 for ; Mon, 20 Jun 2016 13:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j+q1JcR2OLS2GOubf/h49n6j2B65VbtRKQSgIT5Sf0s=; b=ek3m4FvaQ0xsMHrtrfYx6YZC1cUp9d4FRr0TZ1/dzU56dtQ5hvj1indQVwqxc0sxCF IVNgGPqBm9USpe5+cxGq2PBaGtasuiSPsH7Qtrm5Z9fp7gFbtvTtGdoCKDkJrOxa3/IH RgifaiDIOEmmpZA7A74MjYSrkE7BAbv9k5bv6Iidw2XdaV3fkbHeooI8/zP6hk6QyEij u74XrWlbnLVnuuMgo+lKZBa7AXgr+FkfaYYoU84MqrvchWR3t0HZT2Zz0wVS7V9DoWTb AB1heqjc0rsxj5SZ/ty2VmwnMcB8IoVJNsAEHV3dO6eDCRiUcvIpFpR7btBbJ8/xD2su 2Pug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j+q1JcR2OLS2GOubf/h49n6j2B65VbtRKQSgIT5Sf0s=; b=Ahsn89cFE6sEKCvSjdsLx5hlXAj4O0TfZm+jxX7WLy79k5i2F1HTmhSmLRtTBOK8YS wbMHUmjwGQj45/jazaethKqyR4RKaECj03biPdjElPZpNeFzfA7tiJ114kf2yCTzZhom th2SqXJCQkOkb2NihyfXaUeLTb/JwNqAhwUnDtt8qHYcxUPCqgbhonH48YA5xQ5l6XT9 BKc15N5cwIzdv1CCLpK7elGzT/kI27/5ZrFW2SUz7KnUNesKOnAApAIQ1av0Dd9ltGpG LFoEI3vpKVdWuXJ0T7IAJNRUUx2GZxYk2pxLksL76uJehyos1z5NtN8SZA7Cgct65rTh TvXw== X-Gm-Message-State: ALyK8tKDRzLWqphLnfAs7s60zKLxuZ4JR+sqYzcPgedzP6h74G5O7McHkUUhw1QyWihWdyi3gDRNVjLWkzDYNVQz X-Received: by 10.36.11.84 with SMTP id 81mr20663134itd.76.1466452951208; Mon, 20 Jun 2016 13:02:31 -0700 (PDT) MIME-Version: 1.0 References: <655C07320163294895BBADA28372AF5D488DF486@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D488DF486@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Mon, 20 Jun 2016 20:02:21 +0000 Message-ID: To: "Scharf, Michael (Nokia - DE)" , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary=001a1140c3383d05ca0535bb2f74 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] Agenda requests for TCPM at IETF 96 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 20:02:34 -0000 --001a1140c3383d05ca0535bb2f74 Content-Type: text/plain; charset=UTF-8 draft: https://tools.ietf.org/html/draft-cheng-tcpm-rack-00 title: updates of RACK Linux implementation time: 20m speaker: Yuchung Cheng ps. we plan to update the draft before the mtg On Mon, Jun 20, 2016 at 11:20 AM Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > Hi, > > It is time to start building the TCPM meeting agenda for Berlin meeting. > *Tentatively* TCPM got the Monday morning slot. > > If you want to present something, please send a request to the TCPM chairs > with the following information: > > * Draft name / presentation title > * Requested time > * Speaker > > Please send requests as soon as possible, but latest by Thursday, July 7. > > Thanks! > > Michael, Pasi, Yoshifumi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a1140c3383d05ca0535bb2f74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

draft:=C2=A0https://tools.ietf.org/= html/draft-cheng-tcpm-rack-00=C2=A0
title: updates of =C2=A0RACK Li= nux implementation
time: 20m
speaker: Yuchung Cheng
=

ps. we plan to update the draft before the mtg
On Mon, Jun 20, 2016 at = 11:20 AM Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com> wrote:
Hi,

It is time to start building the TCPM meeting agenda for Berlin meeting. *T= entatively* TCPM got the Monday morning slot.

If you want to present something, please send a request to the TCPM chairs = with the following information:

* Draft name / presentation title
* Requested time
* Speaker

Please send requests as soon as possible, but latest by Thursday, July 7.
Thanks!

Michael, Pasi, Yoshifumi

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--001a1140c3383d05ca0535bb2f74-- From nobody Tue Jun 21 00:26:10 2016 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 6C7D212D769; Tue, 21 Jun 2016 00:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEu62OELYjBG; Tue, 21 Jun 2016 00:26:03 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D10012D61D; Tue, 21 Jun 2016 00:26:03 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.161.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 417A4278317; Tue, 21 Jun 2016 16:26:01 +0900 (JST) Received: by mail-yw0-f173.google.com with SMTP id b72so6496394ywa.3; Tue, 21 Jun 2016 00:26:01 -0700 (PDT) X-Gm-Message-State: ALyK8tJomT4BrfXEg12IdVUJT4gp2EtM991WibvDINwe4PaMjfv4Jnt2i4B0Rbw7nOuq1j/xdPS8t9jI8O54tQ== X-Received: by 10.37.221.6 with SMTP id u6mr10789492ybg.85.1466493959836; Tue, 21 Jun 2016 00:25:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.196.3 with HTTP; Tue, 21 Jun 2016 00:25:59 -0700 (PDT) In-Reply-To: <292ce8bf280356eadf53eaa5527d5182.squirrel@webmail.entel.upc.edu> References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> <9c715eeca71b9a647df289dbd40f2092.squirrel@webmail.entel.upc.edu> <655C07320163294895BBADA28372AF5D488D0A96@FR712WXCHMBA15.zeu.alcatel-lucent.com> <292ce8bf280356eadf53eaa5527d5182.squirrel@webmail.entel.upc.edu> From: Yoshifumi Nishida Date: Tue, 21 Jun 2016 00:25:59 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Carles Gomez Montenegro Content-Type: multipart/alternative; boundary=001a114bc8948a9e720535c4bbf4 Archived-At: Cc: "lwip@ietf.org" , "jon.crowcroft@cl.cam.ac.uk" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 07:26:05 -0000 --001a114bc8948a9e720535c4bbf4 Content-Type: text/plain; charset=UTF-8 Hi Carles, On Mon, Jun 20, 2016 at 10:08 AM, Carles Gomez Montenegro < carlesgo@entel.upc.edu> wrote: > Dear Michael, > > Thank you very much for your detailed comments (and sorry for the late > response). > > Please find below some inline responses: > > > Just out-of-curiosity: In 1981, when the current TCP spec was published, > > end hosts had significant processing and memory limitations. Quite a bit > > of the TCP protocol mechanisms were designed to deal with senders and > > receivers that have very small buffers, e.g., of the order of the maximum > > segment size.RFC 793 is very carefully designed to deal with these > > constraints. And current TCP implementations are still backward > compatible > > to RFC 793. > > > > When quickly scanning through this document, some observations (the list > > is not comprehensive): > > > > - TCP counts window sizes in bytes, which > > draft-gomez-core-tcp-constrained-node-networks-00 seems to ignore. > > Agreed. We'll address this in the next draft revision. > > > - Out-of-my-head, nothing prevents a TCP sender from limiting the > > congestion window to a small window (e.g., one MSS). This basically turns > > TCP into a stop-and-wait protocol. A TCP sender can unilaterally decide > to > > limit its congestion window if it wants to simplify its implementation. I > > am not sure if RFC 2119 language is needed for that at all. > > > > - A TCP receiver can use the receive window to prevent the sender from > > sending data, e.g., if it can only deal with one MSS. It may be > > interesting to look into whether advertising a maximum receive window > e.g. > > of at most one MSS would solve some of the problems discussed in the > > draft. > > Right, one thing to provide details about in the document is which are the > available ways to enable the intended stop-and-wait operation. > I'm guessing clamping window size won't be a good way to make TCP perform stop-and-wait operation and there is no good way for it. Because TCP is basically not designed to perform stop-and-wait operation, I think you'll have to describe the operation explicitly if you want to do it. Thanks, -- Yoshi --001a114bc8948a9e720535c4bbf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carles,

On Mon, Jun 20, 2016 at 10:08 AM, Carles Gomez Montenegro <carlesgo@entel.upc.edu> wrote:
Dear M= ichael,

Thank you very much for your detailed comments (and sorry for the late
response).

Please find below some inline responses:

> Just out-of-curiosity: In 1981, when the current TCP spec was publishe= d,
> end hosts had significant processing and memory limitations. Quite a b= it
> of the TCP protocol mechanisms were designed to deal with senders and<= br> > receivers that have very small buffers, e.g., of the order of the maxi= mum
> segment size.RFC 793 is very carefully designed to deal with these
> constraints. And current TCP implementations are still backward compat= ible
> to RFC 793.
>
> When quickly scanning through this document, some observations (the li= st
> is not comprehensive):
>
> - TCP counts window sizes in bytes, which
> draft-gomez-core-tcp-constrained-node-networks-00 seems to ignore.

Agreed. We'll address this in the next draft revision.

> - Out-of-my-head, nothing prevents a TCP sender from limiting the
> congestion window to a small window (e.g., one MSS). This basically tu= rns
> TCP into a stop-and-wait protocol. A TCP sender can unilaterally decid= e to
> limit its congestion window if it wants to simplify its implementation= . I
> am not sure if RFC 2119 language is needed for that at all.
>
> - A TCP receiver can use the receive window to prevent the sender from=
> sending data, e.g., if it can only deal with one MSS. It may be
> interesting to look into whether advertising a maximum receive window = e.g.
> of at most one MSS would solve some of the problems discussed in the > draft.

Right, one thing to provide details about in the document is which a= re the
available ways to enable the intended stop-and-wait operation.

I'm guessing clamping window size won't be = a good way to make TCP perform stop-and-wait operation and there is no good= way for it.
Because TCP is basically not designed to perform sto= p-and-wait operation, I think you'll have to describe the operation exp= licitly if you want to do it.=C2=A0

Thanks,
<= div>--
Yoshi
--001a114bc8948a9e720535c4bbf4-- From nobody Tue Jun 21 03:46:53 2016 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 E1CB012D18B; Tue, 21 Jun 2016 03:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 CBcLN0f6_ORv; Tue, 21 Jun 2016 03:46:42 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8544612D189; Tue, 21 Jun 2016 03:46:42 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id u5LAkb3I017611; Tue, 21 Jun 2016 12:46:37 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 879851D53C1; Tue, 21 Jun 2016 12:46:36 +0200 (CEST) Received: from 131.111.5.142 by webmail.entel.upc.edu with HTTP; Tue, 21 Jun 2016 12:47:13 +0200 Message-ID: <58191482f94cf2604e279ccd0885a9e0.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> Date: Tue, 21 Jun 2016 12:47:13 +0200 From: "Carles Gomez Montenegro" To: "Abhijan Bhattacharyya" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Delayed for 17:38:15 by milter-greylist-4.4.3 (violet.upc.es [147.83.2.51]); Tue, 21 Jun 2016 12:46:38 +0200 (CEST) Archived-At: Cc: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" , core@ietf.org Subject: Re: [tcpm] [core] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 10:46:45 -0000 Hi Abhijan, (Keeping the lists included as destinations, sorry for multiple copies...) Thank you very much for your feedback. Please find some inline comments below: > Hi, > > Section 3.4 of the draft states the following: > > "it is envisaged that further segment exchanges will take place within an > interval of two hours since the last segment has been sent" Actually, the complete sentence is: 'In CNNs, a TCP connection SHOULD be kept open as long as the two TCP endpoints have more data to exchange or it is envisaged that further segment exchanges will take place within an interval of two hours since the last segment has been sent.' So the 'as long as' still precedes the sentence you have pointed out. Anyway, prepending an 'if' to the sentence may help clarify the text. By the way, the two-hour value (influenced by the default keep-alive timer) was chosen here as a trade-off between avoiding too frequent TCP connection establishment overhead and avoiding to keep unused state in constrained devices for too long. > Could you please explain a bit about the basis of such a deterministic > assumption? If you could share some pointers to any study related to this. > There is RFC 5382 which kind of mandates that the time out cannot be less > than 124 minutes. Does it drive the above assumption? However, not sure > how many implementations adheres to the time mentioned in RFC 5382. RFC 5382 (which is very relevant for this draft) requires NATs not to remove state for a live connection, ensuring that 'applications can send keep-alive packets at the default rate (every 2 hours)'. So the two-hour default keep-alive timer is also influencing the 124-minute time out mentioned in RFC 5382. > In the recent time I had been looking at the different efforts that has > gone into improving TCP performance from different aspects under different > circumstances since the early days. Given the short transactional type of > exchanges, would it be also worthwhile to count experimental RFCs like > "TCP Fast Open" and see how CoAP performs on top of it? I agree that this is something to look at. TCP Fast Open allows data to be carried in the SYN (and SYN-ACK) packet(s) and consumed by the receiving end during the initial connection handshake. However, TCP Fast Open involves an initial RTT for requesting a 4-to-16-byte cookie, which is then included in the Fast Open option of the SYN segment of new connections. Furthermore, the cookie needs to be updated (I'm not sure how often) for security. TCP Fast Open can benefit applications that open 'many' new connections, while the approach proposed in our draft is to keep a TCP connection open for long time, avoiding connection establishment as much as possible. If a TCP connection is kept open for long time, the possible benefits (which, in my opinion, are not so clear considering all of the above) of TCP Fast Open will become asymptotically negligible. Cheers, Carles > Regards > Abhijan Bhattacharyya From nobody Tue Jun 21 04:15:03 2016 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 D5CDA12D13D; Tue, 21 Jun 2016 04:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 9Qy-lDszX7ZT; Tue, 21 Jun 2016 04:15:01 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3925912B02A; Tue, 21 Jun 2016 04:15:00 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id u5LBEu9t013285; Tue, 21 Jun 2016 13:14:56 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 38C511D53C1; Tue, 21 Jun 2016 13:14:55 +0200 (CEST) Received: from 131.111.5.142 by webmail.entel.upc.edu with HTTP; Tue, 21 Jun 2016 13:15:32 +0200 Message-ID: <3a4e3401654375e79f48cf4ff123023c.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> <9c715eeca71b9a647df289dbd40f2092.squirrel@webmail.entel.upc.edu> <655C07320163294895BBADA28372AF5D488D0A96@FR712WXCHMBA15.zeu.alcatel-lucent.com> <292ce8bf280356eadf53eaa5527d5182.squirrel@webmail.entel.upc.edu> Date: Tue, 21 Jun 2016 13:15:32 +0200 From: "Carles Gomez Montenegro" To: "Yoshifumi Nishida" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Delayed for 18:06:34 by milter-greylist-4.4.3 (dash.upc.es [147.83.2.50]); Tue, 21 Jun 2016 13:14:57 +0200 (CEST) Archived-At: Cc: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 11:15:03 -0000 Hi Yoshi, > Hi Carles, >> > - A TCP receiver can use the receive window to prevent the sender from >> > sending data, e.g., if it can only deal with one MSS. It may be >> > interesting to look into whether advertising a maximum receive window >> e.g. >> > of at most one MSS would solve some of the problems discussed in the >> > draft. >> >> Right, one thing to provide details about in the document is which are >> the >> available ways to enable the intended stop-and-wait operation. >> > > I'm guessing clamping window size won't be a good way to make TCP perform > stop-and-wait operation and there is no good way for it. > Because TCP is basically not designed to perform stop-and-wait operation, > I > think you'll have to describe the operation explicitly if you want to do > it. Thank you very much for the comment. We'll provide our approach to addressing it in a future revision of the draft. Cheers, Carles From nobody Wed Jun 22 05:39:38 2016 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 50C3E12D0FB; Wed, 22 Jun 2016 05:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JnhxTFnow3b; Wed, 22 Jun 2016 05:39:27 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 975EA12B025; Wed, 22 Jun 2016 05:39:23 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3AqVR5SxWezrtvTDXwu5C+f1LMhRjV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYZxSOt8tkgFKBZ4jH8fUM07OQ6PG4HzRaqsrb+Fk5M7VyFDY9wf?= =?us-ascii?q?0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5?= =?us-ascii?q?K6zPF5LIiIzvjqbpqsWVO18D2GD1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd?= =?us-ascii?q?5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3SNp41Rr1ADTkgL3t9pIiy7UGC?= =?us-ascii?q?HkOz4S5WeWwMlhdTSyfC6RzoFrL2tDf3sOdywi7QdZn9RKowVC+t6I9mTgPljG?= =?us-ascii?q?EaLzV//W3K3J9elqVe9Turpx19yoicSoGcKOZ3daPUZ8ILTCIVV8xRVi5IBMW2?= =?us-ascii?q?b4ITE+MKPe9Cvpj0j0cFtl21Agz6V7Cn8SNBmnKjhf5y6O8mCwyTmVV4R98=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DOAQDshWpX/wQXEqxeDoQGfbo0gXoah?= =?us-ascii?q?X0CgWQUAQEBAQEBAQGBC4IyghoBAQEDAWcQAgULCwcGBAMBAiQEB0YJCAYLCBu?= =?us-ascii?q?IDbFuAQEBkSkBAQEBAQUBAQEBAQEhhH5nhQ+EYIU7BY5rihKBWI4+hFOIZ498H?= =?us-ascii?q?oJxekNmAYpwAQEB?= X-IPAS-Result: =?us-ascii?q?A2DOAQDshWpX/wQXEqxeDoQGfbo0gXoahX0CgWQUAQEBAQE?= =?us-ascii?q?BAQGBC4IyghoBAQEDAWcQAgULCwcGBAMBAiQEB0YJCAYLCBuIDbFuAQEBkSkBA?= =?us-ascii?q?QEBAQUBAQEBAQEhhH5nhQ+EYIU7BY5rihKBWI4+hFOIZ498HoJxekNmAYpwAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.26,509,1459794600"; d="scan'208";a="96758929" In-Reply-To: <58191482f94cf2604e279ccd0885a9e0.squirrel@webmail.entel.upc.edu> References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> <58191482f94cf2604e279ccd0885a9e0.squirrel@webmail.entel.upc.edu> To: "Carles Gomez Montenegro" MIME-Version: 1.0 X-KeepSent: 0901C455:CBF78233-65257FDA:004401B0; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Wed, 22 Jun 2016 18:09:19 +0530 X-MIMETrack: Serialize by Router on InKolM02/TCS(Release 9.0.1FP4HF528 | October 8, 2015) at 06/22/2016 18:09:20, Serialize complete at 06/22/2016 18:09:20 Content-Type: multipart/alternative; boundary="=_alternative 0045848F65257FDA_=" Archived-At: Cc: "lwip@ietf.org" , "tcpm@ietf.org Extensions" , "jon.crowcroft@cl.cam.ac.uk" , core@ietf.org Subject: Re: [tcpm] [core] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 12:39:30 -0000 This is a multipart message in MIME format. --=_alternative 0045848F65257FDA_= Content-Type: text/plain; charset="US-ASCII" Hi Carles, Thank you for the explanations. Just couple of observations: > RFC 5382 (which is very relevant for this draft) requires NATs not to > remove state for a live connection, ensuring that 'applications can send > keep-alive packets at the default rate (every 2 hours)'. So the two-hour > default keep-alive timer is also influencing the 124-minute time out > mentioned in RFC 5382. That is understood. The point is that, there is an element of doubt regarding whether the implementations in reality abide by the given time interval or silently times out without the knowledge of the end-points. > TCP Fast Open can benefit applications that open 'many' new connections, > while the approach proposed in our draft is to keep a TCP connection open > for long time, avoiding connection establishment as much as possible. > > If a TCP connection is kept open for long time, the possible benefits > (which, in my opinion, are not so clear considering all of the above) of > TCP Fast Open will become asymptotically negligible. Keeping TCP session active for long time may be definitely useful for certain cases. But again, there is the additional draining of energy due the keep alive mechanism. Also, as IoT end-points may like to conserve energy by opportunistic sleeping, maintaining TCP connection for too long may be difficult and TFO kind of approach, though designed for browsers, may be useful. So a study in this line may help. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ "Carles Gomez Montenegro" wrote on 06/21/2016 04:17:13 PM: > From: "Carles Gomez Montenegro" > To: "Abhijan Bhattacharyya" > Cc: "jon.crowcroft@cl.cam.ac.uk" , > "lwip@ietf.org" , "tcpm@ietf.org Extensions" > , core@ietf.org > Date: 06/21/2016 04:17 PM > Subject: Re: [core] [tcpm] [Lwip] [Fwd: New Version Notification for > draft-gomez-core-tcp-constrained-node-networks-00.txt] > > Hi Abhijan, > > (Keeping the lists included as destinations, sorry for multiple copies...) > > Thank you very much for your feedback. Please find some inline comments > below: > > > Hi, > > > > Section 3.4 of the draft states the following: > > > > "it is envisaged that further segment exchanges will take place within an > > interval of two hours since the last segment has been sent" > > Actually, the complete sentence is: > > 'In CNNs, a TCP connection SHOULD be kept open as long as the two TCP > endpoints have more data to exchange or it is envisaged that further > segment exchanges will take place within an interval of two hours > since the last segment has been sent.' > > So the 'as long as' still precedes the sentence you have pointed out. > Anyway, prepending an 'if' to the sentence may help clarify the text. > > By the way, the two-hour value (influenced by the default keep-alive > timer) was chosen here as a trade-off between avoiding too frequent TCP > connection establishment overhead and avoiding to keep unused state in > constrained devices for too long. > > > Could you please explain a bit about the basis of such a deterministic > > assumption? If you could share some pointers to any study related to this. > > There is RFC 5382 which kind of mandates that the time out cannot be less > > than 124 minutes. Does it drive the above assumption? However, not sure > > how many implementations adheres to the time mentioned in RFC 5382. > > RFC 5382 (which is very relevant for this draft) requires NATs not to > remove state for a live connection, ensuring that 'applications can send > keep-alive packets at the default rate (every 2 hours)'. So the two-hour > default keep-alive timer is also influencing the 124-minute time out > mentioned in RFC 5382. > > > In the recent time I had been looking at the different efforts that has > > gone into improving TCP performance from different aspects under different > > circumstances since the early days. Given the short transactional type of > > exchanges, would it be also worthwhile to count experimental RFCs like > > "TCP Fast Open" and see how CoAP performs on top of it? > > I agree that this is something to look at. > > TCP Fast Open allows data to be carried in the SYN (and SYN-ACK) packet(s) > and consumed by the receiving end during the initial connection handshake. > > However, TCP Fast Open involves an initial RTT for requesting a > 4-to-16-byte cookie, which is then included in the Fast Open option of the > SYN segment of new connections. Furthermore, the cookie needs to be > updated (I'm not sure how often) for security. > > TCP Fast Open can benefit applications that open 'many' new connections, > while the approach proposed in our draft is to keep a TCP connection open > for long time, avoiding connection establishment as much as possible. > > If a TCP connection is kept open for long time, the possible benefits > (which, in my opinion, are not so clear considering all of the above) of > TCP Fast Open will become asymptotically negligible. > > Cheers, > > Carles > > > > Regards > > Abhijan Bhattacharyya > > =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 0045848F65257FDA_= Content-Type: text/html; charset="US-ASCII" Hi Carles,
Thank you for the explanations.

Just couple of observations:

> RFC 5382 (which is very relevant for this draft) requires NATs not to
> remove state for a live connection, ensuring that 'applications can send
> keep-alive packets at the default rate (every 2 hours)'. So the two-hour
> default keep-alive timer is also influencing the 124-minute time out
> mentioned in RFC 5382.

That is understood. The point is that, there is an element of doubt regarding whether the implementations in reality abide by the given time interval or silently times out without the knowledge of the end-points.

> TCP Fast Open can benefit applications that open 'many' new connections,
> while the approach proposed in our draft is to keep a TCP connection open
> for long time, avoiding connection establishment as much as possible.
>
> If a TCP connection is kept open for long time, the possible benefits
> (which, in my opinion, are not so clear considering all of the above) of
> TCP Fast Open will become asymptotically negligible.

Keeping TCP session active for long time may be definitely useful for certain cases. But again, there is the additional draining of energy due the keep alive mechanism. Also, as IoT end-points may like to conserve energy by opportunistic sleeping, maintaining TCP connection for too long may be difficult and TFO kind of approach, though designed for browsers, may be useful. So a study in this line may help.    

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> wrote on 06/21/2016 04:17:13 PM:

> From: "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
> To: "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>
> Cc: "jon.crowcroft@cl.cam.ac.uk" <jon.crowcroft@cl.cam.ac.uk>,
> "lwip@ietf.org" <lwip@ietf.org>, "tcpm@ietf.org Extensions"
> <tcpm@ietf.org>, core@ietf.org
> Date: 06/21/2016 04:17 PM
> Subject: Re: [core] [tcpm] [Lwip] [Fwd: New Version Notification for
> draft-gomez-core-tcp-constrained-node-networks-00.txt]
>
> Hi Abhijan,
>
> (Keeping the lists included as destinations, sorry for multiple copies...)
>
> Thank you very much for your feedback. Please find some inline comments
> below:
>
> > Hi,
> >
> > Section 3.4 of the draft states the following:
> >
> > "it is envisaged that further segment exchanges will take place within an
> > interval of two hours since the last segment has been sent"
>
> Actually, the complete sentence is:
>
>    'In CNNs, a TCP connection SHOULD be kept open as long as the two TCP
>    endpoints have more data to exchange or it is envisaged that further
>    segment exchanges will take place within an interval of two hours
>    since the last segment has been sent.'
>
> So the 'as long as' still precedes the sentence you have pointed out.
> Anyway, prepending an 'if' to the sentence may help clarify the text.
>
> By the way, the two-hour value (influenced by the default keep-alive
> timer) was chosen here as a trade-off between avoiding too frequent TCP
> connection establishment overhead and avoiding to keep unused state in
> constrained devices for too long.
>
> > Could you please explain a bit about the basis of such a deterministic
> > assumption? If you could share some pointers to any study related to this.
> > There is RFC 5382 which kind of mandates that the time out cannot be less
> > than 124 minutes. Does it drive the above assumption? However, not sure
> > how many implementations adheres to the time mentioned in RFC 5382.
>
> RFC 5382 (which is very relevant for this draft) requires NATs not to
> remove state for a live connection, ensuring that 'applications can send
> keep-alive packets at the default rate (every 2 hours)'. So the two-hour
> default keep-alive timer is also influencing the 124-minute time out
> mentioned in RFC 5382.
>
> > In the recent time I had been looking at the different efforts that has
> > gone into improving TCP performance from different aspects under different
> > circumstances since the early days. Given the short transactional type of
> > exchanges, would it be also worthwhile to count experimental RFCs like
> > "TCP Fast Open" and see how CoAP performs on top of it?
>
> I agree that this is something to look at.
>
> TCP Fast Open allows data to be carried in the SYN (and SYN-ACK) packet(s)
> and consumed by the receiving end during the initial connection handshake.
>
> However, TCP Fast Open involves an initial RTT for requesting a
> 4-to-16-byte cookie, which is then included in the Fast Open option of the
> SYN segment of new connections. Furthermore, the cookie needs to be
> updated (I'm not sure how often) for security.
>
> TCP Fast Open can benefit applications that open 'many' new connections,
> while the approach proposed in our draft is to keep a TCP connection open
> for long time, avoiding connection establishment as much as possible.
>
> If a TCP connection is kept open for long time, the possible benefits
> (which, in my opinion, are not so clear considering all of the above) of
> TCP Fast Open will become asymptotically negligible.
>
> Cheers,
>
> Carles
>
>
> > Regards
> > Abhijan Bhattacharyya
>
>

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 0045848F65257FDA_=-- From nobody Wed Jun 22 06:06:00 2016 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 792FB12B039; Wed, 22 Jun 2016 06:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 FUId0k8lY1IC; Wed, 22 Jun 2016 06:05:53 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 9ED4912B007; Wed, 22 Jun 2016 06:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u5MD5dZi017983; Wed, 22 Jun 2016 15:05:39 +0200 (CEST) Received: from nar-3.local.mail (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3rZPwL5xn1zDgWb; Wed, 22 Jun 2016 15:05:38 +0200 (CEST) Date: Wed, 22 Jun 2016 15:05:32 +0200 From: Carsten Bormann To: Abhijan Bhattacharyya , Carles Gomez Montenegro Message-ID: In-Reply-To: References: <655C07320163294895BBADA28372AF5D488CC027@FR712WXCHMBA15.zeu.alcatel-lucent.com> <575A9092.9090604@tzi.org> <58191482f94cf2604e279ccd0885a9e0.squirrel@webmail.entel.upc.edu> X-Mailer: Airmail (367) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="576a8d22_6c67b9ca_133e" Archived-At: Cc: "=?utf-8?Q?lwip=40ietf.org?=" , "=?utf-8?Q?tcpm=40ietf.org_Extensions?=" , "=?utf-8?Q?jon.crowcroft=40cl.cam.ac.uk?=" , core@ietf.org Subject: Re: [tcpm] [core] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 13:05:54 -0000 --576a8d22_6c67b9ca_133e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 22 June 2016 at 14:39:52, Abhijan Bhattacharyya (abhijan.bhattacharyya= =40tcs.com) wrote: That is understood. The point is that, there is an element of doubt regar= ding whether the implementations in reality abide by the given time inter= val or silently times out without the knowledge of the end-points. There is no doubt at all :-/ http://conferences.sigcomm.org/imc/2010/papers/p260.pdf =46igure 7, Section 4.2: =22More than half the devices fail to meet the IET=46 recommended timeout= of 124 min=E2=80=9D=C2=A0 This study is a few years old, but I would be surprised if the situation = has become much better. (Are there newer studies of this type=3F) Gr=C3=BC=C3=9Fe, Carsten --576a8d22_6c67b9ca_133e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline