From nobody Mon Jan 4 07:31:18 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 B490B1A8998; Mon, 4 Jan 2016 07:31:13 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160104153113.24270.90403.idtracker@ietfa.amsl.com> Date: Mon, 04 Jan 2016 07:31:13 -0800 Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-undeployed@ietf.org, mls.ietf@gmail.com, draft-ietf-tcpm-undeployed@tools.ietf.org, tcpm-chairs@ietf.org Subject: [tcpm] Last Call: (Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.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, 04 Jan 2016 15:31:13 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-01-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document reclassifies several TCP extensions and TCP-related documents that have either been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status. The affected RFCs are RFC 675, RFC 721, RFC 761, RFC 813, RFC 816, RFC 879, RFC 896, RFC 1078, and RFC 6013. Additionally, this document reclassifies RFC 700, RFC 794, RFC 814, RFC 817, RFC 872, RFC 889, RFC 964, and RFC 1071 to "Informational" status. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jan 5 08:04:00 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 AE7DD1A90ED; Mon, 4 Jan 2016 12:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 SZVsMI_qtX3o; Mon, 4 Jan 2016 12:54:01 -0800 (PST) Received: from omr1.cc.vt.edu (omr1.cc.ipv6.vt.edu [IPv6:2607:b400:92:8300:0:c6:2117:b0e]) (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 4C7391A92E2; Mon, 4 Jan 2016 12:54:01 -0800 (PST) Received: from mr3.cc.vt.edu (mr3.cc.ipv6.vt.edu [IPv6:2001:468:c80:2105:0:2b9:e1ff:8be3]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id u04KrwMW031379; Mon, 4 Jan 2016 15:53:58 -0500 Received: from auth1.smtp.vt.edu (auth1.smtp.vt.edu [198.82.161.152] (may be forged)) by mr3.cc.vt.edu (8.14.4/8.14.4) with ESMTP id u04KrrTr014935; Mon, 4 Jan 2016 15:53:58 -0500 Received: from turing-police.cc.vt.edu ([IPv6:2601:5c0:c100:993:8865:3f55:42ca:22cd]) (authenticated bits=0) by auth1.smtp.vt.edu (8.14.4/8.14.4) with ESMTP id u04KroiK014103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2016 15:53:51 -0500 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6+dev To: ietf@ietf.org From: Valdis.Kletnieks@vt.edu In-Reply-To: <20160104153113.24270.90403.idtracker@ietfa.amsl.com> References: <20160104153113.24270.90403.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1451940830_81471P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 04 Jan 2016 15:53:50 -0500 Message-ID: <95406.1451940830@turing-police.cc.vt.edu> Archived-At: X-Mailman-Approved-At: Tue, 05 Jan 2016 08:03:59 -0800 Cc: tcpm@ietf.org, draft-ietf-tcpm-undeployed@ietf.org, mls.ietf@gmail.com, draft-ietf-tcpm-undeployed@tools.ietf.org, IETF-Announce , tcpm-chairs@ietf.org Subject: Re: [tcpm] Last Call: (Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status) to Informational RFC 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, 04 Jan 2016 20:54:02 -0000 --==_Exmh_1451940830_81471P Content-Type: text/plain; charset=us-ascii On Mon, 04 Jan 2016 07:31:13 -0800, The IESG said: > > The IESG has received a request from the TCP Maintenance and Minor > Extensions WG (tcpm) to consider the following document: > - 'Moving Outdated TCP Extensions and TCP-related Documents to Historic > and Informational Status' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2016-01-18. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. The draft says in section 2.1: o [RFC1078] U, "TCP Port Service Multiplexer (TCPMUX)" should be deprecated, because: .... * There are no known client-side deployments. SGI's Data Migration Facility does in fact use tcpmux on port 1 for client systems to contact the DMF server for out-of-band administrative functions. However, this usage is (as far as I know, after been the admin of a DMF system for 5 years) strictly confined to intercommunication between the clients and server of a DMF cluster, and I know of no other vendors or packages that try to talk to DMF over tcpmux (everything uses the SGI-provided DMF client tools to do the heavy lifting, and then operates on the output of the tool). Whether that should be sufficient to deter moving RFC1078 to deprecated is a question for somebody else to answer. --==_Exmh_1451940830_81471P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Exmh version 2.5 07/13/2001 iQIVAwUBVorb3gdmEQWDXROgAQKzPw//TcQydttbniLd40RzmfPeyI3+gm3X7oqx NR+c2IvGhJQY0kL819lqGARYixRJvI1Syu0TCEKoGZeaU/fJkwEZxJ0nE7XlkcOm CLJfgMVU2w5TGl2Mc4M4ISUQ+B8KOP6qBzePa4mqKUtuEzvEloahkHkqhtAZrwpq pBVYTpL403hc2+rAUaVEq1iwriQYwWfYA8Gf+JQvZAlREg2vIFhvvTQ6YQ7unEcH n3j4Vff02cnVkt24sFtWX6yIxIAtkT4Rq01DIjQ12mcfzo9+t24JiABx7jH8fGxA t6xKgEQqO5lqok5K8GfvjNWqbvxn4vi8K+zDrUEuR7avLCdSO4LG0YWfCMbfBdVp 0nRQ0aEDUnasWJ2z4mxWySVQ/I5er4n1JkzDEoHw4Ml/T0u1IAhrb5I2fm5/E1PO rXa7rh9nP/vGFzx5jFiLp6NBsGgE84oyjff/TTrrVN5nOJVu3nLd18ZFCL0i9cvo rtpf3pKwKPGaWuozAkZRHpmLc7Iilh83zLeynW+AqTiRf5jeaFzprWWAv8FHQ9ni lwkcla3rH1z/awtOwSE5bnOw/V6HeUgR2ksBAWLsI8Icabek9l1w8Oxzt4vpsKow 81Ep4GpdOSC+FrcWttqps4fvgyUVX6XT44Jd/zMC/EnI/2pGmZzm8nhYBzSGq10R TqMswWyk79g= =D+aA -----END PGP SIGNATURE----- --==_Exmh_1451940830_81471P-- From nobody Tue Jan 5 08:04:02 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 08A891B2D4E; Tue, 5 Jan 2016 04:40:58 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] 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 gTxEvjRrW7gY; Tue, 5 Jan 2016 04:40:55 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE8E1B2D47; Tue, 5 Jan 2016 04:40:53 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aGQuv-0000CuC; Tue, 5 Jan 2016 13:40:49 +0100 Message-Id: To: ietf@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com In-reply-to: Your message of "Mon, 04 Jan 2016 15:53:50 -0500 ." <95406.1451940830@turing-police.cc.vt.edu> Date: Tue, 05 Jan 2016 13:40:38 +0100 Archived-At: X-Mailman-Approved-At: Tue, 05 Jan 2016 08:03:59 -0800 Cc: tcpm@ietf.org, Valdis.Kletnieks@vt.edu, draft-ietf-tcpm-undeployed@ietf.org, mls.ietf@gmail.com, draft-ietf-tcpm-undeployed@tools.ietf.org, IETF-Announce , tcpm-chairs@ietf.org Subject: Re: [tcpm] Last Call: (Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status) to Informational RFC 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: Tue, 05 Jan 2016 12:40:58 -0000 In your letter dated Mon, 04 Jan 2016 15:53:50 -0500 you wrote: >The draft says in section 2.1: > > o [RFC1078] U, "TCP Port Service Multiplexer (TCPMUX)" should be > deprecated, because: >.... > * There are no known client-side deployments. Just for reference. I use TCPMUX for a private protocol. It is nice for prototyping because it is easier pick a unique string for a protocol than to pick un unused port. (Obviously, when DNS is used, SRV can also be used for this) The second argument is a weird. * It requires all new connections to be received on a single port, which limits the number of connections between two machines." There are many systems that receive essentially all of their traffic over one port. So those system already have this problem. It also is very rare that a single host connects to a remote host more than 16000 times in parallel. So I wonder if this is a practical limitation. From nobody Tue Jan 5 16:51:57 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 5EBAC1A0367; Tue, 5 Jan 2016 16:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 oEhreTt1_FDs; Tue, 5 Jan 2016 16:51:42 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC8C1A0387; Tue, 5 Jan 2016 16:51:42 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u060p95u021196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Jan 2016 16:51:09 -0800 (PST) To: Valdis.Kletnieks@vt.edu, ietf@ietf.org References: <20160104153113.24270.90403.idtracker@ietfa.amsl.com> <95406.1451940830@turing-police.cc.vt.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <568C64FD.4060501@isi.edu> Date: Tue, 5 Jan 2016 16:51:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <95406.1451940830@turing-police.cc.vt.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tcpm@ietf.org, touch@isi.edu, draft-ietf-tcpm-undeployed@ietf.org, mls.ietf@gmail.com, draft-ietf-tcpm-undeployed@tools.ietf.org, IETF-Announce , tcpm-chairs@ietf.org Subject: Re: [tcpm] Last Call: (Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status) to Informational RFC 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, 06 Jan 2016 00:51:49 -0000 On 1/4/2016 12:53 PM, Valdis.Kletnieks@vt.edu wrote: > On Mon, 04 Jan 2016 07:31:13 -0800, The IESG said: >> >> The IESG has received a request from the TCP Maintenance and Minor >> Extensions WG (tcpm) to consider the following document: >> - 'Moving Outdated TCP Extensions and TCP-related Documents to Historic >> and Informational Status' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2016-01-18. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. > > The draft says in section 2.1: > > o [RFC1078] U, "TCP Port Service Multiplexer (TCPMUX)" should be > deprecated, because: > .... > * There are no known client-side deployments. > > SGI's Data Migration Facility does in fact use tcpmux on port 1 for client > systems to contact the DMF server for out-of-band administrative functions. > However, this usage is (as far as I know, after been the admin of a DMF system > for 5 years) strictly confined to intercommunication between the clients and > server of a DMF cluster, and I know of no other vendors or packages that > try to talk to DMF over tcpmux (everything uses the SGI-provided DMF client > tools to do the heavy lifting, and then operates on the output of the tool). > > Whether that should be sufficient to deter moving RFC1078 to deprecated is a > question for somebody else to answer. This sounds like an opportunity for SGI to shift over to DNS-SD. We can change the line about "no known" to "only one known". We could refer to DNS-SD going to PS as a rationale for obsoleting TCPMUX if necessary, IMO. Joe From nobody Tue Jan 5 18:22:35 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 636EA1A8988; Tue, 5 Jan 2016 18:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 7V8K5F0W9PEH; Tue, 5 Jan 2016 18:22:33 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F26C1A8987; Tue, 5 Jan 2016 18:22:33 -0800 (PST) Received: from [192.168.1.28] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u062MAdA024797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jan 2016 18:22:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (13C75) In-Reply-To: <69547.1452045223@turing-police.cc.vt.edu> Date: Tue, 5 Jan 2016 18:22:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <31909C28-7651-41F2-A161-3ECEA767C308@isi.edu> References: <20160104153113.24270.90403.idtracker@ietfa.amsl.com> <95406.1451940830@turing-police.cc.vt.edu> <568C64FD.4060501@isi.edu> <69547.1452045223@turing-police.cc.vt.edu> To: Valdis.Kletnieks@vt.edu X-MailScanner-ID: u062MAdA024797 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tcpm@ietf.org, ietf@ietf.org, draft-ietf-tcpm-undeployed@ietf.org, mls.ietf@gmail.com, draft-ietf-tcpm-undeployed@tools.ietf.org, IETF-Announce , tcpm-chairs@ietf.org Subject: Re: [tcpm] Last Call: (Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status) to Informational RFC 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, 06 Jan 2016 02:22:34 -0000 > On Jan 5, 2016, at 5:53 PM, Valdis.Kletnieks@vt.edu wrote: >=20 > On Tue, 05 Jan 2016 16:51:09 -0800, Joe Touch said: >=20 >> This sounds like an opportunity for SGI to shift over to DNS-SD. >>=20 >> We can change the line about "no known" to "only one known". We could >> refer to DNS-SD going to PS as a rationale for obsoleting TCPMUX if >> necessary, IMO. >=20 > Not a really good fit. In general, you already *know* the hostname that > has the service - it's the host you have the NFS mount from, or the curren= t > CXFS metadata server if you're inside the cluster. And trying to use DNS-S= D > for two logically distinct DMF archives is just *looking* for trouble. You can use DNS-SD to just find the port number given s known hostname.=20 The simplest alternative to that is to get an assigned (user) port number.=20= > It would be a much better fit for portmapper actually (although that would= > involve leaving a daemon running to answer/forward queries - probably not a= s > big an issue today as it was when they started coding DMF almost 25 years a= go). The forwarding is why import mapper might not be a good fit. Joe= From nobody Wed Jan 6 03:09:40 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 033F01A8934; Tue, 5 Jan 2016 17:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ogLZ2Sk3JD9M; Tue, 5 Jan 2016 17:53:51 -0800 (PST) Received: from omr2.cc.vt.edu (omr2.cc.ipv6.vt.edu [IPv6:2607:b400:92:8400:0:33:fb76:806e]) (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 9FD811A8932; Tue, 5 Jan 2016 17:53:51 -0800 (PST) Received: from mr3.cc.vt.edu (mr3.cc.ipv6.vt.edu [IPv6:2001:468:c80:2105:0:2b9:e1ff:8be3]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id u061rn62013598; Tue, 5 Jan 2016 20:53:49 -0500 Received: from auth1.smtp.vt.edu (auth1.smtp.vt.edu [198.82.161.152] (may be forged)) by mr3.cc.vt.edu (8.14.4/8.14.4) with ESMTP id u061riYp002672; Tue, 5 Jan 2016 20:53:49 -0500 Received: from turing-police.cc.vt.edu (turing-police.cc.ipv6.vt.edu [IPv6:2001:468:c80:2103:f21f:afff:fe0c:8ada]) (authenticated bits=0) by auth1.smtp.vt.edu (8.14.4/8.14.4) with ESMTP id u061rhVc005447 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2016 20:53:43 -0500 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6+dev To: Joe Touch From: Valdis.Kletnieks@vt.edu In-Reply-To: <568C64FD.4060501@isi.edu> References: <20160104153113.24270.90403.idtracker@ietfa.amsl.com> <95406.1451940830@turing-police.cc.vt.edu> <568C64FD.4060501@isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1452045223_20072P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 05 Jan 2016 20:53:43 -0500 Message-ID: <69547.1452045223@turing-police.cc.vt.edu> Archived-At: X-Mailman-Approved-At: Wed, 06 Jan 2016 03:09:39 -0800 Cc: tcpm@ietf.org, ietf@ietf.org, draft-ietf-tcpm-undeployed@ietf.org, mls.ietf@gmail.com, draft-ietf-tcpm-undeployed@tools.ietf.org, IETF-Announce , tcpm-chairs@ietf.org Subject: Re: [tcpm] Last Call: (Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status) to Informational RFC 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, 06 Jan 2016 01:53:53 -0000 --==_Exmh_1452045223_20072P Content-Type: text/plain; charset=us-ascii On Tue, 05 Jan 2016 16:51:09 -0800, Joe Touch said: > This sounds like an opportunity for SGI to shift over to DNS-SD. > > We can change the line about "no known" to "only one known". We could > refer to DNS-SD going to PS as a rationale for obsoleting TCPMUX if > necessary, IMO. Not a really good fit. In general, you already *know* the hostname that has the service - it's the host you have the NFS mount from, or the current CXFS metadata server if you're inside the cluster. And trying to use DNS-SD for two logically distinct DMF archives is just *looking* for trouble. It would be a much better fit for portmapper actually (although that would involve leaving a daemon running to answer/forward queries - probably not as big an issue today as it was when they started coding DMF almost 25 years ago). --==_Exmh_1452045223_20072P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Exmh version 2.5 07/13/2001 iQIVAwUBVoxzpwdmEQWDXROgAQKHlhAAtH08Ts1x6+8BsSygbgobe7nP3BAIkc/t eU7auOPxczpbGOHasgVN6dLunp+UVAa/FVIR4+G2eCWO00I4aKOlxsAN1dmJTMJU xwjAculkH/qyUtIaFEbbu+KboGe7aftRCwvduDl0OBCt+P7pdrnZIDNgRMETjn+L lsLcZ4R8fc+9KlCgTfe2bA4rqiJchV5mHKDqAexozyjjdDiS6KU0KuPYobdR0HUp WLeA8qVPYe060W4CmFmQpoStc+TeSLkh1r3JZaRGfXbgCwjLmbxtRrVsX7rSvR61 kAQlXyF3k9rGWTDVSIROMwYS5/mm/KsIGf4eqENVBGn5lKazTp4ZrGnwgRprRMGo snCOLgFR2X2mf77m4Fah/Y8Hvr1CkR1nzNUxBRvRMvvA+3WCo7hyz+GtacwLpigb oCfrMD1sV8AIE5Vfg2frTP/NrnUJNIEgwMaQiXzd0u+f0fTWsCmOpiGcX4TprmB4 KJEVdF1cOOI+iuShnVu0/iodfmglW/KnYtrlK0ZKUhjGvu/LjBWB6+qAs3WdfhCN DIHvmNjWYXrT7jNqY7Ilwp037rb72kAK+lWrz9k4h6l6FW/1e5rtvQIYPPrfA5ea kELc+/8ln+Ism9M9eQo6h0wOXrvH/5h9MwploecsnxujI/6pAbmgMPLEOrDMYNxR bZpY2cKc8yQ= =TL56 -----END PGP SIGNATURE----- --==_Exmh_1452045223_20072P-- From nobody Wed Jan 6 05:37: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 239A71B2B97 for ; Wed, 6 Jan 2016 05:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 IqUHDS5nmL8x for ; Wed, 6 Jan 2016 05:37:08 -0800 (PST) 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 11B841B2B8F for ; Wed, 6 Jan 2016 05:36:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 87B1AD9309; Wed, 6 Jan 2016 14:36:38 +0100 (MET) 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 iaosF0BGszW2; Wed, 6 Jan 2016 14:36:38 +0100 (MET) Received: from [192.168.12.218] (wlan.dagstuhl.de [192.76.146.51]) (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 21466D9307; Wed, 6 Jan 2016 14:36:38 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <74276882340acbc536309a983310cb6c@mail.gmail.com> Date: Wed, 6 Jan 2016 14:36:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2A662320-6C97-44C3-B801-28CBD1376612@tik.ee.ethz.ch> References: <72616.1448386988@lawyers.icir.org> <74276882340acbc536309a983310cb6c@mail.gmail.com> To: mallman@icir.org X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tcpm IETF list Subject: Re: [tcpm] removing TCP's initial window 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, 06 Jan 2016 13:37:13 -0000 Hi, there is actually nothing in an RFC that forbids to use a larger window. = RFC3390 even says: "This increased initial window is optional: a TCP MAY start with a larger initial window.=E2=80=9C Mirja > Am 02.12.2015 um 13:34 schrieb Karen Elisabeth Egede Nielsen = : >=20 > Hi, >=20 > Agree to do this also for SCTP. >=20 > Even more so I would like "the after idle case" to be covered as well = AND > I really like what > was written in one of the previous postings in this thread: >=20 >=20 >>> In the vein of giving an inch and they will ask to take a mile, if >>> such a paced, large IW is OK for the start of a connection, would it >>> also be OK for "slow start after idle?" Or perhaps the lesser of = that >>> IW and cwnd when the connection went idle. >=20 >> Perhaps. The difference is that in this case the host has *some* = notion > of the path it is traversing. But, at some point that notion is so = dated > that indeed treating it like a brand new connection from a >CC = standpoint > seems OK to me. But, there are probably more considerations here than = at > the start of a connection. >=20 >> allman >=20 >=20 > This sounds as if we finally could get to handle the after idle = situation, > which is a significant issue for > semi static long living connections/associations and critical for the > re-usability of a path in multi-path situations. > AND here I would like to see "refresh" of ssthresh come into the = picture > as well as the IW it self. >=20 > E.g., in the unfortunate case where the CWND/flightsize of the = connection > was low when the timeout occurred, then > the set SSthresh would block slow start when traffic resumes after > idleness. >=20 > All of this fist very nicely with our thoughts for RFC4960bis ! >=20 > BR, Karen >=20 >=20 >=20 >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Michael Tuexen >> Sent: 25. november 2015 20:59 >> To: mallman@icir.org >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] removing TCP's initial window >>=20 >>> On 24 Nov 2015, at 18:43, Mark Allman wrote: >>>=20 >>>=20 >>> A proposal for allowing end hosts to set their initial cwnd to >>> whatever they want ... in the canonical form that we use to propose >>> such things ... >> Hi Marc, >>=20 >> I really like and support this document. Wouldn't is make sense >> not to restrict this document to TCP, but also cover SCTP? >>=20 >> Best regards >> Michael >>>=20 >>> draft-allman-tcpm-no-initwin-00.txt >>>=20 >>> allman >>>=20 >>>=20 >>> -- >>> http://www.icir.org/mallman/ >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jan 6 05:49:12 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 6CA0D1B2BAF for ; Wed, 6 Jan 2016 05:49:11 -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_20=-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 1Ewxbc-Fb249 for ; Wed, 6 Jan 2016 05:49:10 -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 812951B2BAE for ; Wed, 6 Jan 2016 05:49:10 -0800 (PST) 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 u06Dn9H0004818; Wed, 6 Jan 2016 05:49:09 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E086936788C2; Wed, 6 Jan 2016 08:49:08 -0500 (EST) To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= From: Mark Allman In-Reply-To: <2A662320-6C97-44C3-B801-28CBD1376612@tik.ee.ethz.ch> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jailhouse Rock X-URL-0: http://www.icir.org/mallman-files/Document66064.docx X-URL-1: http://www.icir.org/mallman-files/Document67507.html X-URL-2: http://www.icir.org/mallman-files/Document58234.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Jan 2016 08:49:08 -0500 Message-ID: <61475.1452088148@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm IETF list Subject: Re: [tcpm] removing TCP's initial window 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: Wed, 06 Jan 2016 13:49:11 -0000 --=-------459435943823349593450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > there is actually nothing in an RFC that forbids to use a larger > window. RFC3390 even says:=20 >=20 > "This increased initial window is optional: a TCP MAY start with a > larger initial window.=E2=80=9C I think that "larger" is supposed to be "smaller". I.e., the intent of the document (and the WG) was not to allow the use of arbitrarily large initial cwnds. (Note: I now suggest it is likely fine to use arbitrary initial cwnds, but that should be conflated with the intent when we wrote RFC 2414/3390.) allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaNG1IACgkQWyrrWs4yIs40uwCfUUTq0cvbyI9mMDh5qr+iA2GE fBUAmwSmRBuKwQ9l4oC9VdxXJ/veX5J/ =n2at -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Jan 6 06:03:02 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 4DBCA1B2BE3 for ; Wed, 6 Jan 2016 06:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 g5yENGflkgUo for ; Wed, 6 Jan 2016 06:03:00 -0800 (PST) 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 3F8301B2BDF for ; Wed, 6 Jan 2016 06:02:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7131ED9309; Wed, 6 Jan 2016 15:02:58 +0100 (MET) 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 8u94VC+Y-3Ye; Wed, 6 Jan 2016 15:02:58 +0100 (MET) Received: from [192.168.12.218] (wlan.dagstuhl.de [192.76.146.51]) (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 2AE6CD9307; Wed, 6 Jan 2016 15:02:58 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <61475.1452088148@lawyers.icir.org> Date: Wed, 6 Jan 2016 15:02:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C2BAC36-0012-40C9-B450-138BDF54EB66@tik.ee.ethz.ch> References: <61475.1452088148@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tcpm IETF list Subject: Re: [tcpm] removing TCP's initial window 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, 06 Jan 2016 14:03:02 -0000 No, there is no normative language that forbids to use a larger window. = An IW of 3 or 10 is effectively just recommended and what=E2=80=99s = considered to be safe by the IETF. I think we still need to give a recommendation here and especially if = you have a large transmission that anyway will take several RTTs (or = even minutes) to be transmitted, I don=E2=80=99t see an advantage in a = larger window. I would find it very dangerous to not give any recommendation here, = because there are cases in the wild already where you see huge IWs which = do cause burst loss. The part that I support is that we give a recommendation that if you use = a larger window than 10, you must be aware that there is a larger risk = of burst loss and that pacing might be a potentially solution for it. = (Not sure if =E2=80=9AMUST use pacing if the IW is larger than 10=E2=80=98= is the right thing to say=E2=80=A6. I guess at least this probably is a = =E2=80=9ASHOULD=E2=80=98). Another recommendation is that if you see = burst loss in your IW, it's likely that you=E2=80=99ve hid the limit of = your own access link buffer and that this might give you an indication = how to set your IW in future for this link (namely IW_old - = num_of_losses) Mirja > Am 06.01.2016 um 14:49 schrieb Mark Allman : >=20 >=20 >> there is actually nothing in an RFC that forbids to use a larger >> window. RFC3390 even says:=20 >>=20 >> "This increased initial window is optional: a TCP MAY start with a >> larger initial window.=E2=80=9C >=20 > I think that "larger" is supposed to be "smaller". I.e., the intent > of the document (and the WG) was not to allow the use of arbitrarily > large initial cwnds. >=20 > (Note: I now suggest it is likely fine to use arbitrary initial > cwnds, but that should be conflated with the intent when we wrote > RFC 2414/3390.) >=20 > allman >=20 >=20 >=20 From nobody Wed Jan 6 06:29:31 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 BDB4C1B2C1B for ; Wed, 6 Jan 2016 06:29:29 -0800 (PST) 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 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 1yIs499NK4Ik for ; Wed, 6 Jan 2016 06:29:28 -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 A4BC81B2C18 for ; Wed, 6 Jan 2016 06:29:28 -0800 (PST) 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 u06ETQBw008048; Wed, 6 Jan 2016 06:29:27 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9FB913679515; Wed, 6 Jan 2016 09:29:26 -0500 (EST) To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= From: Mark Allman In-Reply-To: <2C2BAC36-0012-40C9-B450-138BDF54EB66@tik.ee.ethz.ch> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jailhouse Rock X-URL-0: http://www.icir.org/mallman-files/Document20261.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Jan 2016 09:29:26 -0500 Message-ID: <68563.1452090566@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm IETF list Subject: Re: [tcpm] removing TCP's initial window 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: Wed, 06 Jan 2016 14:29:29 -0000 --=-------459435943823349593450 Content-Type: text/plain I believe you are completely mis-interpreting the situation. You are hanging your hat on a mistake. > No, there is no normative language that forbids to use a larger > window. Not true. The most recent standards track document to specify the initial window is RFC 5681 (a Draft Standard) that says: IW, the initial value of cwnd, MUST be set using the following guidelines as an upper bound. If SMSS > 2190 bytes: IW = 2 * SMSS bytes and MUST NOT be more than 2 segments If (SMSS > 1095 bytes) and (SMSS <= 2190 bytes): IW = 3 * SMSS bytes and MUST NOT be more than 3 segments if SMSS <= 1095 bytes: IW = 4 * SMSS bytes and MUST NOT be more than 4 segments As specified in [RFC3390], the SYN/ACK and the acknowledgment of the SYN/ACK MUST NOT increase the size of the congestion window. Further, if the SYN or SYN/ACK is lost, the initial window used by a sender after a correctly transmitted SYN MUST be one segment consisting of at most SMSS bytes. That is a bunch of normative language that precisely sets the limits of the initial cwnd. RFC 6928 is an experimental RFC that says TCPs can use 10 segment initial windows. In fact, the second sentence of the RFC says: "This increase is optional: a TCP MAY start with an initial window that is smaller than 10 segments." I.e., they got it right where we botched it. That doesn't mean all TCP implementations follow the specifications. Or, even that they all should. As with lots of things there may well be fine reasons to not follow the spec (e.g., certain LAN communication). But, to frame the standards as merely a recommendation and not a constraint is IMHO a completely wrong reading of the documents and history. A perfectly fine and reasonable position to take/discuss would be whether we should move to a model where we give an precise initial cwnd value and *explicitly* say it is a recommendation and hence allow folks to use whatever they want and be within the spec. But, thinking that is the state of the current spec is simply wrong. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaNJMYACgkQWyrrWs4yIs6/MQCeIFuEOYbJc6RYDI0BEw8McsEr YeoAn3WaTP+74nFTDb8wPz6PEVMH1xHj =chtu -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Jan 6 07:59: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 B4F241B2C1D for ; Wed, 6 Jan 2016 07:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 3czEul8R6KaX for ; Wed, 6 Jan 2016 07:59:56 -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 483581B2BFB for ; Wed, 6 Jan 2016 07:59:56 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 75071F54B863D; Wed, 6 Jan 2016 15:59:51 +0000 (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 u06FxqkY018224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Jan 2016 16:59:52 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.114]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 6 Jan 2016 16:59:52 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org Extensions" Thread-Topic: WG acceptance of draft-allman-tcpm-rto-consider? Thread-Index: AdFIm0YGlNQidzZBSMqztionwyeJmQ== Date: Wed, 6 Jan 2016 15:59:51 +0000 Message-ID: <655C07320163294895BBADA28372AF5D485B4E20@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.38] 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] WG acceptance of draft-allman-tcpm-rto-consider? 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, 06 Jan 2016 15:59:57 -0000 Hi all, This e-mail starts a TCPM WG acceptance call for draft-allman-tcpm-rto-cons= ider, which will run until Friday Jan. 22, 2016. The proposal is to add a new TCPM charter milestone May 2016 Submit document on Retransmission Timeout Considerations as Best= Current Practice RFC ... and use the document draft-allman-tcpm-rto-consider-03 as a starting po= int. As the document is relatively short, the expectation is that this docu= ment could be submitted to IESG relatively fast after the next IETF meeting= . WG acceptance in TCPM requires strong community support. Please reply to th= is e-mail if you support a WG adoption in TCPM. If you have any concerns or= objections, please also let us know. Thanks Michael From nobody Wed Jan 6 08:12:52 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 8B5A11A87D2 for ; Wed, 6 Jan 2016 08:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] 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 SWyd9qsQl20Z for ; Wed, 6 Jan 2016 08:12:49 -0800 (PST) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (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 6CB871A8A08 for ; Wed, 6 Jan 2016 08:12:49 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id AF0B6417B6; Wed, 6 Jan 2016 17:12:47 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id vXp122iZLU67; Wed, 6 Jan 2016 17:12:46 +0100 (CET) Date: Wed, 6 Jan 2016 17:12:45 +0100 From: Hagen Paul Pfeifer To: Mark Allman Message-ID: <20160106161245.GA31403@virgo.local> References: <72616.1448386988@lawyers.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72616.1448386988@lawyers.icir.org> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] removing TCP's initial window 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, 06 Jan 2016 16:12:51 -0000 * Mark Allman | 2015-11-24 12:43:08 [-0500]: > draft-allman-tcpm-no-initwin-00.txt Hey Mark, regarding 1. (2): For initial windows of more than 10 segments, the initial window of segments MUST be paced evenly across the first round-trip time (as measured during the 3WHS). For our setups with a bandwidth of ~3000byte/sec pacing will not work as expceted: Measured RTT will be roughly 0.033 sec (because of small, non-MTU sized SYN/ACK packets). Pacing n (e.g. IW 50) full MTU sized packets will lead to massive packet drop (for ~3000byte/sec pipes it is still a burst). Just to much data in the pipe. Subsequently it will lead to congested (nearly standing) forwarding queue which results in TCP timeouts because the control loop is defacto broken. Give it a try: take mininet or whatver you prefer, configure a low bandwidth and increase the IW. Hagen From nobody Wed Jan 6 08:16:24 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 60DC31B2C61 for ; Wed, 6 Jan 2016 08:16:23 -0800 (PST) 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 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 FDu4GcyCDQSn for ; Wed, 6 Jan 2016 08:16:22 -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 4EF721B2B5A for ; Wed, 6 Jan 2016 08:16:22 -0800 (PST) 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 u06GGKL5018103; Wed, 6 Jan 2016 08:16:20 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 49217367C274; Wed, 6 Jan 2016 11:16:20 -0500 (EST) To: Hagen Paul Pfeifer From: Mark Allman In-Reply-To: <20160106161245.GA31403@virgo.local> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jailhouse Rock X-URL-0: http://www.icir.org/mallman-files/Document11215.jpg X-URL-1: http://www.icir.org/mallman-files/Document47289.doc MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Jan 2016 11:16:20 -0500 Message-ID: <87187.1452096980@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] removing TCP's initial window 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: Wed, 06 Jan 2016 16:16:23 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > * Mark Allman | 2015-11-24 12:43:08 [-0500]: >=20 > > draft-allman-tcpm-no-initwin-00.txt >=20 > Hey Mark, regarding 1. (2): >=20 > For initial windows of more than 10 segments, the initial > window of segments MUST be paced evenly across the first > round-trip time (as measured during the 3WHS). >=20 >=20 > For our setups with a bandwidth of ~3000byte/sec pacing will not work > as expceted: >=20 > Measured RTT will be roughly 0.033 sec (because of small, non-MTU > sized SYN/ACK packets). Pacing n (e.g. IW 50) full MTU sized > packets will lead to massive packet drop (for ~3000byte/sec pipes > it is still a burst). Just to much data in the pipe. Subsequently > it will lead to congested (nearly standing) forwarding queue which > results in TCP timeouts because the control loop is defacto > broken. >=20 > Give it a try: take mininet or whatver you prefer, configure a low > bandwidth and increase the IW. Of course. So, why would you do that? allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaNPdMACgkQWyrrWs4yIs5Q5QCeKEujn1pmZM3zF/icG8XHSngF 0m4AniKjDAUdM+X6j8SMO4Ulx8WwRJu6 =pGBB -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Jan 6 09:05:31 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 774D11B2DFE for ; Wed, 6 Jan 2016 09:05:29 -0800 (PST) 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 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 LVjGfH00zUMi for ; Wed, 6 Jan 2016 09:05:27 -0800 (PST) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (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 062D41B2DF7 for ; Wed, 6 Jan 2016 09:05:26 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 306AC417B6; Wed, 6 Jan 2016 18:05:24 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id Ikf3WlDPlli4; Wed, 6 Jan 2016 18:05:23 +0100 (CET) Date: Wed, 6 Jan 2016 18:05:22 +0100 From: Hagen Paul Pfeifer To: Mark Allman Message-ID: <20160106170522.GB31403@virgo.local> References: <20160106161245.GA31403@virgo.local> <87187.1452096980@lawyers.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87187.1452096980@lawyers.icir.org> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] removing TCP's initial window 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, 06 Jan 2016 17:05:29 -0000 * Mark Allman | 2016-01-06 11:16:20 [-0500]: >> Give it a try: take mininet or whatver you prefer, configure a low >> bandwidth and increase the IW. > >Of course. So, why would you do that? Just to get a sensitive feeling about increased IW in an low bandwidth environment. A environment where TCP is used as well. At the lower end of low bandwidth environments a pacing based on the min-mtu-sized packet RTT (SYN/ACK) will differ from the full-mtu-sized RTT (DATA). Hagen From nobody Wed Jan 6 09:12: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 779091B2E06 for ; Wed, 6 Jan 2016 09:12:15 -0800 (PST) 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 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 B-7Hf_kkKlvq for ; Wed, 6 Jan 2016 09:12:14 -0800 (PST) Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1671B2E05 for ; Wed, 6 Jan 2016 09:12:14 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 5F85D4153F; Wed, 6 Jan 2016 18:12:12 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id TZHF6BIDlpkX; Wed, 6 Jan 2016 18:12:11 +0100 (CET) Date: Wed, 6 Jan 2016 18:12:10 +0100 From: Hagen Paul Pfeifer To: Mark Allman Message-ID: <20160106171210.GC31403@virgo.local> References: <20160106161245.GA31403@virgo.local> <87187.1452096980@lawyers.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87187.1452096980@lawyers.icir.org> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] removing TCP's initial window 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, 06 Jan 2016 17:12:15 -0000 * Mark Allman | 2016-01-06 11:16:20 [-0500]: >> Give it a try: take mininet or whatver you prefer, configure a low >> bandwidth and increase the IW. > >Of course. So, why would you do that? One note: you will see that at a given bandwidth (i.e. 3000byte/sec) you will encounter TCP timeouts if you raise IW to a certain level. "Somewhere" there is a correlation between bandwidth and absorbable IW. The lower the bandwidth the higher the risk that an increased IW has an negative effect on connection stability. Hagen From nobody Wed Jan 6 10:21:12 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 64F2E1A0092 for ; Wed, 6 Jan 2016 10:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 SgRgYel6mFWI for ; Wed, 6 Jan 2016 10:21:09 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 100B11A0091 for ; Wed, 6 Jan 2016 10:21:09 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aGshn-0002Ix-6V; Wed, 06 Jan 2016 19:21:07 +0100 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.101]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aGshm-0000LU-HE; Wed, 06 Jan 2016 19:21:07 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <655C07320163294895BBADA28372AF5D485B4E20@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Wed, 6 Jan 2016 19:21:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <655C07320163294895BBADA28372AF5D485B4E20@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 36844 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AA5ABC45331CC5326823AEEA73EE3D2D71A66F5D X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org Extensions" Subject: Re: [tcpm] WG acceptance of draft-allman-tcpm-rto-consider? 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, 06 Jan 2016 18:21:11 -0000 I do support WG adoption. Cheers, Michael > On 6. jan. 2016, at 16.59, Scharf, Michael (Michael) = wrote: >=20 > Hi all, >=20 > This e-mail starts a TCPM WG acceptance call for = draft-allman-tcpm-rto-consider, which will run until Friday Jan. 22, = 2016. >=20 > The proposal is to add a new TCPM charter milestone >=20 > May 2016 Submit document on Retransmission Timeout Considerations as = Best Current Practice RFC >=20 > ... and use the document draft-allman-tcpm-rto-consider-03 as a = starting point. As the document is relatively short, the expectation is = that this document could be submitted to IESG relatively fast after the = next IETF meeting. >=20 > WG acceptance in TCPM requires strong community support. Please reply = to this e-mail if you support a WG adoption in TCPM. If you have any = concerns or objections, please also let us know. >=20 > Thanks >=20 > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jan 6 10:32:36 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 621491A00B0 for ; Wed, 6 Jan 2016 10:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 sJ7T80QKO96V for ; Wed, 6 Jan 2016 10:32:33 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5AD1A00AE for ; Wed, 6 Jan 2016 10:32:33 -0800 (PST) Received: from [10.0.1.109] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7A4821C0B462F; Wed, 6 Jan 2016 19:32:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Michael Tuexen In-Reply-To: <655C07320163294895BBADA28372AF5D485B4E20@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Wed, 6 Jan 2016 19:32:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4102E160-0537-49C8-A833-BBB239647931@lurchi.franken.de> References: <655C07320163294895BBADA28372AF5D485B4E20@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tcpm-chairs@tools.ietf.org tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] WG acceptance of draft-allman-tcpm-rto-consider? 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, 06 Jan 2016 18:32:35 -0000 > On 06 Jan 2016, at 16:59, Scharf, Michael (Michael) = wrote: >=20 > Hi all, >=20 > This e-mail starts a TCPM WG acceptance call for = draft-allman-tcpm-rto-consider, which will run until Friday Jan. 22, = 2016. >=20 > The proposal is to add a new TCPM charter milestone >=20 > May 2016 Submit document on Retransmission Timeout Considerations as = Best Current Practice RFC >=20 > ... and use the document draft-allman-tcpm-rto-consider-03 as a = starting point. As the document is relatively short, the expectation is = that this document could be submitted to IESG relatively fast after the = next IETF meeting. >=20 > WG acceptance in TCPM requires strong community support. Please reply = to this e-mail if you support a WG adoption in TCPM. If you have any = concerns or objections, please also let us know. I do support WG acceptance. Best regards Michael >=20 > Thanks >=20 > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From nobody Wed Jan 6 10:57:00 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 42B7F1A00E4 for ; Wed, 6 Jan 2016 10:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ZzPw_xwp0R9T for ; Wed, 6 Jan 2016 10:56:57 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA211A0011 for ; Wed, 6 Jan 2016 10:56:57 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u06ItxG3027854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Jan 2016 10:55:59 -0800 (PST) To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , mallman@icir.org References: <72616.1448386988@lawyers.icir.org> <74276882340acbc536309a983310cb6c@mail.gmail.com> <2A662320-6C97-44C3-B801-28CBD1376612@tik.ee.ethz.ch> From: Joe Touch Message-ID: <568D633F.3050404@isi.edu> Date: Wed, 6 Jan 2016 10:55:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <2A662320-6C97-44C3-B801-28CBD1376612@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tcpm IETF list , touch@isi.edu Subject: Re: [tcpm] removing TCP's initial window 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, 06 Jan 2016 18:56:59 -0000 FWIW, I submitted an errata on this. It's clearly an error. JOe On 1/6/2016 5:36 AM, Mirja Kühlewind wrote: > Hi, > > there is actually nothing in an RFC that forbids to use a larger window. RFC3390 even says: > > "This increased initial window is optional: a TCP MAY start with a > larger initial window.“ > > Mirja > > >> Am 02.12.2015 um 13:34 schrieb Karen Elisabeth Egede Nielsen : >> >> Hi, >> >> Agree to do this also for SCTP. >> >> Even more so I would like "the after idle case" to be covered as well AND >> I really like what >> was written in one of the previous postings in this thread: >> >> >>>> In the vein of giving an inch and they will ask to take a mile, if >>>> such a paced, large IW is OK for the start of a connection, would it >>>> also be OK for "slow start after idle?" Or perhaps the lesser of that >>>> IW and cwnd when the connection went idle. >> >>> Perhaps. The difference is that in this case the host has *some* notion >> of the path it is traversing. But, at some point that notion is so dated >> that indeed treating it like a brand new connection from a >CC standpoint >> seems OK to me. But, there are probably more considerations here than at >> the start of a connection. >> >>> allman >> >> >> This sounds as if we finally could get to handle the after idle situation, >> which is a significant issue for >> semi static long living connections/associations and critical for the >> re-usability of a path in multi-path situations. >> AND here I would like to see "refresh" of ssthresh come into the picture >> as well as the IW it self. >> >> E.g., in the unfortunate case where the CWND/flightsize of the connection >> was low when the timeout occurred, then >> the set SSthresh would block slow start when traffic resumes after >> idleness. >> >> All of this fist very nicely with our thoughts for RFC4960bis ! >> >> BR, Karen >> >> >> >>> -----Original Message----- >>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Michael Tuexen >>> Sent: 25. november 2015 20:59 >>> To: mallman@icir.org >>> Cc: tcpm@ietf.org >>> Subject: Re: [tcpm] removing TCP's initial window >>> >>>> On 24 Nov 2015, at 18:43, Mark Allman wrote: >>>> >>>> >>>> A proposal for allowing end hosts to set their initial cwnd to >>>> whatever they want ... in the canonical form that we use to propose >>>> such things ... >>> Hi Marc, >>> >>> I really like and support this document. Wouldn't is make sense >>> not to restrict this document to TCP, but also cover SCTP? >>> >>> Best regards >>> Michael >>>> >>>> draft-allman-tcpm-no-initwin-00.txt >>>> >>>> allman >>>> >>>> >>>> -- >>>> http://www.icir.org/mallman/ >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Jan 6 11:05: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 578BF1A00FA for ; Wed, 6 Jan 2016 11:05:15 -0800 (PST) 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 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 RCnJkJYcTeTU for ; Wed, 6 Jan 2016 11:05:14 -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 724911A00F6 for ; Wed, 6 Jan 2016 11:05:14 -0800 (PST) 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 u06J5DIf007027; Wed, 6 Jan 2016 11:05:13 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5F1BD368015E; Wed, 6 Jan 2016 14:05:12 -0500 (EST) To: Hagen Paul Pfeifer From: Mark Allman In-Reply-To: <20160106171210.GC31403@virgo.local> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jailhouse Rock MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Jan 2016 14:05:12 -0500 Message-ID: <15017.1452107112@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] removing TCP's initial window 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: Wed, 06 Jan 2016 19:05:15 -0000 --=-------459435943823349593450 Content-Type: text/plain > One note: you will see that at a given bandwidth > (i.e. 3000byte/sec) you will encounter TCP timeouts if you raise > IW to a certain level. "Somewhere" there is a correlation between > bandwidth and absorbable IW. The lower the bandwidth the higher > the risk that an increased IW has an negative effect on connection > stability. Of course. This is all well known stuff. You could, for instance, look at RFC 2416. I think there is a general appreciation for the impact of the IW in excessively low bandwidth environments. And, your bringing this up underscores the basic reason why I think no-initwin is the way to go: there is not any sort of one-size-fits- all IW we can use. Rather than pretending there is, we should get out of the business of picking one answer and let implementations handle this particular detail in a prudent fashion. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaNZWUACgkQWyrrWs4yIs7Z3gCgggvu8LCCWnaK0S6JVfrFcpld DKcAnAobODocfbFLi47Tedns2bw3ho8D =4RNn -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Jan 6 11:13: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 560851A010B for ; Wed, 6 Jan 2016 11:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 RuQK0wsOyBj4 for ; Wed, 6 Jan 2016 11:13:14 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCC01A0108 for ; Wed, 6 Jan 2016 11:13:14 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u06JCnam001272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Jan 2016 11:12:52 -0800 (PST) To: mallman@icir.org, Hagen Paul Pfeifer References: <15017.1452107112@lawyers.icir.org> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <568D6731.9030102@isi.edu> Date: Wed, 6 Jan 2016 11:12:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <15017.1452107112@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tcpm@ietf.org, touch@isi.edu Subject: Re: [tcpm] removing TCP's initial window 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, 06 Jan 2016 19:13:19 -0000 On 1/6/2016 11:05 AM, Mark Allman wrote: > >> One note: you will see that at a given bandwidth >> (i.e. 3000byte/sec) you will encounter TCP timeouts if you raise >> IW to a certain level. "Somewhere" there is a correlation between >> bandwidth and absorbable IW. The lower the bandwidth the higher >> the risk that an increased IW has an negative effect on connection >> stability. > > Of course. This is all well known stuff. You could, for instance, > look at RFC 2416. I think there is a general appreciation for the > impact of the IW in excessively low bandwidth environments. > > And, your bringing this up underscores the basic reason why I think > no-initwin is the way to go: there is not any sort of one-size-fits- > all IW we can use. Rather than pretending there is, we should get > out of the business of picking one answer and let implementations > handle this particular detail in a prudent fashion. Well, I can see two reasons not to do that: 1. tragedy of the commons There were a few companies that played that card in the late 90's as I recall, and we see it happening now with bigger players doing what's better for their bottom line, not necessarily for the Internet as a whole. 2. implementers don't know who their TCPs will be talking to (now or in the future) It's always been permissible to change any of TCP's parameters in closed environments. The key question is whether it's safe to ignore the broader impacts of widescale deployment of this recommendation. I still don't think it is - IMO, the recommendation needs to come with a feedback mechanism that prevents persistent use of window sizes that could affect others badly (e.g., auto-iw). Joe From nobody Wed Jan 6 11:24:07 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 EB6361A012F for ; Wed, 6 Jan 2016 11:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 s1BxYURzGFiR for ; Wed, 6 Jan 2016 11:24:04 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 4C7E21A0120 for ; Wed, 6 Jan 2016 11:24:04 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id l65so70956493wmf.1 for ; Wed, 06 Jan 2016 11:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KPKc25vd+z83hGo7I19TjTJH4mvl1w4g20ro4CbqK/0=; b=F9W/XSyi1u4MHGbJJNYgvVENI88d4XxN/qulbzlzsbWMR2yWPJKHJXOKzyyCxSIicC ETZ/9estf7FBXWRQICq71sz0WWbydBJuvVxdyZ7/RJfitZCZ+c/8PFQej/beNKzrcAe0 e5Jot+SUKmqNIFFEbuAZHmofFgnycSAJneBOP9SStIYjeywL430I4EjLlartT9grgquX RRHiOCOdPQJ4HU51iwpPaOMPciBYiDyy4UAfOwFSoSr2wDbX6I0p4H00LF5NbYrvCdGx txvDt00r6NVrSeytcIDTi9A3q4E9tnP5JVwUiPhAUshrJRHFy10zSYTd/Zs4J2hBFk7z 0YqQ== 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-type; bh=KPKc25vd+z83hGo7I19TjTJH4mvl1w4g20ro4CbqK/0=; b=Q3o4PfYb9mcoZC6Mg/MyoZZsTk2mtSuUE3VmnxGxQnkycitwLKNKVK4k2To0ulWgK/ HVqUapooNMrs5YDnrSw86lvs5c6q1rsFDnioPIq0jNacRg1ioyaBAfw8v5Ig+bqGj0Kl byzb1kBew1LUvcp1s8lLCJckY16bhlel+jhhTjslKLGtkdZPYdllHjc7B6K1eOgUYb7V rxnQArSgYbXpoUyejizvxwjgcyvk7vHtLRuYpTjk8r+YcbEdvekjw0ug4CD9gwoNDbGW zCkLbJdYkpDbjGy5EIq8bIblrk25fMIW8rQ2Ixi0aRnAVZ6Fx6tlqU4LdiOlkSUOJwgw m3Dg== X-Gm-Message-State: ALoCoQmgBj3Uv9MoVwnMknMIp6sNPmqgKFKMrQHpn7CPyZ7BQs6AXMZekwEpw3jZc6CNx4JcjNwuG3bMOJwzActMMLapYg/D8tcJoWWYkaYr998b0fUP2RM= X-Received: by 10.194.175.198 with SMTP id cc6mr2201828wjc.24.1452108242834; Wed, 06 Jan 2016 11:24:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.184.196 with HTTP; Wed, 6 Jan 2016 11:23:23 -0800 (PST) In-Reply-To: <568D6731.9030102@isi.edu> References: <15017.1452107112@lawyers.icir.org> <568D6731.9030102@isi.edu> From: Yuchung Cheng Date: Wed, 6 Jan 2016 11:23:23 -0800 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org Extensions" , "mallman@icir.org" Subject: Re: [tcpm] removing TCP's initial window 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, 06 Jan 2016 19:24:06 -0000 On Wed, Jan 6, 2016 at 11:12 AM, Joe Touch wrote: > > > On 1/6/2016 11:05 AM, Mark Allman wrote: >> >>> One note: you will see that at a given bandwidth >>> (i.e. 3000byte/sec) you will encounter TCP timeouts if you raise >>> IW to a certain level. "Somewhere" there is a correlation between >>> bandwidth and absorbable IW. The lower the bandwidth the higher >>> the risk that an increased IW has an negative effect on connection >>> stability. >> >> Of course. This is all well known stuff. You could, for instance, >> look at RFC 2416. I think there is a general appreciation for the >> impact of the IW in excessively low bandwidth environments. >> >> And, your bringing this up underscores the basic reason why I think >> no-initwin is the way to go: there is not any sort of one-size-fits- >> all IW we can use. Rather than pretending there is, we should get >> out of the business of picking one answer and let implementations >> handle this particular detail in a prudent fashion. so perhaps having some guideline on this would be useful since people always want to and have already up IW to 100+ (no kidding). > > Well, I can see two reasons not to do that: > > 1. tragedy of the commons > There were a few companies that played that card in the > late 90's as I recall, and we see it happening now with > bigger players doing what's better for their bottom line, > not necessarily for the Internet as a whole. > > 2. implementers don't know who their TCPs will be talking to (now or in > the future) > > It's always been permissible to change any of TCP's parameters in closed > environments. The key question is whether it's safe to ignore the > broader impacts of widescale deployment of this recommendation. I still > don't think it is - IMO, the recommendation needs to come with a > feedback mechanism that prevents persistent use of window sizes that > could affect others badly (e.g., auto-iw). +1 > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jan 6 13:39:31 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 D94A21A1A67 for ; Wed, 6 Jan 2016 13:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 fuuQyMAgN8JU for ; Wed, 6 Jan 2016 13:39:28 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB891A1A69 for ; Wed, 6 Jan 2016 13:39:27 -0800 (PST) Received: from BN3PR0501MB1345.namprd05.prod.outlook.com (10.160.183.22) by BN3PR0501MB1347.namprd05.prod.outlook.com (10.160.183.24) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 6 Jan 2016 21:39:24 +0000 Received: from BN3PR0501MB1345.namprd05.prod.outlook.com ([10.160.183.22]) by BN3PR0501MB1345.namprd05.prod.outlook.com ([10.160.183.22]) with mapi id 15.01.0361.006; Wed, 6 Jan 2016 21:39:24 +0000 From: Jonathan Looney To: "Scharf, Michael (Michael)" , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] WG acceptance of draft-allman-tcpm-rto-consider? Thread-Index: AQHRSMq1lNQidzZBSMqztionwyeJmQ== Date: Wed, 6 Jan 2016 21:39:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 authentication-results: spf=none (sender IP is ) smtp.mailfrom=jlooney@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1347; 5:ML7VpPaO5MrhMiQIo1bqrZ/dkm/MZ/+jvU3uObRUc7lHqyNnRh3uEh9qhOKzsGAHowKvo39MeCy7ztyl5LPsTNEIC66F1t0TRhspsApHYCTuDb8nV5llCEUg/JReZ9tfZE6FBQUEf4+0BDOU5UB6bw==; 24:VClnpTfR1fN8Xo30PKuO4RNbj+elHqbrsLZAx5jo0A9aWasnV3Dv1uuELw41ROG+RjdPRApQcGvx0lBBKM0j292W3eusm+Gtr7X3lRVNCDc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1347; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61489475475257); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BN3PR0501MB1347; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1347; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(53754006)(24454002)(377454003)(479174004)(54356999)(1220700001)(230783001)(50986999)(105586002)(106116001)(66066001)(5001770100001)(92566002)(5001960100002)(1096002)(83506001)(19580405001)(101416001)(2906002)(102836003)(586003)(106356001)(4001350100001)(5004730100002)(77096005)(558084003)(19580395003)(11100500001)(86362001)(122556002)(189998001)(3846002)(2900100001)(99286002)(40100003)(10400500002)(4326007)(87936001)(5002640100001)(5008740100001)(6116002)(81156007)(36756003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1347; H:BN3PR0501MB1345.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <3637C3806F6A9D42A010EDA6C5A0C4B1@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2016 21:39:24.3216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1347 Archived-At: Cc: "tcpm-chairs@tools.ietf.org tcpm-chairs@tools.ietf.org" Subject: Re: [tcpm] WG acceptance of draft-allman-tcpm-rto-consider? 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, 06 Jan 2016 21:39:30 -0000 On 1/6/16, 10:59 AM, "tcpm on behalf of Scharf, Michael (Michael)" wrote: >Hi all, > >This e-mail starts a TCPM WG acceptance call for >draft-allman-tcpm-rto-consider, which will run until Friday Jan. 22, 2016. I support WG adoption. Jonathan From nobody Thu Jan 7 01:12:19 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 646381A87C3 for ; Thu, 7 Jan 2016 01:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 SWaIIkzw_gS3 for ; Thu, 7 Jan 2016 01:12:10 -0800 (PST) Received: from thsbbfxrt01p.thalesgroup.com (thsbbfxrt01p.thalesgroup.com [192.54.144.131]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E447C1A87F2 for ; Thu, 7 Jan 2016 01:12:09 -0800 (PST) Received: from thsbbfxrt01p.thalesgroup.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3pbhf010h7zRM; Thu, 7 Jan 2016 10:12:08 +0100 (CET) X-Thales-IRT1: IRT11 From: SALLANTIN Renaud To: 'Yuchung Cheng' , Joe Touch Date: Thu, 7 Jan 2016 10:12:04 +0100 Thread-Topic: [tcpm] removing TCP's initial window Thread-Index: AdFIt9LDljFZ7Li/SPuRZtYX3YuczQAbWSSQ Message-ID: References: <15017.1452107112@lawyers.icir.org> <568D6731.9030102@isi.edu> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" , "mallman@icir.org" Subject: Re: [tcpm] removing TCP's initial window 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, 07 Jan 2016 09:12:12 -0000 [@@ THALES ALENIA SPACE INTERNAL @@] -----Message d'origine----- De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yuchung Cheng Envoy=E9=A0: mercredi 6 janvier 2016 20:23 =C0=A0: Joe Touch Cc=A0: tcpm@ietf.org Extensions; mallman@icir.org Objet=A0: Re: [tcpm] removing TCP's initial window >On Wed, Jan 6, 2016 at 11:12 AM, Joe Touch wrote: >> >> >> On 1/6/2016 11:05 AM, Mark Allman wrote: >> >>>> One note: you will see that at a given bandwidth (i.e. 3000byte/sec)=20 >>>> you will encounter TCP timeouts if you raise IW to a certain level.=20 >>>>"Somewhere" there is a correlation between bandwidth and absorbable=20 >>>> IW. The lower the bandwidth the higher the risk that an increased IW=20 >>>> has an negative effect on connection stability. >>> >>>Of course. This is all well known stuff. You could, for instance,=20 >>> look at RFC 2416. I think there is a general appreciation for the=20 >>>impact of the IW in excessively low bandwidth environments. >>> >>> And, your bringing this up underscores the basic reason why I think=20 >>> no-initwin is the way to go: there is not any sort of one-size-fits-=20 >>> all IW we can use. Rather than pretending there is, we should get=20 >>> out of the business of picking one answer and let implementations=20 >>> handle this particular detail in a prudent fashion. so perhaps having some guideline on this would be useful since people alway= s want to and have already up IW to 100+ (no kidding). >> >> Well, I can see two reasons not to do that: >> >>1. tragedy of the commons >> There were a few companies that played that card in the >> late 90's as I recall, and we see it happening now with >> bigger players doing what's better for their bottom line, >> not necessarily for the Internet as a whole. >> >> 2. implementers don't know who their TCPs will be talking to (now or=20 >> in the future) >> >> It's always been permissible to change any of TCP's parameters in=20 >> closed environments. The key question is whether it's safe to ignore=20 >> the broader impacts of widescale deployment of this recommendation. I=20 >> still don't think it is - IMO, the recommendation needs to come with a=20 >> feedback mechanism that prevents persistent use of window sizes that=20 >> could affect others badly (e.g., auto-iw). >+1 +1. A smart auto-IW could indeed limit unsuitable IW and reduce the risk of ne= twork collapse, but also enable some outstanding improvements in some other= cases (such as satellite communication).=20 In fact, our preliminary studies shown that a large IW (higher than 50 seg= ments) "smartly" paced in a large RTT environment (>500ms) improves the ind= ividual performance and has less incidence for the others that an un-paced = IW of 10 segments.=20 > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jan 13 15:59:36 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 D1AC11A21A4 for ; Wed, 13 Jan 2016 15:59:35 -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 mv14Q7QOWUKi for ; Wed, 13 Jan 2016 15:59:34 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 5EF9C1ACEC4 for ; Wed, 13 Jan 2016 15:59:34 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id z14so180752075igp.0 for ; Wed, 13 Jan 2016 15:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=nTy5Ev4kE225L7tLdYKSj/GTVA2NYlSXkcfAa5QkIik=; b=gGUVjdiloOQ47xwfK+IDARNHDa7ht3coUqqSzxEH3M23BzVjOqa/tNhi8jdn+VVSxV HiLgNVHpSiKt+EIq8zU5EKwof0gx3sWnLewZE4aVB+XP8vyh3XMtZeRLvggr/4H7Xoao 1ZhBsdqDbJe7tdOaOfg0+kaReIjDAoLYQW089bzVKQsZpt3RivPiCpfKHFo6vS9HWBzB 9OIQUUTVerC0F9Jdr/ZIL53cEr+SwJOK3QDAP6wDrG36eKU9cHBwPcbsDLCCwyPqYeSj S7RQruE3TVHEbyP4IYrvj0o8BEzaSAsYjQf3iokCIQGmxzc5p0v/XNW8Xn6JxD0LoDaB D7Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=nTy5Ev4kE225L7tLdYKSj/GTVA2NYlSXkcfAa5QkIik=; b=f/qVaLiNRsmiIZJIL5Iifh5EAWseqmlH/tB+Zr5hFvGVYZACpAq1asbx32Wl1w8ktn 7qxnfD7eKSwvl2ZT2JUnTWJu3TvErY0drZtM1yvDGxthdIrNcuQfYID2ISl2lywOU0AT LgG8U0sdzjRLfFppX4vJKIXmHuUoPmxpTirG+QnOmTsy4Xk1vE5mNmLF+ntvUedXt+oZ ORhcOFpUcgKhK09v8LTjR41hZM1CUyJkAuVKwRsSg7qkkNFGHe3Bvyf63dTusTQeaQSq 0BZC3w4fLIFJd3Tj6jIrdvfkLmK4GjqUHyRkRSuuFIrsdfO+qWRPHFLsdkWbkEeCxCbp We9g== X-Gm-Message-State: ALoCoQlI9e7cSN3fEmbkH3mJAkNVJIncaIzG4GvVsFy+e879Kh1jNeCVgAJHe8rsljDWJF6cj8WYpFCB/YzlBc4Z7mbyjIfOdQ== X-Received: by 10.50.156.103 with SMTP id wd7mr27919906igb.5.1452729573747; Wed, 13 Jan 2016 15:59:33 -0800 (PST) Received: from still.local (50-121-215-241.drr03.clbg.wv.frontiernet.net. [50.121.215.241]) by smtp.googlemail.com with ESMTPSA id l10sm8869405igx.18.2016.01.13.15.59.32 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 15:59:32 -0800 (PST) To: tcpm@ietf.org References: <655C07320163294895BBADA28372AF5D485B4E20@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Tim Wicinski Message-ID: Date: Wed, 13 Jan 2016 18:59:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0a2 MIME-Version: 1.0 In-Reply-To: <655C07320163294895BBADA28372AF5D485B4E20@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] WG acceptance of draft-allman-tcpm-rto-consider? 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, 13 Jan 2016 23:59:36 -0000 I support adoption tim On 1/6/16 10:59 AM, Scharf, Michael (Michael) wrote: > Hi all, > > This e-mail starts a TCPM WG acceptance call for draft-allman-tcpm-rto-consider, which will run until Friday Jan. 22, 2016. > > The proposal is to add a new TCPM charter milestone > > May 2016 Submit document on Retransmission Timeout Considerations as Best Current Practice RFC > > ... and use the document draft-allman-tcpm-rto-consider-03 as a starting point. As the document is relatively short, the expectation is that this document could be submitted to IESG relatively fast after the next IETF meeting. > > WG acceptance in TCPM requires strong community support. Please reply to this e-mail if you support a WG adoption in TCPM. If you have any concerns or objections, please also let us know. > > Thanks > > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri Jan 15 08:09:08 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 ACA091B2F8A for ; Fri, 15 Jan 2016 08:09:07 -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 TSEmdg3k4w8T for ; Fri, 15 Jan 2016 08:09:05 -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 1CE701A9231 for ; Fri, 15 Jan 2016 08:09:04 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 9CB33405C9EF8 for ; Fri, 15 Jan 2016 16:09:00 +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 u0FG921S028992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 15 Jan 2016 16:09:03 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 u0FG8h1R016545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Jan 2016 17:09:00 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.114]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 15 Jan 2016 17:08:49 +0100 From: "SCHARF, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: E-mail address change Thread-Index: AdFPrwSaqdV3sjPTRtym9olQvX+KTA== Date: Fri, 15 Jan 2016 16:08:49 +0000 Message-ID: <655C07320163294895BBADA28372AF5D485C51C0@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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] E-mail address change 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, 15 Jan 2016 16:09:07 -0000 You may observe that I have a new official e-mail address: michael.scharf@n= okia.com My old e-mail address should continue to work during a transitional period. Michael From nobody Mon Jan 18 07:19:33 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 921941B3819; Mon, 18 Jan 2016 07:19:31 -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.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160118151931.14475.11613.idtracker@ietfa.amsl.com> Date: Mon, 18 Jan 2016 07:19:31 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-cubic-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, 18 Jan 2016 15:19:31 -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 : CUBIC for Fast Long-Distance Networks Authors : Injong Rhee Lisong Xu Sangtae Ha Alexander Zimmermann Lars Eggert Richard Scheffenegger Filename : draft-ietf-tcpm-cubic-01.txt Pages : 15 Date : 2016-01-18 Abstract: CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase of the current TCP standards to improve scalability and stability under fast and long distance networks. BIC-TCP, a predecessor of CUBIC, has been a default TCP adopted by Linux since year 2005 and has already been deployed globally and in use for several years by the Internet community at large. CUBIC is using a similar window growth function as BIC-TCP and is designed to be less aggressive and fairer to TCP in bandwidth usage than BIC-TCP while maintaining the strengths of BIC- TCP such as stability, window scalability and RTT fairness. Through extensive testing in various Internet scenarios, we believe that CUBIC is safe for deployment and testing in the global Internet. The intent of this document is to provide the protocol specification of CUBIC for a third party implementation and solicit the community feedback through experimentation on the performance of CUBIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-cubic-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-cubic-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 Tue Jan 19 00:28:38 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 243981B2B96 for ; Tue, 19 Jan 2016 00:28:37 -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, RCVD_IN_DNSWL_MED=-2.3] 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 TAHYp2W95rP9 for ; Tue, 19 Jan 2016 00:28:33 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A610F1B2B94 for ; Tue, 19 Jan 2016 00:28:31 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-8e-569df3adb1f3 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 18.40.04914.DA3FD965; Tue, 19 Jan 2016 09:28:29 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.247]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Tue, 19 Jan 2016 09:28:29 +0100 From: Ingemar Johansson S To: Yuchung Cheng Thread-Topic: Questions on draft-cheng-tcpm-rack-00.txt Thread-Index: AdFSkjeBRrPUHWEiQ/C+6rBIK17Z9Q== Date: Tue, 19 Jan 2016 08:28:28 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA4151E377@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.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7k+7az3PDDJ5u0LE41DqTxaLjzl4W i20n5zNZfHl8lc2BxWPBplKPJUt+Mnkceh4UwBzFZZOSmpNZllqkb5fAlfFk2xKWgm3cFQ/3 tTI1ME7g7mLk5JAQMJG4cXclC4QtJnHh3nq2LkYuDiGBw4wSn+61QjlLGCW2fZzNDlLFJmAj sfLQd0YQW0RAVaL1wnYmEJtZYBujxNUl1iC2sICRxMqN35ghaswlzuy5zwRh60lMOHkSzGYB 6t31+S2QzcHBK+Arsfu6KUiYUUBW4v73eywQI8Ulbj2ZzwRxnIDEkj3nmSFsUYmXj/+xQtiK Eh9f7WMEGcMsoCmxfpc+RKuixJTuh2AX8woISpyc+YRlAqPILCRTZyF0zELSMQtJxwJGllWM osWpxcW56UbGeqlFmcnFxfl5enmpJZsYgVFycMtv3R2Mq187HmIU4GBU4uEtyJsbJsSaWFZc mXuIUYKDWUmEd9p7oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeZJnGMCGB9MSS1OzU1ILUIpgs EwenVAOj8rO5//8eizt3VGrPpBv7vKpD3ObOP8GklLnif4xQYqb+wQl/P+441Dd9d6bTopmc U5ye3r/zyFRl/q+Zv8Vnr/ZneqdQXfBb5MIZ5yeBcuZC1l22d03X8DgapWl+7VcXOZ2XGy3t Uesnp9Vn07XciiPuzax/WexrWsPP/gl59S5j86Scln+HlFiKMxINtZiLihMBuVUKMI4CAAA= Archived-At: Cc: Ingemar Johansson S , "tcpm@ietf.org" Subject: [tcpm] Questions on draft-cheng-tcpm-rack-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: Tue, 19 Jan 2016 08:28:37 -0000 SGkgWXVjaHVuZywgTmVhbCArIG90aGVycw0KDQpJIGFtIGN1cnJlbnRseSBsb29raW5nIGludG8g dGhlIGlubmVyIGRldGFpbHMgb2YgUkFDSyBhbmQgaG93IGl0IGNvZXhpc3RzIHdpdGggIG90aGVy IChkdXBhY2sgYmFzZWQpIGxvc3MgaGV1cmlzdGljcy4gDQpBcyBJIHVuZGVyc3RhbmQgdGhlIExp bnV4IDQuNCBjb2RlIGFzIHdlbGwgYXMgeW91ciBjb21tZW50ICJDdXJyZW50bHkgaW1wbGVtZW50 ZWQgdG8gY28tZXhpc3Qgd2l0aCBvdGhlciBEdXBUaHJlc2ggaGV1cmlzdGljcyIgaW4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTQvc2xpZGVzL3NsaWRlcy05NC10Y3BtLTYucGRm ICwgUkFDSyBkb2VzIGN1cnJlbnRseSBub3QgcmVwbGFjZSB0aGUgZHVwYWNrIGhldXJpc3RpY3Mg Py4gDQpUaGlzIHRoZW4gbWVhbnMgdGhhdCBldmVuIHRob3VnaCBSQUNLIHVzZSBhIHJlb193bmQg b2YgMTBtcyBpdCBjYW4gbWVhbiB0aGF0IGZhc3QgcmV0cmFuc21pdHMgYXJlIHRyaWdnZXJlZCBl dmVuIHRob3VnaCB0aGUgcGFja2V0IHJlb3JkZXJpbmcgaXMgbGVzcyB0aGFuIDEwbXMuIElzIG15 IG9ic2VydmF0aW9uIGNvcnJlY3QgPy4NCg0KDQpXaGF0IGlzIHRoZSBpbXBsZW1lbnRhdGlvbiBz dGF0dXMgaW4geW91ciAoR29vZ2xlKSBzZXJ2ZXJzID8sIGlzIGl0IHNvbGVseSBSQUNLIGJhc2Vk ID8NCg0KL0luZ2VtYXINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KSW5nZW1h ciBKb2hhbnNzb24gIE0uU2MuIA0KU2VuaW9yIFJlc2VhcmNoZXINCg0KRXJpY3Nzb24gQUINCldp cmVsZXNzIEFjY2VzcyBOZXR3b3Jrcw0KTGFicmF0b3JpZWdyw6RuZCAxMQ0KOTcxIDI4LCBMdWxl w6UsIFN3ZWRlbg0KUGhvbmUgKzQ2LTEwNzEgNDMwNDINClNNUy9NTVMgKzQ2LTczIDA3OCAzMjg5 DQppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbQ0Kd3d3LmVyaWNzc29uLmNvbQ0KDQri gJxXZSBjYW4gYmUgaGVyb2VzLA0KICBqdXN0IGZvciBvbmUgZGF54oCdDQogICAgRGF2aWQgQm93 aWUgDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg== From nobody Tue Jan 19 09:16:54 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 B1E361B32D4; Tue, 19 Jan 2016 09:16:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160119171651.16308.84862.idtracker@ietfa.amsl.com> Date: Tue, 19 Jan 2016 09:16:51 -0800 Archived-At: Cc: draft-ietf-tcpm-undeployed@ietf.org, draft-ietf-tcpm-undeployed@tools.ietf.org, tcpm@ietf.org, tcpm-chairs@ietf.org Subject: [tcpm] Benoit Claise's No Objection on draft-ietf-tcpm-undeployed-03: (with COMMENT) 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, 19 Jan 2016 17:16:51 -0000 Benoit Claise has entered the following ballot position for draft-ietf-tcpm-undeployed-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this clean-up document. The first part of the sentence is obvious, right? For the content of the documents itself, the reader is referred either to the corresponding RFC or, for a brief description, to the TCP Roadmap document [RFC7414]. I guess you want to say something such as: The reader might find brief descriptions of those RFCs in the TCP Roadmap document [RFC7414]. If you keep your sentences: itself -> themselves Editorial OLD: o [RFC0889] U, "Internet Delay Experiments", which which describes experiments with the TCP retransmission timeout calculation NEW: o [RFC0889] U, "Internet Delay Experiments", which describes experiments with the TCP retransmission timeout calculation From nobody Tue Jan 19 13:34:07 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 A1B181B3679 for ; Tue, 19 Jan 2016 13:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 4Yu_ukBmDtVY for ; Tue, 19 Jan 2016 13:34:05 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 2B7791B3677 for ; Tue, 19 Jan 2016 13:34:05 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id 123so109062342wmz.0 for ; Tue, 19 Jan 2016 13:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=d36ZNWuBbe1lmim3lIKWbyoCT9+PoRyEnJjk9Dh6RBg=; b=Zh+/nEMHcP4dYNK5hoAunndAi7p/EC1HPTiv0CD00PfVaDaRW1puC7ROvZcltryBWO 5v5uDd+zkzIhUVkdifYfx51QJ6zIHZBMkXJ5q2QnpGojQCU4IP0qoLbc+n4v+KrUUalX t+l83SnnIa5EgZMJZcIcALw7SPl2C5F845f5zSCyxYy6luGcTObEuaB9IFi41Ohyn69+ 4yZkGj/sZMEIIu0t2k+ETm+BRHykvEyYhMdcd8WRRL6I0MQEaz01LvmWAvMR3X8EK041 lzyHoWDoIhZefrah/9o+rdToZ4dcLOdQXMLhvj+gq3vqagwJW1lxgCOo1FbzV2NteJtZ 1tHw== 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-type:content-transfer-encoding; bh=d36ZNWuBbe1lmim3lIKWbyoCT9+PoRyEnJjk9Dh6RBg=; b=FDbbVY8x094lefH8v8DBjy4PXCqovNw870s0ojxSzJWgZXB89C4j9Qpe13w2yfKoWF +Z7LUFAvDHvi5rnWVEEQZWqpjg42BbVR84E6QzG/vZJqeMFMYPZMWRomzzXnsTriZc7c BtwxjamLUaXayz/2mmtbKOxqEKrbgQOjn2m1mYyxyO5kKTOEvtqKIvNOf1dO5Kr9Qhun dItCgvtaKmFOYCVoUwVamV1B5YwjdDFATOfzIBLuiAPjq1OELgSrXECEV3TJdhAJovj4 z6ZKgqNgL09679EgkX9e9QzP+N/qSd9WbRE7Xqtvsl3t6OqMnSzG7Gc5akWlT5tgNvD8 UsBw== X-Gm-Message-State: AG10YOSaohCbRSypHHcgSbCql76G7YxFg4eQDaTSSd2BIiz0IgVXCwCRqxBvt+/40lRRaI8xwPaB6UwHCJP9IDkZ X-Received: by 10.28.184.76 with SMTP id i73mr157686wmf.43.1453239243714; Tue, 19 Jan 2016 13:34:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.184.196 with HTTP; Tue, 19 Jan 2016 13:33:24 -0800 (PST) In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA4151E377@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA4151E377@ESESSMB205.ericsson.se> From: Yuchung Cheng Date: Tue, 19 Jan 2016 13:33:24 -0800 Message-ID: To: Ingemar Johansson S Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Questions on draft-cheng-tcpm-rack-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: Tue, 19 Jan 2016 21:34:06 -0000 On Tue, Jan 19, 2016 at 12:28 AM, Ingemar Johansson S wrote: > Hi Yuchung, Neal + others > > I am currently looking into the inner details of RACK and how it coexists= with other (dupack based) loss heuristics. > As I understand the Linux 4.4 code as well as your comment "Currently imp= lemented to co-exist with other DupThresh heuristics" in https://www.ietf.o= rg/proceedings/94/slides/slides-94-tcpm-6.pdf , RACK does currently not rep= lace the dupack heuristics ?. > This then means that even though RACK use a reo_wnd of 10ms it can mean t= hat fast retransmits are triggered even though the packet reordering is les= s than 10ms. Is my observation correct ?. That's correct. RACK is currently only used after the recovery starts and does not start the recovery. so your scenario is possible. btw it's one-linear kernel change to enable RACK to start recovery (along with other tricks). I can send you the patch if you are interested. > > What is the implementation status in your (Google) servers ?, is it solel= y RACK based ? It's completely identical to the upstream kernel. No secret sauce ;-) We have RACK-only based implementation but it's not well tested yet. There are two challenges. The first one is design: in a highly reordered and no loss scenario (usually artificially crafted), dynamic dupack threshold beats RACK's reo_wnd. This is b/c dupthresh is near the maximum cwnd that basically turns off fast recovery. obviously it's more effective. the second one is more of implementation: replacing 10 recovery tricks with one has major risk. so the implementation needs to keep the existing code as a emergency backup through sysctl change. that adds significant complexity. but we definitely plan to improve RACK before next meeting :-) > > /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. > Senior Researcher > > Ericsson AB > Wireless Access Networks > Labratoriegr=C3=A4nd 11 > 971 28, Lule=C3=A5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > > =E2=80=9CWe can be heroes, > just for one day=E2=80=9D > 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 From nobody Tue Jan 19 18:14:48 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 2398E1A0143; Tue, 19 Jan 2016 18:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 wGK5dVibOSh7; Tue, 19 Jan 2016 18:14:44 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB291A0141; Tue, 19 Jan 2016 18:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UwTek1opYz4p8uk2o1qpYWqMOsheDp4a0xYlGkW7DQ4=; b=C98cnb2dZ9Sn//mEO9T9E/ypitBF1AOoODjA5Z+KGMI3YVMu7LSEWM8rL+GSz5X5Nru8gUT2kTSTklIjeUHrBRu1p4lmI/NAX6jDeUfp3bR9mjjuINd7SCasxXUUCL6p5EybU1VO7obdagmougX2NuRLqV69rqFIShCp4UFMHco= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [192.168.0.164] (24.242.106.136) by SN1PR08MB1472.namprd08.prod.outlook.com (10.162.2.14) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 02:14:41 +0000 References: <60B5A1AD-6BF7-464D-AEAC-C848FA4CCC03@netapp.com> <655C07320163294895BBADA28372AF5D484D2EA3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <13242_1445862947_t9QCZjWj032356_90A92625-42C7-4B78-B0D6-7DE5805943DB@netapp.com> <562E83A6.8080004@unl.edu> <569097F5.4070804@unl.edu> <24649_1452494742_u0B6jeb5023531_CAO249yeerL2V6q72nyeLT_Awoo-K_wPU_UwjYn99HAbRSRGq8w@mail.gmail.com> <569D01A6.6020300@unl.edu> To: From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <569EED91.8010708@unl.edu> Date: Tue, 19 Jan 2016 20:14:41 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [24.242.106.136] X-ClientProxiedBy: BLUPR0401CA0036.namprd04.prod.outlook.com (25.162.114.174) To SN1PR08MB1472.namprd08.prod.outlook.com (25.162.2.14) X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1472; 2:kut/K0WP+9AOv0LSJpRQb+0O/SX2wvvEobe6n4wJ6sp2q2q1ZTZlzula8ZEapdgxma2Ml9YqLjyztk7s2EybAcxTSBOb6rmBFGpFm+Ig+3CZYo1IahWUFpQE95x2X89QRqCJNOyv8PD3+p8acYQRug==; 3:iz1LC3Zngm/8FxKQEAuUWxHiq5rtiOdNxXTrqbo54hxk0dAryoyGilweQCkvgXfTifzMoxxKw0cZyBhgEtkpsuaXuRct5aGKlO7Aye3OxDCMP+90s/5oZ/HTDeeF4wIj; 25:s0Um13yBZ4mnllBXG9PYrAto/p+TTJBistPrt4OInVMkmQM3NjjtRsJPdX9+llbfWT1DwUtnYUO8N9czndf6WRroAvq3Et7pLlzSu4pbNwiLvMWK+d7kk2IDf7uTcGqmqhUfBxByjaW9s73pztnQFTul3uMKPSHGSrbSuAv6iVsJXf+jx6sAtaBnkteNA2NMlmAog9LegAADcj7KNKdLha62Bw3++szX5OI1UXBarjrom0XZE9Wxbb6SGK00jhh4 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR08MB1472; X-MS-Office365-Filtering-Correlation-Id: 37a46b91-ce40-4439-aebb-08d3213f7561 X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1472; 20:7WTdTZ4Ukf1YQX3heXAnUb2TmN02Njx6cL/08k1RSq1dN43Rxg4g0MVNSaaWJeid37myS+EhJaRpPUz0N2/bcQzA4DjR5kSGs4ZSJ1kpJnFBDb9+vNWnq2ZTCeMQhI7rRa5+muBKkhET8rYvxItJGAEIsVRYDoMXrGarXE6+vhiNwS/r53kdxyvDmuKJy6aeSoJeilVjsFYhwi0nimsweNf2b95RyxRKzkxjwLL0HOhMJ4EtMbzOvNWRG1WaQcvvJPHTYcpJL/kxvxuWr2nRCkJvgMOTcNQwn6e+nRT5J9prvVuzvZqzq5XJz/XiaZIFOLdZvrMGMtCUwvrh0aOp4GcCZqnJkFKjMJyUAQvqn0795UaJzf0zRJa3DzlKnWfGSoRvd73I4Q0wtQIXNZ1N+w7AgHvoVGw9/TMPzzNTH53SnEc0Lfk5XWhLDN6jVtJQkeTdTs2Z+rSVFU3WpZVGGOC253b9kkiqG1HYmN1SMwgRUDtOaYO/ugSTJCxUbhyq; 4:DyYTQ+bJVAp1r15BT7/5bocmlW8VSN7konS1ud36407YZe/D7mUAdN1Her57JklPuWQ0WzOpB57wmJ5egjfJmSQ6dcSMJEY2ffTwQ5oAGz9LolMRowlW5h2057Ce7zhQVOSwNrBUW/IBg0PVVc8kJtvb9UPIgacZpxIvH9cbJR0gtZ+x2Bih+kxTW0sjNTvoWVpKAjKLRc+4ZZ8EqtM5vJM5wRjHzf7WoxAqK/ASEHgLDMFepERAJGCGDLk0qYfjg4HHOPuLW+UPU9FfR+y7O1sAHP6snBobzvMMEY6dQgAbNmJaBaYMV9v9LM3sR7s3KmxHxr2dDFJMf1HTOmpf9KC8IZ3coQnR+Ur24uhhh7QHO4nhigHnzxrcRK0gj5fV X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:SN1PR08MB1472; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1472; X-Forefront-PRVS: 0827D7ACB9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(199003)(189002)(65956001)(65806001)(101416001)(2906002)(64126003)(87976001)(117156001)(47776003)(33656002)(59896002)(66066001)(80316001)(19580395003)(75432002)(93886004)(89122001)(83506001)(229853001)(42186005)(2351001)(97736004)(81156007)(5004730100002)(4001350100001)(40100003)(122386002)(90282001)(23676002)(50466002)(106356001)(65816999)(76176999)(54356999)(87266999)(189998001)(86362001)(110136002)(105586002)(5001960100002)(15975445007)(1096002)(88552002)(36756003)(586003)(3846002)(92566002)(4326007)(77096005)(1720100001)(6116002)(2950100001)(5008740100001)(230700001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1472; H:[192.168.0.164]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA4TUIxNDcyOzIzOjA4SVUrQStyM0pYMlozR0VSQ29oTEpYazJn?= =?utf-8?B?N2x2bExwMjlOT09PV0xzOW9Qb0pYdnBoM3BCQzVyenhiNlNXOXVNVUlXTFRI?= =?utf-8?B?MWJ0TWtVNndFYm5veWlvQ2VPYU95V3A4a1JPcWRUOC9yWnJmd3BjdExSM3ZT?= =?utf-8?B?SlNPYkh0aEt2cDBuUm9WdDJZcE1ZMlFpVCtJNTVBck9iSm9JZGpya0tuaEZp?= =?utf-8?B?QmRHd3h5ZmVCVjdhblNqMzhZUXNIbkpTZVdPNkg1VW8vbTlLOGdVK0tHMjd0?= =?utf-8?B?WmJpdzc3Z3o5bjNrYURaOXFNekFQUjZpM0w5eHdaakMrZkZnYzRKR0JXcit2?= =?utf-8?B?blJRNndnL3VBTm8ybzVseGVLdzQzeFJIa01jZUIyNmRGMFFaVjV0R1pZYWZw?= =?utf-8?B?NDNkbDdDWjhHaUZxaEZlYko4TU45ZS9pWDhHWEdUZ05oSUEyeGRMS2lSR0Vh?= =?utf-8?B?cEt6ZGxrL0dEN3k0cXNiT0hFYzhHMExOMXg4ejh0SjRQNmxEeHp4ZW5kc0pm?= =?utf-8?B?WUh4dTQ3cUpqMVpxU2RkUHFMVmxnd2hEa0k3ZFdLc0llSXBEeHg1QjJtVUZF?= =?utf-8?B?b3NjQW1PeGhxT1NEZ1AzODltdlk5d2Y0STdobHBjOXFoajlXRWpWWnY1SEN2?= =?utf-8?B?bGRsR1pMMXc3RW9wVndVTitOcHBWVDVGRC9BZzdTT1ZxRmR1M1E4SktNZlhY?= =?utf-8?B?V09kcU14NkpiUVoxdFQ1cm4zanR0UFVIdm0ydEk4NnNHZWhnZStRWVRkVFZR?= =?utf-8?B?Uk96RmJzK01JNFllcE5PMnM0aUNycEZPOGxEMjdPMU1pQU1sTXoxb1UveW5K?= =?utf-8?B?U0JpdVNOQWdXck1jOHcxbkJxSmZMbERPOXVoUWdnaEFRQ2FlaUxpbllRSXZN?= =?utf-8?B?WE9PMUV1ODlCYzA4eDRsdFpmWTluYmFvZEJGd0RWNG80REx2L0Rmb2xRZFIx?= =?utf-8?B?OXdUcTA1TzRiVFNKYVR3WTMwcmRTZ2Z4aWluUFI2ZmpVVE1lUWZvOXFoazlI?= =?utf-8?B?NWt3SXJOL0FkWjZSNStiOXRNeUVWZ2szK1N0cDNzWE0rMG5Hb3NaTGFiU1p2?= =?utf-8?B?L0M3dENPc2x0eE1LSGtOS0dYVERoVHpKY2FiMmtGSFBQV2FtNDZIaFgzb2x3?= =?utf-8?B?N0xVRk5ZS1lFNlo0WDJGSW1OSldVZHpWRG5xY2xZOGZFS2xhbkZua0FiSmNs?= =?utf-8?B?dnVXcnluMmpkNWw4WHEzR1lMdlQ5WmVkS04xa0g4aGZJY0JWQURyTzNiK2JG?= =?utf-8?B?QWMzUE9uRHFXWDNxN2lEMGNDTXUrbUIzWHU2elc4bC95ZlRQcS9GSnMyd0Fm?= =?utf-8?B?TlQ5RlZFcjViS0xvWjNhbkNxREpWTmtoYWNITDdTRkhST2RVMHRWakROMlYr?= =?utf-8?B?QWt6ZXZmOWxqdHZlc0ZteHZqVkZjVnRXcTlNSGZLZk1PbHQyNVNTczJVRUtY?= =?utf-8?B?UHFXbk5qeWxYaU1KbWNNVXc1Mm5ZK1NPendYZ1JOSmpUbHhUMWJGRUhXTGNR?= =?utf-8?B?dG91N0IzeFlDQ2R0anFZVG5LUjlxWno5NEErQ0hpRWxHUncrRVNrandqcDhm?= =?utf-8?B?bTdUdWwzYWZmRUNQWVkvT3ZvTmtLc0ZZakhHT3QrNzBYTkRKZjYyZVRRdEwv?= =?utf-8?B?NFJOZ01Ya09uaGRCWll5SGFXVkM1R1p5ZFo0clpGTWpkYklEZ1JPcjZpbDIz?= =?utf-8?B?am5qOFgxeit5TzUvZm4xOVNoWE9OVGh6MVgzM3luVEJZWU9WVlR0M1pJbWNt?= =?utf-8?B?S0c5MlNsTlVnVy8wMW9wckc2Y2FDUHhNcU9nU0pqQVVkY0g0eW5TT1VEN1Ns?= =?utf-8?B?blc3OVVWYUFjTHk4NlVrd0g5TExQWnN2SW5aZkd5ZVM1RDI5VjlvWDNPVmRz?= =?utf-8?B?a1p0cXlqMkxIM1l0Y0Z4N3F5V1llZTRJWDNnaVRWNHpnYkJjZXVHa2tZNlhB?= =?utf-8?Q?OLMQ3aX+/XF+XIiO0PTh7OpgKL8xR0=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR08MB1472; 5:krchReKGi/dDytzSE/JWQt3hXQI+8xNmZtDnXoAbAaK0uvC9rKkP1ZFPoZ0RjeAe86wtZmsz6GFGHTTmII6o2gVtRa/qZ/AgMUP+R8H5hgj0LrAQKGhkogqS3wZxWtEZyirrXTEKN958denKnXsJnw==; 24:kSadIZG0VVB6SLnAqYVQ8KR+PuT+MFfz+trxEsx4lAZoFYF4IW4RVQ9d4dTn1vhGLE0eOj3o4YFLdTi15O4kzcOVVmu8R13PK21of3HU0DE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2016 02:14:41.6926 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1472 Archived-At: Cc: "Scharf, Michael \(Michael\)" , "draft-ietf-tcpm-cubic@ietf.org" , "tcpm-chairs@ietf.org" Subject: [tcpm] A new Internet draft for TCP Cubic 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, 20 Jan 2016 02:14:47 -0000 Hello, We just submitted a new Internet draft for TCP Cubic. https://tools.ietf.org/html/draft-ietf-tcpm-cubic-01 Compare to the previous version 00, this version has the following changes. 1. Changes to address comments at http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_cubic * defined the units of window sizes and times at the beginning of Section 3 * redefined beta according to the traditional convention. + That is, cwnd=cwnd*beta on packet loss, instead of cwnd=cwnd*(1-beta) on packet loss. + Updated all beta-related equations and texts * redefined overloaded variables. + for example, separate beta into beta_cubic and beta_aimd. Similar for W, alpha * added parentheses to equations to avoid confusions. * revised Section 3.2 "TCP-Friendly Region" to make it clearer * some other minor editorial changes (e.g., updating Sangtae's organization, removing todo). 2. Changes to document the Linux Cubic * changed the beta from 0.8 to 0.7 to be consistent with the Linux Cubic code. * updated Equations 6 and 7 accordingly * updated Tables 1, 2, and 3 accordingly * some other minor editorial changes Thanks Lisong From nobody Wed Jan 20 01:47:35 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 04FE31B3978 for ; Wed, 20 Jan 2016 01:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xeQmwC1nFxWz for ; Wed, 20 Jan 2016 01:47:33 -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 B13AC1ACD16 for ; Wed, 20 Jan 2016 01:47:32 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-90-569f57b2aa44 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BE.9C.30208.2B75F965; Wed, 20 Jan 2016 10:47:31 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.247]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Wed, 20 Jan 2016 10:47:29 +0100 From: Ingemar Johansson S To: Yuchung Cheng Thread-Topic: Questions on draft-cheng-tcpm-rack-00.txt Thread-Index: AdFSkjeBRrPUHWEiQ/C+6rBIK17Z9QAZm1AAABuWFLA= Date: Wed, 20 Jan 2016 09:47:28 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA4152015B@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA4151E377@ESESSMB205.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7lu7m8PlhBrtsLQ61zmSx6Lizl8Vi 28n5TBZfHl9lc2DxWLCp1GPJkp9MHoeeBwUwR3HZpKTmZJalFunbJXBlvL/0m73ggnzFjBVL GBsYX8h1MXJySAiYSHy8fIsVwhaTuHBvPVsXIxeHkMBhRollDy9COUsYJfZPvccIUsUmYCOx 8tB3MFtEQFWi9cJ2JhCbWaBGomvnMmYQW1jATOLIh5XsEDXmEmf23GeCsK0k7nb9YgOxWYB6 W3rngNm8Ar4SaybfYYVYNoVR4u3eiWCDOAUCJRb8WAx2HqOArMT97/dYIJaJS9x6Mp8J4mwB iSV7zjND2KISLx//g3pHUaL9aQPQoRxA9ZoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGMVmIZk6 C6FjFpKOWUg6FjCyrGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjKuDW36r7mC8/MbxEKMA B6MSD++G9nlhQqyJZcWVuYcYJTiYlUR4U/TnhwnxpiRWVqUW5ccXleakFh9ilOZgURLnTZJp DBMSSE8sSc1OTS1ILYLJMnFwSjUwMgg6Sh6LZNpyxp3zfC/DZT6u3R4yE4+t5H7A+zp2u67u 7u6NzxPPRRqYN4cv4btrueIwn/7PppRLTbcX754jwzNr8tZ5U4WXVfDcXtnMIKHtxdrAY51d ++bL5/rkq1siX84LMywVre24/Otd513dArcvGRv+TpkeaeO7Kfm43a3YG1dZXrPvVGIpzkg0 1GIuKk4EAPlbCXCnAgAA Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Questions on draft-cheng-tcpm-rack-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, 20 Jan 2016 09:47:35 -0000 SGkNCg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gDQpJIGFtIGluIHRoZSBwcm9jZXNz IHRvIG1ha2Ugb3VyIHByb3ByaWV0YXJ5IExURSBzeXN0ZW0gc2ltdWxhdG9yIG1pbWljIHRoZSBM aW51eCBUQ1Agc3RhY2sgYmV0dGVyLiBJJ2xsIGJlIGhhcHB5IHRvIHNlZSB0aGUgcGF0Y2ggdG8g bWFrZSBSQUNLIHRyaWdnZXIgdGhlIHJlY292ZXJ5IHN0YXRlLiANCkFuZCB0aGFua3MgZm9yIHNo YXJpbmcgdGhlIGluc2lnaHRzIGFyb3VuZCB0aGUgY2hhbGxlbmdlIGZvciBSQUNLLCBjb21wYXJl ZCB0byAidHJhZGl0aW9uYWwiIGR1cEFDSyBiYXNlZCByZWNvdmVyeS4NCg0KL0luZ2VtYXINCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBZdWNodW5nIENoZW5nIFttYWls dG86eWNoZW5nQGdvb2dsZS5jb21dDQo+IFNlbnQ6IGRlbiAxOSBqYW51YXJpIDIwMTYgMjI6MzMN Cj4gVG86IEluZ2VtYXIgSm9oYW5zc29uIFMNCj4gQ2M6IE5lYWwgQ2FyZHdlbGw7IHRjcG1AaWV0 Zi5vcmc7IEthcmVuIEUuIEUuIE5pZWxzZW4NCj4gU3ViamVjdDogUmU6IFF1ZXN0aW9ucyBvbiBk cmFmdC1jaGVuZy10Y3BtLXJhY2stMDAudHh0DQo+IA0KPiBPbiBUdWUsIEphbiAxOSwgMjAxNiBh dCAxMjoyOCBBTSwgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA8aW5nZW1hci5zLmpvaGFuc3NvbkBl cmljc3Nvbi5jb20+IHdyb3RlOg0KPiA+IEhpIFl1Y2h1bmcsIE5lYWwgKyBvdGhlcnMNCj4gPg0K PiA+IEkgYW0gY3VycmVudGx5IGxvb2tpbmcgaW50byB0aGUgaW5uZXIgZGV0YWlscyBvZiBSQUNL IGFuZCBob3cgaXQgY29leGlzdHMNCj4gd2l0aCAgb3RoZXIgKGR1cGFjayBiYXNlZCkgbG9zcyBo ZXVyaXN0aWNzLg0KPiA+IEFzIEkgdW5kZXJzdGFuZCB0aGUgTGludXggNC40IGNvZGUgYXMgd2Vs bCBhcyB5b3VyIGNvbW1lbnQgIkN1cnJlbnRseQ0KPiBpbXBsZW1lbnRlZCB0byBjby1leGlzdCB3 aXRoIG90aGVyIER1cFRocmVzaCBoZXVyaXN0aWNzIiBpbg0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy85NC9zbGlkZXMvc2xpZGVzLTk0LXRjcG0tNi5wZGYgLCBSQUNLDQo+IGRv ZXMgY3VycmVudGx5IG5vdCByZXBsYWNlIHRoZSBkdXBhY2sgaGV1cmlzdGljcyA/Lg0KPiA+IFRo aXMgdGhlbiBtZWFucyB0aGF0IGV2ZW4gdGhvdWdoIFJBQ0sgdXNlIGEgcmVvX3duZCBvZiAxMG1z IGl0IGNhbg0KPiBtZWFuIHRoYXQgZmFzdCByZXRyYW5zbWl0cyBhcmUgdHJpZ2dlcmVkIGV2ZW4g dGhvdWdoIHRoZSBwYWNrZXQgcmVvcmRlcmluZw0KPiBpcyBsZXNzIHRoYW4gMTBtcy4gSXMgbXkg b2JzZXJ2YXRpb24gY29ycmVjdCA/Lg0KPiBUaGF0J3MgY29ycmVjdC4gUkFDSyBpcyBjdXJyZW50 bHkgb25seSB1c2VkIGFmdGVyIHRoZSByZWNvdmVyeSBzdGFydHMgYW5kIGRvZXMNCj4gbm90IHN0 YXJ0IHRoZSByZWNvdmVyeS4gc28geW91ciBzY2VuYXJpbyBpcyBwb3NzaWJsZS4NCj4gDQo+IGJ0 dyBpdCdzIG9uZS1saW5lYXIga2VybmVsIGNoYW5nZSB0byBlbmFibGUgUkFDSyB0byBzdGFydCBy ZWNvdmVyeSAoYWxvbmcNCj4gd2l0aCBvdGhlciB0cmlja3MpLiBJIGNhbiBzZW5kIHlvdSB0aGUg cGF0Y2ggaWYgeW91IGFyZSBpbnRlcmVzdGVkLg0KPiANCj4gPg0KPiA+IFdoYXQgaXMgdGhlIGlt cGxlbWVudGF0aW9uIHN0YXR1cyBpbiB5b3VyIChHb29nbGUpIHNlcnZlcnMgPywgaXMgaXQgc29s ZWx5DQo+IFJBQ0sgYmFzZWQgPw0KPiBJdCdzIGNvbXBsZXRlbHkgaWRlbnRpY2FsIHRvIHRoZSB1 cHN0cmVhbSBrZXJuZWwuIE5vIHNlY3JldCBzYXVjZSA7LSkNCj4gDQo+IFdlIGhhdmUgUkFDSy1v bmx5IGJhc2VkIGltcGxlbWVudGF0aW9uIGJ1dCBpdCdzIG5vdCB3ZWxsIHRlc3RlZCB5ZXQuDQo+ IFRoZXJlIGFyZSB0d28gY2hhbGxlbmdlcy4NCj4gDQo+IFRoZSBmaXJzdCBvbmUgaXMgZGVzaWdu OiBpbiBhIGhpZ2hseSByZW9yZGVyZWQgYW5kIG5vIGxvc3Mgc2NlbmFyaW8gKHVzdWFsbHkNCj4g YXJ0aWZpY2lhbGx5IGNyYWZ0ZWQpLCBkeW5hbWljIGR1cGFjayB0aHJlc2hvbGQgYmVhdHMgUkFD SydzIHJlb193bmQuIFRoaXMgaXMNCj4gYi9jIGR1cHRocmVzaCBpcyBuZWFyIHRoZSBtYXhpbXVt IGN3bmQgdGhhdCBiYXNpY2FsbHkgdHVybnMgb2ZmIGZhc3QNCj4gcmVjb3ZlcnkuIG9idmlvdXNs eSBpdCdzIG1vcmUgZWZmZWN0aXZlLg0KPiANCj4gdGhlIHNlY29uZCBvbmUgaXMgbW9yZSBvZiBp bXBsZW1lbnRhdGlvbjogcmVwbGFjaW5nIDEwIHJlY292ZXJ5IHRyaWNrcyB3aXRoDQo+IG9uZSBo YXMgbWFqb3Igcmlzay4gc28gdGhlIGltcGxlbWVudGF0aW9uIG5lZWRzIHRvIGtlZXAgdGhlIGV4 aXN0aW5nIGNvZGUNCj4gYXMgYSBlbWVyZ2VuY3kgYmFja3VwIHRocm91Z2ggc3lzY3RsIGNoYW5n ZS4gdGhhdCBhZGRzIHNpZ25pZmljYW50DQo+IGNvbXBsZXhpdHkuDQo+IA0KPiBidXQgd2UgZGVm aW5pdGVseSBwbGFuIHRvIGltcHJvdmUgUkFDSyBiZWZvcmUgbmV4dCBtZWV0aW5nIDotKQ0KPiAN Cj4gPg0KPiA+IC9JbmdlbWFyDQo+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQo+ID4gSW5nZW1hciBKb2hhbnNzb24gIE0uU2MuDQo+ID4gU2VuaW9yIFJlc2VhcmNoZXINCj4g Pg0KPiA+IEVyaWNzc29uIEFCDQo+ID4gV2lyZWxlc3MgQWNjZXNzIE5ldHdvcmtzDQo+ID4gTGFi cmF0b3JpZWdyw6RuZCAxMQ0KPiA+IDk3MSAyOCwgTHVsZcOlLCBTd2VkZW4NCj4gPiBQaG9uZSAr NDYtMTA3MSA0MzA0Mg0KPiA+IFNNUy9NTVMgKzQ2LTczIDA3OCAzMjg5DQo+ID4gaW5nZW1hci5z LmpvaGFuc3NvbkBlcmljc3Nvbi5jb20NCj4gPiB3d3cuZXJpY3Nzb24uY29tDQo+ID4NCj4gPiDi gJxXZSBjYW4gYmUgaGVyb2VzLA0KPiA+ICAganVzdCBmb3Igb25lIGRheeKAnQ0KPiA+ICAgICBE YXZpZCBCb3dpZQ0KPiA+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K From nobody Wed Jan 20 08:01:10 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 6C5331B3958; Wed, 20 Jan 2016 01:07:40 -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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160120090740.30306.27049.idtracker@ietfa.amsl.com> Date: Wed, 20 Jan 2016 01:07:40 -0800 Archived-At: X-Mailman-Approved-At: Wed, 20 Jan 2016 08:01:07 -0800 Cc: mls.ietf@gmail.com, tcpm@ietf.org, michael.scharf@alcatel-lucent.com, tcpm-chairs@ietf.org Subject: [tcpm] tcpm - New Meeting Session 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: Wed, 20 Jan 2016 09:07:40 -0000 A new meeting session request has just been submitted by Michael Scharf, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: dclcrg tcpinc taps httpbis rmcat iccrg tsvwg tsvarea mptcp maprg Second Priority: rtcweb aqm ippm Third Priority: Special Requests: --------------------------------------------------------- From nobody Wed Jan 20 11:39:12 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 E3F6C1ACDBC for ; Wed, 20 Jan 2016 11:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 LUfi_1z9TGUT for ; Wed, 20 Jan 2016 11:39:09 -0800 (PST) Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.110]) by ietfa.amsl.com (Postfix) with ESMTP id 708D91ACDCB for ; Wed, 20 Jan 2016 11:39:07 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u0KJd61R005954 for ; Wed, 20 Jan 2016 14:39:06 -0500 Received: (qmail 6703 invoked by uid 0); 20 Jan 2016 19:39:06 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.137?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 20 Jan 2016 19:39:05 -0000 To: Alissa Cooper , The IESG References: <20160120190453.15005.2588.idtracker@ietfa.amsl.com> From: Wesley Eddy Message-ID: <569FE257.7010601@mti-systems.com> Date: Wed, 20 Jan 2016 14:39:03 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160120190453.15005.2588.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-tcpm-undeployed@ietf.org, draft-ietf-tcpm-undeployed@tools.ietf.org, tcpm@ietf.org, tcpm-chairs@ietf.org Subject: Re: [tcpm] Alissa Cooper's No Objection on draft-ietf-tcpm-undeployed-03: (with COMMENT) 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, 20 Jan 2016 19:39:11 -0000 In this case, the implementation wound up deployed in the Linux kernel using that experimental codepoint, which then made it difficult for others to use the experimental codepoint. The ultimate conclusion of this (and similar episodes) was RFC 6994. On 1/20/2016 2:04 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-tcpm-undeployed-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Regarding RFC 6013, wouldn't implementations of an experimental spec be > expected to use experimental code points? It seems to me like the last > two bullets of explanation would be sufficient without the first one. > > > > From nobody Wed Jan 20 16:25:44 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 A04271B2B94; Wed, 20 Jan 2016 16:25: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, RP_MATCHES_RCVD=-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 TlSYwFcYLeDW; Wed, 20 Jan 2016 16:25:40 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF721B2B8C; Wed, 20 Jan 2016 16:25:40 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u0L0P7wY005060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Jan 2016 16:25:11 -0800 (PST) To: Wesley Eddy , Alissa Cooper , The IESG References: <20160120190453.15005.2588.idtracker@ietfa.amsl.com> <569FE257.7010601@mti-systems.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <56A02562.90801@isi.edu> Date: Wed, 20 Jan 2016 16:25:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <569FE257.7010601@mti-systems.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: draft-ietf-tcpm-undeployed@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-undeployed@tools.ietf.org, tcpm-chairs@ietf.org, touch@isi.edu Subject: Re: [tcpm] Alissa Cooper's No Objection on draft-ietf-tcpm-undeployed-03: (with COMMENT) 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, 21 Jan 2016 00:25:41 -0000 Agreed- to be more clear, the problem of RFC 6013 is not using these codepoints is restricted in RFC4727, Sec. 1: It is not appropriate to simply select one of these values and hard code it into a system. RFC3692 has even more direct discussion: Values reserved for experimental use are never to be made permanent; permanent assignments should be obtained through standard processes. As described above, experimental numbers are intended for experimentation and testing and are not intended for wide or general deployments. When protocols that use experimental numbers are included in products, the shipping versions of the products must disable recognition of protocol experimental numbers by default -- that is, the end user of the product must explicitly "turn on" the experimental protocol functionality. In most cases, a product implementation must require the end user to configure the value explicitly prior to enabling its usage. Should a product not have a user interface for such end user configuration, the product must require explicit re-programming (e.g., a special firmware download, or installation of a feature card) to configure the experimental number(s) of the protocol(s) implicitly. I'm not sure if it would be useful to include some of this with the first bullet, but that's the context, FYI. Joe On 1/20/2016 11:39 AM, Wesley Eddy wrote: > In this case, the implementation wound up deployed in the Linux kernel > using that experimental codepoint, which then made it difficult for > others to use the experimental codepoint. > > The ultimate conclusion of this (and similar episodes) was RFC 6994. > > > > On 1/20/2016 2:04 PM, Alissa Cooper wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-tcpm-undeployed-03: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Regarding RFC 6013, wouldn't implementations of an experimental spec be >> expected to use experimental code points? It seems to me like the last >> two bullets of explanation would be sufficient without the first one. >> >> >> >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jan 20 21:37:08 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 B65601B2F8F; Wed, 20 Jan 2016 21:37:06 -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 uDUA5pVrCfmD; Wed, 20 Jan 2016 21:37:05 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 4C6B21B2F8D; Wed, 20 Jan 2016 21:37:05 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id 123so159497244wmz.0; Wed, 20 Jan 2016 21:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=EWLeUqFgV/6doSgGjFKsnCUGXOzYq9JLF0RrybjPeCg=; b=MH2KJ6VzDwbq2RF0MEZ+TCvOeYFmf1puIXy0Sw43MNgN/KnZGE56OqfVTCofpLvfVm PtAlKSWoR1HBnty8AUSO582Hxh46vpi+UGmHnRKbbtsAkAIMXmhR4wolU+yOdOI2VORm GJRqYxAUTtTG9vwEq8sUZa9EJyDp5PO+MDVQSDHdO8nAoylkXM68rgKaHbwEPSLhTh6q Pool6uv72/hU+0jce2ivM46Gu6M9y4EnaZdZXrxnTtXXKqRYUCWNbBPTGbwHNP9T7Ikn MHIfa4xR+T65SqCiVDBqmszmx8wNF7sLgkJS39dmmtFec9tvjT8XjQOlP2AXQegURYux E3Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=EWLeUqFgV/6doSgGjFKsnCUGXOzYq9JLF0RrybjPeCg=; b=WjEDgu1Ec7VBxIsXXvlTgXYOjyFbBpQl6MKTCIzsPI8Zb8ZChR7zH3Xz2PpjQN7nOv qpe2lNmy8XN0TGOp2U7jfJx3HdJIEf4kajojaK5P3v04KAd8peyxU7sTi7aua0bh5amN dV7ljVwTWm/Jhf1znC44RBKa7//l1d6+HgyLtjtxUvgKIqw3EAPa5BSq1DiYjTkPftef aV9zh3rzbY6S+XB6Ui7LB5KGns+CJaC+Ci2wMM6ifOinWsR99iFNrHnhUo9chcSvRUmW jIhYFRldac42xEZ8lfRfb2xrnmYTbI530cUJb/8PdXgEU6zYd6LAOCZVhLRE8XRPor08 WJpw== X-Gm-Message-State: AG10YOTibkF82qWFOwhunilQ7re3DlEzL70plAjzq5cL+hHZ7dkF8+LrZ5RD7YzVdcnBvA== X-Received: by 10.28.11.77 with SMTP id 74mr8347869wml.36.1453354623891; Wed, 20 Jan 2016 21:37:03 -0800 (PST) Received: from Martins-MBP-2.fritz.box ([2001:1a80:280c:8300:c07d:5c19:369e:436c]) by smtp.googlemail.com with ESMTPSA id c185sm28063705wma.5.2016.01.20.21.37.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 21:37:03 -0800 (PST) To: Ben Campbell , The IESG References: <20160120232035.30792.94953.idtracker@ietfa.amsl.com> From: Martin Stiemerling Message-ID: <56A06E7D.5090608@gmail.com> Date: Thu, 21 Jan 2016 06:37:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160120232035.30792.94953.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-tcpm-undeployed@ietf.org, draft-ietf-tcpm-undeployed@tools.ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-undeployed-03: (with COMMENT) 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, 21 Jan 2016 05:37:06 -0000 Hi Ben, Am 21.01.16 um 00:20 schrieb Ben Campbell: > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Does this really obsolete all the affected documents, in addition to the > changing them to "historical"? Yes, for the listed ones. This is to ensure that the metadata of these historical RFCs is pointing to RFC(draft-ietf-tcpm-undeployed-03) as obsoleting them. Just to be clear for anybody out there, leaving no room for any doubt :) Thanks, Martin From nobody Thu Jan 21 05:31:12 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 9C4921B30F8; Thu, 21 Jan 2016 05:31:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160121133109.4620.99751.idtracker@ietfa.amsl.com> Date: Thu, 21 Jan 2016 05:31:09 -0800 Archived-At: Cc: draft-ietf-tcpm-undeployed@ietf.org, draft-ietf-tcpm-undeployed@tools.ietf.org, tcpm@ietf.org, tcpm-chairs@ietf.org Subject: [tcpm] Spencer Dawkins' Yes on draft-ietf-tcpm-undeployed-03: (with COMMENT) 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: Thu, 21 Jan 2016 13:31:09 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-tcpm-undeployed-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for producing this. Anything that helps new implementers understand what they can ignore in TCP is great! I have one nit you might want to consider. There are a couple of descriptions like o [RFC0675] U, "Specification of Internet Transmission Control Program" was replaced by the final TCP specification [RFC0793] that refer to "the final TCP specification". I know what you mean, but given that TCPM has producing an RFC 793 bis specification as a current milestone, RFC 793 may not be "final"! From nobody Thu Jan 21 08:11:28 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 1417E1ACD39; Wed, 20 Jan 2016 11:04:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160120190453.15005.2588.idtracker@ietfa.amsl.com> Date: Wed, 20 Jan 2016 11:04:53 -0800 Archived-At: X-Mailman-Approved-At: Thu, 21 Jan 2016 08:11:27 -0800 Cc: draft-ietf-tcpm-undeployed@ietf.org, draft-ietf-tcpm-undeployed@tools.ietf.org, tcpm@ietf.org, tcpm-chairs@ietf.org Subject: [tcpm] Alissa Cooper's No Objection on draft-ietf-tcpm-undeployed-03: (with COMMENT) 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: Wed, 20 Jan 2016 19:04:53 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-tcpm-undeployed-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Regarding RFC 6013, wouldn't implementations of an experimental spec be expected to use experimental code points? It seems to me like the last two bullets of explanation would be sufficient without the first one. From nobody Thu Jan 21 08:11:40 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 CCE941A8913 for ; Wed, 20 Jan 2016 11:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 d4xSA3uUc5dN for ; Wed, 20 Jan 2016 11:54:13 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677FA1A8912 for ; Wed, 20 Jan 2016 11:54:13 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C7D9F21910 for ; Wed, 20 Jan 2016 14:44:19 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 20 Jan 2016 14:44:19 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ULiiw2d5fvtNfU4M4zlmpBMuBzo=; b=2JJput 6AFnm09tlwQ24SGVwQ3fjkmI5kb6ZFx2HyLsWgx2+XpzaCrRyC1DdQvoH4xPaZ8q tnhDxuVNBgLgCPmEQYDQXYML1FBWtQNtiXOHTKPk0iu5MjnHZg8FBfJrryDN3iXc sZITbSSq0bJSv3Jv3aW8lhnmBIcyChVSRPjgY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ULiiw2d5fvtNfU4 M4zlmpBMuBzo=; b=SfehZFsl14TQGkqWPc2piO77h+3uMBK6QtAiHzx35U1Cjl1 9DZoWMnRYo4+bjFkJ5X2cLL3Pi4atNnNb5m0AjYIRIf8PQZhtKRVwua+ExnWR/72 PQxTFhRl+hyq2D997lsZRWwocFhTWpurXreSLmKMV0N8pFabYPgBCy9qc+us= X-Sasl-enc: BFSwuGNJwvsogNAR+rdDTRUkykhr5Mq2C3k0p+J7vohP 1453319059 Received: from dhcp-171-68-20-108.cisco.com (dhcp-171-68-20-108.cisco.com [171.68.20.108]) by mail.messagingengine.com (Postfix) with ESMTPA id C2E84C01709; Wed, 20 Jan 2016 14:44:18 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <569FE257.7010601@mti-systems.com> Date: Wed, 20 Jan 2016 11:44:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <833859F7-2384-40C3-BF75-B5324D973833@cooperw.in> References: <20160120190453.15005.2588.idtracker@ietfa.amsl.com> <569FE257.7010601@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Thu, 21 Jan 2016 08:11:39 -0800 Cc: tcpm@ietf.org, draft-ietf-tcpm-undeployed@ietf.org, draft-ietf-tcpm-undeployed@tools.ietf.org, IESG , tcpm-chairs@ietf.org Subject: Re: [tcpm] Alissa Cooper's No Objection on draft-ietf-tcpm-undeployed-03: (with COMMENT) 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, 20 Jan 2016 19:54:15 -0000 > On Jan 20, 2016, at 11:39 AM, Wesley Eddy wrote: >=20 > In this case, the implementation wound up deployed in the Linux kernel = using that experimental codepoint, which then made it difficult for = others to use the experimental code point. Ah, I see. That is slightly different from what the text says. I think = it could help to clarify, but it=E2=80=99s not a big deal either way. Alissa >=20 > The ultimate conclusion of this (and similar episodes) was RFC 6994. >=20 >=20 >=20 > On 1/20/2016 2:04 PM, Alissa Cooper wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-tcpm-undeployed-03: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Regarding RFC 6013, wouldn't implementations of an experimental spec = be >> expected to use experimental code points? It seems to me like the = last >> two bullets of explanation would be sufficient without the first one. >>=20 >>=20 >>=20 >>=20 >=20 From nobody Thu Jan 21 08:11:50 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 BA5761B2A91; Wed, 20 Jan 2016 15:20:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160120232035.30792.94953.idtracker@ietfa.amsl.com> Date: Wed, 20 Jan 2016 15:20:35 -0800 Archived-At: X-Mailman-Approved-At: Thu, 21 Jan 2016 08:11:48 -0800 Cc: draft-ietf-tcpm-undeployed@ietf.org, draft-ietf-tcpm-undeployed@tools.ietf.org, tcpm@ietf.org, tcpm-chairs@ietf.org Subject: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-undeployed-03: (with COMMENT) 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: Wed, 20 Jan 2016 23:20:35 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tcpm-undeployed-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Does this really obsolete all the affected documents, in addition to the changing them to "historical"? From nobody Thu Jan 21 08:12:00 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 7C35B1B2FE2 for ; Wed, 20 Jan 2016 21:59:44 -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, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 TGIR_bbxpLkI for ; Wed, 20 Jan 2016 21:59:43 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 DB8C91B2FE0 for ; Wed, 20 Jan 2016 21:59:43 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0L5xckT083638 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 20 Jan 2016 23:59:38 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Martin Stiemerling" Date: Wed, 20 Jan 2016 23:59:39 -0600 Message-ID: In-Reply-To: <56A06E7D.5090608@gmail.com> References: <20160120232035.30792.94953.idtracker@ietfa.amsl.com> <56A06E7D.5090608@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: X-Mailman-Approved-At: Thu, 21 Jan 2016 08:11:59 -0800 Cc: tcpm@ietf.org, draft-ietf-tcpm-undeployed@ietf.org, draft-ietf-tcpm-undeployed@tools.ietf.org, The IESG , tcpm-chairs@ietf.org Subject: Re: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-undeployed-03: (with COMMENT) 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, 21 Jan 2016 05:59:44 -0000 On 20 Jan 2016, at 23:37, Martin Stiemerling wrote: > Hi Ben, > > Am 21.01.16 um 00:20 schrieb Ben Campbell: >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Does this really obsolete all the affected documents, in addition to >> the >> changing them to "historical"? > > Yes, for the listed ones. > This is to ensure that the metadata of these historical RFCs is > pointing to RFC(draft-ietf-tcpm-undeployed-03) as obsoleting them. > > Just to be clear for anybody out there, leaving no room for any doubt > :) Okay--as long as it was on purpose :-) From nobody Fri Jan 22 06:49:18 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 01EBE1ACE7E for ; Fri, 22 Jan 2016 06:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 u_dlBt4JytEi for ; Fri, 22 Jan 2016 06:49:15 -0800 (PST) Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BD11ACE6D for ; Fri, 22 Jan 2016 06:49:14 -0800 (PST) Received: from [62.232.251.194] (port=12187 helo=virgo.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aMd1Q-0000mC-G8 for tcpm@ietf.org; Fri, 22 Jan 2016 14:49:10 +0000 From: Sara Dickinson Content-Type: multipart/alternative; boundary="Apple-Mail=_57C49636-BA01-47A6-A8A9-9A049223F103" Date: Fri, 22 Jan 2016 14:49:10 +0000 References: To: tcpm@ietf.org Message-Id: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sinodun.com X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: sara+sinodun.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: shcp01.hosting.zen.net.uk: sara@sinodun.com Archived-At: Subject: [tcpm] Question on TCP Fast Open 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, 22 Jan 2016 14:49:17 -0000 --Apple-Mail=_57C49636-BA01-47A6-A8A9-9A049223F103 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi,=20 I would like to ask for some clarification on the expected behaviour of = clients when using TCP Fast Open (RFC7413).=20 I=E2=80=99ve observed in inter-op testing of various implementations = that after a successful TFO cookie exchange one client (Linux - Kernel = 4.4) does not acknowledge data sent by the server in the SYN-ACK in = subsequent TFO connections. As a result the server must re-transmit the = data, which introduces a delay. RFC7413 clearly states that the server = =E2=80=98MAY=E2=80=99 send data in the SYN-ACK (Section 4.2.2). My = question is for clarification on what clients should do when receiving = the SYN-ACK (also Section 4.2.2) : =E2=80=9C Client: Receiving SYN-ACK The client SHOULD perform the following steps upon receiving the SYN- ACK: 1. If the SYN-ACK has a Fast Open option, an MSS option, or both, update the corresponding cookie and MSS information in the cookie cache. 2. Send an ACK packet. Set acknowledgment number to RCV.NXT and include the data after SND.UNA if data is available."=20 I read this as clients SHOULD acknowledge data in the SYN-ACK if it is = present - is that correct? Since this is only a SHOULD what are the = reasons a client may choose not to do that? Regards Sara.=20 --Apple-Mail=_57C49636-BA01-47A6-A8A9-9A049223F103 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi, 

I would like to ask for some clarification on the expected = behaviour of clients when using TCP Fast Open (RFC7413). 

I=E2=80=99ve observed in = inter-op testing of various implementations that after a successful TFO = cookie exchange one client (Linux - Kernel 4.4) does not acknowledge = data sent by the server in the SYN-ACK in subsequent TFO connections. As = a result the server must re-transmit the data, which introduces a delay. = RFC7413 clearly states that the server =E2=80=98MAY=E2=80=99 send data = in the SYN-ACK (Section 4.2.2). My question is for clarification on what = clients should do when receiving the SYN-ACK (also Section 4.2.2) = :

=E2=80=9C Client: Receiving = SYN-ACK

   The client SHOULD perform the following steps upon receiving the SYN-
   ACK:

   1. If the SYN-ACK has a Fast Open option, an MSS option, or both,
      update the corresponding cookie and MSS information in the cookie
      cache.

   2. Send an ACK packet.  Set acknowledgment number to RCV.NXT and
      include the data after SND.UNA if data is =
available." 

I read this as clients = SHOULD acknowledge data in the SYN-ACK if it is present - is that = correct? Since this is only a SHOULD what are the reasons a client may = choose not to do that?


Regards

Sara. 


= --Apple-Mail=_57C49636-BA01-47A6-A8A9-9A049223F103-- From nobody Fri Jan 22 08:36: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 E68701B29AD for ; Fri, 22 Jan 2016 08:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 uF7LFU_fxV13 for ; Fri, 22 Jan 2016 08:36:39 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 620AA1B29B3 for ; Fri, 22 Jan 2016 08:36:39 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id r129so220311238wmr.0 for ; Fri, 22 Jan 2016 08:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Pjw3XPBLCUt4EUxPrSiXT+lGPFlT7zZwiJf72w+QcMA=; b=Xnb9zaYog/ofsYB1KTpDOOKTKT/Gj33hsIHqmxKPaT5OGHKBFfu/U68yzLqxIK7x+5 3oGc8avRxlbID5Xga/hu4sKRPjT3je9TRf7LCuWdlS68GCVRJkMWnbBDc7NISxAzbgcK fak+WGmsZmpNU8z/ISolJMrHlR5kNz7i5Cp1m30NElmLzsZbIgI2oR4467yHfXTU9QMH FZ6wbUf87jhuL6JgJVrDict5HgOUMIVV+VOsWfwCR1lcqLgrIpmLtkLg7rbZdbhVYOBa sI7JY2Pm4tUEhMP+uTT+xxvjvXpR3Yb7A+IbT8+nrDdQRdbMQ2rXTf2MhVXyvU0KRzbH 1vBw== 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-type:content-transfer-encoding; bh=Pjw3XPBLCUt4EUxPrSiXT+lGPFlT7zZwiJf72w+QcMA=; b=lUyTm4fDj+CxziHpWhLT2DLbpw/9HHp69W7QFxGJn51mOSvEjdGjw51nqPCEQxqnrX P3odrdwn6vzUQlzSQ3MTstNzR2fFXZVEzvMDujRcrgvkTsZPiRRQvfyzybelC4Ut66TR 7H0Qb906Sm5S5ZEA1Gm8tuG9+IiYTz4Dvf9DIT1lQWS4yToYTnvEzZyrE2hKafpRbgJl PooHQoLPSA/vzdXueErU6rWjGqbj+kCT9TGm1wVTJGYmr4cc1PItCKhvuY1Be9p8WX5I oTxK3w/TSdbZMTkbdQ0SiToV1zVlEBhA1DhepwQHLjEeezO/geGgx7KuiD7W+90w7TR0 9r1w== X-Gm-Message-State: AG10YOQzp/6gchudeHVacIfriFiPHBDM7EY4f7OA7vRTITneV510/1TXYHOZu+q+AxYlS65sZlKlY58a/FjnMHn0 X-Received: by 10.28.174.196 with SMTP id x187mr4789519wme.2.1453480597903; Fri, 22 Jan 2016 08:36:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.184.196 with HTTP; Fri, 22 Jan 2016 08:35:58 -0800 (PST) In-Reply-To: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> References: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> From: Yuchung Cheng Date: Fri, 22 Jan 2016 08:35:58 -0800 Message-ID: To: Sara Dickinson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Question on TCP Fast Open 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, 22 Jan 2016 16:36:41 -0000 On Fri, Jan 22, 2016 at 6:49 AM, Sara Dickinson wrote: > > > Hi, > > I would like to ask for some clarification on the expected behaviour of c= lients when using TCP Fast Open (RFC7413). > > I=E2=80=99ve observed in inter-op testing of various implementations that= after a successful TFO cookie exchange one client (Linux - Kernel 4.4) doe= s not acknowledge data sent by the server in the SYN-ACK in subsequent TFO = connections. As a result the server must re-transmit the data, which introd= uces a delay. RFC7413 clearly states that the server =E2=80=98MAY=E2=80=99 = send data in the SYN-ACK (Section 4.2.2). My question is for clarification = on what clients should do when receiving the SYN-ACK (also Section 4.2.2) : > > =E2=80=9C Client: Receiving SYN-ACK > > The client SHOULD perform the following steps upon receiving the SYN- > ACK: > > 1. If the SYN-ACK has a Fast Open option, an MSS option, or both, > update the corresponding cookie and MSS information in the cookie > cache. > > 2. Send an ACK packet. Set acknowledgment number to RCV.NXT and > include the data after SND.UNA if data is available." > > > I read this as clients SHOULD acknowledge data in the SYN-ACK if it is pr= esent - is that correct? Since this is only a SHOULD what are the reasons a= client may choose not to do that? Linux AFAICT does not implement that (yet). It's that simple :-) but it's certainly do-able. The reason Jerry and I didn't implement that was because in our use cases the (Web) server does not have data available to send when receiving SYN. But your use case can be different that requires this. For now, a simple work-around for the server is to send a pure SYN-ACK followed immediately by a data packet. I am curious what other implementations do (e.g., IOS). HTH > > > > Regards > > Sara. > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri Jan 22 08:51:58 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 77D9E1B29ED for ; Fri, 22 Jan 2016 08:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Jsd5QgNubfd9 for ; Fri, 22 Jan 2016 08:51:56 -0800 (PST) Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4321B29F3 for ; Fri, 22 Jan 2016 08:51:56 -0800 (PST) Received: from [62.232.251.194] (port=11592 helo=virgo.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aMew9-00016N-8c; Fri, 22 Jan 2016 16:51:51 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sara Dickinson In-Reply-To: Date: Fri, 22 Jan 2016 16:51:51 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> To: Yuchung Cheng X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sinodun.com X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: sara+sinodun.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: shcp01.hosting.zen.net.uk: sara@sinodun.com Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Question on TCP Fast Open 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, 22 Jan 2016 16:51:57 -0000 > On 22 Jan 2016, at 16:35, Yuchung Cheng wrote: >=20 > On Fri, Jan 22, 2016 at 6:49 AM, Sara Dickinson = wrote: >>=20 >>=20 >> Hi, >>=20 >> I would like to ask for some clarification on the expected behaviour = of clients when using TCP Fast Open (RFC7413). >>=20 >> I=E2=80=99ve observed in inter-op testing of various implementations = that after a successful TFO cookie exchange one client (Linux - Kernel = 4.4) does not acknowledge data sent by the server in the SYN-ACK in = subsequent TFO connections. As a result the server must re-transmit the = data, which introduces a delay. RFC7413 clearly states that the server = =E2=80=98MAY=E2=80=99 send data in the SYN-ACK (Section 4.2.2). My = question is for clarification on what clients should do when receiving = the SYN-ACK (also Section 4.2.2) : >>=20 >> =E2=80=9C Client: Receiving SYN-ACK >>=20 >> The client SHOULD perform the following steps upon receiving the = SYN- >> ACK: >>=20 >> 1. If the SYN-ACK has a Fast Open option, an MSS option, or both, >> update the corresponding cookie and MSS information in the = cookie >> cache. >>=20 >> 2. Send an ACK packet. Set acknowledgment number to RCV.NXT and >> include the data after SND.UNA if data is available." >>=20 >>=20 >> I read this as clients SHOULD acknowledge data in the SYN-ACK if it = is present - is that correct? Since this is only a SHOULD what are the = reasons a client may choose not to do that? Hi,=20 Thanks for the response. > Linux AFAICT does not implement that (yet). It's that simple :-) but > it's certainly do-able. Right, I thought that might be the case, just wanted to double check my = understanding of the spec first :-) >=20 > The reason Jerry and I didn't implement that was because in our use > cases the (Web) server does not have data available to send when > receiving SYN. But your use case can be different that requires this. Yes, the application I am testing with is a recursive DNS server which = is able to deliver data quickly when the answer to a query is in the = cache.=20 > For now, a simple work-around for the server is to send a pure SYN-ACK > followed immediately by a data packet. >=20 > I am curious what other implementations do (e.g., IOS). =46rom my observations the OS X server TFO implementation also waits = until after the handshake is complete to send data (but the client does = support receiving data in the SYN-ACK). But server side TFO has very = recently been implemented in FreeBSD and in that case the server does = send the data in the SYN-ACK, which is where I came across the problem.=20= Regards Sara.=20 From nobody Fri Jan 22 09:05:35 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 9AE891B2A5D for ; Fri, 22 Jan 2016 09:05:34 -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 InBmCvTdFk6F for ; Fri, 22 Jan 2016 09:05:30 -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 68C101B2A58 for ; Fri, 22 Jan 2016 09:05:30 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id CC5DA1822773C; Fri, 22 Jan 2016 17:05:25 +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 u0MH5SFZ007792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jan 2016 17:05:28 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u0MH5I8Z030402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Jan 2016 18:05:27 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.114]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 22 Jan 2016 18:05:14 +0100 From: "Scharf, Michael (Nokia - DE)" To: EXT Sara Dickinson , Yuchung Cheng Thread-Topic: [tcpm] Question on TCP Fast Open Thread-Index: AQHRVSQeja+/HKgZLEeBPeyozUV6o58HquUAgAAEcICAABODoA== Date: Fri, 22 Jan 2016 17:05:14 +0000 Message-ID: <655C07320163294895BBADA28372AF5D485D5449@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> 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.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Question on TCP Fast Open 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, 22 Jan 2016 17:05:34 -0000 SnVzdCBvdXQgb2YgY3VyaW9zaXR5IGEgdmVyeSB1bnJlbGF0ZWQgcXVlc3Rpb24gb24gVENQIEZh c3QgT3BlbjogSGF2ZSB0aGUgZGlmZmVyZW50IFRGTyBpbXBsZW1lbnRhdGlvbnMgaW5kZWVkIG1v dmVkIGZyb20gdGhlIGV4cGVyaW1lbnRhbCBJRCB0byB0aGUgb3B0aW9uIGtpbmQgMzQgcmVnaXN0 ZXJlZCBieSBJQU5BPw0KDQpJIGFtIGFza2luZyBzaW5jZSB3ZSBoYWQgZGlzY3Vzc2lvbnMgb24g dGhhdCB0cmFuc2l0aW9uIGEgbG9uZyB0aW1lIGFnbywgYW5kIEkgd29uZGVyIGlmIHdlIG5vdyBo YXZlIGxlc3NvbnMgbGVhcm50Li4uDQoNClRoYW5rcw0KDQpNaWNoYWVsDQoNCg== From nobody Fri Jan 22 09:28: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 F26F31B2AB6 for ; Fri, 22 Jan 2016 09:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 F7cYfJPZyUwM for ; Fri, 22 Jan 2016 09:28:51 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 BEC6F1B2AB3 for ; Fri, 22 Jan 2016 09:28:50 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id n5so143201061wmn.0 for ; Fri, 22 Jan 2016 09:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=e+WmSFb8cgEPVD2wgrro/+JhlW1WDBX++m3BPBeioek=; b=P0b3JgxYrQTnajdv3hmeDdbllX1Vz0esn8jC4+VT7DU5XTU4RvrHMNIFdtaG7JakQ8 WlPwFh/ae8muPf+HoVJOwC7rgcvXmnaFjN5HIGgijo8NmBRuxwJIFobVuHdj1hx9639T rE0wvUWoVVaT84LyfXiN3FLcPzHNWVwa04C7RP0/pGS7TJFd0EeMRTf/JVq1tS1E4lIS wNZKADCDNy0e3nzeuZUsSna6F0iUQn/SuhoJB0XiPXb3d7G2TsP+Sr+XIZihoi1bdjaR pW9n97nT3BNnwsxogcAjFqWJpAA9gbA5bstIdpZ+Qyu61JZhwDjqZokMz2B0wdPCZXbb JRWw== 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-type; bh=e+WmSFb8cgEPVD2wgrro/+JhlW1WDBX++m3BPBeioek=; b=FzYeWH/Vvd0rKGQz2+5O2MJNjBfhkK36sd6pD1FMUKQOk/pI0ymwsua5Ty7NYRQKs1 Qms9WPtDIErC5PGQQlwNk9tYPCxC0CPE3dAhKDsn96QKh4o+/4Oz59uLBBb0PNUu2W7F tXgSnTw5+JyyBPwyIDs7AM7jr12AM7Jn4xNQpXsXZhbt6+g6fVDhWfql9YCjJALsxIiD WZ15wLEY3IfuURNKXmXOqQLgRR5F4LlKhLDxep9N+vN3YSGCDs9ohJeBcOw7doC0rOjy zEJ45yhREe8X3lPZ8ohzD6xNKIwwOKj03jotBKxYX+Q++GHnFprY0m6BROmTcNuNoe7o 1wVg== X-Gm-Message-State: AG10YORN9Gu94XeGmeKodEJPS+b+KI+j2QwV8cQ4FbwJn7rkG+HMlzhCiabt2/VrwxEidW+NQtZZefGWpdrqXkhb X-Received: by 10.28.73.135 with SMTP id w129mr5102643wma.55.1453483729278; Fri, 22 Jan 2016 09:28:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.184.196 with HTTP; Fri, 22 Jan 2016 09:28:09 -0800 (PST) In-Reply-To: <655C07320163294895BBADA28372AF5D485D5449@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> <655C07320163294895BBADA28372AF5D485D5449@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Fri, 22 Jan 2016 09:28:09 -0800 Message-ID: To: "Scharf, Michael (Nokia - DE)" Content-Type: multipart/alternative; boundary=001a114b2d9e5f66e40529ef8d1e Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Question on TCP Fast Open 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, 22 Jan 2016 17:28:52 -0000 --001a114b2d9e5f66e40529ef8d1e Content-Type: text/plain; charset=UTF-8 Linux by default uses 34 but also support exp. The client would start with 34. if it didn't work the client retries exp and remembers that in the cache, and takes 2 connections to get a cookie which is ok. But I am not sure this is generally applicable for other features using the exp-id opt. The plan is to retire exp-support after another couple years. On Fri, Jan 22, 2016 at 9:05 AM, Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > Just out of curiosity a very unrelated question on TCP Fast Open: Have the > different TFO implementations indeed moved from the experimental ID to the > option kind 34 registered by IANA? > > I am asking since we had discussions on that transition a long time ago, > and I wonder if we now have lessons learnt... > > Thanks > > Michael > > --001a114b2d9e5f66e40529ef8d1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Linux by default uses 34 but also support exp.=C2=A0The cl= ient would start with 34. if it didn't work the client retries exp and = remembers that in the cache, and takes 2 connections to get a cookie which = is ok. But I am not sure this is generally applicable for other features us= ing the exp-id opt.

The plan is to retire exp-support af= ter another couple years.


On Fri, Jan 22, 2016 at 9:05 AM, Scharf,= Michael (Nokia - DE) <michael.scharf@nokia.com> wrot= e:
Just out of curiosity a very unrelated= question on TCP Fast Open: Have the different TFO implementations indeed m= oved from the experimental ID to the option kind 34 registered by IANA?

I am asking since we had discussions on that transition a long time ago, an= d I wonder if we now have lessons learnt...

Thanks

Michael


--001a114b2d9e5f66e40529ef8d1e-- From nobody Fri Jan 22 09:29:19 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 231771B2AB0 for ; Fri, 22 Jan 2016 09:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 yrmQJw0oXxxv for ; Fri, 22 Jan 2016 09:29:16 -0800 (PST) Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015A41B2AB4 for ; Fri, 22 Jan 2016 09:29:16 -0800 (PST) Received: from [62.232.251.194] (port=9369 helo=virgo.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aMfWH-00076A-NG; Fri, 22 Jan 2016 17:29:11 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sara Dickinson In-Reply-To: <655C07320163294895BBADA28372AF5D485D5449@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 22 Jan 2016 17:29:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2E072CAB-29B0-4E9A-8A90-238CC95568E1@sinodun.com> References: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> <655C07320163294895BBADA28372AF5D485D5449@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Nokia - DE)" X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sinodun.com X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: sara+sinodun.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: shcp01.hosting.zen.net.uk: sara@sinodun.com Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Question on TCP Fast Open 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, 22 Jan 2016 17:29:17 -0000 > On 22 Jan 2016, at 17:05, Scharf, Michael (Nokia - DE) = wrote: >=20 > Just out of curiosity a very unrelated question on TCP Fast Open: Have = the different TFO implementations indeed moved from the experimental ID = to the option kind 34 registered by IANA? To my knowledge: - the OS X and FreeBSD implementations both use only 34 - Linux used only the experimental code up to kernel 4.1 when the = default for the client was switched to 34 (with fallback to the = experimental option available if that failed) and support on the server = for receiving either option. I don=E2=80=99t believe this was = back-ported, so for example Ubunutu 14.04 (LTS release) cannot inter-op = with the FreeBSD/OS X implementations.=20 Sara.=20= From nobody Sun Jan 24 11:53:41 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 71A631B3211 for ; Sun, 24 Jan 2016 11:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 6pQ5mesK2uVN for ; Sun, 24 Jan 2016 11:53:38 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA901B320E for ; Sun, 24 Jan 2016 11:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1453665218; x=2317578818; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MY0RH3otqVZZJ+GZD0L2aHjU6NGaC7sbRY6VlXdyICE=; b=Hpiz/kBZdsmc/g5VzmtWqXFeieTvf84C+iW/VKNabC1zEYOuXqOBVvNdbE5Mbn+O VrkZ33F4xaSeT6udoTRQOgn9zBcXp704WEOwsdwqQGDRQ7ZbGoVCavQTD0GfJoE0 PeKSFC6bz+93asmKhtskx9SqI6gubbeyZIUK8Ca3zRsgugv14hXRbRGwc11thPu4 OUmVa5DZA3Ef+QK4rzXAekgQPBPlD4PshUqfCbiAmHkWx4S++dD7nkWMpNJ5ViLb NHbMQrhCvEaRGE2GPeIOHzJdZN6LsqsdPdcQlX9EvKFTVFD94tTLFv3DRkGi3t4r QVK+Fh/isXSZ+B9V72tVqg==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id DA.6E.03960.1CB25A65; Sun, 24 Jan 2016 11:53:37 -0800 (PST) X-AuditID: 11973e12-f796d6d000000f78-ff-56a52bc1510e Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id BE.5E.05180.1CB25A65; Sun, 24 Jan 2016 11:53:37 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from localhost ([17.149.220.212]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O1H008JC39D4N10@cilantro.apple.com> for tcpm@ietf.org; Sun, 24 Jan 2016 11:53:37 -0800 (PST) Sender: cpaasch@apple.com Date: Sun, 24 Jan 2016 11:53:37 -0800 From: Christoph Paasch To: Sara Dickinson Message-id: <20160124195337.GV48144@Chimay.local> References: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> In-reply-to: User-Agent: Mutt/1.5.24 (08e81162482f) (2015-08-30) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FAYrHtQe2mYwdObNhbbTs5ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuYTKxkLnolVzF0xnbWB8YVgFyMnh4SAicTBzdfZIGwxiQv3 1gPZXBxCAnsZJfa//cAMU7Tv9hMWiMQcJom161eBJXgFBCV+TL4HlODgYBaQlzhyKRskzCwg LfHo7wx2iLC6xJQpuRCtLUwS+4+cYgepERaQlOi+cwdsDIuAqsS2aetZQWw2AS2Jt7fbwWwR oPiJRfdZIWYGS3Q1XmWB6NWVmHf0ByvECYYS0xctYIZY8J5R4ujRNWDfcArYS/z9MRPMFhUw lmg6MgfqmR42idt9fBMYRWcheWEWwguzkLwwC+GFBYwsqxiFchMzc3Qz80z0EgsKclL1kvNz NzGCYmG6ndAOxlOrrA4xCnAwKvHwWqgtDRNiTSwrrsw9xCjNwaIkztvfsyhMSCA9sSQ1OzW1 ILUovqg0J7X4ECMTB6dUA6PNE9/DHM5zpuf/yJ10aeunumUrZYs+vtl1RqJp94Nzbe+KOeRS e/2mrznUp9ZYNocvxkiGjdt3q4F8xKes9X1TDgpLbGBe8I/x2fs0lmm3ld5/WLHOI+Tn5d6v P29yL3bTsV1nmnG6S9vhosyO3yulv06dobPkf8LqmpMH1sk9veBqeupilrqzEktxRqKhFnNR cSIAb1t2pWYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUi2FAspHtQe2mYwcRFVhbbTs5ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuYTKxkLnolVzF0xnbWB8YVgFyMnh4SAicS+209YIGwxiQv3 1rN1MXJxCAnMYZJYu34VM0iCV0BQ4sfke0BFHBzMAvISRy5lg4SZBaQlHv2dwQ4RVpeYMiUX orWFSWL/kVPsIDXCApIS3XfugI1hEVCV2DZtPSuIzSagJfH2djuYLQIUP7HoPivEzGCJrsar LBC9uhLzjv5ghTjBUGL6ogXMEAveM0ocPbqGDSTBKWAv8ffHTDBbVMBYounIHOYJjEKzkJw9 C+HsWUjOnoVw9gJGllWMAkWpOYmVxnqJBQU5qXrJ+bmbGMHBWxi8g/HPMqtDjAIcjEo8vBZq S8OEWBPLiitzDzFKcDArifA+1wAK8aYkVlalFuXHF5XmpBYfYpTmYFES5z15emGYkEB6Yklq dmpqQWoRTJaJg1OqgXGdceeZuwdfB5T8MteTbz+3weRDsCijyzLeX4tMFYvF/Kw0Z3lPjljz 8jP/VobVTgxa0kpqMw5c31wZuUnHdP8/oXBPV5UfF5sZe9YYWHOFny/fMzOI6VDLtejHn9XU bprUqjbszBPjtNHwOF+3MGfxoveTTbKa2Eyec7/6Mt+1+P+NKMbnX5RYijMSDbWYi4oTAZf3 6sZaAgAA Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Question on TCP Fast Open 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: Sun, 24 Jan 2016 19:53:39 -0000 Hello Sara, On 22/01/16 - 16:51:51, Sara Dickinson wrote: > >> I would like to ask for some clarification on the expected behaviour of clients when using TCP Fast Open (RFC7413). > >> > >> I’ve observed in inter-op testing of various implementations that after a successful TFO cookie exchange one client (Linux - Kernel 4.4) does not acknowledge data sent by the server in the SYN-ACK in subsequent TFO connections. As a result the server must re-transmit the data, which introduces a delay. RFC7413 clearly states that the server ‘MAY’ send data in the SYN-ACK (Section 4.2.2). My question is for clarification on what clients should do when receiving the SYN-ACK (also Section 4.2.2) : > >> > >> “ Client: Receiving SYN-ACK > >> > >> The client SHOULD perform the following steps upon receiving the SYN- > >> ACK: > >> > >> 1. If the SYN-ACK has a Fast Open option, an MSS option, or both, > >> update the corresponding cookie and MSS information in the cookie > >> cache. > >> > >> 2. Send an ACK packet. Set acknowledgment number to RCV.NXT and > >> include the data after SND.UNA if data is available." > >> > >> > >> I read this as clients SHOULD acknowledge data in the SYN-ACK if it is present - is that correct? Since this is only a SHOULD what are the reasons a client may choose not to do that? > > Hi, > > Thanks for the response. > > > Linux AFAICT does not implement that (yet). It's that simple :-) but > > it's certainly do-able. > > Right, I thought that might be the case, just wanted to double check my understanding of the spec first :-) > > > > > The reason Jerry and I didn't implement that was because in our use > > cases the (Web) server does not have data available to send when > > receiving SYN. But your use case can be different that requires this. > > Yes, the application I am testing with is a recursive DNS server which is able to deliver data quickly when the answer to a query is in the cache. > > > For now, a simple work-around for the server is to send a pure SYN-ACK > > followed immediately by a data packet. > > > > I am curious what other implementations do (e.g., IOS). > > From my observations the OS X server TFO implementation also waits until after the handshake is complete to send data (but the client does support receiving data in the SYN-ACK). But server side TFO has very recently been implemented in FreeBSD and in that case the server does send the data in the SYN-ACK, which is where I came across the problem. OSX does send data when it receives a SYN+valid TFO-cookie right away (after having sent an "empty" SYN/ACK), without waiting for the third ack. Exactly the same way Linux does it. Have you seen in your tests that OSX server does not send data right after the SYN/ACK? Do you have a packet-trace of this observation? Cheers, Christoph From nobody Mon Jan 25 00:25:25 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 BAE771B29D6; Mon, 25 Jan 2016 00:25:23 -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 GVZZ6rFnIWmv; Mon, 25 Jan 2016 00:25:21 -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 265071A0AF1; Mon, 25 Jan 2016 00:25:18 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 479F899E96EEA; Mon, 25 Jan 2016 08:25:14 +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 u0P8PFh0027624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Jan 2016 08:25:16 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 u0P8P1h2029268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Jan 2016 09:25:14 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.112]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 25 Jan 2016 09:25:08 +0100 From: "Scharf, Michael (Nokia - DE)" To: "mallman@icir.org" , "tcpm@ietf.org Extensions" Thread-Topic: WG acceptance of draft-allman-tcpm-rto-consider Thread-Index: AQHRV0nmsyNXfWyj/kaiGH0JpX9vUA== Date: Mon, 25 Jan 2016 08:25:08 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48604E6D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D485B4E20@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D485B4E20@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.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm-ads@ietf.org" Subject: [tcpm] WG acceptance of draft-allman-tcpm-rto-consider 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, 25 Jan 2016 08:25:23 -0000 According to the feedback and earlier TCPM list discussion it is working gr= oup consensus to adopt draft-allman-tcpm-rto-consider as new WG item. I have asked for AD approval for the new charter milestone. Please resubmit= the document as draft-ietf-tcpm-rto-consider once the new milestone is app= roved. Thanks Michael -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael (Mic= hael) Sent: Wednesday, January 06, 2016 5:00 PM To: tcpm@ietf.org Extensions Cc: tcpm-chairs@tools.ietf.org tcpm-chairs@tools.ietf.org Subject: [tcpm] WG acceptance of draft-allman-tcpm-rto-consider? Hi all, This e-mail starts a TCPM WG acceptance call for draft-allman-tcpm-rto-cons= ider, which will run until Friday Jan. 22, 2016. The proposal is to add a new TCPM charter milestone May 2016 Submit document on Retransmission Timeout Considerations as Best= Current Practice RFC ... and use the document draft-allman-tcpm-rto-consider-03 as a starting po= int. As the document is relatively short, the expectation is that this docu= ment could be submitted to IESG relatively fast after the next IETF meeting= . WG acceptance in TCPM requires strong community support. Please reply to th= is e-mail if you support a WG adoption in TCPM. If you have any concerns or= objections, please also let us know. Thanks Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Jan 25 05:24:02 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 7F57B1A90B7 for ; Mon, 25 Jan 2016 05:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 Bf5OXe2llNNF for ; Mon, 25 Jan 2016 05:23:59 -0800 (PST) Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD0A1A90AA for ; Mon, 25 Jan 2016 05:23:59 -0800 (PST) Received: from [62.232.251.194] (port=31216 helo=virgo.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aNh7a-00060b-MF; Mon, 25 Jan 2016 13:23:55 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sara Dickinson In-Reply-To: <20160124195337.GV48144@Chimay.local> Date: Mon, 25 Jan 2016 13:23:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> <20160124195337.GV48144@Chimay.local> To: Christoph Paasch X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sinodun.com X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: sara+sinodun.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: shcp01.hosting.zen.net.uk: sara@sinodun.com Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Question on TCP Fast Open 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, 25 Jan 2016 13:24:01 -0000 > On 24 Jan 2016, at 19:53, Christoph Paasch wrote: >>=20 >> =46rom my observations the OS X server TFO implementation also waits = until after the handshake is complete to send data (but the client does = support receiving data in the SYN-ACK). But server side TFO has very = recently been implemented in FreeBSD and in that case the server does = send the data in the SYN-ACK, which is where I came across the problem. >=20 > OSX does send data when it receives a SYN+valid TFO-cookie right away = (after > having sent an "empty" SYN/ACK), without waiting for the third ack. Many thanks for clarifying this - I was going to double check the OS X = code but you saved me a job. > Exactly the same way Linux does it. >=20 > Have you seen in your tests that OSX server does not send data right = after > the SYN/ACK? Do you have a packet-trace of this observation? In my (limited) testing I have only ever seen response data being = returned after the 3-way handshake for both Linux and OS X, whereas the = same application will send data in the SYN/ACK on FreeBSD. I=E2=80=99ll = send you a packet-trace off list.=20 Regards Sara.=20 From nobody Mon Jan 25 13:03: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 AD7F71A0217 for ; Mon, 25 Jan 2016 13:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 CJffSQj0Zb4K for ; Mon, 25 Jan 2016 13:03:17 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 0725C1A022C for ; Mon, 25 Jan 2016 13:03:16 -0800 (PST) Received: by mail-ob0-x232.google.com with SMTP id is5so126909907obc.0 for ; Mon, 25 Jan 2016 13:03:15 -0800 (PST) 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-type; bh=HHLlTfxASqu5jkkfuTdw6X7+L333lR7JzI1jH2tWVbE=; b=xK5nNb1XAVYikiw1yOYs1u0N2kxBPvR5A3JwnUmiT8RVxRO6QGgWbZD56ogOT86DI1 c0rbKFyi7Z3irAtAPz3rXuZjv/SHCAx3zMbfv0WTNoeGEFyQRQhnMqKxVbURJzWc4OIy Q/j4HeyP+1pA4LFZCwp2KfWrK+ljR0vubc36eMY/xMwe+oNmkBRJ0wOLWzg9fnSl8RQ4 kgGvdQwehtrTv++iCmZ7y1+jT8SNacrCjP5eQY9holKpJvs4pfMJLxOs3g42+iOIyu2A cVliT6O1ziODszmXzR1HgAc4qXzaeitTlhpVeHLkxdnBbDIBXLvcfv+KSs56j9n2mdwz WcQw== 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-type; bh=HHLlTfxASqu5jkkfuTdw6X7+L333lR7JzI1jH2tWVbE=; b=EZphC9v9NOBVC2NU9zWG7QgnEHBFwfdixyNlh9FvhQDDfip7+AMa1Do/Mbjaa/wWCO SZov7VknmozxWgT6M/KPBc062rvt9VjFT+SAnAinmovY+UGkt3EZzFmB6Gge02UYwTj+ GRxTundsEKStnsq7A0Rht+pETAsyQiELS4SmLS1JV2dYPkvYa2pXTpRi2UntJH/a+Zdp qNkjn4xXDREDmBgUyfLxYl/c5uQUjJIfyrOyVkINGoIf+gc/hsGBX+tBYD5nqO98qPH0 I7h4AI3xIhIoFi9frdPNTmX8UX25zhOD/opTJT3u40waef2A1BHpzctgo8PcQkoeAqI/ gYYQ== X-Gm-Message-State: AG10YOTULOC5E4m/9rS/KgKoKU3f0J2kBpbT1qJqNRRC+oh4xnQK7yjosVjOsPwmsRaTrom0qG7RxBe1U3O59g== X-Received: by 10.182.144.225 with SMTP id sp1mr15139148obb.24.1453755795350; Mon, 25 Jan 2016 13:03:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.201.144 with HTTP; Mon, 25 Jan 2016 13:02:55 -0800 (PST) In-Reply-To: <20151101233801.27010.85072.idtracker@ietfa.amsl.com> References: <20151101233801.27010.85072.idtracker@ietfa.amsl.com> From: Andrew Shewmaker Date: Mon, 25 Jan 2016 14:02:55 -0700 Message-ID: To: Praveen Balasubramanian , "EGGERT, Lars" , Stephen Bensley , Dave THALER , Glenn Judd , Bob Briscoe Content-Type: multipart/alternative; boundary=089e0158ab98c5ae44052a2ee5fb Archived-At: Cc: tcpm IETF list Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-01.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: Mon, 25 Jan 2016 21:03:19 -0000 --089e0158ab98c5ae44052a2ee5fb Content-Type: text/plain; charset=UTF-8 Hi, Does DCTCP's exit from slow start need to be addressed in the Internet-Draft? I did see item 8 from https://www.ietf.org/mail-archive/web/iccrg/current/msg01215.html "[Not discussed in the meeting, but added by Bob B for the record]: Less drastic exit from slow-start, to match less drastic rate reduction per mark. Currently, because marking threshold is shallow, slow start exits earlier than with drop, unnecessarily increasing completion time." But I haven't seen any later discussion archived. I didn't see anything in sections 3.3 Processing Congestion Indications on the Sender or 4 Implementation Issues. Perhaps I missed it? In experiments with Linux DCTCP I've noticed interesting slow start behavior. In a five flow convergence test in Mininet I'm seeing similar overall behavior to that shown in the paper. However, when a flow enters, I see its CWND overshoot (by double what it should be) and results in large SRTTs, until the buffer is switch bottleneck buffer has drained. Even if the first ECE flag seen by Linux DCTCP was at the beginning of its observation window, causing it to not update ALPHA until the end of the window, I would have thought SSTHRESH would have been immediately set to at most CWND (or halved, considering that the initial ALPHA is zero). But I don't think that is what I'm seeing. I added the following logic into the update alpha code, and it did force DCTCP to exit immediately: if (flags & CA_ACK_ECE) { if (ca->acked_bytes_ecn == 0 && tcp_in_slow_start(tp)) tp->snd_ssthresh = tp->snd_cwnd; ... So CWND did not overshoot and tail latencies were dramatically reduced. Unfortunately, it also reduces aggregate goodput somewhat. In my Mininet experiments, the unmodified DCTCP's normalized utilization ranged ~0.78 to ~0.83, whereas the early exit modification resulted in ~0.73 to ~0.81. I can provide more details and graphs, if necessary. Is there better logic for slow start exit than the above? I also tried checking just tcp_in_slow_start(tp) and that hurt goodput much more. Regardless of whether someone wants to optimize for goodput or latency, I think that it would be good to address the subject. Thanks, Andrew Shewmaker --089e0158ab98c5ae44052a2ee5fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Does DCTCP's exit from slo= w start need to be addressed in the Internet-Draft?

I = did see item 8 from https://www.ietf.org/mail-archive/web/iccrg/current/= msg01215.html=C2=A0

&= quot;[Not discussed in the meeting, but added by Bob B for the record]: Les= s drastic exit from slow-start, to match less drastic rate reduction per ma= rk.
Currently, because marking threshold = is shallow, slow start exits earlier than with drop, unnecessarily increasi= ng completion time."

But I haven't seen any later discussion archive= d. I didn't see anything in sections 3.3 Processing Congestion Indicati= ons on the Sender or 4 Implementation Issues. Perhaps I missed it?

In experim= ents with Linux DCTCP I've noticed interesting slow start behavior. In = a five flow convergence test in Mininet I'm seeing similar overall beha= vior to that shown in the paper. However, when a flow enters, I see its CWN= D overshoot (by double what it should be) and results in large SRTTs, until= the buffer is switch bottleneck buffer has drained.

Even if the first ECE flag seen by Linux DCTCP was at the beginning of i= ts observation window, causing it to not update ALPHA until the end of the = window, I would have thought SSTHRESH would have been immediately set to at= most CWND (or halved, considering that the initial ALPHA is zero). But I d= on't think that is what I'm seeing.

I ad= ded the following logic into the update alpha code, and it did force DCTCP = to exit immediately:

if (flags & CA_ACK_ECE) {
=C2=A0 =C2=A0 if (ca-&g= t;acked_bytes_ecn =3D=3D 0 && tcp_in_slow_start(tp))
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0tp->snd_ssthre= sh =3D tp->snd_cwnd;
...
So CWND did not overshoot and t= ail latencies were dramatically reduced. Unfortunately, it also reduces agg= regate goodput somewhat. In my Mininet experiments, the unmodified DCTCP= 9;s=C2=A0normalized=C2=A0utilization ranged ~0.78 to ~0.83, whereas the ear= ly exit modification resulted in ~0.73 to ~0.81.

I can provide more details a= nd graphs, if necessary.

Is there better logic for slow start exit than the a= bove? I also tried checking just tcp_in_slow_start(tp) and that hurt goodpu= t much more.

Regardless of whether someone wants to optimize for goodput or l= atency, I think that it would be good to address the subject.

Thanks,

Andrew Sh= ewmaker
--089e0158ab98c5ae44052a2ee5fb-- From nobody Mon Jan 25 14:10:53 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 87D851A1A79; Mon, 25 Jan 2016 14:10:49 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160125221049.14953.53604.idtracker@ietfa.amsl.com> Date: Mon, 25 Jan 2016 14:10:49 -0800 Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-undeployed@ietf.org, mls.ietf@gmail.com, draft-ietf-tcpm-undeployed@tools.ietf.org, The IESG , tcpm-chairs@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] Document Action: 'Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status' to Informational RFC (draft-ietf-tcpm-undeployed-03.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, 25 Jan 2016 22:10:49 -0000 The IESG has approved the following document: - 'Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status' (draft-ietf-tcpm-undeployed-03.txt) as Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ Technical Summary This document reclassifies several TCP extensions and TCP-related documents that have either been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status. The affected RFCs are RFC 675, RFC 721, RFC 761, RFC 813, RFC 816, RFC 879, RFC 896, RFC 1078, and RFC 6013. Additionally, this document reclassifies RFC 700, RFC 794, RFC 814, RFC 817, RFC 872, RFC 889, RFC 964, and RFC 1071 to "Informational" status. Working Group Summary The inclusion of the TCPMUX document (RFC 1078) raised some discussion earlier, because implementations of TCPMUX have been reported in some OS distributions, although it is not in use to our knowledge. There was consensus in the TCPM WG that because of the operational and security concerns in TCPMUX, it should also be declared Historic. Document Quality Document was reviewed by multiple TCPM WG participants. Given its administrative nature, there has been no controversy over it, and it is generally supported by the TCPM community. Personnel Document shepherd is Pasi Sarolahti. Responsible Area Director is Martin Stiemerling. From nobody Mon Jan 25 15:36:14 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 0A8821A21BB for ; Mon, 25 Jan 2016 15:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 5-_nKgO2qVg9 for ; Mon, 25 Jan 2016 15:36:10 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 769B41A21B5 for ; Mon, 25 Jan 2016 15:36:09 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aNqfx-0003NY-4E; Tue, 26 Jan 2016 00:36:01 +0100 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.107]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aNqfv-0005qE-I9; Tue, 26 Jan 2016 00:36:00 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_0134ABEE-E7FC-420A-B2E2-006567E1E531" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Michael Welzl In-Reply-To: Date: Tue, 26 Jan 2016 00:35:52 +0100 Message-Id: <3F46BC45-972B-45CC-86D6-9699E36E09A1@ifi.uio.no> References: <20151101233801.27010.85072.idtracker@ietfa.amsl.com> To: Andrew Shewmaker X-Mailer: Apple Mail (2.3112) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 1 sum rcpts/h 9 sum msgs/h 2 total rcpts 37492 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0AD3F160CF6FE469D3900DE5E4E5FFE96A4209DA X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 257 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tcpm IETF list , Dave THALER , Stephen Bensley , Glenn Judd Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-01.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: Mon, 25 Jan 2016 23:36:13 -0000 --Apple-Mail=_0134ABEE-E7FC-420A-B2E2-006567E1E531 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 25. jan. 2016, at 22.02, Andrew Shewmaker wrote: >=20 > Hi, >=20 > Does DCTCP's exit from slow start need to be addressed in the = Internet-Draft? >=20 > I did see item 8 from = https://www.ietf.org/mail-archive/web/iccrg/current/msg01215.html = =20 >=20 > "[Not discussed in the meeting, but added by Bob B for the record]: = Less drastic exit from slow-start, to match less drastic rate reduction = per mark. > Currently, because marking threshold is shallow, slow start exits = earlier than with drop, unnecessarily increasing completion time." >=20 > But I haven't seen any later discussion archived. I didn't see = anything in sections 3.3 Processing Congestion Indications on the Sender = or 4 Implementation Issues. Perhaps I missed it? >=20 > In experiments with Linux DCTCP I've noticed interesting slow start = behavior. In a five flow convergence test in Mininet I'm seeing similar = overall behavior to that shown in the paper. However, when a flow = enters, I see its CWND overshoot (by double what it should be) and = results in large SRTTs, until the buffer is switch bottleneck buffer has = drained. >=20 > Even if the first ECE flag seen by Linux DCTCP was at the beginning of = its observation window, causing it to not update ALPHA until the end of = the window, I would have thought SSTHRESH would have been immediately = set to at most CWND (or halved, considering that the initial ALPHA is = zero). But I don't think that is what I'm seeing. >=20 > I added the following logic into the update alpha code, and it did = force DCTCP to exit immediately: >=20 > if (flags & CA_ACK_ECE) { > if (ca->acked_bytes_ecn =3D=3D 0 && tcp_in_slow_start(tp)) > tp->snd_ssthresh =3D tp->snd_cwnd; > ... >=20 > So CWND did not overshoot and tail latencies were dramatically = reduced. Unfortunately, it also reduces aggregate goodput somewhat. In = my Mininet experiments, the unmodified DCTCP's normalized utilization = ranged ~0.78 to ~0.83, whereas the early exit modification resulted in = ~0.73 to ~0.81. >=20 > I can provide more details and graphs, if necessary. >=20 > Is there better logic for slow start exit than the above? I also tried = checking just tcp_in_slow_start(tp) and that hurt goodput much more. >=20 > Regardless of whether someone wants to optimize for goodput or = latency, I think that it would be good to address the subject. I don=E2=80=99t know the DCTCP code well enough to fully understand your = change, but you do seem to suggest that, upon an ECN mark in SS, CWND = should be halved, and I think that=E2=80=99s the root of the problem. In SS, when getting an ECN mark from a shallow queue, whether you have = overshot by a little bit or by almost a BDP is a matter of luck - e.g., = for only one flow, it depends on how its cwnd aligns with the path BDP. We have seen this problem when we developed our ABE proposal ( = draft-khademi-alternativebackoff-ecn ) and addressed it by applying a = less dramatic back-off (in ABE, a fixed value) also at the end of slow = start. This is explained in the subsection =E2=80=9CABE in Slow Start=E2=80=9D = on page 5 of = http://heim.ifi.uio.no/michawe/research/publications/CAIA-TR-150710A.pdf = and, in particular, Figure 6. According to our understanding, =E2=80=9Capply a less dramatic back-off = at the end of slow start=E2=80=9D doesn=E2=80=99t need to be said: the = cwnd reaction upon the first loss or mark should already be CA=E2=80=99s, = right? So, to me, the worrying part is this note in your text above: "(or = halved, considering that the initial ALPHA is zero)=E2=80=9D. Maybe the = initial ALPHA in CA should then be changed. Cheers, Michael --Apple-Mail=_0134ABEE-E7FC-420A-B2E2-006567E1E531 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On = 25. jan. 2016, at 22.02, Andrew Shewmaker <agshew@gmail.com> = wrote:

Hi,

Does DCTCP's exit from = slow start need to be addressed in the Internet-Draft?

I did see item 8 from = https://www.ietf.org/mail-archive/web/iccrg/current/msg01215.ht= ml 

"[Not discussed in the meeting, but added by Bob = B for the record]: Less drastic exit from slow-start, to match less = drastic rate reduction per mark.
Currently, because marking threshold is shallow, = slow start exits earlier than with drop, unnecessarily increasing = completion time."

But I haven't seen any = later discussion archived. I didn't see anything in sections 3.3 = Processing Congestion Indications on the Sender or 4 Implementation = Issues. Perhaps I missed it?

In experiments with Linux = DCTCP I've noticed interesting slow start behavior. In a five flow = convergence test in Mininet I'm seeing similar overall behavior to that = shown in the paper. However, when a flow enters, I see its CWND = overshoot (by double what it should be) and results in large SRTTs, = until the buffer is switch bottleneck buffer has drained.

Even if the first ECE = flag seen by Linux DCTCP was at the beginning of its observation window, = causing it to not update ALPHA until the end of the window, I would have = thought SSTHRESH would have been immediately set to at most CWND (or = halved, considering that the initial ALPHA is zero). But I don't think = that is what I'm seeing.

I added the following = logic into the update alpha code, and it did force DCTCP to exit = immediately:

if (flags & = CA_ACK_ECE) {
    if = (ca->acked_bytes_ecn =3D=3D 0 && = tcp_in_slow_start(tp))
      =   tp->snd_ssthresh =3D tp->snd_cwnd;
...

So CWND did not = overshoot and tail latencies were dramatically reduced. Unfortunately, = it also reduces aggregate goodput somewhat. In my Mininet experiments, = the unmodified DCTCP's normalized utilization ranged ~0.78 to = ~0.83, whereas the early exit modification resulted in ~0.73 to = ~0.81.

I can provide more details and graphs, if = necessary.

Is there better logic for slow start exit than = the above? I also tried checking just tcp_in_slow_start(tp) and that = hurt goodput much more.

Regardless of whether = someone wants to optimize for goodput or latency, I think that it would = be good to address the subject.

I don=E2=80=99t know the DCTCP = code well enough to fully understand your change, but you do seem to = suggest that, upon an ECN mark in SS, CWND should be halved, and I think = that=E2=80=99s the root of the problem.
In SS, when = getting an ECN mark from a shallow queue, whether you have overshot by a = little bit or by almost a BDP is a matter of luck - e.g., for only one = flow, it depends on how its cwnd aligns with the path BDP.
We have seen this problem when we developed our ABE proposal = ( draft-khademi-alternativebackoff-ecn ) and addressed it by applying a = less dramatic back-off (in ABE, a fixed value) also at the end of slow = start.
This is explained in the subsection =E2=80=9CA= BE in Slow Start=E2=80=9D on page 5 of http://heim.ifi.uio.no/michawe/research/publications/CAIA-TR-15= 0710A.pdf and, in particular, Figure 6.

According to our understanding, = =E2=80=9Capply a less dramatic back-off at the end of slow start=E2=80=9D = doesn=E2=80=99t need to be said: the cwnd reaction upon the first loss = or mark should already be CA=E2=80=99s, right?

So, to me, the worrying part is this note in your = text above: "(or = halved, considering that the initial ALPHA is zero)=E2=80=9D. =  Maybe the initial ALPHA in CA should then be = changed.

Cheers,
Michael

= --Apple-Mail=_0134ABEE-E7FC-420A-B2E2-006567E1E531-- From nobody Mon Jan 25 16:00:51 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 1F1C21A892F for ; Mon, 25 Jan 2016 16:00:50 -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 xjF0QY8s_4O8 for ; Mon, 25 Jan 2016 16:00:47 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 BCED11A8928 for ; Mon, 25 Jan 2016 16:00:47 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id ba1so131964972obb.3 for ; Mon, 25 Jan 2016 16:00:47 -0800 (PST) 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-type; bh=yI4GHWvfRhzfTHV9p06gVgrm9lwAcwc2n0MxBbEkS7Y=; b=R0nzb6pNS1+95NC4LaS8NfvCZ5nrRfE1Jrf6MMU1m/iT2B8dPQ9F7+nfqbn03E7QHJ v7PZ7/IYwzEhj3NssrO+7NUo5BGe3PcemRMfU5lgM7I8hbayu+gpYiqcwmK8huD6S6ij m1upUwSBxKAVy1sr+m/chbDG6cHMVpmrhuHnytTHGiYziE95C13eNt4pUoQAG+IfsImq 4sSNsr7pBMrpjFIrCw7gJHO63AM8IB5sPI54xmMNkyD2xod0ejfQ05Vdk+BwmqgrnumN zuUxFbehBccnPfbAUFEU3wTb1MJeY6BY1YV/xbnaAxiYGSGeVA9uzkO7kPkn8qniGKJx Xq2Q== 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-type; bh=yI4GHWvfRhzfTHV9p06gVgrm9lwAcwc2n0MxBbEkS7Y=; b=IXVwGW9mdKt+yJlEB1Ld/e+lgvIPlSgWTH47neyrPf8RmSLpwgYxPv3ZXfGLotGu8F DCMAeY46KuiIlaJuaYOkdjLm3DjIaGNHYgG0vi93fKHdkpe6chj9FthpXHf+xw74nCkp /aUArQat4Bb4hoiLE9sZTLXRC4j0+6yEY7trbRpKsTwGMg/iSGdsjaV/X60RM2bnJvL0 O63KwbrmWYPMZXyJtovhNwSJkGsDJBpKCgltD5PBcqHR1KqEwl1oXgcZ2l76qP3VuDuj WZkY+Ta9+xMuZxIq9nCcIWEGv3Oih6NBi42xxfbbQkZtlUl+YiQazHFtBwcprGqyR/9r b2rQ== X-Gm-Message-State: AG10YORj6u+4F558AfuCIf0lOfa4JlPq4LO36OkFuaAKOjxgajNDYy8JmBXJRMowUx8EBL8AwubGmJa1OPoVGg== X-Received: by 10.182.29.70 with SMTP id i6mr15683435obh.73.1453766447009; Mon, 25 Jan 2016 16:00:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.201.144 with HTTP; Mon, 25 Jan 2016 16:00:27 -0800 (PST) In-Reply-To: <3F46BC45-972B-45CC-86D6-9699E36E09A1@ifi.uio.no> References: <20151101233801.27010.85072.idtracker@ietfa.amsl.com> <3F46BC45-972B-45CC-86D6-9699E36E09A1@ifi.uio.no> From: Andrew Shewmaker Date: Mon, 25 Jan 2016 17:00:27 -0700 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=001a11c2017aa915b1052a3160c5 Archived-At: Cc: tcpm IETF list , Dave THALER , Stephen Bensley , Glenn Judd Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-01.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: Tue, 26 Jan 2016 00:00:50 -0000 --001a11c2017aa915b1052a3160c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 25, 2016 at 4:35 PM, Michael Welzl wrote: > I don=E2=80=99t know the DCTCP code well enough to fully understand your = change, > but you do seem to suggest that, upon an ECN mark in SS, CWND should be > halved, and I think that=E2=80=99s the root of the problem. > In SS, when getting an ECN mark from a shallow queue, whether you have > overshot by a little bit or by almost a BDP is a matter of luck - e.g., f= or > only one flow, it depends on how its cwnd aligns with the path BDP. > We have seen this problem when we developed our ABE proposal ( > draft-khademi-alternativebackoff-ecn ) and addressed it by applying a les= s > dramatic back-off (in ABE, a fixed value) also at the end of slow start. > This is explained in the subsection =E2=80=9CABE in Slow Start=E2=80=9D o= n page 5 of > http://heim.ifi.uio.no/michawe/research/publications/CAIA-TR-150710A.pdf > and, in particular, Figure 6. > > According to our understanding, =E2=80=9Capply a less dramatic back-off a= t the end > of slow start=E2=80=9D doesn=E2=80=99t need to be said: the cwnd reaction= upon the first > loss or mark should already be CA=E2=80=99s, right? > > So, to me, the worrying part is this note in your text above: "(or > halved, considering that the initial ALPHA is zero)=E2=80=9D. Maybe the = initial > ALPHA in CA should then be changed. =E2=80=8BHi Michael, Thanks for that link. I'll have to read it more carefully, but that section seems like a nice writeup of the topic. I didn't mean to suggest that the CWND should be halved---I think something like DCTCP's proportional backoff is the way to go. I was trying to say that DCTCP doesn't have to continue doubling its window once it sees an ECE flag. I'm apologize for my lack of clarity. I also made several mistakes when I was describing Linux DCTCP's initial ALPHA. By default it is ALPHA_MAX (although it is a module parameter and can be overridden). If a new flow doesn't see an ECE for several RTTs, then the ALPHA will, of course, have decayed a bit. So, when DCTCP exists slow start it will back off some fraction less than half. The code I added only exits slow start, so DCTCP won't continue doubling its CWND for the rest of the RTT. Then DCTCP will behave as normal, backing off according to congestion ratio ALPHA. Thanks, Andrew --001a11c2017aa915b1052a3160c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Jan 25, 2016 at 4:35 PM, Michael Welzl <michawe@ifi.uio.no>= ; wrote:
I don=E2=80=99t= know the DCTCP code well enough to fully understand your change, but you d= o seem to suggest that, upon an ECN mark in SS, CWND should be halved, and = I think that=E2=80=99s the root of the problem.
In SS, when getti= ng an ECN mark from a shallow queue, whether you have overshot by a little = bit or by almost a BDP is a matter of luck - e.g., for only one flow, it de= pends on how its cwnd aligns with the path BDP.
We have seen this= problem when we developed our ABE proposal ( draft-khademi-alternativeback= off-ecn ) and addressed it by applying a less dramatic back-off (in ABE, a = fixed value) also at the end of slow start.
This is explained in = the subsection =E2=80=9CABE in Slow Start=E2=80=9D on page 5 of=C2=A0http://heim.ifi.uio.no/michawe/research/publications/= CAIA-TR-150710A.pdf and, in particular, Figure 6.

<= div>According to our understanding, =E2=80=9Capply a less dramatic back-off= at the end of slow start=E2=80=9D doesn=E2=80=99t need to be said: the cwn= d reaction upon the first loss or mark should already be CA=E2=80=99s, righ= t?

So, to me, the worrying part is this note in y= our text above: "(or halve= d, considering that the initial ALPHA is zero)=E2=80=9D.=C2=A0 Maybe the in= itial ALPHA in CA=C2=A0should=C2=A0then be changed.

=E2=80=8BHi Micha= el,

Thanks for that link. I'll have to read it mor= e carefully, but that section seems like a nice writeup of the topic.
=

I didn't mean to suggest that the CWND should be halved= ---I think something like DCTCP's proportional backoff is the way to go= . I was trying to say that DCTCP doesn't have to continue doubling its = window once it sees an ECE flag.

I'm apologize for= my lack of clarity. I also made several mistakes when I was describing Lin= ux DCTCP's initial ALPHA. By default it is ALPHA_MAX (although it is a = module parameter and can be overridden). If a new flow doesn't see an E= CE for several RTTs, then the ALPHA will, of course, have decayed a bit. So= , when DCTCP exists slow start it will back off some fraction less than hal= f.

The code I added only exits slow start, so DCTCP wo= n't continue doubling its CWND for the rest of the RTT. Then DCTCP will= behave as normal, backing off according to congestion ratio ALPHA.

Thanks,

Andrew
--001a11c2017aa915b1052a3160c5-- From nobody Tue Jan 26 04:00:00 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 36B651B29B5 for ; Tue, 26 Jan 2016 03:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 EvGDKyRS6RJ4 for ; Tue, 26 Jan 2016 03:59:56 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4EE1B29AF for ; Tue, 26 Jan 2016 03:59:56 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6664FC94BD; Tue, 26 Jan 2016 06:59:51 -0500 (EST) Date: Tue, 26 Jan 2016 06:59:51 -0500 From: John Leslie To: Michael Welzl Message-ID: <20160126115951.GJ2023@verdi> References: <20151101233801.27010.85072.idtracker@ietfa.amsl.com> <3F46BC45-972B-45CC-86D6-9699E36E09A1@ifi.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F46BC45-972B-45CC-86D6-9699E36E09A1@ifi.uio.no> User-Agent: Mutt/1.4.1i Archived-At: Cc: Glenn Judd , tcpm IETF list , Stephen Bensley , Dave THALER Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-01.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: Tue, 26 Jan 2016 11:59:58 -0000 Michael Welzl wrote: > > In SS, when getting an ECN mark from a shallow queue, whether you have > overshot by a little bit or by almost a BDP is a matter of luck - > e.g., for only one flow, it depends on how its cwnd aligns with the path > BDP. I believe it's more deterministic than that (given the usual ceteris parabus disclaimer ;). The combination of sender&receiver can know RTT quite accurately. The sender should know at what rate it was sending one RTT ago. Thus, at the receipt of the first ECE, the sender knows the "safe" sending rate one RTT ago; and, ceteris parabus, that is the sending rate that deserves to be considered "safe" going forward. > We have seen this problem when we developed our ABE proposal > ( draft-khademi-alternativebackoff-ecn ) and addressed it by applying > a less dramatic back-off (in ABE, a fixed value) also at the end of > slow start. The important point is to stop (or at least greatly reduce) probing for more bandwidth until at least one RTT later, since by definition the sender cannot know whether a packet it sends encounters congestion until one full RTT after sending it. -- John Leslie From nobody Tue Jan 26 04:11:12 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 9767B1B29DD for ; Tue, 26 Jan 2016 04:11:11 -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, RP_MATCHES_RCVD=-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 orWt5fyAHz-E for ; Tue, 26 Jan 2016 04:11:10 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 0A8B81B29DC for ; Tue, 26 Jan 2016 04:11:10 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aO2Sh-0006yH-Tt; Tue, 26 Jan 2016 13:11:07 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aO2Sh-0007uh-Bc; Tue, 26 Jan 2016 13:11:07 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <20160126115951.GJ2023@verdi> Date: Tue, 26 Jan 2016 13:11:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151101233801.27010.85072.idtracker@ietfa.amsl.com> <3F46BC45-972B-45CC-86D6-9699E36E09A1@ifi.uio.no> <20160126115951.GJ2023@verdi> To: John Leslie X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 13 sum msgs/h 4 total rcpts 37524 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.048, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 06175C1C1A8AC8595F1F8AFE67C8A43CF9F08AB5 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 8990 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Glenn Judd , tcpm IETF list , Stephen Bensley , Dave THALER Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-01.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: Tue, 26 Jan 2016 12:11:11 -0000 > On 26 Jan 2016, at 12:59, John Leslie wrote: >=20 > Michael Welzl wrote: >>=20 >> In SS, when getting an ECN mark from a shallow queue, whether you = have >> overshot by a little bit or by almost a BDP is a matter of luck - >> e.g., for only one flow, it depends on how its cwnd aligns with the = path >> BDP. >=20 > I believe it's more deterministic than that (given the usual ceteris > parabus disclaimer ;). >=20 > The combination of sender&receiver can know RTT quite accurately. = The > sender should know at what rate it was sending one RTT ago. >=20 > Thus, at the receipt of the first ECE, the sender knows the "safe" > sending rate one RTT ago; and, ceteris parabus, that is the sending = rate > that deserves to be considered "safe" going forward. I talked about the amount of overshoot, not what the previous "safe" = rate was. First, about overshoot: Note, I mean the capacity limit, not capacity + = queue. Say, you ECN-mark using immediate marking, as soon as the queue grows. = Then your mark occurs just after you've exceeded the capacity limit. If you start with 10 packets, and the BDP of the path equals e.g. 39 = packets, then you've only overshot by 1 packet. If however the BDP of the path is e.g. 40 packets, the next round you've = sent 80, so overshot by 40, and you'd get a mark for the first of them. That's what I meant. About the "safe" rate, yes, halving is the only 100% "safe" way, but = it's often way too little whenever you receive a mark or experience a = loss at a queue that's less than a BDP. When it wasn't loss but ECN, it may be more reasonable to back off by = less - note that, in case you really didn't back off enough, you = immediately get another ECN-mark anyway, so within a few rounds you'll = definitely empty the queue. (with DCTCP, this shouldn't really be a few rounds - as is the case with = our ABE proposal - but proportionally reducing should in fact put you = right down to the right value) >> We have seen this problem when we developed our ABE proposal >> ( draft-khademi-alternativebackoff-ecn ) and addressed it by applying >> a less dramatic back-off (in ABE, a fixed value) also at the end of >> slow start. >=20 > The important point is to stop (or at least greatly reduce) probing > for more bandwidth until at least one RTT later, since by definition = the > sender cannot know whether a packet it sends encounters congestion = until > one full RTT after sending it. Sure. This means that once you saw the first ECN mark you've already sent too = much, and - depending on where in the burst the ECN-mark appeared - = possibly *way* too much. Thus stopping to increase immediately upon = getting an ECN mark (which, if I got this right, is what Andrew's code = now does) sounds exactly right. Cheers, Michael From nobody Tue Jan 26 04:13:53 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 B3E9F1B2CD3 for ; Tue, 26 Jan 2016 04:13:51 -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, RP_MATCHES_RCVD=-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 sSbqwZQebWou for ; Tue, 26 Jan 2016 04:13:49 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 EE09B1B2CD1 for ; Tue, 26 Jan 2016 04:13:45 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aO2Ut-0007NT-9F; Tue, 26 Jan 2016 13:13:23 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aO2Us-0007qb-LL; Tue, 26 Jan 2016 13:13:23 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Tue, 26 Jan 2016 13:13:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0DD06E24-1525-4A21-9123-BE73B9153442@ifi.uio.no> References: <20151101233801.27010.85072.idtracker@ietfa.amsl.com> <3F46BC45-972B-45CC-86D6-9699E36E09A1@ifi.uio.no> To: Andrew Shewmaker X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 14 msgs/h 2 sum rcpts/h 21 sum msgs/h 5 total rcpts 37532 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.048, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AD026263C0E163BAAAF97ACB3C6644A0E8CEB313 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 8991 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tcpm IETF list , Dave THALER , Stephen Bensley , Glenn Judd Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-01.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: Tue, 26 Jan 2016 12:13:51 -0000 > On 26 Jan 2016, at 01:00, Andrew Shewmaker wrote: >=20 >=20 > On Mon, Jan 25, 2016 at 4:35 PM, Michael Welzl = wrote: > I don=E2=80=99t know the DCTCP code well enough to fully understand = your change, but you do seem to suggest that, upon an ECN mark in SS, = CWND should be halved, and I think that=E2=80=99s the root of the = problem. > In SS, when getting an ECN mark from a shallow queue, whether you have = overshot by a little bit or by almost a BDP is a matter of luck - e.g., = for only one flow, it depends on how its cwnd aligns with the path BDP. > We have seen this problem when we developed our ABE proposal ( = draft-khademi-alternativebackoff-ecn ) and addressed it by applying a = less dramatic back-off (in ABE, a fixed value) also at the end of slow = start. > This is explained in the subsection =E2=80=9CABE in Slow Start=E2=80=9D = on page 5 of = http://heim.ifi.uio.no/michawe/research/publications/CAIA-TR-150710A.pdf = and, in particular, Figure 6. >=20 > According to our understanding, =E2=80=9Capply a less dramatic = back-off at the end of slow start=E2=80=9D doesn=E2=80=99t need to be = said: the cwnd reaction upon the first loss or mark should already be = CA=E2=80=99s, right? >=20 > So, to me, the worrying part is this note in your text above: "(or = halved, considering that the initial ALPHA is zero)=E2=80=9D. Maybe the = initial ALPHA in CA should then be changed. >=20 > =E2=80=8BHi Michael, >=20 > Thanks for that link. I'll have to read it more carefully, but that = section seems like a nice writeup of the topic. >=20 > I didn't mean to suggest that the CWND should be halved---I think = something like DCTCP's proportional backoff is the way to go. Agreed; it didn't sound like you suggested it should be, but it sounded = like that's what's currently happening because of the initial ALPHA = value > I was trying to say that DCTCP doesn't have to continue doubling its = window once it sees an ECE flag. >=20 > I'm apologize for my lack of clarity. I also made several mistakes = when I was describing Linux DCTCP's initial ALPHA. By default it is = ALPHA_MAX (although it is a module parameter and can be overridden). If = a new flow doesn't see an ECE for several RTTs, then the ALPHA will, of = course, have decayed a bit. So, when DCTCP exists slow start it will = back off some fraction less than half. That seems better then (but what, then, produces the loss in throughput = that you described?) > The code I added only exits slow start, so DCTCP won't continue = doubling its CWND for the rest of the RTT. Then DCTCP will behave as = normal, backing off according to congestion ratio ALPHA. and that seems good too Cheers, Michael From nobody Tue Jan 26 06:15:22 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 022021A903B for ; Tue, 26 Jan 2016 06:15:20 -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 p78rBSNWd4ZS for ; Tue, 26 Jan 2016 06:15:18 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 AE7B71A9039 for ; Tue, 26 Jan 2016 06:15:18 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id 65so12001638pfd.2 for ; Tue, 26 Jan 2016 06:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=FkGuNZBz/GJ19kV4cVkTCNPRCa/KuFyMGeIzkaPfaKU=; b=rE+SGY6IPSlfShf3YqHZu/As02gcHd9AAg6Evay9da3ukyV1FMSCkWHMUJHw8LfBxb 5zvLrhnM5VGaHkU+76oXAuYEw1xa7PDuzQpjDG4qFIjfc81t0MdYbLAD0AEpCi2uiEl7 ET+wAUFcUwhmDzMEiIXGK35sPoMa28S7TtrJp0Ru9SH8nzjVFewobxiA9/gsmbLhnVZh F+qsiB0i66t5eujhmctDBk2ciENLW0jlqkTsRiYfgsOL/MVMkjU3uHaHpknno1HxN0lE O/dkGN47HuIVsPOgNqY7oIgDpimmyFpJor+vjM5XsfqofpriQd4rSMLTM8M5wOxr0eBX hDnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:mime-version:content-transfer-encoding; bh=FkGuNZBz/GJ19kV4cVkTCNPRCa/KuFyMGeIzkaPfaKU=; b=l1LTlwgN/l/T4lRz4G1LLIg9knHPCCqd/rAAPReiuBo6N0YrHjle52ARDchWyRRRYr VWJF6mLkZdf4nuazJRAaTYhn/mWW40NUjnGn9RZXw/82pbqAV2UTYMfX/dFVsL2XsqT6 ZNFdmlj0wK3bui9mz2ExQ6vvwxwhbNVnNkWLuc5HkkAamtMHJZFd+VvD5Ys9Nqu2vpDm BmwndTrTCxZLF/L3/vmXsHaW2Z+XGeybGN4KVQfqk6l0lNf1aVW3fnEw4cnf0bSKTc8u DAF7yJFDPtD8q8rZWhKRLwWx0PF6GaY8PKlwUDvCBaUibVurMNoCZIHwXURGuTnVNwja sK1g== X-Gm-Message-State: AG10YOT0+XHE9n4+F/VPrEq2iHbJbucukoiQbyXm0fF2bRY4tnts2oL7uybmtMcrmwHtwQ== X-Received: by 10.98.14.209 with SMTP id 78mr33832609pfo.157.1453817718281; Tue, 26 Jan 2016 06:15:18 -0800 (PST) Received: from [172.19.246.212] ([172.19.246.212]) by smtp.gmail.com with ESMTPSA id y76sm2253910pfi.39.2016.01.26.06.15.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 06:15:17 -0800 (PST) Message-ID: <1453817716.11327.15.camel@edumazet-glaptop2.roam.corp.google.com> From: Eric Dumazet To: Sara Dickinson Date: Tue, 26 Jan 2016 06:15:16 -0800 In-Reply-To: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> References: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] Question on TCP Fast Open 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: Tue, 26 Jan 2016 14:15:20 -0000 On Fri, 2016-01-22 at 14:49 +0000, Sara Dickinson wrote: > > Hi, > > > I would like to ask for some clarification on the expected behaviour > of clients when using TCP Fast Open (RFC7413). > > > I’ve observed in inter-op testing of various implementations that > after a successful TFO cookie exchange one client (Linux - Kernel 4.4) > does not acknowledge data sent by the server in the SYN-ACK in > subsequent TFO connections. As a result the server must re-transmit > the data, which introduces a delay. RFC7413 clearly states that the > server ‘MAY’ send data in the SYN-ACK (Section 4.2.2). My question is > for clarification on what clients should do when receiving the SYN-ACK > (also Section 4.2.2) : > > > “ Client: Receiving SYN-ACK > > The client SHOULD perform the following steps upon receiving the SYN- > ACK: > > 1. If the SYN-ACK has a Fast Open option, an MSS option, or both, > update the corresponding cookie and MSS information in the cookie > cache. > > 2. Send an ACK packet. Set acknowledgment number to RCV.NXT and > include the data after SND.UNA if data is available." > > > > I read this as clients SHOULD acknowledge data in the SYN-ACK if it is > present - is that correct? Since this is only a SHOULD what are the > reasons a client may choose not to do that? > > Hi Sara. I implemented the linux patch to accept the payload included in SYNACK message. I would advise a server adds payload in SYNACK only if it has 4+ MSS worth of data to send, so that fast retransmit could repair the damage caused by lack of client support. From nobody Tue Jan 26 10:26:38 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 74A3D1B2A27 for ; Tue, 26 Jan 2016 10:26:36 -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 TY2YNmuTKd1R for ; Tue, 26 Jan 2016 10:26:34 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 477EB1B2A43 for ; Tue, 26 Jan 2016 10:26:27 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id n128so102735617pfn.3 for ; Tue, 26 Jan 2016 10:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=Fe4vTvhftiDjnEjiI4Qvv0TIS5UT1CYVV2OKCkuXPFM=; b=A07UV96GM6oYpE7ENHGjTNSK4Xvxi2F/HIHYYn1eT/Zj9bcIuGTdfXclgx6m7PC0De U+DDfxEuBkbfuK9r30agsxIbyL4fRqDyDTSOOnmnJ7HVrmmrXgAmF1eqXyU7WZAz/4mD bmh+UsWCuDz+13qqaMe/a9gI1TWg9svaOXlSSEk1LR7BqNT5OaSfqpC7MYCHdEnQKRDo fdtt75MN1jNGLIkbtBZmdRdWbMoyQRF7XbPBfWBHbblTsQfW4MHeSUHP9MXsa4amzqPw 1+ElzZa+CU9Pb+8k8HoMfFPKtIJ/53e0sgfxDc4l5fsIv8q289qMM89tCddZfYxiIyLm EqKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:mime-version:content-transfer-encoding; bh=Fe4vTvhftiDjnEjiI4Qvv0TIS5UT1CYVV2OKCkuXPFM=; b=k0sQaIXQRjzLL2pT6tNvELh0CGSJfkc5jS+/H85Afy9ZJjQHcq36q3tTlRa+mXSTCn qTfcKWpIbrVU8E7okbl+P1icEnYljgi9YUsvsHvR1QdcfhKyvdxkw2jHMdth7h2zHYn1 eTSmZ9/QkwN7t9NZM1yTOg6NJRL21ySAGWg4AbDAg3foymqtzUxH3ej8h0Iu/zjzxmxv HHpkGKE0gmcxSN+Y/pD3h3a0sQHDnGbUxa44FpKXQaJaePYv9ughQV+7/5Zb5NI7e/RN guKNDPZc0pQUkcFwSSu+OG75crfsfb0hswiqaimJZIxrDV9cTIgIPIzsh/ZUr/cn1nP9 8D9g== X-Gm-Message-State: AG10YOT0XDbLt0/1WTnwGxCdyFAA1fzA/+lVK+8NvQjnH1ut4kF8KwCGnvRdFnh0hcVA5A== X-Received: by 10.98.14.80 with SMTP id w77mr36111534pfi.152.1453832786663; Tue, 26 Jan 2016 10:26:26 -0800 (PST) Received: from ?IPv6:2620:0:1000:3e02:10ff:8953:6a5e:8215? ([2620:0:1000:3e02:10ff:8953:6a5e:8215]) by smtp.gmail.com with ESMTPSA id o67sm3346438pfa.58.2016.01.26.10.26.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 10:26:25 -0800 (PST) Message-ID: <1453832784.11327.36.camel@edumazet-glaptop2.roam.corp.google.com> From: Eric Dumazet To: Sara Dickinson Date: Tue, 26 Jan 2016 10:26:24 -0800 In-Reply-To: <1453817716.11327.15.camel@edumazet-glaptop2.roam.corp.google.com> References: <02DC876E-218E-41D0-811E-37FDA40FF7EB@sinodun.com> <1453817716.11327.15.camel@edumazet-glaptop2.roam.corp.google.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] Question on TCP Fast Open 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: Tue, 26 Jan 2016 18:26:36 -0000 On Tue, 2016-01-26 at 06:15 -0800, Eric Dumazet wrote: > I would advise a server adds payload in SYNACK only if it has 4+ MSS > worth of data to send, so that fast retransmit could repair the damage > caused by lack of client support. Or, when server receives the ACK packet coming from client, it can immediately tell if the SYN-ACK payload was acked or not. If not -> immediately send the data that was in the SYN-ACK, without waiting for a timeout. From nobody Fri Jan 29 06:14:06 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 10D781ACDF8 for ; Fri, 29 Jan 2016 06:14:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160129141404.4500.69287.idtracker@ietfa.amsl.com> Date: Fri, 29 Jan 2016 06:14:04 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG 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: Fri, 29 Jan 2016 14:14:04 -0000 Changed milestone "Submit document on Retransmission Timeout Considerations as Best Current Practice RFC", set state to active from review, accepting new milestone. Changed milestone "Submit specification of more accurate ECN feedback in TCP to the IESG for publication as an Experimental RFC", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/tcpm/charter/