From Michael.Scharf@alcatel-lucent.com Thu Mar 1 01:18:51 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1424721F8681 for ; Thu, 1 Mar 2012 01:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKE6jiu9x5N3 for ; Thu, 1 Mar 2012 01:18:50 -0800 (PST) Received: from mailrelay1.alcatel.de (mailrelay1.alcatel.de [194.113.59.95]) by ietfa.amsl.com (Postfix) with ESMTP id 6578921F8687 for ; Thu, 1 Mar 2012 01:18:49 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay1.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id q219IXNP015070; Thu, 1 Mar 2012 10:18:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 10:15:10 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C06E03485@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Removal of TCPM milestone on security hardening Thread-Index: Acz3i80TYrK1cn59QEG4rwdYqWnYBQ== From: "SCHARF, Michael" To: "Fernando Gont" X-Scanned-By: MIMEDefang 2.69 on 149.204.45.72 Cc: tcpm@ietf.org Subject: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 09:18:51 -0000 Fernando, The document draft-ietf-tcpm-tcp-security expired more than half a year ago, and given that lack of progress, it has been suggested several times to remove the corresponding milestone from the TCPM charter: Aug 2010 Submit document on security hardening of TCP implementations to the IESG for publication as a Best Current Practices RFC Unfortunately, it seems to be quite apparent that TCPM cannot meet this milestone due to lack of progress and consensus on the document scope. Therefore, the chairs will ask for removal of that milestone before the Paris meeting, unless another solution for addressing that milestone is found in the next two weeks. I personally think that a document on security hardening would be very valuable, but we need TCPM consensus on the scope first. Best regards Michael (TCPM co-chair) From ananth@cisco.com Thu Mar 1 11:30:31 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5727621E8252 for ; Thu, 1 Mar 2012 11:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.874 X-Spam-Level: X-Spam-Status: No, score=-8.874 tagged_above=-999 required=5 tests=[AWL=1.725, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yVb8067awxS for ; Thu, 1 Mar 2012 11:30:30 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C5DC221E8093 for ; Thu, 1 Mar 2012 11:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=472; q=dns/txt; s=iport; t=1330630230; x=1331839830; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1ZPWztuK0qTQem84nl23RYM1xFRup7DpgHofJ7PDXqs=; b=Qw/6ixlgLXfgX+C+JSBzKEfd3FCKAK/T9VCxsPI4oEih3rRcKXuFCRWd NO84IuibemWot6fogho2nJy5FXeIFFgMC+ncBRVdyODuDP4A1FZfSyH6H YZJHrEUPViq3W3mcnHmFpLlstW/BIOaDVKZnWaagaa193Hr95ZTiAmZkx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFvNT0+rRDoH/2dsb2JhbABDtBCBB4F9AQEBAwEBAQEPAR0KNAsFCwIBCCIGGAYBJjABAQQBEggah18EAQugSQGWfwSNGxYCRBEDAwECAoRBBWADBwYNARgGGoJNYwSIT59/ X-IronPort-AV: E=Sophos;i="4.73,512,1325462400"; d="scan'208";a="33813833" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 01 Mar 2012 19:30:30 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q21JUUXL007701; Thu, 1 Mar 2012 19:30:30 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 11:30:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 11:30:29 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580E99564A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C06E03485@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Removal of TCPM milestone on security hardening Thread-Index: Acz3i80TYrK1cn59QEG4rwdYqWnYBQAVSr4Q References: <133D9897FB9C5E4E9DF2779DC91E947C06E03485@SLFSNX.rcs.alcatel-research.de> From: "Anantha Ramaiah (ananth)" To: "SCHARF, Michael" , "Fernando Gont" X-OriginalArrivalTime: 01 Mar 2012 19:30:30.0529 (UTC) FILETIME=[C36CC710:01CCF7E1] Cc: tcpm@ietf.org Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 19:30:31 -0000 > I personally think that a document on security hardening would be very > valuable, but we need TCPM consensus on the scope first. +1 on security hardening for TCP. I haven't looked into the latest document, but I would think the scope can be worked out.=20 -Anantha >=20 > Best regards >=20 > Michael (TCPM co-chair) > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mjethanandani@gmail.com Fri Mar 2 07:31:39 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4BB21F85F6 for ; Fri, 2 Mar 2012 07:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzZTVTLdQ4R9 for ; Fri, 2 Mar 2012 07:31:38 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9A721F85F1 for ; Fri, 2 Mar 2012 07:31:38 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so446871pbb.31 for ; Fri, 02 Mar 2012 07:31:38 -0800 (PST) Received-SPF: pass (google.com: domain of mjethanandani@gmail.com designates 10.68.220.67 as permitted sender) client-ip=10.68.220.67; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mjethanandani@gmail.com designates 10.68.220.67 as permitted sender) smtp.mail=mjethanandani@gmail.com; dkim=pass header.i=mjethanandani@gmail.com Received: from mr.google.com ([10.68.220.67]) by 10.68.220.67 with SMTP id pu3mr17305277pbc.61.1330702298537 (num_hops = 1); Fri, 02 Mar 2012 07:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=mfSfv2TNDmNtvPViqeVA+LGeZPEmOcwVizCp6RcBbvw=; b=RzUYyQvZ9hxLX1a4fdJw03IpG6pZtjbRV7G7CluA97/To05XjWl7BM5jl3AqWPhS2T z1E0OSpIhybPA3g3mVqM4wkacxEQjZ41WVjNqkYTZsrd1XfIhtNsjs1tq9g7wCa0sVcw yjAZtaR6KyG1tJo8vmenK3rl13KRayeubb544e+Vz+b3AF9ffgXHtYudu7Fpds9AO/5W Uvr7NuUjOkjCNxjVL3KomxaAIU5MhKEGQ8jPXjgHe4ZQffcoZvF8/hMYsm8UG8NFwGV4 lslo0RqosOM7r2WoWJtbEKCIc23ldg2waGZwMUaYz47QDdFif15hAVkJLvIMU4Cma4L2 pdww== Received: by 10.68.220.67 with SMTP id pu3mr14452710pbc.61.1330702298501; Fri, 02 Mar 2012 07:31:38 -0800 (PST) Received: from [192.168.1.131] (c-24-6-173-225.hsd1.ca.comcast.net. [24.6.173.225]) by mx.google.com with ESMTPS id b6sm5270770pbf.32.2012.03.02.07.31.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Mar 2012 07:31:36 -0800 (PST) References: <133D9897FB9C5E4E9DF2779DC91E947C06E03485@SLFSNX.rcs.alcatel-research.de> <0C53DCFB700D144284A584F54711EC580E99564A@xmb-sjc-21c.amer.cisco.com> From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (9A405) In-Reply-To: <0C53DCFB700D144284A584F54711EC580E99564A@xmb-sjc-21c.amer.cisco.com> Message-Id: <4B2190D4-B057-4027-A7A4-45F1AE59CE54@gmail.com> Date: Fri, 2 Mar 2012 07:31:35 -0800 To: "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 15:31:39 -0000 +1 On Mar 1, 2012, at 11:30 AM, "Anantha Ramaiah (ananth)" w= rote: >=20 >> I personally think that a document on security hardening would be very >> valuable, but we need TCPM consensus on the scope first. >=20 > +1 on security hardening for TCP. I haven't looked into the latest > document, but I would think the scope can be worked out.=20 >=20 > -Anantha >=20 >>=20 >> Best regards >>=20 >> Michael (TCPM co-chair) >> _______________________________________________ >> 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 mallman@icir.org Fri Mar 2 07:35:22 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88AB21F863F for ; Fri, 2 Mar 2012 07:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.445 X-Spam-Level: X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeZw9j1PlBpg for ; Fri, 2 Mar 2012 07:35:22 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7811C21F8642 for ; Fri, 2 Mar 2012 07:35: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 q22FZFUC001882; Fri, 2 Mar 2012 07:35:15 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5E7D6BE43D5; Fri, 2 Mar 2012 10:35:15 -0500 (EST) To: "Anantha Ramaiah (ananth)" From: Mark Allman In-Reply-To: <0C53DCFB700D144284A584F54711EC580E99564A@xmb-sjc-21c.amer.cisco.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Friend Of The Devil X-URL-0: http://www.icir.org/mallman-files/Document50631.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma59568-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 02 Mar 2012 10:35:15 -0500 Sender: mallman@icir.org Message-Id: <20120302153515.5E7D6BE43D5@lawyers.icir.org> Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:35:23 -0000 ----------ma59568-1 Content-Type: text/plain Content-Disposition: inline > > I personally think that a document on security hardening would be very > > valuable, but we need TCPM consensus on the scope first. > > +1 on security hardening for TCP. We should absolutely harden TCP in places where it is vulnerable. But, this document is a large mess of a way to go about it (as I have previously argued). We should let it die and pick up the useful pieces. allman ----------ma59568-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk9Q6LIACgkQWyrrWs4yIs4o9wCfVw+kAxGDMhy5JnoM97X9eXqc UVIAn26eFXTP5ID0ckQBfzimXS/a2z5a =5gqt -----END PGP SIGNATURE----- ----------ma59568-1-- From faber@isi.edu Fri Mar 2 09:30:33 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27C421F86B9 for ; Fri, 2 Mar 2012 09:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZJQX+IQ1UYr for ; Fri, 2 Mar 2012 09:30:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E011C21F86B3 for ; Fri, 2 Mar 2012 09:30:32 -0800 (PST) Received: from vim.isi.edu (vim.isi.edu [128.9.168.184]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q22HUBJH029897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Mar 2012 09:30:12 -0800 (PST) Date: Fri, 2 Mar 2012 09:30:11 -0800 From: Ted Faber To: Mark Allman Message-ID: <20120302173010.GC71443@vim.isi.edu> References: <0C53DCFB700D144284A584F54711EC580E99564A@xmb-sjc-21c.amer.cisco.com> <20120302153515.5E7D6BE43D5@lawyers.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rQ2U398070+RC21q" Content-Disposition: inline In-Reply-To: <20120302153515.5E7D6BE43D5@lawyers.icir.org> X-url: http://www.isi.edu/~faber User-Agent: Mutt/1.5.21 (2010-09-15) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 17:30:34 -0000 --rQ2U398070+RC21q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 02, 2012 at 10:35:15AM -0500, Mark Allman wrote: >=20 > > > I personally think that a document on security hardening would be very > > > valuable, but we need TCPM consensus on the scope first. > >=20 > > +1 on security hardening for TCP. =20 >=20 > We should absolutely harden TCP in places where it is vulnerable. >=20 > But, this document is a large mess of a way to go about it (as I have > previously argued). We should let it die and pick up the useful pieces. As is often the case, Mark is talking sense and I agree with him. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --rQ2U398070+RC21q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9RA6IACgkQaUz3f+Zf+XteWgCeNCcln0i4KFjSqacweBLcqg6d g0cAoLjR2YiSJfxAFfdGEPO38FjwFTV2 =e9g6 -----END PGP SIGNATURE----- --rQ2U398070+RC21q-- From ananth@cisco.com Fri Mar 2 11:27:08 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABFF21E8063 for ; Fri, 2 Mar 2012 11:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.066 X-Spam-Level: X-Spam-Status: No, score=-9.066 tagged_above=-999 required=5 tests=[AWL=1.533, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJHD1HLlLtpW for ; Fri, 2 Mar 2012 11:27:07 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAC521E8019 for ; Fri, 2 Mar 2012 11:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=1295; q=dns/txt; s=iport; t=1330716427; x=1331926027; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=LLV6jYWheg7l2i4fKUvCZfr2a2Ok5zQRrAvVUILVVh4=; b=jMiXXEMFCBVs+AeFVRdL7W/cjZ1ZVvWqpDWkCYpL5WWMJXaY827VOso5 wwjqnHpJs0OPmS4GDFIfI+ABIXFPP2tzqy/Vb385rdMeJNFpNdfJGTZnO YL/AA/KSODL4hhWA4SwQCRPlkXtV6aX/zlF8kpCILyl8hX9eRHl5VRthC I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMAdUU+rRDoI/2dsb2JhbABDtEaBB4F9AQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAQEEEwgah2MBoQUBlySMQoI/YwSIUKAEgTUX X-IronPort-AV: E=Sophos;i="4.73,519,1325462400"; d="scan'208";a="31643060" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 02 Mar 2012 19:27:03 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q22JR3hn006804; Fri, 2 Mar 2012 19:27:03 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 11:27:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Mar 2012 11:27:01 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580EA2169F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20120302153515.5E7D6BE43D5@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Removal of TCPM milestone on security hardening Thread-Index: Acz4ihhLumpPrzSgQ2GQwBgF6CFwlAAH2UGQ References: <0C53DCFB700D144284A584F54711EC580E99564A@xmb-sjc-21c.amer.cisco.com> <20120302153515.5E7D6BE43D5@lawyers.icir.org> From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 02 Mar 2012 19:27:03.0207 (UTC) FILETIME=[7243B370:01CCF8AA] Cc: tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 19:27:08 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Mark Allman > Sent: Friday, March 02, 2012 7:35 AM > To: Anantha Ramaiah (ananth) > Cc: tcpm@ietf.org; Fernando Gont > Subject: Re: [tcpm] Removal of TCPM milestone on security hardening >=20 >=20 > > > I personally think that a document on security hardening would be > > > very valuable, but we need TCPM consensus on the scope first. > > > > +1 on security hardening for TCP. >=20 > We should absolutely harden TCP in places where it is vulnerable. >=20 > But, this document is a large mess of a way to go about it (as I have > previously argued). We should let it die and pick up the useful > pieces. I am not sure about the procedure. This document does contain hardening measures recommended for TCP, therefore I would think it is worth pursuing it. OTOH, there are so many things (IMO) that need to be yanked out of the document like some validation etc., which belongs to implementation guidance sort of document in some sense. Maybe one way is to write a fresh ID that covers only the hardening aspects OR remove the gunk from the document and re-structure it. I don't know. I'll let chairs chime in.... -Anantha >=20 > allman >=20 >=20 From mjethanandani@gmail.com Fri Mar 2 11:29:48 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCB821F84F1 for ; Fri, 2 Mar 2012 11:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1enXD2PLvvh for ; Fri, 2 Mar 2012 11:29:47 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD6121F84EB for ; Fri, 2 Mar 2012 11:29:33 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so664708pbb.31 for ; Fri, 02 Mar 2012 11:29:33 -0800 (PST) Received-SPF: pass (google.com: domain of mjethanandani@gmail.com designates 10.68.136.71 as permitted sender) client-ip=10.68.136.71; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mjethanandani@gmail.com designates 10.68.136.71 as permitted sender) smtp.mail=mjethanandani@gmail.com; dkim=pass header.i=mjethanandani@gmail.com Received: from mr.google.com ([10.68.136.71]) by 10.68.136.71 with SMTP id py7mr20173019pbb.76.1330716573546 (num_hops = 1); Fri, 02 Mar 2012 11:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=OOVjIxMDkbWF1ZTcML++C33YqSEHzD7ZAu6qQkX8pE0=; b=fNcCyVnLa0HxbinM6qmjzV1NXra8cG1AKiNV4PAisqp8dHWf9MKVftIzXojvxJ7TvY PXC7T7VfSxJKZL8ipDX9tSIR09dNwfZwwqf110EK/GkQw/ZuzA7vklPGBFBORqEs07JP HXFsNgw69gX9bq3/oq9wL/f0kM0ee6HnqZ1XWub3vkzzTs60ZyD/O8WqcS17iFw9MP7Z jEwa/HQMOQjQnPpwXJZkBsosCLFLieaxEZlzkqUOO5J1tVeqeu0ROpKch5CbfWIKSlN/ G2NsnK2IdKkv6enDP6rszr1mWOcpZUui6vElDTN9a7rCy92AFHTydLl0oLxpp+obLQA3 XVSg== Received: by 10.68.136.71 with SMTP id py7mr16834169pbb.76.1330716573476; Fri, 02 Mar 2012 11:29:33 -0800 (PST) Received: from [192.168.1.123] (c-24-6-173-225.hsd1.ca.comcast.net. [24.6.173.225]) by mx.google.com with ESMTPS id l1sm5712863pbe.54.2012.03.02.11.29.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Mar 2012 11:29:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-222051592 From: Mahesh Jethanandani In-Reply-To: <20120302173010.GC71443@vim.isi.edu> Date: Fri, 2 Mar 2012 11:29:29 -0800 Message-Id: <8F4B45BA-EE71-4DB6-8D23-9F0D55A57FE4@gmail.com> References: <0C53DCFB700D144284A584F54711EC580E99564A@xmb-sjc-21c.amer.cisco.com> <20120302153515.5E7D6BE43D5@lawyers.icir.org> <20120302173010.GC71443@vim.isi.edu> To: Ted Faber X-Mailer: Apple Mail (2.1084) Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont , Mark Allman Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 19:29:48 -0000 --Apple-Mail-2-222051592 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It is not that I disagree with what Mark is saying, but the tcpm group = has done little to help or guide Fernando on the draft either. Dropping = the draft and picking up the necessary pieces is fine if there is a plan = for how to go about it. We can derive some hints from the way other groups go about a topic that = is large and wieldy. In this particular case, how about we split the = work into: - What are the security vulnerabilities are (and what we want to focus = on) and what the ideal state should be. - Solutions/suggestions/BCP on those vulnerabilities.=20 The second part could be one or more drafts. On Mar 2, 2012, at 9:30 AM, Ted Faber wrote: > As is often the case, Mark is talking sense and I agree with him. --Apple-Mail-2-222051592 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It is = not that I disagree with what Mark is saying, but the tcpm group has = done little to help or guide Fernando on the draft either. Dropping the = draft and picking up the necessary pieces is fine if there is a plan for = how to go about it.

We can derive some hints from the = way other groups go about a topic that is large and wieldy. In this = particular case, how about we split the work = into:

- What are the security vulnerabilities = are (and what we want to focus on) and what the ideal state should = be.
- Solutions/suggestions/BCP on those = vulnerabilities. 

The second part could be = one or more drafts.

On Mar 2, 2012, at 9:30 AM, = Ted Faber wrote:

As is often = the case, Mark is talking sense and I agree with = him.

= --Apple-Mail-2-222051592-- From mallman@icir.org Fri Mar 2 12:10:02 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B5121E801E for ; Fri, 2 Mar 2012 12:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.464 X-Spam-Level: X-Spam-Status: No, score=-106.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCupkfzTLTEe for ; Fri, 2 Mar 2012 12:10:02 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id BFFF621E8019 for ; Fri, 2 Mar 2012 12:10:01 -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 q22K9pjD006283; Fri, 2 Mar 2012 12:09:51 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id EBE13C147B2; Fri, 2 Mar 2012 15:09:50 -0500 (EST) To: Mahesh Jethanandani From: Mark Allman In-Reply-To: <8F4B45BA-EE71-4DB6-8D23-9F0D55A57FE4@gmail.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Friend Of The Devil X-URL-0: http://www.icir.org/mallman-files/Document30327.jpg MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma10510-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 02 Mar 2012 15:09:50 -0500 Sender: mallman@icir.org Message-Id: <20120302200950.EBE13C147B2@lawyers.icir.org> Cc: "Anantha Ramaiah \(ananth\)" , tcpm@ietf.org, Ted Faber , Fernando Gont Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 20:10:02 -0000 ----------ma10510-1 Content-Type: text/plain Content-Disposition: inline > It is not that I disagree with what Mark is saying, but the tcpm group > has done little to help or guide Fernando on the draft > either. Well, look, some of us reviewed it or portions of it. And, Wes and David tried hard to manage this beast and get it moved forward, IMO. The parts I read were simply lots of words with very little in the way of fixing of anything. And, some of us did suggest a way forward here ... and that is instead of a monolithic document that tries to make tweaks to a couple dozen RFCs that we simply update the RFCs in question if there is something to update. Or, in some cases we just actually read what the current RFCs say (e.g., when I read the congestion control section it was talking about an RFC that had been updated by another RFC 18mo prior to when I was reading it!). > Dropping the draft and picking up the necessary pieces is fine if > there is a plan for how to go about it. I think that is the wrong approach. We should drop this document, because (1) it has received a bunch of [legitimate IMO] pushback, (2) it .has proven too big to manage and (3) it hasn't been updated for over a year. Rather than trying to foist a path on Fernando and the WG what we should do is let people who have *energy* for this suggest a path and let the WG consider that path. If people think this is important enough to put *energy* into then it will happen. If people don't, it won't happen. But, we should realize that if there is no energy it isn't going to happen no matter what. allman ----------ma10510-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk9RKQ4ACgkQWyrrWs4yIs5AnACfXKg730uC20NHSRqGRLcwUUFV Sg8AoI2ABuWm4UHII6/I/kTdBKiU7Cjx =8mHe -----END PGP SIGNATURE----- ----------ma10510-1-- From michael.scharf@alcatel-lucent.com Fri Mar 2 13:15:56 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A120A21E805F for ; Fri, 2 Mar 2012 13:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsD7deVLo1MM for ; Fri, 2 Mar 2012 13:15:56 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id DFBCB21E8019 for ; Fri, 2 Mar 2012 13:15:55 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q22LFkPL023220 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 22:15:46 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 2 Mar 2012 22:15:46 +0100 From: "SCHARF, Michael" To: "mallman@icir.org" , Mahesh Jethanandani Date: Fri, 2 Mar 2012 22:15:45 +0100 Thread-Topic: [tcpm] Removal of TCPM milestone on security hardening Thread-Index: Acz4sHe+vgR+XacXTvWfWvmZrUZvLQAA2ubA Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F419@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <8F4B45BA-EE71-4DB6-8D23-9F0D55A57FE4@gmail.com> <20120302200950.EBE13C147B2@lawyers.icir.org> In-Reply-To: <20120302200950.EBE13C147B2@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: Ted Faber , "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , Fernando Gont Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 21:15:56 -0000 > > It is not that I disagree with what Mark is saying, but the=20 > tcpm group=20 > > has done little to help or guide Fernando on the draft either. Mahesh, this statement is not correct. =20 > > Dropping the draft and picking up the necessary pieces is fine if=20 > > there is a plan for how to go about it. >=20 > I think that is the wrong approach. We should drop this=20 > document, because (1) it has received a bunch of [legitimate=20 > IMO] pushback, (2) it .has proven too big to manage and (3)=20 > it hasn't been updated for over a year. >=20 > Rather than trying to foist a path on Fernando and the WG=20 > what we should do is let people who have *energy* for this=20 > suggest a path and let the WG consider that path. If people=20 > think this is important enough to put > *energy* into then it will happen. If people don't, it won't happen. > But, we should realize that if there is no energy it isn't=20 > going to happen no matter what. Technically, adding a new milestone is fairly trivial, if there is enough e= nergy in the community _and_ if there is consensus about the content of a d= raft. A good first step would be a submission of one (or more) individual draft(s= ) that address the past discussions and reviews. Michael From mjethanandani@gmail.com Fri Mar 2 13:25:30 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE8C21E8021 for ; Fri, 2 Mar 2012 13:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTSzj0prrqyN for ; Fri, 2 Mar 2012 13:25:30 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F063621E8010 for ; Fri, 2 Mar 2012 13:25:08 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so756558pbb.31 for ; Fri, 02 Mar 2012 13:25:08 -0800 (PST) Received-SPF: pass (google.com: domain of mjethanandani@gmail.com designates 10.68.195.99 as permitted sender) client-ip=10.68.195.99; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mjethanandani@gmail.com designates 10.68.195.99 as permitted sender) smtp.mail=mjethanandani@gmail.com; dkim=pass header.i=mjethanandani@gmail.com Received: from mr.google.com ([10.68.195.99]) by 10.68.195.99 with SMTP id id3mr20287592pbc.149.1330723508876 (num_hops = 1); Fri, 02 Mar 2012 13:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=rKJAAU9BQUFKPJYF1M6tgPrPW4CdmyP4veDFrEh1oMg=; b=oVcpMPpK26uAzPFJ39bvERWPBHerALhfARdyVtt7HlLbP9FIYkYjUiiMojCqdd069B nOLqus4LYOIMkIAvs3Y0W4ykZr/44nQ59qt0RpWT7XdcZFQcornvy0WrmHcGPn2KDc69 RVE9ffSVAxtwo5N5JTzCWT1vZmyok88oPDgvHiepdF1PLU9mLxlVJA+USY8IXEzGAIrF nu9l7A1nvNriCjqcEYRVBfEC38vD0ZldbdPsI7Cgmi2keNsg38j6e3caw+6EXE01L3ET /jcm7USOcWyxlE5/SCCHrdKq0M05Rvo+XQJONjwrgqjOb6usrSvIuFJLygfT8qbbMhig slRQ== Received: by 10.68.195.99 with SMTP id id3mr16944635pbc.149.1330723508788; Fri, 02 Mar 2012 13:25:08 -0800 (PST) Received: from [192.168.1.123] (c-24-6-173-225.hsd1.ca.comcast.net. [24.6.173.225]) by mx.google.com with ESMTPS id m3sm5936818pbg.44.2012.03.02.13.25.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Mar 2012 13:25:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5-228986847 From: Mahesh Jethanandani In-Reply-To: <20120302200950.EBE13C147B2@lawyers.icir.org> Date: Fri, 2 Mar 2012 13:25:04 -0800 Message-Id: <86693FF1-6A18-4089-9AA6-50E14D9DAD52@gmail.com> References: <20120302200950.EBE13C147B2@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1084) Cc: "Anantha Ramaiah \(ananth\)" , tcpm@ietf.org, Ted Faber , Fernando Gont Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 21:25:30 -0000 --Apple-Mail-5-228986847 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, Do we agree that there is a need to identify and secure TCP? I think I = did hear a yes. On Mar 2, 2012, at 12:09 PM, Mark Allman wrote: > because (1) it has received a bunch of [legitimate IMO] pushback, (2) = it > .has proven too big to manage and (3) it hasn't been updated for over = a > year. If I get this right then for (1) identify which parts received pushbacks. For the parts that you = reviewed can you identify which were areas that you felt needed to stay. = I can do the same for the parts I read. I know Anantha has reviewed the = document. (2) As I suggested in my last e-mail, if it is too big to manage, we can = split it up. If not along the lines I suggested, then suggest which = other way. I am sure Fernando will not have a problem with splitting the = draft if it helps move it forward. (3) will take of itself if we agree on (1) and (2).= --Apple-Mail-5-228986847 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
because (1) = it has received a bunch of [legitimate IMO] pushback, (2) it
.has = proven too big to manage and (3) it hasn't been updated for over = a
year.

If I get this right then = for

(1) identify which parts received = pushbacks. For the parts that you reviewed can you identify which were = areas that you felt needed to stay. I can do the same for the parts I = read. I know Anantha has reviewed the = document.

(2) As I suggested in my = last e-mail, if it is too big to manage, we can split it up. If not = along the lines I suggested, then suggest which other way. I am sure = Fernando will not have a problem with splitting the draft if it helps = move it forward.

(3) will take of itself if we = agree on (1) and (2).
= --Apple-Mail-5-228986847-- From mallman@icir.org Fri Mar 2 13:39:01 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C63921E806F for ; Fri, 2 Mar 2012 13:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovH9n6dUhNTx for ; Fri, 2 Mar 2012 13:39:00 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id DF43B21E806C for ; Fri, 2 Mar 2012 13:39:00 -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 q22LcpPt016563; Fri, 2 Mar 2012 13:38:52 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F0655C17714; Fri, 2 Mar 2012 16:38:50 -0500 (EST) To: Mahesh Jethanandani From: Mark Allman In-Reply-To: <86693FF1-6A18-4089-9AA6-50E14D9DAD52@gmail.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Friend Of The Devil X-URL-0: http://www.icir.org/mallman-files/Document42121.jpg X-URL-1: http://www.icir.org/mallman-files/Document38097.html X-URL-2: http://www.icir.org/mallman-files/Document99577.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma15850-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 02 Mar 2012 16:38:50 -0500 Sender: mallman@icir.org Message-Id: <20120302213850.F0655C17714@lawyers.icir.org> Cc: "Anantha Ramaiah \(ananth\)" , tcpm@ietf.org, Ted Faber , Fernando Gont Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 21:39:01 -0000 ----------ma15850-1 Content-Type: text/plain Content-Disposition: inline > Do we agree that there is a need to identify and secure TCP? If there are places where TCP is vulnerable then I agree it would be good to fix those. But, for instance, I do not believe this document says anything over and above what the RFCs already say in terms of congestion control. > > because (1) it has received a bunch of [legitimate IMO] pushback, (2) it > > .has proven too big to manage and (3) it hasn't been updated for over a > > year. > > If I get this right then for > > (1) identify which parts received pushbacks. For the parts that you > reviewed can you identify which were areas that you felt needed to > stay. I can do the same for the parts I read. I know Anantha has > reviewed the document. I provided detailed reviews of sections 9 & 14. Neither provided anything useful in terms of identifying vulnerabilities or fixing them over the current RFCs. > (2) As I suggested in my last e-mail, if it is too big to manage, we > can split it up. If not along the lines I suggested, then suggest > which other way. I am sure Fernando will not have a problem with > splitting the draft if it helps move it forward. I **did** suggest something. In the email you are responding to, in fact. I suggest we fix the root documents. If there is a problem in RFC 5681 then lets fix that document. There may be some cases where a new document is needed for something because the root document is just untenable to deal with directly or something. Thats fine. But, as I have said many times, the way to fix small problems in a couple of dozen document is NOT to write some monolithic document that conflicts with those couple dozen other documents. That is a giant MESS. Please stop pretending the WG hasn't done anything in this space. We have discussed this document. We have tried to help. We have made suggestions. Any number of members have done so. The previous chairs did so. > (3) will take of itself if we agree on (1) and (2). I listed (3) to basically indicate this WG has had very little energy for this work for some time now. If there is good energy for something that needs fixed then lets do it. allman ----------ma15850-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk9RPeoACgkQWyrrWs4yIs6XvgCfUoSRTPwMkxeMnqIrxU5Ac7su cbEAniUq4Gpf5AMjDnnG530zSE9lkPJm =LDVT -----END PGP SIGNATURE----- ----------ma15850-1-- From touch@isi.edu Fri Mar 2 13:46:54 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA40121E8079 for ; Fri, 2 Mar 2012 13:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uVJOcVMb3Wh for ; Fri, 2 Mar 2012 13:46:54 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 72D4221E8073 for ; Fri, 2 Mar 2012 13:46:54 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q22LkQV9018974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Mar 2012 13:46:26 -0800 (PST) Message-ID: <4F513FB2.8060002@isi.edu> Date: Fri, 02 Mar 2012 13:46:26 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mahesh Jethanandani References: <20120302200950.EBE13C147B2@lawyers.icir.org> <86693FF1-6A18-4089-9AA6-50E14D9DAD52@gmail.com> In-Reply-To: <86693FF1-6A18-4089-9AA6-50E14D9DAD52@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Ted Faber , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont , mallman@icir.org Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 21:46:55 -0000 On 3/2/2012 1:25 PM, Mahesh Jethanandani wrote: > Mark, > > Do we agree that there is a need to identify and secure TCP? I think I > did hear a yes. "Securing" TCP is done with RFC 5925 (TCP-AO). Fixing bugs in TCP is done with the RFC 2525 (implementation issues), which may be due for an update. We do NOT need a doc that teaches best-practices of implementing TCP using techniques any protocol programmer should already know (check your fields before acting on them, etc.) We do NOT need a doc that paints every undesired or unexpected behavior as an attack. Be liberal in what you receive, even if it means ignoring it. If there is a specific security problem, a specific ID might prove useful. But we should evaluate each issue on its own merits. There's no need to call for a crusade here. Joe From mallman@icir.org Fri Mar 2 13:50:45 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E138021F84DA for ; Fri, 2 Mar 2012 13:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6bbocpyfLCI for ; Fri, 2 Mar 2012 13:50:45 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0E84121F84D9 for ; Fri, 2 Mar 2012 13:50:45 -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 q22LoekQ017707; Fri, 2 Mar 2012 13:50:40 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AD53FC17A61; Fri, 2 Mar 2012 16:50:39 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4F513FB2.8060002@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Friend Of The Devil X-URL-0: http://www.icir.org/mallman-files/Document82297.docx X-URL-1: http://www.icir.org/mallman-files/Document6748.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma16559-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 02 Mar 2012 16:50:39 -0500 Sender: mallman@icir.org Message-Id: <20120302215039.AD53FC17A61@lawyers.icir.org> Cc: Ted Faber , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 21:50:46 -0000 ----------ma16559-1 Content-Type: text/plain Content-Disposition: inline > "Securing" TCP is done with RFC 5925 (TCP-AO). > > Fixing bugs in TCP is done with the RFC 2525 (implementation > issues), which may be due for an update. > > We do NOT need a doc that teaches best-practices of implementing TCP > using techniques any protocol programmer should already know (check > your fields before acting on them, etc.) > > We do NOT need a doc that paints every undesired or unexpected > behavior as an attack. Be liberal in what you receive, even if it > means ignoring it. > > If there is a specific security problem, a specific ID might prove > useful. But we should evaluate each issue on its own merits. There's > no need to call for a crusade here. Holy crap ... I don't think Joe wrote anything above I disagree with! Spooky .... :-) :-) allman ----------ma16559-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk9RQK8ACgkQWyrrWs4yIs4nSQCeIYvNOuHpsQQdfcCzfYFi+Ro9 93sAnRyid9mMt/xZEuoIgXkbVuZ8H4Do =RNxA -----END PGP SIGNATURE----- ----------ma16559-1-- From michael.scharf@alcatel-lucent.com Fri Mar 2 14:27:47 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6B921E8073 for ; Fri, 2 Mar 2012 14:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlqINV-6DGad for ; Fri, 2 Mar 2012 14:27:46 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 94CD521E8065 for ; Fri, 2 Mar 2012 14:27:46 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q22MRcEp029703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 23:27:39 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 2 Mar 2012 23:27:38 +0100 From: "SCHARF, Michael" To: Mahesh Jethanandani , "mallman@icir.org" Date: Fri, 2 Mar 2012 23:27:38 +0100 Thread-Topic: [tcpm] Removal of TCPM milestone on security hardening Thread-Index: Acz4uxXT1+HKVQRSRW+fN+4TwHfU3AABBcAQ Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F41C@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20120302200950.EBE13C147B2@lawyers.icir.org> <86693FF1-6A18-4089-9AA6-50E14D9DAD52@gmail.com> In-Reply-To: <86693FF1-6A18-4089-9AA6-50E14D9DAD52@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: Ted Faber , "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , Fernando Gont Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 22:27:47 -0000 > Do we agree that there is a need to identify and secure TCP?=20 > I think I did hear a yes. The current milestone text is about security hardening of TCP _implementati= ons_. My personal understanding is that such guidance to stack implementors could= , for instance, also be achieved by a short informational survey document l= ike RFC 4614 that just points to the relevant sections in standard track RF= Cs. But it is really useless to discuss about hypothetical documents that d= o not exist. Michael= From fgont@si6networks.com Sun Mar 4 00:30:38 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E7521F85A5 for ; Sun, 4 Mar 2012 00:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBmKEahQ2jE4 for ; Sun, 4 Mar 2012 00:30:37 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id CCA1C21F85A2 for ; Sun, 4 Mar 2012 00:30:36 -0800 (PST) Received: from [2001:5c0:1000:a::545] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S46pn-0004WS-Kl; Sun, 04 Mar 2012 09:30:28 +0100 Message-ID: <4F532807.8030306@si6networks.com> Date: Sun, 04 Mar 2012 05:29:59 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Joe Touch References: <20120302200950.EBE13C147B2@lawyers.icir.org> <86693FF1-6A18-4089-9AA6-50E14D9DAD52@gmail.com> <4F513FB2.8060002@isi.edu> In-Reply-To: <4F513FB2.8060002@isi.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, deraadt@cvs.openbsd.org, Ted Faber , "Anantha Ramaiah \(ananth\)" , mallman@icir.org, Fernando Gont Subject: Re: [tcpm] Removal of TCPM milestone on security hardening X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 04 Mar 2012 08:30:38 -0000 Joe, On 03/02/2012 06:46 PM, Joe Touch wrote: > On 3/2/2012 1:25 PM, Mahesh Jethanandani wrote: >> Mark, >> >> Do we agree that there is a need to identify and secure TCP? I think I >> did hear a yes. > > "Securing" TCP is done with RFC 5925 (TCP-AO). 1) Is this deployable for the general case, in the real world? 2) Even if it was (which I don't think it's the case), that just "authenticates" the remote endpoint. That doesn't mean that an authenticated endpoint (whether because it's infected with malware or because it simply wants to have fun) won't be able to mess with others' connections. > We do NOT need a doc that teaches best-practices of implementing TCP > using techniques any protocol programmer should already know (check your > fields before acting on them, etc.) Have you bothered to check e.g. US-CERT's web site, and see what is going on in the real world? > We do NOT need a doc that paints every undesired or unexpected behavior > as an attack. Agreed. We just need implementations that do not break under any undesired or unexpected behavior. > If there is a specific security problem, a specific ID might prove > useful. Joe, you even argued against the publication of RFC 6528. Are you being serious? > But we should evaluate each issue on its own merits. There's no > need to call for a crusade here. No crusades. Just caring about that thing called "running code". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From naito.kengo@lab.ntt.co.jp Mon Mar 5 17:01:29 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290DA21E805C for ; Mon, 5 Mar 2012 17:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdK9zhEwvytQ for ; Mon, 5 Mar 2012 17:01:28 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id F1E1B21E8071 for ; Mon, 5 Mar 2012 17:01:27 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q2611PYX003834; Tue, 6 Mar 2012 10:01:25 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id DA9D1E0086; Tue, 6 Mar 2012 10:01:25 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id CF22FE0084; Tue, 6 Mar 2012 10:01:25 +0900 (JST) Received: from [127.0.0.1] ([129.60.7.245]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q2611O4d008068; Tue, 6 Mar 2012 10:01:25 +0900 Message-ID: <4F556156.6030803@lab.ntt.co.jp> Date: Tue, 06 Mar 2012 09:59:02 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: tcpm@ietf.org, "'Pasi Sarolahti'" References: <20120305125040.13625.47540.idtracker@ietfa.amsl.com> In-Reply-To: <20120305125040.13625.47540.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] New Version Notification for draft-naito-nat-resource-optimizing-extension-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 01:01:29 -0000 Pasi, tcpm members, Hi, I wrote a new draft written below. https://datatracker.ietf.org/doc/draft-naito-nat-resource-optimizing-extension/?include_text=1 I've already asked Pasi for adding this discussion to Agenda, Paris. There's some topic I want to add to my draft, which I'll do so by Paris. (which I wrote like "I'll write this part by Paris" in 00 version) I would appreciate your comments and advice. Best regards, (2012/03/05 21:50), internet-drafts@ietf.org wrote: > A new version of I-D, draft-naito-nat-resource-optimizing-extension-00.txt has been successfully submitted by Kengo and posted to the IETF repository. > > Filename: draft-naito-nat-resource-optimizing-extension > Revision: 00 > Title: NAT resource optimizing extension > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 4 > > Abstract: > When NAT is used in address resource restricted environment, or when > a lot of users are located under a NAT device, IP address and port > resources may be eaten up, and it brings severe bad effects on user > experiences. This situation can be greatly mitigated by tweaking > mapping behavior and session timer handling at NAT function. This > document proposes to NAT IP address and port resource optimizing > extension for address resource restricted environment. One extension > is to enable simultaneous use of a port for different transport > sessions, and the other is to make use of TCP timestamp for TIME_WAIT > Assassination. > > > > > The IETF Secretariat > > -- ---------------------------------------- NTT Service Integration Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- From ycheng@google.com Mon Mar 5 18:17:32 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D3021E8074 for ; Mon, 5 Mar 2012 18:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6OmgnL32flf for ; Mon, 5 Mar 2012 18:17:31 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 557A321E8018 for ; Mon, 5 Mar 2012 18:17:31 -0800 (PST) Received: by iazz13 with SMTP id z13so7439526iaz.31 for ; Mon, 05 Mar 2012 18:17:30 -0800 (PST) Received-SPF: pass (google.com: domain of ycheng@google.com designates 10.50.222.135 as permitted sender) client-ip=10.50.222.135; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ycheng@google.com designates 10.50.222.135 as permitted sender) smtp.mail=ycheng@google.com; dkim=pass header.i=ycheng@google.com Received: from mr.google.com ([10.50.222.135]) by 10.50.222.135 with SMTP id qm7mr9264894igc.9.1331000250861 (num_hops = 1); Mon, 05 Mar 2012 18:17:30 -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:x-system-of-record; bh=H4R6aahTq/Y+dDTiDvCAF5rSXQRasqmTtrhEjR9jXOQ=; b=ei62GDMDUaUsS3JIy/TPW9duAMPTLw6wawdNw02dsrAmyY9dCk9bZjkPyhvvQTa77C FJIDRqPQOsT65xGh6klyBIYTFSL4ZMrWZrjK2Ad7K6gFOFUxtuGtqj7B1a6PplKNM20i 7u2tI9/+Nr4UmFWUXx10FpxxwiZP33Dh7ZWz6246aYeAyKeINHPWV5bIafqwXfrq8B8q gTMLBn85TE6OXhKRAWNCIW4waa3CtNztUu/MPB2SWwYyTSmQhI5vQuw5OEni+Xr+z9Lo unmOPvWvB5zZ8wbvllvoxqCNODuZbM5hbvsLQEams2EjUIAX05AvnInqC08oU2IGGSsQ xJ+w== Received: by 10.50.222.135 with SMTP id qm7mr7689288igc.9.1331000250819; Mon, 05 Mar 2012 18:17:30 -0800 (PST) Received: by 10.50.222.135 with SMTP id qm7mr7689282igc.9.1331000250758; Mon, 05 Mar 2012 18:17:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.180.136 with HTTP; Mon, 5 Mar 2012 18:17:10 -0800 (PST) In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C06C80E67@SLFSNX.rcs.alcatel-research.de> References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E67@SLFSNX.rcs.alcatel-research.de> From: Yuchung Cheng Date: Mon, 5 Mar 2012 18:17:10 -0800 Message-ID: To: "SCHARF, Michael" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl7a5HcR+b+P77hH6iwBOvEYVG+RrwPyeL7OjfvguzJGwyexq02E1nC64qyI7sj8adRG0pAg4N22sH1v3S7ZNEa34M1yWIBFRx4EhwD6xqxMZIBjUJ7/whDX79r7JT1EuWi07zQ Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM rechartering discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 02:17:32 -0000 Are middleboxes issues (NAT messing up TCP) part of the charter. also is there an RFC (or draft) for this ? " * The WG is writing an informational document about the ways in which TCPs can handle ICMP "soft errors". " Thanks, Yuchung On Mon, Feb 20, 2012 at 2:19 AM, SCHARF, Michael wrote: > Dear all, > > The current TCPM charter https://datatracker.ietf.org/wg/tcpm/charter/ > includes some outdated text. Most notably, the "Specific Goals" > mentioned in the charter are not up to date. Also, the current charter > requires IESG approval of every new milestone. > > Therefore, the chairs think that it would make sense to recharter TCPM > in order to clean up the completed goals and to make it easier to manage > future milestones. Please find below a first draft for a new charter > text. The intention is a minor modification that does not to affect the > overall scope of the working group. > > We would highly appreciate comments or suggestions. > > Best regards > > Michael (TCPM co-chair) > > > > > TCP Maintenance and Minor Extensions (tcpm) > ------------------------------------------- > > Description of Working Group: ***DRAFT*** > > TCP is currently the Internet's predominant transport protocol. > To maintain TCP's utility the IETF has regularly updated both > the protocol itself and the congestion control algorithms > implemented by the protocol that are crucial for the stability > of the Internet. These changes reflect our evolving > understanding of transport protocols, congestion control and new > needs presented by an ever-changing network. The TCPM WG provides > a venue within the IETF to work on these issues. The WG > serves several purposes: > > * The WG mostly focuses on maintenance issues (e.g., bug > fixes) and modest changes to the protocol and algorithms > that maintain TCP's utility, including incremental enhancements > of the congestion control mechanisms. > > * The WG is a venue for moving current TCP specifications > along the standards track (as community energy is available > for such efforts). > > * The focus of the working group are minor extensions to TCP > algorithms and mechanisms. In cases where these are > directly applicable to other transports (e.g. SCTP or DCCP), > the mappings to other transports may be specified alongside > that for TCP, but significant additions and changes to other > transports are not in scope. > > TCPM is the working group within the IETF that handles small TCP > changes, or minor extensions to TCP algorithms and mechanisms. While > fundamental changes to TCP or its congestion control algorithms > (e.g., departure from loss-based congestion control) should be brought > through TCPM, it is expected that such large changes will be handled > by other working groups or require additional reviews, in particular by > the IRTF Congestion Control Research Group (ICCRG). > > TCP's congestion control algorithms are the model followed by > alternate transports (e.g., SCTP and (in some cases) DCCP), > which are handled for instance by the Transport Area WG (tsvwg). > The IETF has recently worked on several documents > about algorithms that are specified for multiple protocols > (e.g., TCP and SCTP) in the same document. Which WG shepherds > such documents will determined on a case-by-case > basis. In any case, the TCPM WG will remain in close contact > with other relevant WGs working on these protocols to ensure > openness and stringent review from all angles. > > New TCPM milestones that fall within the scope specified within > the charter can be added after approval of the working group and the > responsible Area Director. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From alexander.zimmermann@comsys.rwth-aachen.de Tue Mar 6 00:03:42 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD0021F8675 for ; Tue, 6 Mar 2012 00:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.525 X-Spam-Level: X-Spam-Status: No, score=-5.525 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX0sOcUmylza for ; Tue, 6 Mar 2012 00:03:41 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.rwth-aachen.de [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5394021F8671 for ; Tue, 6 Mar 2012 00:03:40 -0800 (PST) MIME-version: 1.0 Received: from mx-out-1.rwth-aachen.de ([134.130.5.186]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0M0G00KW5EE3LB70@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 06 Mar 2012 09:03:39 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.73,538,1325458800"; d="asc'?scan'208";a="168457250" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by mx-1.rz.rwth-aachen.de with ESMTP; Tue, 06 Mar 2012 09:03:39 +0100 Received: from [137.226.12.25] ([unknown] [137.226.12.25]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0M0G00DPOEE3ST80@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 06 Mar 2012 09:03:39 +0100 (CET) Content-type: multipart/signed; boundary="Apple-Mail=_E9F2AB9D-D024-4FBF-B9C7-474F2D9A77D0"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Alexander Zimmermann In-reply-to: Date: Tue, 06 Mar 2012 09:03:39 +0100 Message-id: <647CF0D5-B9C2-495B-8CC2-466F1125D952@comsys.rwth-aachen.de> References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E67@SLFSNX.rcs.alcatel-research.de> To: Yuchung Cheng X-Mailer: Apple Mail (2.1257) Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM rechartering discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 08:03:42 -0000 --Apple-Mail=_E9F2AB9D-D024-4FBF-B9C7-474F2D9A77D0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Yuchung, Am 06.03.2012 um 03:17 schrieb Yuchung Cheng: > Are middleboxes issues (NAT messing up TCP) part of the charter. > > also is there an RFC (or draft) for this ? > " * The WG is writing an informational document about the ways in > which TCPs can handle ICMP "soft errors". " See RFC 5461: TCP's Reaction to Soft Errors and RFC 5927 ICMP: attacks against TCP Alex > > Thanks, > > Yuchung > > On Mon, Feb 20, 2012 at 2:19 AM, SCHARF, Michael > wrote: // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // mobile: (49-176) 32820027, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail=_E9F2AB9D-D024-4FBF-B9C7-474F2D9A77D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk9VxNsACgkQdyiq39b9uS7MwQCgwkFHSzf9cjapnKSObcvPcv/p oe4AnitDt3LUOkpSIbEwxRUPC4tu2rtI =GBWV -----END PGP SIGNATURE----- --Apple-Mail=_E9F2AB9D-D024-4FBF-B9C7-474F2D9A77D0-- From michael.scharf@alcatel-lucent.com Tue Mar 6 04:05:12 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA95D21F879A for ; Tue, 6 Mar 2012 04:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNtAAXsJ14lL for ; Tue, 6 Mar 2012 04:05:12 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id AA8EA21F872A for ; Tue, 6 Mar 2012 04:05:11 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q26C2plC009320 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Mar 2012 13:05:09 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 6 Mar 2012 13:05:08 +0100 From: "Scharf, Michael (Michael)" To: Yuchung Cheng Date: Tue, 6 Mar 2012 13:05:07 +0100 Thread-Topic: [tcpm] TCPM rechartering discussion Thread-Index: Acz7P03UYJQeQLgdSNmXvCLowBmyuQAT5LQA Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F43E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E67@SLFSNX.rcs.alcatel-research.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCPM rechartering discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 12:05:12 -0000 Yuchung,=20 > Are middleboxes issues (NAT messing up TCP) part of the charter. =20 Good question. We have in the charter (both in the current and in the propo= sed update) the statement that the "WG mostly focuses on maintenance issues= (e.g., bug fixes) and modest changes to the protocol and algorithms that m= aintain TCP's utility [...]". As a result, I think that potential minor modifications of the TCP protocol= to improve the interoperability of TCP's existing service with NATs would = be in scope of the charter. Of course, provided that there is indeed a real= need for such modifications, consensus in TCPM, etc. Do you suggest a rephrasing of the charter text? > also is there an RFC (or draft) for this ? > " * The WG is writing an informational document about the=20 > ways in which TCPs can handle ICMP "soft errors". " As already pointed out by Alex, this part of the current TCPM charter is re= ally outdated. Removing the legacy text is one key motivation for this char= ter update discussion. Thanks for the feedback Michael From L.Wood@surrey.ac.uk Tue Mar 6 05:26:52 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E2721F86D9 for ; Tue, 6 Mar 2012 05:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.973 X-Spam-Level: X-Spam-Status: No, score=-4.973 tagged_above=-999 required=5 tests=[AWL=1.625, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq+JUQtoj0BU for ; Tue, 6 Mar 2012 05:26:51 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0384F21F850D for ; Tue, 6 Mar 2012 05:25:57 -0800 (PST) Received: from [195.245.230.131:3423] by server-2.bemta-3.messagelabs.com id 61/17-28206-460165F4; Tue, 06 Mar 2012 13:25:56 +0000 X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-7.tower-78.messagelabs.com!1331040356!19255548!1 X-Originating-IP: [131.227.200.35] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10308 invoked from network); 6 Mar 2012 13:25:56 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-7.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 6 Mar 2012 13:25:56 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.208]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Tue, 6 Mar 2012 13:25:55 +0000 From: To: , Date: Tue, 6 Mar 2012 13:25:55 +0000 Thread-Topic: [tcpm] TCPM rechartering discussion Thread-Index: Acz7P03UYJQeQLgdSNmXvCLowBmyuQAT5LQAAAM2Njg= Message-ID: References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E67@SLFSNX.rcs.alcatel-research.de> , <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F43E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F43E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM rechartering discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 13:26:52 -0000 Um, RFC 5461, TCP's Reaction to Soft Errors?=20 http://tools.ietf.org/html/rfc5461 http://www.gont.com.ar/papers/index.html http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html may also be of interest. Lloyd Wood http://sat-net.com/L.Wood/ > also is there an RFC (or draft) for this ? > " * The WG is writing an informational document about the > ways in which TCPs can handle ICMP "soft errors". " As already pointed out by Alex, this part of the current TCPM charter is re= ally outdated. Removing the legacy text is one key motivation for this char= ter update discussion. Thanks for the feedback Michael From michael.scharf@alcatel-lucent.com Tue Mar 6 05:36:42 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA3C21F871E for ; Tue, 6 Mar 2012 05:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9nHpzQlS8Bg for ; Tue, 6 Mar 2012 05:36:41 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 92CD721F871A for ; Tue, 6 Mar 2012 05:36:41 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q26DYbZs015351 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Mar 2012 14:36:30 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 6 Mar 2012 14:35:58 +0100 From: "Scharf, Michael (Michael)" To: "L.Wood@surrey.ac.uk" , "ycheng@google.com" Date: Tue, 6 Mar 2012 14:35:57 +0100 Thread-Topic: [tcpm] TCPM rechartering discussion Thread-Index: Acz7P03UYJQeQLgdSNmXvCLowBmyuQAT5LQAAAM2NjgAAGBnAA== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F440@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E67@SLFSNX.rcs.alcatel-research.de> , <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F43E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCPM rechartering discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 13:36:42 -0000 Isn't this what RFC 5927 is about? RFC 5927/draft-ietf-tcpm-icmp-attacks dates back quite some time... Michael > -----Original Message----- > From: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk]=20 > Sent: Tuesday, March 06, 2012 2:26 PM > To: Scharf, Michael (Michael); ycheng@google.com > Cc: tcpm@ietf.org > Subject: RE: [tcpm] TCPM rechartering discussion >=20 > Um, RFC 5461, TCP's Reaction to Soft Errors?=20 >=20 > http://tools.ietf.org/html/rfc5461 >=20 > http://www.gont.com.ar/papers/index.html > http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html > may also be of interest. >=20 > Lloyd Wood > http://sat-net.com/L.Wood/ >=20 > > also is there an RFC (or draft) for this ? > > " * The WG is writing an informational document about the ways in=20 > > which TCPs can handle ICMP "soft errors". " >=20 > As already pointed out by Alex, this part of the current TCPM=20 > charter is really outdated. Removing the legacy text is one=20 > key motivation for this charter update discussion. >=20 > Thanks for the feedback >=20 > Michael > = From ycheng@google.com Tue Mar 6 16:43:03 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F6F21F870B for ; Tue, 6 Mar 2012 16:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMqtPXdWqo05 for ; Tue, 6 Mar 2012 16:43:01 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4E2321F8705 for ; Tue, 6 Mar 2012 16:43:01 -0800 (PST) Received: by obbta4 with SMTP id ta4so4852999obb.31 for ; Tue, 06 Mar 2012 16:43:01 -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:x-system-of-record; bh=KrSzuPIf9MAixJPrVP2iNh5veXICLAHv5tmG0yh+U6Q=; b=ZMmB4deTjXB7SzQ0gO2gX5IGX5N6UAiwrDxaDxeF4MB29ZL2ng9PJ4pU76UqU4ESkJ pSGEPyuuVQAXOTuhbDQXg8K1GDnqSJ9qFtNLH97lS4wm/TEi1t+nPdzLxV8mzp3Eb9BW r/gg40Y0Gd0nM73kEOcHaYfhcln7LmDilDZnYJSxjnWErUk9PgiEpd5ERY5KeK3rLm3Q UIQCUIfNYKxyo2xR4CqK7NaZ7kausZlQzeQol+7ATH3oCO44/3c92FNwO1+1rVsNT1Qa cr94I9ekSjK3weyKCHYBPPuxS6Z4hXfgcc3DJVEapqcJUdxlG6l7xBIXH94z7XyDtu1e ONFA== Received: by 10.60.12.72 with SMTP id w8mr18596oeb.31.1331080981312; Tue, 06 Mar 2012 16:43:01 -0800 (PST) Received: by 10.60.12.72 with SMTP id w8mr18590oeb.31.1331080981214; Tue, 06 Mar 2012 16:43:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.71.103 with HTTP; Tue, 6 Mar 2012 16:42:41 -0800 (PST) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F43E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E67@SLFSNX.rcs.alcatel-research.de> <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F43E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Tue, 6 Mar 2012 16:42:41 -0800 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnqPbRRyGI+JpsT6ikeMZWleKzb+1Oitk/ct+QhSsmSa7Oy4E66Q/0JF+T+dYx33ArxNuhK3rF6KpDEfLIqO9j4D5STnSQW1D4Z8YgbXkSJHACDVrN8PcYibe6r9i4z/QdR2Ep1 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCPM rechartering discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 00:43:03 -0000 On Tue, Mar 6, 2012 at 4:05 AM, Scharf, Michael (Michael) wrote: > Yuchung, > >> Are middleboxes issues (NAT messing up TCP) part of the charter. > > Good question. We have in the charter (both in the current and in the pro= posed update) the statement that the "WG mostly focuses on maintenance issu= es (e.g., bug fixes) and modest changes to the protocol and algorithms that= maintain TCP's utility [...]". > > As a result, I think that potential minor modifications of the TCP protoc= ol to improve the interoperability of TCP's existing service with NATs woul= d be in scope of the charter. Of course, provided that there is indeed a re= al need for such modifications, consensus in TCPM, etc. Great! is there any guideline on middlebox cooking up new TCP headers? e.g., draft-ananth-middisc-tcpopt-00.tx From touch@isi.edu Tue Mar 6 17:14:51 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF3921E8010 for ; Tue, 6 Mar 2012 17:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-OLP11lDuS2 for ; Tue, 6 Mar 2012 17:14:50 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAD021E800C for ; Tue, 6 Mar 2012 17:14:50 -0800 (PST) Received: from [207.151.141.201] ([207.151.141.201]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q271EVND029891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Mar 2012 17:14:41 -0800 (PST) Message-ID: <4F56B677.4030702@isi.edu> Date: Tue, 06 Mar 2012 17:14:31 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Yuchung Cheng References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E67@SLFSNX.rcs.alcatel-research.de> <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F43E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCPM rechartering discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 01:14:51 -0000 On 3/6/2012 4:42 PM, Yuchung Cheng wrote: > On Tue, Mar 6, 2012 at 4:05 AM, Scharf, Michael (Michael) > wrote: >> Yuchung, >> >>> Are middleboxes issues (NAT messing up TCP) part of the charter. >> >> Good question. We have in the charter (both in the current and in the proposed update) the statement that the "WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility [...]". >> >> As a result, I think that potential minor modifications of the TCP protocol to improve the interoperability of TCP's existing service with NATs would be in scope of the charter. Of course, provided that there is indeed a real need for such modifications, consensus in TCPM, etc. > > Great! is there any guideline on middlebox cooking up new TCP headers? Check with the MIDCOM WG. However, in general, I'd say "don't" ;-) Joe From ananth@cisco.com Tue Mar 6 17:22:43 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BB921E801F for ; Tue, 6 Mar 2012 17:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.592 X-Spam-Level: X-Spam-Status: No, score=-9.592 tagged_above=-999 required=5 tests=[AWL=1.007, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v52VGw7OmsoR for ; Tue, 6 Mar 2012 17:22:42 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A6E6221E800C for ; Tue, 6 Mar 2012 17:22:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=1285; q=dns/txt; s=iport; t=1331083362; x=1332292962; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qpvqjFEZp3VZe0YLQLbi8y+4QZWjTPhUdQMSdDHTmGg=; b=dxmXAULjtGUYxxGamMX2mlc9WDJj2iQMJW/qwVZS+KPJElLh1gOOwr5G izMUVIt3/T8gVgUaIlmaRd7XxkJ0SezjqPW2U0shUzd5sMrWbsKL7GiTs E//gLOcb4ugV/Y+jidJZrMbOql64z+h31fcJ/Ay83qBfjdgEwhlfYDNWk k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACu3Vk+rRDoJ/2dsb2JhbABDtQWBB4F9AQEBAwESAR0KPxACAQgOFAYYBgFWAQEEGxqHYAQBC5pHAZ8KkA1jBIhSnQODBA X-IronPort-AV: E=Sophos;i="4.73,542,1325462400"; d="scan'208";a="32201500" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 07 Mar 2012 01:22:42 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q271Mgir013511; Wed, 7 Mar 2012 01:22:42 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 17:22:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Mar 2012 17:22:42 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580EA2223B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCPM rechartering discussion Thread-Index: Acz7+0Pvq9Doy6n8Q9qBMjyOf2yzMQAAri2g References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E67@SLFSNX.rcs.alcatel-research.de><2A886F9088894347A3BE0CC5B7A85F3E88E2D4F43E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: "Anantha Ramaiah (ananth)" To: "Yuchung Cheng" , "Scharf, Michael (Michael)" X-OriginalArrivalTime: 07 Mar 2012 01:22:42.0475 (UTC) FILETIME=[CB1C97B0:01CCFC00] Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM rechartering discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 01:22:43 -0000 Yuchung, I think I need to explain some context here.. >=20 > Great! is there any guideline on middlebox cooking up new TCP headers? > e.g., draft-ananth-middisc-tcpopt-00.tx A few years back there was a draft which talked about transparent middlebox discovery (http://tools.ietf.org/html/draft-knutsen-tcpm-middlebox-discovery-03 ) and seeking a TCP option for the same that would be used by the middleboxes. TCPM decided not to take up that work and an alias was formed (with the blessings of the transport AD's) which was used by multiple vendors doing WAN optimization to discuss and converge upon a single TCP option format. The main goal of this is to dis-courage vendors from doing TCP option poaching and using the TCP options officially unassigned by IANA for middlebox services like Wan optimization etc.,=20 I am trying to interpret your comment on "middlebox cooking up new TCP headers", Well middleboxes are there and they do connection termination and optimization (Performance enhancing proxies), for quite some time in the internet as you probably are aware. The issue the middisc draft is trying to address is to get all vendors try using a single TCP option code point and stop using unassigned TCP option code points.=20 -Anantha From michael.scharf@alcatel-lucent.com Wed Mar 7 00:36:36 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499B421F8623 for ; Wed, 7 Mar 2012 00:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.789 X-Spam-Level: X-Spam-Status: No, score=-9.789 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyOIRA7zge1X for ; Wed, 7 Mar 2012 00:36:35 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8844621F8622 for ; Wed, 7 Mar 2012 00:36:35 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q278W2Pg001136 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 Mar 2012 09:36:23 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 7 Mar 2012 09:35:41 +0100 From: "Scharf, Michael (Michael)" To: Yuchung Cheng Date: Wed, 7 Mar 2012 09:35:39 +0100 Thread-Topic: [tcpm] TCPM rechartering discussion Thread-Index: Acz7+0Gi9f/qM/RLRSOwDJE5dOrRRAAPPJeA Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F464@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <133D9897FB9C5E4E9DF2779DC91E947C06C80E67@SLFSNX.rcs.alcatel-research.de> <2A886F9088894347A3BE0CC5B7A85F3E88E2D4F43E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCPM rechartering discussion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 08:36:36 -0000 > >> Are middleboxes issues (NAT messing up TCP) part of the charter. > > > > Good question. We have in the charter (both in the current=20 > and in the proposed update) the statement that the "WG mostly=20 > focuses on maintenance issues (e.g., bug fixes) and modest=20 > changes to the protocol and algorithms that maintain TCP's=20 > utility [...]". > > > > As a result, I think that potential minor modifications of=20 > the TCP protocol to improve the interoperability of TCP's=20 > existing service with NATs would be in scope of the charter.=20 > Of course, provided that there is indeed a real need for such=20 > modifications, consensus in TCPM, etc. >=20 > Great! is there any guideline on middlebox cooking up new TCP headers? > e.g., draft-ananth-middisc-tcpopt-00.tx Note that I stated that "interoperability of TCP's existing service" might = be in scope of TCPM. In my understanding, middlebox discovery would be a fu= nction beyond what TCP offers today. The TCPM charter explicitly states that the WG only deals with minor TCP ex= tensions, and other working groups might be needed otherwise. IMHO it makes= sense to raise awareness about work such as draft-ananth-middisc-tcpopt in= TCPM (and this discussion is thus helpful). In my understanding, this does= n't imply that TCPM will be the best place to home such work. Michael= From pasi.sarolahti@iki.fi Wed Mar 7 01:59:01 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3603B21F879D for ; Wed, 7 Mar 2012 01:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.291 X-Spam-Level: X-Spam-Status: No, score=-106.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgHEhmXiELwV for ; Wed, 7 Mar 2012 01:58:57 -0800 (PST) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3699921F86E4 for ; Wed, 7 Mar 2012 01:58:51 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id q279wour021177 for ; Wed, 7 Mar 2012 11:58:50 +0200 Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 04946-310 for ; Wed, 7 Mar 2012 11:58:50 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id q279wlPm021173 for ; Wed, 7 Mar 2012 11:58:47 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 9C01B1E136 for ; Wed, 7 Mar 2012 11:58:47 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Giw1BUx-6L-8 for ; Wed, 7 Mar 2012 11:58:43 +0200 (EET) Received: from pc107.netlab.hut.fi (pc107.netlab.hut.fi [130.233.154.107]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 968DD1E0C1 for ; Wed, 7 Mar 2012 11:58:43 +0200 (EET) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Mar 2012 11:58:46 +0200 Message-Id: <7174E034-F57E-499B-A605-C93A3C8EEACA@iki.fi> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [tcpm] Write-up for draft-ietf-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 09:59:01 -0000 Hi, Below is the write-up for draft-ietf-tcpm-3517bis-01 that we will pass = to the TSV ADs with a request to publish the document as Proposed = Standard. Many thanks to authors and others who contributed in producing a solid = document! - Pasi -------------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is requested to be published as Proposed Standard. It is an update to an existing Proposed Standard RFC 3517. The intended status is NOT indicated on the title page of the current version of document. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies a loss recovery algorithm based on the use of TCP SACK option that conforms to the current TCP congestion control requirements. It is a revision of Proposed Standard RFC 3517, to provide clarifications and certain performance enhancements to the earlier specified algorithm. Working Group Summary The document was accepted for publication by the TCPM working group by clear consensus. The working group has extensively reviewed the earlier versions of the document, and the result represents the working group consensus. During the working group last call, there were no requests for changes and only comments were supportive of publication. Document Quality The document has employed the long-standing experience of various people working closely with simulated and native TCP SACK implementations. The current TCP SACK implementations are believed to apply closely similar algorithm than what described in this document, even though there may be implementation-specific variations. Personnel Document Shepherd is Pasi Sarolahti . Responsible Area Director is Wesley Eddy . (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Document Shepherd has reviewed the latest version of the document and thinks the document is ready for publication without further changes (apart from nits described below). (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No.=20 (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no concerns with the current version of the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed for this document, or its predecessor RFC 3517. (9) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Considering the past discussions and a succesful working group last call, the shepherd's view is that this document represents a strong WG consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)=20 No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. * The title page is missing the intended status=20 * The document is missing IANA Considerations section (it has no considerations, but the section should be included nevertheless) * According to idnits, there are a few instances of too long lines and control characters * Two references [RFC2018] and [RFC3042] are not referred to from text These nits should be straightforward to fix before the final publication. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews are required for this document. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in = the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document is a revision of RFC 3517, and intended to replace the earlier RFC, as implied by the draft name (draft-ietf-tcpm-3517bis). This has not been otherwise explicitly indicated on the title page, abstract, or introduction, but the purpose is assumed to be understood by the TCPM participants. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document does not have any IANA considerations, and is currently missing the IANA considerations section. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries are required. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no sections that would require formal validation. From pasi.sarolahti@iki.fi Thu Mar 8 05:29:13 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F55E21F86AA for ; Thu, 8 Mar 2012 05:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yK6Y327vPlqS for ; Thu, 8 Mar 2012 05:29:12 -0800 (PST) Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by ietfa.amsl.com (Postfix) with ESMTP id 21C5E21F86A4 for ; Thu, 8 Mar 2012 05:29:11 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id q28DTBBb005980 for ; Thu, 8 Mar 2012 15:29:11 +0200 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 05032-586 for ; Thu, 8 Mar 2012 15:29:10 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id q28DSuJm005974 for ; Thu, 8 Mar 2012 15:28:56 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 973781E1DE for ; Thu, 8 Mar 2012 15:28:56 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id p5f7EfDt8Myc for ; Thu, 8 Mar 2012 15:28:52 +0200 (EET) Received: from pc109.netlab.hut.fi (pc109.netlab.hut.fi [130.233.154.109]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 8F2B51E130 for ; Thu, 8 Mar 2012 15:28:52 +0200 (EET) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 15:28:52 +0200 References: <9538_1330122016_4F480D1F_9538_260_1_20120224221955.4514.3901.idtracker@ietfa.amsl.com> To: tcpm@ietf.org Message-Id: <5A87B650-FBA7-4308-B05E-60A74B9541CC@iki.fi> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [tcpm] Fwd: I-D Action: draft-ietf-tcpm-proportional-rate-reduction-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 13:29:13 -0000 Hi, The authors of the Proportional Rate Reduction draft think the draft = starts to be ready. There hasn't been much mailing list traffic on this = in the recent months apart from I-D announcements, so now -- 3 weeks = before the meeting -- would be a great time to read the current version = of the draft and send comments to the list. Thanks! - Pasi Begin forwarded message: > From: > Subject: [tcpm] I-D Action: = draft-ietf-tcpm-proportional-rate-reduction-01.txt > Date: February 25, 2012 12:19:55 AM GMT+02:00 > To: > Cc: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the TCP Maintenance and Minor = Extensions Working Group of the IETF. >=20 > Title : Proportional Rate Reduction for TCP > Author(s) : Matt Mathis > Nandita Dukkipati > Yuchung Cheng > Filename : = draft-ietf-tcpm-proportional-rate-reduction-01.txt > Pages : 16 > Date : 2012-02-24 >=20 > This document describes an experimental algorithm, Proportional Rate > Reduction (PPR) to improve the accuracy of the amount of data sent = by > TCP during loss recovery. Standard Congestion Control requires that > TCP and other protocols reduce their congestion window in response = to > losses. This window reduction naturally occurs in the same round > trip as the data retransmissions to repair the losses, and is > implemented by choosing not to transmit any data in response to some > ACKs arriving from the receiver. Two widely deployed algorithms are > used to implement this window reduction: Fast Recovery and Rate > Halving. Both algorithms are needlessly fragile under a number of > conditions, particularly when there is a burst of losses that such > that the number of ACKs returning to the sender is small. > Proportional Rate Reduction minimizes these excess window reductions > such that at the end of recovery the actual window size will be as > close as possible to ssthresh, the window size determined by the > congestion control algorithm. It is patterned after Rate Halving, > but using the fraction that is appropriate for target window chosen > by the congestion control algorithm. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-tcpm-proportional-rate-redu= ction-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-proportional-rate-reduc= tion-01.txt >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Fri Mar 9 00:34:31 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101B321F85D8 for ; Fri, 9 Mar 2012 00:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.332 X-Spam-Level: X-Spam-Status: No, score=-106.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2v1aD8amr-1 for ; Fri, 9 Mar 2012 00:34:30 -0800 (PST) Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3A41321F85D7 for ; Fri, 9 Mar 2012 00:34:30 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id q298YS0F031366 for ; Fri, 9 Mar 2012 10:34:28 +0200 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 05022-720 for ; Fri, 9 Mar 2012 10:34:28 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id q298YPAt031362 for ; Fri, 9 Mar 2012 10:34:26 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id D8BF91E130 for ; Fri, 9 Mar 2012 10:34:25 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kPgXsbo1z0y8 for ; Fri, 9 Mar 2012 10:34:22 +0200 (EET) Received: from [192.168.1.65] (dsl-hkibrasgw4-fe5cdf00-46.dhcp.inet.fi [80.223.92.46]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 485BD1E0B8 for ; Fri, 9 Mar 2012 10:34:22 +0200 (EET) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 10:34:21 +0200 Message-Id: <473CE97F-C262-453A-80F2-9BD14C4AE6E4@iki.fi> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [tcpm] Draft TCPM agenda for IETF-83 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 08:34:31 -0000 Hi, Below is the current draft agenda for the Paris meeting. It starts to be = quite full, but let us know if something is missing, and we'll see if we = can squeeze it in. - Pasi ----------- Draft TCPM agenda for IETF-83 / Paris, France Friday, March 30, 2012, 09:00 -- 11:00 -------------------------------------- Admin (15 mins) ----- * Agenda bash & WG status (5 min) chairs * TCPM Rechartering discussion (10 min) chairs WG items (65 mins) -------- * TCP Fast Open (15 min) draft-ietf-tcpm-fastopen-00 Jerry Chu * Increasing TCP's Initial Window (15 min) draft-ietf-tcpm-initcwnd-03 Jerry Chu * IW10 in Low Bandwidth Environments (15 min) (related to draft-ietf-tcpm-initcwnd-03) Hagen Paul Pfeifer * Security Assessment of TCP (15 min) draft-ietf-tcpm-tcp-security-02 Fernando Gont * Proportional Rate Reduction (5 min) draft-ietf-tcpm-proportional-rate-reduction-01 Matt Mathis Other items (30 mins) ----------- * Laminar TCP (15 min) draft-mathis-tcpm-tcp-laminar-00 Matt Mathis * NAT functional extension for address resource restricted environment = (15 min) draft-naito-nat-resource-optimizing-extension-00 Kengo Naito ------------- Total: 110 min From wes@mti-systems.com Fri Mar 9 20:22:13 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BEB21F85D7 for ; Fri, 9 Mar 2012 20:22:13 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4THs7kww26n for ; Fri, 9 Mar 2012 20:22:12 -0800 (PST) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA4F21F8557 for ; Fri, 9 Mar 2012 20:22:12 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2A4MBHa030760 for ; Fri, 9 Mar 2012 23:22:11 -0500 Authentication-Results: cm-omr7 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [69.81.143.202] ([69.81.143.202:42154] helo=[192.168.1.106]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 34/6A-29124-3F6DA5F4; Fri, 09 Mar 2012 23:22:11 -0500 Message-ID: <4F5AD696.8060002@mti-systems.com> Date: Fri, 09 Mar 2012 23:20:38 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: draft-ietf-tcpm-rfc3517bis@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: [tcpm] AD review of draft-ietf-tcpm-rfc3517bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 04:22:13 -0000 I have completed AD review of the 3517bis document. I only have a few small, editorial comments. Only the first one is important to address before moving the document forward, the other two are just personal nits that you're free to ignore if you feel otherwise. (1) The title page is missing some headers: Obsoletes: RFC 3517 Updates: RFC 5681 (?) (2) I believe the Introduction should say something about the status of this document as a replacement for 3517 and refer the reader to the later Section 9 for the detailed discussion of the changes. (3) In several places in Section 5, it seems like the notation "1 SMSS" could be simplified to just "SMSS", but I don't think this is a big deal if others prefer the 1 for some reason, but it seems like notational noise to me. -- Wes Eddy MTI Systems From nishida@sfc.wide.ad.jp Sun Mar 11 21:20:27 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC9B21F855F for ; Sun, 11 Mar 2012 21:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.546 X-Spam-Level: X-Spam-Status: No, score=-98.546 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxFUmPD5t4h5 for ; Sun, 11 Mar 2012 21:20:26 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3E06221F852D for ; Sun, 11 Mar 2012 21:20:26 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A2EFD278097 for ; Mon, 12 Mar 2012 13:20:21 +0900 (JST) Received: by lbol12 with SMTP id l12so984696lbo.31 for ; Sun, 11 Mar 2012 21:20:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.98.198 with SMTP id ek6mr2398862lbb.4.1331526018779; Sun, 11 Mar 2012 21:20:18 -0700 (PDT) Received: by 10.112.63.174 with HTTP; Sun, 11 Mar 2012 21:20:18 -0700 (PDT) In-Reply-To: <4F556156.6030803@lab.ntt.co.jp> References: <20120305125040.13625.47540.idtracker@ietfa.amsl.com> <4F556156.6030803@lab.ntt.co.jp> Date: Sun, 11 Mar 2012 21:20:18 -0700 Message-ID: From: Yoshifumi Nishida To: Kengo Naito Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-naito-nat-resource-optimizing-extension-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 04:20:27 -0000 Hello Mr. Naito, I believe the draft aims to solve the following issue. If server performs active close, it will enter into TIME_WAIT and keep connection info for 2MSL. if client or NAT picks the same port for a new connection to the server during this 2MSL period, the connection attempt will be rejected. On busy NAT boxes, this will prone to happen. I think there are 3 entities in this draft: TCP client, TCP server and NAT. I think it would be better to articulate which entity your proposals are aiming. I think the section 2.1 describes the behavior of NAT. This seems to be a bit out of scope for tcpm. The section 2.2 seems to describe the behavior of tcp server, although the section title seems to indicate updating the behavior of NAT. In addition, in order to make this work properly, I think client, NAT and server will need to support rfc6191. But, the deployment of this approach looks difficult. The authors might need to describe the case where this approach doesn't work. Also, can we use the approach described in the section 4.2.2.13 of rfc1122 instead of rfc6191? Thanks, -- Yoshifumi Nishida On Mon, Mar 5, 2012 at 4:59 PM, Kengo Naito wro= te: > Pasi, > tcpm members, > > Hi, I wrote a new draft written below. > > https://datatracker.ietf.org/doc/draft-naito-nat-resource-optimizing-exte= nsion/?include_text=3D1 > > I've already asked Pasi for adding this discussion to Agenda, Paris. > There's some topic I want to add to my draft, which I'll do so by Paris. > (which I wrote like "I'll write this part by Paris" in 00 version) > > I would appreciate your comments and advice. > > Best regards, > > > (2012/03/05 21:50), internet-drafts@ietf.org wrote: >> >> A new version of I-D, draft-naito-nat-resource-optimizing-extension-00.t= xt >> has been successfully submitted by Kengo and posted to the IETF reposito= ry. >> >> Filename: =A0 =A0 =A0 =A0draft-naito-nat-resource-optimizing-extension >> Revision: =A0 =A0 =A0 =A000 >> Title: =A0 =A0 =A0 =A0 =A0 NAT resource optimizing extension >> Creation date: =A0 2012-03-05 >> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission >> Number of pages: 4 >> >> Abstract: >> =A0 =A0When NAT is used in address resource restricted environment, or w= hen >> =A0 =A0a lot of users are located under a NAT device, IP address and por= t >> =A0 =A0resources may be eaten up, and it brings severe bad effects on us= er >> =A0 =A0experiences. =A0This situation can be greatly mitigated by tweaki= ng >> =A0 =A0mapping behavior and session timer handling at NAT function. =A0T= his >> =A0 =A0document proposes to NAT IP address and port resource optimizing >> =A0 =A0extension for address resource restricted environment. =A0One ext= ension >> =A0 =A0is to enable simultaneous use of a port for different transport >> =A0 =A0sessions, and the other is to make use of TCP timestamp for TIME_= WAIT >> =A0 =A0Assassination. >> >> >> >> >> The IETF Secretariat >> >> > > > -- > ---------------------------------------- > NTT Service Integration Laboratories > Kengo Naito > E-Mail: naito.kengo@lab.ntt.co.jp > TEL: +81 422-59-4949 > ---------------------------------------- > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From internet-drafts@ietf.org Mon Mar 12 17:00:59 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E837821E82BA; Mon, 12 Mar 2012 17:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LoCzYdruynk; Mon, 12 Mar 2012 17:00:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F9721E82B6; Mon, 12 Mar 2012 17:00:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120313000058.5364.42642.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 17:00:58 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-security-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 00:00:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : Survey of Security Hardening Methods for Transmission Co= ntrol Protocol (TCP) Implementations Author(s) : Fernando Gont Filename : draft-ietf-tcpm-tcp-security-03.txt Pages : 86 Date : 2012-03-12 This document surveys methods to harden Transmission Control Protocol (TCP) implementations. It provides an overview of known attacks and refers to the corresponding solutions in the TCP standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-security-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-security-03.txt From fernando.gont.netbook.win@gmail.com Mon Mar 12 18:44:57 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF221F87D2 for ; Mon, 12 Mar 2012 18:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y4XtT+-L2BT for ; Mon, 12 Mar 2012 18:44:57 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2279421F87CD for ; Mon, 12 Mar 2012 18:44:56 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so3754214wib.13 for ; Mon, 12 Mar 2012 18:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=WNGWQf8MUK1GYweIeRYcIDO88g2T/Hu95gD6s5iJqBE=; b=E9QsHbfK8AHnViGQYlUPGVbELAEpOC2AwxDsJKnz8HHYkS+KK4ndPMgykkzLu96KAi HJcuJDRCHJLdHBKEanGOv7A9TMWxVwOt1rQqgXAGuL9KZA8mrg8TfrKk4UCUUynCowZI fDM4SIfr5J0Sz/dSGp3wtMHSTKJa8EeaGcSrmnaZKobtqer6wjreGbJ9u9lJ5vFx5V9G 1y7hKce4OiCcYZlmLKS0IWqOLEYasaqW49DvvaWeEvVaUlMk6JDDoyCVr6P41QRRUEzX yj0FH9BoTwsrYJLHOP8bvaNCHjy9JWTiI6/vk1yRjjbFilXRRxyuOvqP9IyJoQNjds7C Q9zg== Received: by 10.216.132.98 with SMTP id n76mr8308766wei.101.1331603096264; Mon, 12 Mar 2012 18:44:56 -0700 (PDT) Received: from [172.21.24.34] (46-37-55-80.dsl.cnl.uk.net. [46.37.55.80]) by mx.google.com with ESMTPS id p10sm1149289wic.0.2012.03.12.18.44.54 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 18:44:55 -0700 (PDT) Sender: Fernando Gont Message-ID: <4F5EA694.50208@gont.com.ar> Date: Mon, 12 Mar 2012 22:44:52 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tcpm] Update of the tcp-security I-D X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 01:44:58 -0000 Folks, I've posted an update of the aforementioned I-D. Some of the big changes are: * The document track has been changed from BCP to Informational * Lots of text has been removed from the document -- particularly that which repeated or summarized stuff already present in the RFC series * Those parts that fitted into bcp/std track have been extracted, and will be published in stand-alone documents, such that rather than having a large document updating lots of specs, we have small and manageable documents making small updates to the specs. * There's still quite a bit of polishing to do in the document (in general), and the last sections in particular (Section >9) need heavy editing -- but hopefully it is more clear now where we're heading (and hopefully there's better consensus in that area). Any feedback on the general approach will be welcomed. Regarding the technical contents, since there's quite a bit of stuff to discuss, I'd appreciate if the technical discussion focused on each of the spin-off documents rather than on draft-ietf-tcpm-tcp-security (which I plan rev again soon). Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Mon Mar 12 18:55:09 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C89921F8861 for ; Mon, 12 Mar 2012 18:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jctAU27HjFQe for ; Mon, 12 Mar 2012 18:55:08 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 453B321F8846 for ; Mon, 12 Mar 2012 18:55:08 -0700 (PDT) Received: by werb10 with SMTP id b10so30732wer.31 for ; Mon, 12 Mar 2012 18:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=lmFrYDiYfmN0y9jzS+Ls8LF1Cur5LpO+tfYPCKawCNQ=; b=hHcKCq7nnKdqFvR7vFCnulYdAbh58anVBL9QwO5F96y8OsXHa4m33YBlJHNV+KGL/W ySqsQwW5QLYfw5U47NERQ5wX9u9tZfRWHDi7mQbEgXrgPaVMg9r6eCbNuawqtYpIlA8o Gk8sChXKhL55DyQGU324Bf2jEuJ6zWT/NkpTJ/Umys9/0os6TNUPaRbn7yhwzGMbYWSc cuf1shwsO8VM8CFJfo84SYEjpZXtC84TQk85HbU8QSrSxMZRM2tdswomZCQNWA6YaHFE kZNJKRo9NuhCos8DwSJ1A7jJ9l0GTlz39Kxj6099GAmzpQZOwwCW4iynQmm+6nVU6xxt aTYA== Received: by 10.180.102.231 with SMTP id fr7mr2828876wib.10.1331603707475; Mon, 12 Mar 2012 18:55:07 -0700 (PDT) Received: from [172.21.24.34] (46-37-55-80.dsl.cnl.uk.net. [46.37.55.80]) by mx.google.com with ESMTPS id t20sm66176755wiv.0.2012.03.12.18.55.04 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 18:55:06 -0700 (PDT) Sender: Fernando Gont Message-ID: <4F5EA8F7.8010004@gont.com.ar> Date: Mon, 12 Mar 2012 22:55:03 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tcpm] Processing of IP Security Compartment and Precedence information by TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 01:55:09 -0000 Folks, One of the spin-off documents from the tcp-security I-D is entitled "Processing of IP Security/Compartment and Precedence Information by TCP" Its abstract says: ---- cut here ---- This document discusses the security and interoperability problems that may arise as a result of the processing of IP security/ compartment and precedence information by TCP. Additionally, it formally updates RFC 793 such that these issues are mitigated. ---- cut here ---- The I-D is currently available at (it will become available on the IETF repositories when submission of version -00 documents is re-enabled in a couple of weeks). Of course, any feedback will be appreciated. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Mon Mar 12 19:11:24 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8DA21F88D0 for ; Mon, 12 Mar 2012 19:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KfeEjPri7XX for ; Mon, 12 Mar 2012 19:11:23 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6197221F88C9 for ; Mon, 12 Mar 2012 19:11:23 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so36260wib.13 for ; Mon, 12 Mar 2012 19:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=iE1nRWRr5MA6fnRG2OGS0Rh+4a78Z/VOpf3f+0IyLQA=; b=z4GgxizMzRhmJEayFFA9jhtxIib605DDloGYYaRU4KOfV4YzfrnnhQopuJyDxDl1GU OSby/SzwWG7/TYnzXer6Q9ZJgeXm8HZlfFVb/48At0+3EupfkVrEqIPQM1ePqb/uPQdg HdGFzkJceI1saoutVdRdNB6uH5J+9N8Cv2Ib+1Ksmr9evNzZaoM2M0nEI9y5uM5cZA5U Ltsxx/FTXuxAvwUZHpM8Hs3jva400N2LoHc1ehadIAIWXTJc7YvCuW2YXq9C+gzFjzeE RWdxHtMKPi/IdIbg06oNid12XCLeKow1DnlxlZFg48iXTkPRXDni4jXydOSL9UoZGTB4 NRyg== Received: by 10.180.87.8 with SMTP id t8mr2904314wiz.15.1331604682617; Mon, 12 Mar 2012 19:11:22 -0700 (PDT) Received: from [172.21.24.34] (46-37-55-80.dsl.cnl.uk.net. [46.37.55.80]) by mx.google.com with ESMTPS id n15sm38958552wiw.6.2012.03.12.19.11.20 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 19:11:21 -0700 (PDT) Sender: Fernando Gont Message-ID: <4F5EACC7.3090200@gont.com.ar> Date: Mon, 12 Mar 2012 23:11:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tcpm] Processing of TCP segments with Mirrored End-points X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 02:11:24 -0000 Folks, [Yet another of the spin-off document from the tcp-security I-D] I've published an I-D entitled "Processing of TCP segments with Mirrored End-points". The Abstract of the I-D is: ---- cut here ---- This document describes a problem found in some popular implementations regarding the processing of TCP segments in which the local endpoint is equal to the remote endpoint. Additionally, it formally updates RFC 793 clarifying how this scenario should be handled. ---- cut here ---- The I-D is currently available at: Any feedback will be greatly appreciated. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From naito.kengo@lab.ntt.co.jp Tue Mar 13 02:51:50 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBB521F8705 for ; Tue, 13 Mar 2012 02:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v84RGk1Qcf4o for ; Tue, 13 Mar 2012 02:51:49 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9F921F86D7 for ; Tue, 13 Mar 2012 02:51:49 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q2D9plI7029728; Tue, 13 Mar 2012 18:51:47 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id C04676840; Tue, 13 Mar 2012 18:51:47 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B9D366831; Tue, 13 Mar 2012 18:51:47 +0900 (JST) Received: from [127.0.0.1] ([129.60.7.245]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q2D9pkHK001833; Tue, 13 Mar 2012 18:51:47 +0900 Message-ID: <4F5F181F.2010201@lab.ntt.co.jp> Date: Tue, 13 Mar 2012 18:49:19 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Yoshifumi Nishida , tcpm@ietf.org References: <20120305125040.13625.47540.idtracker@ietfa.amsl.com> <4F556156.6030803@lab.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] New Version Notification for draft-naito-nat-resource-optimizing-extension-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 09:51:50 -0000 Hello Mr.Nishida, Thank you for your advice. Sorry some part of my draft is not ready. I'll write the answer below, (2012/03/12 13:20), Yoshifumi Nishida wrote: > Hello Mr. Naito, > > I believe the draft aims to solve the following issue. > If server performs active close, it will enter into TIME_WAIT and keep > connection info for 2MSL. if client or NAT picks the same port for a > new connection to the server during this 2MSL period, the connection > attempt will be rejected. On busy NAT boxes, this will prone to > happen. Well, this may be a problem, but in my draft I focus on NAT equipment, which resource is restricted. Problem I state is TIME_WAIT entered into at NAT equipment, and it disables new connection. > > I think there are 3 entities in this draft: TCP client, TCP server and > NAT. I think it would be better to articulate which entity your > proposals are aiming. OK. I'll write it in my slides for Paris meeting. > I think the section 2.1 describes the behavior of NAT. This seems to > be a bit out of scope for tcpm. I'm also talking with chairman in behave WG. I'll discuss this part at behave. > > The section 2.2 seems to describe the behavior of tcp server, although > the section title seems to indicate updating the behavior of NAT. > In addition, in order to make this work properly, I think client, NAT > and server will need to support rfc6191. But, the deployment of this > approach looks difficult. The authors might need to describe the case > where this approach doesn't work. OK. I'll write it in my slides for Paris meeting. > Also, can we use the approach described in the section 4.2.2.13 of > rfc1122 instead of rfc6191? As written in rfc6191, we may use sequence number to terminate TIME_WAIT, but rfc6191 tries to prevent the overlap of the sequence number. So, in my opinion, it is preferable to use timestamp option. regards, > > Thanks, > -- > Yoshifumi Nishida > > > On Mon, Mar 5, 2012 at 4:59 PM, Kengo Naito wrote: >> Pasi, >> tcpm members, >> >> Hi, I wrote a new draft written below. >> >> https://datatracker.ietf.org/doc/draft-naito-nat-resource-optimizing-extension/?include_text=1 >> >> I've already asked Pasi for adding this discussion to Agenda, Paris. >> There's some topic I want to add to my draft, which I'll do so by Paris. >> (which I wrote like "I'll write this part by Paris" in 00 version) >> >> I would appreciate your comments and advice. >> >> Best regards, >> >> >> (2012/03/05 21:50), internet-drafts@ietf.org wrote: >>> A new version of I-D, draft-naito-nat-resource-optimizing-extension-00.txt >>> has been successfully submitted by Kengo and posted to the IETF repository. >>> >>> Filename: draft-naito-nat-resource-optimizing-extension >>> Revision: 00 >>> Title: NAT resource optimizing extension >>> Creation date: 2012-03-05 >>> WG ID: Individual Submission >>> Number of pages: 4 >>> >>> Abstract: >>> When NAT is used in address resource restricted environment, or when >>> a lot of users are located under a NAT device, IP address and port >>> resources may be eaten up, and it brings severe bad effects on user >>> experiences. This situation can be greatly mitigated by tweaking >>> mapping behavior and session timer handling at NAT function. This >>> document proposes to NAT IP address and port resource optimizing >>> extension for address resource restricted environment. One extension >>> is to enable simultaneous use of a port for different transport >>> sessions, and the other is to make use of TCP timestamp for TIME_WAIT >>> Assassination. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >> >> -- >> ---------------------------------------- >> NTT Service Integration Laboratories >> Kengo Naito >> E-Mail: naito.kengo@lab.ntt.co.jp >> TEL: +81 422-59-4949 >> ---------------------------------------- >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > -- ---------------------------------------- NTT Service Integration Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- From Al.Smith@unisys.com Tue Mar 13 06:41:32 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7874621F88D8 for ; Tue, 13 Mar 2012 06:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krFitoBROIA6 for ; Tue, 13 Mar 2012 06:41:31 -0700 (PDT) Received: from mail46.messagelabs.com (mail46.messagelabs.com [216.82.241.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA9C21F88D7 for ; Tue, 13 Mar 2012 06:41:31 -0700 (PDT) X-Env-Sender: Al.Smith@unisys.com X-Msg-Ref: server-7.tower-46.messagelabs.com!1331646086!20769963!17 X-Originating-IP: [192.61.61.105] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24960 invoked from network); 13 Mar 2012 13:41:29 -0000 Received: from naedge.unisys.com (HELO USEA-NAEDGE2.unisys.com) (192.61.61.105) by server-7.tower-46.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2012 13:41:29 -0000 Received: from usea-nahubcas1.na.uis.unisys.com (129.224.76.114) by USEA-NAEDGE2.unisys.com (192.61.61.105) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 13 Mar 2012 08:41:14 -0500 Received: from USEA-EXCH7.na.uis.unisys.com ([129.224.76.38]) by usea-nahubcas1.na.uis.unisys.com ([129.224.76.114]) with mapi; Tue, 13 Mar 2012 08:41:13 -0500 From: "Smith, Allyn D" To: Fernando Gont , "tcpm@ietf.org" Date: Tue, 13 Mar 2012 08:41:13 -0500 Thread-Topic: [tcpm] Processing of IP Security Compartment and Precedence information by TCP Thread-Index: Ac0AvF5sIZw50IiPTeK+R5BCpKhc0QAYPy4A Message-ID: References: <4F5EA8F7.8010004@gont.com.ar> In-Reply-To: <4F5EA8F7.8010004@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] Processing of IP Security Compartment and Precedence information by TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 13:41:32 -0000 Fernando, In your document, you may want to refer to RFC 2873, TCP Processing of the = IPv4 Precedence Field. RFC 2873 attempts to reconcile the IP precedence, T= OS, and DS field conflict. In summary, here is the resolution from the RFC= which also addresses security concerns: 4. Proposed Modification to TCP The proposed modification to TCP is that TCP must ignore the precedence of all received segments. .... Best regards, Al Smith =A0=20 Al Smith=A0 |=A0 Principal Engineer=A0 |=A0 Operating Systems Development -= Networking Unisys=A0 |=A0 2470 Highcrest Road=A0 |=A0 Roseville, MN USA 55113=A0 =A0 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MA= TERIAL and is thus for use only by the intended recipient. If you received = this in error, please contact the sender and delete the e-mail and its atta= chments from all computers.=20 -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Fer= nando Gont Sent: Monday, March 12, 2012 8:55 PM To: tcpm@ietf.org Subject: [tcpm] Processing of IP Security Compartment and Precedence inform= ation by TCP Folks, One of the spin-off documents from the tcp-security I-D is entitled "Processing of IP Security/Compartment and Precedence Information by TCP" Its abstract says: ---- cut here ---- This document discusses the security and interoperability problems that may arise as a result of the processing of IP security/ compartment and precedence information by TCP. Additionally, it formally updates RFC 793 such that these issues are mitigated. ---- cut here ---- The I-D is currently available at (it will become available on the IETF repositories when submission of version -00 documents is re-enabled in a couple of weeks). Of course, any feedback will be appreciated. Thanks! Best regards, --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From fernando.gont.netbook.win@gmail.com Tue Mar 13 06:56:51 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E7821F888F for ; Tue, 13 Mar 2012 06:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GunZSbCfMAFG for ; Tue, 13 Mar 2012 06:56:50 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 302E021F8887 for ; Tue, 13 Mar 2012 06:56:50 -0700 (PDT) Received: by bkuw5 with SMTP id w5so514642bku.31 for ; Tue, 13 Mar 2012 06:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=irWDg5C7yvum9Hz2r4ZTES0YQmEJposem+6fRWqyu4I=; b=KvX63brzttoFbPGq4foO4HG+k/E/kY7muNiluuidKjayVBXS8cIcu+aF3QLF9U4klK pEPy90WVrxGcE5+uZj6Uz7ENfvMBfpEhDhyMJWI4L30D1Wn79UXTRQT56n2nIdw/jXY8 QHySHC1t2fhYqdepVtf2WUlIWvcsdimy9Wj1d5+zOqDLmGt3djAMe5GUcJwgI2f+hwRs 5wz5r/p8jYrXyXkFag7Wi/rRl8+Z81xBriQUiRFkRv0BjLSQV0LkbKDTD8eCKXYUc/op ukWu7W9dfwJvVjSQP1BYsZuEU+t663e3AT8bvALTpkliZOFm6o2p0+/kQXY0DzrIoSrp +5lg== Received: by 10.204.155.73 with SMTP id r9mr2864809bkw.22.1331647009210; Tue, 13 Mar 2012 06:56:49 -0700 (PDT) Received: from [172.21.24.196] (46-37-55-80.dsl.cnl.uk.net. [46.37.55.80]) by mx.google.com with ESMTPS id bw9sm1623843bkb.8.2012.03.13.06.56.46 (version=SSLv3 cipher=OTHER); Tue, 13 Mar 2012 06:56:48 -0700 (PDT) Sender: Fernando Gont Message-ID: <4F5F521C.6050305@gont.com.ar> Date: Tue, 13 Mar 2012 10:56:44 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "Smith, Allyn D" References: <4F5EA8F7.8010004@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Processing of IP Security Compartment and Precedence information by TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 13:56:51 -0000 Hi, Al, Thanks for your timely feedback! Please find my comment in-line... On 03/13/2012 10:41 AM, Smith, Allyn D wrote: > In your document, you may want to refer to RFC 2873, TCP Processing > of the IPv4 Precedence Field. RFC 2873 attempts to reconcile the IP > precedence, TOS, and DS field conflict. Agreed. -- I wonder how I missed this one... :-( In any case, it seems that RFC2873 does not contain "Updates" metadata, and does not include RFC2119-language requirements. So how about this: I can keep the discussion/rationale of the Precedence field brief (pointing to RFC2873), and simply include a short RFC2119-language requirement stating that the Precedence information should be disregarded. Thoughts? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From michawe@ifi.uio.no Tue Mar 13 07:11:31 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4EA21F8881 for ; Tue, 13 Mar 2012 07:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_OFF=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAdz4DZRc7PZ for ; Tue, 13 Mar 2012 07:11:31 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id E965121F8880 for ; Tue, 13 Mar 2012 07:11:30 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1S7SRl-0007SV-H1 for tcpm@ietf.org; Tue, 13 Mar 2012 15:11:29 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtp (Exim 4.76) (envelope-from ) id 1S7SRl-0003LZ-6D for tcpm@ietf.org; Tue, 13 Mar 2012 15:11:29 +0100 Message-ID: <4F5F5591.6020202@ifi.uio.no> Date: Tue, 13 Mar 2012 15:11:29 +0100 From: Michael Welzl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 18184 max rcpts/h 45 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 76D856882DA69FB32DD99C1900BEB6813575C6D7 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7755 max/h 19 blacklist 0 greylist 0 ratelimit 0 Subject: [tcpm] Review of draft-ietf-tcpm-proportional-rate-reduction-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 14:11:31 -0000 Hi all, I just read this draft, and don't see any problems with it. I don't have the same insight into the Linux implementation details as Mirja, and so I might have missed some issues - like the ones that Mirja pointed out, which I found to be very sound criticism, but which was in my opinion also amply answered by Matt. So, as a reader who was convinced by the document that this is a good idea, what's left for me to comment on is nits, and nothing but nits. They're below. Cheers, Michael ----- abstract: remove first "that" in "that such that the number of ACKs" intro: par 2: "It's stated goal" => "Its stated goal" further down: "...expected behavior would be _to_ wait for half _a_ window of ACKs to pass..." par 3: Rate-having => Rate-halving par 4: remove comma before ssthresh next sentence: "appropriate for _the_ target window chosen..." section 3, algorithm description: why i think it's understandable what's meant with it, the function "delta" isn't defined or described anywhere, and this should be done. section 3.1: "In all cases we assume bulk data, ..." => I guess what you mean is that you assume a greedy sender transmitting bulk data, and I would suggest that phrase instead. par underneath the first example graphs: "Note that all three algorithms send _the_ same total amount of data" par no. 3 below the next example graphs: "PRR_CRB implements _a_ conservative reduction bound" next par: "remember that this _is_ actually less aggressive..." about the graphs, what's the intuition behind the use of "f" and "d" for RB? This would be easier to read if one would understand the logic behind this choice of letters for the flag (sorry, maybe this is obvious and I just missed it). appendix a: par 4 (the thought experiment): "I mean when a packet is..." => I think this should be "we mean ..." next par: "Any more aggressive algorithm which sends additional data _can_ cause a queue overflow and loss." .... I think this is more precise. next par: remove "of" in "includes appropriately sharing of the network" From Al.Smith@unisys.com Tue Mar 13 08:32:56 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD7921F8949 for ; Tue, 13 Mar 2012 08:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3clXvshhdUl for ; Tue, 13 Mar 2012 08:32:55 -0700 (PDT) Received: from mail51.messagelabs.com (mail51.messagelabs.com [216.82.241.99]) by ietfa.amsl.com (Postfix) with ESMTP id 3311F21F88D2 for ; Tue, 13 Mar 2012 08:32:54 -0700 (PDT) X-Env-Sender: Al.Smith@unisys.com X-Msg-Ref: server-5.tower-51.messagelabs.com!1331652746!7080153!64 X-Originating-IP: [192.61.61.104] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21472 invoked from network); 13 Mar 2012 15:32:45 -0000 Received: from unknown (HELO USEA-NAEDGE1.unisys.com) (192.61.61.104) by server-5.tower-51.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2012 15:32:45 -0000 Received: from usea-nahubcas1.na.uis.unisys.com (129.224.76.114) by USEA-NAEDGE1.unisys.com (192.61.61.104) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 13 Mar 2012 10:32:10 -0500 Received: from USEA-EXCH7.na.uis.unisys.com ([129.224.76.38]) by usea-nahubcas1.na.uis.unisys.com ([129.224.76.114]) with mapi; Tue, 13 Mar 2012 10:32:10 -0500 From: "Smith, Allyn D" To: Fernando Gont Date: Tue, 13 Mar 2012 10:32:09 -0500 Thread-Topic: [tcpm] Processing of IP Security Compartment and Precedence information by TCP Thread-Index: Ac0BISX3OlEPPdluTeiVnQ66Ce4PaAADIfuw Message-ID: References: <4F5EA8F7.8010004@gont.com.ar> <4F5F521C.6050305@gont.com.ar> In-Reply-To: <4F5F521C.6050305@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Processing of IP Security Compartment and Precedence information by TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 15:32:56 -0000 That works for me since RFC2873 is missing the "Updates" metadata and does = not include RFC2119-language requirements. However, I'll reserve final jud= gment to see how everything shakes out within the context of the security s= pin-off documents and the final "TCP security" document. ;-) Regards, Al Smith -----Original Message----- From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On Behalf = Of Fernando Gont Sent: Tuesday, March 13, 2012 8:57 AM To: Smith, Allyn D Cc: tcpm@ietf.org Subject: Re: [tcpm] Processing of IP Security Compartment and Precedence in= formation by TCP Hi, Al, Thanks for your timely feedback! Please find my comment in-line... On 03/13/2012 10:41 AM, Smith, Allyn D wrote: > In your document, you may want to refer to RFC 2873, TCP Processing > of the IPv4 Precedence Field. RFC 2873 attempts to reconcile the IP > precedence, TOS, and DS field conflict. =20 Agreed. -- I wonder how I missed this one... :-( In any case, it seems that RFC2873 does not contain "Updates" metadata, and does not include RFC2119-language requirements. So how about this: I can keep the discussion/rationale of the Precedence field brief (pointing to RFC2873), and simply include a short RFC2119-language requirement stating that the Precedence information should be disregarded. Thoughts? Thanks! Best regards, --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rs@netapp.com Tue Mar 13 12:59:07 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FCE21F850B for ; Tue, 13 Mar 2012 12:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuWAh97e4YUi for ; Tue, 13 Mar 2012 12:59:05 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id C085021F84FE for ; Tue, 13 Mar 2012 12:59:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,579,1325491200"; d="scan'208,217";a="633111856" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 13 Mar 2012 12:58:50 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q2DJwoXv010556; Tue, 13 Mar 2012 12:58:50 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.144]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0247.003; Tue, 13 Mar 2012 12:58:50 -0700 From: "Scheffenegger, Richard" To: "Matthew Mathis (mattmathis@google.com)" Thread-Topic: laminar tcp Thread-Index: Ac0BT3S6sMeKwUOOSwaa1ALlOAVDsg== Date: Tue, 13 Mar 2012 19:58:48 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0CC581@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F0CC581SACEXCMBX02PRDhqn_" MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: [tcpm] laminar tcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 19:59:07 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F0CC581SACEXCMBX02PRDhqn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matt, I'm currently reading your draft, and found a few nits, and two comments/qu= estions: 1.1: s/simpler simpler/simpler/ 1.2: s/to to/to/ 3.2: s/WIth standard TCP, any application stall reducs/With ... reduces/ 4: s/MAX_WINOW/MAX_WIN/ Ad Section 3.6: I think you are aiming at MPTCP here, correct? I think the text, as written, is really only relevant when you know (automa= gically) that the congestion control triggering event was somewhere along a= common path of these separate TCP flows... I.e. same sending interface, s= ame destination, same source or destination network. It may be worthwhile t= o explicitly spell out the intent here (ie. RFC2140 has host-pair only). Ad section 3.7: Another comment: The text of the draft appears to operate on packet units, = rather than byte units (which may complicate things, in particular if the f= low consists of non-uniform sized packets). Then again, the sample code app= ears to work on byte units. Perhaps the text can be checked again that it t= alks about byte (or packet) oriented implementations for consistency. For t= he non-SACK example, will laminar deviate much if SMSS is assumed to have = left the network on a DUP ACK, even if only a smaller packet triggered the = ACK? Best regards, Richard Scheffenegger --_000_012C3117EDDB3C4781FD802A8C27DD4F0CC581SACEXCMBX02PRDhqn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Matt,
 
I’m currently reading your draft, and found a few nits, and two = comments/questions:
 
 
= 1.1: s/simpler simpler/simpler/
1.2:    s/to to/to/
= 3.2: s/WIth standard TCP, any application stall reducs/With … reduces= /
= 4: s/MAX_WINOW/MAX_WIN/
=  
 
Ad Section 3.6:
 
I think you are aiming at MPTCP here, correct?
I think the text, as written, is really only relevant when you know (a= utomagically) that the congestion control triggering event was somewhere al= ong a common path of these separate TCP flows…  I.e. same sendin= g interface, same destination, same source or destination network. It may be worthwhile to explicitly spell out the in= tent here (ie. RFC2140 has host-pair only).
 
Ad section 3.7:
Another comment: The text of the draft appears to operate on packet un= its, rather than byte units (which may complicate things, in particular if = the flow consists of non-uniform sized packets). Then again, the sample cod= e appears to work on byte units. Perhaps the text can be checked again that it talks about byte (or packet) = oriented implementations for consistency. For the non-SACK example,  w= ill laminar deviate much if SMSS is assumed to have left the network on a D= UP ACK, even if only a smaller packet triggered the ACK?
 
Best regards,
 
Richard Scheffenegger
 
 --_000_012C3117EDDB3C4781FD802A8C27DD4F0CC581SACEXCMBX02PRDhqn_-- From nishida@sfc.wide.ad.jp Tue Mar 13 13:05:50 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812D021F86AB for ; Tue, 13 Mar 2012 13:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.541 X-Spam-Level: X-Spam-Status: No, score=-98.541 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1Sz1nTOTedq for ; Tue, 13 Mar 2012 13:05:49 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4E921F86AA for ; Tue, 13 Mar 2012 13:05:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 898EC2780D0 for ; Wed, 14 Mar 2012 05:05:45 +0900 (JST) Received: by lbol12 with SMTP id l12so526213lbo.31 for ; Tue, 13 Mar 2012 13:05:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.103.12 with SMTP id fs12mr6057721lab.47.1331669143111; Tue, 13 Mar 2012 13:05:43 -0700 (PDT) Received: by 10.112.63.174 with HTTP; Tue, 13 Mar 2012 13:05:43 -0700 (PDT) In-Reply-To: <4F5F181F.2010201@lab.ntt.co.jp> References: <20120305125040.13625.47540.idtracker@ietfa.amsl.com> <4F556156.6030803@lab.ntt.co.jp> <4F5F181F.2010201@lab.ntt.co.jp> Date: Tue, 13 Mar 2012 13:05:43 -0700 Message-ID: From: Yoshifumi Nishida To: Kengo Naito Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-naito-nat-resource-optimizing-extension-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 20:05:50 -0000 Hello Mr. Naito, Thanks for your reply. On Tue, Mar 13, 2012 at 2:49 AM, Kengo Naito wr= ote: > Hello Mr.Nishida, > > Thank you for your advice. > Sorry some part of my draft is not ready. > I'll write the answer below, > > (2012/03/12 13:20), Yoshifumi Nishida wrote: >> >> Hello Mr. Naito, >> >> I believe the draft aims to solve the following issue. >> If server performs active close, it will enter into TIME_WAIT and keep >> connection info for 2MSL. if client or NAT picks the same port for a >> new connection to the server during this 2MSL period, =A0the connection >> attempt will be rejected. On busy NAT boxes, this will prone to >> happen. > > Well, this may be a problem, but in my draft I focus on NAT equipment, > which resource is restricted. > Problem I state is TIME_WAIT entered into at NAT equipment, > and it disables new connection. hmm. Do you mean a NAT box maintains TIME_WAIT state just like TCP? Or, does this mean tcp proxies? Could you elaborate a bit? >> Also, can we use the approach described in the section 4.2.2.13 of >> rfc1122 instead of rfc6191? > > As written in rfc6191, we may use sequence number to terminate TIME_WAIT, > =A0but rfc6191 tries to prevent the overlap of the sequence number. > So, in my opinion, it is preferable to use timestamp option. I think the preference is fine. I just thought you might want to state if it can be used or not since both address the same issue. Thanks, -- Yoshifumi Nishida From michawe@ifi.uio.no Wed Mar 14 03:12:55 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04C121F868C for ; Wed, 14 Mar 2012 03:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpMEPbo3XxL3 for ; Wed, 14 Mar 2012 03:12:54 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 7819E21F8675 for ; Wed, 14 Mar 2012 03:12:54 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1S7lCP-0001wQ-1P for tcpm@ietf.org; Wed, 14 Mar 2012 11:12:53 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtp (Exim 4.76) (envelope-from ) id 1S7lCO-0001Xu-Jk for tcpm@ietf.org; Wed, 14 Mar 2012 11:12:53 +0100 Message-ID: <4F606F24.2090103@ifi.uio.no> Date: Wed, 14 Mar 2012 11:12:52 +0100 From: Michael Welzl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: tcpm@ietf.org References: <012C3117EDDB3C4781FD802A8C27DD4F0CC581@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0CC581@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 5 sum msgs/h 3 total rcpts 18202 max rcpts/h 45 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 45587AC82B7162CC5043DC82B3D2419BC7E91B55 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7770 max/h 19 blacklist 0 greylist 0 ratelimit 0 Subject: [tcpm] laminar tcp, separate thread X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 10:12:55 -0000 Hi, I also read Laminar TCP now, and I applaud! This is great stuff! As for the document itself, while this certainly forms a good basis for discussion, if I imagine that being an RFC, I would say that it's too messy, in several ways: 1) I think that most of what this document does is just to provide guidance to application designers, i.e. it could be an informational description of how a TCP could be implemented in an easier and more modern fashion. There doesn't seem to bee much in it, now, that is (as the abstract says) "technically in violation of all existing TCP standards"? I mean, does counting packets instead of bytes make Linux TCP in violation of the standards? I guess not... similarly, would I violate standards if I call ssthresh "xythresh" in my implementation? I guess not... so I think that only behavioral changes really affect the rules laid out by the other TCP RFCs. That would, then, only concern the behavior when TCP is application-limited, I think, and that would perhaps only update RFC 2861 :-) Of course, if that would really lead to an RFC updating not much more than RFC 2861 and one or two others, one would have to make pretty damn sure that the behavior of Laminar REALLY doesn't diverge from the standards in any other way. 2) You seem to have made a rather arbitrary selection of algorithms that you survey in section 3 - e.g., why mention F-RTO and not Eifel? Anyway both really don't seem to have much to do with Laminar... and which RFC defines "Undo"? I guess what you mean is the Eifel Response algorithm. 3) I find your mention of aggressiveness, Tragedy of the Commons etc. out of place. It just strikes me as unrelated. I also think it's weird to mention the de-obfuscation of code achieved with Laminar as a possible security concern :-) Again, all of these comments concern only the document writing style and structure, not the technical idea, which I think is just beautiful. Cheers, Michael From naito.kengo@lab.ntt.co.jp Thu Mar 15 04:15:24 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E15821F8571 for ; Thu, 15 Mar 2012 04:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzbXMH-sHtPG for ; Thu, 15 Mar 2012 04:15:24 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 9C16121F856F for ; Thu, 15 Mar 2012 04:15:23 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.14.5/8.14.5) with ESMTP id q2FBFMHo004932; Thu, 15 Mar 2012 20:15:22 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 483E0E0088; Thu, 15 Mar 2012 20:15:22 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 3CB47E006F; Thu, 15 Mar 2012 20:15:22 +0900 (JST) Received: from [127.0.0.1] ([129.60.7.245]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q2FBFLKj019505; Thu, 15 Mar 2012 20:15:22 +0900 Message-ID: <4F61CEB4.8020207@lab.ntt.co.jp> Date: Thu, 15 Mar 2012 20:12:52 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Yoshifumi Nishida , tcpm@ietf.org References: <20120305125040.13625.47540.idtracker@ietfa.amsl.com> <4F556156.6030803@lab.ntt.co.jp> <4F5F181F.2010201@lab.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] New Version Notification for draft-naito-nat-resource-optimizing-extension-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2012 11:15:24 -0000 Hi Mr.Nishida, (2012/03/14 5:05), Yoshifumi Nishida wrote: > Hello Mr. Naito, > > Thanks for your reply. > > On Tue, Mar 13, 2012 at 2:49 AM, Kengo Naito wrote: >> Hello Mr.Nishida, >> >> Thank you for your advice. >> Sorry some part of my draft is not ready. >> I'll write the answer below, >> >> (2012/03/12 13:20), Yoshifumi Nishida wrote: >>> Hello Mr. Naito, >>> >>> I believe the draft aims to solve the following issue. >>> If server performs active close, it will enter into TIME_WAIT and keep >>> connection info for 2MSL. if client or NAT picks the same port for a >>> new connection to the server during this 2MSL period, the connection >>> attempt will be rejected. On busy NAT boxes, this will prone to >>> happen. >> Well, this may be a problem, but in my draft I focus on NAT equipment, >> which resource is restricted. >> Problem I state is TIME_WAIT entered into at NAT equipment, >> and it disables new connection. > hmm. Do you mean a NAT box maintains TIME_WAIT state just like TCP? > Or, does this mean tcp proxies? Could you elaborate a bit? I mean NAT box maintains TIME_WAIT. I'm thinking of adopting mechanism to assassinate TIME_WAIT state at NAT, so that NAT equipment can make new connection immediately. This will work if we can get timestamp from incoming packet, and maintain it at NAT equipment. > >>> Also, can we use the approach described in the section 4.2.2.13 of >>> rfc1122 instead of rfc6191? >> As written in rfc6191, we may use sequence number to terminate TIME_WAIT, >> but rfc6191 tries to prevent the overlap of the sequence number. >> So, in my opinion, it is preferable to use timestamp option. > I think the preference is fine. > I just thought you might want to state if it can be used or not since > both address the same issue. OK. Thank you for your advice. > Thanks, > -- > Yoshifumi Nishida > > -- ---------------------------------------- NTT Service Integration Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- From mattmathis@google.com Fri Mar 16 15:23:22 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC4621F8627 for ; Fri, 16 Mar 2012 15:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bq21Q5Otktr5 for ; Fri, 16 Mar 2012 15:23:22 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id D11DA21F8624 for ; Fri, 16 Mar 2012 15:23:21 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so1178175wib.13 for ; Fri, 16 Mar 2012 15:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=RwWXHNUMIzexcPoMf0ftszRwb8Awt44xhwtkt6bw7FE=; b=i0GQpqOLVvaVkDFSqdT9q75ehIc1jyRfHvLSqmt3M5XZaX9SR/Om7SPvaeOkpMX4WI fGn1piXQh4ngv4FOgyQ6bJuIfGfuey4ek41ppA31fYTVuNi+rFcJOfmVczllIROrACBq I4lS3qBuQ3L++D/RWjLi9/YrEi0KUV/oRqX8vJt4vgI1owrR8m0eSBop2G6uvk1hci3k xI/xo3pfZRzFMQO7WCt5r5/BpNlUj26YTo+BqdLmNXr7yRNuoOSRAqcY2gRuQFR/Ixcq AQR4g0Bnora7tlsh54mqboxXQTYqCVMO2pmBdrwJRd29YKB3g4wBS7JxEh37cYoknzB3 NJPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=RwWXHNUMIzexcPoMf0ftszRwb8Awt44xhwtkt6bw7FE=; b=DpjjolCDhUZVgVYsogU7y9t1dBq73OnCQGQJFmKhK84NwhjCo1A2s94UXn/dtgwLKU fAkLiA1I/OtgJ9MyWdwvUneTZomU1MdVTQeDV7XQYclEyjC/w/f5g2cZIDwjIo6Fu1vO ITUuUNBGQQOB8r/ub3sUuqTQlp9AabUDOj1tmdJ13QNPJbPqgs/OWMI+vxy4Np/03QoZ ph0N3SDMNo5nDb99aHtpT3ByKkKIsN1w2mEXAlFGMkNSbMeZk7wOISKPR+8uxpfQ57NI RdQM463OcAS0B1aX3UIjEMg9vOtba/9J6bPjPPcG3VbF6fKQ4WtxTP9U1fZJuYJ+tYHp oUPg== Received: by 10.216.136.138 with SMTP id w10mr2517913wei.75.1331936601032; Fri, 16 Mar 2012 15:23:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.136.138 with SMTP id w10mr2517908wei.75.1331936600938; Fri, 16 Mar 2012 15:23:20 -0700 (PDT) Received: by 10.216.217.85 with HTTP; Fri, 16 Mar 2012 15:23:20 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0CC581@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F0CC581@SACEXCMBX02-PRD.hq.netapp.com> Date: Fri, 16 Mar 2012 15:23:20 -0700 Message-ID: From: Matt Mathis To: "Scheffenegger, Richard" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQm7Si22PqV9JvDV7dSgS1w/ifyIuopSVejNha5DtttdXLY/Radgdft5RTg7nbe64V0Q2m86HvN8sYXCxoZFK7z0W0oceiKWzWPGMWNCDsbw//lVzTjEg2pC67sD6QqAqEh+Spne Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] laminar tcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2012 22:23:22 -0000 Thanks for the comments! Nits have been fixed. Yea, I was sloppy about units. I will make it (fractional) bytes everywher= e. > Ad Section 3.6: > > I think you are aiming at MPTCP here, correct? > I think the text, as written, is really only relevant when you know > (automagically) that the congestion control triggering event was somewher= e > along a common path of these separate TCP flows=85=A0 I.e. same sending > interface, same destination, same source or destination network. It may b= e > worthwhile to explicitly spell out the intent here (ie. RFC2140 has > host-pair only). I was actually only thinking about the narrower host pair case. For MPTCP you do need to keep CCwin and total_pipe per flow. Since Laminar decouples the CCwin adjustment from other complexity, it becomes easier for some higher level function to dynamically allocate the window adjustment across flows other than where it was detected. In particular it is reasonable to update the CCwin of another flow, without worrying about what state it is in. Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay From mattmathis@google.com Fri Mar 16 15:57:39 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC3921F85EA for ; Fri, 16 Mar 2012 15:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5WMgmbnlJ3h for ; Fri, 16 Mar 2012 15:57:38 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1997221F85E5 for ; Fri, 16 Mar 2012 15:57:37 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so1212227wib.13 for ; Fri, 16 Mar 2012 15:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=5PN4eVBeRTZKQdHUc3jCNSYOZxUVjVBj4wJv5P2Cq6k=; b=eTeDkMRzNro/yt7SnErIXpt/P4MYpYrtYgoTRGYcRwPAjffl2XgftskuIlIGVPn40j SESdmlLRFpFLeKm5+8YFeKR1QDRkQXlpc3PvJZHlspQCR4xL2imzlojHjbAJkGjS/+08 /YJxotjK32T/JSObuslqWlqf+MMiASdNOFoVtbB5ljfH9PWISxW0tsf//CyTIUh1U8i/ gw8LcbNUJc6Vxhc6g6bbEMQajjQ0lisqy8hTkiKpThVJSMT9B6QiQi6aWYqkDLhjPL4H Ql2LPL2naVFOYp4af/cMnfNA27ANhv6CEl0WOZfoR23ZLuhodvnkkkEZIzHTnltfsrjv LO2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=5PN4eVBeRTZKQdHUc3jCNSYOZxUVjVBj4wJv5P2Cq6k=; b=jlYfiI6E3QMVboRIqNQ97avqGaFjaLs+8VKMMpw1yEjIHYFWWrrJJ3qDFymDDeW/oz Qg+iX68qCXliSXU/eEex39AZQt9r7CH0aVuFIOVMiQLJ+FPxmbXbqYHzC2JmVvU8iKbA KC40jiw+ryidBf80/WdcqSwzuWvNPu1DXNJTOWPlkHV6OESjrwU0+mIOOWmqT7lyNSjl P/4dpHVnqsH5eIsyXyyBvBRl5MOJu668Wj59VIc/15vSZzad92zdBeoTFME/79w79/kk UZ/7WOm80INyJyTWx/V488iVa64GZ9v7pldwMfDdxW9NmL4voSPiOQmMWDMG69WMlZ8t z/5g== Received: by 10.180.82.136 with SMTP id i8mr2084440wiy.19.1331938657085; Fri, 16 Mar 2012 15:57:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.82.136 with SMTP id i8mr2084421wiy.19.1331938656936; Fri, 16 Mar 2012 15:57:36 -0700 (PDT) Received: by 10.216.217.85 with HTTP; Fri, 16 Mar 2012 15:57:36 -0700 (PDT) In-Reply-To: <4F606F24.2090103@ifi.uio.no> References: <012C3117EDDB3C4781FD802A8C27DD4F0CC581@SACEXCMBX02-PRD.hq.netapp.com> <4F606F24.2090103@ifi.uio.no> Date: Fri, 16 Mar 2012 15:57:36 -0700 Message-ID: From: Matt Mathis To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQk4AY2zvk4sVSheiOVJ4a2zcvYccPVFe91RYPRtKFXUTQ5NLAcyEaoY4761vISyS9vfsRnJMfPamI6DlYlMuWbihmxiLoW04wuRNOuEyruh2G8orYCNktkWRFAgLJm/Y0PcaeX1 Cc: tcpm@ietf.org Subject: Re: [tcpm] laminar tcp, separate thread X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2012 22:57:39 -0000 Thanks! I just realized that my earlier reply wasn't to the entire list. (Revised) My big question for Paris will be how to frame this work relative to TCPM. I was actually deliberate about writing this draft for the wrong audience (it is addressed to the WG itself sort of in the form of an independent submission. TCPM docs are normally addressed to TCP implementers.) It is also very spotty about which algorithms it chose to update. This will improve as the draft evolves. I used "undo" in a generic sense. Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay On Wed, Mar 14, 2012 at 3:12 AM, Michael Welzl wrote: > Hi, > > I also read Laminar TCP now, and I applaud! This is great stuff! > > As for the document itself, while this certainly forms a good basis for > discussion, if I imagine that being an RFC, I would say that it's too mes= sy, > in several ways: > > > 1) > I think that most of what this document does is just to provide guidance = to > application designers, i.e. it could be an informational description of h= ow > a TCP could be implemented in an easier and more modern fashion. There > doesn't seem to bee much in it, now, that is (as the abstract says) > "technically in violation of all existing TCP standards"? =A0 I mean, doe= s > counting packets instead of bytes make Linux TCP in violation of the > standards? I guess not... similarly, would I violate standards if I call > ssthresh "xythresh" in my implementation? I guess not... so I think that > only behavioral changes really affect the rules laid out by the other TCP > RFCs. > > That would, then, only concern the behavior when TCP is application-limit= ed, > I think, and that would perhaps only update RFC 2861 =A0:-) > > Of course, if that would really lead to an RFC updating not much more tha= n > RFC 2861 and one or two others, one would have to make pretty damn sure t= hat > the behavior of Laminar REALLY doesn't diverge from the standards in any > other way. > > > 2) > You seem to have made a rather arbitrary selection of algorithms that you > survey in section 3 - e.g., why mention F-RTO and not Eifel? Anyway both > really don't seem to have much to do with Laminar... =A0and which RFC def= ines > "Undo"? I guess what you mean is the Eifel Response algorithm. > > > 3) > I find your mention of aggressiveness, Tragedy of the Commons etc. out of > place. It just strikes me as unrelated. I also think it's weird to mentio= n > the de-obfuscation of code achieved with Laminar as a possible security > concern =A0 :-) > > > Again, all of these comments concern only the document writing style and > structure, not the technical idea, which I think is just beautiful. > > > Cheers, > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ananth@cisco.com Mon Mar 19 19:50:04 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1349421E805A for ; Mon, 19 Mar 2012 19:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfRyT-R-Ob-1 for ; Mon, 19 Mar 2012 19:50:03 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0C821E8027 for ; Mon, 19 Mar 2012 19:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=4627; q=dns/txt; s=iport; t=1332211803; x=1333421403; h=mime-version:subject:date:message-id:from:to; bh=e3Aac6HI9BfceSElLsn721OAdKB3KJytamQEkcrmyyk=; b=L14CtmH5dd5L9kaGB/U+4HoNNNUaCjIfdmPApG4G0CvCc75i34TCEio5 GjcmsVyyawWJdLzOeVzdRdy+XoMU/hf7sXiZ7YtuzHuyiSx+hwjcNCZNj jM+PG/9yNsVZRXRncJuJvP2FfOFlP0FHuokR20tS+rMl+bPGmsKtqfyuG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABbvZ0+rRDoJ/2dsb2JhbABBgka0CoEHggsBBBIBCREDWwEMHgYYB1cBBBsah2cBlx+BJ58WjT+CP2MEiFabSIFogwY X-IronPort-AV: E=Sophos;i="4.73,616,1325462400"; d="scan'208,217";a="36819450" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 20 Mar 2012 02:50:03 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2K2o3HD021466 for ; Tue, 20 Mar 2012 02:50:03 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 19:50:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0644.25E62500" Date: Mon, 19 Mar 2012 19:50:02 -0700 Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504AEA894@xmb-sjc-23e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A new ID on TCP option space extension. Thread-Index: Ac0GRCWpoUYoPErxQTueLRGjeTgRyQ== From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 20 Mar 2012 02:50:02.0940 (UTC) FILETIME=[260AD7C0:01CD0644] Subject: [tcpm] A new ID on TCP option space extension. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 02:50:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0644.25E62500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a new ID on TCP option space extension. Basically, sometime back I had volunteered to write up a draft which talks about the TCP option space issue, motivation, current list of proposals , other ideas if any and what we should moving forward on this. Here is the link :- (I could not meet the draft -00- cut off and hence posting the link) =20 ftp://ftpeng.cisco.com/ananth/draft-ananth-tcpm-tcpopt.txt =20 Please review and provide feedback. In the upcoming TCPM meeting there is a slot allotted to go over this, but I would appreciate if there is earlier feedback. (At least this issue is well known and has been discussed several times in the past, in some sense nothing new) =20 Note : there is some scope to improve the structure of the draft, like when comparing each of the proposals one could chose a tabular form OR at least do comparisons in an orderly fashion (like M1, M2 to M6) instead of the way currently it is.=20 =20 Thanks, -Anantha ------_=_NextPart_001_01CD0644.25E62500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

      I have a new ID on TCP = option space extension. Basically, sometime back I had volunteered =  to  write up a draft which talks about the TCP option space = issue, motivation, current list of proposals , other ideas if any and = what we should moving forward  on this.

     Here is the link :- (I could = not meet the draft -00- cut off and hence posting the = link)

 

ftp:/= /ftpeng.cisco.com/ananth/draft-ananth-tcpm-tcpopt.txt

<= p class=3DMsoNormal> 

Please = review and provide feedback.  In the upcoming TCPM meeting there is = a slot allotted to go over this, but I would appreciate if there is = earlier feedback.  (At least this issue is well known and has been = discussed several times in the past, in some sense nothing = new)

 

Note :  there is some scope to improve the = structure of the draft, like when comparing each of the proposals one = could chose a tabular form OR at least do comparisons in an orderly = fashion (like M1, M2 to M6) instead of the way currently it is. =

 

Thanks,

-Anantha

------_=_NextPart_001_01CD0644.25E62500-- From ananth@cisco.com Tue Mar 20 00:28:44 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D472121F879A for ; Tue, 20 Mar 2012 00:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYI77ufI8mIF for ; Tue, 20 Mar 2012 00:28:43 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 52C3B21F8743 for ; Tue, 20 Mar 2012 00:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=6951; q=dns/txt; s=iport; t=1332228523; x=1333438123; h=mime-version:subject:date:message-id:from:to; bh=p3gLx4QjltSrXVDScFhYfeqTWVYhgsNO3GXoefqJfys=; b=UBob61u+TlaTrEQXOnLZSJTEfXDj0uBNg5H7LGWwOo1J1gCO892X87Ut 7Qi2FUZxUWvStTb1ypV5y/BscoNxtE23faMfJDRQMEweOdf3mDUxVe7X7 O4p/ietUIAR7EMWLPdZQkkxWOLB5hBfFFBvkF8jQc4FuRlXOmZXitO3GW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALQwaE+rRDoG/2dsb2JhbABBgka0C4EHggkBAQEEEgEJEQM+HQEIEQQBAQsGGAdOCQEEEwgah2cBl0+BJ58VjT+CP2MEiFabSIFogwY X-IronPort-AV: E=Sophos;i="4.73,617,1325462400"; d="scan'208,217";a="36846333" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 20 Mar 2012 07:28:43 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2K7Sg66022727 for ; Tue, 20 Mar 2012 07:28:42 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 00:28:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD066B.1392ABAC" Date: Tue, 20 Mar 2012 00:28:41 -0700 Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504AEA904@xmb-sjc-23e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A new ID on TCP option space extension. Thread-Index: Ac0GRCWpoUYoPErxQTueLRGjeTgRyQAJZVQw From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 20 Mar 2012 07:28:42.0736 (UTC) FILETIME=[13D13F00:01CD066B] Subject: Re: [tcpm] A new ID on TCP option space extension. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 07:28:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD066B.1392ABAC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forgot to add :- =20 I am thankful to the chairs to squeeze this item for the last 10 mins left on the agenda. Of course if things take more time for other allotted slots etc.,, this slot has the risk of getting shunted out. I hope we get some time to discuss this during the meeting, if not we can always continue the discussion on the mailing list. =20 Thanks, -Anantha =20 From: Anantha Ramaiah (ananth)=20 Sent: Monday, March 19, 2012 7:50 PM To: tcpm@ietf.org Subject: A new ID on TCP option space extension. =20 Hi, I have a new ID on TCP option space extension. Basically, sometime back I had volunteered to write up a draft which talks about the TCP option space issue, motivation, current list of proposals , other ideas if any and what we should moving forward on this. Here is the link :- (I could not meet the draft -00- cut off and hence posting the link) =20 ftp://ftpeng.cisco.com/ananth/draft-ananth-tcpm-tcpopt.txt =20 Please review and provide feedback. In the upcoming TCPM meeting there is a slot allotted to go over this, but I would appreciate if there is earlier feedback. (At least this issue is well known and has been discussed several times in the past, in some sense nothing new) =20 Note : there is some scope to improve the structure of the draft, like when comparing each of the proposals one could chose a tabular form OR at least do comparisons in an orderly fashion (like M1, M2 to M6) instead of the way currently it is.=20 =20 Thanks, -Anantha ------_=_NextPart_001_01CD066B.1392ABAC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Forgot to add :-

 

I am thankful to the = chairs to squeeze this item for the last 10 mins left on the agenda. Of = course if things take more time for other allotted slots etc.,, =  this slot has the risk of getting shunted out.  I hope we get =  some time  to discuss this during the meeting, if not we can = always continue the discussion on the mailing = list.

 

Thanks,

-Anantha

 

From:= = Anantha Ramaiah (ananth)
Sent: Monday, March 19, 2012 7:50 = PM
To: tcpm@ietf.org
Subject: A new ID on TCP option = space extension.

 

Hi,

      I have a new ID on TCP = option space extension. Basically, sometime back I had volunteered =  to  write up a draft which talks about the TCP option space = issue, motivation, current list of proposals , other ideas if any and = what we should moving forward  on this.

     Here is the link :- (I could = not meet the draft -00- cut off and hence posting the = link)

 

ftp:/= /ftpeng.cisco.com/ananth/draft-ananth-tcpm-tcpopt.txt

<= p class=3DMsoNormal> 

Please = review and provide feedback.  In the upcoming TCPM meeting there is = a slot allotted to go over this, but I would appreciate if there is = earlier feedback.  (At least this issue is well known and has been = discussed several times in the past, in some sense nothing = new)

 

Note :  there is some scope to improve the = structure of the draft, like when comparing each of the proposals one = could chose a tabular form OR at least do comparisons in an orderly = fashion (like M1, M2 to M6) instead of the way currently it is. =

 

Thanks,

-Anantha

------_=_NextPart_001_01CD066B.1392ABAC-- From nishida@sfc.wide.ad.jp Tue Mar 20 22:15:00 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A8521F8516 for ; Tue, 20 Mar 2012 22:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.059 X-Spam-Level: X-Spam-Status: No, score=-97.059 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, MIME_BASE64_TEXT=1.753, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 669wwwT97gGa for ; Tue, 20 Mar 2012 22:14:59 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id A392D21F8504 for ; Tue, 20 Mar 2012 22:14:59 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4229E2780A6 for ; Wed, 21 Mar 2012 14:14:53 +0900 (JST) Received: by lagj5 with SMTP id j5so652620lag.31 for ; Tue, 20 Mar 2012 22:14:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.104.134 with SMTP id ge6mr1002720lbb.7.1332306891572; Tue, 20 Mar 2012 22:14:51 -0700 (PDT) Received: by 10.112.63.174 with HTTP; Tue, 20 Mar 2012 22:14:51 -0700 (PDT) Date: Tue, 20 Mar 2012 22:14:51 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org\"" Content-Type: multipart/alternative; boundary=14dae9d67c8001069404bbb9df17 Subject: [tcpm] Review of draft-ietf-tcpm-proportional-rate-reduction-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 05:15:00 -0000 --14dae9d67c8001069404bbb9df17 Content-Type: text/plain; charset=ISO-8859-1 Hi, I reviewed draft-ietf-tcpm-proportional-rate-reduction-01. I think this is valid and useful idea. I would like to support publishing it to do more broad experiments. Below are my comments on the draft. Please check and update if you agree with them. Technical Comments 1: This is just out of my curiosity and I know there's no major difference, but is there any reasons to use Limited Transmit in the examples in Section 3.1? I just personally thought these examples might be a bit simpler if you just use RFC3517 logic only. (You don't have to count packets transmitted by limited transmit for pipe calculation) But, this is a really minor point. Please keep it if you prefer. 2: I have a question in the pseudo code in Section 3. if (pipe > ssthresh) { Is this supposed to be like this? if (pipe >= ssthresh) { Otherwise, if pipe equals to ssthresh, sndcnt will be zero. 3: If the assumption above is correct, I think the example in Page 6: PRR ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 pipe: 19 19 18 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 10 sent: N N R N N N N N N N N RB: s s will be something like this. Is this correct? PRR pipe: 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 sent: N N R N N N N N N N N RB: s BTW, is there any reason that there is no cwnd data for PRR in the figures? 4: In the following case, PRR-CRB ack# X X X X X X X X X X X X X X X 15 16 17 18 19 pipe: 19 19 4 4 4 sent: N N R R R RB: f f f I think PRR_CRB works like this way and this is understandable. ack #: 17 18 19 prr_delivered: 1 2 3 prr_out: 0 1 2 limit: 1 1 1 sndcnt: 1 1 1 However, in the following case, I think the parameters change like this way according to the logic in Section 3. This result doesn't match the explanation in the draft. Am I misunderstanding something? PRR-SSRB ack# X X X X X X X X X X X X X X X 15 16 17 18 19 pipe: 19 19 4 5 6 sent: N N 2R 2R 2R RB: d d d ack #: 17 18 19 prr_delivered: 1 2 3 prr_out: 0 2 4 limit: 2 1 1 sndcnt: 2 1 1 5: Is 'DeliveredData' necessary in the following equation? I couldn't come up with good examples. But, I might miss something.. limit = MAX(prr_delivered - prr_out, DeliveredData) + MSS Editorial Comments: Page 7: -> There is no explanation for 'f' and 'd' in the figure. I guess this is transmission triggered by PRR+CRB and PRR+SSRB, but, please confirm this. Page 10: .. limited transmit [RFC3742] .. -> I guess this doesn't mean Limited Slow Start and should be RFC3042. Please confirm this. Page 12: Reference -> I think you can put RFC2018, 3517, 3042 and 5681 into Normative References and put others into Informative References. Typos: Total bytes delivered during recov -> Total bytes delivered during recovery FlightSize at the start of recov -> FlightSize at the start of recovery sshthresh -> ssthresh Regards, -- Yoshifumi Nishida --14dae9d67c8001069404bbb9df17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SGksIEkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi10Y3BtLXByb3BvcnRpb25hbC1yYXRlLXJlZHVjdGlv bi0wMS4gPGJyPkkgdGhpbmsgdGhpcyBpcyB2YWxpZCBhbmQgdXNlZnVsIGlkZWEuIEkgd291bGQg bGlrZSB0byBzdXBwb3J0IHB1Ymxpc2hpbmcgaXQgdG8gZG8gbW9yZSBicm9hZCBleHBlcmltZW50 cy48YnI+QmVsb3cgYXJlIG15IGNvbW1lbnRzIG9uIHRoZSBkcmFmdC48YnI+UGxlYXNlIGNoZWNr IGFuZCB1cGRhdGUgaWYgeW91IGFncmVlIHdpdGggdGhlbS48YnI+Cjxicj48YnI+VGVjaG5pY2Fs IENvbW1lbnRzPGJyPjxicj6gIDE6IFRoaXMgaXMganVzdCBvdXQgb2YgbXkgY3VyaW9zaXR5IGFu ZCBJIGtub3cgdGhlcmUmIzM5O3Mgbm8gbWFqb3IgZGlmZmVyZW5jZSwgPGJyPqCgoKAgYnV0IGlz IHRoZXJlIGFueSByZWFzb25zIHRvIHVzZSBMaW1pdGVkIFRyYW5zbWl0IGluIHRoZSBleGFtcGxl cyBpbiBTZWN0aW9uIDMuMT8gPGJyPqCgoKAgSSBqdXN0IHBlcnNvbmFsbHkgdGhvdWdodCB0aGVz ZSBleGFtcGxlcyBtaWdodCBiZSBhIGJpdCBzaW1wbGVyIGlmIHlvdSBqdXN0IHVzZSBSRkMzNTE3 IGxvZ2ljIG9ubHkuPGJyPgqgoKCgIChZb3UgZG9uJiMzOTt0IGhhdmUgdG8gY291bnQgcGFja2V0 cyB0cmFuc21pdHRlZCBieSBsaW1pdGVkIHRyYW5zbWl0IGZvciBwaXBlIGNhbGN1bGF0aW9uKTxi cj6goKCgIEJ1dCwgdGhpcyBpcyBhIHJlYWxseSBtaW5vciBwb2ludC4gUGxlYXNlIGtlZXAgaXQg aWYgeW91IHByZWZlci48YnI+PGJyPqAgMjogSSBoYXZlIGEgcXVlc3Rpb24gaW4gdGhlIHBzZXVk byBjb2RlIGluIFNlY3Rpb24gMy48YnI+CqCgoKAgPGJyPqCgoKCgoKAgaWYgKHBpcGUgJmd0OyBz c3RocmVzaCmgIHs8YnI+oCA8YnI+oKCgoCBJcyB0aGlzIHN1cHBvc2VkIHRvIGJlIGxpa2UgdGhp cz88YnI+oKCgoCA8YnI+oKCgoKCgoCBpZiAocGlwZSAmZ3Q7PSBzc3RocmVzaCmgIHs8YnI+PGJy PqCgoKAgT3RoZXJ3aXNlLCBpZiBwaXBlIGVxdWFscyB0byBzc3RocmVzaCwgc25kY250IHdpbGwg YmUgemVyby48YnI+PGJyPqAgMzogSWYgdGhlIGFzc3VtcHRpb24gYWJvdmUgaXMgY29ycmVjdCwg SSB0aGluayB0aGUgZXhhbXBsZSBpbiBQYWdlIDY6PGJyPgo8YnI+oFBSUjxicj6goCBhY2sjoKAg WKAgMaAgMqAgM6AgNKAgNaAgNqAgN6AgOKAgOSAxMCAxMSAxMiAxMyAxNCAxNSAxNiAxNyAxOCAx OTxicj6goCBwaXBlOqCgoCAxOSAxOSAxOCAxOCAxOCAxNyAxNyAxNiAxNiAxNSAxNSAxNCAxNCAx MyAxMyAxMiAxMiAxMSAxMDxicj6goCBzZW50OqCgoKAgTqAgTqAgUqCgoKAgTqCgoKAgTqCgoKAg TqCgoKAgTqCgoKAgTqCgoKAgTqCgoKCgoKAgTqAgTjxicj4KoKAgUkI6oKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHOgIHM8YnI+PGJyPqCg oKCgIHdpbGwgYmUgc29tZXRoaW5nIGxpa2UgdGhpcy4gSXMgdGhpcyBjb3JyZWN0Pzxicj48YnI+ oFBSUqCgoKCgoKCgoKCgoKCgoKCgIDxicj6goCBwaXBlOqCgoCAxOSAxOSAxOCAxOCAxNyAxNyAx NiAxNiAxNSAxNSAxNCAxNCAxMyAxMyAxMiAxMiAxMSAxMSAxMDxicj4KoKAgc2VudDqgoKCgIE6g IE6gIFKgoKCgIE6goKCgIE6goKCgIE6goKCgIE6goKCgIE6goKCgIE6goKCgIE6goKCgIE48YnI+ oKAgUkI6oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgIHM8YnI+PGJyPjxicj6goCBCVFcsIGlzIHRoZXJlIGFueSByZWFzb24gdGhhdCB0 aGVyZSBpcyBubyBjd25kIGRhdGEgZm9yIFBSUiBpbiB0aGUgZmlndXJlcz88YnI+Cjxicj48YnI+ PGJyPqAgNDogSW4gdGhlIGZvbGxvd2luZyBjYXNlLDxicj48YnI+UFJSLUNSQjxicj6gIGFjayOg oCBYoCBYoCBYoCBYoCBYoCBYoCBYoCBYoCBYoCBYoCBYoCBYoCBYoCBYoCBYIDE1IDE2IDE3IDE4 IDE5PGJyPqAgcGlwZTqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKAgMTkgMTmgIDSgIDSgIDQ8YnI+oCBzZW50OqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKAgTqAgTqAgUqAgUqAgUjxicj4KoCBSQjqgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgZqAgZqAgZjxicj48YnI+oCA8 YnI+oKCgoCBJIHRoaW5rIFBSUl9DUkIgd29ya3MgbGlrZSB0aGlzIHdheSBhbmQgdGhpcyBpcyB1 bmRlcnN0YW5kYWJsZS48YnI+PGJyPqCgoKCgoKCgoCBhY2sgIzogMTcgMTggMTk8YnI+oCBwcnJf ZGVsaXZlcmVkOqAgMaAgMqAgMzxicj6gIHBycl9vdXQ6oKCgoKCgoCAwoCAxoCAyPGJyPgqgIGxp bWl0OqCgoKCgoKCgoCAxoCAxoCAxPGJyPqAgc25kY250OqCgoKCgoKCgIDGgIDGgIDE8YnI+PGJy Pjxicj48YnI+oKCgoCBIb3dldmVyLCBpbiB0aGUgZm9sbG93aW5nIGNhc2UsIEkgdGhpbmsgdGhl IHBhcmFtZXRlcnMgY2hhbmdlIGxpa2UgdGhpcyB3YXkgYWNjb3JkaW5nIHRvIHRoZSBsb2dpYyBp biBTZWN0aW9uIDMuPGJyPqCgoKAgVGhpcyByZXN1bHQgZG9lc24mIzM5O3QgbWF0Y2ggdGhlIGV4 cGxhbmF0aW9uIGluIHRoZSBkcmFmdC4gQW0gSSBtaXN1bmRlcnN0YW5kaW5nIHNvbWV0aGluZz88 YnI+Cjxicj5QUlItU1NSQjxicj6gIGFjayOgoCBYoCBYoCBYoCBYoCBYoCBYoCBYoCBYoCBYoCBY oCBYoCBYoCBYoCBYoCBYIDE1IDE2IDE3IDE4IDE5PGJyPqAgcGlwZTqgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgMTkgMTmgIDSgIDWgIDY8YnI+oCBzZW50OqCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgTqAgTiAyUiAyUiAy Ujxicj4KoCBSQjqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKAgZKAgZKAgZDxicj48YnI+oKCgoKCgoKCgIGFjayAjOiAxNyAxOCAxOTxicj6gIHBy cl9kZWxpdmVyZWQ6oCAxoCAyoCAzPGJyPqAgcHJyX291dDqgoKCgoKCgIDCgIDKgIDQ8YnI+oCBs aW1pdDqgoKCgoKCgoKAgMqAgMaAgMTxicj6gIHNuZGNudDqgoKCgoKCgoCAyoCAxoCAxPGJyPjxi cj4KPGJyPqAgNTogSXMgJiMzOTtEZWxpdmVyZWREYXRhJiMzOTsgbmVjZXNzYXJ5IGluIHRoZSBm b2xsb3dpbmcgZXF1YXRpb24/IDxicj6goKCgIEkgY291bGRuJiMzOTt0IGNvbWUgdXAgd2l0aCBn b29kIGV4YW1wbGVzLiBCdXQsIEkgbWlnaHQgbWlzcyBzb21ldGhpbmcuLjxicj48YnI+oKCgoCBs aW1pdCA9IE1BWChwcnJfZGVsaXZlcmVkIC0gcHJyX291dCwgRGVsaXZlcmVkRGF0YSkgKyBNU1M8 YnI+CqCgIDxicj48YnI+PGJyPkVkaXRvcmlhbCBDb21tZW50czo8YnI+PGJyPqBQYWdlIDc6PGJy PqCgIDxicj6goCAtJmd0OyBUaGVyZSBpcyBubyBleHBsYW5hdGlvbiBmb3IgJiMzOTtmJiMzOTsg YW5kICYjMzk7ZCYjMzk7IGluIHRoZSBmaWd1cmUuPGJyPqCgoKCgIEkgZ3Vlc3MgdGhpcyBpcyB0 cmFuc21pc3Npb24gdHJpZ2dlcmVkIGJ5IFBSUitDUkIgYW5kIFBSUitTU1JCLCA8YnI+oKCgoKAg YnV0LCBwbGVhc2UgY29uZmlybSB0aGlzLjxicj4KPGJyPjxicj6gUGFnZSAxMDo8YnI+PGJyPqCg IC4uIGxpbWl0ZWQgdHJhbnNtaXQgW1JGQzM3NDJdIC4uPGJyPjxicj6goCAtJmd0OyBJIGd1ZXNz IHRoaXMgZG9lc24mIzM5O3QgbWVhbiBMaW1pdGVkIFNsb3cgU3RhcnQgYW5kIHNob3VsZCBiZSBS RkMzMDQyLiA8YnI+oKCgoKAgUGxlYXNlIGNvbmZpcm0gdGhpcy48YnI+PGJyPjxicj6gUGFnZSAx Mjo8YnI+PGJyPqCgIFJlZmVyZW5jZTxicj4KoDxicj6goCAtJmd0OyBJIHRoaW5rIHlvdSBjYW4g cHV0IFJGQzIwMTgsIDM1MTcsIDMwNDIgYW5kIDU2ODEgaW50byBOb3JtYXRpdmUgUmVmZXJlbmNl cyBhbmQgcHV0IG90aGVycyBpbnRvIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMuPGJyPjxicj5UeXBv czo8YnI+PGJyPqCgoCBUb3RhbCBieXRlcyBkZWxpdmVyZWQgZHVyaW5nIHJlY292IC0mZ3Q7oKAg VG90YWwgYnl0ZXMgZGVsaXZlcmVkIGR1cmluZyByZWNvdmVyeTxicj4KPGJyPqCgoCBGbGlnaHRT aXplIGF0IHRoZSBzdGFydCBvZiByZWNvdiAtJmd0O6AgRmxpZ2h0U2l6ZSBhdCB0aGUgc3RhcnQg b2YgcmVjb3Zlcnk8YnI+PGJyPqCgoCBzc2h0aHJlc2ggLSZndDsgc3N0aHJlc2g8YnI+PGJyPjxi cj48YnI+UmVnYXJkcyw8YnI+LS08YnI+WW9zaGlmdW1pIE5pc2hpZGE8YnI+PGJyPjxicj4K --14dae9d67c8001069404bbb9df17-- From michael.scharf@alcatel-lucent.com Fri Mar 23 02:48:07 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9BF21F8543 for ; Fri, 23 Mar 2012 02:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.868 X-Spam-Level: X-Spam-Status: No, score=-9.868 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIpOdpZzaa5p for ; Fri, 23 Mar 2012 02:48:06 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCA221F84BF for ; Fri, 23 Mar 2012 02:48:06 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2N9k8AH032013 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 23 Mar 2012 10:48:01 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 23 Mar 2012 10:47:51 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Fri, 23 Mar 2012 10:47:50 +0100 Thread-Topic: Feedback on usage and deployment recommendations in draft-ietf-tcpm-initcwnd-03 Thread-Index: Ac0I2gLTG2g18YcaTsuRtG6Fum2+nQ== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E88E443F134@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [tcpm] Feedback on usage and deployment recommendations in draft-ietf-tcpm-initcwnd-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 23 Mar 2012 09:48:07 -0000 Hi all, In the past meetings we had quite some discussion under which constraints i= t is reasonable to experiment with a larger initial window. The recently submitted draft-ietf-tcpm-initcwnd-03 includes a new section "= 12. Usage and Deployment Recommendations" that tries to summarize the conce= rns expressed by the TCPM community: Further experiments are required before a larger initial window shall be enabled by default in the Internet. The existing measurement results indicate that this does not cause significant harm to other traffic. However, widespread use in the Internet could reveal issues not known yet, e.g., regarding fairness or impact on latency- sensitive traffic such as VoIP. Therefore, special care is needed when using this experimental TCP extension, in particular on large-scale systems originating a significant amount of Internet traffic. Anyone (stack vendors, network administrators, etc.) turning on a larger initial window SHOULD ensure that the performance is monitored before and after that change. Relevant performance metrics include the percentages of packet losses or segment retransmissions as well as application-level metrics such as data transfer completion times or media quality. Note that it is important also to take into account hosts that do not implement a larger initial window. Furthermore, non-TCP traffic (such as VoIP) should be monitored as well. If users observe any significant deterioration of performance, they SHOULD fall back to an initial window as allowed by RFC 3390 for safety reasons. An increased initial window SHOULD NOT be turned on by default on systems without such monitoring capabilities. The IETF TCPM working group is very much interested in further reports from experiments with this specification and encourages the publication of such measurement data. If no significant harm is reported, a follow-up document may revisit the question on whether a larger initial window can be safely used by default in all Internet hosts. Feedback on this text would be highly welcome. Thanks Michael (TCPM co-chair) From pasi.sarolahti@iki.fi Fri Mar 23 06:20:33 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C2F21F8501 for ; Fri, 23 Mar 2012 06:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUdbpKunEDmB for ; Fri, 23 Mar 2012 06:20:28 -0700 (PDT) Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8FB21F846A for ; Fri, 23 Mar 2012 06:20:28 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id q2NDKRFM024868 for ; Fri, 23 Mar 2012 15:20:27 +0200 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 19555-1564 for ; Fri, 23 Mar 2012 15:20:27 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id q2NDJwku024856 for ; Fri, 23 Mar 2012 15:19:58 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id CA23C1E1C3 for ; Fri, 23 Mar 2012 15:19:58 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id E5vj1pmb6tg1 for ; Fri, 23 Mar 2012 15:19:53 +0200 (EET) Received: from pc104.netlab.hut.fi (pc104.netlab.hut.fi [130.233.154.104]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id AC7461E123 for ; Fri, 23 Mar 2012 15:19:53 +0200 (EET) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Mar 2012 15:19:53 +0200 Message-Id: <5F76440F-1878-4D7A-B7C8-FAA779BA1FDD@iki.fi> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [tcpm] TCPM final agenda for IETF-83 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 23 Mar 2012 13:20:34 -0000 Hi, Below is the final agenda for the TCPM meeting. Speakers, please send = slides in advance to the chairs, to be uploaded to the meeting materials = system. The earlier the better, but at latest by Thursday afternoon. = Please number the slides to help possible remote participants follow the = talk. TCPM agenda for IETF-83 / Paris, France Friday, March 30, 2012, 09:00 -- 11:00 -------------------------------------- Admin ----- * Agenda bash & WG status (5 min) chairs * TCPM Rechartering discussion (10 min) chairs WG items -------- * TCP Fast Open (15 min) draft-ietf-tcpm-fastopen-00 Jerry Chu * Increasing TCP's Initial Window (15 min) draft-ietf-tcpm-initcwnd-03 Jerry Chu * IW10 in Low Bandwidth Environments (15 min) (related to draft-ietf-tcpm-initcwnd-03) Hagen Paul Pfeifer * Security Assessment of TCP (15 min) draft-ietf-tcpm-tcp-security-03 Fernando Gont * Proportional Rate Reduction (5 min) draft-ietf-tcpm-proportional-rate-reduction-01 Matt Mathis Other items ----------- * Laminar TCP (15 min) draft-mathis-tcpm-tcp-laminar-00 Matt Mathis * NAT functional extension for address resource restricted environment = (15 min) draft-naito-nat-resource-optimizing-extension-00 Kengo Naito * TCP option space extension - a brief discussion (10 min) ftp://ftpeng.cisco.com/ananth/draft-ananth-tcpm-tcpopt.txt Anantha Ramaiah From internet-drafts@ietf.org Mon Mar 26 07:24:37 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C09E21E80A1; Mon, 26 Mar 2012 07:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFZUB0Dq3Hqs; Mon, 26 Mar 2012 07:24:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0071921E803C; Mon, 26 Mar 2012 07:24:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326142433.24827.44952.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 07:24:33 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-3517bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 14:24:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : A Conservative Selective Acknowledgment (SACK)-based Los= s Recovery Algorithm for TCP Author(s) : Ethan Blanton Mark Allman Lili Wang Ilpo Jarvinen Markku Kojo Yoshifumi Nishida Filename : draft-ietf-tcpm-3517bis-02.txt Pages : 14 Date : 2012-03-26 This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-3517bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-3517bis-02.txt From ingemar.s.johansson@ericsson.com Mon Mar 26 07:32:33 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECF921E80B2 for ; Mon, 26 Mar 2012 07:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.488 X-Spam-Level: X-Spam-Status: No, score=-9.488 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2V1XvC92Xrh for ; Mon, 26 Mar 2012 07:32:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0425A21E80AA for ; Mon, 26 Mar 2012 07:32:31 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-2b-4f707dfe4ebf Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 58.F0.27041.EFD707F4; Mon, 26 Mar 2012 16:32:31 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.196]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Mon, 26 Mar 2012 16:32:30 +0200 From: Ingemar Johansson S To: "tcpm@ietf.org" Date: Mon, 26 Mar 2012 16:32:28 +0200 Thread-Topic: Timestamp option and ticks Thread-Index: Ac0LXUVs+icVS9c8SA2h+vDTCG8X5w== Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_DBB1DC060375D147AC43F310AD987DCC4B699667B1ESESSCMS0366e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [tcpm] Timestamp option and ticks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 14:32:33 -0000 --_000_DBB1DC060375D147AC43F310AD987DCC4B699667B1ESESSCMS0366e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have a question related to the time stamp option. Is there any list somew= here what "timebase" various OS use for the timestamp. Thinking of Android,= Apple iOS , MS Windows etc. Then a question regarding http://tools.ietf.org/id/draft-scheffenegger-tcpm= -timestamp-negotiation-03.txt is this draft in an active state ?. Asking because something like this is p= robably needed for optimal performance for TCP with LEDBAT CC /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=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com www.thenodepole.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_DBB1DC060375D147AC43F310AD987DCC4B699667B1ESESSCMS0366e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
I have a question related to the time stamp option. Is there any list = somewhere what "timebase" various OS use for the timestamp. Think= ing of Android, Apple iOS , MS Windows etc.
 
is this draft in an active state ?. Asking because something like this= is probably needed for optimal performance for TCP with LEDBAT CC
 
 
/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=E4nd 11
971 28, Lule=E5, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 328= 9
ingemar.s.johansson@ericss= on.com
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 
 
 --_000_DBB1DC060375D147AC43F310AD987DCC4B699667B1ESESSCMS0366e_-- From hagen@jauu.net Mon Mar 26 07:57:45 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7A521F85D3 for ; Mon, 26 Mar 2012 07:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KcQLgDCXHze for ; Mon, 26 Mar 2012 07:57:44 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id 75DC121F8483 for ; Mon, 26 Mar 2012 07:57:44 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 90D06F44181; Mon, 26 Mar 2012 16:57:42 +0200 (CEST) Date: Mon, 26 Mar 2012 16:57:41 +0200 From: Hagen Paul Pfeifer To: Ingemar Johansson S Message-ID: <20120326145741.GF3572@hell> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.21 (2010-09-15) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Timestamp option and ticks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 14:57:45 -0000 * Ingemar Johansson S | 2012-03-26 16:32:28 [+0200]: >I have a question related to the time stamp option. Is there any list >somewhere what "timebase" various OS use for the timestamp. Thinking of >Android, Apple iOS , MS Windows etc. I am not aware of this list. Anyway: Linux simple use jiffies (actually the lower 32 bit on a 64 bit system). Without guaranty: this should also be true for Android. Hagen From rs@netapp.com Mon Mar 26 08:02:13 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB85021E80CE for ; Mon, 26 Mar 2012 08:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnEKbEPNx65A for ; Mon, 26 Mar 2012 08:02:11 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id C2AA221E80BD for ; Mon, 26 Mar 2012 08:02:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,320,1330934400"; d="scan'208,217";a="636301007" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 26 Mar 2012 08:02:11 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q2QF2Bdx005891; Mon, 26 Mar 2012 08:02:11 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.178]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0247.003; Mon, 26 Mar 2012 08:02:06 -0700 From: "Scheffenegger, Richard" To: Ingemar Johansson S , "tcpm@ietf.org" Thread-Topic: Timestamp option and ticks Thread-Index: Ac0LXUVs+icVS9c8SA2h+vDTCG8X5wAAwJhw Date: Mon, 26 Mar 2012 15:02:05 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F12976F@SACEXCMBX02-PRD.hq.netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F12976FSACEXCMBX02PRDhqn_" MIME-Version: 1.0 Subject: Re: [tcpm] Timestamp option and ticks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 15:02:13 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F12976FSACEXCMBX02PRDhqn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ingemar, During my investigation, I didn't find any explicit way how to figure out t= he timebase; some implementations try to figure out the remote timebase dur= ing the three way handshake, and then put the result in one of a small numb= er of buckets. However, this approach has a couple of obvious drawbacks (i= e. missing "timebase" buckets, problems delineating between buckets being c= lose together, transient network conditions during the measurement, to name= a few). The draft has lingered somewhat, but I still want to drive it forward. From= what I gathered during the last meetings, there is a general view that som= ething like this is interesting, but the document is not ready for WGLC (or= even close). I believe part of that is, that the draft as it stands now mingles too much= of the rationale for this modification, with the simple, straight-forward = implementation details. Perhaps I should split the document into two parts.= But I really would appreciate any input as to how to proceed with this pro= posal. Also, contributors are very welcome :) Richard Scheffenegger From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Ing= emar Johansson S Sent: Montag, 26. M=E4rz 2012 16:32 To: tcpm@ietf.org Subject: [tcpm] Timestamp option and ticks Hi I have a question related to the time stamp option. Is there any list somew= here what "timebase" various OS use for the timestamp. Thinking of Android,= Apple iOS , MS Windows etc. Then a question regarding http://tools.ietf.org/id/draft-scheffenegger-tcpm= -timestamp-negotiation-03.txt is this draft in an active state ?. Asking because something like this is p= robably needed for optimal performance for TCP with LEDBAT CC /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=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com www.thenodepole.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_012C3117EDDB3C4781FD802A8C27DD4F12976FSACEXCMBX02PRDhqn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ingemar,

 <= /p>

During my = investigation, I didn’t find any explicit way how to figure out the t= imebase; some implementations try to figure out the remote timebase during the three way handshake, and then put the result in one of a small = number of  buckets. However, this approach has a couple of obvious dra= wbacks (ie. missing “timebase” buckets, problems delineating be= tween buckets being close together, transient network conditions during the measurement, to name a few).

 = ;

The draft = has lingered somewhat, but I still want to drive it forward. From what I ga= thered during the last meetings, there is a general view that something like this is interesting, but the document is not ready for WGLC= (or even close).

 = ;

I believe = part of that is, that the draft as it stands now mingles too much of the ra= tionale for this modification, with the simple, straight-forward implementation details. Perhaps I should split the document into two parts= . But I really would appreciate any input as to how to proceed with this pr= oposal.

 = ;

Also, cont= ributors are very welcome J

 = ;

 = ;

 = ;

Richard Sc= heffenegger

 = ;

From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Ingemar Johansson S
Sent: Montag, 26. M=E4rz 2012 16:32
To: tcpm@ietf.org
Subject: [tcpm] Timestamp option and ticks

 

Hi

 

I have a question related to the time stamp option. Is the= re any list somewhere what "timebase" various OS use for the time= stamp. Thinking of Android, Apple iOS , MS Windows etc.

 

is this draft in an active state ?. Asking because somethi= ng like this is probably needed for optimal performance for TCP with LEDBAT= CC

 

 

/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=E4nd 11

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

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

 

 

--_000_012C3117EDDB3C4781FD802A8C27DD4F12976FSACEXCMBX02PRDhqn_-- From ananth@cisco.com Mon Mar 26 13:09:43 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2AC21E80B0 for ; Mon, 26 Mar 2012 13:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmIvIYq-Va8F for ; Mon, 26 Mar 2012 13:09:42 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8671D21E809C for ; Mon, 26 Mar 2012 13:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=420; q=dns/txt; s=iport; t=1332792582; x=1334002182; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=M89Q0o1vGGm3Y19rCZe/aDeCYSQ31mreQBa+yaE4ow0=; b=mTbmlMqervHlFm9dnyhGRN3l0XAo1G5Qz2LUPtDgnvqRklpeHzv8iwzk TJEp5qsKn8mzD6jqb9WvPurq3BHZadJXTfZrkb7nbMV2Eb2+I+cCzSIJs 2Syr9kZ3Q2kbaQNsqEQ/McjgAQypQxnoM+cHIihP2MKZCBlIGy7p/E18M 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOrLcE+rRDoJ/2dsb2JhbABEuDuBB4IJAQEBAwEBAQEPAR0KNBALAgEIIgYYBgEmMAEBBAESCBqHYwQBC5o5nm4EkCxjBIhXm06BaIMH X-IronPort-AV: E=Sophos;i="4.73,652,1325462400"; d="scan'208";a="35165249" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 26 Mar 2012 20:09:42 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2QK9g1V011595; Mon, 26 Mar 2012 20:09:42 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 13:09:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Mar 2012 13:09:40 -0700 Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C03357@xmb-sjc-23e.amer.cisco.com> In-Reply-To: <5F76440F-1878-4D7A-B7C8-FAA779BA1FDD@iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCPM final agenda for IETF-83 Thread-Index: Ac0I9710euviOEeJQTW0Y48kC5mvjwClB03Q References: <5F76440F-1878-4D7A-B7C8-FAA779BA1FDD@iki.fi> From: "Anantha Ramaiah (ananth)" To: "Pasi Sarolahti" , X-OriginalArrivalTime: 26 Mar 2012 20:09:42.0144 (UTC) FILETIME=[616C8000:01CD0B8C] Subject: Re: [tcpm] TCPM final agenda for IETF-83 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 20:09:43 -0000 >=20 > * TCP option space extension - a brief discussion (10 min) > ftp://ftpeng.cisco.com/ananth/draft-ananth-tcpm-tcpopt.txt I just the posted the same version into the official repository. It now should show up in the usual places. -Anantha > Anantha Ramaiah >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From naito.kengo@lab.ntt.co.jp Mon Mar 26 21:56:26 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FE421F85B7 for ; Mon, 26 Mar 2012 21:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.886 X-Spam-Level: * X-Spam-Status: No, score=1.886 tagged_above=-999 required=5 tests=[AWL=-1.976, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_73=0.6, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvgiO2TrGGD8 for ; Mon, 26 Mar 2012 21:56:24 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8451F21F85AC for ; Mon, 26 Mar 2012 21:56:24 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.5/8.14.5) with ESMTP id q2R4uMQU025381; Tue, 27 Mar 2012 13:56:22 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 5EC1865EC; Tue, 27 Mar 2012 13:56:22 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 5819F65EB; Tue, 27 Mar 2012 13:56:22 +0900 (JST) Received: from gwras.ecl.ntt.co.jp (webras.ecl.ntt.co.jp [129.60.57.68]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id q2R4uMZ9023917; Tue, 27 Mar 2012 13:56:22 +0900 Message-Id: <201203270456.q2R4uMZ9023917@imail3.m.ecl.ntt.co.jp> From: =?iso-2022-jp?B?IhskQkZiRiMbKEIgGyRCN3s4YxsoQiI=?= To: tcpm@ietf.org X-Mailer: Html Mime Mail Class MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MasGrpSmtpServerHost: imm.m.ecl.ntt.co.jp MasGrpSmtpServerPort: 25 MasGrpPolicyRtgTable: main Date: Tue, 27 Mar 2012 13:56:21 +0900 Cc: koara7@gmail.com Subject: Re: [tcpm] =?utf-8?q?New_Version_Notification_for_draft-naito-nat-res?= =?utf-8?q?ource-optimizing-extension-01=2Etxt?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 04:56:26 -0000 Hi, I've wrote a new revision of my draft. The draft is posted below. http://www.ietf.org/id/draft-naito-nat-resource-optimizing-extension-01.txt I'll appriciate for any comments. I have a slot in Friday, so I'll introduce this draft there as well. Thanks, -- Kengo Original message: --------------- Received:03/27/12 02:27 From:internet-drafts@ietf.org To:naito.kengo@lab.ntt.co.jp Cc:arifumi@nttv6.net Subject:New Version Notification for draft-naito-nat-resource-optimizing-extension-01.txt A new version of I-D, draft-naito-nat-resource-optimizing-extension-01.txt has been successfully submitted by Kengo Naito and posted to the IETF repository. Filename: draft-naito-nat-resource-optimizing-extension Revision: 01 Title: NAT resource optimizing extension Creation date: 2012-03-26 WG ID: Individual Submission Number of pages: 6 Abstract: When network address translation (NAT) is used in an address resource restricted environment, or when a lot of users are located under a NAT device, IP addresses and port resources may be eaten up, and this affects user experiences very negatively. This situation can be greatly mitigated by tweaking mapping behavior and session timer handling in NAT functions. This document proposes two extensions for optimizing NAT IP address and port resources in address resource restricted environments. One extension enables simultaneous use of a NAT external port for different transport sessions, and the other makes use of a TCP timestamp for TIME_WAIT assassination. The IETF Secretariat From rs@netapp.com Tue Mar 27 00:48:23 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89E821F875C; Tue, 27 Mar 2012 00:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI3nH4cJY9qy; Tue, 27 Mar 2012 00:48:21 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1647921F875A; Tue, 27 Mar 2012 00:48:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,325,1330934400"; d="scan'208,217";a="636479368" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 27 Mar 2012 00:48:20 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q2R7mKCK012262; Tue, 27 Mar 2012 00:48:20 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.178]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 00:47:38 -0700 From: "Scheffenegger, Richard" To: "tsvwg@ietf.org" Thread-Topic: RTO Restart Thread-Index: Ac0L7dVnV/NPhLOPTEuh9aBSMcJdyg== Date: Tue, 27 Mar 2012 07:48:15 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F12A46B@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F12A46BSACEXCMBX02PRDhqn_" MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: [tcpm] RTO Restart X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 07:48:24 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F12A46BSACEXCMBX02PRDhqn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a quick comment on draft-hurtig-tcpm-rtorestart: Slide 7 (unfortunately, no numbering), Cost/Benefit To the last point - when Timestamps get used, with high enough time-resolut= ion, one can get away without any additional variables within the sender. O= f course, without using timestamps, a cycling buffer of three or four entri= es is required to hold a high-res timestamp when the last packet was sent. = I just wanted to add this comment. Apart from that, I like that draft (as expressed earlier) :) Richard Scheffenegger --_000_012C3117EDDB3C4781FD802A8C27DD4F12A46BSACEXCMBX02PRDhqn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Just a quick comment on draft-hurtig-tcpm-rtor= estart:
 
Slide 7 (unfortunately, no numbering), Cost/Benefit
 
To the last point – when Timestamps get used, with high enough t= ime-resolution, one can get away without any additional variables within th= e sender. Of course, without using timestamps, a cycling buffer of three or= four entries is required to hold a high-res timestamp when the last packet was sent. I just wanted to add this comment.=
 
Apart from that, I like that draft (as expressed earlier) J
 
Richard Scheffenegger
 
 --_000_012C3117EDDB3C4781FD802A8C27DD4F12A46BSACEXCMBX02PRDhqn_-- From ingemar.s.johansson@ericsson.com Tue Mar 27 01:45:49 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB90821E8063 for ; Tue, 27 Mar 2012 01:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.043 X-Spam-Level: X-Spam-Status: No, score=-10.043 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiI9mo1h3i7W for ; Tue, 27 Mar 2012 01:45:48 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DB17021E8064 for ; Tue, 27 Mar 2012 01:45:47 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-30-4f717e3ab42a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D7.F4.17856.A3E717F4; Tue, 27 Mar 2012 10:45:46 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.196]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 27 Mar 2012 10:45:46 +0200 From: Ingemar Johansson S To: "Scheffenegger, Richard" , "tcpm@ietf.org" Date: Tue, 27 Mar 2012 10:45:45 +0200 Thread-Topic: Timestamp option and ticks Thread-Index: Ac0LXUVs+icVS9c8SA2h+vDTCG8X5wAAwJhwACVjo8A= Message-ID: References: <012C3117EDDB3C4781FD802A8C27DD4F12976F@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F12976F@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_DBB1DC060375D147AC43F310AD987DCC4B69966B3DESESSCMS0366e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [tcpm] Timestamp option and ticks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 08:45:50 -0000 --_000_DBB1DC060375D147AC43F310AD987DCC4B69966B3DESESSCMS0366e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thanks for the response. I will read though the draft and see if I can cont= ribute with something useful. It seems to be very well written though. /Ingemar ________________________________ From: Scheffenegger, Richard [mailto:rs@netapp.com] Sent: den 26 mars 2012 17:02 To: Ingemar Johansson S; tcpm@ietf.org Subject: RE: Timestamp option and ticks Hi Ingemar, During my investigation, I didn't find any explicit way how to figure out t= he timebase; some implementations try to figure out the remote timebase dur= ing the three way handshake, and then put the result in one of a small numb= er of buckets. However, this approach has a couple of obvious drawbacks (i= e. missing "timebase" buckets, problems delineating between buckets being c= lose together, transient network conditions during the measurement, to name= a few). The draft has lingered somewhat, but I still want to drive it forward. From= what I gathered during the last meetings, there is a general view that som= ething like this is interesting, but the document is not ready for WGLC (or= even close). I believe part of that is, that the draft as it stands now mingles too much= of the rationale for this modification, with the simple, straight-forward = implementation details. Perhaps I should split the document into two parts.= But I really would appreciate any input as to how to proceed with this pro= posal. Also, contributors are very welcome :) Richard Scheffenegger From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Ing= emar Johansson S Sent: Montag, 26. M=E4rz 2012 16:32 To: tcpm@ietf.org Subject: [tcpm] Timestamp option and ticks Hi I have a question related to the time stamp option. Is there any list somew= here what "timebase" various OS use for the timestamp. Thinking of Android,= Apple iOS , MS Windows etc. Then a question regarding http://tools.ietf.org/id/draft-scheffenegger-tcpm= -timestamp-negotiation-03.txt is this draft in an active state ?. Asking because something like this is p= robably needed for optimal performance for TCP with LEDBAT CC /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=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com www.thenodepole.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_DBB1DC060375D147AC43F310AD987DCC4B69966B3DESESSCMS0366e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
Thanks=20 for the response. I will read though the draft and see if I can contribute = with=20 something useful. It seems to be very well written though.
 
/Ingemar

From: Scheffenegger, Richard=20 [mailto:rs@netapp.com]
Sent: den 26 mars 2012 17:02
To:<= /B>=20 Ingemar Johansson S; tcpm@ietf.org
Subject: RE: Timestamp optio= n and=20 ticks

Hi=20 Ingemar,

During=20 my investigation, I didn=92t find any explicit way how to figure out the= =20 timebase; some implementations try to figure out the remote timebase duri= ng=20 the three way handshake, and then put the result in one of a small number= =20 of  buckets. However, this approach has a couple of obvious drawback= s=20 (ie. missing =93timebase=94 buckets, problems delineating between buckets= being=20 close together, transient network conditions during the measurement, to n= ame a=20 few).

The=20 draft has lingered somewhat, but I still want to drive it forward. From w= hat I=20 gathered during the last meetings, there is a general view that something= like=20 this is interesting, but the document is not ready for WGLC (or even=20 close).

I=20 believe part of that is, that the draft as it stands now mingles too much= of=20 the rationale for this modification, with the simple, straight-forward=20 implementation details. Perhaps I should split the document into two part= s.=20 But I really would appreciate any input as to how to proceed with this=20 proposal.

Also,=20 contributors are very welcome J

Richard=20 Scheffenegger

From:Hi

I = have a=20 question related to the time stamp option. Is there any list somewhere wh= at=20 "timebase" various OS use for the timestamp. Thinking of Android, Apple i= OS ,=20 MS Windows etc.

Th= en a=20 question regarding http://tools.ietf.org/id/draft-scheffenegger-tcpm-timestamp-= negotiation-03.txt=20

is= this=20 draft in an active state ?. Asking because something like this is probabl= y=20 needed for optimal performance for TCP with LEDBAT=20 CC

/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=20 Johansson  M.Sc.

Senior=20 Researcher

Ericsson=20 AB

Wireless Acc= ess=20 Networks

Labratoriegr= =E4nd=20 11

971 28, Lule= =E5,=20 Sweden

Phone +46-10= 71=20 43042

SMS/MMS +46-= 73 078=20 3289

ingemar.s.johansson@eric= sson.com

www.ericsson.com

www.thenodepole.com/

=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

<= /DIV>
--_000_DBB1DC060375D147AC43F310AD987DCC4B69966B3DESESSCMS0366e_-- From rs@netapp.com Tue Mar 27 04:36:53 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0421E8199 for ; Tue, 27 Mar 2012 04:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt0HveTpihni for ; Tue, 27 Mar 2012 04:36:50 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 89F2C21E8169 for ; Tue, 27 Mar 2012 04:36:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,325,1330934400"; d="scan'208,217";a="636511190" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 27 Mar 2012 04:36:48 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q2RBamM7015319; Tue, 27 Mar 2012 04:36:48 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.178]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 04:36:43 -0700 From: "Scheffenegger, Richard" To: Ingemar Johansson S , "tcpm@ietf.org" Thread-Topic: Timestamp option and ticks Thread-Index: Ac0LXUVs+icVS9c8SA2h+vDTCG8X5wAAwJhwACVjo8AABWL2gA== Date: Tue, 27 Mar 2012 11:36:42 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F12AD96@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F12976F@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F12AD96SACEXCMBX02PRDhqn_" MIME-Version: 1.0 Cc: "Michael Welzl \(michawe@ifi.uio.no\)" Subject: Re: [tcpm] Timestamp option and ticks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 11:36:53 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F12AD96SACEXCMBX02PRDhqn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ingemar, if you would be willing to formally review the draft (Michael Welzl also in= dicated that he'd volunteer as a reviewer, if he wouldn't be the only one)= , that would be great support already. After the reviews I'd like to ask th= e WG to adopt that draft unless someone has already major objections at thi= s time. Best regards, Richard Scheffenegger From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] Sent: Dienstag, 27. M=E4rz 2012 10:46 To: Scheffenegger, Richard; tcpm@ietf.org Subject: RE: Timestamp option and ticks Hi Thanks for the response. I will read though the draft and see if I can cont= ribute with something useful. It seems to be very well written though. /Ingemar ________________________________ From: Scheffenegger, Richard [mailto:rs@netapp.com] Sent: den 26 mars 2012 17:02 To: Ingemar Johansson S; tcpm@ietf.org Subject: RE: Timestamp option and ticks Hi Ingemar, During my investigation, I didn't find any explicit way how to figure out t= he timebase; some implementations try to figure out the remote timebase dur= ing the three way handshake, and then put the result in one of a small numb= er of buckets. However, this approach has a couple of obvious drawbacks (i= e. missing "timebase" buckets, problems delineating between buckets being c= lose together, transient network conditions during the measurement, to name= a few). The draft has lingered somewhat, but I still want to drive it forward. From= what I gathered during the last meetings, there is a general view that som= ething like this is interesting, but the document is not ready for WGLC (or= even close). I believe part of that is, that the draft as it stands now mingles too much= of the rationale for this modification, with the simple, straight-forward = implementation details. Perhaps I should split the document into two parts.= But I really would appreciate any input as to how to proceed with this pro= posal. Also, contributors are very welcome :) Richard Scheffenegger From: tcpm-bounces@ietf.org [mailto:tcpm-boun= ces@ietf.org] On Behalf Of Ingemar J= ohansson S Sent: Montag, 26. M=E4rz 2012 16:32 To: tcpm@ietf.org Subject: [tcpm] Timestamp option and ticks Hi I have a question related to the time stamp option. Is there any list somew= here what "timebase" various OS use for the timestamp. Thinking of Android,= Apple iOS , MS Windows etc. Then a question regarding http://tools.ietf.org/id/draft-scheffenegger-tcpm= -timestamp-negotiation-03.txt is this draft in an active state ?. Asking because something like this is p= robably needed for optimal performance for TCP with LEDBAT CC /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=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com www.thenodepole.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_012C3117EDDB3C4781FD802A8C27DD4F12AD96SACEXCMBX02PRDhqn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 <= /p>

Ingemar,

 <= /p>

if you wou= ld be willing to formally review the draft (Michael Welzl also indicated th= at he’d volunteer as a  reviewer, if he wouldn’t be the on= ly one), that would be great support already. After the reviews I’d lik= e to ask the WG to adopt that draft unless someone has already major object= ions at this time.

 = ;

Best regar= ds,

 = ;

Richard Scheffenegger

 <= /p>

From: Ingemar Johansson S [mailto:ingemar.s.johansson@erics= son.com]
Sent: Dienstag, 27. M=E4rz 2012 10:46
To: Scheffenegger, Richard; tcpm@ietf.org
Subject: RE: Timestamp option and ticks

 

Hi

 

Thanks for the response. I wil= l read though the draft and see if I can contribute with something useful. = It seems to be very well written though.

 

/Ingemar

 

From: Scheffenegger, Richard [mailto:rs@netapp.com]
Sent: den 26 mars 2012 17:02
To: Ingemar Johansson S; tcpm@ietf.= org
Subject: RE: Timestamp option and ticks<= o:p>

Hi Ingemar,

During my = investigation, I didn’t find any explicit way how to figure out the t= imebase; some implementations try to figure out the remote timebase during the three way handshake, and then put the result in one of a small = number of  buckets. However, this approach has a couple of obvious dra= wbacks (ie. missing “timebase” buckets, problems delineating be= tween buckets being close together, transient network conditions during the measurement, to name a few).

The draft = has lingered somewhat, but I still want to drive it forward. From what I ga= thered during the last meetings, there is a general view that something like this is interesting, but the document is not ready for WGLC= (or even close).

I believe = part of that is, that the draft as it stands now mingles too much of the ra= tionale for this modification, with the simple, straight-forward implementation details. Perhaps I should split the document into two parts= . But I really would appreciate any input as to how to proceed with this pr= oposal.

Also, cont= ributors are very welcome J

Richard Sc= heffenegger


From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Ingemar Johansson S<= br> Sent: Montag, 26. M=E4rz 2012 16:32
To: tcpm@ietf.org
Subject: [tcpm] Timestamp option and ticks

Hi

I have a question related to the time stamp option. Is the= re any list somewhere what "timebase" various OS use for the time= stamp. Thinking of Android, Apple iOS , MS Windows etc.

is this draft in an active state ?. Asking because somethi= ng like this is probably needed for optimal performance for TCP with LEDBAT= CC

/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=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

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

--_000_012C3117EDDB3C4781FD802A8C27DD4F12AD96SACEXCMBX02PRDhqn_-- From michael.scharf@alcatel-lucent.com Wed Mar 28 02:21:10 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD1A21E80FA for ; Wed, 28 Mar 2012 02:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.871 X-Spam-Level: X-Spam-Status: No, score=-9.871 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrEGSRTn0pRi for ; Wed, 28 Mar 2012 02:21:09 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5192321E809E for ; Wed, 28 Mar 2012 02:21:09 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2S9Jn9K031204 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 28 Mar 2012 11:20:59 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 28 Mar 2012 11:20:22 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Wed, 28 Mar 2012 11:20:20 +0200 Thread-Topic: TCPM status Thread-Index: Ac0Mw/9bhtBYlbSjQZeWQEofuwDmqA== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E88E443F202@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [tcpm] TCPM status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 09:21:10 -0000 Hi all, Below the usual update regarding the current TCPM status. Please let the ch= airs know any comments or feedback. Thanks Michael PS: I apologize for attending this IETF only on Friday. Recent RFCs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Clarification of sender behavior in persist condition=20 draft-ietf-tcpm-persist Status: RFC 6429 Defending Against Sequence Number Attacks draft-ietf-tcpm-rfc1948bis Status: RFC 6528 WG Items Nearing RFC Publication =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 The NewReno Modification to TCP's Fast Recovery Algorithm draft-ietf-tcpm-rfc3782-bis Milestone Target: Proposed Standard in April 2011 Status: RFC Editor Queue (RFC 6582) SACK Entry / RFC 3517bis draft-blanton-tcpm-3517bis Milestone Target: Proposed Standard in October 2010 Status: IESG processing WG Items in WGLC or being revised after WGLC =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MSS Option draft-ietf-tcpm-tcpmss Milestone Target: Proposed Standard in July 2009 Status: Needs revision Action: Update with post-WGLC comments in preparation Active WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1323bis draft-ietf-tcpm-1323bis Milestone Target: Proposed Standard in July 2009 Status: Needs revision Action: Action with David Borman TCP Security draft-ietf-tcpm-tcp-security Milestone Target: August 2010 Status: Version -03 with reduced scope (informational) Action: Discussion during IETF 83 Increasing the Initial Window draft-ietf-tcpm-initcwnd Milestone Target: Experimental in September 2011 Status: Under active discussion / review Action: WGLC planned Proportional Rate Reduction for TCP draft-ietf-tcpm-proportional-rate-reduction Milestone Target: Experimental in May 2012 Status: Under active discussion / review Action: WGLC planned Shared Use of Experimental TCP Options draft-ietf-tcpm-experimental-options Milestone Target: PS in Sept. 2012 Status: Under active discussion / review Action: Continue discussion on list TCP Fast Open draft-ietf-tcpm-fastopen Milestone Target: Experimental in Sept. 2012 Status: Under active discussion / review Action: Continue discussion Documents Under a Poll to Become WG Items =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=3D=3D=3D=3D=3D=3D=3D=3D Active Internet-Drafts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D draft-ananth-tcpm-tcpoptext draft-hurtig-tcpm-rtorestart draft-kuehlewind-tcpm-accurate-ecn draft-kuehlewind-tcpm-accurate-ecn-option draft-mathis-tcpm-tcp-laminar draft-scheffenegger-tcpm-timestamp-negotiation draft-touch-tcpm-automatic-iw (+ many expired Internet-Drafts) Other WG Activities =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Errata Review for legacy TCP RFCs (many outstanding)= From iesg-secretary@ietf.org Wed Mar 28 05:42:53 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27DB21E81E6; Wed, 28 Mar 2012 05:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mrJVXvDUSiC; Wed, 28 Mar 2012 05:42:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001E921E81DC; Wed, 28 Mar 2012 05:42:53 -0700 (PDT) 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: 4.00 Message-ID: <20120328124252.16470.54400.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 05:42:52 -0700 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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: Wed, 28 Mar 2012 12:42:54 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP' as a Proposed Standard 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 2012-04-11. 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 presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-3517bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-3517bis/ballot/ No IPR declarations have been submitted directly on this I-D. From prvs=9433c159c1=david.borman@quantum.com Tue Mar 27 08:34:49 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9E721E820F for ; Tue, 27 Mar 2012 08:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EYRpt+A17GH for ; Tue, 27 Mar 2012 08:34:48 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id 9069321E81FD for ; Tue, 27 Mar 2012 08:34:48 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.4/8.14.4) with SMTP id q2RFXXYn005710 for ; Tue, 27 Mar 2012 08:34:48 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0a-000ceb01.pphosted.com with ESMTP id 13ug4qg13d-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 27 Mar 2012 08:34:48 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 27 Mar 2012 08:34:37 -0700 Received: from PPOMSG1.QUANTUM.com ([fe80::6081:f8af:54f6:10cc]) by PPOMSG2.QUANTUM.com ([fe80::e4fd:df34:99ee:ac5e%20]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 09:34:47 -0600 From: David Borman To: TCP Maintenance and Minor Extensions WG Thread-Topic: Update for TCP MSS draft Thread-Index: AQHNDC8j7eMFz8DrJU6X7kayE2q/fg== Date: Tue, 27 Mar 2012 15:34:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-ID: <31FBDE839708F94F8232169B57D30BC6@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-03-27_06:2012-03-27, 2012-03-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1203270151 Content-Type: text/plain; charset="ISO-8859-1" X-Mailman-Approved-At: Wed, 28 Mar 2012 08:12:42 -0700 Subject: [tcpm] Update for TCP MSS draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 15:36:40 -0000 I've just submitted an update to the TCP MSS draft, to address some comment= s made after the WG Last Call, and some things pointed out by the I-D Nits = tool. I'm attaching a diff of the full list of changes. Many of them are just ch= anging format from "RFC-XXX" to "RFC XXX". Aside from that, fix a typo of = 897 that should be 879, add comments to the Abstract that it updates RFC 87= 9 and RFC 2385, and add some clarification to the text after the table. -David Borman ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From prvs=9433c159c1=david.borman@quantum.com Tue Mar 27 08:40:59 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ABC21E824C for ; Tue, 27 Mar 2012 08:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSveNievKGdi for ; Tue, 27 Mar 2012 08:40:58 -0700 (PDT) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id 979CB21E8243 for ; Tue, 27 Mar 2012 08:40:58 -0700 (PDT) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.4/8.14.4) with SMTP id q2RFce1g011395 for ; Tue, 27 Mar 2012 08:40:58 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0a-000ceb01.pphosted.com with ESMTP id 13ug4qg1ks-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 27 Mar 2012 08:40:58 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 27 Mar 2012 08:40:47 -0700 Received: from PPOMSG1.QUANTUM.com ([fe80::6081:f8af:54f6:10cc]) by PPOMSG2.QUANTUM.com ([fe80::e4fd:df34:99ee:ac5e%20]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 09:40:57 -0600 From: David Borman To: TCP Maintenance and Minor Extensions WG Thread-Topic: Update for TCP MSS draft Thread-Index: AQHNDC8j7eMFz8DrJU6X7kayE2q/fpZ+rDYA Date: Tue, 27 Mar 2012 15:40:57 +0000 Message-ID: <3DCF0EBF-2006-46E7-9D05-BD97849A4CDA@quantum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: multipart/mixed; boundary="_004_3DCF0EBF200646E79D05BD97849A4CDAquantumcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-03-27_06:2012-03-27, 2012-03-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1203270153 X-Mailman-Approved-At: Wed, 28 Mar 2012 08:13:06 -0700 Subject: Re: [tcpm] Update for TCP MSS draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 15:40:59 -0000 --_004_3DCF0EBF200646E79D05BD97849A4CDAquantumcom_ Content-Type: multipart/alternative; boundary="_000_3DCF0EBF200646E79D05BD97849A4CDAquantumcom_" --_000_3DCF0EBF200646E79D05BD97849A4CDAquantumcom_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" QW5kIG5vdyBmb3IgdGhlIGF0dGFjaG1lbnTigKYNCg0KDQpPbiBNYXIgMjcsIDIwMTIsIGF0IDEw OjM0IEFNLCBEYXZpZCBCb3JtYW4gd3JvdGU6DQoNCj4gSSd2ZSBqdXN0IHN1Ym1pdHRlZCBhbiB1 cGRhdGUgdG8gdGhlIFRDUCBNU1MgZHJhZnQsIHRvIGFkZHJlc3Mgc29tZSBjb21tZW50cyBtYWRl IGFmdGVyIHRoZSBXRyBMYXN0IENhbGwsIGFuZCBzb21lIHRoaW5ncyBwb2ludGVkIG91dCBieSB0 aGUgSS1EIE5pdHMgdG9vbC4NCj4NCj4gSSdtIGF0dGFjaGluZyBhIGRpZmYgb2YgdGhlIGZ1bGwg bGlzdCBvZiBjaGFuZ2VzLiAgTWFueSBvZiB0aGVtIGFyZSBqdXN0IGNoYW5naW5nIGZvcm1hdCBm cm9tICJSRkMtWFhYIiB0byAiUkZDIFhYWCIuICBBc2lkZSBmcm9tIHRoYXQsIGZpeCBhIHR5cG8g b2YgODk3IHRoYXQgc2hvdWxkIGJlIDg3OSwgYWRkIGNvbW1lbnRzIHRvIHRoZSBBYnN0cmFjdCB0 aGF0IGl0IHVwZGF0ZXMgUkZDIDg3OSBhbmQgUkZDIDIzODUsIGFuZCBhZGQgc29tZSBjbGFyaWZp Y2F0aW9uIHRvIHRoZSB0ZXh0IGFmdGVyIHRoZSB0YWJsZS4NCj4NCj4gICAgICAgICAgICAgICAg ICAgICAgICAtRGF2aWQgQm9ybWFuDQo+DQoNCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gbWF5IGJlIGNvbmZpZGVudGlhbC4gQW55 IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIG9yIGZ1cnRoZXIgZGlzdHJpYnV0aW9uIG9mIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiBpcyBub3QgcGVybWl0dGVkIHVubGVzcyBzdWNoIHByaXZpbGVnZSBp cyBleHBsaWNpdGx5IGdyYW50ZWQgaW4gd3JpdGluZyBieSBRdWFudHVtLiBRdWFudHVtIHJlc2Vy dmVzIHRoZSByaWdodCB0byBoYXZlIGVsZWN0cm9uaWMgY29tbXVuaWNhdGlvbnMsIGluY2x1ZGlu ZyBlbWFpbCBhbmQgYXR0YWNobWVudHMsIHNlbnQgYWNyb3NzIGl0cyBuZXR3b3JrcyBmaWx0ZXJl ZCB0aHJvdWdoIGFudGkgdmlydXMgYW5kIHNwYW0gc29mdHdhcmUgcHJvZ3JhbXMgYW5kIHJldGFp biBzdWNoIG1lc3NhZ2VzIGluIG9yZGVyIHRvIGNvbXBseSB3aXRoIGFwcGxpY2FibGUgZGF0YSBz ZWN1cml0eSBhbmQgcmV0ZW50aW9uIHJlcXVpcmVtZW50cy4gUXVhbnR1bSBpcyBub3QgcmVzcG9u c2libGUgZm9yIHRoZSBwcm9wZXIgYW5kIGNvbXBsZXRlIHRyYW5zbWlzc2lvbiBvZiB0aGUgc3Vi c3RhbmNlIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBvciBmb3IgYW55IGRlbGF5IGluIGl0cyByZWNl aXB0Lgo= --_000_3DCF0EBF200646E79D05BD97849A4CDAquantumcom_ Content-ID: Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBjbGFzcz0i Qm9keUZyYWdtZW50Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7 Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+QW5kIG5vdyBmb3IgdGhlIGF0dGFjaG1lbnTigKY8 YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSJCb2R5RnJhZ21l bnQiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPg0KPGRpdiBj bGFzcz0iUGxhaW5UZXh0Ij48YnI+DQo8YnI+DQpPbiBNYXIgMjcsIDIwMTIsIGF0IDEwOjM0IEFN LCBEYXZpZCBCb3JtYW4gd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBJJ3ZlIGp1c3Qgc3VibWl0dGVk IGFuIHVwZGF0ZSB0byB0aGUgVENQIE1TUyBkcmFmdCwgdG8gYWRkcmVzcyBzb21lIGNvbW1lbnRz IG1hZGUgYWZ0ZXIgdGhlIFdHIExhc3QgQ2FsbCwgYW5kIHNvbWUgdGhpbmdzIHBvaW50ZWQgb3V0 IGJ5IHRoZSBJLUQgTml0cyB0b29sLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJJ20gYXR0YWNoaW5n IGEgZGlmZiBvZiB0aGUgZnVsbCBsaXN0IG9mIGNoYW5nZXMuJm5ic3A7IE1hbnkgb2YgdGhlbSBh cmUganVzdCBjaGFuZ2luZyBmb3JtYXQgZnJvbSAmcXVvdDtSRkMtWFhYJnF1b3Q7IHRvICZxdW90 O1JGQyBYWFgmcXVvdDsuJm5ic3A7IEFzaWRlIGZyb20gdGhhdCwgZml4IGEgdHlwbyBvZiA4OTcg dGhhdCBzaG91bGQgYmUgODc5LCBhZGQgY29tbWVudHMgdG8gdGhlIEFic3RyYWN0IHRoYXQgaXQg dXBkYXRlcyBSRkMgODc5IGFuZCBSRkMgMjM4NSwgYW5kIGFkZCBzb21lIGNsYXJpZmljYXRpb24N CiB0byB0aGUgdGV4dCBhZnRlciB0aGUgdGFibGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1EYXZpZCBCb3JtYW48YnI+DQomZ3Q7IDxicj4NCjxicj4NCjwv ZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCgo8SFI+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBtYXkgYmUgY29uZmlkZW50aWFsLiBBbnkgZGlzY2xvc3Vy ZSwgY29weWluZywgb3IgZnVydGhlciBkaXN0cmlidXRpb24gb2YgY29uZmlkZW50aWFsIGluZm9y bWF0aW9uIGlzIG5vdCBwZXJtaXR0ZWQgdW5sZXNzIHN1Y2ggcHJpdmlsZWdlIGlzIGV4cGxpY2l0 bHkgZ3JhbnRlZCBpbiB3cml0aW5nIGJ5IFF1YW50dW0uIFF1YW50dW0gcmVzZXJ2ZXMgdGhlIHJp Z2h0IHRvIGhhdmUgZWxlY3Ryb25pYyBjb21tdW5pY2F0aW9ucywgaW5jbHVkaW5nIGVtYWlsIGFu ZCBhdHRhY2htZW50cywgc2VudCBhY3Jvc3MgaXRzIG5ldHdvcmtzIGZpbHRlcmVkIHRocm91Z2gg YW50aSB2aXJ1cyBhbmQgc3BhbSBzb2Z0d2FyZSBwcm9ncmFtcyBhbmQgcmV0YWluIHN1Y2ggbWVz c2FnZXMgaW4gb3JkZXIgdG8gY29tcGx5IHdpdGggYXBwbGljYWJsZSBkYXRhIHNlY3VyaXR5IGFu ZCByZXRlbnRpb24gcmVxdWlyZW1lbnRzLiBRdWFudHVtIGlzIG5vdCByZXNwb25zaWJsZSBmb3Ig dGhlIHByb3BlciBhbmQgY29tcGxldGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBzdWJzdGFuY2Ugb2Yg dGhpcyBjb21tdW5pY2F0aW9uIG9yIGZvciBhbnkgZGVsYXkgaW4gaXRzIHJlY2VpcHQuPEJSPgo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_3DCF0EBF200646E79D05BD97849A4CDAquantumcom_-- --_004_3DCF0EBF200646E79D05BD97849A4CDAquantumcom_ Content-Type: application/octet-stream; name="draft-ietf-tcpm-tcpmss-04.diff" Content-Description: draft-ietf-tcpm-tcpmss-04.diff Content-Disposition: attachment; filename="draft-ietf-tcpm-tcpmss-04.diff"; size=7810; creation-date="Tue, 27 Mar 2012 15:40:56 GMT"; modification-date="Tue, 27 Mar 2012 15:40:56 GMT" Content-ID: Content-Transfer-Encoding: base64 LS0tIGRyYWZ0LWlldGYtdGNwbS10Y3Btc3MtMDMubnJvZmYJMjAxMC0wMy0yNSAxNzo1Mzo1My4w MDAwMDAwMDAgLTA1MDANCisrKyBkcmFmdC1pZXRmLXRjcG0tdGNwbXNzLTA0Lm5yb2ZmCTIwMTIt MDMtMjcgMTA6MTY6NTguMDAwMDAwMDAwIC0wNTAwDQpAQCAtMSwxNiArMSwxNyBAQA0KIC5zbyBy ZmMubWFjcm8NCiAuZHMgVEwgVENQIE9wdGlvbnMgYW5kIE1TUw0KLS5kcyBGTCBkcmFmdC1pZXRm LXRjcG0tdGNwbXNzLTAzLnR4dA0KKy5kcyBGTCBkcmFmdC1pZXRmLXRjcG0tdGNwbXNzLTA0LnR4 dA0KIC5kcyBJUyBJbmZvcm1hdGlvbmFsDQogLmRzIFdHIE5ldHdvcmsgV29ya2luZyBHcm91cA0K IC5kcyBSTiBEUkFGVA0KIC5kcyBBVSBELiBCb3JtYW4NCi0uZHMgQ08gV2luZCBSaXZlciBTeXN0 ZW1zDQorLmRzIENPIFF1YW50dW0gQ29ycG9yYXRpb24NCiAuZHMgVUQgODc5LCAyMzg1DQogLkhE DQogQWJzdHJhY3QNCiAuSU4gKzAuM2kNCi1UaGlzIG1lbW8gZGlzY3Vzc2VzIHdoYXQgdmFsdWUg dG8gdXNlIHdpdGggdGhlIFRDUCBNU1Mgb3B0aW9uLg0KK1RoaXMgbWVtbyBkaXNjdXNzZXMgd2hh dCB2YWx1ZSB0byB1c2Ugd2l0aCB0aGUgVENQIE1TUyBvcHRpb24sDQorYW5kIHVwZGF0ZXMgUkZD IDg3OSBhbmQgUkZDIDIzODUuDQogLnNwDQogLklOIC0wLjNpDQogU3RhdHVzIG9mIFRoaXMgTWVt bw0KQEAgLTI3LDEzICsyOCwxMyBAQA0KIC5zcA0KIFRoZXJlIGhhcyBiZWVuIHNvbWUgY29uZnVz aW9uIGFzIHRvIHdoYXQgdmFsdWUgc2hvdWxkIGJlIGZpbGxlZCBpbg0KIHRoZSBUQ1AgTVNTIG9w dGlvbiB3aGVuIHVzaW5nIElQIGFuZCBUQ1Agb3B0aW9ucy4NCi1SRkMtODc5IFtSRkM4NzldIHN0 YXRlZDoNCitSRkMgODc5IFtSRkM4NzldIHN0YXRlZDoNCiAuSU4gKzAuNWkNCiBUaGUgTVNTIGNv dW50cyBvbmx5IGRhdGEgb2N0ZXRzIGluIHRoZSBzZWdtZW50LCBpdCBkb2VzIG5vdCBjb3VudCB0 aGUNCiBUQ1AgaGVhZGVyIG9yIHRoZSBJUCBoZWFkZXIuDQogLklOIC0wLjVpDQogd2hpY2ggaXMg dW5jbGVhciBhYm91dCB3aGF0IHRvIGRvIGFib3V0IElQIGFuZCBUQ1Agb3B0aW9ucywgc2luY2Ug dGhleQ0KLWFyZSBwYXJ0IG9mIHRoZSBoZWFkZXJzLiAgUkZDLTExMjIgW1JGQzExMjJdIGNsYXJp ZmllZCB0aGUgTVNTDQorYXJlIHBhcnQgb2YgdGhlIGhlYWRlcnMuICBSRkMgMTEyMiBbUkZDMTEy Ml0gY2xhcmlmaWVkIHRoZSBNU1MNCiBvcHRpb24gKHNlZSBBcHBlbmRpeCBBKSwgYnV0IHRoZXJl IHN0aWxsIHNlZW1zIHRvIGJlIHNvbWUgY29uZnVzaW9uLg0KIC5zcA0KIC5MVCAiMS4xIFRlcm1p bm9sb2d5IiAwLjNpDQpAQCAtNTQsMTcgKzU1LDE3IEBADQogVGhlIHJlc3Qgb2YgdGhpcyBkb2N1 bWVudCBqdXN0IGV4cG91bmRzIG9uIHRoYXQgc3RhdGVtZW50LCBhbmQNCiB0aGUgZ29hbCBpcyB0 byBhdm9pZCBJUCBsZXZlbCBmcmFnbWVudGF0aW9uIG9mIFRDUCBwYWNrZXRzLg0KIC5zcA0KLVRo ZSBzaXplIG9mIHRoZSBmaXhlZCBUQ1AgaGVhZGVyIGlzIDIwIGJ5dGVzLCB0aGUgc2l6ZSBvZiB0 aGUNCi1maXhlZCBJUHY0IGhlYWRlciBpcyAyMCBieXRlcywgYW5kIHRoZSBzaXplIG9mIHRoZSBm aXhlZCBJUHY2DQotaGVhZGVyIGlzIDQwIGJ5dGVzLiAgVGhlIGRldGVybWluYXRpb24gb2Ygd2hh dCBNVFUgdmFsdWUgc2hvdWxkIGJlDQorVGhlIHNpemUgb2YgdGhlIGZpeGVkIFRDUCBoZWFkZXIg aXMgMjAgYnl0ZXMgW1JGQzc5M10sIHRoZSBzaXplIG9mIHRoZQ0KK2ZpeGVkIElQdjQgaGVhZGVy IGlzIDIwIGJ5dGVzIFtSRkM3OTFdLCBhbmQgdGhlIHNpemUgb2YgdGhlIGZpeGVkIElQdjYNCito ZWFkZXIgaXMgNDAgYnl0ZXMgW1JGQzI0NjBdLiAgVGhlIGRldGVybWluYXRpb24gb2Ygd2hhdCBN VFUgdmFsdWUgc2hvdWxkIGJlDQogdXNlZCwgZXNwZWNpYWxseSBpbiB0aGUgY2FzZSBvZiBtdWx0 aS1ob21lZCBob3N0cywgaXMgYmV5b25kDQogdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQog LnNwDQogLkxUICIzLiBNU1MgaW4gdG8gb3RoZXIgUkZDcyIgMC4zaQ0KIC5JTiArMC4zaQ0KLS5M VCAiMy4xIFJGQy04NzkiIDAuM2kNCisuTFQgIjMuMSBSRkMgODc5IiAwLjNpDQogLnNwDQotUkZD LTg5NyBbUkZDODc5XSBkaXNjdXNzZXMgdGhlIE1TUyBvcHRpb24gYW5kIG90aGVyIHRvcGljcy4N CitSRkMgODc5IFtSRkM4NzldIGRpc2N1c3NlcyB0aGUgTVNTIG9wdGlvbiBhbmQgb3RoZXIgdG9w aWNzLg0KIEluIHRoZSBpbnRyb2R1Y3Rpb24sIGl0IHN0YXRlczoNCiAuSU4gKzAuM2kNCiAiVEhF IFRDUCBNQVhJTVVNIFNFR01FTlQgU0laRSBJUyBUSEUgSVAgTUFYSU1VTSBEQVRBR1JBTSBTSVpF IE1JTlVTIEZPUlRZLiINCkBAIC05Niw5ICs5Nyw5IEBADQogaW4gYW55IGdpdmVuIHBhY2tldCBi eSBudW1iZXIgb2Ygb2N0ZXRzIHVzZWQgYnkgdGhlIElQIGFuZCBUQ1ANCiBvcHRpb25zLg0KIC5J TiAtMC4zaQ0KLS5MVCAiMy4yIFJGQy0yMzg1IiAwLjNpDQorLkxUICIzLjIgUkZDIDIzODUiIDAu M2kNCiAuc3ANCi1SRkMtMjM4NSBbUkZDMjM4NV0gaW5jb3JyZWN0bHkgc3RhdGVzIGluIHNlY3Rp b24gNC4zOg0KK1JGQyAyMzg1IFtSRkMyMzg1XSBpbmNvcnJlY3RseSBzdGF0ZXMgaW4gc2VjdGlv biA0LjM6DQogLklOICswLjNpDQogIkFzIHdpdGggb3RoZXIgb3B0aW9ucyB0aGF0IGFyZSBhZGRl ZCB0byBldmVyeSBzZWdtZW50LCB0aGUgc2l6ZSBvZg0KIHRoZSBNRDUgb3B0aW9uIG11c3QgYmUg ZmFjdG9yZWQgaW50byB0aGUgTVNTIG9mZmVyZWQgdG8gdGhlIG90aGVyDQpAQCAtMTQwLDEwICsx NDEsMTIgQEANCiArLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQogLmZpDQogLnNwDQotU2luY2UgdGhlIGdvYWwgaXMgdG8gbm90 IHNlbmQgSVAgZGF0YWdyYW1zIHRoYXQgaGF2ZSB0byBiZQ0KK1RoZSBnb2FsIGlzIHRvIG5vdCBz ZW5kIElQIGRhdGFncmFtcyB0aGF0IGhhdmUgdG8gYmUNCiBmcmFnbWVudGVkLCBhbmQgcGFja2V0 cyBzZW50IHdpdGggdGhlIGNvbnN0cmFpbnRzIGluDQotdGhlIGxvd2VyIHJpZ2h0IG9mIHRoaXMg Z3JpZCB3aWxsIGNhdXNlIElQIGZyYWdtZW50YXRpb24sDQotdGhlIG9ubHkgd2F5IHRvIGd1YXJh bnRlZSB0aGF0IHRoaXMgZG9lc24ndCBoYXBwZW4gaXMgZm9yDQordGhlIGxvd2VyIHJpZ2h0IG9m IHRoaXMgZ3JpZCB3aWxsIGNhdXNlIElQIGZyYWdtZW50YXRpb24uDQorU2luY2UgdGhlIHNlbmRl ciBkb2Vzbid0IGtub3cgaWYgdGhlIHJlY2VpdmVkIE1TUyBvcHRpb24NCit3YXMgYWRqdXN0ZWQg dG8gaW5jbHVkZSBvcHRpb25zLA0KK3RoZSBvbmx5IHdheSB0byBndWFyYW50ZWUgdGhhdCB0aGUg cGFja2V0cyBhcmUgbm90IHRvbyBsb25nIGlzIGZvcg0KIHRoZSBkYXRhIHNlbmRlciB0byBkZWNy ZWFzZSB0aGUgVENQIGRhdGEgbGVuZ3RoIGJ5IHRoZQ0KIHNpemUgb2YgdGhlIElQIGFuZCBUQ1Ag b3B0aW9ucy4NCiBJdCBmb2xsb3dzIHRoZW4sIHRoYXQgc2luY2UgdGhlIHNlbmRlciB3aWxsIGJl IGFkanVzdGluZyB0aGUgVENQIGRhdGENCkBAIC0xNzAsMTEgKzE3MywxMSBAQA0KIHRvIGZpbmQg YSBsYXJnZXIgUGF0aCBNVFUuICBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBQYXRoDQogTVRVIERp c2NvdmVyeSwgc2VlOg0KIC5JTiArMC4zaQ0KLVJGQy0xMTkxICAiUGF0aCBNVFUgRGlzY292ZXJ5 IiBbUkZDMTE5MV0NCitSRkMgMTE5MSAgIlBhdGggTVRVIERpc2NvdmVyeSIgW1JGQzExOTFdDQog LmJyDQotUkZDLTI5MjMgIlRDUCBQcm9ibGVtcyB3aXRoIFBhdGggTVRVIERpc2NvdmVyeSIgW1JG QzI5MjNdDQorUkZDIDI5MjMgIlRDUCBQcm9ibGVtcyB3aXRoIFBhdGggTVRVIERpc2NvdmVyeSIg W1JGQzI5MjNdDQogLmJyDQotUkZDLTQ4MjEgIlBhY2tldGl6YXRpb24gTGF5ZXIgUGF0aCBNVFUg RGlzY292ZXJ5IiBbUkZDNDgyMV0NCitSRkMgNDgyMSAiUGFja2V0aXphdGlvbiBMYXllciBQYXRo IE1UVSBEaXNjb3ZlcnkiIFtSRkM0ODIxXQ0KIC5JTiAtMC4zaQ0KIC5zcA0KIC5MVCAiNS4yIElu dGVyZmFjZXMgd2l0aCBWYXJpYWJsZSBNU1MgdmFsdWVzIiAwLjNpDQpAQCAtMTk2LDcgKzE5OSw3 IEBADQogLkxUICI1LjMgSVB2NiBKdW1ib2dyYW1zIiAwLjNpDQogLnNwDQogSW4gb3JkZXIgdG8g c3VwcG9ydCBUQ1Agb3ZlciBJUHY2IEp1bWJvZ3JhbXMsIGltcGxlbWVudGF0aW9ucw0KLW5lZWQg dG8gYmUgYWJsZSB0byBzZW5kIFRDUCBzZWdtZW50cyBsYXJnZXIgdGhhbiA2NEsuICBSRkMtMjY3 NSBbUkZDMjY3NV0NCituZWVkIHRvIGJlIGFibGUgdG8gc2VuZCBUQ1Agc2VnbWVudHMgbGFyZ2Vy IHRoYW4gNjRLLiAgUkZDIDI2NzUgW1JGQzI2NzVdDQogZGVmaW5lcyB0aGF0IGEgdmFsdWUgb2Yg NjUsNTM1IGlzIHRvIGJlIHRyZWF0ZWQgYXMgaW5maW5pdHksIGFuZA0KIFBhdGggTVRVIERpc2Nv dmVyeSBbUkZDMTk4MV0gaXMgdXNlZCB0byBkZXRlcm1pbmUgdGhlIGFjdHVhbCBNU1MuDQogLklO IC0wLjNpDQpAQCAtMjIzLDU1ICsyMjYsNjIgQEANCiB0byB0aGUgdGNwbHcgbWFpbGluZyBsaXN0 LCBKYW4gNywgMTk5My4NCiAuc3ANCiAubmUgMg0KK1tSRkM3OTFdIFBvc3RlbCwgSi4sICJJbnRl cm5ldCBQcm90b2NvbCwiDQorUkZDIDc5MSwgU2VwdGVtYmVyIDE5ODEuDQorLnNwDQorLm5lIDIN CiBbUkZDNzkzXSBQb3N0ZWwsIEouLCAiVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wsIg0K LVJGQy03OTMsIFNlcHRlbWJlciAxOTgxLg0KK1JGQyA3OTMsIFNlcHRlbWJlciAxOTgxLg0KIC5z cA0KIC5uZSAzDQogW1JGQzg3OV0gUG9zdGVsLCBKLiwgIlRoZSBUQ1AgTWF4aW11bSBTZWdtZW50 IFNpemUgYW5kIFJlbGF0ZWQgVG9waWNzIiwNCi1SRkMtODc5LCBJU0ksIE5vdmVtYmVyIDE5ODMu DQorUkZDIDg3OSwgSVNJLCBOb3ZlbWJlciAxOTgzLg0KIC5zcA0KIC5uZSAyDQogW1JGQzExMjJd IEJyYWRlbiwgUi4sIGVkaXRvciwNCiAiUmVxdWlyZW1lbnRzIGZvciBJbnRlcm5ldCBIb3N0cyAt LSBDb21tdW5pY2F0aW9uIExheWVycyIsDQotUkZDLTExMjIsIE9jdG9iZXIsIDE5ODkuDQorUkZD IDExMjIsIE9jdG9iZXIsIDE5ODkuDQogLnNwDQogLm5lIDINCiBbUkZDMTE5MV0gTW9ndWwsIEou Qy4sIERlZXJpbmcsIFMuRS4sICJQYXRoIE1UVSBkaXNjb3ZlcnkiDQotUkZDLTExOTEsIE5vdmVt YmVyIDE5OTAuDQorUkZDIDExOTEsIE5vdmVtYmVyIDE5OTAuDQogLnNwDQogLm5lIDINCiBbUkZD MTk4MV0gTWNDYW5uLCBKLiwgRGVlcmluZywgUy4gYW5kIE1vZ3VsLCBKLiwsICJQYXRoIE1UVSBE aXNjb3ZlcnkNCi1mb3IgSVAgVmVyc2lvbiA2IiwgUkZDLTE5ODEsIEF1Z3VzdCAxOTg2Lg0KK2Zv ciBJUCBWZXJzaW9uIDYiLCBSRkMgMTk4MSwgQXVndXN0IDE5ODYuDQogLnNwDQogLm5lIDINCiBb UkZDMjExOV0gQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGlj YXRlDQotUmVxdWlyZW1lbnQgTGV2ZWxzIiwgUkZDLTIxMTksIE1hcmNoIDE5OTcuDQorUmVxdWly ZW1lbnQgTGV2ZWxzIiwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQogLnNwDQogLm5lIDMNCiBbUkZD MjM4NV0gSGVmZmVybmFuLCBBLiwgIlByb3RlY3Rpb24gb2YgQkdQIFNlc3Npb25zIHZpYSB0aGUN Ci1UQ1AgTUQ1IFNpZ25hdHVyZSBPcHRpb24iLCBSRkMtMjM4NSwgQXVndXN0IDE5ODguDQorVENQ IE1ENSBTaWduYXR1cmUgT3B0aW9uIiwgUkZDIDIzODUsIEF1Z3VzdCAxOTg4Lg0KKy5zcA0KKy5u ZSAzDQorW1JGQzI0NjBdIERlZXJpbmcsIFMuLCBIaW5kZW4sIFIuLCAiSW50ZXJuZXQgUHJvdG9j b2wsIFZlcnNpb24gNiAoSVB2NikgU3BlY2lmaWNhdGlvbiIsIFJGQyAyNDYwLCBEZWNlbWJlciwg MTk5OC4NCiAuc3ANCiAubmUgMg0KIFtSRkMyNjc1XSBCb3JtYW4sIEQuLCBEZWVyaW5nLCBTLiwg SGluZGVuLCBSLiwgIklQdjYgSnVtYm9ncmFtcyIsDQotUkZDLTI2NzUsIEF1Z3VzdCwgMTk5OS4N CitSRkMgMjY3NSwgQXVndXN0LCAxOTk5Lg0KIC5zcA0KIC5uZSAyDQogW1JGQzI5MjNdIExhaGV5 LCBLLiwgIlRDUCBQcm9ibGVtcyB3aXRoIFBhdGggTVRVIERpc2NvdmVyeSIsDQotUkZDLTI5MjMs IFNlcHRlbWJlciAyMDAwLg0KK1JGQyAyOTIzLCBTZXB0ZW1iZXIgMjAwMC4NCiAuc3ANCiAubmUg Mg0KIFtSRkM0ODIxXSBNYXRoaXMsIE0uLCBIZWZmbmVyLCBKLiwgIlBhY2tldGl6YXRpb24gTGF5 ZXIgUGF0aCBNVFUgRGlzY292ZXJ5IiwNCi1SRkMtNDgyMSwgTWFyY2ggMjAwNy4NCitSRkMgNDgy MSwgTWFyY2ggMjAwNy4NCiAuc3ANCiAubjMgMw0KIFtSRkM1Nzk1XSBTYW5kbHVuZCwgSy4sIEdl bGxldGllciwgRy4gYW5kIEpvbnNzb24sIEwtRS4sDQotIlRoZSBST2J1c3QgSGVhZGVyIENvbXBy ZXNzaW9uIChST0hDKSBGcmFtZXdvcmsiLCBSRkMtNTc5NSwgTWFyY2ggMjAxMC4NCisiVGhlIFJP YnVzdCBIZWFkZXIgQ29tcHJlc3Npb24gKFJPSEMpIEZyYW1ld29yayIsIFJGQyA1Nzk1LCBNYXJj aCAyMDEwLg0KIC5icA0KIC5JTiAtMC4zaQ0KIC5zcA0KLS5MVCAiQXBwZW5kaXggQTogRGV0YWls cyBmcm9tIFJGQy03OTMgYW5kIFJGQy0xMTIyIiAwLjNpDQorLkxUICJBcHBlbmRpeCBBOiBEZXRh aWxzIGZyb20gUkZDIDc5MyBhbmQgUkZDIDExMjIiIDAuM2kNCiAuc3ANCi1SRkMtNzkzIFtSRkM3 OTNdIGRlZmluZXMgdGhlIE1TUyBvcHRpb246DQorUkZDIDc5MyBbUkZDNzkzXSBkZWZpbmVzIHRo ZSBNU1Mgb3B0aW9uOg0KIC5JTiArMC41aQ0KIC5uZg0KIE1heGltdW0gU2VnbWVudCBTaXplIE9w dGlvbiBEYXRhOiAgMTYgYml0cw0KQEAgLTI4Miw3ICsyOTIsNyBAQA0KICAgb3B0aW9uIGlzIG5v dCB1c2VkLCBhbnkgc2VnbWVudCBzaXplIGlzIGFsbG93ZWQuDQogLmZpDQogLklOIC0wLjVpDQot UkZDLTExMjIgW1JGQzExMjJdIHByb3ZpZGVzIGFkZGl0aW9uYWwgY2xhcmlmaWNhdGlvbg0KK1JG QyAxMTIyIFtSRkMxMTIyXSBwcm92aWRlcyBhZGRpdGlvbmFsIGNsYXJpZmljYXRpb24NCiBpbiBz ZWN0aW9uIDQuMi4yLjYsIHBhZ2VzIDg1LTg2LiAgRmlyc3QsIGl0IGNoYW5nZXMgdGhlDQogZGVm YXVsdCBiZWhhdmlvciB3aGVuIHRoZSBNU1Mgb3B0aW9uDQogaXMgbm90IHByZXNlbnQ6DQpAQCAt MzM0LDcgKzM0NCw3IEBADQogY2FuIGJlIHJlY2VpdmVkIHdpdGhvdXQgZnJhZ21lbnRhdGlvbi4g IFRha2luZyB0aGlzIGxpdGVyYWxseSwgc2luY2UNCiBtb3N0IG1vZGVybiBUQ1AvSVAgaW1wbGVt ZW50YXRpb25zIGNhbiByZWFzc2VtYmxlIGEgZnVsbCA2NEsgSVANCiBwYWNrZXQsIGltcGxlbWVu dGF0aW9ucyBzaG91bGQgYmUgdXNpbmcgNjU1MzUgLSAyMCAtIDIwLCBvciA2NTQ5NSBmb3IgdGhl DQotTVNTIG9wdGlvbi4gIEJ1dCB0aGVyZSBpcyBtb3JlIHRvIGl0IHRoYW4gdGhhdCwgaW4gUkZD LTExMjIgb24gcGFnZSA4Ng0KK01TUyBvcHRpb24uICBCdXQgdGhlcmUgaXMgbW9yZSB0byBpdCB0 aGFuIHRoYXQsIGluIFJGQyAxMTIyIG9uIHBhZ2UgODYNCiBpdCBhbHNvIHN0YXRlczoNCiAuSU4g KzAuNWkNCiAubmYNCkBAIC01MjcsMTEgKzUzNywxMSBAQA0KIC5zcA0KIC5uZg0KIERhdmlkIEJv cm1hbg0KLVdpbmQgUml2ZXIgU3lzdGVtcw0KK1F1YW50dW0gQ29ycG9yYXRpb24NCiBNZW5kb3Rh IEhlaWdodHMsIE1OIDU1MTIwDQogLnNwDQotUGhvbmU6ICg2NTEpIDQ1NC0zMDUyDQotRW1haWw6 IGRhdmlkLmJvcm1hbkB3aW5kcml2ZXIuY29tDQorRW1haWw6IGRhdmlkLmJvcm1hbkBxdWFudHVt LmNvbQ0KIC5maQ0KIC5zcCAyDQogLkxUICJGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQiIDAuM2kN Cg== --_004_3DCF0EBF200646E79D05BD97849A4CDAquantumcom_-- From ycheng@google.com Wed Mar 28 19:17:51 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4466D21E8036 for ; Wed, 28 Mar 2012 19:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIPjBBG9RODd for ; Wed, 28 Mar 2012 19:17:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 237D621E800F for ; Wed, 28 Mar 2012 19:17:49 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2492599obb.31 for ; Wed, 28 Mar 2012 19:17:49 -0700 (PDT) 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:x-system-of-record; bh=rBKO7gU7KkiM6/2UfMVQenHcE3R81+je+5XKnUB2WDA=; b=VbabAkNO9ceW4HiS8W2z6r6JVvO7wVQDgzgyxGzn6EU6f6z0V5O+cLx59nx1DPKe99 mJgFxjGjm8vV8uDPiRSNpBfiSMJ9hTh0XhtmdNxRqR9oTMHfNL7ui2EIF1ktwyyoPwCl KOrlwUZ0NtxTq/Xo3epBChNimLQEvGdj+5Jz17fsIrWcrciRmWDasCjCStpv68im/BLC 5FO/bVsirfEM4k/Sr48ssd1URSjBg7uG5uWRDUTZp50vkV5E/zsMhVbOaYadyvGAwLLW kzKzia93Gq+6jIWZkjXkxMWVXGj6rbC8bpBl8CbcC5LAbEdqedxv9moNedIk5Ipw5Mp4 WJ1A== X-Google-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:x-system-of-record:x-gm-message-state; bh=rBKO7gU7KkiM6/2UfMVQenHcE3R81+je+5XKnUB2WDA=; b=Qso2QDXcCg3AayWIyjcKFuY6Z0Tc9HFFWKrtzriZyZhRO82TYTcbE8pu/C0Bgj3OHc b2GTXg64FIuDzSjIcqOtUpxNZPFmb/zz2IVv9HuTUDEsl8M67gDymic7bbk98nekZxh8 nmYO53jhrMHlL8zuq5SezUpCV/+6SZqtIo2rimjyMslJa1lTaFjoccr8CvJ1d3xspPQK t1utAlNyc/ampPTXUfUnnQW+Y2vX0sWZLhFBW66CtXgiYm9Odzye6vkz1WvAKkzusu2l Tmjn2Qr6rFfpCYUAdV/aPuzsgbxiVX7yy09PuxqeSzxsccnkZ1fl1sQNTIQDnDHUcugJ tChQ== Received: by 10.60.24.170 with SMTP id v10mr42426484oef.60.1332987469454; Wed, 28 Mar 2012 19:17:49 -0700 (PDT) Received: by 10.60.24.170 with SMTP id v10mr42426474oef.60.1332987469363; Wed, 28 Mar 2012 19:17:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.74.233 with HTTP; Wed, 28 Mar 2012 19:17:29 -0700 (PDT) In-Reply-To: References: <012C3117EDDB3C4781FD802A8C27DD4F0CC581@SACEXCMBX02-PRD.hq.netapp.com> <4F606F24.2090103@ifi.uio.no> From: Yuchung Cheng Date: Wed, 28 Mar 2012 19:17:29 -0700 Message-ID: To: Matt Mathis Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlEsUvoXP7ZnLEtuVbgFMTJyPyrIJ5YkFd85IbepJ/wWzpEs7BEUK8YIaMtrVbw+soVTvoHrLKtW2s4Tq75tkqJfa6H5p1y+ZFMkH8rqMFn8wQK/jW5t908f782gycioQEP+ccW Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] laminar tcp, separate thread X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 02:17:51 -0000 As a TCP developer, I would like to give a big +1 because Linux suffers the exact problem Laminar is trying to address. Some questions: 1) are cwnd and ssthresh obsolete in Laminar? but IW is mentioned in the draft. 2) Linux performs burst suppression by pulling cwnd to pipe+max_burst AFAIU, Laminar replaces that with (implicit) slow-start. But the pseudo code appears to moderate burst in transmission scheduling // cue the (re)transmission machinery sndBank += sndcnt limit = maxBank() if sndBank > limit: sndBank = limit What does maxBank() do? 3) does in_recovery() and new_recovery() include timeout recovery? it seems so to me (but it suggests a loss window = 2 which I would love to change to). Thanks! From mattmathis@google.com Thu Mar 29 01:03:21 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A9621F886E for ; Thu, 29 Mar 2012 01:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpQRA9FYaZ9w for ; Thu, 29 Mar 2012 01:03:20 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A28BC21F8810 for ; Thu, 29 Mar 2012 01:03:19 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1852844bku.31 for ; Thu, 29 Mar 2012 01:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=djRCqd47qfCkevYsMznVcmDPpImEg7SRtF68DhW5fqU=; b=b3SyXGDIUgkkXqIdvuhIq9bgG3/iadc894lHbcHA6ExROgEEoU7jJIV2ZkJct0vvSD 8PV/9qmtvTG0Tam8vJTfTxZbDHDXzab6E7IopZpGJBF67XbaAXW9YSDGZJzcYW86DNy0 A4J74DUEYSBc42TlkahPZGMKvyVuDEFcUSfOTRuu38gKzDvjDhDt6gm+T6zBuG+IgL/R dGFWpOfMwDof1xO4juzVvrDuZfybzyEB3HX7nlIlG1uZ2FVQxQ8euDKQnO6/HRp4vjMd 3fqg7G2fQlwJu7/dPt8XaNF/tIQla6+/4isq7EAMQFVlE21fjIgdFqLNTtBGgMuFv7FX ED0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=djRCqd47qfCkevYsMznVcmDPpImEg7SRtF68DhW5fqU=; b=G8rOb8j1nbK58ehZoBq85X0YavQSUX9rHKuyE+lcLc+Rdj7ZOI6xm5pEQVas0Ai9MG Atg8sADrqw4l+unZRaT6J0+CJ94sNJ0YVF9LA4YCJ/QMwwemQF1WF/n5fPe819XdOhjC zazZu+ADc4yc+pJOdqalKowIIVjDao3YsPWkCISJ4jb9bv8L0qj/a/bNr3ZZTOyEFG0S tnPJzcjXuQB6yZj0EYZX0Cg/3V4AH83cIj6f82l0IsfB8xbJ1fRilt8ct0k/i6KbMn9O fpnkXBda3fKJq9UlL5octfOEOKm3fz1q1zDFqccuyv8LuLLMQCs/BZeObE66UEZ+dzPM 97/w== Received: by 10.205.81.3 with SMTP id zw3mr9604977bkb.30.1333008198746; Thu, 29 Mar 2012 01:03:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.81.3 with SMTP id zw3mr9604967bkb.30.1333008198546; Thu, 29 Mar 2012 01:03:18 -0700 (PDT) Received: by 10.204.184.195 with HTTP; Thu, 29 Mar 2012 01:03:18 -0700 (PDT) In-Reply-To: References: <012C3117EDDB3C4781FD802A8C27DD4F0CC581@SACEXCMBX02-PRD.hq.netapp.com> <4F606F24.2090103@ifi.uio.no> Date: Thu, 29 Mar 2012 01:03:18 -0700 Message-ID: From: Matt Mathis To: Yuchung Cheng Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnIYRy/hYmw1a8TPoC6+BKkB5CxKALiQCLRa7ns41FN+sVg/Jdalbc5Kl3Z1+JJIysD432uunEbB0HqF99j4okP6uSaxrXwE79p8H/fPS0MjlrCNqgOUOXTtoE+AzBwhguOroGi Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] laminar tcp, separate thread X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 08:03:21 -0000 On Wed, Mar 28, 2012 at 7:17 PM, Yuchung Cheng wrote: > As a TCP developer, I would like to give a big +1 because Linux > suffers the exact > =A0problem Laminar is trying to address. Thanks! The standards themselves are problematic. I would expect the problems to be present in all TCP implementations. > Some questions: > 1) are cwnd and ssthresh obsolete in Laminar? but IW is mentioned in the = draft. You are correct. IW is misnamed, it should be Initial Burst or something like that. > 2) Linux performs burst suppression by pulling cwnd to pipe+max_burst > =A0 AFAIU, Laminar replaces that with (implicit) slow-start. But the > =A0 pseudo code appears to moderate burst in transmission scheduling > =A0 =A0 // cue the (re)transmission machinery > =A0 =A0 sndBank +=3D sndcnt > =A0 =A0 limit =3D maxBank() > =A0 =A0 if sndBank > limit: > =A0 =A0 =A0 =A0sndBank =3D limit > > =A0 What does maxBank() do? sndBank is needed to support TSO, and normally it would never be larger than the TSO chunk size. However the receiver window check and NIC back pressure (e.g. Ethernet pause frames) both happen deep inside of the TCP output code, and could cause sndBank to become arbitrarily large. After such an output stall, maxBank() controls how much TCP can catch up by by using Laminar's transmission scheduling algorithm vs sending a line rate burst. If sndBank gets pulled down it deflates total_pipe and the transmission scheduler will have to make up the difference on future ACKs. If there is no TSO, sndBank is not needed and output stalls could just cause total_pipe to deflate. BTW There is a simple thought experiment to determine if total_pipe is implemented correctly: if you imagine disabling the the CCwin based sndcnt adjustments (e.g. constant window as long as the network remains lossless), total_pipe will not be affected by either irregular delayed ACKs (DeliveredData not uniform) or irregular TSOs (SndBank not uniform) or any combination. > 3) does in_recovery() and new_recovery() include timeout recovery? it > seems so to > =A0 me (but it suggests a loss window =3D 2 which I would love to change = to) Yea, I was being wishful. That should probably be a separate change. My presentation in TCPM will be Friday AM. Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay From gorry@erg.abdn.ac.uk Thu Mar 29 04:49:40 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0C521F88F5 for ; Thu, 29 Mar 2012 04:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lzr+JohU02jW for ; Thu, 29 Mar 2012 04:49:40 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id AC6D121F88AF for ; Thu, 29 Mar 2012 04:49:38 -0700 (PDT) Received: from ra-gorry.erg.abdn.ac.uk ([IPv6:2001:df8:0:16:5ab0:35ff:fe7b:b828]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q2TBnX4o020337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 29 Mar 2012 12:49:33 +0100 (BST) Message-ID: <4F744C4D.6000704@erg.abdn.ac.uk> Date: Thu, 29 Mar 2012 13:49:33 +0200 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: [tcpm] Feedback on usage and deployment recommendations in draft-ietf-tcpm-initcwnd-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:49:40 -0000 I've looked through the changes in the last revision again and I do look forward to finding out more at the TCPM WG meeting. In general: I think the experiment with IW=10 is OK with me, but I am not sure that this draft has yet addressed the other things that were brought up over the time, in the mailing list. My comments are below, mainly on understanding the impact on non-TCP applications, which seem to be the most likely to suffer collateral damage from sharing a network bottleneck with the updated mechanism. Gorry ##### The ID says: However, since the increase is one-time only (at the beginning of a connection), and the rest of TCP's congestion backoff mechanism remains in place, it's highly unlikely the increase will render a network in a persistent state of congestion, or even congestion collapse. - I think the impression here is not entirely true. It would be nice to note there is no limit to the number of new TCP sessions that can start over a network link, and explain this ... since this a partly a motivation for back-off in TCP. ##### Although no severe unfairness has been detected on all the known tests so far, further study on this topic may be warranted. - Pity we have not seen more studies with non-TCP flows. - This section only partly capture my concerns. ##### Section 8: The negative impact can be mitigated by hosts directly connected to a low-speed link advertising a smaller initial receive window than 10 segments. - True although I think this remedy is not so easily deployed. And This can be achieved either through manual configuration by the users, or through the host stack auto-detecting the low bandwidth links. - I do not agree with this statement at all. I strongly oppose the idea of requiring users to manually configure key transport parameters based on their understanding of the path. This seems a very undesirable way of solving this problem. [I'm intrigued at how an end point can determine there is a slow link on the path by "auto-detecting the low bandwidth links" - are there robust algorithms that can do this? I've seen a lot of proposals over the years from things, even local interface speed (seriously flawed approach for finding the min path bandwidth).] - I would REALLY like to see some simple method specified that is a part of this experiment. I do not believe there is one value that works for all paths. I could make a strawman suggestion: If the sender looses a segment after the SYN to a specific IP host and within the first IW segments using IW>3, then the IP host SHOULD use a window of not more than 3 segments for all new TCP connections to the same IP address (on the same interface) for the next 1 hour. (It could be argued this should also happen on loss during rw for flow restart.) I think should also update restart window for the conenction, as described in the ID. I know there are issues with this: It does not catch all flows from a host (which would useful if the host were doing P2P), it may not always prevent collateral disruption - but it really would help. Any thoughts from others? If the experiment shows that the feature is rarely triggered, or doesn't benefit, then we'd be wiser - by guess is that it helps a lot in specific scenarios were IW=10 will be painful. ##### Furthermore, non-TCP traffic (such as VoIP) should be monitored as well. If users observe any significant deterioration of performance, they SHOULD fall back to an initial window as allowed by RFC 3390 for safety reasons. An increased initial window SHOULD NOT be turned on by default on systems without such monitoring capabilities. - While I agree with the sentiment, how does this ID actually address these concerns? (see previous). ##### NiT: I think the abstract reads like it is direct replacement for IW=3, which doesn't seem quite appropriate for an experimental update. ##### I understand IW=1, IW=3 and would like to see IW=10 more widely available. I don't yet understand a benefit from finely tuning IW, so I'm not sure we need to tune IW. As I see it, the key benefit is to apps that need to send ~6 to ~30K, I'm not sure I would break other Internet traffic to support this. I think my comments above cab be addressed by the group - so I am keen to see other thoughts/experience. Gorry From pasi.sarolahti@iki.fi Thu Mar 29 04:53:59 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0033321F88B2 for ; Thu, 29 Mar 2012 04:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fACQRDO1Ut7 for ; Thu, 29 Mar 2012 04:53:58 -0700 (PDT) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by ietfa.amsl.com (Postfix) with ESMTP id C79D921F8870 for ; Thu, 29 Mar 2012 04:53:57 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id q2TBrqub000543 for ; Thu, 29 Mar 2012 14:53:52 +0300 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 22301-844 for ; Thu, 29 Mar 2012 14:53:52 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id q2TBricM000538 for ; Thu, 29 Mar 2012 14:53:45 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id C1BCA1E143 for ; Thu, 29 Mar 2012 14:53:44 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZQRaHnnwDeLB for ; Thu, 29 Mar 2012 14:53:41 +0300 (EEST) Received: from dhcp-47f0.meeting.ietf.org (dhcp-47f0.meeting.ietf.org [130.129.71.240]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 22C2A1E136 for ; Thu, 29 Mar 2012 14:53:41 +0300 (EEST) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 13:53:38 +0200 Message-Id: <24961FC0-7453-45B7-9032-8423AA1EFEAC@iki.fi> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [tcpm] Note takers wanted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 11:53:59 -0000 Hi, We need note takers and jabber scribe for tomorrow morning's TCPM = meeting, and it would be great to find these in advance to save meeting = time. If you think you could help us out, please drop us chairs a note. Thanks! - Pasi From internet-drafts@ietf.org Thu Mar 29 07:18:48 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37D921E817A; Thu, 29 Mar 2012 07:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lsLTm2M0X8e; Thu, 29 Mar 2012 07:18:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CC421E8167; Thu, 29 Mar 2012 07:18:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120329141848.26808.80585.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2012 07:18:48 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcpmss-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 14:18:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : TCP Options and MSS Author(s) : David Borman Filename : draft-ietf-tcpm-tcpmss-04.txt Pages : 9 Date : 2012-03-29 This memo discusses what value to use with the TCP MSS option, and updates RFC 879 and RFC 2385. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpmss-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcpmss-04.txt From dab@weston.borman.com Thu Mar 29 07:34:33 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4609D21E81C1 for ; Thu, 29 Mar 2012 07:34:33 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO-WUD4-uu2P for ; Thu, 29 Mar 2012 07:34:32 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5129A21E81B1 for ; Thu, 29 Mar 2012 07:34:31 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id q2TEYSkD000491 for ; Thu, 29 Mar 2012 08:34:29 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: David Borman In-Reply-To: Date: Thu, 29 Mar 2012 09:34:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6D65DC32-5323-4CA6-9756-4A28DC415F22@weston.borman.com> References: To: TCP Maintenance and Minor Extensions WG X-Mailer: Apple Mail (2.1257) Subject: Re: [tcpm] Update for TCP MSS draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 14:34:33 -0000 Sorry for the delay, the draft is now posted. I was having trouble with = the submission tool, I wasn't getting the verification emails and = finally had to upload it using a different email address so I could get = the verification email and complete the process. -David Borman On Mar 27, 2012, at 10:34 AM, David Borman wrote: > I've just submitted an update to the TCP MSS draft, to address some = comments made after the WG Last Call, and some things pointed out by the = I-D Nits tool. >=20 > I'm attaching a diff of the full list of changes. Many of them are = just changing format from "RFC-XXX" to "RFC XXX". Aside from that, fix = a typo of 897 that should be 879, add comments to the Abstract that it = updates RFC 879 and RFC 2385, and add some clarification to the text = after the table. >=20 > -David Borman From brandon.williams@akamai.com Thu Mar 29 08:11:31 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FAD21F8809 for ; Thu, 29 Mar 2012 08:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp7KCDqyoCBy for ; Thu, 29 Mar 2012 08:11:27 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id DF8A521F87F4 for ; Thu, 29 Mar 2012 08:11:21 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7DEBA27C26 for ; Thu, 29 Mar 2012 15:11:21 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 6AE6A27C24 for ; Thu, 29 Mar 2012 15:11:21 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 4FDD0FE06B for ; Thu, 29 Mar 2012 15:11:21 +0000 (GMT) Message-ID: <4F747B99.9030701@akamai.com> Date: Thu, 29 Mar 2012 11:11:21 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] draft-williams-overlaypath-ip-tcp-rfc-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 15:12:45 -0000 An Internet-Draft is available from the on-line Internet-Drafts directories. Title : Overlay Path Option for IP and TCP Author : Brandon Williams Filename : draft-williams-overlaypath-ip-tcp-rfc-00.txt Pages : 15 Date : 2012-01-17 This document proposes IPv4, IPv6, and TCP options for communicating the true IP address of a TCP connection endpoint to its peer when that address is hidden due to the use of NAT on an overlay network. A URL for this Internet-Draft is: http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From touch@isi.edu Thu Mar 29 08:38:07 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8655A21F88FF for ; Thu, 29 Mar 2012 08:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.584 X-Spam-Level: X-Spam-Status: No, score=-104.584 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GergHVlf3ZlS for ; Thu, 29 Mar 2012 08:38:06 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A687621F88CD for ; Thu, 29 Mar 2012 08:38:04 -0700 (PDT) Received: from [100.44.124.173] ([216.53.135.2]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q2TFaxLw017573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Mar 2012 08:37:08 -0700 (PDT) References: <4F744C4D.6000704@erg.abdn.ac.uk> In-Reply-To: <4F744C4D.6000704@erg.abdn.ac.uk> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <7E92F335-78FA-4238-81DC-ACA9542FFADC@isi.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9B176) From: Joe Touch Date: Thu, 29 Mar 2012 11:36:59 -0400 To: "gorry@erg.abdn.ac.uk" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback on usage and deployment recommendations in draft-ietf-tcpm-initcwnd-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 15:38:07 -0000 On Mar 29, 2012, at 7:49 AM, Gorry Fairhurst wrote: >=20 > I've looked through the changes in the last revision again and I do look f= orward to finding out more at the TCPM WG meeting. >=20 > In general: I think the experiment with IW=3D10 is OK with me, but I am no= t sure that this draft has yet addressed the other things that were brought u= p over the time, in the mailing list. >=20 > My comments are below, mainly on understanding the impact on non-TCP appli= cations, which seem to be the most likely to suffer collateral damage from s= haring a network bottleneck with the updated mechanism. >=20 > Gorry ... > ##### > Section 8: > The negative impact can be mitigated by hosts directly connected to a > low-speed link advertising a smaller initial receive window than 10 > segments. >=20 > - True although I think this remedy is not so easily deployed. >=20 > And > This can be achieved either through manual configuration by > the users, or through the host stack auto-detecting the low bandwidth > links. >=20 > - I do not agree with this statement at all. I strongly oppose the idea of= requiring users to manually configure key transport parameters based on the= ir understanding of the path. This seems a very undesirable way of solving t= his problem. >=20 > [I'm intrigued at how an end point can determine there is a slow link on t= he path by "auto-detecting the low bandwidth links" - are there robust algor= ithms that can do this? I've seen a lot of proposals over the years from thi= ngs, even local interface speed (seriously flawed approach for finding the m= in path bandwidth).] >=20 > - I would REALLY like to see some simple method specified that is a part o= f this experiment. I do not believe there is one value that works for all pa= ths. I could make a strawman suggestion: >=20 > If the sender looses a segment after the SYN to a specific > IP host and within the first IW segments using IW>3, > then the IP host SHOULD use a window of not more than 3 > segments for all new TCP connections to the same IP address > (on the same interface) for the next 1 hour. >=20 > (It could be argued this should also happen on loss during rw for flow res= tart.) >=20 > I think should also update restart window for the conenction, as described= in the ID. >=20 > I know there are issues with this: It does not catch all flows from a host= (which would useful if the host were doing P2P), it may not always prevent c= ollateral disruption - but it really would help. Any thoughts from others? I= f the experiment shows that the feature is rarely triggered, or doesn't bene= fit, then we'd be wiser - by guess is that it helps a lot in specific scenar= ios were IW=3D10 will be painful. >=20 > ##### This is basically what I proposed as an alternative, but I include a way to u= se the lack of lows to increase the IW over time too. IMO this is the better way to proceed, rather than to use static, no reactiv= e approaches or just ones that back off. > ##### > NiT: I think the abstract reads like it is direct replacement for IW=3D3, w= hich doesn't seem quite appropriate for an experimental update. >=20 > ##### > I understand IW=3D1, IW=3D3 and would like to see IW=3D10 more widely avai= lable. I don't yet understand a benefit from finely tuning IW, so I'm not su= re we need to tune IW. As I see it, the key benefit is to apps that need to= send ~6 to ~30K, I'm not sure I would break other Internet traffic to suppo= rt this. I think my comments above cab be addressed by the group - so I am k= een to see other thoughts/experience. fwiw I agree - tuning IW isnt needed, but a coarsely reactive IW over long t= imescales remains safer. Joe From touch@isi.edu Thu Mar 29 12:48:45 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C983621F882F for ; Thu, 29 Mar 2012 12:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.333 X-Spam-Level: X-Spam-Status: No, score=-105.333 tagged_above=-999 required=5 tests=[AWL=1.266, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRPaPzOJJKev for ; Thu, 29 Mar 2012 12:48:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2A721F882E for ; Thu, 29 Mar 2012 12:48:45 -0700 (PDT) Received: from [192.168.6.166] ([216.53.135.2]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q2TJllKL029953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Mar 2012 12:47:57 -0700 (PDT) Message-ID: <4F74BC64.3070506@isi.edu> Date: Thu, 29 Mar 2012 12:47:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Kengo Naito References: <20120305125040.13625.47540.idtracker@ietfa.amsl.com> <4F556156.6030803@lab.ntt.co.jp> <4F5F181F.2010201@lab.ntt.co.jp> In-Reply-To: <4F5F181F.2010201@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-naito-nat-resource-optimizing-extension-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 19:48:45 -0000 On 3/13/2012 2:49 AM, Kengo Naito wrote: > Hello Mr.Nishida, > > Thank you for your advice. > Sorry some part of my draft is not ready. > I'll write the answer below, > > (2012/03/12 13:20), Yoshifumi Nishida wrote: >> Hello Mr. Naito, >> >> I believe the draft aims to solve the following issue. >> If server performs active close, it will enter into TIME_WAIT and keep >> connection info for 2MSL. if client or NAT picks the same port for a >> new connection to the server during this 2MSL period, the connection >> attempt will be rejected. On busy NAT boxes, this will prone to >> happen. > Well, this may be a problem, but in my draft I focus on NAT equipment, > which resource is restricted. > Problem I state is TIME_WAIT entered into at NAT equipment, > and it disables new connection. As it should. Please don't forget that as far as the rest of the network is concerned, the NAT *is* the endpoint of that TCP connection, and all of the rules of IP, ICMP, TCP, and host requirements and their updates apply. Joe From touch@isi.edu Thu Mar 29 12:52:39 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443FC21E801F for ; Thu, 29 Mar 2012 12:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.431 X-Spam-Level: X-Spam-Status: No, score=-105.431 tagged_above=-999 required=5 tests=[AWL=1.168, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iffvvF2VIym for ; Thu, 29 Mar 2012 12:52:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6884421E801A for ; Thu, 29 Mar 2012 12:52:38 -0700 (PDT) Received: from [192.168.6.166] ([216.53.135.2]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q2TJq2xX000767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Mar 2012 12:52:12 -0700 (PDT) Message-ID: <4F74BD64.20903@isi.edu> Date: Thu, 29 Mar 2012 12:52:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brandon Williams References: <4F747B99.9030701@akamai.com> In-Reply-To: <4F747B99.9030701@akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 19:52:39 -0000 This doc needs to be updated immediately, and references to numbers not assigned by IANA replaced with TBDs. Notably IP option 218, TCP option 30, etc. are NOT assigned by IANA. There is no such thing as "provisional pending IANA approval"; this document establishes squatting, period. This document should be revised before being further discussed. Joe On 3/29/2012 8:11 AM, Brandon Williams wrote: > An Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Overlay Path Option for IP and TCP > Author : Brandon Williams > Filename : draft-williams-overlaypath-ip-tcp-rfc-00.txt > Pages : 15 > Date : 2012-01-17 > > This document proposes IPv4, IPv6, and TCP options for > communicating the true IP address of a TCP connection endpoint > to its peer when that address is hidden due to the use of NAT on > an overlay network. > > A URL for this Internet-Draft is: > http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt > From brandon.williams@akamai.com Thu Mar 29 14:24:13 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA7221E8036 for ; Thu, 29 Mar 2012 14:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sHEoYDUo+HG for ; Thu, 29 Mar 2012 14:24:13 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 075CD21E801F for ; Thu, 29 Mar 2012 14:24:12 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 24574CF17A; Thu, 29 Mar 2012 21:24:12 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id 0FF45CF126; Thu, 29 Mar 2012 21:24:12 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 00BBE47BD2; Thu, 29 Mar 2012 21:24:11 +0000 (GMT) Message-ID: <4F74D2FB.7060109@akamai.com> Date: Thu, 29 Mar 2012 17:24:11 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Joe Touch References: <4F747B99.9030701@akamai.com> <4F74BD64.20903@isi.edu> In-Reply-To: <4F74BD64.20903@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 21:24:13 -0000 Thank you for taking the time to look the document over and for noting this shortcoming. You are absolutely right that the document should not have been published with any reference to unassigned numbers. I should have realized that this would be unacceptable. I will make that change and publish a version 01 ASAP in order to facilitate further discussion. --Brandon On 03/29/2012 03:52 PM, Joe Touch wrote: > This doc needs to be updated immediately, and references to numbers not > assigned by IANA replaced with TBDs. Notably IP option 218, TCP option > 30, etc. are NOT assigned by IANA. > > There is no such thing as "provisional pending IANA approval"; this > document establishes squatting, period. > > This document should be revised before being further discussed. > > Joe > > > On 3/29/2012 8:11 AM, Brandon Williams wrote: >> An Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Overlay Path Option for IP and TCP >> Author : Brandon Williams >> Filename : draft-williams-overlaypath-ip-tcp-rfc-00.txt >> Pages : 15 >> Date : 2012-01-17 >> >> This document proposes IPv4, IPv6, and TCP options for >> communicating the true IP address of a TCP connection endpoint >> to its peer when that address is hidden due to the use of NAT on >> an overlay network. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt >> -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From brandon.williams@akamai.com Thu Mar 29 15:19:57 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB8421F86AA for ; Thu, 29 Mar 2012 15:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMgIG2cTpy1X for ; Thu, 29 Mar 2012 15:19:56 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 63F5121F86A7 for ; Thu, 29 Mar 2012 15:19:56 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AC4E427C85; Thu, 29 Mar 2012 22:19:55 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 9953727C7A; Thu, 29 Mar 2012 22:19:55 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 7E9AD47BD2; Thu, 29 Mar 2012 22:19:55 +0000 (GMT) Message-ID: <4F74E00B.5060006@akamai.com> Date: Thu, 29 Mar 2012 18:19:55 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Brandon Williams References: <4F747B99.9030701@akamai.com> <4F74BD64.20903@isi.edu> <4F74D2FB.7060109@akamai.com> In-Reply-To: <4F74D2FB.7060109@akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 22:19:57 -0000 I have submitted a revised version of the draft which no longer inappropriately refers to specific option numbers that have not been assigned by IANA. Please let me know if the revision does not meet your expectations for clarity in this regard. Thank you, --Brandon A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-01.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Filename: draft-williams-overlaypath-ip-tcp-rfc Revision: 01 Title: Overlay Path Option for IP and TCP Creation date: 2012-03-29 WG ID: Individual Submission Number of pages: 15 Abstract: Data transport through overlay networks often uses either connection termination or network address translation (NAT) in such a way that the public IP addresses of the true endpoint machines involved in the data transport are invisible to each other. This document describes IPv4, IPv6, and TCP options for communicating this information from the overlay network to the endpoint machines. On 03/29/2012 05:24 PM, Brandon Williams wrote: > Thank you for taking the time to look the document over and for noting > this shortcoming. You are absolutely right that the document should not > have been published with any reference to unassigned numbers. I should > have realized that this would be unacceptable. > > I will make that change and publish a version 01 ASAP in order to > facilitate further discussion. > > --Brandon > > On 03/29/2012 03:52 PM, Joe Touch wrote: >> This doc needs to be updated immediately, and references to numbers not >> assigned by IANA replaced with TBDs. Notably IP option 218, TCP option >> 30, etc. are NOT assigned by IANA. >> >> There is no such thing as "provisional pending IANA approval"; this >> document establishes squatting, period. >> >> This document should be revised before being further discussed. >> >> Joe >> >> >> On 3/29/2012 8:11 AM, Brandon Williams wrote: >>> An Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Overlay Path Option for IP and TCP >>> Author : Brandon Williams >>> Filename : draft-williams-overlaypath-ip-tcp-rfc-00.txt >>> Pages : 15 >>> Date : 2012-01-17 >>> >>> This document proposes IPv4, IPv6, and TCP options for >>> communicating the true IP address of a TCP connection endpoint >>> to its peer when that address is hidden due to the use of NAT on >>> an overlay network. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt >>> > -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From gorry@erg.abdn.ac.uk Fri Mar 30 00:18:00 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5BE21E8056 for ; Fri, 30 Mar 2012 00:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Agfinzi0Nfqg for ; Fri, 30 Mar 2012 00:18:00 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id F3C9621E8015 for ; Fri, 30 Mar 2012 00:17:58 -0700 (PDT) Received: from ra-gorry.erg.abdn.ac.uk ([IPv6:2001:df8:0:16:5ab0:35ff:fe7b:b828]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q2U7HmVc005546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 30 Mar 2012 08:17:48 +0100 (BST) Message-ID: <4F755E1C.1050200@erg.abdn.ac.uk> Date: Fri, 30 Mar 2012 09:17:48 +0200 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: [tcpm] Minor NiTs in proposed charter change discussed in tcpm this morning. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:18:00 -0000 A few more suggested tweaks to the proposed charter text: English: /The focus ...are/ should be / the focus ... is/ Add: /other/ to /significant changes/ /The IETF has recently/ remove /recently/ ... SCTP has been done for a while... Goery From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Mar 30 01:53:12 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23A721F8871 for ; Fri, 30 Mar 2012 01:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.424, BAYES_05=-1.11, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHA6CskBoqV3 for ; Fri, 30 Mar 2012 01:53:10 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0A22B21F884C for ; Fri, 30 Mar 2012 01:53:10 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 7A428633B1; Fri, 30 Mar 2012 10:53:08 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5CF7459A8A; Fri, 30 Mar 2012 10:53:08 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: Matt Mathis Date: Fri, 30 Mar 2012 10:53:07 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201203230042.q2N0gV8h029884@bagheera.jungle.bt.co.uk> <201203261713.57206.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201203301053.08029.mkuehle@ikr.uni-stuttgart.de> Cc: tcpm@ietf.org Subject: [tcpm] TCP Laminar -> 60 RFCs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 08:53:12 -0000 Hi Matt, can you add the list of the 60 affected RFCs to the draft ans/or post it on the mailing list? Thanks, Mirja From bob.briscoe@bt.com Fri Mar 30 01:57:57 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2AF21F8787 for ; Fri, 30 Mar 2012 01:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F1YnUWIY1S5 for ; Fri, 30 Mar 2012 01:57:56 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5571121F8552 for ; Fri, 30 Mar 2012 01:57:35 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 30 Mar 2012 09:57:31 +0100 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 30 Mar 2012 09:57:32 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Fri, 30 Mar 2012 09:57:25 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1333097857151; Fri, 30 Mar 2012 09:57:37 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.163.73]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2U8vNil007606; Fri, 30 Mar 2012 09:57:23 +0100 Message-ID: <201203300857.q2U8vNil007606@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 Mar 2012 09:57:21 +0100 To: Jerry Chu From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tcpm IETF list Subject: [tcpm] IW10 & queuebloat X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 08:57:57 -0000 Jerry, In the tcpm meeting just now, you blamed large buffers for the bufferbloat problem. Not so... With a good AQM (loss or ECN), a large* buffer beyond the AQM threshold is good, not evil. The problem is actually queuebloat, not bufferbloat. (The buffer is the memory set aside for the queue. The queue is how much of the memory is used to store packets or frames.) The blame for large AQM thresholds lies primarily with TCP's cc algo. DCTCP shows the way forward, and highlights that NewReno TCP sawteeth are to blame for large average queues, and constraining how low an AQM threshold can go without harming utilisation. I predicted nearly a year ago, that the term "bufferbloat" would confuse people by seeming to point the finger of blame at the wrong thing: When it starts to mislead experts in the field, I get worried. _____ * Large, but not bloated - see the above URL. ==Relevance to IW10== I would like to see experiments with IW10 in a simulation modelling how the Internet is likely to be in future (with more DCTCP-like protocols and shallower AQM) rather than just how the Internet is now. I'm not saying whether IW10 is good or bad for "queuebloat", because I haven't done such experiments. Intuitively it may be OK, but I don't trust my intuition in this case. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From hkchu@google.com Fri Mar 30 03:50:03 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3116721F86BD for ; Fri, 30 Mar 2012 03:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.31 X-Spam-Level: X-Spam-Status: No, score=-101.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgNhJzcFxk3P for ; Fri, 30 Mar 2012 03:50:02 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7553F21F86FD for ; Fri, 30 Mar 2012 03:50:01 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so300476wgb.13 for ; Fri, 30 Mar 2012 03:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=0iYCgztOKW4JqgUiLsrYhV0MIaQEjUyEDZklmIDpixc=; b=mgW/e3uL4IcUajA4fasi1TPgr7xIl1p8IbUJ0Ox2SshqOHAoOsRTxRwueq8ifJ6W2C 6zHaw94JtqTaQV0EkNru9bS7bL5j5rjaUXfn8AmiQCHibA37Zhr83QTPotQrP21Yx/dn TvcOOrekZmQvR4o/aqQQVbynHgscH6+QtP/PWEZPr0kDshXjNDjiyKmv0lAIBsz952qQ 9IgNq7wbbN20zv1SFirn58C4V4hThXLTNX3ojGab2bqxjg5mTX0P4mvDYI12SDp1ur88 ST7DhR+FeA6s/u8BxmemJvQDGB84pzbs0PcPPoNH00aqPEc2Mk/dR1kAWmvDt0u/LygI svzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:x-gm-message-state:content-type; bh=0iYCgztOKW4JqgUiLsrYhV0MIaQEjUyEDZklmIDpixc=; b=YXbTCZDbruiuN+Qdhr7+9mjLrIHSUz+BPSZFcVQoABDp+9q7vHDUQAMtuge6cPFW1/ Eqeyu5ir0nPsbWmBkRwkGalgrgvOMQlWdgGFx6jKCydSzvp1yCExA0mdetsELCwbxEcf rRhUkbr+i9TF2SpjlaByiO57fJr9bzdhSQFxw9nncVYKbQPruawh0MDF3Ql50oX/7oOg Wn44h2MEwZTvwQfzSHpv06jw7zgDR84OFlpe2xf6zwXukVAKvNpv17O/D2mSljnrJ4vL XSVFdU5eTHATHeY5/3WWq/OHtVCMrRnti5M3/pMBRyxTsDw8Nc1f0G/ZFARjw6GPQQrX lINA== Received: by 10.180.86.132 with SMTP id p4mr5214702wiz.15.1333104600660; Fri, 30 Mar 2012 03:50:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.86.132 with SMTP id p4mr5214678wiz.15.1333104600489; Fri, 30 Mar 2012 03:50:00 -0700 (PDT) Received: by 10.227.143.6 with HTTP; Fri, 30 Mar 2012 03:50:00 -0700 (PDT) In-Reply-To: <201203300857.q2U8vNil007606@bagheera.jungle.bt.co.uk> References: <201203300857.q2U8vNil007606@bagheera.jungle.bt.co.uk> Date: Fri, 30 Mar 2012 03:50:00 -0700 Message-ID: From: Jerry Chu To: Bob Briscoe X-System-Of-Record: true X-Gm-Message-State: ALoCoQkpFgUn77uwcw1k3OtMsQL//w2MdvNCfkVs3zH445qVPK1fWmhI8U/SsroEhG9wu8n/OdrZ36shI1ekuGdCpx3bElBcMruXE9YqpjxYLr8gmuHbCX3kIRJEaKfpomov2rjtzuAV Content-Type: multipart/alternative; boundary=f46d044286d229214004bc739a7b Cc: tcpm IETF list Subject: Re: [tcpm] IW10 & queuebloat X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 10:50:03 -0000 --f46d044286d229214004bc739a7b Content-Type: text/plain; charset=ISO-8859-1 Bob, On Fri, Mar 30, 2012 at 1:57 AM, Bob Briscoe wrote: > Jerry, > > In the tcpm meeting just now, you blamed large buffers for the bufferbloat > problem. Not so... > Stanford researchers have shown that backbone routers do not need large buffers to maintain high utilization. Yes it's the bloated average queue size that is the culprit and one can have large buffers but small average queue size if an adequate AQM is deployment. But most home/edge routers with large buffers do not have adequate AQM, hence my statement. > With a good AQM (loss or ECN), a large* buffer beyond the AQM threshold is > good, not evil. > > The problem is actually queuebloat, not bufferbloat. (The buffer is the > memory set aside for the queue. The queue is how much of the memory is used > to store packets or frames.) > > The blame for large AQM thresholds lies primarily with TCP's cc algo. Specifically with the "loss-based", not "delayed-based" CC algorithms. > DCTCP shows the way forward, and highlights that NewReno TCP sawteeth are > to blame for large average queues, and constraining how low an AQM > threshold can go without harming utilisation. > Yes there has been discussion about why ECN has not see deployment widely, and how to fix it. > > I predicted nearly a year ago, that the term "bufferbloat" would confuse > people by seeming to point the finger of blame at the wrong thing: > > > > When it starts to mislead experts in the field, I get worried. > To some of us the term "bufferbloat" itself already implies no AQM,... etc so no worry, we are not confused. > _____ > * Large, but not bloated - see the above URL. > > > ==Relevance to IW10== > I would like to see experiments with IW10 in a simulation modelling how > the Internet is likely to be in future (with more DCTCP-like protocols and > shallower AQM) rather than just how the Internet is now. I'm not saying > whether IW10 is good or bad for "queuebloat", because I haven't done such > experiments. Did I just hear a volunteer? ;-) Best, Jerry > Intuitively it may be OK, but I don't trust my intuition in this case. > > > Bob > > > ______________________________**______________________________**____ > Bob Briscoe, BT Innovate & Design > --f46d044286d229214004bc739a7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bob,

On Fri, Mar 30, 2012 at 1:57 AM, Bob Briscoe = <bob.briscoe@bt.= com> wrote:
Jerry,

In the tcpm meeting just now, you blamed large buffers for the bufferbloat = problem. Not so...

Stanford researchers= have shown that backbone routers do not need large
buffers to=A0= maintain high utilization. Yes it's the bloated average queue
size that=A0is the culprit and one can have large buffers but small av= erage queue
size if an adequate AQM is deployment. But most home/= edge routers with
large buffers do not=A0have adequate AQM, hence= my statement.


With a good AQM (loss or ECN), a large* buffer beyond the AQM threshold is = good, not evil.

The problem is actually queuebloat, not bufferbloat. (The buffer is the mem= ory set aside for the queue. The queue is how much of the memory is used to= store packets or frames.)

The blame for large AQM thresholds lies primarily with TCP's cc algo.

Specifically with the "loss-based"= , not "delayed-based" CC algorithms.
=A0
DCTCP shows the way forward, and highlights that NewReno TCP sawteeth are t= o blame for large average queues, and constraining how low an AQM threshold= can go without harming utilisation.

Yes there has been discussion about why ECN has not see deployment widely,<= /div>
and how to fix it.
=A0

I predicted nearly a year ago, that the term "bufferbloat" would = confuse people by seeming to point the finger of blame at the wrong thing:<= br> <http://www.mail-archive.com/bloat@lists= .bufferbloat.net/msg00215.html>
When it starts to mislead experts in the field, I get worried.

To some of us the term "bufferbloat" itse= lf already implies no AQM,... etc so
no worry, we are not confuse= d.


_____
* Large, but not bloated - see the above URL.


=3D=3DRelevance to IW10=3D=3D
I would like to see experiments with IW10 in a simulation modelling how the= Internet is likely to be in future (with more DCTCP-like protocols and sha= llower AQM) rather than just how the Internet is now. I'm not saying wh= ether IW10 is good or bad for "queuebloat", because I haven't= done such experiments.

Did I just hear a volunteer? ;-)

Best,

Jerry
=A0
Intuitively it may be OK, but I don't trust my intuition in this case.<= br>

Bob


_____________________________________________________________= ___
Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0BT Innovate & Design

--f46d044286d229214004bc739a7b-- From ananth@cisco.com Fri Mar 30 04:02:41 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EFD21F8809 for ; Fri, 30 Mar 2012 04:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnQczM4AVopA for ; Fri, 30 Mar 2012 04:02:40 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0222721F8720 for ; Fri, 30 Mar 2012 04:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=5226; q=dns/txt; s=iport; t=1333105360; x=1334314960; h=mime-version:subject:date:message-id:from:to; bh=uYLWdDTHHXHgnm7xvBkt8KGSuC7bhFj3J+//gUHGKys=; b=Uh8Kz5Qf3akoFO5CrWA+kRrBriWRBxDHJAjrY4MtgspbqbN08fi0VSSR u4qBl1sVL2LsT63JjlPeVy5EXJmCARK1silGiAxlJzq7rYhN8enj6c7Ss MRuvt6+0akm2jaPqfofsFdgP+tIBuE3PuTSEJGo+TqHn3KUHb9Q2ILjtE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJuSdU+rRDoG/2dsb2JhbABDglO2IYEHggsBBBIBCREDQhkBKgYYB1cBBBsah2YBnkuBJ5cwjWyCQWMEiFqbT4Fogwc X-IronPort-AV: E=Sophos;i="4.75,342,1330905600"; d="scan'208,217";a="35777575" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 30 Mar 2012 11:02:39 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2UB2dHu008041 for ; Fri, 30 Mar 2012 11:02:39 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 04:02:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0E64.9F29AC5F" Date: Fri, 30 Mar 2012 04:02:37 -0700 Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C9245F@xmb-sjc-23e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initial Window units. Thread-Index: Ac0OZJ44w050HakVQJypBbOngNbeAA== From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 30 Mar 2012 11:02:39.0523 (UTC) FILETIME=[9F44FF30:01CD0E64] Subject: [tcpm] Initial Window units. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 11:02:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0E64.9F29AC5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I had brought this question to Jerry offline. TCP communicates receive window in bytes (sliding window is based on bytes) So, it would be useful to have the initial window as bytes. Oh, yeah the "bytes versus packet" argument again J Is that an issue? Maybe not but with larger IW's it probably would.. =20 Consider the case of IW=3D10, and the stack doesn't do PMTU, then we end up putting more segments on the network, in case of fragmentation in the path). Even with PMTU, PMTU convergence takes time and it can complicate things. Would it be useful to list this relationship and recommend a lesser IW if the MSS > 1500? In such cases the # of bytes would be useful metric. Another point in favor of this thought would be that Jerry mentioned that anything above than IW=3D10 wasn't that useful for many web objects.. so having IW in bytes versus packets seems useful. Basically I am nervous about the high watermark (cap) of IW in packets, would think it is safer if bytes were used instead. =20 -Anantha ------_=_NextPart_001_01CD0E64.9F29AC5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi,

    I had brought = this question to Jerry offline.  TCP communicates receive window in = bytes (sliding window is based on bytes) So, it would be useful to have = the initial window as bytes. Oh, yeah the “bytes versus = packet” argument again J Is that an issue? Maybe not but = with larger IW’s it probably would..

 

   =  Consider the case of IW=3D10, and the stack doesn’t do PMTU, = then we end up putting more segments on the network, in case of = fragmentation in the path). Even with PMTU,  PMTU convergence takes = time and it can complicate things.  Would it be useful to list this = relationship and recommend a lesser IW if the MSS > 1500?  In = such cases the # of bytes would be useful metric.  Another point in = favor of this thought would be that Jerry mentioned that anything above = than IW=3D10 wasn’t that useful for many web objects.. so having =  IW in bytes versus packets seems useful.  Basically I am = nervous about the high watermark (cap) of IW in packets, would think it = is safer if bytes were used instead.

 

-Anantha

------_=_NextPart_001_01CD0E64.9F29AC5F-- From bob.briscoe@bt.com Fri Mar 30 06:22:24 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6277421F847F for ; Fri, 30 Mar 2012 06:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLXXzj3xP4UA for ; Fri, 30 Mar 2012 06:22:23 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB2D21F848B for ; Fri, 30 Mar 2012 06:22:23 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 30 Mar 2012 14:22:19 +0100 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 30 Mar 2012 14:22:21 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.247.3; Fri, 30 Mar 2012 14:22:20 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1333113752570; Fri, 30 Mar 2012 14:22:32 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.163.89]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2UDMIcc009352; Fri, 30 Mar 2012 14:22:18 +0100 Message-ID: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 Mar 2012 14:22:15 +0100 To: Jerry Chu From: Bob Briscoe In-Reply-To: References: <201203300857.q2U8vNil007606@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_-1952615603==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tcpm IETF list Subject: Re: [tcpm] IW10 & queuebloat X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 13:22:24 -0000 --=====================_-1952615603==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Jerry, At 11:50 30/03/2012, Jerry Chu wrote: >Bob, > >On Fri, Mar 30, 2012 at 1:57 AM, Bob Briscoe ><bob.briscoe@bt.com> wrote: >==Relevance to IW10== >I would like to see experiments with IW10 in a simulation modelling >how the Internet is likely to be in future (with more DCTCP-like >protocols and shallower AQM) rather than just how the Internet is >now. I'm not saying whether IW10 is good or bad for "queuebloat", >because I haven't done such experiments. > > >Did I just hear a volunteer? ;-) I'd love to see the people who are making the proposal pay for the research ;) Seriously, we have other priorities for our stretched resources, but would love to see this done. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_-1952615603==.ALT Content-Type: text/html; charset="us-ascii" Jerry,

At 11:50 30/03/2012, Jerry Chu wrote:
Bob,

On Fri, Mar 30, 2012 at 1:57 AM, Bob Briscoe <bob.briscoe@bt.com> wrote:
==Relevance to IW10==
I would like to see experiments with IW10 in a simulation modelling how the Internet is likely to be in future (with more DCTCP-like protocols and shallower AQM) rather than just how the Internet is now. I'm not saying whether IW10 is good or bad for "queuebloat", because I haven't done such experiments.


Did I just hear a volunteer? ;-)

I'd love to see the people who are making the proposal pay for the research ;)
Seriously, we have other priorities for our stretched resources, but would love to see this done.


Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_-1952615603==.ALT-- From mallman@icir.org Fri Mar 30 07:29:00 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE4121F85A2 for ; Fri, 30 Mar 2012 07:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBYz1qqaXlj7 for ; Fri, 30 Mar 2012 07:28:46 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id A4A9621F85EA for ; Fri, 30 Mar 2012 07:28:46 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q2UESe75028809; Fri, 30 Mar 2012 07:28:41 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 209BF1054DD8; Fri, 30 Mar 2012 10:28:40 -0400 (EDT) To: Bob Briscoe From: Mark Allman In-Reply-To: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Cadillac Ranch X-URL-0: http://www.icir.org/mallman-files/Document42722.docx X-URL-1: http://www.icir.org/mallman-files/Document13450.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma49943-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 30 Mar 2012 10:28:40 -0400 Sender: mallman@icir.org Message-Id: <20120330142840.209BF1054DD8@lawyers.icir.org> Cc: tcpm IETF list Subject: Re: [tcpm] IW10 & queuebloat X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:29:01 -0000 ----------ma49943-1 Content-Type: text/plain Content-Disposition: inline With all due respect Bob, Bob: > > I would like to see experiments with IW10 in a simulation > > modelling how the Internet is likely to be in future (with more > > DCTCP-like protocols and shallower AQM) rather than just how the > > Internet is now. I'm not saying whether IW10 is good or bad for > > "queuebloat", because I haven't done such experiments. More Bob: > I'd love to see the people who are making the proposal pay for the > research ;) Surely the bar for getting something standardized these days is not assessing how a proposal measures up to someone's notion of "how the Internet is likely to be in [the] future". Put another way, I don't think you'd appreciate this bar being applied to your proposals and my volumous notions about the future Internet, would you? (Hint: I am *full* of (ahem) "vision".) Silliness. Dear TCPM chairs, Can we please WGLC IW10? We have been talking about it for eons. There is much empirical / simulation / testbed assessment of it. The pros and cons have been discussed to death. Everyone will never agree with it. But, lets put a stake in the ground and see where we're at WRT WG consensus. If we have consensus then lets move it. If we don't have consensus then lets table it. It is time. allman ----------ma49943-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk91wxcACgkQWyrrWs4yIs5sDQCggXxKxO2bWsKcZFrj+sH2lmEp oaYAoIgh0F2iuCEigegij0NGS/vJ0LXB =Ok7m -----END PGP SIGNATURE----- ----------ma49943-1-- From rs@netapp.com Fri Mar 30 07:46:02 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D1121F8644 for ; Fri, 30 Mar 2012 07:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.242 X-Spam-Level: X-Spam-Status: No, score=-9.242 tagged_above=-999 required=5 tests=[AWL=-1.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV++47dtDadK for ; Fri, 30 Mar 2012 07:45:55 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA7021F85B4 for ; Fri, 30 Mar 2012 07:45:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,344,1330934400"; d="scan'208,217";a="637482165" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Mar 2012 07:45:55 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q2UEjsU4014377; Fri, 30 Mar 2012 07:45:55 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.178]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 07:45:47 -0700 From: "Scheffenegger, Richard" To: "Anantha Ramaiah (ananth)" , "tcpm@ietf.org" Thread-Topic: A new ID on TCP option space extension. Thread-Index: Ac0GRCWpoUYoPErxQTueLRGjeTgRyQAJZVQwAgWphcA= Date: Fri, 30 Mar 2012 14:45:47 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F13156B@SACEXCMBX02-PRD.hq.netapp.com> References: <1F8E0A684D3FF54680294BCFE57A7DB504AEA904@xmb-sjc-23e.amer.cisco.com> In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504AEA904@xmb-sjc-23e.amer.cisco.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F13156BSACEXCMBX02PRDhqn_" MIME-Version: 1.0 Subject: Re: [tcpm] A new ID on TCP option space extension. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 14:46:02 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F13156BSACEXCMBX02PRDhqn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Anantha, After a hint by Matt, I dug out this mail; my comments follow afterwards. * To: TCP Maintenance and Minor Extensions WG > * Subject: [tcpm] RFC 1323: Timestamps option * From: David Borman > * Date: Fri, 26 Jan 2007 12:33:29 -0600 One of the topics that has been discussed in the past for the revision of R= FC 1323 is to relax the requirement on when to send the Timestamps option. = I'd like to come to some resolution on this issue. Current: The Timestamps option is negotiated during the initial SYN exchange. If bot= h sides support it, then every packet in the connection has to have the Tim= estamps option. Option #1 --------- The proposed change is to relax the requirement that Timestamps have to be = negotiated in the initial SYN, and instead allow them to be enabled later o= n in the connection. At the time 1323 was originally written, there was a b= ig concern for legacy TCP stacks that didn't handle unknown options in the = middle of the connection, but were able to properly ignore unknown options = during the SYN exchange. But that was a long time ago, and unknown options = in the middle of a TCP connection *shouldn't* be as big of an issue anymore= . The rules for enabling Timestamps mid-stream would be: 1) If you receive a Timestamps option mid-stream, you can enable Timestamps= . From then on, every packet sent will need to contain a Timestamps option. 2) If you want to enable Timestamps mid-stream, you can only do so on a dat= a packet. You record the sequence number of that data packet, and include t= he Timestamps option on every packet from then on, until you receive an ACK= for that sequence number. If at any time you receive a packet with the Tim= estamps option, then they are enabled for the rest of the connection. If yo= u do not receive a packet with a Timestamps option by the time you get the = ACK for that initial sequence number, then the other side has not enabled T= imestamps and you must stop sending Timestamps for the duration of the conn= ection. The restriction on only being able to initiate Timestamps on a data packet = is that they are the only packets that are delivered reliably, so determini= ng whether or not the other side supports them is deterministic by getting = the ACK for that data. Option #2 --------- This is similar to Option #1, but not quite the same. In this case, the Tim= estamps would be negotiated in the initial SYN as before, but then no addit= ional packets would have Timestamps options. At any point during the connec= tion, either side can enable the use of Timestamps just by starting to send= them. Since we already know that both sides support them, once you start s= ending them you never stop. And if you every receive one, you are then requ= ired to also send them for the duration of the connection. The question then is, how do you negotiate Timestamps without turning them = on? My suggestion would be to send a Timestamps option with the special for= mat TSval=3D0,TSecr=3D0. If you receive this in a SYN, then the request is = to negotiate knowledge of the Timestamps option. The returning SYN,ACK woul= d also need to contain TSval=3D0,TSecr=3D0 to complete the negotiation. If = you are connecting to a site that doesn't support this feature but does sup= port Timestamps, it would respond with TSval=3Dxxx,TSecr=3D0. At that point= , Timestamps are now enabled. The downside of this is that now the originat= or has started their Timestamps values at 0, and must continue from there w= ith their timestamps; they can't just suddenly jump to some arbitrary value= because that could break PAWs. Option #3 --------- Do nothing, and leave Timestamps alone as they are currently defined. You n= egotiate them in the SYN, and then include them in every packet from then o= n. One of the issues with Timestamps is that the TSecr value is defined to be = valid anytime the ACK bit is set. This works well with the initial SYN nego= tiation, but when you enable Timestamps midstream, the initiator has to sen= d a Timestamps option with an invalid TSecr value, but the ACK bit will be = set. That's the case for both of the previous options. So why should we change things? My recollection was that the primary motiva= tion was to conserve option space, to avoid having to put in the extra 12 b= ytes of TCP options on every packet until we get to the point where the seq= uence space might wrap, and then turn them on so that we can get PAWS to pr= otect the rest of the connection. But I'm not sure I buy that argument. One= of the things that you lose by deferring enabling Timestamps is that you d= on't get the RTT measurements that Timestamps provide. Without Timestamps, = using the typical BSD algorithm of timing one segment and waiting for an AC= K, and adding in the Karn algorithm that you have to invalidate any measure= ments if you had to retransmit in that window, means that at best, you'll g= et one measurement per RTT. At worst, you can get in a state where you neve= r get a valid RTT measurement. When you use the Timestamps option, the wors= t case is that you'll only get one measurement per RTT, and the best case i= s that you'll get multiple valid samples, My viewpoint ------------ Right now, I'm inclined to leave the Timestamps option alone; you negotiate= it during the SYN exchange, and then include it on every packet. I'm willi= ng to be convinced otherwise, but now I've placed a stake in the ground, an= d the mailing list will have to decide if there is sufficient reason to cha= nge the behavior. -David Borman Perhaps we should review some of the options that are large and fairly typ= ical. The mentioned timestamp option is prime candidate to try and shift t= hat to somewhere later in the stream. Timestamps really are only useful and necessary (in their current form) for= "high-speed" links (>100 Mbit), and then also only when there are many pac= kets in flight. During the initial few (data) packets, initial RTO and the = limited initial window, a session could do without timestamps... However, not having timestamps in the SYN - as a virtual extention of the s= equence number space, assuming the timestamps between two hosts are monoton= ically increasing also across sessions - would impact certain ad-hoc featur= es (i.e. reducing the 2MSL port reuse policy). >From the above options, Option #1 seems to be most workable - with minimal = code chance. I even suspect, that some stacks implicitly support that alrea= dy from my timestamp tests some time ago (where I stopped sending timestamp= s, after they were negotiated for, and then sent them again). Sending the first timestamp only with the first data packet (and maintainin= g sending timestamps thereafter for one full window/RTT) could be useful. P= erhaps also allowing a passive sender (web server) to initiate this, when t= he first data is sent from that side. This may mean that a negotiation is = started only once a client request has made it in full to the server. After= all, moving these 10 bytes / 80 bits away from the SYN would yield just as= many bits as what Tim today mentioned in his comment to your presentation.= ... Another approach (Option #4) would be to define a new option, without the a= ctual fields - much alike how it is done with SACK - to prime for timestamp= s in the SYN. That would yield only 8 bytes. And it could be done even with= out asking for a new tcp option codepoint, if the tuple is use= d. Len=3D2, option=3Dtimestamp is currently invalid, but could be used to s= ignal the delayed use of timestamps... Are there any other options, that would allow for lazy negotiation (with a = data segment), without breaking things? Best regards, Richard Scheffenegger Anantha Ramaiah (ananth) Sent: Dienstag, 20. M=E4rz 2012 08:29 To: tcpm@ietf.org Subject: Re: [tcpm] A new ID on TCP option space extension. Forgot to add :- I am thankful to the chairs to squeeze this item for the last 10 mins left = on the agenda. Of course if things take more time for other allotted slots = etc.,, this slot has the risk of getting shunted out. I hope we get some= time to discuss this during the meeting, if not we can always continue th= e discussion on the mailing list. Thanks, -Anantha From: Anantha Ramaiah (ananth) Sent: Monday, March 19, 2012 7:50 PM To: tcpm@ietf.org Subject: A new ID on TCP option space extension. Hi, I have a new ID on TCP option space extension. Basically, sometime ba= ck I had volunteered to write up a draft which talks about the TCP option= space issue, motivation, current list of proposals , other ideas if any an= d what we should moving forward on this. Here is the link :- (I could not meet the draft -00- cut off and hence= posting the link) ftp://ftpeng.cisco.com/ananth/draft-ananth-tcpm-tcpopt.txt Please review and provide feedback. In the upcoming TCPM meeting there is = a slot allotted to go over this, but I would appreciate if there is earlier= feedback. (At least this issue is well known and has been discussed sever= al times in the past, in some sense nothing new) Note : there is some scope to improve the structure of the draft, like whe= n comparing each of the proposals one could chose a tabular form OR at leas= t do comparisons in an orderly fashion (like M1, M2 to M6) instead of the w= ay currently it is. Thanks, -Anantha --_000_012C3117EDDB3C4781FD802A8C27DD4F13156BSACEXCMBX02PRDhqn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Hi Anantha,=

 

After a= hint by Matt, I dug out this mail; my comments follow afterwards.

 

= =B7  To: TCP Maintenance and Minor Extensions WG <tcpm at iet= f.org>

= =B7  Subject: [tcpm] RFC 1323: Timestamps option

= =B7  From: David Borman <david.borman at windriver.com<= /span>>

= =B7  Date: Fri, 26 Jan 2007 12:33:29 -0600

  

One of the t= opics that has been discussed in the past for the revision of RFC 1323 is t= o relax the requirement on when to send the Timestamps option. I'd like to come to some resolution on this issue.

Current:
The Timestamps option is negotiated during the initial SYN exchange. If bot= h sides support it, then every packet in the connection has to have the Tim= estamps option.

Option #1
---------
The proposed change is to relax the requirement that Timestamps have to be = negotiated in the initial SYN, and instead allow them to be enabled later o= n in the connection. At the time 1323 was originally written, there was a b= ig concern for legacy TCP stacks that didn't handle unknown options in the middle of the connection, but we= re able to properly ignore unknown options during the SYN exchange. But tha= t was a long time ago, and unknown options in the middle of a TCP connectio= n *shouldn't* be as big of an issue anymore.

The rules for enabling Timestamps mid-stream would be:
1) If you receive a Timestamps option mid-stream, you can enable Timestamps= . From then on, every packet sent will need to contain a Timestamps option.=
2) If you want to enable Timestamps mid-stream, you can only do so on a dat= a packet. You record the sequence number of that data packet, and include t= he Timestamps option on every packet from then on, until you receive an ACK= for that sequence number. If at any time you receive a packet with the Timestamps option, then they are en= abled for the rest of the connection. If you do not receive a packet with a= Timestamps option by the time you get the ACK for that initial sequence nu= mber, then the other side has not enabled Timestamps and you must stop sending Timestamps for the duration o= f the connection.

The restriction on only being able to initiate Timestamps o= n a data packet is that they are the only packets that are delivered reliab= ly, so determining whether or not the other side supports them is deterministic by getting the ACK for that data.


Option #2
---------
This is similar to Option #1, but not quite the same. In this case, the Tim= estamps would be negotiated in the initial SYN as before, but then no addit= ional packets would have Timestamps options. At any point during the connec= tion, either side can enable the use of Timestamps just by starting to send them. Since we already know tha= t both sides support them, once you start sending them you never stop. And = if you every receive one, you are then required to also send them for the d= uration of the connection.

The question then is, how do you negotiate Timestamps witho= ut turning them on? My suggestion would be to send a Timestamps option with= the special format TSval=3D0,TSecr=3D0. If you receive this in a SYN, then the request is to negotiate knowledge of the Timestamp= s option. The returning SYN,ACK would also need to contain TSval=3D0,TSecr= =3D0 to complete the negotiation. If you are connecting to a site that does= n't support this feature but does support Timestamps, it would respond with TSval=3Dxxx,TSecr=3D0. At that point, Ti= mestamps are now enabled. The downside of this is that now the originator h= as started their Timestamps values at 0, and must continue from there with = their timestamps; they can't just suddenly jump to some arbitrary value because that could break PAWs.


Option #3
---------
Do nothing, and leave Timestamps alone as they are currently defined. You n= egotiate them in the SYN, and then include them in every packet from then o= n.

One of the issues with Timestamps is that the TSecr value i= s defined to be valid anytime the ACK bit is set. This works well with the = initial SYN negotiation, but when you enable Timestamps midstream, the initiator has to send a Timestamps option with an invalid T= Secr value, but the ACK bit will be set. That's the case for both of the pr= evious options.

So why should we change things? My recollection was that th= e primary motivation was to conserve option space, to avoid having to put i= n the extra 12 bytes of TCP options on every packet until we get to the point where the sequence space might wrap, and then tu= rn them on so that we can get PAWS to protect the rest of the connection. B= ut I'm not sure I buy that argument. One of the things that you lose by def= erring enabling Timestamps is that you don't get the RTT measurements that Timestamps provide. Without Timest= amps, using the typical BSD algorithm of timing one segment and waiting for= an ACK, and adding in the Karn algorithm that you have to invalidate any m= easurements if you had to retransmit in that window, means that at best, you'll get one measurement per RTT. At= worst, you can get in a state where you never get a valid RTT measurement.= When you use the Timestamps option, the worst case is that you'll only get= one measurement per RTT, and the best case is that you'll get multiple valid samples,

My viewpoint
------------
Right now, I'm inclined to leave the Timestamps option alone; you negotiate= it during the SYN exchange, and then include it on every packet. I'm willi= ng to be convinced otherwise, but now I've placed a stake in the ground, an= d the mailing list will have to decide if there is sufficient reason to change the behavior.

 &nb= sp;            =          -David Borman

&n= bsp;

&n= bsp;

Perhaps= we should review some of the options that  are large and fairly typic= al. The mentioned timestamp option is  prime candidate to try and shif= t that to somewhere later in the stream.

&n= bsp;

Timesta= mps really are only useful and necessary (in their current form) for “= ;high-speed” links (>100 Mbit), and then also only when there are = many packets in flight. During the initial few (data) packets, initial RTO and the limited initial window, a session could do wi= thout timestamps…

&n= bsp;

However= , not having timestamps in the SYN – as a virtual extention of the se= quence number space, assuming the timestamps between two hosts are monotoni= cally increasing also across sessions – would impact certain ad-hoc features (i.e. reducing the 2MSL port reuse policy).=

&n= bsp;

From th= e above options, Option #1 seems to be most workable – with minimal c= ode chance. I even suspect, that some stacks implicitly support that alread= y from my timestamp tests some time ago (where I stopped sending timestamps, after they were negotiated for, and then sen= t them again).

&n= bsp;

Sending= the first timestamp only with the first data packet (and maintaining sendi= ng timestamps thereafter for one full window/RTT) could be useful. Perhaps = also allowing a passive sender (web server) to initiate this, when the first data is sent from that side. This may mea= n that a  negotiation is started only once a client request has made i= t in full to the server. After all, moving these 10 bytes / 80 bits away fr= om the SYN would yield just as many bits as what Tim today mentioned in his comment to your presentation….

&n= bsp;

Another= approach (Option #4) would be to define a new option, without the actual f= ields – much alike how it is done with SACK – to prime for time= stamps in the SYN. That would yield only 8 bytes. And it could be done even without asking for a new tcp option codepoint, i= f the tuple <len,option> is used. Len=3D2, option=3Dtimestamp is curr= ently invalid, but could be used to signal the delayed use of timestamps= 230;

&n= bsp;

&n= bsp;

Are the= re any other options, that would allow for lazy negotiation (with a data se= gment), without breaking things?

&n= bsp;

&n= bsp;

Best re= gards,

&n= bsp;

&n= bsp;

Richard Scheffenegger<= /span>


Anantha Ramaiah (ananth)<= br> Sent: Dienstag, 20. M=E4rz 2012 08:29
To: tcpm@ietf.org
Subject: Re: [tcpm] A new ID on TCP option space extension.

 

Forgot = to add :-

&n= bsp;

I am th= ankful to the chairs to squeeze this item for the last 10 mins left on the = agenda. Of course if things take more time for other allotted slots etc.,, =  this slot has the risk of getting shunted out.  I hope we get  some time  to discuss this during the = meeting, if not we can always continue the discussion on the mailing list.<= o:p>

&n= bsp;

Thanks,=

-Ananth= a

&n= bsp;

From: Anantha Ramaiah (ananth)
Sent: Monday, March 19, 2012 7:50 PM
To: tcpm@ietf.org
Subject: A new ID on TCP option space extension.

 

Hi,

      = I have a new ID on TCP option space extension. Basically, sometime back I h= ad volunteered  to  write up a draft which talks about the TCP op= tion space issue, motivation, current list of proposals , other ideas if any and what we should moving forward  on this.

     Here i= s the link :- (I could not meet the draft -00- cut off and hence posting th= e link)

 

ftp://ftpeng.cisco.com/ananth/draft= -ananth-tcpm-tcpopt.txt

 

Please review and provide feedb= ack.  In the upcoming TCPM meeting there is a slot allotted to go over= this, but I would appreciate if there is earlier feedback.  (At least= this issue is well known and has been discussed several times in the past, in some sense nothing new)

 

Note :  there is some scop= e to improve the structure of the draft, like when comparing each of the pr= oposals one could chose a tabular form OR at least do comparisons in an ord= erly fashion (like M1, M2 to M6) instead of the way currently it is.

 

Thanks,

-Anantha

--_000_012C3117EDDB3C4781FD802A8C27DD4F13156BSACEXCMBX02PRDhqn_-- From mallman@icir.org Fri Mar 30 08:21:06 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEF921F86D9 for ; Fri, 30 Mar 2012 08:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.522 X-Spam-Level: X-Spam-Status: No, score=-106.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 061NSf1Rnb1o for ; Fri, 30 Mar 2012 08:21:04 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id E281821F864B for ; Fri, 30 Mar 2012 08:20:59 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q2UFKvDQ004743; Fri, 30 Mar 2012 08:20:58 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D48931055EF3; Fri, 30 Mar 2012 11:20:57 -0400 (EDT) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F13156B@SACEXCMBX02-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Cadillac Ranch X-URL-0: http://www.icir.org/mallman-files/Document92718.jpg X-URL-1: http://www.icir.org/mallman-files/Document66399.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma53079-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 30 Mar 2012 11:20:57 -0400 Sender: mallman@icir.org Message-Id: <20120330152057.D48931055EF3@lawyers.icir.org> Cc: david.borman@windriver.com, "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] A new ID on TCP option space extension. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 15:21:06 -0000 ----------ma53079-1 Content-Type: text/plain Content-Disposition: inline David- > So why should we change things? My recollection was that the primary > motivation was to conserve option space, to avoid having to put in the > extra 12 bytes of TCP options on every packet until we get to the > point where the sequence space might wrap, and then turn them on so > that we can get PAWS to protect the rest of the connection. I think that is the right motivation. Why send timestamps until they are actually useful for something? Until you need PAWS to kick in you're just wasting space. > One of the things that you lose by deferring enabling Timestamps is > that you don't get the RTT measurements that Timestamps > provide. Without Timestamps, using the typical BSD algorithm of timing > one segment and waiting for an ACK, and adding in the Karn algorithm > that you have to invalidate any measurements if you had to retransmit > in that window, means that at best, you'll get one measurement per > RTT. At worst, you can get in a state where you never get a valid RTT > measurement. When you use the Timestamps option, the worst case is > that you'll only get one measurement per RTT, and the best case is > that you'll get multiple valid samples, (1) Multiple RTT samples per RTT is not useful. (a) It was conjectured in the original RFC that multiple samples per RTT was useful, but never shown. (b) There is empirical evidence that suggests multiple samples give no benefit. (See Allman/Paxson, SIGCOMM 1999.) Or, put another way: Please show us *evidence* that indicates multiple RTT samples per RTT are useful. (2) If you can't get an RTT sample because of Karn's algorithm you're essentially hosed anyway. (a) Lots of the traffic doesn't use timestamps now and so regardless of what we do with the option going forward lots of connections won't be helped by the TS option. (b) It seems a steep price that *everyone* should *always* use the TS option on *every* packet for the *rare* cases when the network is *pathologically* wonky enough to prevent a valid RTT sample from being taken. I think the evidence points to enabling the TS option only when it is necessary for PAWS being the right approach. (And, in fact, ideally just getting rid of the TS option and using a counter option for PAWS that would be smaller in size would be better. But, leveraging the installed base of TS-savvy systems seems useful.) allman ----------ma53079-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk91z1kACgkQWyrrWs4yIs6w7ACeLUQzlSXdHI+bOM1+JyaZUcu9 qzEAnjOu5KnDXrOvM3rHMt8/zi3wyK9I =swTx -----END PGP SIGNATURE----- ----------ma53079-1-- From dab@weston.borman.com Fri Mar 30 09:31:33 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688DB21F86D0 for ; Fri, 30 Mar 2012 09:31:33 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTJHHjI-85vm for ; Fri, 30 Mar 2012 09:31:32 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9992C21F86CB for ; Fri, 30 Mar 2012 09:31:31 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id q2UGVRkD008036; Fri, 30 Mar 2012 10:31:28 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <20120330152057.D48931055EF3@lawyers.icir.org> Date: Fri, 30 Mar 2012 11:31:27 -0500 Content-Transfer-Encoding: 7bit Message-Id: <4143BAFF-5494-43A1-B3DC-917FA4BDB2C3@weston.borman.com> References: <20120330152057.D48931055EF3@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1257) Cc: "Anantha Ramaiah \(ananth\)" , "tcpm@ietf.org" , david.borman@windriver.com Subject: Re: [tcpm] A new ID on TCP option space extension. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 16:31:33 -0000 On Mar 30, 2012, at 10:20 AM, Mark Allman wrote: > > David- > >> So why should we change things? My recollection was that the primary >> motivation was to conserve option space, to avoid having to put in the >> extra 12 bytes of TCP options on every packet until we get to the >> point where the sequence space might wrap, and then turn them on so >> that we can get PAWS to protect the rest of the connection. > > I think that is the right motivation. Why send timestamps until they > are actually useful for something? Until you need PAWS to kick in > you're just wasting space. > >> One of the things that you lose by deferring enabling Timestamps is >> that you don't get the RTT measurements that Timestamps >> provide. Without Timestamps, using the typical BSD algorithm of timing >> one segment and waiting for an ACK, and adding in the Karn algorithm >> that you have to invalidate any measurements if you had to retransmit >> in that window, means that at best, you'll get one measurement per >> RTT. At worst, you can get in a state where you never get a valid RTT >> measurement. When you use the Timestamps option, the worst case is >> that you'll only get one measurement per RTT, and the best case is >> that you'll get multiple valid samples, > > (1) Multiple RTT samples per RTT is not useful. > > (a) It was conjectured in the original RFC that multiple samples per > RTT was useful, but never shown. > > (b) There is empirical evidence that suggests multiple samples give > no benefit. (See Allman/Paxson, SIGCOMM 1999.) > > Or, put another way: Please show us *evidence* that indicates > multiple RTT samples per RTT are useful. > > (2) If you can't get an RTT sample because of Karn's algorithm you're > essentially hosed anyway. > > (a) Lots of the traffic doesn't use timestamps now and so regardless > of what we do with the option going forward lots of connections > won't be helped by the TS option. > > (b) It seems a steep price that *everyone* should *always* use the > TS option on *every* packet for the *rare* cases when the > network is *pathologically* wonky enough to prevent a valid RTT > sample from being taken. > > I think the evidence points to enabling the TS option only when it is > necessary for PAWS being the right approach. While multiple samples per RTT may not be useful, as you have alluded to, with the Karn algorithm at *best* you'll get one sample per RTT, whereas with timestamps, at *worst* you'll get one time sample per RTT. The Karn algorithm can only get an RTT sample when a new ACK arrives and there haven't been any retransmissions. Using timestamps you don't have that ambiguity, and you can calculate the RTT in every new ACK. Maybe you only use one sample per RTT, but at least you are guaranteed to get at least one sample. -David Borman > > (And, in fact, ideally just getting rid of the TS option and using a > counter option for PAWS that would be smaller in size would be better. > But, leveraging the installed base of TS-savvy systems seems useful.) > > allman > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Fri Mar 30 09:47:07 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E699621F86C6 for ; Fri, 30 Mar 2012 09:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwG-sj7rdsr7 for ; Fri, 30 Mar 2012 09:47:07 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 73F8E21F8498 for ; Fri, 30 Mar 2012 09:47:07 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q2UGl5QN015725; Fri, 30 Mar 2012 09:47:05 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 875FE105F1CF; Fri, 30 Mar 2012 12:47:04 -0400 (EDT) To: David Borman From: Mark Allman In-Reply-To: <4143BAFF-5494-43A1-B3DC-917FA4BDB2C3@weston.borman.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Cadillac Ranch X-URL-0: http://www.icir.org/mallman-files/Document25989.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma58247-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 30 Mar 2012 12:47:04 -0400 Sender: mallman@icir.org Message-Id: <20120330164704.875FE105F1CF@lawyers.icir.org> Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] A new ID on TCP option space extension. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 16:47:08 -0000 ----------ma58247-1 Content-Type: text/plain Content-Disposition: inline > > (2) If you can't get an RTT sample because of Karn's algorithm you're > > essentially hosed anyway. > > > > (a) Lots of the traffic doesn't use timestamps now and so regardless > > of what we do with the option going forward lots of connections > > won't be helped by the TS option. > > > > (b) It seems a steep price that *everyone* should *always* use the > > TS option on *every* packet for the *rare* cases when the > > network is *pathologically* wonky enough to prevent a valid RTT > > sample from being taken. > > > > I think the evidence points to enabling the TS option only when it is > > necessary for PAWS being the right approach. > > While multiple samples per RTT may not be useful, as you have alluded > to, (I didn't allude to it. I brought *data* to the table. Just FYI.) > with the Karn algorithm at *best* you'll get one sample per RTT, > whereas with timestamps, at *worst* you'll get one time sample per > RTT. The Karn algorithm can only get an RTT sample when a new ACK > arrives and there haven't been any retransmissions. Using timestamps > you don't have that ambiguity, and you can calculate the RTT in every > new ACK. Maybe you only use one sample per RTT, but at least you are > guaranteed to get at least one sample. Right - I fully understand that. And, if all other things were equal we'd clearly prefer "at worst one sample" to "at best one sample". But, all other things are not equal. Two things in addition to my (2) above: - If that happens for an RTT or two then Who Cares? It is quite unlikely to have much impact on the estimator---which is the thing we really care about. - The only case I can see really caring about in terms of Karn's algorithm is the case you sketched where you couldn't get *any* sample. That is bad. But, also pretty pathological. I don't see engineering every packet on the Internet for this pathology. (Not to mention if you know you'll be in an environment where this is likely you can just use TS from the SYN.) If getting rid of the need for Karn's algorithm is the entire reason to keep timestamps in every packet I think that is very, very thin. allman ----------ma58247-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk9144gACgkQWyrrWs4yIs7PUgCfZ/aoZEpiTUgdJ8YbvLGScZLj 7oAAn039XLcuXBFJvr82obulQJggCrbt =20ew -----END PGP SIGNATURE----- ----------ma58247-1-- From ycheng@google.com Fri Mar 30 10:41:30 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9E221F861B for ; Fri, 30 Mar 2012 10:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.456 X-Spam-Level: X-Spam-Status: No, score=-103.456 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH-y-i-sG-PG for ; Fri, 30 Mar 2012 10:41:29 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C5D1A21F8617 for ; Fri, 30 Mar 2012 10:41:29 -0700 (PDT) Received: by ggmi1 with SMTP id i1so571444ggm.31 for ; Fri, 30 Mar 2012 10:41:29 -0700 (PDT) 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:x-system-of-record:content-type:content-transfer-encoding; bh=tjdkQgqH1NRh6ynSqLzZWyngmy+zwxAQsqwd2/Voozo=; b=Frh0DxTrpJC9eewZwyamuAwXrW24RgDzoA+4j/Nu6Q+14/MlS5uOlW12Ws0ms3UcLv SEBiEpf1R0c1eVWSyl4KZlZFABnEUIBfPW9L4dIaVf/drs+vrxFuYPMkaH+rZPFLVfla bnWmJYXDVaYsgWghIl3BRMqEXbG5bBwyX9SZyDAt6Pk+PKC4U4ZBqFt1uW0dCJ/lNwUc etnkpCRHAs3hCa5ikboq5xJTH4nd5yYx4akRZn5hgYX2kHjBQC+s0lte0zAW2tRnP1jj Ok7qOlZiadcQTg1kwq7AjXoEg04RDAc0taIf57aCpELVexjW5MkXsybduimVo6Grswsv SnBA== X-Google-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:x-system-of-record:x-gm-message-state:content-type :content-transfer-encoding; bh=tjdkQgqH1NRh6ynSqLzZWyngmy+zwxAQsqwd2/Voozo=; b=iBWjX2lZZR/9yhFhgLawghVto5+oynt0q3aYeQV6yePShdphuTP9rDoRfmnsUJpP2V lxIn38D7Pr3X+MBQW08x1d7a5xFZLhYydJLk6ZVK9NH2kdwKldhw3aboVCoTK7JFs1Ds PfxWNHxmJR0RBdgS3ZqbxT/w1us/AOHlAkyU+ROziduZ20AdSMJlr+t+C3Xww3JtAZof NADUX5M+hwjtI57p90Ew3aWZhQeOWXW5463jenbqIX+tS0iwvBXdgChO7V2/NewTBWXZ LpZtfN+m4rC2jrjwpe9kkzk0e52o6CNK+URcl+Zi8QRlPcheYYijtIEWkW/AEhgnVgV8 kHAQ== Received: by 10.60.13.37 with SMTP id e5mr4107455oec.70.1333129289311; Fri, 30 Mar 2012 10:41:29 -0700 (PDT) Received: by 10.60.13.37 with SMTP id e5mr4107444oec.70.1333129289212; Fri, 30 Mar 2012 10:41:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.74.233 with HTTP; Fri, 30 Mar 2012 10:41:08 -0700 (PDT) In-Reply-To: <20120330142840.209BF1054DD8@lawyers.icir.org> References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org> From: Yuchung Cheng Date: Fri, 30 Mar 2012 10:41:08 -0700 Message-ID: To: mallman@icir.org X-System-Of-Record: true X-Gm-Message-State: ALoCoQn1REI3rc/3TLcwqTNyQ3fw58nHcvirc60uSxanp55N4Y7JgT8K3bLfrrD+EIJqhqFKbwWNHMqgcRoMlpCmKy/5pIDnJPVrByRg2AQTItOxpV2DC0FOXgipWb15Er3VUHPnUrv8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm IETF list Subject: Re: [tcpm] IW10 & queuebloat X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 17:41:30 -0000 On Fri, Mar 30, 2012 at 7:28 AM, Mark Allman wrote: > > With all due respect Bob, > > Bob: >> > I would like to see experiments with IW10 in a simulation >> > modelling how the Internet is likely to be in future (with more >> > DCTCP-like protocols and shallower AQM) rather than just how the >> > Internet is now. I'm not saying whether IW10 is good or bad for >> > "queuebloat", because I haven't done such experiments. > > More Bob: >> I'd love to see the people who are making the proposal pay for the >> research ;) > > Surely the bar for getting something standardized these days is not > assessing how a proposal measures up to someone's notion of "how the > Internet is likely to be in [the] future". > > Put another way, I don't think you'd appreciate this bar being applied > to your proposals and my volumous notions about the future Internet, > would you? =A0(Hint: I am *full* of (ahem) "vision".) nod > > Silliness. > > > Dear TCPM chairs, Can we please WGLC IW10? =A0We have been talking about > it for eons. =A0There is much empirical / simulation / testbed assessment > of it. =A0The pros and cons have been discussed to death. =A0Everyone wil= l > never agree with it. =A0But, lets put a stake in the ground and see where > we're at WRT WG consensus. =A0If we have consensus then lets move it. =A0= If > we don't have consensus then lets table it. =A0It is time. A gentle reminder the intended status is experimental which calls for more experiments like what Bob and others are suggesting. > > allman > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From rs@netapp.com Sat Mar 31 01:13:48 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9970521F86EE for ; Sat, 31 Mar 2012 01:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ot57qlo+dDUT for ; Sat, 31 Mar 2012 01:13:48 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 06ADB21F86EC for ; Sat, 31 Mar 2012 01:13:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,348,1330934400"; d="scan'208";a="637670634" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 31 Mar 2012 01:13:32 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q2V8DVIX027487; Sat, 31 Mar 2012 01:13:31 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.76]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0247.003; Sat, 31 Mar 2012 01:13:24 -0700 From: "Scheffenegger, Richard" To: "mallman@icir.org" , David Borman Thread-Topic: [tcpm] A new ID on TCP option space extension. Thread-Index: AQHNDpS8oUh7TxzN3kGQDUD43vV8cJaDY3FQ Date: Sat, 31 Mar 2012 08:13:23 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F13C4D1@SACEXCMBX02-PRD.hq.netapp.com> References: <4143BAFF-5494-43A1-B3DC-917FA4BDB2C3@weston.borman.com> <20120330164704.875FE105F1CF@lawyers.icir.org> In-Reply-To: <20120330164704.875FE105F1CF@lawyers.icir.org> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] A new ID on TCP option space extension. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 08:13:48 -0000 Hi Mark, > If getting rid of the need for Karn's algorithm is the entire reason to k= eep > timestamps in every packet I think that is very, very thin. Actually, allowing for delay-based congestion algorithms like LEDBET, CTCP = may be a stronger use case for timestamps. However, the way they are signal= ed currently (opaque to the receiver), these controllers all rely on more o= r less good heuristics to interpret the timestamp. I'll rewrite my draft to emphasize on this in the next couple weeks..=20 Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Mark Allman > Sent: Freitag, 30. M=E4rz 2012 18:47 > To: David Borman > Cc: tcpm@ietf.org; Anantha Ramaiah (ananth) > Subject: Re: [tcpm] A new ID on TCP option space extension. >=20 >=20 > > > (2) If you can't get an RTT sample because of Karn's algorithm you're > > > essentially hosed anyway. > > > > > > (a) Lots of the traffic doesn't use timestamps now and so regardle= ss > > > of what we do with the option going forward lots of connection= s > > > won't be helped by the TS option. > > > > > > (b) It seems a steep price that *everyone* should *always* use the > > > TS option on *every* packet for the *rare* cases when the > > > network is *pathologically* wonky enough to prevent a valid RT= T > > > sample from being taken. > > > > > > I think the evidence points to enabling the TS option only when it > > > is necessary for PAWS being the right approach. > > > > While multiple samples per RTT may not be useful, as you have alluded > > to, >=20 > (I didn't allude to it. I brought *data* to the table. Just FYI.) >=20 > > with the Karn algorithm at *best* you'll get one sample per RTT, > > whereas with timestamps, at *worst* you'll get one time sample per > > RTT. The Karn algorithm can only get an RTT sample when a new ACK > > arrives and there haven't been any retransmissions. Using timestamps > > you don't have that ambiguity, and you can calculate the RTT in every > > new ACK. Maybe you only use one sample per RTT, but at least you are > > guaranteed to get at least one sample. >=20 > Right - I fully understand that. And, if all other things were equal we'= d clearly > prefer "at worst one sample" to "at best one sample". But, all other thi= ngs > are not equal. >=20 > Two things in addition to my (2) above: >=20 > - If that happens for an RTT or two then Who Cares? It is quite > unlikely to have much impact on the estimator---which is the thing > we really care about. >=20 > - The only case I can see really caring about in terms of Karn's > algorithm is the case you sketched where you couldn't get *any* > sample. That is bad. But, also pretty pathological. I don't see > engineering every packet on the Internet for this pathology. >=20 > (Not to mention if you know you'll be in an environment where this > is likely you can just use TS from the SYN.) >=20 > If getting rid of the need for Karn's algorithm is the entire reason to k= eep > timestamps in every packet I think that is very, very thin. >=20 > allman >=20 >=20 From mallman@icir.org Sat Mar 31 07:03:02 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B4921F85C7 for ; Sat, 31 Mar 2012 07:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogMNOOI6lPhI for ; Sat, 31 Mar 2012 07:03:01 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id EA05021F8567 for ; Sat, 31 Mar 2012 07:03:01 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q2VE2wgc013184; Sat, 31 Mar 2012 07:02:59 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3AADC109F66B; Sat, 31 Mar 2012 10:02:58 -0400 (EDT) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F13C4D1@SACEXCMBX02-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Sweet Home Alabama X-URL-0: http://www.icir.org/mallman-files/Document96485.doc X-URL-1: http://www.icir.org/mallman-files/Document31549.docx X-URL-2: http://www.icir.org/mallman-files/Document25224.html X-URL-3: http://www.icir.org/mallman-files/Document13195.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma3727-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 31 Mar 2012 10:02:58 -0400 Sender: mallman@icir.org Message-Id: <20120331140258.3AADC109F66B@lawyers.icir.org> Cc: David Borman , "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] A new ID on TCP option space extension. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 31 Mar 2012 14:03:02 -0000 ----------ma3727-1 Content-Type: text/plain Content-Disposition: inline > Actually, allowing for delay-based congestion algorithms like LEDBET, > CTCP may be a stronger use case for timestamps. That is absolutely fine. I am not saying we should rid the world of timestamps. I am saying that we should re-arrange the world such that TCP connections do not have to use timestamps because they *might* need them later. If there is some good reason to use them from the onset of the connection, great, use them. But, - If RTTM is the reason to use the TS option then I haven't seen the empirical evidence that says this is at all helpful and so I am pretty dubious. - If PAWS is the reason to use the TS option then I don't see why we'd waste the bytes on the TS option for connections that send less than 4GB (i.e., that will not wrap the sequence space). So, being able to turn on the TS option mid-connection when PAWS is required makes good sense to me. So, I am voting for an RFC 1323bis that calls for negotiating timestamps only when they are needed. And, if some new use needs to do so at the beginning of the connection and use them throughout then we should absolutely not preclude that. allman ----------ma3727-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk93DpEACgkQWyrrWs4yIs4ITwCgh/z8ZMp3xTOz4iyH4a7iX1Nr A0IAn0QKgnwOjWoAJX4FjB/WGSISl/rx =Ocgf -----END PGP SIGNATURE----- ----------ma3727-1-- From ananth@cisco.com Sat Mar 31 19:12:34 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9421F85C0 for ; Sat, 31 Mar 2012 19:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdLP53sjOQYZ for ; Sat, 31 Mar 2012 19:12:33 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A5B2C21F85BD for ; Sat, 31 Mar 2012 19:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2884; q=dns/txt; s=iport; t=1333246353; x=1334455953; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qvXzmMIt8FJ17S31L6a+AT7ThnDeVxJeltf7M+J1ExQ=; b=V8m397hyC4Mbgbv1dBxTP4PWjNQ869AeMQP+or6A/AcdQa28ieLWIWmB 2epPMyIss1cJ28RVqCWhIPVGcG1HDjwUEYDaR4/5Ox4o+urfdtL4OVvFZ vkaOBV8wUsFNxbqyA1VzFvs7nwz/nouxNtCjsSUACVKdCyhVCgfMkeTHB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAES5d0+rRDoI/2dsb2JhbABCuQmBB4IJAQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAQEEEwgTB4dmAaAclkyQOWMEiFibUIFogweBNAc X-IronPort-AV: E=Sophos;i="4.75,350,1330905600"; d="scan'208";a="35425403" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 01 Apr 2012 02:12:33 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q312CXma015972; Sun, 1 Apr 2012 02:12:33 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Mar 2012 19:12:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 31 Mar 2012 19:12:32 -0700 Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C9287B@xmb-sjc-23e.amer.cisco.com> In-Reply-To: <20120331140258.3AADC109F66B@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] A new ID on TCP option space extension. Thread-Index: Ac0PRvyOMRvgXm16R8ygQeKqiYlCLAAYQLQg References: <012C3117EDDB3C4781FD802A8C27DD4F13C4D1@SACEXCMBX02-PRD.hq.netapp.com> <20120331140258.3AADC109F66B@lawyers.icir.org> From: "Anantha Ramaiah (ananth)" To: , "Scheffenegger, Richard" X-OriginalArrivalTime: 01 Apr 2012 02:12:33.0083 (UTC) FILETIME=[E5FAE8B0:01CD0FAC] Cc: David Borman , tcpm@ietf.org Subject: Re: [tcpm] A new ID on TCP option space extension. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Apr 2012 02:12:34 -0000 RTTM has been touted to be the main use for timestamps which includes solution to the Karn's ambiguity problem. The other one is PAWS and w.r.t I agree it is wastage of TCP option bytes and the idea of turning on PAWS detection dynamically (using timestamps) makes sense to me. Changing the timestamp semantics means change to many TCP/IP stacks (variables like ts_val, ts_recent would not be interpreted as before, all other debugging tools etc., may need to understand this change) Even if we are planning to do so, I thought you meant to negotiate the capability during SYN (don't send the timestamp value) and send timestamps when needed. Or are we saying that we are trying to negotiate the option when needed, this sounds like a bigger change in semantics since every TCP option is only negotiated during SYN as it stands today. To make this more useful, you would want to not only turn on this capability when needed, also turn off when not needed. Didn't we already have a RFC 1323bis document? Is that expired or did it make it to the RFC 1323 update ? If not, you could always fold this idea (assuming there is a consensus) into that document. Not sure whether we would want multiple RFC 1323bis documents... Just my 2 cents.. -Anantha > -----Original Message----- > From: mallman@icir.org [mailto:mallman@icir.org] > Sent: Saturday, March 31, 2012 7:03 AM > To: Scheffenegger, Richard > Cc: David Borman; tcpm@ietf.org; Anantha Ramaiah (ananth) > Subject: Re: [tcpm] A new ID on TCP option space extension. >=20 >=20 > > Actually, allowing for delay-based congestion algorithms like LEDBET, > > CTCP may be a stronger use case for timestamps. >=20 > That is absolutely fine. I am not saying we should rid the world of > timestamps. I am saying that we should re-arrange the world such that > TCP connections do not have to use timestamps because they *might* need > them later. If there is some good reason to use them from the onset of > the connection, great, use them. But, >=20 > - If RTTM is the reason to use the TS option then I haven't seen the > empirical evidence that says this is at all helpful and so I am > pretty dubious. >=20 > - If PAWS is the reason to use the TS option then I don't see why > we'd > waste the bytes on the TS option for connections that send less > than > 4GB (i.e., that will not wrap the sequence space). So, being able > to turn on the TS option mid-connection when PAWS is required makes > good sense to me. >=20 > So, I am voting for an RFC 1323bis that calls for negotiating > timestamps only when they are needed. And, if some new use needs to do > so at the beginning of the connection and use them throughout then we > should absolutely not preclude that. >=20 > allman >=20 >=20