From nobody Tue Feb 2 06:02:08 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 9AE411A9004; Tue, 2 Feb 2016 06:02:03 -0800 (PST) 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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160202140203.3223.9884.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 06:02:03 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 14:02:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Retransmission Timeout Considerations Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-00.txt Pages : 7 Date : 2016-02-02 Abstract: Each implementation of a retransmission timeout mechanism must balance correctness and timeliness and therefore no implementation suits all situations. This document provides high-level guidance for retransmission timeout schemes appropriate for general use in the Internet. Within the guidelines, 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-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 3 02:34:30 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEDC1A89E9 for ; Wed, 3 Feb 2016 02:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 NI14UhdvD5Q5 for ; Wed, 3 Feb 2016 02:34:26 -0800 (PST) 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 56F2B1A89C5 for ; Wed, 3 Feb 2016 02:34:25 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DCDC3577012F3 for ; Wed, 3 Feb 2016 10:34:20 +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 u13AYMSA020890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 3 Feb 2016 10:34:23 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 u13AYDT5002292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Feb 2016 11:34:21 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 3 Feb 2016 11:34:08 +0100 From: "Scharf, Michael (Nokia - DE)" To: "tcpm@ietf.org Extensions" Thread-Topic: I-D Action: draft-ietf-tcpm-rto-consider-00.txt Thread-Index: AQHRXcJccnOUdy9FEkyLW+envu/qoJ8aHs9A Date: Wed, 3 Feb 2016 10:34:08 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4862C817@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.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] FW: I-D Action: draft-ietf-tcpm-rto-consider-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2016 10:34:28 -0000 Since it has been suggested to move this short document forward relatively = fast, please have look at this new version. With chair hat off: To me, the sentence on page 5 "In such a case a congest= ion control action is not required." does not really cover an undo of conge= stion control actions once a non-congestion event is detected. But this may= really be nitpicking... Thanks Michael -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of EXT = internet-drafts@ietf.org Sent: Tuesday, February 02, 2016 3:02 PM To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: I-D Action: draft-ietf-tcpm-rto-consider-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Retransmission Timeout Considerations Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-00.txt Pages : 7 Date : 2016-02-02 Abstract: Each implementation of a retransmission timeout mechanism must balance correctness and timeliness and therefore no implementation suits all situations. This document provides high-level guidance for retransmission timeout schemes appropriate for general use in the Internet. Within the guidelines, 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-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt From nobody Thu Feb 4 04:58:01 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE1E1B2E75 for ; Thu, 4 Feb 2016 04:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dL5njBGieL4J for ; Thu, 4 Feb 2016 04:57:58 -0800 (PST) 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 B5EDD1B2E74 for ; Thu, 4 Feb 2016 04:57:58 -0800 (PST) Received: from lawyers.icir.org (obrien.ICSI.Berkeley.EDU [192.150.187.23]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u14Cvv3i012820; Thu, 4 Feb 2016 04:57:57 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 57DCE391DE4B; Thu, 4 Feb 2016 07:57:58 -0500 (EST) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D4862C817@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Glycerine X-URL-0: http://www.icir.org/mallman-files/Document14671.pdf X-URL-1: http://www.icir.org/mallman-files/Document89779.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 04 Feb 2016 07:57:58 -0500 Message-ID: <9974.1454590678@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-rto-consider-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2016 12:57:59 -0000 --=-------459435943823349593450 Content-Type: text/plain Michael- > To me, the sentence on page 5 "In such a case a congestion control > action is not required." does not really cover an undo of > congestion control actions once a non-congestion event is > detected. But this may really be nitpicking... I am not sure I understand what you mean. The full text says: (4) Retransmission timeouts MUST be taken as indications of congestion in the network and the sending rate adapted using a standard mechanism (e.g., TCP collapses the congestion window to one segment [RFC5681]). This ensures network safety. An exception is made to this rule if a standard mechanism is used to determine that a particular loss is due to a non-congestion event (e.g., bit errors or packet reordering). In such a case a congestion control action is not required. Would you prefer this just explicitly notes that undo-ing CC decisions (via a standard mechanism) is fine? In other words, is your comment that the language focuses too much on the initial decision and not a later decision that might reverse course? I am happy to try to make things more clear, but I don't quite follow what isn't clear yet. Thanks! allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlazStYACgkQWyrrWs4yIs43dQCffyx5Q1ofSgp7RvJM9wdaFd3x ArYAn2tBOqx9UfTyHJDl0P6/y1WAIHMk =3iM9 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Thu Feb 4 05:06:16 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771E71A8978 for ; Thu, 4 Feb 2016 05:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 vNS_fRssgq25 for ; Thu, 4 Feb 2016 05:06:14 -0800 (PST) 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 EA3011A1A25 for ; Thu, 4 Feb 2016 05:06:13 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id C4A14CD29B234; Thu, 4 Feb 2016 13:06:09 +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 u14D6BFf025400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Feb 2016 13:06:11 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 u14D62Q6029131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Feb 2016 14:06:11 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 4 Feb 2016 14:06:07 +0100 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" Thread-Topic: [tcpm] FW: I-D Action: draft-ietf-tcpm-rto-consider-00.txt Thread-Index: AQHRX0u21ulI2fRWwUetxt0a4rAWMZ8b2Tpw Date: Thu, 4 Feb 2016 13:06:06 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48635F41@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D4862C817@FR712WXCHMBA15.zeu.alcatel-lucent.com> <9974.1454590678@lawyers.icir.org> In-Reply-To: <9974.1454590678@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.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-rto-consider-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 13:06:15 -0000 Yes, I think that a slightly different wording that also includes a later d= ecision could be better. Possibly one could just add something like "... an= d could be undone". Anyway, as I said, this may really be nitpicking - and I am not a native sp= eaker. Michael -----Original Message----- From: mallman@icir.org [mailto:mallman@icir.org]=20 Sent: Thursday, February 04, 2016 1:58 PM To: Scharf, Michael (Nokia - DE) Cc: tcpm@ietf.org Extensions Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-rto-consider-00.txt=20 Michael- > To me, the sentence on page 5 "In such a case a congestion control=20 > action is not required." does not really cover an undo of congestion=20 > control actions once a non-congestion event is detected. But this may=20 > really be nitpicking... I am not sure I understand what you mean. The full text says: (4) Retransmission timeouts MUST be taken as indications of congestion in the network and the sending rate adapted using a standard mechanism (e.g., TCP collapses the congestion window to one segment [RFC5681]). This ensures network safety. An exception is made to this rule if a standard mechanism is used to determine that a particular loss is due to a non-congestion event (e.g., bit errors or packet reordering). In such a case a congestion control action is not required. Would you prefer this just explicitly notes that undo-ing CC decisions (via= a standard mechanism) is fine? In other words, is your comment that the l= anguage focuses too much on the initial decision and not a later decision t= hat might reverse course? I am happy to try to make things more clear, but I don't quite follow what = isn't clear yet. Thanks! allman From nobody Thu Feb 11 11:12:39 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC83B1B394F; Thu, 11 Feb 2016 11:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 cD9ia-uevMbq; Thu, 11 Feb 2016 11:12:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24D21B3958; Thu, 11 Feb 2016 11:12:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D7109180471; Thu, 11 Feb 2016 11:11:56 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160211191156.D7109180471@rfc-editor.org> Date: Thu, 11 Feb 2016 11:11:56 -0800 (PST) Archived-At: Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 7765 on TCP and Stream Control Transmission Protocol (SCTP) RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 19:12:36 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7765 Title: TCP and Stream Control Transmission Protocol (SCTP) RTO Restart Author: P. Hurtig, A. Brunstrom, A. Petlund, M. Welzl Status: Experimental Stream: IETF Date: February 2016 Mailbox: per.hurtig@kau.se, anna.brunstrom@kau.se, apetlund@simula.no, michawe@ifi.uio.no Pages: 15 Characters: 35361 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-rtorestart-10.txt URL: https://www.rfc-editor.org/info/rfc7765 DOI: http://dx.doi.org/10.17487/RFC7765 This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short lived or application limited. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Feb 17 12:20:49 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25D61A8A95 for ; Wed, 17 Feb 2016 12:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 v0WY_778ghBo for ; Wed, 17 Feb 2016 12:20:47 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C1D1AD049 for ; Wed, 17 Feb 2016 12:20:46 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-16-56c4d61ccf5a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7A.28.15637.C16D4C65; Wed, 17 Feb 2016 21:20:44 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.36]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Wed, 17 Feb 2016 21:20:44 +0100 From: Ingemar Johansson S To: "'gorry@erg.abdn.ac.uk' (gorry@erg.abdn.ac.uk)" Thread-Topic: RFC7661, more recent Linux patch available ? Thread-Index: AdFpv4nq/EL5/KCORje/D8pV6bhJ5w== Date: Wed, 17 Feb 2016 20:20:43 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA4155DAC7@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA4155DAC7ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbFdTlfm2pEwg4aHhhav22YzWmw7OZ/J gcmj5/MLJo8lS34yBTBFcdmkpOZklqUW6dslcGVMn36evWCHQ8WUm7MYGxi3WHcxcnJICJhI nD3zig3CFpO4cG89kM3FISRwmFFi/4JFzBDOYkaJlhOvGUGq2ARsJFYe+g5miwh4SSx7+h/M ZhZQllh+bDo7iC0sYCox79hcJogaK4nNR/pYIGw9ifkLZrKC2CwCqhIzV00Bq+EV8JXY37AU rIZRQFbi/vd7LBAzxSVuPZnPBHGdgMSSPeeZIWxRiZeP/7FC2EoSK7ZfgrohX2Lx/t0sEDMF JU7OfMIygVF4FpJRs5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1dixr9DLMjiCxjZVzGKFqcW J+WmGxnrpRZlJhcX5+fp5aWWbGIERtDBLb9VdzBefuN4iFGAg1GJh3dD4eEwIdbEsuLK3EOM EhzMSiK83NuOhAnxpiRWVqUW5ccXleakFh9ilOZgURLnXeO8PkxIID2xJDU7NbUgtQgmy8TB KdXAqGfteTzRoXL/pX/cyZ3bDykUboi0vta9W/6D0hn5ZVwz7mhZh9wyak9+WrHp7gauI9+d +/euXyg38S3LdNEfIRd6l+wNmfG+esOWktPrOth2VEl27LR7xj3nj/fCxd+/vYrufOE/7ZnQ osK1/prbt9x9MIXzftvzunTHfJOjc1bcmNyXIHVl/3QlluKMREMt5qLiRADlByaenAIAAA== Archived-At: Cc: "tcpm@ietf.org" Subject: [tcpm] RFC7661, more recent Linux patch available ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2016 20:20:49 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA4155DAC7ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gorry + others Is there a recent linux patch availlable for NewCWV (RFC7661) ?. I found some info at https://erg.abdn.ac.uk/newcwv.html , is this the lates= t ? Also, will RFC7661 be included in the Linux kernel in the future? /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "We can be heroes, just for one day" David Bowie =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_81564C0D7D4D2A4B9A86C8C7404A13DA4155DAC7ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Gorry + others

 

Is there a recent linux patch a= vaillable for NewCWV (RFC7661) ?.

I found some info at https://erg.abdn.ac.uk/newcwv.html , is this the latest ?

 

Also, will RFC7661 be included = in the Linux kernel in the future?

 

/Ingemar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Ingemar Johansson  M.Sc.

Master Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com= =

www.ericsson.com

 

“We can be heroes,

  just for on= e day”
    David Bowie

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA4155DAC7ESESSMB205erics_-- From nobody Thu Feb 18 03:55:42 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604651B3E6D for ; Thu, 18 Feb 2016 03:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 oel2z4UAmT6u for ; Thu, 18 Feb 2016 03:55:39 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 E9BBD1B3E6C for ; Thu, 18 Feb 2016 03:55:38 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 9495744A51ABA; Thu, 18 Feb 2016 11:55:34 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1IBta1O025187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Feb 2016 11:55:36 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 u1IBtagb011902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Feb 2016 12:55:36 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.231]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 18 Feb 2016 12:55:35 +0100 From: "Scharf, Michael (Nokia - DE)" To: "tcpm@ietf.org Extensions" Thread-Topic: TCPM slot at IETF 95 Thread-Index: AdFqQ0Xjhk7XZK2SS5e9DhLGwl7oeQ== Date: Thu, 18 Feb 2016 11:55:35 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4868BE99@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE 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 tcpm-chairs@tools.ietf.org" Subject: [tcpm] TCPM slot at IETF 95 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 11:55:41 -0000 Hi all, Pasi, Yoshifumi, and me would like to gauge the interest in a face-to-face = TCPM meeting in Buenos Aires.=20 In the last years, TCPM has traditionally met at every IETF meeting, and th= e chairs have already requested the usual slot for IETF 95. However, unfort= unately, right now it is not clear whether any of us chairs will make it to= Buenos Aires. Our current assumption is that we will not run into this pro= blem in the next meetings, and we assume that TCPM will meet as usual durin= g IETF 96 in Berlin. Please let us know if you are planning a presentation at IETF 95 that would= benefit from a face-to-face TCPM discussion, e.g., if an important decisio= n is to be made. If so, the chairs will look into how to make this happen.= =20 Thanks Michael From nobody Fri Feb 19 05:28:21 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECD51B2EC2; Fri, 19 Feb 2016 05:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 W3tu7sovRIWN; Fri, 19 Feb 2016 05:28:15 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACBD1B2B1C; Fri, 19 Feb 2016 05:28:12 -0800 (PST) Received: from 154.236.199.146.dyn.plus.net ([146.199.236.154]:56076 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aWl6Q-00075F-14; Fri, 19 Feb 2016 13:28:10 +0000 To: tcpm IETF list , tsvwg IETF list , AQM IETF list , TCP Prague List From: Bob Briscoe Message-ID: <56C71869.9080503@bobbriscoe.net> Date: Fri, 19 Feb 2016 13:28:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090006030305010904050805" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: "De Schepper, Koen \(Koen\)" Subject: [tcpm] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2016 13:28:18 -0000 This is a multi-part message in MIME format. --------------090006030305010904050805 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Folks, I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers. We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S, DualQ and solutions to the TCP Prague Requirements. If you don't know what all these buzzwords mean, pls read 'Background' at the end first. If you don't know what a Bar BoF is, see https://www.ietf.org/tao.html At least two purposes: i) Updates so everyone can see progress on design, implementation, evaluation, specification of the different parts, who is working on what etc. Note: You might be working on, say, an improvement to DCTCP without being motivated by all this L4S stuff, but it might be relevant. ii) To discuss how best to standardise all the different parts iii) Anything else? Perhaps interop testing, but it's probably too early for that Shout now, if you think this should be a real BoF, not just a Bar BoF, cos the deadline for BoF proposals is about 11 hrs from now: UTC 23:59 2016-02-19 (Friday). Also shout - either on or off list - if you have something relevant you would like to present at item (i) Regarding item (ii) on how best to standardise all this, we've been talking with the Transport ADs and relevant WG chairs, and there are two possible routes forward: * Proposal #1: Standardise the pieces in their relevant existing WGs. Ie: - the IP packet identifier for the L4S service in tsvwg, e.g. > - the AQM mechanism in the aqm wg, e.g. > - The essential TCP Prague requirements in the tcpm wg (the essential requirements happen to all be applicable to regular TCP congestion avoidance as well) - The 'optional' TCP Prague requirements (performance improvements) in perhaps the IRTF iccrg or tcpm, whichever is most appropriate. * Proposal #2: A new WG to do all the above. Discuss! *Background** *Back in July'15, at the IETF AQM wg in Prague, we presented the DualQ Coupled AQM. > And we demonstrated it later that week at IETF bits-n-bites exhibition. The message is, once you partition off the queuing delay of 'Classic' TCP congestion control (Reno, Cubic, etc), it's really easy to get ultra-low queueing delay with the family of TCPs that includes Data Center TCP (DCTCP). The DCTCP family is more aggressive, so normally they would starve a Classic TCP flow. This coexistence problem is why it hasn't so far been possible to release DCTCP on the public Internet. The DualQ solves this coexistence problem. it is like a semi-permeable membrane: it partitions delay, but flows share bandwidth across the divide as if they are all the same type of TCP. So, as a fortunate side-effect, DualQ also solves the problem of scaling TCP throughput long term. {Note 1} We are proposing that senders will identify packets for this new L4S queue with the ECT(1) codepoint. > We call the service offered by this new queue 'L4S' for 'Low Delay, Low Loss, Scalable throughput' DCTCP works OK as it is, but it will need some safety features. There was a lot of energy in an ad hoc session in Prague back last July, which produced a prioritised list, including performance improvements (see TCP Prague Requirements ) but then everyonr went home, went on summer holidays, returned to their day jobs and it all went quiet... If you missed all the above, we've pulled together videos of demos, short papers, I-Ds etc here: https://riteproject.eu/dctth/ Incuding this particularly useful 2-pager: “Ultra-Low Delay for All ” IETF Journal, Nov 2015. Cheers Bob Briscoe & Koen De Schepper {Note 1} As the window scales, the number of congestion signals per RTT remains the same, whereas with classic TCPs it gets smaller. -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------090006030305010904050805 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Folks,

I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers.

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S, DualQ and solutions to the TCP Prague Requirements.

If you don't know what all these buzzwords mean, pls read 'Background' at the end first.
If you don't know what a Bar BoF is, see https://www.ietf.org/tao.html

At least two purposes:
i) Updates so everyone can see progress on design, implementation, evaluation, specification of the different parts, who is working on what etc.
   Note: You might be working on, say, an improvement to DCTCP without being motivated by all this L4S stuff, but it might be relevant.
ii) To discuss how best to standardise all the different parts
iii) Anything else? Perhaps interop testing, but it's probably too early for that

Shout now, if you think this should be a real BoF, not just a Bar BoF, cos the deadline for BoF proposals is about 11 hrs from now: UTC 23:59 2016-02-19 (Friday).
Also shout - either on or off list - if you have something relevant you would like to present at item (i)

Regarding item (ii) on how best to standardise all this, we've been talking with the Transport ADs and relevant WG chairs, and there are two possible routes forward:
* Proposal #1: Standardise the pieces in their relevant existing WGs. Ie:
  - the IP packet identifier for the L4S service in tsvwg, e.g. <draft-briscoe-tsvwg-ecn-l4s-id>
  - the AQM mechanism in the aqm wg, e.g. <draft-briscoe-aqm-dualq-coupled>
  - The essential TCP Prague requirements in the tcpm wg (the essential requirements happen to all be applicable to regular TCP congestion avoidance as well)
  - The 'optional' TCP Prague requirements (performance improvements) in perhaps the IRTF iccrg or tcpm, whichever is most appropriate.
* Proposal #2: A new WG to do all the above.

Discuss!


Background
Back in July'15, at the IETF AQM wg in Prague, we presented the DualQ Coupled AQM. <draft-briscoe-aqm-dualq-coupled>
And we demonstrated it later that week at IETF bits-n-bites exhibition.

The message is, once you partition off the queuing delay of 'Classic' TCP congestion control (Reno, Cubic, etc), it's really easy to get ultra-low queueing delay with the family of TCPs that includes Data Center TCP (DCTCP).

The DCTCP family is more aggressive, so normally they would starve a Classic TCP flow. This coexistence problem is why it hasn't so far been possible to release DCTCP on the public Internet.
The DualQ solves this coexistence problem. it is like a semi-permeable membrane: it partitions delay, but flows share bandwidth across the divide as if they are all the same type of TCP.
So, as a fortunate side-effect, DualQ also solves the problem of scaling TCP throughput long term. {Note 1}

We are proposing that senders will identify packets for this new L4S queue with the ECT(1) codepoint. <draft-briscoe-tsvwg-ecn-l4s-id>
We call the service offered by this new queue 'L4S' for 'Low Delay, Low Loss, Scalable throughput'
DCTCP works OK as it is, but it will need some safety features. There was a lot of energy in an ad hoc session in Prague back last July, which produced a prioritised list, including performance improvements (see TCP Prague Requirements) but then everyonr went home, went on summer holidays, returned to their day jobs and it all went quiet...

If you missed all the above, we've pulled together videos of demos, short papers, I-Ds etc here: https://riteproject.eu/dctth/
Incuding this particularly useful 2-pager: “Ultra-Low Delay for All” IETF Journal, Nov 2015.

Cheers


Bob Briscoe & Koen De Schepper

{Note 1} As the window scales, the number of congestion signals per RTT remains the same, whereas with classic TCPs it gets smaller.
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------090006030305010904050805-- From nobody Fri Feb 19 06:28:49 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942971A8AE8 for ; Fri, 19 Feb 2016 06:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 RH32W0PDobDE for ; Fri, 19 Feb 2016 06:28:46 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 1AEE81A8AE7 for ; Fri, 19 Feb 2016 06:28:46 -0800 (PST) Received: by mail-lb0-x22a.google.com with SMTP id x4so48513902lbm.0 for ; Fri, 19 Feb 2016 06:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to:cc :content-type; bh=YV6nayokmUWF9xBXngHJM5oCb/J1cIhw+GzztAiJP5s=; b=Pn6FvJEC2kWKK3tQormsq0ZP0YxgSszeH3U62FqxFJPWuTbXVfMxKrhFbaXk0Nz0a3 FKAR8wi+LJm7hFPBHSGfw03op8wgLOJXFC+M1jQN2de5JKir8lcmEDBBmg/ZFkMyT/TP DWQd9Cou9aB6BoQEJb2ASs6iklQoX/f3pUSbZttv8hsxD2u7Wnuor2cEqqggESIfeT9+ 8UMp0BSGCIHO6a2PXjAhUnXfJF3cyxDmpUs44JgcP7Ux4wkPuwP1UUQFdeLBOfhAsK7p S8A/JxZ9/tTew8hqL8QLGqOKijl8HbgozhRYSRynE5G5nYFrMHfPlg7+o51kfwujNi4h tnLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc:content-type; bh=YV6nayokmUWF9xBXngHJM5oCb/J1cIhw+GzztAiJP5s=; b=IusV2qK2Ro3sxo+qU/keR6R/N6JbrTloE7uyjBML7O9v5kp5/qQV4PFvaeEd1Aqb9X tj6xCFufUu1MksgOKuTbx5+DBeWJSaxjXtl4EIoLA1EXTGXUPH0c+UsF5pjtf5OcPR28 JYCuoQAmyGr2aOlxUYoALzWCAmSTJLIzu34xn+zCfMdyQ3IlNY3m4vXRBO5UiaFQP//F qnBXyKxgG8CkJ3EAz+xzXr9pnnlnfg9MGjIUA46QFPIRxgVMzj6ZpP/lukGZwcq8LmrE hey5GU/nwAVSiGp2q06K5Pzw+BjtrqXT4Zt3wn6R9GufnKObPDos+F51GBz0EVMF7hO2 FHRw== X-Gm-Message-State: AG10YOQdwcMEUIt3JYNkrFKPJ15c30x/OjN4y2UPA9VrRiNKP9SlzgSCoyaxlX72uhUyMFquQ8tDUZ73zTMbhg== X-Received: by 10.112.73.69 with SMTP id j5mr4576620lbv.124.1455892124352; Fri, 19 Feb 2016 06:28:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.78.74 with HTTP; Fri, 19 Feb 2016 06:28:24 -0800 (PST) From: Raffaello Secchi Date: Fri, 19 Feb 2016 14:28:24 +0000 Message-ID: To: Ingemar Johansson S , Gorry Fairhurst Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: [tcpm] RFC7661, more recent Linux patch available ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: r.secchi@gmail.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 14:28:47 -0000 Hi Ingemar, Yes, the patch that you found is the most updated. At the moment there are no plans to put this in the Linux kernel. Raffaello From nobody Fri Feb 19 10:24:10 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBBE1B2B05; Fri, 19 Feb 2016 10:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 H-4ECxd_b1U4; Fri, 19 Feb 2016 10:24:04 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 377471ACE6C; Fri, 19 Feb 2016 10:24:04 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 69834C94BF; Fri, 19 Feb 2016 13:23:59 -0500 (EST) Date: Fri, 19 Feb 2016 13:23:59 -0500 From: John Leslie To: Bob Briscoe Message-ID: <20160219182359.GA74531@verdi> References: <56C71869.9080503@bobbriscoe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C71869.9080503@bobbriscoe.net> User-Agent: Mutt/1.4.1i Archived-At: Cc: tcpm IETF list , tsvwg IETF list , AQM IETF list , TCP Prague List , tsv-ads@ietf.org, "De Schepper, Koen \(Koen\)" Subject: Re: [tcpm] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2016 18:24:05 -0000 Bob Briscoe wrote: > > I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers. > > We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S, > DualQ and solutions to the TCP Prague Requirements. This feels like it belongs as a non-WG-forming formal BoF. It describes work spanning at least three WGs; and could benefit from formal scheduling to avoid conflicts with those WGs and others. OTOH, it really isn't to the point where a WG charter can reasonably be drafted. First we must decide whether the work _can_ be split among existing WGs. However this may turn out, I wish to participate remotely. -- John Leslie From nobody Mon Feb 22 00:54:20 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FC91B2B6F; Mon, 22 Feb 2016 00:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 H9LR2nYLJL4q; Mon, 22 Feb 2016 00:54:12 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA8B1B2B32; Mon, 22 Feb 2016 00:54:12 -0800 (PST) Received: from 238.28.198.146.dyn.plus.net ([146.198.28.238]:60114 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aXmFu-0008GS-0W; Mon, 22 Feb 2016 08:54:10 +0000 To: John Leslie References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> From: Bob Briscoe Message-ID: <56CACCB1.2080502@bobbriscoe.net> Date: Mon, 22 Feb 2016 08:54:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160219182359.GA74531@verdi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: tcpm IETF list , tsvwg IETF list , tsv-ads@ietf.org, TCP Prague List , "De Schepper, Koen \(Koen\)" , AQM IETF list Subject: Re: [tcpm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 22 Feb 2016 08:54:16 -0000 John, On 19/02/16 18:23, John Leslie wrote: > Bob Briscoe wrote: >> I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers. >> >> We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S, >> DualQ and solutions to the TCP Prague Requirements. > This feels like it belongs as a non-WG-forming formal BoF. > > It describes work spanning at least three WGs; and could benefit from > formal scheduling to avoid conflicts with those WGs and others. > > OTOH, it really isn't to the point where a WG charter can reasonably > be drafted. First we must decide whether the work _can_ be split among > existing WGs. > > However this may turn out, I wish to participate remotely. OK, we'll see if the secretariat can help us with that. Unfortunately we ran out of time for the formal BoF deadline on Friday. Bob > > -- > John Leslie > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Feb 22 09:21:34 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD2B1ACF19; Mon, 22 Feb 2016 09:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 adofOQvtrqQY; Mon, 22 Feb 2016 09:21:25 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 3F68B1A8796; Mon, 22 Feb 2016 09:21:25 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id u200so124504136ywf.0; Mon, 22 Feb 2016 09:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bHev+2W9a4ZjGp3R/8N28gupmZwanuXHCSwd0Hr0Kow=; b=QNWBbxUYD+769XYgmsT2Vj8DZkxf39GXopOKdgQ4PIkSWVRHHpsyodbqDaGpCd+liP /YRN9VYKe9lohGgN6oQCc0aQtaFcql1xDRcgI6PDbILwxQfXRW3vX7GLTuFuXzEqBQIP jzRPy8wOtU3ap5Z+MCj73WJmlKo8zHf35O/WJtyYIyLMdmZmAwEE1hXyodRPdWuV4J9k krfRG+u5WAB3PXhirxjBkM4pYGY9n78dH94ZbVc39JqhtYjcfN/7utlYtB37JrwEi9gq ks9IgczgfGNHdzRUfsN5tpIaqoohW8W3G++NscE0jG8iwQjXUkJrYV4YH7hQRBpjZuho ukKg== 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:date :message-id:subject:from:to:cc:content-type; bh=bHev+2W9a4ZjGp3R/8N28gupmZwanuXHCSwd0Hr0Kow=; b=S9mQDtHXdeRMbijQvAFQrtn3Vd1yBs22gG7V9SW3pSSyVux8CaYMZZTJi8X5HXxnxO fdOUETrkTf602KodKnRSFpvI9UgEAagKP4E89okyS4lQUqOIAONb8c8jmyJOue0Abwv1 cYYUTSfnk7V4cf9a//wdLLhHxm796FWzjrBNEhVIyRiVTxCRxYHNEKQJmc5aN0wsXK/k IOjWAlkS0AJ1A2CGBs9rznIpujQ+9mQb1E8bRtjHHp5wR98EvfnvGR9Yp4N/r2f+ggsh DduXNubavxzZcORvly865G5r/0ZugP/M3jcXhzyrSOh5WudkN+iSPfXMPWk8aSCj1MYI PsUQ== X-Gm-Message-State: AG10YOTUqpNfTF2g6QCEbxUSXgEWUmQ7sBY/bX0gDCmyvXxIoHPu4npfVjKsKkMFdxKHQO+4txuPS/s+/+6g9w== MIME-Version: 1.0 X-Received: by 10.13.210.7 with SMTP id u7mr14225566ywd.100.1456161684492; Mon, 22 Feb 2016 09:21:24 -0800 (PST) Received: by 10.37.99.65 with HTTP; Mon, 22 Feb 2016 09:21:24 -0800 (PST) In-Reply-To: <56CACCB1.2080502@bobbriscoe.net> References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> Date: Mon, 22 Feb 2016 11:21:24 -0600 Message-ID: From: Spencer Dawkins at IETF To: Bob Briscoe Content-Type: multipart/alternative; boundary=001a114e7e78f0aa6b052c5f0fd5 Archived-At: Cc: tcpm IETF list , tsvwg IETF list , TCP Prague List , "tsv-ads@ietf.org" , AQM IETF list , "De Schepper, Koen \(Koen\)" Subject: Re: [tcpm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 22 Feb 2016 17:21:29 -0000 --001a114e7e78f0aa6b052c5f0fd5 Content-Type: text/plain; charset=UTF-8 Just to try to be helpful ... On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe wrote: > John, > > On 19/02/16 18:23, John Leslie wrote: > >> Bob Briscoe wrote: >> >>> I'm cross-posting 'cos this impacts 3 IETF WGs and interested >>> implementers. >>> >>> We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S, >>> DualQ and solutions to the TCP Prague Requirements. >>> >> This feels like it belongs as a non-WG-forming formal BoF. >> >> It describes work spanning at least three WGs; and could benefit from >> formal scheduling to avoid conflicts with those WGs and others. >> >> OTOH, it really isn't to the point where a WG charter can reasonably >> be drafted. First we must decide whether the work _can_ be split among >> existing WGs. >> >> However this may turn out, I wish to participate remotely. >> > OK, we'll see if the secretariat can help us with that. > I believe that happens at http://www.ietf.org/meeting/amreq.html. If you put "TSV" in as "type of meeting", your happy TSV ADs would see the request. Thanks, Spencer > Unfortunately we ran out of time for the formal BoF deadline on Friday. > > > Bob > > >> -- >> John Leslie >> >> _______________________________________________ >> tcpPrague mailing list >> tcpPrague@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpprague >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --001a114e7e78f0aa6b052c5f0fd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to try to be helpful ...
On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <= span dir=3D"ltr"><ietf@bobbriscoe.net> wrote:
John,

On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe <ie= tf@bobbriscoe.net> wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs and interested imple= menters.

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
=C2=A0 =C2=A0 This feels like it belongs as a non-WG-forming formal BoF.
=C2=A0 =C2=A0 It describes work spanning at least three WGs; and could bene= fit from
formal scheduling to avoid conflicts with those WGs and others.

=C2=A0 =C2=A0 OTOH, it really isn't to the point where a WG charter can= reasonably
be drafted. First we must decide whether the work _can_ be split among
existing WGs.

=C2=A0 =C2=A0 However this may turn out, I wish to participate remotely.
OK, we'll see if the secretariat can help us with that.

I believe that happens at=C2=A0http://www.ietf.org/meeting/amreq.html. If = you put "TSV" in as "type of meeting", your happy TSV A= Ds would see the request.

Thanks,

Spencer
=C2=A0
Unfortunately we ran out of time for the formal BoF deadline on Friday.


Bob


--
John Leslie <john@jlc.= net>

_______________________________________________
tcpPrague mailing list
tcpPrague@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/tcpprague

--
________________________________________________________________
Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/


--001a114e7e78f0aa6b052c5f0fd5-- From nobody Wed Feb 24 08:53:11 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 EE2F91B35E8; Tue, 23 Feb 2016 08:30:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160223163003.24350.12485.idtracker@ietfa.amsl.com> Date: Tue, 23 Feb 2016 08:30:03 -0800 Archived-At: X-Mailman-Approved-At: Wed, 24 Feb 2016 08:53:10 -0800 Cc: mls.ietf@gmail.com, tcpm@ietf.org, smccammon@amsl.com, tcpm-chairs@ietf.org Subject: [tcpm] tcpm - Cancelling a meeting request for IETF 95 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 16:30:04 -0000 A request to cancel a meeting session has just been submitted by . From nobody Thu Feb 25 03:10:54 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FB71A00AE; Thu, 25 Feb 2016 03:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 smdXeMgQaHWP; Thu, 25 Feb 2016 03:10:49 -0800 (PST) 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 F23B21A0056; Thu, 25 Feb 2016 03:10:48 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DF100FC860681; Thu, 25 Feb 2016 11:10:44 +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 u1PBAkDW023511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Feb 2016 11:10:47 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 u1PBAT4T001200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Feb 2016 12:10:46 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.15]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 25 Feb 2016 12:10:39 +0100 From: "Scharf, Michael (Nokia - DE)" To: "tcpm@ietf.org" Thread-Topic: tcpm - Cancelling a meeting request for IETF 95 Thread-Index: AQHRbld9IyaIVbJ8DUaAiwFGvUghZp88mvZA Date: Thu, 25 Feb 2016 11:10:38 +0000 Message-ID: <655C07320163294895BBADA28372AF5D486C554E@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20160223163003.24350.12485.idtracker@ietfa.amsl.com> In-Reply-To: <20160223163003.24350.12485.idtracker@ietfa.amsl.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.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm-chairs@ietf.org" Subject: Re: [tcpm] tcpm - Cancelling a meeting request for IETF 95 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 11:10:52 -0000 SW4gY2FzZSBzb21lYm9keSB3b25kZXJzOiAiLiIgPT0gIk1pY2hhZWwgU2NoYXJmIg0KDQpUaGVy ZSB3YXMgbm8gcmVzcG9uc2UgdG8gbXkgcHJldmlvdXMgZS1tYWlsLiBBcyBhIHJlc3VsdCwgSSBo YXZlIHJlcXVlc3RlZCB0byBjYW5jZWwgdGhlIHBsYW5uZWQgVENQTSBtZWV0aW5nLiBXZSB3aWxs IHNlbmQgdGhlIHN0YXR1cyByZXBvcnQgb2YgdGhlIGNoYWlycyB0byB0aGUgbGlzdCwgcHJpb3Ig dG8gSUVURiA5NS4NCg0KVGhlIGNoYWlycyBwbGFuIHRvIGhhdmUgYWdhaW4gb3VyIHVzdWFsIFRD UE0gbWVldGluZyBkdXJpbmcgSUVURiA5Ni4gVW50aWwgdGhlbiwgd2Ugd291bGQgaGlnaGx5IHdl bGNvbWUgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQpUaGFua3MNCg0KTWljaGFl bA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiSUVURiBNZWV0aW5nIFNl c3Npb24gUmVxdWVzdCBUb29sIiBbbWFpbHRvOnNlc3Npb25fcmVxdWVzdF9kZXZlbG9wZXJzQGll dGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDIzLCAyMDE2IDU6MzAgUE0NClRvOiBz ZXNzaW9uLXJlcXVlc3RAaWV0Zi5vcmcNCkNjOiBtbHMuaWV0ZkBnbWFpbC5jb207IHRjcG1AaWV0 Zi5vcmc7IHNtY2NhbW1vbkBhbXNsLmNvbTsgdGNwbS1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6 IHRjcG0gLSBDYW5jZWxsaW5nIGEgbWVldGluZyByZXF1ZXN0IGZvciBJRVRGIDk1DQoNCg0KDQpB IHJlcXVlc3QgdG8gY2FuY2VsIGEgbWVldGluZyBzZXNzaW9uIGhhcyBqdXN0IGJlZW4gc3VibWl0 dGVkIGJ5IC4NCg0K From nobody Mon Feb 29 05:57:56 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 C1B501B317E; Mon, 29 Feb 2016 05:57:54 -0800 (PST) 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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160229135754.18399.55407.idtracker@ietfa.amsl.com> Date: Mon, 29 Feb 2016 05:57:54 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 13:57:54 -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 Considerations Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-01.txt Pages : 7 Date : 2016-02-29 Abstract: Each implementation of a retransmission timeout mechanism must balance correctness and timeliness and therefore no implementation suits all situations. This document provides high-level guidance for retransmission timeout schemes appropriate for general use in the Internet. Within the guidelines, 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-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-01 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 Mon Feb 29 06:00:59 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EC21B3197 for ; Mon, 29 Feb 2016 06:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 FYEASv6Fq33e for ; Mon, 29 Feb 2016 06:00:54 -0800 (PST) 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 793811B3198 for ; Mon, 29 Feb 2016 06:00:54 -0800 (PST) Received: from lawyers.icir.org (obrien.ICSI.Berkeley.EDU [192.150.187.23]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id u1TE0rST017831; Mon, 29 Feb 2016 06:00:53 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E185F3AE968A; Mon, 29 Feb 2016 09:00:52 -0500 (EST) To: "Scharf\, Michael \(Nokia - DE\)" From: Mark Allman In-Reply-To: <655C07320163294895BBADA28372AF5D4862C817@FR712WXCHMBA15.zeu.alcatel-lucent.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Eight Days a Week X-URL-0: http://www.icir.org/mallman-files/Document38645.jpg X-URL-1: http://www.icir.org/mallman-files/Document85688.docx X-URL-2: http://www.icir.org/mallman-files/Document12114.html X-URL-3: http://www.icir.org/mallman-files/Document62887.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 29 Feb 2016 09:00:52 -0500 Message-ID: <63373.1456754452@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] FW: I-D Action: draft-ietf-tcpm-rto-consider-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 14:00:56 -0000 --=-------459435943823349593450 Content-Type: text/plain > To me, the sentence on page 5 "In such a case a congestion control > action is not required." does not really cover an undo of > congestion control actions once a non-congestion event is > detected. But this may really be nitpicking... I just submitted a new version (-01) that includes a tweaked version of the text referenced above. I have received no other comments and so this is the only change between -00 and -01. Please advise on next steps. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlbUTxQACgkQWyrrWs4yIs7WYQCgiWhLLuz2zSYu/fTDolsplX7E c2cAn10uxfQc2r2vozaEvxoWcc2xqyKi =a0Dj -----END PGP SIGNATURE----- --=-------459435943823349593450--