From root@core3.amsl.com Wed Jun 2 20:30:03 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5AD2D3A692C; Wed, 2 Jun 2010 20:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100603033003.5AD2D3A692C@core3.amsl.com> Date: Wed, 2 Jun 2010 20:30:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-persist-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 03:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Clarification of sender behaviour in persist condition. Author(s) : M. Bashyam, et al. Filename : draft-ietf-tcpm-persist-00.txt Pages : 11 Date : 2010-06-02 This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-persist-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-02202454.I-D@ietf.org> --NextPart-- From lars.eggert@nokia.com Wed Jun 9 09:28:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17DC3A69A2 for ; Wed, 9 Jun 2010 09:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKLh5M-7vmmT for ; Wed, 9 Jun 2010 09:28:38 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id F34CE3A6971 for ; Wed, 9 Jun 2010 09:28:37 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o59GST1P006688 for ; Wed, 9 Jun 2010 19:28:36 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jun 2010 19:28:28 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jun 2010 19:28:28 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o59GSQBc008098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Jun 2010 19:28:26 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-44--706532500; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 9 Jun 2010 19:28:14 +0300 References: <20100609151532.8E75E28C0D0@core3.amsl.com> To: "tcpm@ietf.org Extensions" Message-Id: <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Wed, 09 Jun 2010 19:28:20 +0300 (EEST) X-OriginalArrivalTime: 09 Jun 2010 16:28:28.0085 (UTC) FILETIME=[CA7BD650:01CB07F0] X-Nokia-AV: Clean Subject: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 16:28:41 -0000 --Apple-Mail-44--706532500 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Quite possibly the most boring RFC ever. But at least it's short. = Comments welcome. http://tools.ietf.org/html/draft-eggert-tcpm-historicize Begin forwarded message: > Filename: draft-eggert-tcpm-historicize > Revision: 00 > Title: Moving the Undeployed TCP Extensions RFC1072, = RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and = RFC1693 to Historic Status > Creation_date: 2010-06-09 > WG ID: Independent Submission > Number_of_pages: 4 >=20 > Abstract: > This document recommends that several TCP extensions that have never > seen widespread use be moved to Historic status. The affected RFCs > are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, > RFC1644 and RFC1693. Lars= --Apple-Mail-44--706532500 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDYwOTE2MjgxNFowIwYJKoZIhvcNAQkEMRYEFNDLaq7q94qNlHKyzVAv4XJK2DOsMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBt2iBdQvP8U1YgzoYTYsZ3a2i2IpaClVvX3MzOWIb0BZWkuhsTmIrM1OECywBuYKf4FOYP 7ovuJLdl1V2f/mAbPh4nWMyM5iUJ3GarTofke4VS0rZZBwfDBXGWuISRdJMQ7RSuTO5k1ioIB70I vR6DqnFhzFQ00wYVUYNOTLSLE4QUbpse1aS4Smcm02629YG/7j4QZRCIXz74O329Qz9Y7i/4qisi Cla+WCH5KyGnQ/2iWfHepMrFFeQ+eOhQaQxlVLVFuhFSwPCzGTPNZqFocRerMR2FX0XJxY8N4G0V F2/ZP2qitXKXLuFeWi2Xi3WG1nxNHUwwCJwOI+xqV4VOAAAAAAAA --Apple-Mail-44--706532500-- From rbonica@juniper.net Wed Jun 9 10:23:16 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985803A67AB for ; Wed, 9 Jun 2010 10:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZgiF2UgvypZ for ; Wed, 9 Jun 2010 10:23:15 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 8338D3A699E for ; Wed, 9 Jun 2010 10:23:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTA/OBSwtBIy3MqfZKtendfyQPur3JBkj@postini.com; Wed, 09 Jun 2010 10:23:17 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 9 Jun 2010 10:19:56 -0700 Received: from [172.28.134.21] (172.28.134.21) by p-emfe02-wf.jnpr.net (172.28.145.22) with Microsoft SMTP Server id 8.2.254.0; Wed, 9 Jun 2010 13:19:55 -0400 Message-ID: <4C0FCD39.6090703@juniper.net> Date: Wed, 9 Jun 2010 13:19:53 -0400 From: Ron Bonica User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> In-Reply-To: <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 17:23:16 -0000 I applaud this effort. I think that we should all take a sweep through our registries and RFCs to get rid of some old cruft. Ron On 6/9/2010 12:28 PM, Lars Eggert wrote: > Quite possibly the most boring RFC ever. But at least it's short. Comments welcome. > > http://tools.ietf.org/html/draft-eggert-tcpm-historicize > > Begin forwarded message: >> Filename: draft-eggert-tcpm-historicize >> Revision: 00 >> Title: Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and RFC1693 to Historic Status >> Creation_date: 2010-06-09 >> WG ID: Independent Submission >> Number_of_pages: 4 >> >> Abstract: >> This document recommends that several TCP extensions that have never >> seen widespread use be moved to Historic status. The affected RFCs >> are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, >> RFC1644 and RFC1693. > > Lars From hagen@jauu.net Wed Jun 9 10:36:01 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086E43A699E for ; Wed, 9 Jun 2010 10:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Q0S+kVJkZb7 for ; Wed, 9 Jun 2010 10:36:00 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id A0C143A6977 for ; Wed, 9 Jun 2010 10:35:58 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 6157AF44129; Wed, 9 Jun 2010 19:35:57 +0200 (CEST) Date: Wed, 9 Jun 2010 19:35:56 +0200 From: Hagen Paul Pfeifer To: Lars Eggert Message-ID: <20100609173556.GA5338@nuttenaction> References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> 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.20 (2009-06-14) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 17:36:01 -0000 * Lars Eggert | 2010-06-09 19:28:14 [+0300]: >Quite possibly the most boring RFC ever. But at least it's short. Comments >welcome. Lars, I thought about RFC 1145 "TCP Alternate Checksum Options", there are no real shortcomings in the RFC. It is not _widely_ deployed but there is no real security concern like say T/TCP. I thought only superseded or defective RFCs can be declared historic? I mean TCP Alternate Checksum Options _can eventually_ useful in the future for example Interplanetary TCP. Maybe some military sites already employ RFC 1145. HGN From ananth@cisco.com Wed Jun 9 11:07:05 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75D128C119 for ; Wed, 9 Jun 2010 11:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.392 X-Spam-Level: X-Spam-Status: No, score=-9.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUm-r6Ey4sJf for ; Wed, 9 Jun 2010 11:07:03 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A76E728C10E for ; Wed, 9 Jun 2010 11:07:03 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKp0D0yrR7H+/2dsb2JhbACeUHGlNZoWhRgEg0k X-IronPort-AV: E=Sophos;i="4.53,393,1272844800"; d="scan'208";a="141840317" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 09 Jun 2010 18:07:01 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o59I71hj017398; Wed, 9 Jun 2010 18:07:01 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jun 2010 11:07:01 -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: Wed, 9 Jun 2010 11:07:00 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20100609173556.GA5338@nuttenaction> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsH+kNJs30OOH2cRXuS0AecodzrewAAJlFA References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> From: "Anantha Ramaiah (ananth)" To: "Hagen Paul Pfeifer" , "Lars Eggert" X-OriginalArrivalTime: 09 Jun 2010 18:07:01.0349 (UTC) FILETIME=[8F105150:01CB07FE] Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 18:07:06 -0000 +1 FWIW, there is a recent proposal which talks about enhancing TCP checksums as well :- http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/ The above proposal tries to leverage on the TCP alternate checksum option. My thinking it may be useful to have a "TCP generalized checksum option" which can give the flexibility for a TCP stack to choose from a set of checksum algorithms (of course the default stays what it is today ;-)=20 -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Hagen Paul Pfeifer > Sent: Wednesday, June 09, 2010 10:36 AM > To: Lars Eggert > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 >=20 > * Lars Eggert | 2010-06-09 19:28:14 [+0300]: >=20 > >Quite possibly the most boring RFC ever. But at least it's short.=20 > >Comments welcome. >=20 > Lars, I thought about RFC 1145 "TCP Alternate Checksum=20 > Options", there are no real shortcomings in the RFC. It is=20 > not _widely_ deployed but there is no real security concern=20 > like say T/TCP. >=20 > I thought only superseded or defective RFCs can be declared=20 > historic? I mean TCP Alternate Checksum Options _can=20 > eventually_ useful in the future for example Interplanetary=20 > TCP. Maybe some military sites already employ RFC 1145. >=20 > HGN > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From touch@isi.edu Wed Jun 9 11:23:16 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69EC28C11E for ; Wed, 9 Jun 2010 11:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+TCGBQCGWiF for ; Wed, 9 Jun 2010 11:23:15 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 154ED3A67E7 for ; Wed, 9 Jun 2010 11:23:15 -0700 (PDT) Received: from [75.214.122.201] (201.sub-75-214-122.myvzw.com [75.214.122.201]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o59ILth5026185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jun 2010 11:22:10 -0700 (PDT) Message-ID: <4C0FDBA0.7030500@isi.edu> Date: Wed, 09 Jun 2010 11:21:20 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig23CBAE26486FC221EE01C91B" X-MailScanner-ID: o59ILth5026185 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 18:23:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig23CBAE26486FC221EE01C91B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Ananth, Anantha Ramaiah (ananth) wrote: > +1 >=20 > FWIW, there is a recent proposal which talks about enhancing TCP > checksums as well :- >=20 > http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/ I was wondering why this didn't just use the alternate checksum option (t= hey talk about it, but it's not clear why they don't just assume that path). > The above proposal tries to leverage on the TCP alternate checksum > option. My thinking it may be useful to have a "TCP generalized checksu= m > option" which can give the flexibility for a TCP stack to choose from a= > set of checksum algorithms (of course the default stays what it is toda= y > ;-)=20 The question is whether we need a "generalized" such option, or whether t= he current alternate checksum is basically sufficient, given a table of appr= opriate algorithms and algorithm IDs. There are already 253 available ID values l= eft ;-) Joe --------------enig23CBAE26486FC221EE01C91B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwP26QACgkQE5f5cImnZrvRcQCg5V7YpkvN04qRCP4epM212l8w UQkAnRDog12GAeSRDptGxNNgO53Qpker =AWO2 -----END PGP SIGNATURE----- --------------enig23CBAE26486FC221EE01C91B-- From lars.eggert@nokia.com Wed Jun 9 11:28:04 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6463C3A67EC for ; Wed, 9 Jun 2010 11:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.356 X-Spam-Level: X-Spam-Status: No, score=-5.356 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwhw1B-glzSd for ; Wed, 9 Jun 2010 11:28:03 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 28FB23A676A for ; Wed, 9 Jun 2010 11:28:03 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o59IS1Gr006803; Wed, 9 Jun 2010 13:28:02 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jun 2010 21:28:00 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jun 2010 21:28:00 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o59IRxAq008555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jun 2010 21:27:59 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-45--699360132; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <20100609173556.GA5338@nuttenaction> Date: Wed, 9 Jun 2010 21:27:46 +0300 Message-Id: <4ADFD444-468E-4120-A5B4-B91927844565@nokia.com> References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> To: Hagen Paul Pfeifer X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Wed, 09 Jun 2010 21:27:53 +0300 (EEST) X-OriginalArrivalTime: 09 Jun 2010 18:28:00.0607 (UTC) FILETIME=[7DA3D6F0:01CB0801] X-Nokia-AV: Clean Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 18:28:04 -0000 --Apple-Mail-45--699360132 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-6-9, at 20:35, Hagen Paul Pfeifer wrote: > Lars, I thought about RFC 1145 "TCP Alternate Checksum Options", there = are no > real shortcomings in the RFC. It is not _widely_ deployed but there is = no real > security concern like say T/TCP. true. But nobody has bothered to ship it in twenty years, AFAIK. > I thought only superseded or defective RFCs can be declared historic? See Section 4.2.4 of RFC2026:=20 A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. RFC4614 has classified this extension as Historic for "lack of interest" = in 2006. This ID just nails the coffin shut. > I mean > TCP Alternate Checksum Options _can eventually_ useful in the future = for > example Interplanetary TCP. Sure, but it hasn't been in use in twenty years, and the Interplanetary = TCP is also not immediately around the corner. > Maybe some military sites already employ RFC 1145. If you know of deployments, I'm all ears. But even if we do declare it = Historic, that does *not* mean that folks that are running it shouldn't = run it anymore. The code points, for example, do remain assigned. Lars= --Apple-Mail-45--699360132 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDYwOTE4Mjc0N1owIwYJKoZIhvcNAQkEMRYEFH3VLinINYJ94lOplexFy1azya9YMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAUnIrt2DZP/RQG5f37XHNjLKgyA2sl++56+JUG99CxjP2RHSTcLftu+zZ5ZyG6OOBNJwgj SlEfYuSS6S/cwvkc/mfq682UwdOmiudE8vJUwczHG7haP319uByOW4Qgz+Gm8XMMSkgrV9qZzVqL c5cEjUnnkvLY3g+Qd/aq8hT/d2Z6FTCx1zCZuvkvjh1Jn+qiQEcomp4o8ERSC0Bfw+1E4Fk7DVlZ NJ3YC6rItFIxDaEl6Dvf9OdCwifzJjN/xftrjVVdyYqU63FPLebqQdL5XeyIHuplBtTsVz7/wcAi QYc8FQEQacMCiIekkHAJb5lDYzlliCNzpw1rM6HlQBA7AAAAAAAA --Apple-Mail-45--699360132-- From lars.eggert@nokia.com Wed Jun 9 11:30:55 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F843A67E7 for ; Wed, 9 Jun 2010 11:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.086 X-Spam-Level: X-Spam-Status: No, score=-6.086 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHRRCvrP7tJT for ; Wed, 9 Jun 2010 11:30:49 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 07E783A6877 for ; Wed, 9 Jun 2010 11:30:45 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o59IUbb4007559; Wed, 9 Jun 2010 21:30:42 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jun 2010 21:30:41 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jun 2010 21:30:41 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o59IUZhj011594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jun 2010 21:30:40 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-46--699202886; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com> Date: Wed, 9 Jun 2010 21:30:24 +0300 Message-Id: <8B364027-73E4-4C85-B879-7609E28A8B19@nokia.com> References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com> To: Anantha Ramaiah (ananth) X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Wed, 09 Jun 2010 21:30:29 +0300 (EEST) X-OriginalArrivalTime: 09 Jun 2010 18:30:41.0460 (UTC) FILETIME=[DD840F40:01CB0801] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" Subject: [tcpm] draft-anumita-tcpm-stronger-checksum (was: Re: draft-eggert-tcpm-historicize-00) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 18:30:55 -0000 --Apple-Mail-46--699202886 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-6-9, at 21:07, Anantha Ramaiah (ananth) wrote: > FWIW, there is a recent proposal which talks about enhancing TCP > checksums as well :- >=20 > http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/ >=20 > The above proposal tries to leverage on the TCP alternate checksum > option. I've skimmed through this draft when it first came out. I may be missing = something, but why isn't TLS the right solution here? Sure, it may be = overkill, but it's readily available. Lars= --Apple-Mail-46--699202886 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDYwOTE4MzAyNFowIwYJKoZIhvcNAQkEMRYEFHP//kJigldk/RnUeVLCq/FDlkSWMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCQQO0L5uMaqrH84o76ZK8PsZUIO60CLfcSPb4Q1EGaukvqm4wXjhCl5fkg5UNvc3cpXXZk t6M+4P9bwW20bQOwQm//+FiZCgakoDMWQI9bpLomC/iRKD7K7AhrPF7tSwTLX2P+I2kTQltSNRsp oorasag2TKmL0lYIAvvVX1l0TGMJGknpXs1LYE5FN/gLdH2ue50yaRL+yl1WEBx8BPA7ip05/XmE N+pDUrrPb8PJ/9TiYrXYRGZPPPhyzr6iSF1UMci2VoNUaq/1SgAyrUS8PEmYnNFuZ+HlI/UBt5U+ 90xkJOIMfI0Oyc0XtVcLVRDkU/m15899z9Nt5krGV56hAAAAAAAA --Apple-Mail-46--699202886-- From L.Wood@surrey.ac.uk Wed Jun 9 12:15:15 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B183A6818 for ; Wed, 9 Jun 2010 12:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn0mhJmLgcQu for ; Wed, 9 Jun 2010 12:15:11 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 15A6E3A676A for ; Wed, 9 Jun 2010 12:15:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-15.tower-82.messagelabs.com!1276110911!10461854!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 22065 invoked from network); 9 Jun 2010 19:15:11 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-15.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 9 Jun 2010 19:15:11 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 9 Jun 2010 20:15:11 +0100 From: To: Date: Wed, 9 Jun 2010 20:15:09 +0100 Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsICBQ8J1cjZMVwRaaWiZka4WO5Rw== Message-ID: <07BF7B99-FF83-44E1-BF52-BED91ACA7F3A@surrey.ac.uk> References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> In-Reply-To: <20100609173556.GA5338@nuttenaction> Accept-Language: en-US, en-GB Content-Language: en-US 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, L.Wood@surrey.ac.uk Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 19:15:16 -0000 On 9 Jun 2010, at 18:35, Hagen Paul Pfeifer wrote: >=20 > TCP Alternate Checksum Options _can eventually_ useful in the future for > example Interplanetary TCP. Unlikely. TCP is usable (albeit slow) up until 1.5 light seconds, which just about encompasses the Moon. Beyond that, interactions of the path delay with TCP timers degrade performance considerably. Long-distance interplanetary communication is more likely to be scheduled and continuous, carefully managed, rather than just throwing a bunch of competing flows down a pipe and out a dish and trusting TCP endpoints to do anything useful with the bandwidth their algorithms prevent them from using effectively. (The old 'loss due to channel corruption is not loss due to congestion, so don't back off sending' problem.) Long-distance interplanetary communication may use IP, but it won't use TCP. Some details in http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#pro= tocol-radius Lloyd Wood, Cathryn Peoples, Gerard Parr, Bryan Scotney, Adrian Moore, 'TCP's protocol radius: the distance where timers prevent communication,' peer-reviewed conference paper, International Workshop on Space and Satellite Communications (IWSSC '07), Salzburg, Austria, September 2007. In any case, the TCP/UDP checksum often acts as a final demux check at the endpoint thanks to the pseudo-header coverage; lower-layer frame checksums detect transmission errors, while higher-layer checksums or digests across e.g. files detect errors after reassembly on final delivery. > Maybe some military sites already employ RFC 1145. Unlikely. SCPS-TP (a 'restandardising' of TCP by other bodies aimed at the US Department of Defense and others way back when) has found a niche in PEP acceleration for satellite in US military networks - and that only has the TCP checksum. (A rare example of stuff being left out in restandardising, rather than being added in.) If you want TCP behaviour but with a stronger checksum, use SCTP. See RFC4960. (Won't help with large jumbo SCTP frames, though; longer lengths need stronger checks, and CRC32c weakens after about 14Kbytes of payload.) Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From Martin.Duke@boeing.com Wed Jun 9 12:25:41 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1853A67E7 for ; Wed, 9 Jun 2010 12:25:41 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnSEZxLF6fg4 for ; Wed, 9 Jun 2010 12:25:40 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 7EB7C3A676A for ; Wed, 9 Jun 2010 12:25:40 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o59JPfjm025747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Jun 2010 12:25:41 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o59JPeQg016126; Wed, 9 Jun 2010 12:25:41 -0700 (PDT) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o59JPeq1016118 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 9 Jun 2010 12:25:40 -0700 (PDT) Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 9 Jun 2010 12:25:40 -0700 From: "Duke, Martin" To: Lars Eggert , "tcpm@ietf.org Extensions" Date: Wed, 9 Jun 2010 12:25:38 -0700 Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsH8N/0MaqoTcy+Q5CcdnXAnlnj8wAF06fQ Message-ID: References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> In-Reply-To: <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> 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 Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 19:25:41 -0000 Long overdue! Is the intent to eventually free up those TCP option numbers for future use= ?=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Lars Eggert > Sent: Wednesday, June 09, 2010 10:28 AM > To: tcpm@ietf.org Extensions > Subject: [tcpm] draft-eggert-tcpm-historicize-00 >=20 > Quite possibly the most boring RFC ever. But at least it's=20 > short. Comments welcome. >=20 > http://tools.ietf.org/html/draft-eggert-tcpm-historicize >=20 > Begin forwarded message: > > Filename: draft-eggert-tcpm-historicize > > Revision: 00 > > Title: Moving the Undeployed TCP Extensions=20 > RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263,=20 > RFC1379, RFC1644 and RFC1693 to Historic Status > > Creation_date: 2010-06-09 > > WG ID: Independent Submission > > Number_of_pages: 4 > >=20 > > Abstract: > > This document recommends that several TCP extensions that=20 > have never=20 > > seen widespread use be moved to Historic status. The affected RFCs=20 > > are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, > > RFC1644 and RFC1693. >=20 > Lars= From touch@isi.edu Wed Jun 9 12:28:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3263A685F for ; Wed, 9 Jun 2010 12:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdNP5QVjVS9d for ; Wed, 9 Jun 2010 12:28:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0BD973A67CF for ; Wed, 9 Jun 2010 12:28:34 -0700 (PDT) Received: from [75.214.122.201] (201.sub-75-214-122.myvzw.com [75.214.122.201]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o59JRO51025502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jun 2010 12:27:35 -0700 (PDT) Message-ID: <4C0FEB1C.8070006@isi.edu> Date: Wed, 09 Jun 2010 12:27:24 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Lars Eggert References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com> <8B364027-73E4-4C85-B879-7609E28A8B19@nokia.com> In-Reply-To: <8B364027-73E4-4C85-B879-7609E28A8B19@nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3ADF236A4CAFDC04759A2F14" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 19:28:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3ADF236A4CAFDC04759A2F14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > Hi, >=20 > On 2010-6-9, at 21:07, Anantha Ramaiah (ananth) wrote: >> FWIW, there is a recent proposal which talks about enhancing TCP >> checksums as well :- >> >> http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/ >> >> The above proposal tries to leverage on the TCP alternate checksum >> option. >=20 > I've skimmed through this draft when it first came out. I may be missin= g > something, but why isn't TLS the right solution here? Sure, it may be o= verkill, > but it's readily available. Hi, Lars, I don't know if they say it in detail, but: TLS doesn't protect TCP against errors which result in bad segments not b= eing retransmitted at the TCP layer; TLS secures, but does not retransmit lost= info (it's not a 'reliability' layer). Further, TLS would interpret a bad MAC = as an attack and would drop the connection, AFAICT (RFC 5246, see "bad_record_m= ac"). With large frames, TCP's checksum would allow false positives (bad segmen= ts would get sent to TLS), and TLS would fail. Joe --------------enig3ADF236A4CAFDC04759A2F14 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwP6xwACgkQE5f5cImnZruyvwCghMoPjcDe7CpA4QOd05pK1qb4 6joAn3qru56YvTxLIwJpxkcYtIY5N4da =KjVC -----END PGP SIGNATURE----- --------------enig3ADF236A4CAFDC04759A2F14-- From hagen@jauu.net Wed Jun 9 13:00:59 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C813A6781 for ; Wed, 9 Jun 2010 13:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ynz+MfdX7a7t for ; Wed, 9 Jun 2010 13:00:59 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id 01AF73A659B for ; Wed, 9 Jun 2010 13:00:58 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 02520F44129; Wed, 9 Jun 2010 22:00:59 +0200 (CEST) Date: Wed, 9 Jun 2010 22:00:53 +0200 From: Hagen Paul Pfeifer To: L.Wood@surrey.ac.uk Message-ID: <20100609200052.GB5338@nuttenaction> References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <07BF7B99-FF83-44E1-BF52-BED91ACA7F3A@surrey.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07BF7B99-FF83-44E1-BF52-BED91ACA7F3A@surrey.ac.uk> 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.20 (2009-06-14) Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 20:00:59 -0000 * L.Wood@surrey.ac.uk | 2010-06-09 20:15:09 [+0100]: >> TCP Alternate Checksum Options _can eventually_ useful in the future for >> example Interplanetary TCP. > >Unlikely. I read exactly the same number of papers where people analysed TCP and come to the conclusion that TCP is suitable at general but timers must be adjusted to meet the requirements, ok this statement is a little bit exaggerated, but I cannot resist to post it. ;-) Anyway, I don't want to start a debate if TCP is suitable for interplanetary communication. Be creative and think about another environments where TCP may be adequate but the user simple require a stronger checksum. My second example are therefore, attention: Sensor Networks. ;-) Lloyd, thank you for the in-deep elucidations! My point was and is why to move a itself not defective nor overhauled RFC to historic. But as Lars already pointed out that this does not affect already existing implementations I am fine with it. I am general fine with Lars postings, so consider it as a question, not a objection. ;-) Best regards, Hagen From L.Wood@surrey.ac.uk Wed Jun 9 13:13:37 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611BB3A67CF for ; Wed, 9 Jun 2010 13:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVRrbcGu9Zgh for ; Wed, 9 Jun 2010 13:13:36 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id D39623A67C1 for ; Wed, 9 Jun 2010 13:13:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-5.tower-78.messagelabs.com!1276114415!15665422!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 7468 invoked from network); 9 Jun 2010 20:13:36 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-5.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 9 Jun 2010 20:13:36 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Wed, 9 Jun 2010 21:13:35 +0100 From: To: Date: Wed, 9 Jun 2010 21:13:34 +0100 Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsIED0WjLsQ5bq0R0uNjgzLMlzIuQ== Message-ID: References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <07BF7B99-FF83-44E1-BF52-BED91ACA7F3A@surrey.ac.uk> <20100609200052.GB5338@nuttenaction> In-Reply-To: <20100609200052.GB5338@nuttenaction> Accept-Language: en-US, en-GB Content-Language: en-US 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, L.Wood@surrey.ac.uk Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 20:13:37 -0000 On 9 Jun 2010, at 21:00, Hagen Paul Pfeifer wrote: > * L.Wood@surrey.ac.uk | 2010-06-09 20:15:09 [+0100]: >=20 >>> TCP Alternate Checksum Options _can eventually_ useful in the future fo= r >>> example Interplanetary TCP. >>=20 >> Unlikely. >=20 > I read exactly the same number of papers where people analysed TCP and co= me to > the conclusion that TCP is suitable at general but timers must be adjuste= d to > meet the requirements I've read such papers. They tend not to discuss the initial SYN/ACK handsha= ke and the timer related to that (probably because their simulation tools defa= ult to not simulating SYN/ACK), or consider the implications of TCP slow start = with long propagation delays. > , ok this statement is a little bit exaggerated, but I > cannot resist to post it. ;-) Anyway, I don't want to start a debate if T= CP > is suitable for interplanetary communication. Be creative and think about > another environments where TCP may be adequate but the user simple requir= e a > stronger checksum. My second example are therefore, attention: Sensor > Networks. ;-) the sensor networks I'm familiar with use IP, but don't use TCP, for many of the same underlying reasons. http://sat-net.com/L.Wood/dtn/saratoga Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From hagen@jauu.net Wed Jun 9 13:33:27 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6062D3A67B3 for ; Wed, 9 Jun 2010 13:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4KdIYYFVwkY for ; Wed, 9 Jun 2010 13:33:23 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id A53283A67A5 for ; Wed, 9 Jun 2010 13:33:18 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 63201F44129; Wed, 9 Jun 2010 22:33:16 +0200 (CEST) Date: Wed, 9 Jun 2010 22:33:15 +0200 From: Hagen Paul Pfeifer To: L.Wood@surrey.ac.uk Message-ID: <20100609203315.GC5338@nuttenaction> References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <07BF7B99-FF83-44E1-BF52-BED91ACA7F3A@surrey.ac.uk> <20100609200052.GB5338@nuttenaction> 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.20 (2009-06-14) Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 20:33:27 -0000 * L.Wood@surrey.ac.uk | 2010-06-09 21:13:34 [+0100]: >I've read such papers. They tend not to discuss the initial SYN/ACK handshake >and the timer related to that (probably because their simulation tools default >to not simulating SYN/ACK), or consider the implications of TCP slow start with >long propagation delays. It is a little bit off-topic, but can you comment on the actual problems of the initial SYN/ACK handshake and the timer interplay? Linux for example use the same RTO timer for the initial handshake and the ongoing connection. If you tune the RTO timer you will also tune it for the initial three way handshake (this statement is not 100% sure, I hide some petite differences, but the effect is insignificant). Why differs the handshake so much in your eyes? And yes, don't trust any simulation models that you have fully developed by your own. ;-) >the sensor networks I'm familiar with use IP, but don't use TCP, for >many of the same underlying reasons. >http://sat-net.com/L.Wood/dtn/saratoga Yes, the characteristics and problems are nearly the same. The papers I read ("Making TCP/IP Viable for Wireless Sensor Networks", "Hop-by-Hop TCP for Sensor Networks", ...) are pure academic papers and I personally saw no sensor network TCP implementation in the wild. Hagen From alejandroacostaalamo@gmail.com Wed Jun 9 14:21:35 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72BB3A67F3 for ; Wed, 9 Jun 2010 14:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RsuYEZqgU8v for ; Wed, 9 Jun 2010 14:21:34 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 924E23A67FD for ; Wed, 9 Jun 2010 14:21:34 -0700 (PDT) Received: by gyh4 with SMTP id 4so4332163gyh.31 for ; Wed, 09 Jun 2010 14:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=x1PtRlrTZlCXiBVLuE0mFLOSqtviNBGPAbecn0ZxWgQ=; b=BudeS9yxjEKGYx+pnjbx2Uog2QDvc/l+Tlvh8J9ky4y13gDftwSj6yDDSjgVEffQSx C+rw5EUtFSdJSaBIpWF16kK8qHVo9HmjR3XuKLTRwPh9oziUDVs7rLXzaLQwgdvcCOrW je/OAjuu793JNHk5PW6IBW1MOlmd/DGgRM5BE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n1j1nDw9TPqh+pAeiepQ+fzJ3DpZShQhcz3gSpepJNmu4MvJ4XEprmGfvHNO/tTfNU CrwzS0d8Fu5Vrm+mgGHFJUM8Y88dUHWj/JfrCNRDQczmtfPbyLhtpY8pI1altNJ0UEMP iFQbMhDY6tg/eCqFniGOLgc6+ti4ny8R0lNhM= MIME-Version: 1.0 Received: by 10.91.180.3 with SMTP id h3mr542741agp.82.1276118493437; Wed, 09 Jun 2010 14:21:33 -0700 (PDT) Received: by 10.90.118.19 with HTTP; Wed, 9 Jun 2010 14:21:33 -0700 (PDT) In-Reply-To: <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com> References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com> Date: Wed, 9 Jun 2010 16:51:33 -0430 Message-ID: From: Alejandro Acosta To: "Anantha Ramaiah (ananth)" Content-Type: multipart/alternative; boundary=0016e64641267e20a004889f7d25 Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 21:21:36 -0000 --0016e64641267e20a004889f7d25 Content-Type: text/plain; charset=ISO-8859-1 +1 On Wed, Jun 9, 2010 at 1:37 PM, Anantha Ramaiah (ananth) wrote: > > +1 > > FWIW, there is a recent proposal which talks about enhancing TCP > checksums as well :- > > http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/ > > The above proposal tries to leverage on the TCP alternate checksum > option. My thinking it may be useful to have a "TCP generalized checksum > option" which can give the flexibility for a TCP stack to choose from a > set of checksum algorithms (of course the default stays what it is today > ;-) > > -Anantha > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf Of Hagen Paul Pfeifer > > Sent: Wednesday, June 09, 2010 10:36 AM > > To: Lars Eggert > > Cc: tcpm@ietf.org Extensions > > Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 > > > > * Lars Eggert | 2010-06-09 19:28:14 [+0300]: > > > > >Quite possibly the most boring RFC ever. But at least it's short. > > >Comments welcome. > > > > Lars, I thought about RFC 1145 "TCP Alternate Checksum > > Options", there are no real shortcomings in the RFC. It is > > not _widely_ deployed but there is no real security concern > > like say T/TCP. > > > > I thought only superseded or defective RFCs can be declared > > historic? I mean TCP Alternate Checksum Options _can > > eventually_ useful in the future for example Interplanetary > > TCP. Maybe some military sites already employ RFC 1145. > > > > HGN > > _______________________________________________ > > 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 > --0016e64641267e20a004889f7d25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On Wed, Jun 9, 2010 at 1:37 PM, Ananth= a Ramaiah (ananth) <ananth@cisco.com> wrote:

+1

FWIW, there is a recent proposal which talks about enhancing TCP
checksums as well :-

http://datatracker.ietf.org/doc/draft-anumita-tcpm= -stronger-checksum/

The above proposal tries to leverage on the TCP alternate checksum
option. My thinking it may be useful to have a "TCP generalized checks= um
option" which can give the flexibility for a TCP stack to choose from = a
set of checksum algorithms (of course the default stays what it is today ;-)

-Anantha

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On
> Behalf Of Hagen Paul Pfeifer
> Sent: Wednesday, June 09, 2010 10:36 AM
> To: Lars Eggert
> Cc: tcpm@ietf.org Extensions
> Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00
>
> * Lars Eggert | 2010-06-09 19:28:14 [+0300]:
>
> >Quite possibly the most boring RFC ever. But at least it's sho= rt.
> >Comments welcome.
>
> Lars, I thought about RFC 1145 "TCP Alternate Checksum
> Options", there are no real shortcomings in the RFC. It is
> not _widely_ deployed but there is no real security concern
> like say T/TCP.
>
> I thought only superseded or defective RFCs can be declared
> historic? I mean TCP Alternate Checksum Options _can
> eventually_ useful in the future for example Interplanetary
> TCP. Maybe some military sites already employ RFC 1145.
>
> HGN
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--0016e64641267e20a004889f7d25-- From ananth@cisco.com Wed Jun 9 15:59:01 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCF03A68DD for ; Wed, 9 Jun 2010 15:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.995 X-Spam-Level: X-Spam-Status: No, score=-9.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBcT91XUkAvR for ; Wed, 9 Jun 2010 15:59:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 27C2F3A68D5 for ; Wed, 9 Jun 2010 15:59:01 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABu5D0yrRN+J/2dsb2JhbACeXHGlP5oXhRgEg0mMPQ X-IronPort-AV: E=Sophos;i="4.53,394,1272844800"; d="scan'208";a="333686418" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 09 Jun 2010 22:59:03 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o59Mx3TG021041; Wed, 9 Jun 2010 22:59:03 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jun 2010 15:59:02 -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: Wed, 9 Jun 2010 15:59:01 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5809E5C58B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4C0FDBA0.7030500@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsIANVr/yHeQtWwTN+ABsRqntp/CAAJh25A References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com> <4C0FDBA0.7030500@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 09 Jun 2010 22:59:03.0125 (UTC) FILETIME=[5ADB2850:01CB0827] Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 22:59:01 -0000 =20 >=20 > The question is whether we need a "generalized" such option,=20 > or whether the current alternate checksum is basically=20 > sufficient, given a table of appropriate algorithms and=20 > algorithm IDs. There are already 253 available ID values left ;-) I agree, I was just stating in the context of the current proposal (Lars draft). If what we have already accommadates this situation, then we are good. -Anantha From rs@netapp.com Wed Jun 9 16:53:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5B63A695A for ; Wed, 9 Jun 2010 16:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqgttMms4YUN for ; Wed, 9 Jun 2010 16:53:55 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 707E53A691D for ; Wed, 9 Jun 2010 16:53:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,395,1272870000"; d="scan'208";a="171039230" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 09 Jun 2010 16:53:55 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o59Nr48p010310; Wed, 9 Jun 2010 16:53:19 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 00:53:04 +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, 10 Jun 2010 00:53:03 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A08F65D8B@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4C0FEB1C.8070006@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-anumita-tcpm-stronger-checksum Thread-Index: AcsICfwuTcvIlT2/R4Weh1kzJLrm2wAGuFaw References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com><8B364027-73E4-4C85-B879-7609E28A8B19@nokia.com> <4C0FEB1C.8070006@isi.edu> From: "Scheffenegger, Richard" To: "Joe Touch" , "Lars Eggert" X-OriginalArrivalTime: 09 Jun 2010 23:53:04.0086 (UTC) FILETIME=[E69E8F60:01CB082E] Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 23:53:57 -0000 To further this discussion: I believe the suggestion using Alternate Checksum Option has the highest merits: O) no new tcp option number would be needed O) only an additional checksum option type would need to be defined (and there are still plenty left; I found no evidence so far, that any other value than 0 and 1 were ever used - scanning though the I-D archives). To make this proposal compatible with existing middleboxes, which might not understand the option, but choose to simply forward it, my suggestion would be to *NOT* include the TCP pseudo-header in that alternate checksum, but *only* cover the data section. This would make it also possible to traverse NAT/PAT gateways, which are agnostic to this option. Furthermore, as Koopman has demonstrated, the Hamming distance is a function of data bits covered - the fewer bits covered, the higher the HD. Also, As TCP CRC-32 can detect *every* corruption affecting an uneven number of bits, yet another CRC-32 could be choosen that works especially well only for even bit corruptions... The combination of CRC-32 + "CRC-32E" might have even better compound properties than CRC-32C. However, the drawback would be to do two calculations (one for the standard TCP CRC-32, and one for CRC-32C covering only the data portion). Also, to stay with Alternate Checksum semantics, if that option is negotiated once, it should be kept for the remainder of the session - even if PMTUD / BH decide to start sending only small (MTU<=3D1500) packets at some point. Further, I have spent some time looking for research on the effectiveness of SACK - as this option would reduce the typical number of SACK fields from a maximum of 3 down to 2. But from what I learned, it seems that the number of SACK fields in an ACK have the property of diminishing returns. You gain a lot from the 1st field; somewhat from the 2nd, a bit from the 3rd, and having a 4th is surplus :). Besides, if that option would only be valid for data-carrying segments, it could be omitted if no data is to be carried - but still kept in "enabled" mode instead of disabling. Other than that, only a few nit-picks in wording and definitions (can be addressed in a later version). Richard Scheffenegger > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu]=20 > Sent: Mittwoch, 9. Juni 2010 21:27 > To: Lars Eggert > Cc: tcpm@ietf.org; Anantha Ramaiah (ananth) > Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum >=20 >=20 >=20 > Lars Eggert wrote: > > Hi, > >=20 > > On 2010-6-9, at 21:07, Anantha Ramaiah (ananth) wrote: > >> FWIW, there is a recent proposal which talks about enhancing TCP=20 > >> checksums as well :- > >> > >>=20 > http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/ > >> > >> The above proposal tries to leverage on the TCP alternate checksum=20 > >> option. > >=20 > > I've skimmed through this draft when it first came out. I may be=20 > > missing something, but why isn't TLS the right solution=20 > here? Sure, it=20 > > may be overkill, but it's readily available. >=20 > Hi, Lars, >=20 > I don't know if they say it in detail, but: >=20 > TLS doesn't protect TCP against errors which result in bad=20 > segments not being retransmitted at the TCP layer; TLS=20 > secures, but does not retransmit lost info (it's not a=20 > 'reliability' layer). Further, TLS would interpret a bad MAC=20 > as an attack and would drop the connection, AFAICT (RFC 5246,=20 > see "bad_record_mac"). > With large frames, TCP's checksum would allow false positives=20 > (bad segments would get sent to TLS), and TLS would fail. >=20 > Joe >=20 >=20 >=20 From touch@isi.edu Wed Jun 9 17:46:54 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33633A69AC for ; Wed, 9 Jun 2010 17:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcAc7WqCkLZN for ; Wed, 9 Jun 2010 17:46:54 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id E5D8C3A6857 for ; Wed, 9 Jun 2010 17:46:53 -0700 (PDT) Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5A0jdOf014359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jun 2010 17:45:49 -0700 (PDT) Message-ID: <4C1035B2.7020502@isi.edu> Date: Wed, 09 Jun 2010 17:45:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com><8B364027-73E4-4C85-B879-7609E28A8B19@nokia.com> <4C0FEB1C.8070006@isi.edu> <5FDC413D5FA246468C200652D63E627A08F65D8B@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A08F65D8B@LDCMVEXC1-PRD.hq.netapp.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3C6B786E66637220B19FA221" X-MailScanner-ID: o5A0jdOf014359 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 00:46:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3C6B786E66637220B19FA221 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Some notes below... Scheffenegger, Richard wrote: > To further this discussion: >=20 > I believe the suggestion using Alternate Checksum Option has the highes= t > merits: >=20 > O) no new tcp option number would be needed > O) only an additional checksum option type would need to be defined (an= d > there are still plenty left; I found no evidence so far, that any other= > value than 0 and 1 were ever used - scanning though the I-D archives). >=20 > To make this proposal compatible with existing middleboxes, which might= > not understand the option, but choose to simply forward it, my > suggestion would be to *NOT* include the TCP pseudo-header in that > alternate checksum, but *only* cover the data section. This would make > it also possible to traverse NAT/PAT gateways, which are agnostic to > this option. Middleboxes will be a problem no matter what you do. Some will drop the segment simply because it has an option they don't und= erstand. Some will drop the option, which will result in drops at the receiver. Many (most) will try to validate the TCP checksum, which is zero or conta= ins part of the alternate checksum when the alternate checksum is present, so= they'll drop the segment in that case. As a result, it's not particularly useful to tailor this option to work t= hrough middleboxes. Further, RFC 1146 defines the option to work over the same fields as the = TCP checksum; I don't think it would be appropriate to use that option with m= erely a different algorithm and redefine the bits covered. Finally, if the TCP header isn't protected, it's no longer a TCP checksum= - it's a data checksum, at which point TLS is probably more appropriate. I don't think the other suggestions (two checksums, issues of how many bi= ts are covered, etc.) are important. If the above doesn't work, the rest is moot= anyway. Joe --------------enig3C6B786E66637220B19FA221 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwQNbIACgkQE5f5cImnZrtHjwCg7cNxqfssMVsO6Zyq58EPt+nJ mnoAoPVllHS9yov7xhIMZGt9XTYpMfi3 =f0Df -----END PGP SIGNATURE----- --------------enig3C6B786E66637220B19FA221-- From L.Wood@surrey.ac.uk Wed Jun 9 23:45:21 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487C93A68C2 for ; Wed, 9 Jun 2010 23:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.345 X-Spam-Level: X-Spam-Status: No, score=-5.345 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAygazjhzbFR for ; Wed, 9 Jun 2010 23:45:19 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id 20D9A3A68BF for ; Wed, 9 Jun 2010 23:45:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-8.tower-78.messagelabs.com!1276152311!15741467!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 3409 invoked from network); 10 Jun 2010 06:45:11 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-8.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 10 Jun 2010 06:45:11 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Thu, 10 Jun 2010 07:45:11 +0100 From: To: Date: Thu, 10 Jun 2010 07:45:09 +0100 Thread-Topic: [tcpm] draft-anumita-tcpm-stronger-checksum Thread-Index: AcsIaHhWb4bv3nZITemc77O4ny0xNg== Message-ID: References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com><8B364027-73E4-4C85-B879-7609E28A8B19@nokia.com> <4C0FEB1C.8070006@isi.edu> <5FDC413D5FA246468C200652D63E627A08F65D8B@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A08F65D8B@LDCMVEXC1-PRD.hq.netapp.com> Accept-Language: en-US, en-GB Content-Language: en-US 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, ananth@cisco.com, L.Wood@surrey.ac.uk, touch@isi.edu Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 06:45:21 -0000 On 10 Jun 2010, at 00:53, Scheffenegger, Richard wrote: >=20 > Further, I have spent some time looking for research on the > effectiveness of SACK - as this option would reduce the typical number > of SACK fields from a maximum of 3 down to 2. But from what I learned, > it seems that the number of SACK fields in an ACK have the property of > diminishing returns. You gain a lot from the 1st field; somewhat from > the 2nd, a bit from the 3rd, and having a 4th is surplus :). That's probably because TCP's dupack threshold is three, after which fast recovery is invoked. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From L.Wood@surrey.ac.uk Thu Jun 10 02:39:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BBB3A6930 for ; Thu, 10 Jun 2010 02:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.834 X-Spam-Level: X-Spam-Status: No, score=-4.834 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLuJwzC9SkaS for ; Thu, 10 Jun 2010 02:39:56 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 04D9A3A63CA for ; Thu, 10 Jun 2010 02:39:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-9.tower-82.messagelabs.com!1276162796!640212!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 27361 invoked from network); 10 Jun 2010 09:39:56 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-9.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 10 Jun 2010 09:39:56 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Thu, 10 Jun 2010 10:39:56 +0100 From: To: Date: Thu, 10 Jun 2010 10:39:54 +0100 Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsIEv4GZuotJVlZSyGzdbxpOR8VkwAbdRTA Message-ID: References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <07BF7B99-FF83-44E1-BF52-BED91ACA7F3A@surrey.ac.uk> <20100609200052.GB5338@nuttenaction> <20100609203315.GC5338@nuttenaction> In-Reply-To: <20100609203315.GC5338@nuttenaction> Accept-Language: en-US, en-GB Content-Language: en-US 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] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 09:39:57 -0000 =20 See section IIc of our protocol radius paper. -----Original Message----- From: Hagen Paul Pfeifer [mailto:hagen@jauu.net]=20 Sent: 09 June 2010 21:33 To: Wood L Dr (Electronic Eng) Cc: lars.eggert@nokia.com; tcpm@ietf.org Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 Importance: High * L.Wood@surrey.ac.uk | 2010-06-09 21:13:34 [+0100]: >I've read such papers. They tend not to discuss the initial SYN/ACK=20 >handshake and the timer related to that (probably because their=20 >simulation tools default to not simulating SYN/ACK), or consider the=20 >implications of TCP slow start with long propagation delays. It is a little bit off-topic, but can you comment on the actual problems of= the initial SYN/ACK handshake and the timer interplay? Linux for example u= se the same RTO timer for the initial handshake and the ongoing connection.= If you tune the RTO timer you will also tune it for the initial three way = handshake (this statement is not 100% sure, I hide some petite differences,= but the effect is insignificant). Why differs the handshake so much in you= r eyes? And yes, don't trust any simulation models that you have fully deve= loped by your own. ;-) From rs@netapp.com Thu Jun 10 02:41:22 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B9F3A63CA for ; Thu, 10 Jun 2010 02:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWwfIXHSdBoD for ; Thu, 10 Jun 2010 02:41:21 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 3AFC03A6929 for ; Thu, 10 Jun 2010 02:41:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,397,1272870000"; d="scan'208";a="171232418" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 10 Jun 2010 02:41:21 -0700 Received: from amsrsexc1-prd.hq.netapp.com (amsrsexc1-prd.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o5A9dQGC028260; Thu, 10 Jun 2010 02:40:39 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 11:39:43 +0200 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, 10 Jun 2010 10:39:42 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A08F65F39@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-anumita-tcpm-stronger-checksum Thread-Index: AcsIaHhWb4bv3nZITemc77O4ny0xNgAF08xw References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com><8B364027-73E4-4C85-B879-7609E28A8B19@nokia.com> <4C0FEB1C.8070006@isi.edu> <5FDC413D5FA246468C200652D63E627A08F65D8B@LDCMVEXC1-PRD.hq.netapp.com> From: "Scheffenegger, Richard" To: X-OriginalArrivalTime: 10 Jun 2010 09:39:43.0639 (UTC) FILETIME=[DB301A70:01CB0880] Cc: tcpm@ietf.org, ananth@cisco.com, touch@isi.edu Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 09:41:22 -0000 My understanding was, that it has more to do with the reliability of your back channel (ACK/SACK dropped on their way to the receiver). But SACK is not required to have "perfect" state shared between receiver and sender; if multiple consecutive SACKs are dropped, and due to the lower number of SACK fields some of that info never comes to the sender, it might unnecessarily retransmit segments, which the receiver did in fact already receive properly. Just an edge issue, really, causing behaviour more like Reno (non-SACK) retransmissions. But even having just one SACK field should already serve to conserve much bandwidth (and responsiveness, as fewer RTTs are necessary to re-send all missing data) over NewReno. Richard Scheffenegger =20 > -----Original Message----- > From: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk]=20 > Sent: Donnerstag, 10. Juni 2010 08:45 > To: Scheffenegger, Richard > Cc: L.Wood@surrey.ac.uk; touch@isi.edu;=20 > lars.eggert@nokia.com; tcpm@ietf.org; ananth@cisco.com > Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum >=20 >=20 > On 10 Jun 2010, at 00:53, Scheffenegger, Richard wrote: > >=20 > > Further, I have spent some time looking for research on the=20 > > effectiveness of SACK - as this option would reduce the=20 > typical number=20 > > of SACK fields from a maximum of 3 down to 2. But from what=20 > I learned,=20 > > it seems that the number of SACK fields in an ACK have the=20 > property of=20 > > diminishing returns. You gain a lot from the 1st field;=20 > somewhat from=20 > > the 2nd, a bit from the 3rd, and having a 4th is surplus :). >=20 > That's probably because TCP's dupack threshold is three,=20 > after which fast recovery is invoked. >=20 > Lloyd Wood > L.Wood@surrey.ac.uk > http://sat-net.com/L.Wood >=20 >=20 >=20 >=20 From rs@netapp.com Thu Jun 10 02:53:47 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A262D3A6939 for ; Thu, 10 Jun 2010 02:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.742 X-Spam-Level: X-Spam-Status: No, score=-4.742 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YyB9tLip6m3 for ; Thu, 10 Jun 2010 02:53:46 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 4C6B83A69FB for ; Thu, 10 Jun 2010 02:53:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,397,1272870000"; d="scan'208";a="160467484" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 10 Jun 2010 02:53:42 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o5A9q90R029976; Thu, 10 Jun 2010 02:53:06 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 10:52:28 +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, 10 Jun 2010 10:52:27 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A08F65F56@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4C1035B2.7020502@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-anumita-tcpm-stronger-checksum Thread-Index: AcsINqcWi7HEDNWTRp+2J6IlXJSSAwASjW+A References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com><8B364027-73E4-4C85-B879-7609E28A8B19@nokia.com> <4C0FEB1C.8070006@isi.edu> <5FDC413D5FA246468C200652D63E627A08F65D8B@LDCMVEXC1-PRD.hq.netapp.com> <4C1035B2.7020502@isi.edu> From: "Scheffenegger, Richard" To: "Joe Touch" X-OriginalArrivalTime: 10 Jun 2010 09:52:28.0533 (UTC) FILETIME=[A319AA50:01CB0882] Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 09:53:47 -0000 Hi Joe, I think you mentioned that a checksum violation in TLS will cause the connection to be aborted - rather than the corrupted packet to be resent... If keeping the standard TCP CRC intact (and covering TCP header & data) and having an RFC1146 alternate checksum that works differently than defined therein, perhaps it would be better to make it a new TCP option then. During handshake, the CRC-32C capable sender would need to do the proper think (retry one or two times with all options, and then retry with the minimum options); For agnostic middleboxes (and NAT/PAT routers currently deployed), not covering the pseudo-header seems to me to be the only option, to make this feature work with existing gear...=20 Again, if the group feels that this is better not called "Alternative Checksum" (re-using preexisting TCP options), but rather "TCP Stronger Data Checksum", that's fine :). The key is to keep the TCP state and retransmission behaviour intact, as re-negotiating a new, TLS-protected TCP stream after corruption might not be good enough these days (too high latency impact).=20 As there exist HW that implements SCTP checksum offloading (as well as segmentation) nowadays, new appliactions could probably make use of that. However, applications would have to revert back to TCP (with small segments), if the other side wouldn't support SCTP. Richard Scheffenegger =20 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu]=20 > Sent: Donnerstag, 10. Juni 2010 02:46 > To: Scheffenegger, Richard > Cc: Lars Eggert; tcpm@ietf.org; Anantha Ramaiah (ananth) > Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum >=20 > Some notes below... >=20 > Scheffenegger, Richard wrote: > > To further this discussion: > >=20 > > I believe the suggestion using Alternate Checksum Option has the=20 > > highest > > merits: > >=20 > > O) no new tcp option number would be needed > > O) only an additional checksum option type would need to be defined=20 > > (and there are still plenty left; I found no evidence so=20 > far, that any=20 > > other value than 0 and 1 were ever used - scanning though=20 > the I-D archives). > >=20 > > To make this proposal compatible with existing middleboxes, which=20 > > might not understand the option, but choose to simply=20 > forward it, my=20 > > suggestion would be to *NOT* include the TCP pseudo-header in that=20 > > alternate checksum, but *only* cover the data section. This=20 > would make=20 > > it also possible to traverse NAT/PAT gateways, which are=20 > agnostic to=20 > > this option. >=20 > Middleboxes will be a problem no matter what you do. >=20 > Some will drop the segment simply because it has an option=20 > they don't understand. >=20 > Some will drop the option, which will result in drops at the receiver. >=20 > Many (most) will try to validate the TCP checksum, which is=20 > zero or contains part of the alternate checksum when the=20 > alternate checksum is present, so they'll drop the segment in=20 > that case. >=20 > As a result, it's not particularly useful to tailor this=20 > option to work through middleboxes. >=20 > Further, RFC 1146 defines the option to work over the same=20 > fields as the TCP checksum; I don't think it would be=20 > appropriate to use that option with merely a different=20 > algorithm and redefine the bits covered. >=20 > Finally, if the TCP header isn't protected, it's no longer a=20 > TCP checksum - it's a data checksum, at which point TLS is=20 > probably more appropriate. >=20 > I don't think the other suggestions (two checksums, issues of=20 > how many bits are covered, etc.) are important. If the above=20 > doesn't work, the rest is moot anyway. >=20 > Joe >=20 >=20 From touch@isi.edu Thu Jun 10 06:55:22 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED933A6A24 for ; Thu, 10 Jun 2010 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oYd-GnXdWqV for ; Thu, 10 Jun 2010 06:55:21 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 46DCA3A6A21 for ; Thu, 10 Jun 2010 06:55:21 -0700 (PDT) Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5ADraXD023142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Jun 2010 06:53:46 -0700 (PDT) Message-ID: <4C10EE60.4010402@isi.edu> Date: Thu, 10 Jun 2010 06:53:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <0C53DCFB700D144284A584F54711EC5809E5C397@xmb-sjc-21c.amer.cisco.com><8B364027-73E4-4C85-B879-7609E28A8B19@nokia.com> <4C0FEB1C.8070006@isi.edu> <5FDC413D5FA246468C200652D63E627A08F65D8B@LDCMVEXC1-PRD.hq.netapp.com> <4C1035B2.7020502@isi.edu> <5FDC413D5FA246468C200652D63E627A08F65F56@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A08F65F56@LDCMVEXC1-PRD.hq.netapp.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig132704103174654E8F49576C" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 13:55:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig132704103174654E8F49576C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Richard, Scheffenegger, Richard wrote: > Hi Joe, >=20 > I think you mentioned that a checksum violation in TLS will cause the > connection to be aborted - rather than the corrupted packet to be > resent... Yes - TLS operates at the application layer, not in conjunction with TCP.= > If keeping the standard TCP CRC intact (and covering TCP header & data)= > and having an RFC1146 alternate checksum that works differently than > defined therein, perhaps it would be better to make it a new TCP option= > then. Defined therein where? The alternate checksum isn't TLS; TLS is an application-layer security protocol. > During handshake, the CRC-32C capable sender would need to do the prope= r > think (retry one or two times with all options, and then retry with the= > minimum options); For agnostic middleboxes (and NAT/PAT routers > currently deployed), not covering the pseudo-header seems to me to be > the only option, to make this feature work with existing gear...=20 RFC1146 defines a handshake behavior, during which only a short label is exchanged and confirmed, and the conventional TCP checksum is used. This = is more appropriate for TCP; options in the SYN should not render the rest of the= SYN unintelligible to parties that don't support the option. As to retry with or without options, that is not typically defined at the= level of a TCP option. That too is application behavior - i.e., to try to open = a TCP connection with certain parameters, and to try a different attempt if the= first fails. Having an option redefine core TCP protocol behavior (such as time= outs, retries, etc.) seems more than just an option. Options should extend, not= redefine, that core behavior. =2E.. > As there exist HW that implements SCTP checksum offloading (as well as > segmentation) nowadays, new appliactions could probably make use of > that. However, applications would have to revert back to TCP (with smal= l > segments), if the other side wouldn't support SCTP. Yes. But that's what you've described above when the TCP handshake fails = - i.e., that's no different. It's worth thinking further about that, as a result.= Joe --------------enig132704103174654E8F49576C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwQ7mAACgkQE5f5cImnZrsiiQCggMGiHpbYXhhr9iSBV8aLiv6o HMsAoKVGK50Xj0ZczPhnKWsJ92GfMGOk =yLN7 -----END PGP SIGNATURE----- --------------enig132704103174654E8F49576C-- From Anumita.Biswas@netapp.com Thu Jun 10 11:36:22 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EEF53A69A2 for ; Thu, 10 Jun 2010 11:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkkAt1MS2uFV for ; Thu, 10 Jun 2010 11:35:32 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 76D513A6A2F for ; Thu, 10 Jun 2010 11:32:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,399,1272870000"; d="scan'208";a="379345638" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 10 Jun 2010 11:31:45 -0700 Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o5AIVdsr020490; Thu, 10 Jun 2010 11:31:45 -0700 (PDT) Received: from SACMVEXC2-PRD.hq.netapp.com ([10.99.115.18]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 11:31: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: Thu, 10 Jun 2010 11:31:30 -0700 Message-ID: In-Reply-To: <4C1035B2.7020502@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-anumita-tcpm-stronger-checksum Thread-Index: AcsINonUEPEgOZW3R5uRPKiO1O+evAAkKYKg From: "Biswas, Anumita" To: "Joe Touch" , "Scheffenegger, Richard" X-OriginalArrivalTime: 10 Jun 2010 18:31:42.0715 (UTC) FILETIME=[2C7094B0:01CB08CB] Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 18:36:22 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu]=20 > Sent: Wednesday, June 09, 2010 5:46 PM > To: Scheffenegger, Richard > Cc: tcpm@ietf.org; Anantha Ramaiah (ananth) > Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum >=20 >=20 > Some notes below... >=20 > Scheffenegger, Richard wrote: > > To further this discussion: > >=20 > > I believe the suggestion using Alternate Checksum Option has the=20 > > highest > > merits: > >=20 > > O) no new tcp option number would be needed > > O) only an additional checksum option type would need to be defined=20 > > (and there are still plenty left; I found no evidence so=20 > far, that any=20 > > other value than 0 and 1 were ever used - scanning though the I-D=20 > > archives). > >=20 > > To make this proposal compatible with existing middleboxes, which=20 > > might not understand the option, but choose to simply=20 > forward it, my=20 > > suggestion would be to *NOT* include the TCP pseudo-header in that=20 > > alternate checksum, but *only* cover the data section. This=20 > would make=20 > > it also possible to traverse NAT/PAT gateways, which are=20 > agnostic to=20 > > this option. >=20 > Middleboxes will be a problem no matter what you do. >=20 If middleboxes are not RFC compliant, then yes. > Some will drop the segment simply because it has an option=20 > they don't understand. >=20 I guess our goal is not to solve the problem for workaround middleboxes that do not follow RFC 1122 interoperability mandate in 4.2.2.5.=20 I am more worried about the bigger problem of losing data integrity for packet MTUs greater than 1500. Today we are storing peta bytes of data in a single storage bin. Imagine copying peta bytes of data over the network to that bin. The likelihood of bit errors going undetected just increased probably by many magnitudes.=20 The other day I was listening to someone from probably the most largest software company talk about copying data over the network and seeing bit corruptions going unnoticed. Bit corruptions will go unnoticed when you send a large amount of data on the wire. This Internet Draft is just a small beginning in improving the rate of error detection.=20 Also, the cost of costly cryptographic operations have to be weighed against simpler CRC checksum algorithms that are already offloaded to modern NICs for SCTP. If we standardize the CRC-32C for TCP, then NIC vendors can offload them to newer versions of NICs and we get rid of the in-software computations. > Some will drop the option, which will result in drops at the receiver. >=20 > Many (most) will try to validate the TCP checksum, which is=20 > zero or contains part of the alternate checksum when the=20 > alternate checksum is present, so they'll drop the segment in=20 > that case. >=20 > As a result, it's not particularly useful to tailor this=20 > option to work through middleboxes. >=20 > Further, RFC 1146 defines the option to work over the same=20 > fields as the TCP checksum; I don't think it would be=20 > appropriate to use that option with merely a different=20 > algorithm and redefine the bits covered. > Agreed.=20 =20 > Finally, if the TCP header isn't protected, it's no longer a=20 > TCP checksum - it's a data checksum, at which point TLS is=20 > probably more appropriate. >=20 Based on comments I received from Richard Scheffenegger offline, we have to continue to put in the summation based 16-bit checksum in the TCP header so that we don't break the existing standard of what the TCP checksum is expected to be.=20 However, I am a bit skeptical about the comment that the 16-bit summation based checksum is adequate to pass off as protecting the TCP header. In theory it does protect the TCP header, but in practice, when the checksum spans MTU sizes larger than 1500 bytes, it is not going to catch the random bit flip in the sequence number, ack number etc. Instead, the draft proposes a stronger tcp checksum =20 The draft also only debates over whether the psuedoheader must be added to the TCP checksum. But it states that the TCP header + Data must be included in the CRC 32C checksum. Again, these are details that can be worked out if the WG thinks that this draft is worth taking up by the WG for further consideration.=20 > I don't think the other suggestions (two checksums, issues of=20 > how many bits are covered, etc.) are important. If the above=20 > doesn't work, the rest is moot anyway. >=20 > Joe >=20 >=20 From Anumita.Biswas@netapp.com Thu Jun 10 11:36:47 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3810328C162 for ; Thu, 10 Jun 2010 11:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB6LcpUFj7PK for ; Thu, 10 Jun 2010 11:36:46 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id CFE4728C12A for ; Thu, 10 Jun 2010 11:36:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,399,1272870000"; d="scan'208";a="379347625" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 10 Jun 2010 11:35:56 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o5AIZlg2023298; Thu, 10 Jun 2010 11:35:56 -0700 (PDT) Received: from SACMVEXC2-PRD.hq.netapp.com ([10.99.115.18]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 11:35:47 -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: Thu, 10 Jun 2010 11:35:20 -0700 Message-ID: In-Reply-To: <4C10EE60.4010402@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-anumita-tcpm-stronger-checksum Thread-Index: AcsIpKDbUcjCAATNTAK2WmplBcpLrAAJsZSQ From: "Biswas, Anumita" To: "Joe Touch" , "Scheffenegger, Richard" X-OriginalArrivalTime: 10 Jun 2010 18:35:47.0248 (UTC) FILETIME=[BE315B00:01CB08CB] Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 18:36:47 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu]=20 > Sent: Thursday, June 10, 2010 6:54 AM > To: Scheffenegger, Richard > Cc: tcpm@ietf.org; Anantha Ramaiah (ananth) > Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum >=20 >=20 > Hi, Richard, >=20 > Scheffenegger, Richard wrote: > > Hi Joe, > >=20 > > I think you mentioned that a checksum violation in TLS will=20 > cause the=20 > > connection to be aborted - rather than the corrupted packet to be=20 > > resent... >=20 > Yes - TLS operates at the application layer, not in=20 > conjunction with TCP. >=20 > > If keeping the standard TCP CRC intact (and covering TCP header &=20 > > data) and having an RFC1146 alternate checksum that works=20 > differently=20 > > than defined therein, perhaps it would be better to make it=20 > a new TCP=20 > > option then. >=20 > Defined therein where?=20 http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/ Section 3 - "Negotiating the use of CRC 32C" The alternate checksum isn't TLS; TLS=20 > is an application-layer security protocol. >=20 > > During handshake, the CRC-32C capable sender would need to do the=20 > > proper think (retry one or two times with all options, and=20 > then retry=20 > > with the minimum options); For agnostic middleboxes (and NAT/PAT=20 > > routers currently deployed), not covering the pseudo-header=20 > seems to=20 > > me to be the only option, to make this feature work with existing=20 > > gear... >=20 > RFC1146 defines a handshake behavior, during which only a=20 > short label is exchanged and confirmed, and the conventional=20 > TCP checksum is used. This is more appropriate for TCP;=20 > options in the SYN should not render the rest of the SYN=20 > unintelligible to parties that don't support the option. >=20 > As to retry with or without options, that is not typically=20 > defined at the level of a TCP option. That too is application=20 > behavior - i.e., to try to open a TCP connection with certain=20 > parameters, and to try a different attempt if the first=20 > fails. Having an option redefine core TCP protocol behavior=20 > (such as timeouts, retries, etc.) seems more than just an=20 > option. Options should extend, not redefine, that core behavior. >=20 > ... > > As there exist HW that implements SCTP checksum offloading=20 > (as well as > > segmentation) nowadays, new appliactions could probably make use of=20 > > that. However, applications would have to revert back to TCP (with=20 > > small segments), if the other side wouldn't support SCTP. >=20 > Yes. But that's what you've described above when the TCP=20 > handshake fails - i.e., that's no different. It's worth=20 > thinking further about that, as a result. >=20 > Joe >=20 >=20 From touch@isi.edu Thu Jun 10 14:16:37 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD35B3A69A6 for ; Thu, 10 Jun 2010 14:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gT6wVmaiANE for ; Thu, 10 Jun 2010 14:16:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A9C4D3A69A3 for ; Thu, 10 Jun 2010 14:16:36 -0700 (PDT) Received: from [75.213.115.189] (189.sub-75-213-115.myvzw.com [75.213.115.189]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5ALFGo3015830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Jun 2010 14:15:27 -0700 (PDT) Message-ID: <4C1155E4.7030202@isi.edu> Date: Thu, 10 Jun 2010 14:15:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Biswas, Anumita" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig37A943528304B6AB9F7A32DE" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 21:16:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig37A943528304B6AB9F7A32DE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Anumita, Biswas, Anumita wrote: >=20 >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu]=20 >> Sent: Wednesday, June 09, 2010 5:46 PM >> To: Scheffenegger, Richard >> Cc: tcpm@ietf.org; Anantha Ramaiah (ananth) >> Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum >> >> >> Some notes below... >> >> Scheffenegger, Richard wrote: >>> To further this discussion: >>> >>> I believe the suggestion using Alternate Checksum Option has the=20 >>> highest >>> merits: >>> >>> O) no new tcp option number would be needed >>> O) only an additional checksum option type would need to be defined=20 >>> (and there are still plenty left; I found no evidence so=20 >> far, that any=20 >>> other value than 0 and 1 were ever used - scanning though the I-D=20 >>> archives). >>> >>> To make this proposal compatible with existing middleboxes, which=20 >>> might not understand the option, but choose to simply=20 >> forward it, my=20 >>> suggestion would be to *NOT* include the TCP pseudo-header in that=20 >>> alternate checksum, but *only* cover the data section. This=20 >> would make=20 >>> it also possible to traverse NAT/PAT gateways, which are=20 >> agnostic to=20 >>> this option. >> Middleboxes will be a problem no matter what you do. >> > If middleboxes are not RFC compliant, then yes. I don't know what that means, FWIW. NATs by their very definition violate= RFC 1122 and 1812, but we don't need to rehash that here. My view is that it'= s not sensical to talk about "laws for the lawless", and AFAICT most middleboxe= s *want* to violate the standards. >> Some will drop the segment simply because it has an option=20 >> they don't understand. > > I guess our goal is not to solve the problem for workaround middleboxes= > that do not follow RFC 1122 interoperability mandate in 4.2.2.5.=20 This is an issue more with, e.g., RFC 1812. The middlebox isn't an endpoi= nt, so it has no business caring about or modifying such options. RFC 1122 is on= ly about endpoints. However, my point is that this is the common behavior of many middleboxes= , AFAICT. Ignoring that is saying "we don't expect it to work at all anyway= =2E" > I am more worried about the bigger problem of losing data integrity for= > packet MTUs greater than 1500. Today we are storing peta bytes of data > in a single storage bin. Imagine copying peta bytes of data over the > network to that bin. The likelihood of bit errors going undetected just= > increased probably by many magnitudes.=20 There are two separate issues: 1- integrity of the data 2- coordinating that integrity with TCP TLS gets you #1, if you deal with retries at the application layer (you n= eed to write your own "file transfer over TLS" protocol. #2 - which is better, AFAICT, since TCP will do the retries - can be achi= eved various ways with existing protocols using any other IP encapsulation tha= t provides similar strength, e.g., using IPsec or SEAL E2E. That would ensu= re bad segments would be dropped before TCP processing, and then TCP's retransmi= ssion would fix the hole. Another trick is to build a wrapper on some other system, e.g., using Jav= a and FTP. FTP the files, use Java to do a local stronger whole-file check, and= resend if the check fails. So although I appreciate the problem, it's not at all clear TCP is the appropriate or easiest place to fix it, IMO. =2E.. >> Finally, if the TCP header isn't protected, it's no longer a=20 >> TCP checksum - it's a data checksum, at which point TLS is=20 >> probably more appropriate. >> > Based on comments I received from Richard Scheffenegger offline, we hav= e > to continue to put in the summation based 16-bit checksum in the TCP > header so that we don't break the existing standard of what the TCP > checksum is expected to be.=20 You can't do this without redefining RFC 1146 - i.e., that's not RFC 1145= anymore. That may be OK, but that's a limit of this approach. > However, I am a bit skeptical about the comment that the 16-bit > summation based checksum is adequate to pass off as protecting the TCP > header. In theory it does protect the TCP header, but in practice, when= > the checksum spans MTU sizes larger than 1500 bytes, it is not going to= > catch the random bit flip in the sequence number, ack number etc. > Instead, the draft proposes a stronger tcp checksum =20 A single random bit flip will be caught by the TCP checksum; it's certain= patterns of multiple flips that won't. > The draft also only debates over whether the psuedoheader must be added= > to the TCP checksum. But it states that the TCP header + Data must be > included in the CRC 32C checksum. FWIW, the TCP header *includes* the IP pseudoheader. It's an artifact of = how TCP and IP were split that the info isn't copied into the TCP header. The onl= y way around that is to have some other crypto state shared at the endpoints th= at identifies the connection - e.g., this is why I suggested we could drop s= ome of the pseudoheader for TCP-AO support over NATs (draft-touch-tcp-ao-nat). > Again, these are details that can be worked out if the WG thinks that > this draft is worth taking up by the WG for further consideration. I think what you're hearing (the WG chairs can correct me if not) is that= some of these details may need working out in order to make that decision. Joe --------------enig37A943528304B6AB9F7A32DE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwRVeQACgkQE5f5cImnZrsl1ACeKYA5RUSz8sWn4OM4J3kr50Io 7hcAoLylYg/bSf1fauyGMEcxOj9R2VYe =3pCA -----END PGP SIGNATURE----- --------------enig37A943528304B6AB9F7A32DE-- From touch@isi.edu Thu Jun 10 14:21:46 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D563A69AA for ; Thu, 10 Jun 2010 14:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCJFAbR3RN7O for ; Thu, 10 Jun 2010 14:21:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 22C8E3A69A3 for ; Thu, 10 Jun 2010 14:21:44 -0700 (PDT) Received: from [75.213.115.189] (189.sub-75-213-115.myvzw.com [75.213.115.189]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5ALJkhE016684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Jun 2010 14:19:58 -0700 (PDT) Message-ID: <4C1156F2.9030600@isi.edu> Date: Thu, 10 Jun 2010 14:19:46 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Biswas, Anumita" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4CDB1563777154EA5D90BE91" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 21:21:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4CDB1563777154EA5D90BE91 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Biswas, Anumita wrote: =2E.. >>> If keeping the standard TCP CRC intact (and covering TCP header &=20 >>> data) and having an RFC1146 alternate checksum that works=20 >> differently=20 >>> than defined therein, perhaps it would be better to make it=20 >> a new TCP=20 >>> option then. >> >> Defined therein where?=20 > > http://datatracker.ietf.org/doc/draft-anumita-tcpm-stronger-checksum/ >=20 > Section 3 - "Negotiating the use of CRC 32C" There are two differences: a) different processing rules computed over different portions of the segment and different rules for what happens to the original TCP checksum area and different rules for what to do when the option fails on SYNs These are hard to fix without rewriting RFC-1146, which is feasible only = if there is a real need. b) different algorithm this is easily fixed without modifying RFC-1146, by defining a new algorithm this assumes only the algorithm changes, though Joe --------------enig4CDB1563777154EA5D90BE91 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwRVvIACgkQE5f5cImnZru4ogCgvtxX5oqz6OlkSNSYGDQqBZjv dCwAni9XOVt+G5jREEVuEHSvSYtp5Q7C =/jzx -----END PGP SIGNATURE----- --------------enig4CDB1563777154EA5D90BE91-- From lars.eggert@nokia.com Mon Jun 14 06:22:23 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670563A68D8 for ; Mon, 14 Jun 2010 06:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlrRhvOUo+Ey for ; Mon, 14 Jun 2010 06:22:22 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 75E6E3A6781 for ; Mon, 14 Jun 2010 06:22:22 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5EDMELI019694 for ; Mon, 14 Jun 2010 08:22:25 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 16:20:30 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 16:20:29 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5EDKQgb029173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Jun 2010 16:20:28 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-5--285807585; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 14 Jun 2010 16:20:19 +0300 In-Reply-To: <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> To: "tcpm@ietf.org Extensions" References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> Message-Id: <73940FF0-5B42-40DE-8F8F-EB4C10F714C0@nokia.com> X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Mon, 14 Jun 2010 16:20:20 +0300 (EEST) X-OriginalArrivalTime: 14 Jun 2010 13:20:29.0645 (UTC) FILETIME=[5C1337D0:01CB0BC4] X-Nokia-AV: Clean Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 14 Jun 2010 13:22:23 -0000 --Apple-Mail-5--285807585 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-6-9, at 19:28, Eggert Lars (Nokia-NRC/Espoo) wrote: > Quite possibly the most boring RFC ever. But at least it's short. = Comments welcome. I wanted to clarify that I'm not personally against (or for) any of the = TCP extensions mentioned in the draft, especially the alternate checksum = option. The criteria for including these RFCs here is that we had = consensus to tag them as Historic when we published RFC4614. We can = certainly change our mind about any of these extensions. Lars > http://tools.ietf.org/html/draft-eggert-tcpm-historicize >=20 > Begin forwarded message: >> Filename: draft-eggert-tcpm-historicize >> Revision: 00 >> Title: Moving the Undeployed TCP Extensions RFC1072, = RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and = RFC1693 to Historic Status >> Creation_date: 2010-06-09 >> WG ID: Independent Submission >> Number_of_pages: 4 >>=20 >> Abstract: >> This document recommends that several TCP extensions that have never >> seen widespread use be moved to Historic status. The affected RFCs >> are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, >> RFC1644 and RFC1693. >=20 > Lars --Apple-Mail-5--285807585 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDYxNDEzMjAxOVowIwYJKoZIhvcNAQkEMRYEFOYZiFRwPKv4rnEnWiJOKc7r53MtMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDXXp3ybcA7FoHY7crTCT/VgmZ8iANoOzwRHi0+eZwL9msFBODuZxakVUxn1JggaErqQ4vx vGVFwdK97AW5NSGJQ3IdKb+d4ncqIL04FrwvH+r+04+5YhDzl6yMQ3nD2BoB1tj/nWXmhLtIYDK+ lxp1NWPdZVnfMbfyTYJivgOoEynU/+IYbgP9qdhsk57O15qEu4UFd2NOz9jcJorQ5mD0TsduqWKk 4rHcSKHZ2gTG+sHppkiIbigDJXcHTtiYcgCUJlxd8g9enhs/Mxn3BlN8DkhfrwQ7wLIz9a/U2oX1 jCW09lCnIR1+tDiZNJd3UeNfQSieEw+rbGBZRn+VHSE7AAAAAAAA --Apple-Mail-5--285807585-- From hagen@jauu.net Mon Jun 14 13:36:37 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913B13A68F0 for ; Mon, 14 Jun 2010 13:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.205 X-Spam-Level: X-Spam-Status: No, score=-0.205 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsaQzNrQtET8 for ; Mon, 14 Jun 2010 13:36:36 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id 3CC4C3A635F for ; Mon, 14 Jun 2010 13:36:36 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 7008EF44133; Mon, 14 Jun 2010 22:36:38 +0200 (CEST) Date: Mon, 14 Jun 2010 22:36:37 +0200 From: Hagen Paul Pfeifer To: Lars Eggert Message-ID: <20100614203628.GA12250@nuttenaction> References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <73940FF0-5B42-40DE-8F8F-EB4C10F714C0@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73940FF0-5B42-40DE-8F8F-EB4C10F714C0@nokia.com> 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.20 (2009-06-14) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 14 Jun 2010 20:36:37 -0000 * Lars Eggert | 2010-06-14 16:20:19 [+0300]: >I wanted to clarify that I'm not personally against (or for) any of the TCP >extensions mentioned in the draft, especially the alternate checksum option. >The criteria for including these RFCs here is that we had consensus to tag >them as Historic when we published RFC4614. We can certainly change our mind >about any of these extensions. I am fine with that document, IMHO it is all said. Hagen From David.Ros@telecom-bretagne.eu Tue Jun 15 05:08:42 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3413A68C0 for ; Tue, 15 Jun 2010 05:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F77THdXGE4iZ for ; Tue, 15 Jun 2010 05:08:41 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id 87F1C3A6A63 for ; Tue, 15 Jun 2010 05:08:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o5FC8jXT029271; Tue, 15 Jun 2010 14:08:46 +0200 Received: from courrier.enst-bretagne.fr (smtps.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id o5FC8dc6029235; Tue, 15 Jun 2010 14:08:43 +0200 Received: from [10.35.128.121] ([10.35.128.121]) (user=dros mech=PLAIN bits=0) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2010.02.22) with ESMTP id o5FC8awN019851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jun 2010 14:08:37 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: David Ros In-Reply-To: <20100609203315.GC5338@nuttenaction> Date: Tue, 15 Jun 2010 14:08:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <20100609173556.GA5338@nuttenaction> <07BF7B99-FF83-44E1-BF52-BED91ACA7F3A@surrey.ac.uk> <20100609200052.GB5338@nuttenaction> <20100609203315.GC5338@nuttenaction> To: Hagen Paul Pfeifer X-Mailer: Apple Mail (2.1078) X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: tcpm@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 12:08:42 -0000 Le 9 juin 2010 =E0 22:33, Hagen Paul Pfeifer a =E9crit : >=20 >> the sensor networks I'm familiar with use IP, but don't use TCP, for >> many of the same underlying reasons. >> http://sat-net.com/L.Wood/dtn/saratoga >=20 > Yes, the characteristics and problems are nearly the same. The papers = I read > ("Making TCP/IP Viable for Wireless Sensor Networks", "Hop-by-Hop TCP = for > Sensor Networks", ...) are pure academic papers and I personally saw = no sensor > network TCP implementation in the wild. >=20 Hi, FWIW, the Contiki OS for sensors does have a TCP implementation (albeit = with a lot of limitations, it seems). I don't know if it's used by = anybody :-), but it's already there in the code. Regards, David. =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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David ROS http://www.rennes.enst-bretagne.fr/~dros/ I love deadlines. I like the whooshing sound they make as they fly by. = -- Douglas Adams From root@core3.amsl.com Mon Jun 21 11:30:07 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 653FC28C0D0; Mon, 21 Jun 2010 11:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100621183004.653FC28C0D0@core3.amsl.com> Date: Mon, 21 Jun 2010 11:30:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-timestamps-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 21 Jun 2010 18:30:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Reducing the TIME-WAIT state using TCP timestamps Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-timestamps-00.txt Pages : 10 Date : 2010-6-21 This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-timestamps-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-timestamps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-6-21111730.I-D@ietf.org> --NextPart-- From wwwrun@rfc-editor.org Mon Jun 21 15:58:13 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119EA28C15E; Mon, 21 Jun 2010 15:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoaAI1vC4Qf9; Mon, 21 Jun 2010 15:58:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 3F64228C157; Mon, 21 Jun 2010 15:58:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BBD38E06C9; Mon, 21 Jun 2010 15:58:19 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100621225819.BBD38E06C9@rfc-editor.org> Date: Mon, 21 Jun 2010 15:58:19 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 5925 on The TCP Authentication Option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 21 Jun 2010 22:58:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5925 Title: The TCP Authentication Option Author: J. Touch, A. Mankin, R. Bonica Status: Standards Track Stream: IETF Date: June 2010 Mailbox: touch@isi.edu, mankin@psg.com, rbonica@juniper.net Pages: 48 Characters: 106174 Obsoletes: RFC2385 I-D Tag: draft-ietf-tcpm-tcp-auth-opt-11.txt URL: http://www.rfc-editor.org/rfc/rfc5925.txt This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Jun 21 15:58:31 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1513A68E0; Mon, 21 Jun 2010 15:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8stRe5OVB88o; Mon, 21 Jun 2010 15:58:24 -0700 (PDT) Received: from rfc-editor.org (rfcpa [64.170.98.47]) by core3.amsl.com (Postfix) with ESMTP id 73BAE28C13F; Mon, 21 Jun 2010 15:58:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 00449E06CB; Mon, 21 Jun 2010 15:58:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100621225832.00449E06CB@rfc-editor.org> Date: Mon, 21 Jun 2010 15:58:31 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 5926 on Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 21 Jun 2010 22:58:31 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5926 Title: Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) Author: G. Lebovitz, E. Rescorla Status: Standards Track Stream: IETF Date: June 2010 Mailbox: gregory.ietf@gmail.com, ekr@rtfm.com Pages: 15 Characters: 31010 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-tcp-ao-crypto-03.txt URL: http://www.rfc-editor.org/rfc/rfc5926.txt The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARD TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From lars.eggert@nokia.com Tue Jun 22 12:52:45 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E785F28C107; Tue, 22 Jun 2010 12:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.326 X-Spam-Level: X-Spam-Status: No, score=-6.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3GHniBDB81G; Tue, 22 Jun 2010 12:52:43 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 72C1928C0D0; Tue, 22 Jun 2010 12:52:43 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5MJoaUO012425; Tue, 22 Jun 2010 14:52:49 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 22:52:31 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 22:52:31 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5MJqVYd024425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jun 2010 22:52:31 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-2-428917405; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 22 Jun 2010 22:52:24 +0300 References: <3D3C75174CB95F42AD6BCC56E5555B4502BE0741@FIESEXC015.nsn-intra.net> To: Multipath TCP Mailing List , "tcpm@ietf.org Extensions" Message-Id: X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Tue, 22 Jun 2010 22:52:25 +0300 (EEST) X-OriginalArrivalTime: 22 Jun 2010 19:52:31.0539 (UTC) FILETIME=[73856830:01CB1244] X-Nokia-AV: Clean Cc: Hannes Tschofenig Subject: [tcpm] Fwd: Probing the viability of TCP extensions X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 22 Jun 2010 19:52:45 -0000 --Apple-Mail-2-428917405 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thanks for the link, Hannes! Begin forwarded message: > From: "Tschofenig, Hannes (NSN - FI/Espoo)" > Date: June 22, 2010 22:45:28 GMT+03:00 > To: "Eggert Lars (Nokia-NRC/Espoo)" > Subject: Probing the viability of TCP extensions > > FYI: http://www.imperialviolet.org/binary/ecntest.pdf > --Apple-Mail-2-428917405 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYyMjE5 NTIyNFowIwYJKoZIhvcNAQkEMRYEFNWUhxA3G3+9aQjU8bz7kVnJCJofMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBACyMLbCVAI2Fs3oKo4fYw0yr0LUbCqDZfxOz6zsImR7dgdZR0Q18 tgV7anqQQhNqo7992OPNHHEPPp+KwtVoAZeVmDRP/Qjp0jipoUvtkUGAHQZoGqgxLLTZjuAtd554 nPAc7Pi36CBEVkDLzxGo5ZYqNPTqSf45Q4Ou1a+3jJMRjgxss6YBk3fs0j4uaTj2zYUygyu55UoT nQY1q+LSKGbpoQzKQ7YNp+Mx+CajBxCZ/RD1H7V274fVnjbe529VFhkO8WXcxlUjmGRGGhE9grAN Vi+fyfL3dSm1JEok7+/a5wyp5P3ZD0VHLCV7h9288InDrbx5gxFL+poZuZKVHBgAAAAAAAA= --Apple-Mail-2-428917405-- From rs@netapp.com Tue Jun 22 16:14:43 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5A993A6A2D; Tue, 22 Jun 2010 16:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.556 X-Spam-Level: X-Spam-Status: No, score=-4.556 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBTJGAo1bBrv; Tue, 22 Jun 2010 16:14:40 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id EE98E3A67AC; Tue, 22 Jun 2010 16:14:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,463,1272870000"; d="scan'208";a="176685029" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 22 Jun 2010 16:14:45 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o5MNDqaG021338; Tue, 22 Jun 2010 16:14:18 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jun 2010 00:14:02 +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: Wed, 23 Jun 2010 00:13:58 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A09227C84@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Fwd: Probing the viability of TCP extensions Thread-Index: AcsSRIOzlIUt69HQS+yxXwSYI0Z3LwAGqOlg References: <3D3C75174CB95F42AD6BCC56E5555B4502BE0741@FIESEXC015.nsn-intra.net> From: "Scheffenegger, Richard" To: "Lars Eggert" , "Multipath TCP Mailing List" , X-OriginalArrivalTime: 22 Jun 2010 23:14:02.0556 (UTC) FILETIME=[9A542FC0:01CB1260] Cc: Hannes Tschofenig Subject: Re: [tcpm] Fwd: Probing the viability of TCP extensions X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 22 Jun 2010 23:14:43 -0000 Adam is a member of the TCPM list :) I am curious, out of the 1,07% of Hosts where ECN negotiation was successful, is there any indication that internet routers are actually making use of the ECT / CE codepoints in the IP header? Ie. When loading a page from those web servers, were any CE marked segments received? Or is ECN only negotiated between hosts, but never actually used to deliver a benefit (which might explain the extremely low adoption rate almost 10 years after standardization. Also, your research was done in 2008 - Microsoft has introduced ECN support with Windows Vista / 7, is there any indication of rising levels of public ECN support, or still a falling trend? I'm asking as there seems to be renewed interest in having ECN-singalling in private networks again... Best regards, Richard Scheffenegger =20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Dienstag, 22. Juni 2010 21:52 > To: Multipath TCP Mailing List; tcpm@ietf.org Extensions > Cc: Hannes Tschofenig > Subject: [tcpm] Fwd: Probing the viability of TCP extensions >=20 > Thanks for the link, Hannes! >=20 > Begin forwarded message: > > From: "Tschofenig, Hannes (NSN - FI/Espoo)"=20 > > > > Date: June 22, 2010 22:45:28 GMT+03:00 > > To: "Eggert Lars (Nokia-NRC/Espoo)" > > Subject: Probing the viability of TCP extensions > >=20 > > FYI: http://www.imperialviolet.org/binary/ecntest.pdf > >=20 >=20 >=20 From alangley@gmail.com Tue Jun 22 18:11:07 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BAB33A690D; Tue, 22 Jun 2010 18:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj8MhSOML7lv; Tue, 22 Jun 2010 18:11:06 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 184473A68BF; Tue, 22 Jun 2010 18:11:05 -0700 (PDT) Received: by vws15 with SMTP id 15so162836vws.31 for ; Tue, 22 Jun 2010 18:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=ZiR/DICaYBjUlvqeX5PoAq3paR7McOg6TaueTAxfCRE=; b=bq8qM4lHY+nrW93xGcRKcfu5Af0ANxZApLs9+a/KmWdNRIjjELbEI1uduShhrDgjMc D72TCttkzKTQfIr7s5YS2A+ajSsZ1UV2uMiGtCYLy+dqAOCwB7HH1CK6KxWhtS17ERqp LQCawLiNp0BmTv82wjTOxcAq08YQym0y5wCwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=rShfq3BCQsNLQ4D/igAIagXqlpQUg0u9vJm4pa+lv7wSACVCrLiktyJ0KhdkuSes+s e8jliibS5pV5q/g2PtHePVSmR1cGnFjPO1MbzSk06x3wMpgYzOibctSTFPvtSt21sFen 98S0ZRIC5/PvCTT1FJR8Ia0zQmorgUC4HC6mM= MIME-Version: 1.0 Received: by 10.220.172.198 with SMTP id m6mr178766vcz.79.1277255470479; Tue, 22 Jun 2010 18:11:10 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.220.105.211 with HTTP; Tue, 22 Jun 2010 18:11:10 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A09227C84@LDCMVEXC1-PRD.hq.netapp.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE0741@FIESEXC015.nsn-intra.net> <5FDC413D5FA246468C200652D63E627A09227C84@LDCMVEXC1-PRD.hq.netapp.com> Date: Tue, 22 Jun 2010 21:11:10 -0400 X-Google-Sender-Auth: Uif_kMv6HVNuf3W7Wuz7Q6UGdNo Message-ID: From: Adam Langley To: "Scheffenegger, Richard" Content-Type: text/plain; charset=UTF-8 Cc: Multipath TCP Mailing List , tcpm@ietf.org, Hannes Tschofenig Subject: Re: [tcpm] Fwd: Probing the viability of TCP extensions X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 23 Jun 2010 01:11:07 -0000 On Tue, Jun 22, 2010 at 7:13 PM, Scheffenegger, Richard wrote: > Adam is a member of the TCPM list :) Er, yea, hi :) > I am curious, out of the 1,07% of Hosts where ECN negotiation was > successful, is there any indication that internet routers are actually > making use of the ECT / CE codepoints in the IP header? I didn't look for it. The prober didn't progress beyond the initial TCP handshake. > Also, your research was done in 2008 - Microsoft has introduced ECN > support with Windows Vista / 7, is there any indication of rising levels > of public ECN support, or still a falling trend? > > I'm asking as there seems to be renewed interest in having > ECN-singalling in private networks again... I haven't retried the experiment since the initial investigation. However, there wasn't anything special about it: I did it from a standard hosting company VPS machine (after clearing it with them first). The only sensitive bit was the list of hostname from the Google index. You could just download the .com zone and achieve much the same effect I'm sure. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From lars.eggert@nokia.com Wed Jun 23 23:41:06 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F75F28C103 for ; Wed, 23 Jun 2010 23:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xka-BoH916Dy for ; Wed, 23 Jun 2010 23:41:03 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id EB7BC3A6846 for ; Wed, 23 Jun 2010 23:41:02 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5O6f92V027564 for ; Thu, 24 Jun 2010 01:41:10 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 09:41:08 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 09:41:08 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5O6f8JD028470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jun 2010 09:41:08 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-26-554224861; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 24 Jun 2010 09:40:51 +0300 In-Reply-To: <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> To: "tcpm@ietf.org Extensions" References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> Message-Id: <2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Thu, 24 Jun 2010 09:40:58 +0300 (EEST) X-OriginalArrivalTime: 24 Jun 2010 06:41:08.0603 (UTC) FILETIME=[3A4FDCB0:01CB1368] X-Nokia-AV: Clean Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jun 2010 06:41:06 -0000 --Apple-Mail-26-554224861 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, since we're not meeting in Maastricht, I might as well ask this now: Do = folks believe we should go forward with making these extensions = historic? In that case, I'll ask the chairs to do a consensus poll on = adopting this document as a WG work item. Lars On 2010-6-9, at 19:28, Eggert Lars (Nokia-NRC/Espoo) wrote: > Begin forwarded message: >> Filename: draft-eggert-tcpm-historicize >> Revision: 00 >> Title: Moving the Undeployed TCP Extensions RFC1072, = RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and = RFC1693 to Historic Status >> Creation_date: 2010-06-09 >> WG ID: Independent Submission >> Number_of_pages: 4 >>=20 >> Abstract: >> This document recommends that several TCP extensions that have never >> seen widespread use be moved to Historic status. The affected RFCs >> are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, >> RFC1644 and RFC1693. --Apple-Mail-26-554224861 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYyNDA2 NDA1MlowIwYJKoZIhvcNAQkEMRYEFGGMtAuO2NSVhNszDkEDqgOWCWGWMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAEwUifRUyKW0Aukx1mvY0JQtRpsKBXvVSATxPtjCWITGtx4T0IEl luRfdMv+1KbMMYM+M6ItkPDW0fuWIEl3HaB5wfqUhtyv1T2ebBq13RkrmyUKkxyCRlIt9Uddx4Zm YzcQn3Z+n3Ud/Vk1IcsdiPrI+7nrrAsNtKeU3JGRkSjEGJf+WfcjNFxHuoCrFiCsNMOg0r/ABvVx z52OE1llMbuQUO5k9Bu4fX66pubjv48W36vCnet3VQ/qkVNWqnXhJQAgc9cmz6diluIE+mNh33wu rELDH5ZmCJo9o/ieK7Vfyq/+bz3IA2T06KZ7s+WO+hIkfx6RqpY0UXloQK4cwZsAAAAAAAA= --Apple-Mail-26-554224861-- From alexander.zimmermann@nets.rwth-aachen.de Thu Jun 24 00:26:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA973A63CB for ; Thu, 24 Jun 2010 00:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOpqoTOo-hPn for ; Thu, 24 Jun 2010 00:26:57 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id E57553A6A39 for ; Thu, 24 Jun 2010 00:26:56 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L4I00J1HCP3SB20@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 24 Jun 2010 09:27:03 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.53,472,1272837600"; d="sig'?scan'208";a="62629970" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 24 Jun 2010 09:27:03 +0200 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L4I00HNBCP3XR30@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 24 Jun 2010 09:27:03 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-2-556999807 From: Alexander Zimmermann In-reply-to: <2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> Date: Thu, 24 Jun 2010 09:27:06 +0200 Content-transfer-encoding: 7bit Message-id: <2A54056F-DA38-4196-B0F0-6A767A5AF4E9@nets.rwth-aachen.de> References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> To: Lars Eggert X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jun 2010 07:26:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-556999807 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 24.06.2010 um 08:40 schrieb Lars Eggert: > Hi, >=20 > since we're not meeting in Maastricht, :-( > I might as well ask this now: Do folks believe we should go forward = with making these extensions historic? Ja/yes/oui > In that case, I'll ask the chairs to do a consensus poll on adopting = this document as a WG work item. >=20 > Lars Alex >=20 > On 2010-6-9, at 19:28, Eggert Lars (Nokia-NRC/Espoo) wrote: >> Begin forwarded message: >>> Filename: draft-eggert-tcpm-historicize >>> Revision: 00 >>> Title: Moving the Undeployed TCP Extensions RFC1072, = RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and = RFC1693 to Historic Status >>> Creation_date: 2010-06-09 >>> WG ID: Independent Submission >>> Number_of_pages: 4 >>>=20 >>> Abstract: >>> This document recommends that several TCP extensions that have never >>> seen widespread use be moved to Historic status. The affected RFCs >>> are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, >>> RFC1644 and RFC1693. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-2-556999807 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkwjCMsACgkQdyiq39b9uS4aIACg6jET2mZukCPfTFwnZ4frdxqp Q8UAnjI8vYmib3nTtyncyc4KDnQGTp6g =OmBx -----END PGP SIGNATURE----- --Apple-Mail-2-556999807-- From ycheng@google.com Thu Jun 24 10:04:49 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3806B3A6912 for ; Thu, 24 Jun 2010 10:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUuA5pUPZD5Y for ; Thu, 24 Jun 2010 10:04:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C285F3A6976 for ; Thu, 24 Jun 2010 10:04:47 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o5OH4tU3008122 for ; Thu, 24 Jun 2010 10:04:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277399095; bh=ySsZp4UBDBZjoas2RbqiPvbjwvs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CEypF31Z2W87CD6vP8LdsB65xNTeUjOwDqEGxWPQcK5E6JOo9Uj1K4ee9nOvTQPee JGP1VsfiuT8evaKyqk9lg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=W/IHZQOq+z/u/Klv+B637RQMW+CITIkkTu3H1Q7ikGp245lf0eZr865tldoiwFWz0 Lz59YjhH9lQBosdxNeH2g== Received: from wwi14 (wwi14.prod.google.com [10.241.243.14]) by wpaz21.hot.corp.google.com with ESMTP id o5OH4rEM023346 for ; Thu, 24 Jun 2010 10:04:54 -0700 Received: by wwi14 with SMTP id 14so831780wwi.7 for ; Thu, 24 Jun 2010 10:04:53 -0700 (PDT) Received: by 10.216.163.204 with SMTP id a54mr7630201wel.2.1277399082235; Thu, 24 Jun 2010 10:04:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.189.199 with HTTP; Thu, 24 Jun 2010 10:04:21 -0700 (PDT) In-Reply-To: <2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> From: Yuchung Cheng Date: Thu, 24 Jun 2010 10:04:21 -0700 Message-ID: To: Lars Eggert Content-Type: multipart/alternative; boundary=0016367f9f6e8af7ea0489c9a638 X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jun 2010 17:04:49 -0000 --0016367f9f6e8af7ea0489c9a638 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 23, 2010 at 11:40 PM, Lars Eggert wrote: > Hi, > > since we're not meeting in Maastricht, I might as well ask this now: Do > folks believe we should go forward with making these extensions historic? In > that case, I'll ask the chairs to do a consensus poll on adopting this > document as a WG work item. > +1 yes vote. --0016367f9f6e8af7ea0489c9a638 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 23, 2010 at 11:40 PM, Lars E= ggert <lars.e= ggert@nokia.com> wrote:
Hi,

since we're not meeting in Maastricht, I might as well ask this now: Do= folks believe we should go forward with making these extensions historic? = In that case, I'll ask the chairs to do a consensus poll on adopting th= is document as a WG work item.
+1 yes vote.
=A0
--0016367f9f6e8af7ea0489c9a638-- From wesley.m.eddy@nasa.gov Thu Jun 24 10:34:04 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEBB03A6896 for ; Thu, 24 Jun 2010 10:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X6I+yY7UUIG for ; Thu, 24 Jun 2010 10:34:03 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id EC6D43A68DB for ; Thu, 24 Jun 2010 10:33:43 -0700 (PDT) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 2B97C260008; Thu, 24 Jun 2010 12:33:52 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o5OHXntN004886; Thu, 24 Jun 2010 12:33:51 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Thu, 24 Jun 2010 12:33:52 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Lars Eggert , "tcpm@ietf.org Extensions" Date: Thu, 24 Jun 2010 12:33:50 -0500 Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsTaELvChlaGVTORWuANEwU7pfW3QAWo8PA Message-ID: References: <20100609151532.8E75E28C0D0@core3.amsl.com> <33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> In-Reply-To: <2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-24_02:2010-02-06, 2010-06-24, 2010-06-24 signatures=0 Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jun 2010 17:34:04 -0000 >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Lars Eggert >Sent: Thursday, June 24, 2010 2:41 AM >To: tcpm@ietf.org Extensions >Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 > >Hi, > >since we're not meeting in Maastricht, I might as well ask this now: Do >folks believe we should go forward with making these extensions >historic? In that case, I'll ask the chairs to do a consensus poll on >adopting this document as a WG work item. > Ok, consider the mail from Lars the opening of this consensus to adopt poll. :) In the next two weeks, if people could respond whether they: 1) Support this document for development towards publication as an Informational RFC via the TCPM working group 2) Do not support the document as a TCPM work item. 3) Have other thoughts ... -- Wes Eddy MTI Systems From ananth@cisco.com Thu Jun 24 11:17:18 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6193A69BD for ; Thu, 24 Jun 2010 11:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.197 X-Spam-Level: X-Spam-Status: No, score=-10.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhsL3q7F9k4M for ; Thu, 24 Jun 2010 11:17:17 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5F8E33A6889 for ; Thu, 24 Jun 2010 11:17:13 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADc+I0yrR7Ht/2dsb2JhbACfOHGnZppZhSEEg14 X-IronPort-AV: E=Sophos;i="4.53,475,1272844800"; d="scan'208";a="217227689" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 24 Jun 2010 18:17:21 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5OIHIvL005489; Thu, 24 Jun 2010 18:17:21 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jun 2010 11:17:20 -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: Thu, 24 Jun 2010 11:17:19 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsTaELvChlaGVTORWuANEwU7pfW3QAWo8PAAAGP6oA= References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> From: "Anantha Ramaiah (ananth)" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , "Lars Eggert" , X-OriginalArrivalTime: 24 Jun 2010 18:17:20.0405 (UTC) FILETIME=[7C3F0450:01CB13C9] Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jun 2010 18:17:18 -0000 =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] > Sent: Thursday, June 24, 2010 10:34 AM > To: Lars Eggert; tcpm@ietf.org Extensions > Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 >=20 > >-----Original Message----- > >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org]=20 > On Behalf Of=20 > >Lars Eggert > >Sent: Thursday, June 24, 2010 2:41 AM > >To: tcpm@ietf.org Extensions > >Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 > > > >Hi, > > > >since we're not meeting in Maastricht, I might as well ask=20 > this now: Do=20 > >folks believe we should go forward with making these extensions=20 > >historic? In that case, I'll ask the chairs to do a=20 > consensus poll on=20 > >adopting this document as a WG work item. > > >=20 >=20 > Ok, consider the mail from Lars the opening of this consensus=20 > to adopt poll. :) In the next two weeks, if people could=20 > respond whether they: >=20 > 1) Support this document for development towards publication=20 > as an Informational RFC via the TCPM working group >=20 > 2) Do not support the document as a TCPM work item. I have already communicated earlier that the TCP alternate checksum option needs to be removed from this list. Reason being it is still being used and there are proposals out there that is trying to make use of this option. Other than that point I am fine with this draft moving forward. -Anantha From touch@isi.edu Thu Jun 24 11:48:58 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB663A6982 for ; Thu, 24 Jun 2010 11:48:58 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45kFs8qx9jfO for ; Thu, 24 Jun 2010 11:48:54 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C7DDE3A688A for ; Thu, 24 Jun 2010 11:48:53 -0700 (PDT) Received: from [128.9.176.226] (c2-vpn09.isi.edu [128.9.176.226]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5OIlSbp005005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jun 2010 11:47:28 -0700 (PDT) Message-ID: <4C23A83F.3080102@isi.edu> Date: Thu, 24 Jun 2010 11:47:27 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig92DBE6BF3AE8EB6C41E8F384" X-MailScanner-ID: o5OIlSbp005005 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jun 2010 18:48:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig92DBE6BF3AE8EB6C41E8F384 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. >> Ok, consider the mail from Lars the opening of this consensus=20 >> to adopt poll. :) In the next two weeks, if people could=20 >> respond whether they: >> >> 1) Support this document for development towards publication=20 >> as an Informational RFC via the TCPM working group >> >> 2) Do not support the document as a TCPM work item. >=20 > I have already communicated earlier that the TCP alternate checksum > option needs to be removed from this list. Reason being it is still > being used and there are proposals out there that is trying to make use= > of this option. Other than that point I am fine with this draft moving > forward. I agree with Anantha, except that I think the doc might have a short sect= ion explaining *why* the alt checksum isn't in the list. Joe --------------enig92DBE6BF3AE8EB6C41E8F384 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwjqEAACgkQE5f5cImnZrsblACguKsiVa6Z4GLFKJqoXJrYy1pU sLcAoNblzttT5LCU1BVqlYvxRkRtdg2M =J9Zh -----END PGP SIGNATURE----- --------------enig92DBE6BF3AE8EB6C41E8F384-- From hkchu@google.com Thu Jun 24 16:57:01 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF78828C100 for ; Thu, 24 Jun 2010 16:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtBblBXyPJ8a for ; Thu, 24 Jun 2010 16:57:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3532628C0FB for ; Thu, 24 Jun 2010 16:57:01 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o5ONv8Ah010319 for ; Thu, 24 Jun 2010 16:57:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277423829; bh=aKYbh8JD1IEkMSylrtR6U2Bv114=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=K4sMny+KStDIo1+vCtmlUcV8xF4JH6Uix9Icjx0+u4QOFjwd6eaz6Gr+bNU8pe5Ih viA7jJpj/5BX2CINDBG1A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=yJ6skFi9MvvzRVjVnMAFGSsLWs53+NZXrqbN8+F4Ryv2AuMxdQX75cEK9QQVMa0EA LcXJD81ODIjBmWwIuChSA== Received: from vws12 (vws12.prod.google.com [10.241.21.140]) by kpbe11.cbf.corp.google.com with ESMTP id o5ONv7eR005077 for ; Thu, 24 Jun 2010 16:57:08 -0700 Received: by vws12 with SMTP id 12so3145666vws.29 for ; Thu, 24 Jun 2010 16:57:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.241.206 with SMTP id lf14mr5791814qcb.205.1277423826757; Thu, 24 Jun 2010 16:57:06 -0700 (PDT) Received: by 10.229.78.25 with HTTP; Thu, 24 Jun 2010 16:57:06 -0700 (PDT) Date: Thu, 24 Jun 2010 16:57:06 -0700 Message-ID: From: Jerry Chu To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=0016362845266be9ee0489cf690c X-System-Of-Record: true Subject: [tcpm] no meeting at Maastricht? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jun 2010 23:57:02 -0000 --0016362845266be9ee0489cf690c Content-Type: text/plain; charset=ISO-8859-1 Just saw the draft agenda but did not see tcpm? Are we not meeting at Maastricht? Thanks, Jerry --0016362845266be9ee0489cf690c Content-Type: text/html; charset=ISO-8859-1 Just saw the draft agenda but did not see tcpm? Are we not meeting at Maastricht?

Thanks,

Jerry

--0016362845266be9ee0489cf690c-- From rs@netapp.com Fri Jun 25 04:31:19 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F2D3A68FA for ; Fri, 25 Jun 2010 04:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.671 X-Spam-Level: X-Spam-Status: No, score=-5.671 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdJWEqpFi1kY for ; Fri, 25 Jun 2010 04:31:01 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 6C4C93A6845 for ; Fri, 25 Jun 2010 04:30:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,480,1272870000"; d="scan'208";a="166931686" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 25 Jun 2010 04:31:06 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o5PBTkjA006996 for ; Fri, 25 Jun 2010 04:31:01 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jun 2010 12:30:55 +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: Fri, 25 Jun 2010 12:30:54 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0935F672@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsTaFT0Ejq/bdicTV6d+pWDLmbPggAdvrCg References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com> <2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> From: "Scheffenegger, Richard" To: X-OriginalArrivalTime: 25 Jun 2010 11:30:55.0230 (UTC) FILETIME=[DFF659E0:01CB1459] Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jun 2010 11:31:19 -0000 I'd support that, based on the recent discussions that the alternate checksum option is not a viable method for better payload protection anyway :) Richard Scheffenegger =20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Donnerstag, 24. Juni 2010 08:41 > To: tcpm@ietf.org Extensions > Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 >=20 > Hi, >=20 > since we're not meeting in Maastricht, I might as well ask=20 > this now: Do folks believe we should go forward with making=20 > these extensions historic? In that case, I'll ask the chairs=20 > to do a consensus poll on adopting this document as a WG work item. >=20 > Lars >=20 > On 2010-6-9, at 19:28, Eggert Lars (Nokia-NRC/Espoo) wrote: > > Begin forwarded message: > >> Filename: draft-eggert-tcpm-historicize > >> Revision: 00 > >> Title: Moving the Undeployed TCP Extensions=20 > RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263,=20 > RFC1379, RFC1644 and RFC1693 to Historic Status > >> Creation_date: 2010-06-09 > >> WG ID: Independent Submission > >> Number_of_pages: 4 > >>=20 > >> Abstract: > >> This document recommends that several TCP extensions that=20 > have never=20 > >> seen widespread use be moved to Historic status. The=20 > affected RFCs=20 > >> are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, > >> RFC1644 and RFC1693. >=20 >=20 From wesley.m.eddy@nasa.gov Fri Jun 25 05:14:16 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A23A3A6981 for ; Fri, 25 Jun 2010 05:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCHEfHQ8hhRU for ; Fri, 25 Jun 2010 05:14:14 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id A5AAC3A685C for ; Fri, 25 Jun 2010 05:14:14 -0700 (PDT) Received: from ndjsppt05.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 6AAA7A80D0; Fri, 25 Jun 2010 07:14:23 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt05.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o5PCENjm020897; Fri, 25 Jun 2010 07:14:23 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Fri, 25 Jun 2010 07:14:23 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Jerry Chu , "tcpm@ietf.org" Date: Fri, 25 Jun 2010 07:14:21 -0500 Thread-Topic: [tcpm] no meeting at Maastricht? Thread-Index: AcsT+Pn6nhthJrNjRHW/ASpHj8HRoQAZu3+A Message-ID: References: In-Reply-To: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-25_06:2010-02-06, 2010-06-25, 2010-06-24 signatures=0 Subject: Re: [tcpm] no meeting at Maastricht? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jun 2010 12:14:16 -0000 >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Jerry Chu >Sent: Thursday, June 24, 2010 7:57 PM >To: tcpm@ietf.org >Subject: [tcpm] no meeting at Maastricht? > >Just saw the draft agenda but did not see tcpm? Are we not meeting at >Maastricht? > >Thanks, > >Jerry > Hi Jerry, we originally submitted a request for a meeting slot, but withdrew it in the last couple days after looking at a few things, including: - much of our work is in the phase where it's nearing completion - among the active WG documents, tcp-security is the main one that could use face-time, but the editor can't make it to Maastricht - availability of webex to IETF WGs seemed like a good way to make progress on tcp-security and other potential new documents - we had seen reports that the agenda slots were heavily over-requested for Maastricht - both WG chairs were having difficulty scheduling Maastricht travel So, with the combination of those factors, we decided it would be more beneficial to setup a webex to work on tcp-security, at least, and use the mailing list to close out any issues on the other documents. I hope that makes sense; I had planned on communicating it to the list in the next couple days, but your question pushed it out today :). -- Wes Eddy MTI Systems From rs@netapp.com Fri Jun 25 08:07:59 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C212828C0F4 for ; Fri, 25 Jun 2010 08:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.556 X-Spam-Level: X-Spam-Status: No, score=-4.556 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tGDsPE3SVw1 for ; Fri, 25 Jun 2010 08:07:58 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 5F9093A6784 for ; Fri, 25 Jun 2010 08:07:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,481,1272870000"; d="scan'208";a="167002390" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 25 Jun 2010 08:08:05 -0700 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o5PF4tIL004136; Fri, 25 Jun 2010 08:07:28 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jun 2010 17:07:14 +0200 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, 25 Jun 2010 16:07:12 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsTaELvChlaGVTORWuANEwU7pfW3QAWo8PAAAGP6oAAKxw48A== References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> From: "Scheffenegger, Richard" To: "Anantha Ramaiah (ananth)" , "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , "Lars Eggert" , X-OriginalArrivalTime: 25 Jun 2010 15:07:14.0360 (UTC) FILETIME=[18206B80:01CB1478] Cc: "Biswas, Anumita" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jun 2010 15:07:59 -0000 Anantha, I think for purposes of documenting "legacy" implementations, the RFC1146 would still be valid. I will try to define the goal of that recent proposal again, at least as far as I understand this, so that we are all on the same page here. Our expirience has shown, that TCP often runs over links with much higher error rates, than intended for the technology (ie. Design goal of BER <=3D 1E-12 over Ethernet often has an actual BER >> 1E-12). If such error-prone links are running at a high speed and with large segment sizes (jumbo / giant frames), there exists the real problem that within a short timeframe (weeks to months), TCP will deliver corrupted data, as CRC-16 was not able to catch the error. >From my point of view, I understood the recent discussions around RFC1146 in such a way, that for the intended purpose, which is to provide a stronger payload checksum (equivalent to SCTP levels), a new option would be required rather than reusing the alternate checksum option. The reasoning is that currently deployed gear, especially NAT / PAT gateways - which have to re-calculate the TCP Checksum as the Pseudo-Header is changed - might know about the originally defined alternate checksum algorithms, but not the new ones. Furthermore, RFC1146 specifically requires the Pseudo Header to be included - which one wouldn't want to do if only payload CRC is required. Providing a Payload-only CRC (ie. as the first TCP option), would enable the transparent forwarding of such a new option by NAT/PAT gateways without any problems. Of course, if RFC1146 could be extended to include algorithms which actually "violate" some of the specs of it, but maintain using the same TCP options with a new algorithm codepoint, that would be fine with me. But this would probably ask for a new RFC obsoliting RFC1146 anyway (in effect making it again historic :) ). Does that make sense? Thanks for your comments! Richard > -----Original Message----- > From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com]=20 > Sent: Donnerstag, 24. Juni 2010 20:17 > To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; Lars=20 > Eggert; tcpm@ietf.org > Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 >=20 > I have already communicated earlier that the TCP alternate=20 > checksum option needs to be removed from this list. Reason=20 > being it is still being used and there are proposals out=20 > there that is trying to make use of this option. Other than=20 > that point I am fine with this draft moving forward. >=20 > -Anantha > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From touch@isi.edu Fri Jun 25 11:37:53 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206C53A67E7 for ; Fri, 25 Jun 2010 11:37:53 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKZy4MAnJETE for ; Fri, 25 Jun 2010 11:37:51 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 0B1AB28C0E2 for ; Fri, 25 Jun 2010 11:37:40 -0700 (PDT) Received: from [75.212.178.160] (160.sub-75-212-178.myvzw.com [75.212.178.160]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5PIam9m009893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Jun 2010 11:36:59 -0700 (PDT) Message-ID: <4C24F73F.9060402@isi.edu> Date: Fri, 25 Jun 2010 11:36:47 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB5024D45892739B0F7102730" X-MailScanner-ID: o5PIam9m009893 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , "Biswas, Anumita" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jun 2010 18:37:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB5024D45892739B0F7102730 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Richard, Scheffenegger, Richard wrote: > Anantha, >=20 > I think for purposes of documenting "legacy" implementations, the > RFC1146 would still be valid. >=20 > I will try to define the goal of that recent proposal again, at least a= s > far as I understand this, so that we are all on the same page here. >=20 > Our expirience has shown, that TCP often runs over links with much > higher error rates, than intended for the technology (ie. Design goal o= f > BER <=3D 1E-12 over Ethernet often has an actual BER >> 1E-12). If such= > error-prone links are running at a high speed and with large segment > sizes (jumbo / giant frames), there exists the real problem that within= > a short timeframe (weeks to months), TCP will deliver corrupted data, a= s > CRC-16 was not able to catch the error. Just to confirm, is this a measured problem or a mathematical one? I.e., = have you seen this actually occur (i.e., TCP with invalid CRC-16 but valid che= cksum) in the wild, in a lab, or have you never seen it but consider it importan= t anyway? > From my point of view, I understood the recent discussions around > RFC1146 in such a way, that for the intended purpose, which is to > provide a stronger payload checksum (equivalent to SCTP levels), a new > option would be required rather than reusing the alternate checksum > option. The reasoning is that currently deployed gear, especially NAT /= > PAT gateways - which have to re-calculate the TCP Checksum as the > Pseudo-Header is changed - might know about the originally defined > alternate checksum algorithms, but not the new ones. NATs would recalculate the TCP checksum, which, for packets using alterna= te checksums as per 1146, would remain valid. The NAT would destroy the alte= rnate checksum, though, since it is defined by 1146 over the pseudoheader and T= CP header, so any changes to IP addresses or ports would result in an incorr= ect alternate checksum unless corrected by the NAT (which is, as you note, un= likely). So no matter how you proceed, you're better off with RFC 1146's version o= f how the existing checksum field is calculated. (your current proposal puts pa= rt of the new checksum in the TCP header field, which the NAT would interpret a= s invalid and drop). Which means you're calculating TWO checksums for every= packet - the current one (which the NAT will update), and the new (alternate) on= e (which NATs won't/can't update). > Furthermore, RFC1146 specifically requires the Pseudo Header to be > included - which one wouldn't want to do if only payload CRC is > required. Agreed. > Providing a Payload-only CRC (ie. as the first TCP option), would enabl= e > the transparent forwarding of such a new option by NAT/PAT gateways > without any problems. TCP options are not ordered. Their processing may be suggested, when defi= ning how the option interacts with other options, e.g. > Of course, if RFC1146 could be extended to include algorithms which > actually "violate" some of the specs of it, but maintain using the same= > TCP options with a new algorithm codepoint, that would be fine with me.= That would involve writing two docs (IMO): - one specifying a new algorithm you'd like to use - one specifying an alternate way to calculate the alt-cs value as a change to RFC1146 These are, in effect, two different issues. > But this would probably ask for a new RFC obsoliting RFC1146 anyway (in= > effect making it again historic :) ). It doesn't need to obsolete 1146; it does need to explain how an implemen= ter knows the difference between just a new algorithm and a different way to = compute it (i.e., over different data bits). That might be by redefining the code= s so that some codes mean "skip the header" and others don't, etc. The group w= ould need to discuss this as a legacy issue. An interesting question is why you care that the payload doesn't get accidentally altered, but you don't care if the port or address does (and= you don't notice), though. Joe >> -----Original Message----- >> From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com]=20 >> Sent: Donnerstag, 24. Juni 2010 20:17 >> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; Lars=20 >> Eggert; tcpm@ietf.org >> Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 >> >> I have already communicated earlier that the TCP alternate=20 >> checksum option needs to be removed from this list. Reason=20 >> being it is still being used and there are proposals out=20 >> there that is trying to make use of this option. Other than=20 >> that point I am fine with this draft moving forward. >> >> -Anantha >> _______________________________________________ >> 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 --------------enigB5024D45892739B0F7102730 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwk9z8ACgkQE5f5cImnZruUtACg/Hp6avyBD4osqhXYPGPgp/Uc QUsAoJygQfIfBujxgwdUL8bh08/B/Slv =yw86 -----END PGP SIGNATURE----- --------------enigB5024D45892739B0F7102730-- From hkchu@google.com Fri Jun 25 12:44:31 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7733A687D for ; Fri, 25 Jun 2010 12:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.377 X-Spam-Level: X-Spam-Status: No, score=-99.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaBf-0PXk5W6 for ; Fri, 25 Jun 2010 12:44:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D9FFA3A6837 for ; Fri, 25 Jun 2010 12:44:29 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o5PJiaSh019664 for ; Fri, 25 Jun 2010 12:44:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277495077; bh=/RIp3G2YLiixNBlDelAedUA74Iw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=QnzOiYjgOtp7sgdk1ATloab0kwc4AkU5U1CsS/nSlswhb7NChW0944B94+FClvkcw KnBydxj3zzlVT+U5SDiXw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Ne+/9j5FD2uXm2+bSTKTlwYY6vDA8aqh8nMvU6p4ZH1US5RpHcf6qyuj/boh/Dt8V 9bXX8s0Sayudi4BgQvj5A== Received: from qwd7 (qwd7.prod.google.com [10.241.193.199]) by wpaz17.hot.corp.google.com with ESMTP id o5PJiZpT008289 for ; Fri, 25 Jun 2010 12:44:36 -0700 Received: by qwd7 with SMTP id 7so1244896qwd.16 for ; Fri, 25 Jun 2010 12:44:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.88.21 with SMTP id y21mr984456qal.217.1277495075265; Fri, 25 Jun 2010 12:44:35 -0700 (PDT) Received: by 10.229.78.25 with HTTP; Fri, 25 Jun 2010 12:44:35 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Jun 2010 12:44:35 -0700 Message-ID: From: Jerry Chu To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] no meeting at Maastricht? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jun 2010 19:44:32 -0000 Hi Wes, How about other proposals that are still waiting to get on the WG agenda? (http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt http://www.ietf.org/id/draft-paxson-tcpm-rfc2988bis-00.txt) Since our "Increasing TCP's Initial Window" proposal in Anaheim, we've done more experiments and have a lot more data to present. We've also been hard pressed to make forward progress. I was hoping to meet you and many others f2f in Maastricht to discuss our data. It looks like the alternative is ICCRG. (A request for presentation slots has been sent to ICCRG.) Thanks, Jerry On Fri, Jun 25, 2010 at 5:14 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > > >-----Original Message----- > >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > >Jerry Chu > >Sent: Thursday, June 24, 2010 7:57 PM > >To: tcpm@ietf.org > >Subject: [tcpm] no meeting at Maastricht? > > > >Just saw the draft agenda but did not see tcpm? Are we not meeting at > >Maastricht? > > > >Thanks, > > > >Jerry > > > > Hi Jerry, we originally submitted a request for a meeting slot, but > withdrew it in the last couple days after looking at a few things, > including: > > - much of our work is in the phase where it's nearing completion > - among the active WG documents, tcp-security is the main one that > =A0could use face-time, but the editor can't make it to Maastricht > - availability of webex to IETF WGs seemed like a good way to make > =A0progress on tcp-security and other potential new documents > - we had seen reports that the agenda slots were heavily over-requested > =A0for Maastricht > - both WG chairs were having difficulty scheduling Maastricht travel > > So, with the combination of those factors, we decided it would be > more beneficial to setup a webex to work on tcp-security, at least, > and use the mailing list to close out any issues on the other documents. > I hope that makes sense; I had planned on communicating it to the list > in the next couple days, but your question pushed it out today :). > > -- > Wes Eddy > MTI Systems From touch@isi.edu Fri Jun 25 13:09:42 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD13C3A69D3 for ; Fri, 25 Jun 2010 13:09:42 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLN7t+q1d7TA for ; Fri, 25 Jun 2010 13:09:41 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id A400E3A686A for ; Fri, 25 Jun 2010 13:09:41 -0700 (PDT) Received: from [75.212.178.160] (160.sub-75-212-178.myvzw.com [75.212.178.160]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5PK8JcP002334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Jun 2010 13:08:30 -0700 (PDT) Message-ID: <4C250CB3.50609@isi.edu> Date: Fri, 25 Jun 2010 13:08:19 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jerry Chu References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCFD7238730A6247CAD619C54" X-MailScanner-ID: o5PK8JcP002334 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] no meeting at Maastricht? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jun 2010 20:09:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCFD7238730A6247CAD619C54 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FWIW, it might actually be more useful to have this viewed by ICCRG, and = have them post to TCPM with their view of these proposed changes. Joe Jerry Chu wrote: > Hi Wes, >=20 > How about other proposals that are still waiting to get on the WG agend= a? > (http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt > http://www.ietf.org/id/draft-paxson-tcpm-rfc2988bis-00.txt) >=20 > Since our "Increasing TCP's Initial Window" proposal in Anaheim, we've = done > more experiments and have a lot more data to present. We've also been h= ard > pressed to make forward progress. I was hoping to meet you and many oth= ers > f2f in Maastricht to discuss our data. It looks like the alternative > is ICCRG. (A request for presentation slots has been sent to ICCRG.) >=20 > Thanks, >=20 > Jerry >=20 > On Fri, Jun 25, 2010 at 5:14 AM, Eddy, Wesley M. (GRC-MS00)[ASRC > AEROSPACE CORP] wrote: >>> -----Original Message----- >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of >>> Jerry Chu >>> Sent: Thursday, June 24, 2010 7:57 PM >>> To: tcpm@ietf.org >>> Subject: [tcpm] no meeting at Maastricht? >>> >>> Just saw the draft agenda but did not see tcpm? Are we not meeting at= >>> Maastricht? >>> >>> Thanks, >>> >>> Jerry >>> >> Hi Jerry, we originally submitted a request for a meeting slot, but >> withdrew it in the last couple days after looking at a few things, >> including: >> >> - much of our work is in the phase where it's nearing completion >> - among the active WG documents, tcp-security is the main one that >> could use face-time, but the editor can't make it to Maastricht >> - availability of webex to IETF WGs seemed like a good way to make >> progress on tcp-security and other potential new documents >> - we had seen reports that the agenda slots were heavily over-requeste= d >> for Maastricht >> - both WG chairs were having difficulty scheduling Maastricht travel >> >> So, with the combination of those factors, we decided it would be >> more beneficial to setup a webex to work on tcp-security, at least, >> and use the mailing list to close out any issues on the other document= s. >> I hope that makes sense; I had planned on communicating it to the list= >> in the next couple days, but your question pushed it out today :). >> >> -- >> Wes Eddy >> MTI Systems > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------enigCFD7238730A6247CAD619C54 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwlDLMACgkQE5f5cImnZrtsZgCfdwTYYpmKVvGWw5uvR+MZmrE1 CkIAoKg4a1ZTpAuqVSzfXg0ULffcPOQk =h7CS -----END PGP SIGNATURE----- --------------enigCFD7238730A6247CAD619C54-- From wesley.m.eddy@nasa.gov Fri Jun 25 13:11:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38A9F3A6983 for ; Fri, 25 Jun 2010 13:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6YVy4VsVUbQ for ; Fri, 25 Jun 2010 13:11:38 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 815523A68E6 for ; Fri, 25 Jun 2010 13:11:38 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 16F69148035; Fri, 25 Jun 2010 15:11:47 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o5PKBkOW006456; Fri, 25 Jun 2010 15:11:46 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Fri, 25 Jun 2010 15:11:46 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Jerry Chu Date: Fri, 25 Jun 2010 15:11:45 -0500 Thread-Topic: [tcpm] no meeting at Maastricht? Thread-Index: AcsUntmdk2VEs0MFTDy1pTy9oZqP/gAAIEbg Message-ID: References: In-Reply-To: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-25_09:2010-02-06, 2010-06-25, 2010-06-25 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] no meeting at Maastricht? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jun 2010 20:11:40 -0000 >-----Original Message----- >From: Jerry Chu [mailto:hkchu@google.com] >Sent: Friday, June 25, 2010 3:45 PM >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >Cc: tcpm@ietf.org >Subject: Re: [tcpm] no meeting at Maastricht? > >Hi Wes, > >How about other proposals that are still waiting to get on the WG >agenda? >(http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt >http://www.ietf.org/id/draft-paxson-tcpm-rfc2988bis-00.txt) > >Since our "Increasing TCP's Initial Window" proposal in Anaheim, we've >done >more experiments and have a lot more data to present. We've also been >hard >pressed to make forward progress. I was hoping to meet you and many >others >f2f in Maastricht to discuss our data. It looks like the alternative >is ICCRG. (A request for presentation slots has been sent to ICCRG.) > Hi Jerry, thanks for the update. In both cases, would it be possible to get some of that new data out to the list? I think people would appreciate having time to look at it rather than seeing it for the first time in the meeting. As we found in Anaheim, there's more data then there is ample time to set the context, present it all, and answer questions about it, plus have the discussion about next steps. On the 2988bis document, since it's been discussed on the list and in person for a while, and evolved based on feedback, I'd guess it's time that we poll the list for adoption as a WG item; if you agree, we can kick that off. The way we left Anaheim's meeting was, I think, that you were going to update the draft to talk about why the minimum RTO isn't proposed for reduction as well, think about the effect on slow links with a long RTT, and potential effects of the lower RTO on other (non-HTTP) applications. If you want to add those prior to polling the WG for adoption of the document, it might help. Increasing the initial window was more hotly discussed both in TCPM and in ICCRG, but there doesn't seem to have been much follow-up discussion on the lists in the mean time. There was clear interest in continuing to talk about this in TCPM, though I didn't get the impression that we were ready to ask TCPM to make it a work item yet. I may be wrong. =20 I think this is the first agenda request for ICCRG in Maastricht, and people were really interested in it at the Anaheim meeting, so it should get ICCRG time in Maastricht. We had decided in Anaheim that we wanted to avoid giving the same presentation to both groups again, so if TCPM doesn't meet, that makes it easy (half-kidding). One suggestion was to have a joint meeting; this may be a good idea for Maastricht if the ICCRG chairs agree ;). -- Wes Eddy MTI Systems From fernando.gont.netbook.win@gmail.com Sat Jun 26 00:18:04 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CD53A689E for ; Sat, 26 Jun 2010 00:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hedJSB+rMbLo for ; Sat, 26 Jun 2010 00:18:03 -0700 (PDT) Received: from mail-gx0-f194.google.com (mail-gx0-f194.google.com [209.85.161.194]) by core3.amsl.com (Postfix) with ESMTP id 134223A6862 for ; Sat, 26 Jun 2010 00:18:02 -0700 (PDT) Received: by gxk23 with SMTP id 23so27573gxk.1 for ; Sat, 26 Jun 2010 00:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=JorOWmBDwWc2fGZsLAk8Dc8UTLxlCRY1KtkXUtbWWS0=; b=wufMZ4Wg2A6j5dDNVtLgFYbZYRbmfFkkBHSp/sGFBsf6mHD9r8EFQgy+Fvif0pmM04 uUqIx8ujLMjfcDKSSBAmlFivan+Gs5jpV8X7mYCeRDnexEGpas4kMRr+ytidMVh914nH YQV81/SeIRd31S3HSdzmCigdvmETRNW204FOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=dwAZpZHUohaIZ5ycMNQftlVipMgrYWJj6mCOlpnFbzLXyso8ke48wJYSyBKuINlQKs Ifnwx39r1u2Do67BdYSM4MJVMcjLU0jdPFM29/UQgcV5NOpb+bk6F3g8AuvCOGVt5RfY Gq4uZgEcIG3yUt+Q8GUH9m/IiSgHDKWCsdEQk= Received: by 10.101.135.31 with SMTP id m31mr2206293ann.164.1277536689202; Sat, 26 Jun 2010 00:18:09 -0700 (PDT) Received: from [190.48.244.65] ([190.48.244.65]) by mx.google.com with ESMTPS id b6sm12225310ani.1.2010.06.26.00.18.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 26 Jun 2010 00:18:03 -0700 (PDT) Sender: Fernando Gont Message-ID: <4C25A9A1.3040302@gont.com.ar> Date: Sat, 26 Jun 2010 04:17:53 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Joe Touch References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> In-Reply-To: <4C24F73F.9060402@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , "Biswas, Anumita" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jun 2010 07:18:04 -0000 Joe Touch wrote: >> Our expirience has shown, that TCP often runs over links with much >> higher error rates, than intended for the technology (ie. Design goal of >> BER <= 1E-12 over Ethernet often has an actual BER >> 1E-12). If such >> error-prone links are running at a high speed and with large segment >> sizes (jumbo / giant frames), there exists the real problem that within >> a short timeframe (weeks to months), TCP will deliver corrupted data, as >> CRC-16 was not able to catch the error. > > Just to confirm, is this a measured problem or a mathematical one? I.e., have > you seen this actually occur (i.e., TCP with invalid CRC-16 but valid checksum) > in the wild, in a lab, or have you never seen it but consider it important anyway? IIRC, wasn't this sort of what the SIGCOMM (?) paper "when the checksum and CRC disagree" (authored by J. Stone) was about? Just my two cents, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From L.Wood@surrey.ac.uk Sat Jun 26 01:49:55 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05C93A67D4 for ; Sat, 26 Jun 2010 01:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.463 X-Spam-Level: X-Spam-Status: No, score=-4.463 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+Reqr7iTfXF for ; Sat, 26 Jun 2010 01:49:54 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 7F3CA3A68E3 for ; Sat, 26 Jun 2010 01:49:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-3.tower-72.messagelabs.com!1277542202!3697151!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 8235 invoked from network); 26 Jun 2010 08:50:02 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-3.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 26 Jun 2010 08:50:02 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sat, 26 Jun 2010 09:50:02 +0100 From: To: Date: Sat, 26 Jun 2010 09:50:01 +0100 Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsVDJCUoCwHTqT3Qp6HJZ8HhzlXfg== Message-ID: <87877965-FBC4-4A67-917A-EB48BED2CBB1@surrey.ac.uk> References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> In-Reply-To: <4C24F73F.9060402@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-US 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, ananth@cisco.com, Anumita.Biswas@netapp.com, L.Wood@surrey.ac.uk Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jun 2010 08:49:55 -0000 Ethernet uses CRC-32, TCP's existing 16-bit checksum isn't a CRC. So I'm a bit puzzled by the question. The link CRC and TCP checksum can disagree. See Stone, J., Greenwald, M., Hughes, J., and C. Partridge, "Performance of checksums and CRCs over real data", IEEE Transactions on Networks vol. 6 issue 5, pp. 529-543, October 1998. Stone, J. and C. Partridge, "When the CRC and TCP Checksum Disagree", Proceedings of ACM SIGCOMM , September 2000. On 25 Jun 2010, at 19:36, Joe Touch wrote: >>=20 >> Our expirience has shown, that TCP often runs over links with much >> higher error rates, than intended for the technology (ie. Design goal of >> BER <=3D 1E-12 over Ethernet often has an actual BER >> 1E-12). If such >> error-prone links are running at a high speed and with large segment >> sizes (jumbo / giant frames), there exists the real problem that within >> a short timeframe (weeks to months), TCP will deliver corrupted data, as >> CRC-16 was not able to catch the error. >=20 > Just to confirm, is this a measured problem or a mathematical one? I.e., = have > you seen this actually occur (i.e., TCP with invalid CRC-16 but valid che= cksum) > in the wild, in a lab, or have you never seen it but consider it importan= t anyway? From touch@isi.edu Sat Jun 26 11:10:15 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79233A694A for ; Sat, 26 Jun 2010 11:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlHNalZm7UxS for ; Sat, 26 Jun 2010 11:10:08 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 62E4E3A6978 for ; Sat, 26 Jun 2010 11:10:08 -0700 (PDT) Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5QI9JkT020198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jun 2010 11:09:35 -0700 (PDT) Message-ID: <4C26424F.3020005@isi.edu> Date: Sat, 26 Jun 2010 11:09:19 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> <87877965-FBC4-4A67-917A-EB48BED2CBB1@surrey.ac.uk> In-Reply-To: <87877965-FBC4-4A67-917A-EB48BED2CBB1@surrey.ac.uk> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9E927AE6E8FE9E8A0F93003A" X-MailScanner-ID: o5QI9JkT020198 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, ananth@cisco.com, Anumita.Biswas@netapp.com Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jun 2010 18:10:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9E927AE6E8FE9E8A0F93003A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable L.Wood@surrey.ac.uk wrote: > Ethernet uses CRC-32, TCP's existing 16-bit checksum > isn't a CRC. So I'm a bit puzzled by the question. >=20 > The link CRC and TCP checksum can disagree. See *can*. The paper below did mathematical analyses, but didn't observe them= either in a lab or in the wild. I.e., that work didn't see places where it *did*= =2E Thus my question. I'm not asking whether this is important to address, just what the curren= t motivation is. The work below suggests using application-layer checksums.= That seems prudent for large transfers, but I don't see a motivation for needi= ng this fixed at the TCP layer... Joe > Stone, J., Greenwald, M., Hughes, J., and C. Partridge, > "Performance of checksums and CRCs over real data", IEEE > Transactions on Networks vol. 6 issue 5, pp. 529-543, > October 1998. >=20 > Stone, J. and C. Partridge, "When the CRC and TCP Checksum > Disagree", Proceedings of ACM SIGCOMM , September 2000. >=20 >=20 > On 25 Jun 2010, at 19:36, Joe Touch wrote: >>> Our expirience has shown, that TCP often runs over links with much >>> higher error rates, than intended for the technology (ie. Design goal= of >>> BER <=3D 1E-12 over Ethernet often has an actual BER >> 1E-12). If su= ch >>> error-prone links are running at a high speed and with large segment >>> sizes (jumbo / giant frames), there exists the real problem that with= in >>> a short timeframe (weeks to months), TCP will deliver corrupted data,= as >>> CRC-16 was not able to catch the error. >> >> Just to confirm, is this a measured problem or a mathematical one? I.e= =2E, have >> you seen this actually occur (i.e., TCP with invalid CRC-16 but valid = checksum) >> in the wild, in a lab, or have you never seen it but consider it impor= tant anyway? >=20 --------------enig9E927AE6E8FE9E8A0F93003A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwmQk8ACgkQE5f5cImnZruhwQCdH6sKS14rj47S0YcMHuPnDN/M aFUAnRGD09B4j9iFtGoFsV6byWTGijH8 =08DK -----END PGP SIGNATURE----- --------------enig9E927AE6E8FE9E8A0F93003A-- From L.Wood@surrey.ac.uk Sat Jun 26 11:31:07 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F4F3A692C for ; Sat, 26 Jun 2010 11:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wXLZNfhYD2d for ; Sat, 26 Jun 2010 11:31:04 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 9A4813A68BD for ; Sat, 26 Jun 2010 11:31:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-6.tower-72.messagelabs.com!1277577071!3734123!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 6107 invoked from network); 26 Jun 2010 18:31:11 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-6.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 26 Jun 2010 18:31:11 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Sat, 26 Jun 2010 19:31:11 +0100 From: To: Date: Sat, 26 Jun 2010 19:31:10 +0100 Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsVXcBLy3EU/jyZQk+zxivp0VFeXw== Message-ID: <9858250F-96F1-427A-A211-004A9FE3FE82@surrey.ac.uk> References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> <87877965-FBC4-4A67-917A-EB48BED2CBB1@surrey.ac.uk> <4C26424F.3020005@isi.edu> In-Reply-To: <4C26424F.3020005@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-US 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, ananth@cisco.com, Anumita.Biswas@netapp.com, L.Wood@surrey.ac.uk Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jun 2010 18:31:08 -0000 Joe, can you at least read the cited papers before making claims about them? >From the abstract of Stone's SIGCOMM paper: Traces of Internet packets from the past two years show that between 1 pack= et in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links wh= ere link-level CRCs should catch all but 1 in 4 billion errors.=20 [..] Much of our time has been spent negotiating access to data. s/*can*/*was observed to over two years in the wild*. TCP is supposed to provide a *reliable* transfer to application writers. Wi= th jumbo frames and the one's complement checksum, that is no longer true..= . and application writers don't necessarily have control over frame sizes. Needs fixing imo. On 26 Jun 2010, at 19:09, Joe Touch wrote: > L.Wood@surrey.ac.uk wrote: >> Ethernet uses CRC-32, TCP's existing 16-bit checksum >> isn't a CRC. So I'm a bit puzzled by the question. >>=20 >> The link CRC and TCP checksum can disagree. See >=20 > *can*. The paper below did mathematical analyses, but didn't observe them= either > in a lab or in the wild. I.e., that work didn't see places where it *did*= . Thus > my question. >=20 > I'm not asking whether this is important to address, just what the curren= t > motivation is. The work below suggests using application-layer checksums.= That > seems prudent for large transfers, but I don't see a motivation for needi= ng this > fixed at the TCP layer... >=20 > Joe >=20 >> Stone, J., Greenwald, M., Hughes, J., and C. Partridge, >> "Performance of checksums and CRCs over real data", IEEE >> Transactions on Networks vol. 6 issue 5, pp. 529-543, >> October 1998. >>=20 >> Stone, J. and C. Partridge, "When the CRC and TCP Checksum >> Disagree", Proceedings of ACM SIGCOMM , September 2000. >>=20 >>=20 >> On 25 Jun 2010, at 19:36, Joe Touch wrote: >>>> Our expirience has shown, that TCP often runs over links with much >>>> higher error rates, than intended for the technology (ie. Design goal = of >>>> BER <=3D 1E-12 over Ethernet often has an actual BER >> 1E-12). If suc= h >>>> error-prone links are running at a high speed and with large segment >>>> sizes (jumbo / giant frames), there exists the real problem that withi= n >>>> a short timeframe (weeks to months), TCP will deliver corrupted data, = as >>>> CRC-16 was not able to catch the error. >>>=20 >>> Just to confirm, is this a measured problem or a mathematical one? I.e.= , have >>> you seen this actually occur (i.e., TCP with invalid CRC-16 but valid c= hecksum) >>> in the wild, in a lab, or have you never seen it but consider it import= ant anyway? >>=20 >=20 Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From touch@isi.edu Sat Jun 26 12:06:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC653A67E7 for ; Sat, 26 Jun 2010 12:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw3JhJBbZrkg for ; Sat, 26 Jun 2010 12:06:39 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id F0FB43A6767 for ; Sat, 26 Jun 2010 12:06:38 -0700 (PDT) Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5QJ58kA029909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jun 2010 12:05:19 -0700 (PDT) Message-ID: <4C264F64.4010908@isi.edu> Date: Sat, 26 Jun 2010 12:05:08 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> <87877965-FBC4-4A67-917A-EB48BED2CBB1@surrey.ac.uk> <4C26424F.3020005@isi.edu> <9858250F-96F1-427A-A211-004A9FE3FE82@surrey.ac.uk> In-Reply-To: <9858250F-96F1-427A-A211-004A9FE3FE82@surrey.ac.uk> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB5BA7B3AA1731D326D3C7A2E" X-MailScanner-ID: o5QJ58kA029909 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, ananth@cisco.com, Anumita.Biswas@netapp.com Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jun 2010 19:06:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB5BA7B3AA1731D326D3C7A2E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable L.Wood@surrey.ac.uk wrote: >>From the abstract of Stone's SIGCOMM paper: >=20 > Traces of Internet packets from the past two years show that between 1 = packet > in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links w= here > link-level CRCs should catch all but 1 in 4 billion errors. > [..] Much of our time has been spent negotiating access to data. >=20 > s/*can*/*was observed to over two years in the wild*. See Section 4.3. End hosts that compute bad TCP checksums, or alter packets after the chec= ksums are validated aren't fixed by adding another checksum they can incorrectl= y implement. The only errors that appear to be happening due to paths were due to a fa= ulty router. Those errors were single bit errors, likely in memory of the rout= er (as per their observation, Sec 4.3.4). I.e., the authors believe the router w= as accepting a valid CRC in, modifying the packet, and transmitting one with= a (different) valid CRC out. The end receiver thus saw a packet with a vali= d CRC but would have seen an invalid TCP checksum. Their methodology captured packets at the link layer, (Sec 3.1): "For each complete packet, the software calculates the checksum and if the checksum fails, the entire packet is saved." Later they note how they find out of the segment was faulty due to a retransmission without the fault: "If the IP datagram contains a TCP segment, the capture program records what bytes were in the segment (on the as- sumption that the sequence numbers are correct!) and then looks for valid retransmissions of those bytes." The do not seek, nor did they find in the wild, a single packet where the= CRC was valid and the TCP checksum was valid, but the packet had changed in contents. That could have been attempted (perhaps with greater computatio= nal power), but was not. Joe --------------enigB5BA7B3AA1731D326D3C7A2E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwmT2QACgkQE5f5cImnZrvZ8gCfXOtWjoWGiZ9xSJNVTQ0gZ+fP wQ4AoOqOzVY3Z6CrrQyFMIw4gyfRGqBk =DlDr -----END PGP SIGNATURE----- --------------enigB5BA7B3AA1731D326D3C7A2E-- From L.Wood@surrey.ac.uk Sat Jun 26 12:16:36 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE6E3A6957 for ; Sat, 26 Jun 2010 12:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD455IV15lmB for ; Sat, 26 Jun 2010 12:16:34 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 5F2453A6897 for ; Sat, 26 Jun 2010 12:16:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-13.tower-82.messagelabs.com!1277579802!8905654!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 26676 invoked from network); 26 Jun 2010 19:16:42 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-13.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 26 Jun 2010 19:16:42 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sat, 26 Jun 2010 20:16:42 +0100 From: To: Date: Sat, 26 Jun 2010 20:16:41 +0100 Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsVZBwaEEkwsUtsRBCVisTj/bQ6CQ== Message-ID: References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> <87877965-FBC4-4A67-917A-EB48BED2CBB1@surrey.ac.uk> <4C26424F.3020005@isi.edu> <9858250F-96F1-427A-A211-004A9FE3FE82@surrey.ac.uk> <4C264F64.4010908@isi.edu> In-Reply-To: <4C264F64.4010908@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-US 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, ananth@cisco.com, Anumita.Biswas@netapp.com, L.Wood@surrey.ac.uk Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jun 2010 19:16:36 -0000 > The do not seek, nor did they find in the wild, a single packet where the= CRC > was valid and the TCP checksum was valid, but the packet had changed in > contents. Before going any further - did you really mean to write that? Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From touch@isi.edu Sat Jun 26 12:17:50 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B472F3A68F9 for ; Sat, 26 Jun 2010 12:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLvo3QTpIaqt for ; Sat, 26 Jun 2010 12:17:50 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id E029C3A6897 for ; Sat, 26 Jun 2010 12:17:49 -0700 (PDT) Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5QJGv15001804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jun 2010 12:17:08 -0700 (PDT) Message-ID: <4C265222.8030904@isi.edu> Date: Sat, 26 Jun 2010 12:16:50 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Fernando Gont References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> <4C25A9A1.3040302@gont.com.ar> In-Reply-To: <4C25A9A1.3040302@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2BDEFD6A7553E809B67320DB" X-MailScanner-ID: o5QJGv15001804 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , "Biswas, Anumita" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jun 2010 19:17:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2BDEFD6A7553E809B67320DB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >>> Our expirience has shown, that TCP often runs over links with much >>> higher error rates, than intended for the technology (ie. Design goal= of >>> BER <=3D 1E-12 over Ethernet often has an actual BER >> 1E-12). If su= ch >>> error-prone links are running at a high speed and with large segment >>> sizes (jumbo / giant frames), there exists the real problem that with= in >>> a short timeframe (weeks to months), TCP will deliver corrupted data,= as >>> CRC-16 was not able to catch the error. >> >> Just to confirm, is this a measured problem or a mathematical one? I.e= =2E, have >> you seen this actually occur (i.e., TCP with invalid CRC-16 but valid = checksum) >> in the wild, in a lab, or have you never seen it but consider it impor= tant anyway? To clarify, what I'm seeking is: a TCP segment that: has a valid TCP checksum actually has been received in the lab or wild would have an invalid CRC-16 as proposed in the ID i.e., this is a case where the ethernet or other link checksum would have= succeeded on all the hops, and the TCP checksum succeeds, so an error wou= ld NOT have been caught. That's the only case where we need to consider replacing the TCP checksum= =2E So far, it appears that the only reported evidence (the 2000 Sigcomm pape= r) looked only for real packets where the TCP checksum already failed. The case where both the link and TCP checks fail is in Sec 4.4 (I had mis= typed that as 5 previously), and is only a mathematical analysis of probability= =2E Joe --------------enig2BDEFD6A7553E809B67320DB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwmUiIACgkQE5f5cImnZrvFPgCgzdoU9192IcAsO7xCUexJNmiY bDAAn2MGswcaSJ82eYUK/g4oebJr9HGY =emFZ -----END PGP SIGNATURE----- --------------enig2BDEFD6A7553E809B67320DB-- From touch@isi.edu Sat Jun 26 12:26:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2333A697F for ; Sat, 26 Jun 2010 12:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nvn8QKcVKnpe for ; Sat, 26 Jun 2010 12:26:37 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 9E6673A6961 for ; Sat, 26 Jun 2010 12:26:37 -0700 (PDT) Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5QJPfFS003346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jun 2010 12:25:51 -0700 (PDT) Message-ID: <4C265435.3010601@isi.edu> Date: Sat, 26 Jun 2010 12:25:41 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> <87877965-FBC4-4A67-917A-EB48BED2CBB1@surrey.ac.uk> <4C26424F.3020005@isi.edu> <9858250F-96F1-427A-A211-004A9FE3FE82@surrey.ac.uk> <4C264F64.4010908@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig58030F2DC12F95C3CAED116E" X-MailScanner-ID: o5QJPfFS003346 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, ananth@cisco.com, Anumita.Biswas@netapp.com Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jun 2010 19:26:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58030F2DC12F95C3CAED116E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable L.Wood@surrey.ac.uk wrote: >> The do not seek, nor did they find in the wild, a single packet where = the CRC >> was valid and the TCP checksum was valid, but the packet had changed i= n >> contents. >=20 > Before going any further - did you really mean to write that? Yes. FWIW, the CRC I'm referring to above is the link CRC (CRC32 for Ethe= rnet). The only way a packet is accepted erroneously at a receiver, but would ca= use an problem, would be: link check OK TCP (1s compl) checksum OK new checksum FAIL I.e., the only reason a new TCP checksum would be useful is in this case.= If either of the link or existing TCP checks succeed, there's no new problem= =2E Please see draft-ietf-tcpm-anumita-tcp-stronger-checksum-00, e.g., in the= abstract, or Sec 1. In fact, the case they're considering is where real l= ink errors occur that are not detectable - not TCP/IP implementation errors o= r router memory errors, as were the only ones seen in the wild in the Sigco= mm paper. Joe --------------enig58030F2DC12F95C3CAED116E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwmVDUACgkQE5f5cImnZrv4YwCgkNCquqX1pCPBNoKdmbEl06R9 aD8AnRv/kXoBuNpF9/dk/m2ArNrYyj29 =I3LP -----END PGP SIGNATURE----- --------------enig58030F2DC12F95C3CAED116E-- From Anumita.Biswas@netapp.com Sun Jun 27 11:19:52 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21AB3A6951 for ; Sun, 27 Jun 2010 11:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNAUw3KQP0Wz for ; Sun, 27 Jun 2010 11:19:51 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 459B33A691B for ; Sun, 27 Jun 2010 11:19:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,492,1272870000"; d="scan'208";a="390644315" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 27 Jun 2010 11:19:45 -0700 Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o5RIJiPn025999; Sun, 27 Jun 2010 11:19:45 -0700 (PDT) Received: from SACMVEXC2-PRD.hq.netapp.com ([10.99.115.17]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Jun 2010 11:19:44 -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: Sun, 27 Jun 2010 11:19:44 -0700 Message-ID: In-Reply-To: <4C265435.3010601@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 thread-index: AcsVZZO4WFAaP+deTCaxlbWLLhKW7AAvV/Xw From: "Biswas, Anumita" To: "Joe Touch" , X-OriginalArrivalTime: 27 Jun 2010 18:19:44.0816 (UTC) FILETIME=[518FA300:01CB1625] Cc: tcpm@ietf.org, ananth@cisco.com Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 27 Jun 2010 18:19:52 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu]=20 > Sent: Saturday, June 26, 2010 12:26 PM > To: L.Wood@surrey.ac.uk > Cc: tcpm@ietf.org; ananth@cisco.com; Biswas, Anumita > Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 >=20 >=20 >=20 >=20 > L.Wood@surrey.ac.uk wrote: > >> The do not seek, nor did they find in the wild, a single=20 > packet where=20 > >> the CRC was valid and the TCP checksum was valid, but the=20 > packet had=20 > >> changed in contents. > >=20 > > Before going any further - did you really mean to write that? >=20 > Yes. FWIW, the CRC I'm referring to above is the link CRC=20 > (CRC32 for Ethernet). >=20 > The only way a packet is accepted erroneously at a receiver,=20 > but would cause an problem, would be: > link check OK > TCP (1s compl) checksum OK > new checksum FAIL >=20 > I.e., the only reason a new TCP checksum would be useful is=20 > in this case. If either of the link or existing TCP checks=20 > succeed, there's no new problem. >=20 > Please see draft-ietf-tcpm-anumita-tcp-stronger-checksum-00,=20 > e.g., in the abstract, or Sec 1. In fact, the case they're=20 > considering is where real link errors occur that are not=20 > detectable - not TCP/IP implementation errors or router=20 > memory errors, as were the only ones seen in the wild in the=20 > Sigcomm paper. >=20 Although the draft specifically calls out link errors, the draft by no means does not discard other sources of errors as are mentioned in those papers and are also referenced in the draft. I think the only reason the link errors were called out is because we *know* that is possible to have bad cables that can have higher BER than advertised. It is very hard to "detect" "undetectable" errors in the wild (actually by definition itself) and that is why it is worrisome to me. Its only possible to have a measurement like "Probability of undetected errors" rather than "X is the number of the undetected errors" in such cases. =20 I have heard only anecdotal evidence of a very large company doing very large copies of data (about a Tera Byte) across a local network and then finding bit corruptions in the data received on the other end - clearly the link CRC and the TCP 1s compl summation checksum failed to catch those errors.=20 In my own company, I have seen a case where a very large block (1460 bytes - a packet size) of data was replaced and gone undetected and we could not root cause the problem - the problem just disappeared after showing up for a few weeks - but in this case, it is possible that the corruption occurred before the data was sent by TCP itself.=20 So to me, to hinge whether we support a new TCP CRC based checksum or not, on practical experience in the wild, is probably not a safe approach. Ofcourse, if we had multiple proven examples of this in the wild, we'd feel more motivated to do this.=20 Also, I am more worried about packet sizes greater than 1500 bytes - where the Ethernet CRC checksum becomes weaker. Typical ethernet MTUs across the internet does not exceed 1500 bytes today - so right now, the problem scope is limited to Data Centers and other such local LANs where the end to end PMTU is greater than 1500 bytes. Based on comments from Richard Scheffenegger on the issue of middleboxes, I am planning to upload a new version of the draft that only checksums the data portion.=20 I also think TCP is *the* place for a stronger checksum, so that upper layers do not have to reinvent checksumming after rediscovering the weaknesses of the lower layer "reliable" checksums. It also allows for easy offloading to NICs as the TCP 16 bit checksum is offloaded today so that software gets rid of the computational overheads of a stronger checksum. It is much harder, almost impossible for an application layer checksum to be offloaded off to NICs. As NIC vendors, for obvious reasons, prefer only to offload standards based computation, and only in case where performance matters hugely are ready to offload work like TCP segmentation offload and receive side coalescing.=20 Thanks, Anumita > Joe >=20 >=20 From touch@isi.edu Sun Jun 27 11:51:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6933A6980 for ; Sun, 27 Jun 2010 11:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sELlh0rmmnTi for ; Sun, 27 Jun 2010 11:51:44 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 064043A6979 for ; Sun, 27 Jun 2010 11:51:44 -0700 (PDT) Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5RIpG8M000395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 27 Jun 2010 11:51:26 -0700 (PDT) Message-ID: <4C279DA4.8080604@isi.edu> Date: Sun, 27 Jun 2010 11:51:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Biswas, Anumita" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF135499E5D967A50BC629B9E" X-MailScanner-ID: o5RIpG8M000395 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, ananth@cisco.com, L.Wood@surrey.ac.uk Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 27 Jun 2010 18:51:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF135499E5D967A50BC629B9E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Anumita, Biswas, Anumita wrote: =2E.. > I have heard only anecdotal evidence of a very large company doing very= > large copies of data (about a Tera Byte) across a local network and the= n > finding bit corruptions in the data received on the other end - clearly= > the link CRC and the TCP 1s compl summation checksum failed to catch > those errors.=20 Well, that's the point. It's not so clear that the checks are what failed= =2E It could easily have been a bug in the implementation, or an error in the ha= rdware that corrupted data after it was received correctly. I.e., no matter how = good these checks, there are other ways in which data can be corrupted. > In my own company, I have seen a case where a very large block (1460 > bytes - a packet size) of data was replaced and gone undetected and we > could not root cause the problem - the problem just disappeared after > showing up for a few weeks - but in this case, it is possible that the > corruption occurred before the data was sent by TCP itself.=20 Yes, that's my concern. > So to me, to hinge whether we support a new TCP CRC based checksum or > not, on practical experience in the wild, is probably not a safe > approach. Ofcourse, if we had multiple proven examples of this in the > wild, we'd feel more motivated to do this.=20 I don't follow this logic. We have no measured evidence of this ever occu= rring. The evidence we have to date is that the end system software is more like= ly the problem. Everything so far points to the need for an application protocol check, i= =2Ee., a final, total transfer checksum on each large transaction (i.e., the whole= file). That was one conclusion of the 2000 paper, FWIW. > Also, I am more worried about packet sizes greater than 1500 bytes - > where the Ethernet CRC checksum becomes weaker. Typical ethernet MTUs > across the internet does not exceed 1500 bytes today - so right now, th= e > problem scope is limited to Data Centers and other such local LANs wher= e > the end to end PMTU is greater than 1500 bytes. That should be verifiable. Then again, if the CRC32 fails on jumboframes,= why would adding CRC16 at TCP help? other than the fact that it's a 'differen= t' sum? Your argument suggests that such data centers need different *ethernet* checksums, not different TCP ones. Then the data centers can leverage - a= nd reuse - that where necessary. Joe --------------enigF135499E5D967A50BC629B9E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwnnaQACgkQE5f5cImnZrsiRACg4Ov3yGob+nZF3V7XXQKvQG2p AmUAoMWoiASHSbNtEyJqCUtorqs0v63x =86Fh -----END PGP SIGNATURE----- --------------enigF135499E5D967A50BC629B9E-- From Anumita.Biswas@netapp.com Sun Jun 27 12:22:29 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BCAE3A69BF for ; Sun, 27 Jun 2010 12:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.732 X-Spam-Level: X-Spam-Status: No, score=-5.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3H6o8yhU9YI for ; Sun, 27 Jun 2010 12:22:25 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 92A2D3A69C8 for ; Sun, 27 Jun 2010 12:22:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,492,1272870000"; d="scan'208";a="390677895" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 27 Jun 2010 12:22:25 -0700 Received: from svlrsexc1-prd.hq.netapp.com (svlrsexc1-prd.hq.netapp.com [10.57.115.30]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o5RJMOKs029462; Sun, 27 Jun 2010 12:22:25 -0700 (PDT) Received: from SACMVEXC2-PRD.hq.netapp.com ([10.99.115.17]) by svlrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Jun 2010 12:22:24 -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: Sun, 27 Jun 2010 12:22:24 -0700 Message-ID: In-Reply-To: <4C279DA4.8080604@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 thread-index: AcsWKdbTsDOfNqeaTpC5e3sZg0qXtgAAkKqA From: "Biswas, Anumita" To: "Joe Touch" X-OriginalArrivalTime: 27 Jun 2010 19:22:24.0739 (UTC) FILETIME=[12A65B30:01CB162E] Cc: tcpm@ietf.org, ananth@cisco.com, L.Wood@surrey.ac.uk Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 27 Jun 2010 19:22:29 -0000 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu]=20 > Sent: Sunday, June 27, 2010 11:51 AM > To: Biswas, Anumita > Cc: L.Wood@surrey.ac.uk; tcpm@ietf.org; ananth@cisco.com > Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 >=20 >=20 > Hi, Anumita, >=20 > Biswas, Anumita wrote: > ... > > I have heard only anecdotal evidence of a very large company doing=20 > > very large copies of data (about a Tera Byte) across a=20 > local network=20 > > and then finding bit corruptions in the data received on=20 > the other end=20 > > - clearly the link CRC and the TCP 1s compl summation=20 > checksum failed=20 > > to catch those errors. >=20 > Well, that's the point. It's not so clear that the checks are=20 > what failed. It could easily have been a bug in the=20 > implementation, or an error in the hardware that corrupted=20 > data after it was received correctly. I.e., no matter how=20 > good these checks, there are other ways in which data can be=20 > corrupted. >=20 > > In my own company, I have seen a case where a very large=20 > block (1460=20 > > bytes - a packet size) of data was replaced and gone=20 > undetected and we=20 > > could not root cause the problem - the problem just=20 > disappeared after=20 > > showing up for a few weeks - but in this case, it is=20 > possible that the=20 > > corruption occurred before the data was sent by TCP itself. >=20 > Yes, that's my concern. >=20 > > So to me, to hinge whether we support a new TCP CRC based=20 > checksum or=20 > > not, on practical experience in the wild, is probably not a safe=20 > > approach. Ofcourse, if we had multiple proven examples of=20 > this in the=20 > > wild, we'd feel more motivated to do this. >=20 > I don't follow this logic. We have no measured evidence of=20 > this ever occurring. The evidence we have to date is that the=20 > end system software is more likely the problem. >=20 > Everything so far points to the need for an application=20 > protocol check, i.e., a final, total transfer checksum on=20 > each large transaction (i.e., the whole file). That was one=20 > conclusion of the 2000 paper, FWIW. >=20 I mentioned the advantage of being able to offload a TCP based checksum to the NIC. If I were to extend your argument that end system software is more likely the problem - a checksum over the whole file could also be prone to error.=20 I think we are only trying to deploy a "stronger" checksum - we are not making claims that it will find all problems in end to end software - and as such is not the strongest checksum. > > Also, I am more worried about packet sizes greater than=20 > 1500 bytes -=20 > > where the Ethernet CRC checksum becomes weaker. Typical=20 > ethernet MTUs=20 > > across the internet does not exceed 1500 bytes today - so=20 > right now,=20 > > the problem scope is limited to Data Centers and other such=20 > local LANs=20 > > where the end to end PMTU is greater than 1500 bytes. >=20 > That should be verifiable. Then again, if the CRC32 fails on=20 > jumboframes, why would adding CRC16 at TCP help? other than=20 > the fact that it's a 'different' sum? =20 The draft suggests using the Castagnoli 32-bit polynomial used in the "CRC 32C" algorithm which generates a 32 bit checksum quantity. No mention of CRC16. The draft specifies using a different "space" in the TCP options area, to transfer this checksum. It does not suggest using the 16-bit TCP checksum space for this value. It does debate over what to do with the 16-bit summation checksum. Now, after many discussions, it is more clear that we do need the 16-bit checksum as well to prevent middleboxes from breaking.=20 http://tools.ietf.org/html/draft-anumita-tcpm-stronger-checksum-00 Please read why the Castagnoli polynomial based CRC checksum is stronger than the Ethernet CRC32 checksum carried by the Ethernet frame.=20 Your argument suggests=20 > that such data centers need different *ethernet* checksums,=20 > not different TCP ones. Then the data centers can leverage -=20 > and reuse - that where necessary. The ideal way to do this would be to have Ethernet frames include the CRC32C checksum instead of the CRC32 checksum. But changing the Ethernet standard across the board is impossible due to backward compatibility issues. But TCP options provides a much easier path to introducing a stronger checksum as it does not break backward compatibility and can be offloaded to the NIC as well.=20 Data Centers are one place where Jumbo frames are deployed - but there could be others. So I don't understand what you mean by "data centers can leverage and reuse that where necessary". >=20 > Joe >=20 >=20 From touch@isi.edu Sun Jun 27 14:01:19 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B053A67B8 for ; Sun, 27 Jun 2010 14:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irqofnb1QtvB for ; Sun, 27 Jun 2010 14:01:18 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id BE2133A69F8 for ; Sun, 27 Jun 2010 14:01:18 -0700 (PDT) Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5RL03W2024285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 27 Jun 2010 14:00:13 -0700 (PDT) Message-ID: <4C27BBD2.4060002@isi.edu> Date: Sun, 27 Jun 2010 14:00:02 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Biswas, Anumita" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFB6599D31048C70783087F36" X-MailScanner-ID: o5RL03W2024285 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, ananth@cisco.com, L.Wood@surrey.ac.uk Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 27 Jun 2010 21:01:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB6599D31048C70783087F36 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Animita, Biswas, Anumita wrote: >> Everything so far points to the need for an application=20 >> protocol check, i.e., a final, total transfer checksum on=20 >> each large transaction (i.e., the whole file). That was one=20 >> conclusion of the 2000 paper, FWIW. >> > I mentioned the advantage of being able to offload a TCP based checksum= > to the NIC. If I were to extend your argument that end system software > is more likely the problem - a checksum over the whole file could also > be prone to error.=20 That's true too, but it would catch errors at all other places in the sta= ck, e.g., even errors that would not be caught by errors actually seen (e.g.,= in the 2000 paper). > I think we are only trying to deploy a "stronger" checksum - we are not= > making claims that it will find all problems in end to end software - > and as such is not the strongest checksum. My point above is that 'stronger' won't fix the flaws actually seen thus = far. =2E.. > Please read why the Castagnoli polynomial based CRC checksum is stronge= r > than the Ethernet CRC32 checksum carried by the Ethernet frame.=20 I have no question about that. This is a great argument to raise to the E= thernet community. > Your argument suggests=20 >> that such data centers need different *ethernet* checksums,=20 >> not different TCP ones. Then the data centers can leverage -=20 >> and reuse - that where necessary. > > The ideal way to do this would be to have Ethernet frames include the > CRC32C checksum instead of the CRC32 checksum. But changing the Etherne= t > standard across the board is impossible due to backward compatibility > issues.=20 That's no more true for ethernet than for TCP. > But TCP options provides a much easier path to introducing a > stronger checksum as it does not break backward compatibility and can b= e > offloaded to the NIC as well.=20 That may all be true, but as I've noted repeatedly, the errors *actually = seen* thus far would not be solved by a new, stronger TCP sum. Only an applicat= ion sum would have caught those errors. > Data Centers are one place where Jumbo frames are deployed - but there > could be others. So I don't understand what you mean by "data centers > can leverage and reuse that where necessary". I'm suggesting that this is a jumboframe problem. Fix it in the implement= ation of jumboframes, and all users of jumboframes will eventually benefit - i.= e., fix this at the Ethernet vendor level, and it can be used in all data centers= that use jumboframes. Note that those vendors *do* deploy new capabilities - e.g., see the IETF= TRILL WG. Joe --------------enigFB6599D31048C70783087F36 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwnu9IACgkQE5f5cImnZrt0aQCeJwkxSWWwQopP7E5m+Z+ikBhj eKkAoIL3xBZSEQvMzSsuhc4aZk5W4Qwg =fZg9 -----END PGP SIGNATURE----- --------------enigFB6599D31048C70783087F36-- From L.Wood@surrey.ac.uk Mon Jun 28 01:35:32 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028053A69A2 for ; Mon, 28 Jun 2010 01:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.821 X-Spam-Level: X-Spam-Status: No, score=-5.821 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weQIcpNj1eTt for ; Mon, 28 Jun 2010 01:35:30 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 533D13A67E3 for ; Mon, 28 Jun 2010 01:35:30 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-6.tower-72.messagelabs.com!1277714138!3945149!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 1294 invoked from network); 28 Jun 2010 08:35:38 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-6.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 28 Jun 2010 08:35:38 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Mon, 28 Jun 2010 09:35:38 +0100 From: To: Date: Mon, 28 Jun 2010 09:35:37 +0100 Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00 Thread-Index: AcsWnOK8q7Ic9XFdTySujVfZa7tw3w== Message-ID: References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> <87877965-FBC4-4A67-917A-EB48BED2CBB1@surrey.ac.uk> <4C26424F.3020005@isi.edu> <9858250F-96F1-427A-A211-004A9FE3FE82@surrey.ac.uk> <4C264F64.4010908@isi.edu> <4C265435.3010601@isi.edu> In-Reply-To: <4C265435.3010601@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-US 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, ananth@cisco.com, Anumita.Biswas@netapp.com, L.Wood@surrey.ac.uk Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 28 Jun 2010 08:35:32 -0000 On 26 Jun 2010, at 20:25, Joe Touch wrote: > The only way a packet is accepted erroneously at a receiver, but would ca= use an > problem, would be: > link check OK > TCP (1s compl) checksum OK > new checksum FAIL >=20 > I.e., the only reason a new TCP checksum would be useful is in this case.= If > either of the link or existing TCP checks succeed, there's no new problem= . An example of that scenario is an echo server: http://en.wikipedia.org/wiki/Echo_protocol http://www.faqs.org/rfcs/rfc862.html http://www.faqs.org/rfcs/rfc2075.html which swaps source and destination addresses. These are covered by the pseu= do-header check; the 1's complement checksum is oblivious to the byte swapping, and t= he echoed packet is still considered valid, even though it has been altered. A stronger TCP checksum would detect this modification, and have to be reco= mputed. much as payload checksums are recomputed through NAT boxes. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From hkchu@google.com Mon Jun 28 01:49:35 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009D728C0E4 for ; Mon, 28 Jun 2010 01:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.676 X-Spam-Level: X-Spam-Status: No, score=-104.676 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYXLGarAuKuI for ; Mon, 28 Jun 2010 01:49:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 32D1B28C0E7 for ; Mon, 28 Jun 2010 01:49:33 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o5S8nf3f013423 for ; Mon, 28 Jun 2010 01:49:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277714982; bh=rw+5OaDCBVHJbe9hUVRWQdSbfQw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=RrseaS1qYYo36ogbG4stf4wINchSurE3K3y0TH4h8ubyvqM0Aux3lIaBwJXeRL6Ee kZMBTHf89Ru6WPMHUGaPA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=UAOeeetQx3DvhI43FxXhhuihsQjDGxjXT7ajxyKd7FIkyID5N6cHuJtzf9gt8QmGx 9s0XWbkAfZu5MtRkvMhEQ== Received: from vws4 (vws4.prod.google.com [10.241.21.132]) by kpbe12.cbf.corp.google.com with ESMTP id o5S8nTXP015286 for ; Mon, 28 Jun 2010 01:49:40 -0700 Received: by vws4 with SMTP id 4so514851vws.16 for ; Mon, 28 Jun 2010 01:49:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.212.18 with SMTP id gq18mr2414246qcb.139.1277714980406; Mon, 28 Jun 2010 01:49:40 -0700 (PDT) Received: by 10.229.78.25 with HTTP; Mon, 28 Jun 2010 01:49:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Jun 2010 01:49:40 -0700 Message-ID: From: Jerry Chu To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] no meeting at Maastricht? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 28 Jun 2010 08:49:35 -0000 Hi Wes, On Fri, Jun 25, 2010 at 1:11 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: >>-----Original Message----- >>From: Jerry Chu [mailto:hkchu@google.com] >>Sent: Friday, June 25, 2010 3:45 PM >>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >>Cc: tcpm@ietf.org >>Subject: Re: [tcpm] no meeting at Maastricht? >> >>Hi Wes, >> >>How about other proposals that are still waiting to get on the WG >>agenda? >>(http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt >>http://www.ietf.org/id/draft-paxson-tcpm-rfc2988bis-00.txt) >> >>Since our "Increasing TCP's Initial Window" proposal in Anaheim, we've >>done >>more experiments and have a lot more data to present. We've also been >>hard >>pressed to make forward progress. I was hoping to meet you and many >>others >>f2f in Maastricht to discuss our data. It looks like the alternative >>is ICCRG. (A request for presentation slots has been sent to ICCRG.) >> > > > Hi Jerry, thanks for the update. =A0In both cases, would it be possible > to get some of that new data out to the list? =A0I think people would > appreciate having time to look at it rather than seeing it for the > first time in the meeting. =A0As we found in Anaheim, there's more > data then there is ample time to set the context, present it all, and > answer questions about it, plus have the discussion about next steps. Understood. Note that for Anaheim we published our data (in a paper) weeks before the meeting so it wasn't like people saw the data for the first time in the meeting. We hope to do the same this time. It's just that there has been a lot of work and we don't know how soon it can be completed... But will certainly try to publish the data as soon as we finis= h the analysis. > > On the 2988bis document, since it's been discussed on the list and > in person for a while, and evolved based on feedback, I'd guess it's > time that we poll the list for adoption as a WG item; if you agree, > we can kick that off. Yes, there have been some good questions and discussions, both at Anaheim's meeting and from the list. Although not all questions have been adequately answered, none of them seem to be directed to the overall feasiblity or usefulness of the draft. Therefore they should not be a gatin= g factor toward WG adoption. (Right?) > > The way we left Anaheim's meeting was, I think, that you were going > to update the draft to talk about why the minimum RTO isn't proposed > for reduction as well, Well, it was more like someone asked why reducing minRTO wasn't included and I asked why should it be included? (I.e., why must the two be bundled together?) Mark Allman also provided some explanation to the list. Frankly I'm not objecting to the idea of reducing minRTO at all - Linux and some other OSes have done that for years. But in-between other work we've taken on (e.g., the raising IW proposal) and our day jobs we're stretched very thin now. I think it's only fair for those who have asked about it to = pick up the work themselves, isn't it? >think about the effect on slow links with a > long RTT, and potential effects of the lower RTO on other (non-HTTP) The draft has been designed specifically to minimize the impact of spruriou= s RTO. There was also a question at Anaheim meeting regarding the possible interaction between the IW=3D10 and the initRTO=3D1sec proposals. Specifica= lly if IW has been changed to ten and 10 pkts were sent through a slow link of, e.g., 128Kbps, it will take more than 1sec to get all 10 pkts through (assu= ming Ethernet MTU), hence incurring a spurious RTO. My answer was that was not how the RTO timer works. (According to section 5.3 of RFC2988, the RTO timer will be restarted after each ACK that acks ne= w data. So the above spurious RTO won't happen.) > applications. =A0If you want to add those prior to polling the WG for > adoption of the document, it might help. > > Increasing the initial window was more hotly discussed both in TCPM > and in ICCRG, but there doesn't seem to have been much follow-up > discussion on the lists in the mean time. =A0There was clear interest > in continuing to talk about this in TCPM, though I didn't get the > impression that we were ready to ask TCPM to make it a work item > yet. =A0I may be wrong. What will be the criteria for a proposal to accepted as WG work item? Isn't the interest level the primary one (besides the benefit vs cost and feasibility equation. But one can argue the interest level should already reflect that)? I was a little confused by Lars' comment at Anaheim's meeting about the actual work for the WG being small, implying perhaps a working group only oversees the final "paper work". Yes the actual "paper work" as far as amending RFC3390 to raise IW may be small. But the amount of nvestigation work and large scale experiments and data analysis effort to justify/validate (or even disapprove) the proposal are huge. It just sounds very odd the latter are not conducted under the WG's guidance and auspices. Best, Jerry > > I think this is the first agenda request for ICCRG in Maastricht, and > people were really interested in it at the Anaheim meeting, so it > should get ICCRG time in Maastricht. =A0We had decided in Anaheim that > we wanted to avoid giving the same presentation to both groups again, > so if TCPM doesn't meet, that makes it easy (half-kidding). =A0One > suggestion was to have a joint meeting; this may be a good idea for > Maastricht if the ICCRG chairs agree ;). > > -- > Wes Eddy > MTI Systems > > From mcmanus@ducksong.com Mon Jun 28 08:31:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF7328C144; Mon, 28 Jun 2010 08:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnpb3i-BEgdb; Mon, 28 Jun 2010 08:31:47 -0700 (PDT) Received: from linode.ducksong.com (unknown [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 9CA253A6A66; Mon, 28 Jun 2010 08:31:20 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id 7F3AD10157; Mon, 28 Jun 2010 11:31:02 -0400 (EDT) Received: from [192.168.16.214] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id D02AC1014F; Mon, 28 Jun 2010 11:31:00 -0400 (EDT) From: Patrick McManus To: "Scheffenegger, Richard" In-Reply-To: <5FDC413D5FA246468C200652D63E627A09227C84@LDCMVEXC1-PRD.hq.netapp.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE0741@FIESEXC015.nsn-intra.net> <5FDC413D5FA246468C200652D63E627A09227C84@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 28 Jun 2010 11:31:02 -0400 Message-ID: <1277739062.2166.6.camel@tng> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: Multipath TCP Mailing List , tcpm@ietf.org, Hannes Tschofenig Subject: Re: [tcpm] Fwd: Probing the viability of TCP extensions X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 28 Jun 2010 15:31:48 -0000 On Wed, 2010-06-23 at 00:13 +0100, Scheffenegger, Richard wrote: > I am curious, out of the 1,07% of Hosts where ECN negotiation was > successful, is there any indication that internet routers are actually > making use of the ECT / CE codepoints in the IP header? > I have a blog post from 2007 on a different, much smaller, data set: http://bitsup.blogspot.com/2007/08/lamenting-ecn-deployments.html Basically, it looks at a small sample of 41K flows from my home network and sees 8% of them negotiated ECN end to end (which certainly skews high), but doesn't see a single instance of a packet being marked by a router. just one data point. From touch@isi.edu Mon Jun 28 09:40:41 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106BC3A6A71 for ; Mon, 28 Jun 2010 09:40:41 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQeH8FH6Vvg0 for ; Mon, 28 Jun 2010 09:40:39 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2C1243A6A7F for ; Mon, 28 Jun 2010 09:40:39 -0700 (PDT) Received: from [75.212.154.146] (146.sub-75-212-154.myvzw.com [75.212.154.146]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5SGSsDh012682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jun 2010 09:29:07 -0700 (PDT) Message-ID: <4C28CDC6.4020907@isi.edu> Date: Mon, 28 Jun 2010 09:28:54 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> <87877965-FBC4-4A67-917A-EB48BED2CBB1@surrey.ac.uk> <4C26424F.3020005@isi.edu> <9858250F-96F1-427A-A211-004A9FE3FE82@surrey.ac.uk> <4C264F64.4010908@isi.edu> <4C265435.3010601@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC8ED7236631A2A8E1BFABC87" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, ananth@cisco.com, Anumita.Biswas@netapp.com Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 28 Jun 2010 16:40:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC8ED7236631A2A8E1BFABC87 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable L.Wood@surrey.ac.uk wrote: > On 26 Jun 2010, at 20:25, Joe Touch wrote: >> The only way a packet is accepted erroneously at a receiver, but would= cause an >> problem, would be: >> link check OK >> TCP (1s compl) checksum OK >> new checksum FAIL >> >> I.e., the only reason a new TCP checksum would be useful is in this ca= se. If >> either of the link or existing TCP checks succeed, there's no new prob= lem. >=20 > An example of that scenario is an echo server: > http://en.wikipedia.org/wiki/Echo_protocol > http://www.faqs.org/rfcs/rfc862.html This RFC defines TCP and UDP echo services. Both loop data back to the so= urce, but at "layer 7" to the transport protocols. Both create new transport pa= ckets to send data back - in fact, the TCP variant might have different segment= boundaries, e.g., if the return path MTU is different. Both thus compute = a new transport checksum, so errors in either would not be detected by a strong= er transport checksum per se. > http://www.faqs.org/rfcs/rfc2075.html >=20 > which swaps source and destination addresses. These are covered by the = pseudo-header > check;=20 =2E.. > A stronger TCP checksum would detect this modification, and have to be > recomputed. much as payload checksums are recomputed through NAT boxes.= The pseudoheader is not covered by the current proposal, specifically to = support NAT traversal. Any device that recomputes the checksum on traversal (expl= icitly, or because that calculation is buried in the NIC and done automatically) = will defeat the ability of the checksum to detect errors inside that node. The only L7-L7 protection would be a full transfer checksum, which is not= being proposed. Joe --------------enigC8ED7236631A2A8E1BFABC87 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwozcYACgkQE5f5cImnZrshoQCfTBVEHKYDwN8XJ+fPNME5ec3q T6oAnjYM++fUpp0RG8H4gPFlFfYtI0oi =8yt0 -----END PGP SIGNATURE----- --------------enigC8ED7236631A2A8E1BFABC87-- From perfgeek@mac.com Mon Jun 28 18:53:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7823A6A0E for ; Mon, 28 Jun 2010 18:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJpGAFi-+WMO for ; Mon, 28 Jun 2010 18:53:01 -0700 (PDT) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by core3.amsl.com (Postfix) with ESMTP id 4D9053A6881 for ; Mon, 28 Jun 2010 18:53:01 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L4R007AJ6K29230@asmtp017.mac.com> for tcpm@ietf.org; Mon, 28 Jun 2010 18:52:51 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1006280151 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2010-06-29_01:2010-02-06, 2010-06-29, 2010-06-28 signatures=0 Message-id: <351D0AEF-4DA3-49DF-9CDB-2897C478BBE6@mac.com> From: rick jones To: Joe Touch In-reply-to: <4C27BBD2.4060002@isi.edu> Date: Mon, 28 Jun 2010 18:52:48 -0700 References: <4C27BBD2.4060002@isi.edu> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, ananth@cisco.com, L.Wood@surrey.ac.uk, "Biswas, Anumita" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jun 2010 01:53:02 -0000 On Jun 27, 2010, at 2:00 PM, Joe Touch wrote: > I'm suggesting that this is a jumboframe problem. Fix it in the > implementation > of jumboframes, and all users of jumboframes will eventually benefit > - i.e., fix > this at the Ethernet vendor level, and it can be used in all data > centers that > use jumboframes. JumboFrames (9000 bytes or better) in "Ethernet" appeared back in the mid to late 1990's with the Alteon AceNIC right? (at least that is my first conscious memory of them) They are still outside the IEEE framework. Frame sizes going extra-IEEE is one thing, I'm rather more skeptical of CRC's being able to go extra-IEEE. Given there is perhaps a snowball's chance of the IEEE blessing JumboFrames, I suspect there is less than a snowball's chance of them blessing another CRC to address anything presented as "a jumboframe problem." So, to push a fix down to the link-layer is to effectively assert it is something that need never be fixed. rick jones http://homepage.mac.com/perfgeek From touch@isi.edu Mon Jun 28 19:47:15 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B51A3A684E for ; Mon, 28 Jun 2010 19:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOrcok41TRAj for ; Mon, 28 Jun 2010 19:46:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 500283A657C for ; Mon, 28 Jun 2010 19:46:55 -0700 (PDT) Received: from [192.168.1.96] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5T2kXuR010765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jun 2010 19:46:43 -0700 (PDT) Message-ID: <4C295E88.1060505@isi.edu> Date: Mon, 28 Jun 2010 19:46:32 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: rick jones References: <4C27BBD2.4060002@isi.edu> <351D0AEF-4DA3-49DF-9CDB-2897C478BBE6@mac.com> In-Reply-To: <351D0AEF-4DA3-49DF-9CDB-2897C478BBE6@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig45B0C0C96CFBDCBFEE8C2726" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, ananth@cisco.com, L.Wood@surrey.ac.uk, "Biswas, Anumita" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jun 2010 02:47:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig45B0C0C96CFBDCBFEE8C2726 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable rick jones wrote: >=20 > On Jun 27, 2010, at 2:00 PM, Joe Touch wrote: >> I'm suggesting that this is a jumboframe problem. Fix it in the >> implementation >> of jumboframes, and all users of jumboframes will eventually benefit -= >> i.e., fix >> this at the Ethernet vendor level, and it can be used in all data >> centers that >> use jumboframes. >=20 > JumboFrames (9000 bytes or better) in "Ethernet" appeared back in the > mid to late 1990's with the Alteon AceNIC right? (at least that is my > first conscious memory of them) They are still outside the IEEE > framework. Frame sizes going extra-IEEE is one thing, I'm rather more > skeptical of CRC's being able to go extra-IEEE. Given there is perhaps= > a snowball's chance of the IEEE blessing JumboFrames, I suspect there i= s > less than a snowball's chance of them blessing another CRC to address > anything presented as "a jumboframe problem." So, to push a fix down t= o > the link-layer is to effectively assert it is something that need never= > be fixed. I'm claiming there are only two issues that have been raised: - a real, measured problem with intermediate devices which won't be fixed with a link or transport solution but could be addressed with an L7 transfer sum - a hypothetical link problem for some links (i.e., jumboframes) which ought to be fixed by the vendors who support jumboframes Note that I didn't say "IEEE" here. The same vendors that have a de-facto standard for jumboframes are the ones who can fix their mess with a jumboframe CRC ;-) Neither one warrants a TCP solution, IMO. Joe --------------enig45B0C0C96CFBDCBFEE8C2726 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwpXogACgkQE5f5cImnZruTjwCfTDKcOKTwtvbZhMLnuKvSvyyS 55kAoI34hNsC1gmjN6V3Kr+9KkXbB2Kh =sY6h -----END PGP SIGNATURE----- --------------enig45B0C0C96CFBDCBFEE8C2726-- From alexander.zimmermann@nets.rwth-aachen.de Tue Jun 29 02:32:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145023A6814 for ; Tue, 29 Jun 2010 02:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a465KTqdLuJw for ; Tue, 29 Jun 2010 02:32:43 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id B02F43A67C0 for ; Tue, 29 Jun 2010 02:32:42 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L4R003FQRUSJ1E0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 29 Jun 2010 11:32:52 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.53,503,1272837600"; d="sig'?scan'208";a="63217999" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 29 Jun 2010 11:32:53 +0200 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L4R00L49RUMER50@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 29 Jun 2010 11:32:52 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-10-996550870 From: Alexander Zimmermann In-reply-to: Date: Tue, 29 Jun 2010 11:32:57 +0200 Content-transfer-encoding: 7bit Message-id: <094F4803-1A6A-4E90-BA29-94E250D8B810@nets.rwth-aachen.de> References: To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , David Borman X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WGLC for LCD document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jun 2010 09:32:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-10-996550870 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi folks, the WGLC has been closed for a while (end of april) without any negative = response. I think it is time to ship the doc to the IESG. What do you think Wes/David? Comments from the list? Alex Am 13.04.2010 um 22:37 schrieb Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE = CORP]: > This email starts a working group last call in TCPM for the > document on making TCP more robust to long connectivity > disruptions: >=20 > http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-lcd/ >=20 > As discussed at IETF 77, this has been stable for a while, and > is believed to be complete, aside from checking on how SYNs are > handled and making this clear, as Mark Handley raised. >=20 > This WGLC is planned to last for 2 weeks, and end on April 28. > Please send your comments on this document to the TCPM list. >=20 >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-10-996550870 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkwpvckACgkQdyiq39b9uS4DYgCeN82IKO66L+X75+sSjRYTd3Gi 9kEAnibsDYx06LdMHC5i4rbxuZdp5oXy =N2O2 -----END PGP SIGNATURE----- --Apple-Mail-10-996550870-- From perfgeek@mac.com Tue Jun 29 08:09:35 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D8A3A6877 for ; Tue, 29 Jun 2010 08:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAgNofnb3jD2 for ; Tue, 29 Jun 2010 08:09:34 -0700 (PDT) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by core3.amsl.com (Postfix) with ESMTP id 9489F3A6A4E for ; Tue, 29 Jun 2010 08:09:34 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L4S003PS7G8NL80@asmtp020.mac.com> for tcpm@ietf.org; Tue, 29 Jun 2010 08:09:45 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1006290073 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2010-06-29_02:2010-02-06, 2010-06-29, 2010-06-29 signatures=0 Message-id: From: rick jones To: Joe Touch In-reply-to: <4C295E88.1060505@isi.edu> Date: Tue, 29 Jun 2010 08:09:43 -0700 References: <4C27BBD2.4060002@isi.edu> <351D0AEF-4DA3-49DF-9CDB-2897C478BBE6@mac.com> <4C295E88.1060505@isi.edu> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, ananth@cisco.com, L.Wood@surrey.ac.uk, "Biswas, Anumita" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jun 2010 15:09:35 -0000 On Jun 28, 2010, at 7:46 PM, Joe Touch wrote: > > - a hypothetical link problem for some links (i.e., jumboframes) > which ought to be fixed by the vendors who support jumboframes > > Note that I didn't say "IEEE" here. The same vendors that have > a de-facto standard for jumboframes are the ones who can fix > their mess with a jumboframe CRC ;-) I think that is a place where one should be careful what one wishes for. If the NIC vendors become too accustomed to going off the standard body reservation at the link-layer, chances are they and the other vendor types with which they interact won't make much of distinction for transport. rick jones http://homepage.mac.com/perfgeek From touch@isi.edu Tue Jun 29 09:51:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043463A696B for ; Tue, 29 Jun 2010 09:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQcPjZSZhyww for ; Tue, 29 Jun 2010 09:51:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 936C63A6848 for ; Tue, 29 Jun 2010 09:51:36 -0700 (PDT) Received: from [75.213.82.102] (102.sub-75-213-82.myvzw.com [75.213.82.102]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5TGlw78025685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jun 2010 09:48:09 -0700 (PDT) Message-ID: <4C2A23BE.9020905@isi.edu> Date: Tue, 29 Jun 2010 09:47:58 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: rick jones References: <4C27BBD2.4060002@isi.edu> <351D0AEF-4DA3-49DF-9CDB-2897C478BBE6@mac.com> <4C295E88.1060505@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1ED91298260CD57847A74F6E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, ananth@cisco.com, L.Wood@surrey.ac.uk, "Biswas, Anumita" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jun 2010 16:51:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1ED91298260CD57847A74F6E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable rick jones wrote: >=20 > On Jun 28, 2010, at 7:46 PM, Joe Touch wrote: >> >> - a hypothetical link problem for some links (i.e., jumboframes) >> which ought to be fixed by the vendors who support jumboframes= >> >> Note that I didn't say "IEEE" here. The same vendors that have= >> a de-facto standard for jumboframes are the ones who can fix >> their mess with a jumboframe CRC ;-) >=20 > I think that is a place where one should be careful what one wishes for= =2E > If the NIC vendors become too accustomed to going off the standard body= > reservation at the link-layer, chances are they and the other vendor > types with which they interact won't make much of distinction for > transport. They already are going "off the reservation" with jumboframes. Those are = either useless (as you imply above, e.g., because of lack of interoperability), = or important to support properly. If jumboframes aren't used, AFAICT there's no problem to solve. If they a= re used, the problem lies in the jumboframes themselves using an insufficien= t CRC. Joe --------------enig1ED91298260CD57847A74F6E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwqI74ACgkQE5f5cImnZrv7DgCgkaAHC95Sm3XW8U5JQmHKFWhq xEgAn1hAAl+GyXUFEfaC8CkNE4KoZqOm =pC+m -----END PGP SIGNATURE----- --------------enig1ED91298260CD57847A74F6E-- From lars.eggert@nokia.com Tue Jun 29 10:15:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139CC3A6C11 for ; Tue, 29 Jun 2010 10:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+-NOcyxyiG2 for ; Tue, 29 Jun 2010 10:15:26 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0D2103A6C04 for ; Tue, 29 Jun 2010 10:15:23 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5THFSd9025416; Tue, 29 Jun 2010 20:15:28 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 20:15:27 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 20:15:27 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5THFQC6018999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jun 2010 20:15:26 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-25-1024291338; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> Date: Tue, 29 Jun 2010 18:15:18 +0100 Message-Id: <94AE5A53-9C1C-474B-9D8A-ACF2D0FC2842@nokia.com> References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Tue, 29 Jun 2010 20:15:20 +0300 (EEST) X-OriginalArrivalTime: 29 Jun 2010 17:15:27.0315 (UTC) FILETIME=[AB233230:01CB17AE] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , "Biswas, Anumita" Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jun 2010 17:15:44 -0000 --Apple-Mail-25-1024291338 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-6-25, at 16:07, Scheffenegger, Richard wrote: > Of course, if RFC1146 could be extended to include algorithms which > actually "violate" some of the specs of it, but maintain using the = same > TCP options with a new algorithm codepoint, that would be fine with = me. >=20 > But this would probably ask for a new RFC obsoliting RFC1146 anyway = (in > effect making it again historic :) ). yes, that was my thinking too. I don't think we can fix RFC1146 in a way = that is backwards compatible, so we might as well make it historic and = then decide if we need a new piece of work in this space. Lars= --Apple-Mail-25-1024291338 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYyOTE3 MTUxOFowIwYJKoZIhvcNAQkEMRYEFB8jNNzG5VInJud81cS7RcdnuZl1MIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAEabx9+tB5SvMenK3LoUqajVz3kKoP+jAvAU0//EBqjzfZAldSAr 174huUMprLQQvKnikkf3oWUufAzMYBvL8AeQEl+Wg5Ymia0cxCC7krLrVw3rnIWtJ3lqwYUPI89e 4NwMHGx5KyfBZWW6/fVwQ8WYGzU7DAWIA20gcRvhExJ6gGnoa0cd/HuS+5NyLGyEJ1Mnz8jr49rc h8lKiaUJw6gGF/19+9oJ7l27apeQXep8RKwrNjRt8FCTXIoGGUojQu1DlhmEVNUeejbjZxs25ZEH npdkMbp5QkgKkSa5kSR0lhB04uoov5Cze28VaapDpQYVlvHPd8ZFebtg4+drU6sAAAAAAAA= --Apple-Mail-25-1024291338-- From fred@cisco.com Tue Jun 29 11:31:10 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D743A689F; Tue, 29 Jun 2010 11:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.856 X-Spam-Level: X-Spam-Status: No, score=-109.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp9hwC7Bp0tQ; Tue, 29 Jun 2010 11:31:04 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id F17663A6C14; Tue, 29 Jun 2010 11:30:50 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP7YKUyrR7Hu/2dsb2JhbACfR3GmPJpPhSQEg2k X-IronPort-AV: E=Sophos;i="4.53,506,1272844800"; d="scan'208";a="228588914" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 29 Jun 2010 18:31:01 +0000 Received: from Freds-Computer.local (sjc-vpn6-179.cisco.com [10.21.120.179]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5TIUqeH015719; Tue, 29 Jun 2010 18:30:55 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 29 Jun 2010 11:31:01 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 29 Jun 2010 11:31:01 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <1277739062.2166.6.camel@tng> Date: Tue, 29 Jun 2010 11:29:08 -0700 Message-Id: References: <3D3C75174CB95F42AD6BCC56E5555B4502BE0741@FIESEXC015.nsn-intra.net> <5FDC413D5FA246468C200652D63E627A09227C84@LDCMVEXC1-PRD.hq.netapp.com> <1277739062.2166.6.camel@tng> To: Patrick McManus X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Multipath TCP Mailing List , tcpm@ietf.org, Hannes Tschofenig Subject: Re: [tcpm] [multipathtcp] Fwd: Probing the viability of TCP extensions X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jun 2010 18:31:10 -0000 how many routers does it show that had ECN marking configured active? On Jun 28, 2010, at 8:31 AM, Patrick McManus wrote: > On Wed, 2010-06-23 at 00:13 +0100, Scheffenegger, Richard wrote: > >> I am curious, out of the 1,07% of Hosts where ECN negotiation was >> successful, is there any indication that internet routers are actually >> making use of the ECT / CE codepoints in the IP header? >> > > I have a blog post from 2007 on a different, much smaller, data set: > > http://bitsup.blogspot.com/2007/08/lamenting-ecn-deployments.html > > Basically, it looks at a small sample of 41K flows from my home network > and sees 8% of them negotiated ECN end to end (which certainly skews > high), but doesn't see a single instance of a packet being marked by a > router. > > just one data point. > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp http://www.ipinc.net/IPv4.GIF From mcmanus@ducksong.com Tue Jun 29 16:04:25 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5D03A69F0; Tue, 29 Jun 2010 16:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.682 X-Spam-Level: X-Spam-Status: No, score=0.682 tagged_above=-999 required=5 tests=[AWL=1.422, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQJ7vALHah5H; Tue, 29 Jun 2010 16:04:24 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id C4B653A6957; Tue, 29 Jun 2010 16:04:24 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id A2DC3101F5; Tue, 29 Jun 2010 19:04:36 -0400 (EDT) Received: from [192.168.16.214] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id C3E361014F; Tue, 29 Jun 2010 19:04:34 -0400 (EDT) From: Patrick McManus To: Fred Baker In-Reply-To: References: <3D3C75174CB95F42AD6BCC56E5555B4502BE0741@FIESEXC015.nsn-intra.net> <5FDC413D5FA246468C200652D63E627A09227C84@LDCMVEXC1-PRD.hq.netapp.com> <1277739062.2166.6.camel@tng> Content-Type: text/plain; charset="UTF-8" Date: Tue, 29 Jun 2010 19:04:39 -0400 Message-ID: <1277852679.2166.21.camel@tng> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: Multipath TCP Mailing List , tcpm@ietf.org, Hannes Tschofenig Subject: Re: [tcpm] [multipathtcp] Fwd: Probing the viability of TCP extensions X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jun 2010 23:04:25 -0000 On Tue, 2010-06-29 at 11:29 -0700, Fred Baker wrote: > how many routers does it show that had ECN marking configured active? not a single ecn capable flow in the data contained a ecn-marked packet. This was general Internet traffic, including a lot of spam SMTP flows from abroad that you would think would have a reasonable chance of seeing congestion. I don't see how to identify which if any routers had ecn configured on, but the implication is that it is very few if any. (or that there is no congestion on "my" internet :)), right? From hagen@jauu.net Tue Jun 29 17:04:54 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F67A3A6A51; Tue, 29 Jun 2010 17:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.212 X-Spam-Level: X-Spam-Status: No, score=0.212 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPn3M03Vro4i; Tue, 29 Jun 2010 17:04:53 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id DD9423A6A35; Tue, 29 Jun 2010 17:04:52 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id DD9D0F4413A; Wed, 30 Jun 2010 02:05:01 +0200 (CEST) Date: Wed, 30 Jun 2010 02:04:59 +0200 From: Hagen Paul Pfeifer To: Patrick McManus Message-ID: <20100630000459.GA3043@nuttenaction> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE0741@FIESEXC015.nsn-intra.net> <5FDC413D5FA246468C200652D63E627A09227C84@LDCMVEXC1-PRD.hq.netapp.com> <1277739062.2166.6.camel@tng> <1277852679.2166.21.camel@tng> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1277852679.2166.21.camel@tng> 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.20 (2009-06-14) Cc: Multipath TCP Mailing List , tcpm@ietf.org, Hannes Tschofenig , Fred Baker Subject: Re: [tcpm] [multipathtcp] Fwd: Probing the viability of TCP extensions X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 30 Jun 2010 00:04:54 -0000 * Patrick McManus | 2010-06-29 19:04:39 [-0400]: >> how many routers does it show that had ECN marking configured active? > >not a single ecn capable flow in the data contained a ecn-marked packet. >This was general Internet traffic, including a lot of spam SMTP flows >from abroad that you would think would have a reasonable chance of >seeing congestion. > >I don't see how to identify which if any routers had ecn configured on, >but the implication is that it is very few if any. (or that there is no >congestion on "my" internet :)), right? ;-) was this insight surprising? ECN lacks one important attribute: it is not good-natured if things goes wrong. What would you do if you had to configure a core router: a) configure the router and setup standard RED/WRED where you _know_ that if you are on fire and drop packets the sender will reduce their sending rate or b) configure ECN and _hope_ that everything between you, the receiver the last but not least the sender goes right? Eventually you will think about the advantages of ECN and the reduced TCP/DCCP/whatever retransmissions but is this more important then the former paragraph? I don't think that this is the view of the guys at the core routers. ECN is a technical superior answer for a question questioned in a complex and fragile environment. HGN PS: anyway, nice analysis! ;) -- Hagen Paul Pfeifer || http://blog.jauu.net/ Telephone: +49 174 5455209 || Key Id: 0x98350C22 Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22