From lars.eggert@nokia.com Mon Feb 1 01:30: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 83A3D3A6933 for ; Mon, 1 Feb 2010 01:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 XIoNrGypR3vY for ; Mon, 1 Feb 2010 01:30:04 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 90B973A68F5 for ; Mon, 1 Feb 2010 01:30:03 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o119Tcvv023349; Mon, 1 Feb 2010 11:29:44 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 11:29:26 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 11:29:26 +0200 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 o119TOMc005361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2010 11:29:24 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-21--1053461670; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 1 Feb 2010 11:29:06 +0200 In-Reply-To: <50DBEEEC-1EA0-4C8D-8B52-3063F13BAB7B@nokia.com> To: Fernando Gont , "tcpm@ietf.org WG" References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A3EC.20308@gont.com.ar> <4B6204F7.1070908@gont.com.ar> <50DBEEEC-1EA0-4C8D-8B52-3063F13BAB7B@nokia.com> Message-Id: <729695D0-6DF5-4599-908C-9B375C30E9E8@nokia.com> X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 01 Feb 2010 11:29:13 +0200 (EET) X-OriginalArrivalTime: 01 Feb 2010 09:29:26.0331 (UTC) FILETIME=[0BF4A0B0:01CAA321] X-Nokia-AV: Clean Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 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, 01 Feb 2010 09:30:05 -0000 --Apple-Mail-21--1053461670 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-1-29, at 11:32, Eggert Lars (Nokia-NRC/Espoo) wrote: > On 2010-1-28, at 23:43, Fernando Gont wrote: >>> If yes, then with delayed ACKs (or otherwise in corner cases) >>> acked_packet_size is actually larger than maxsizesent always.=20 >>=20 >> Well, that depends on the amount of data you send. But yes, you could >> say that "acked_packet_size is actually larger than maxsizesent = *usually*". >>=20 >>> On >>> second reading, I don't think that's a problem for the technique, = but >>> the name and description of the variable confused me earlier. >>=20 >> Should I add a clarification? >=20 > I think this would make sense. You might also want to change the name = of the variable. this is the only issue I haven't seen addressed in -10. I'll start the IETF Last Call based on -10 now; we can work out the few = remaining issues (incl. this one) in parallel. Lars= --Apple-Mail-21--1053461670 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 MQ8XDTEwMDIwMTA5MjkwN1owIwYJKoZIhvcNAQkEMRYEFC8hZGDxzYUu+ZHpUEJod8YX6/fMMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDRSTKseY5nmisOSQiqKAmWa70Ug8GJOuRD0lZGT7XClxGmHMcWAt+/tHXikyeDgfw6hMBo KQH7AjfGy7WhnI4B7CxKbOurkEQsT5bJOUzFMdfKWoqt61bdhF2v93wJRfIajJFqyZYhXhImm/HC 5ZXjK6udAigN1Yx5+Xosn+8M7CP/KDhCCAdIIZG0y8k6/61AhoM6cBs6LkV32QH1IU0M0pGw15/i /cgLcgFh16A2QUA1R3yCC6piYscFix7eKX1bafMYf8Iz8cvN8aTH90sMJBo65vkqzv2KSR8NEmN+ 8oQ69V6hf0Cbz2CATWsq/y3GFceChRRNFSgedR40nlwTAAAAAAAA --Apple-Mail-21--1053461670-- From michawe@ifi.uio.no Mon Feb 1 04:48:03 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 C24B13A692E for ; Mon, 1 Feb 2010 04:48:03 -0800 (PST) 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 CGb3PVGNsSDN for ; Mon, 1 Feb 2010 04:48:02 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 821713A6898 for ; Mon, 1 Feb 2010 04:48:02 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1Nbvhj-0002yj-3q for tcpm@ietf.org; Mon, 01 Feb 2010 13:48:35 +0100 Received: from div-8021x-dhcp216.uio.no ([193.157.176.225]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1Nbvhi-0004WN-Oc for tcpm@ietf.org; Mon, 01 Feb 2010 13:48:35 +0100 Message-Id: <50E51A6B-FC91-460A-9B78-EA19BB07640C@ifi.uio.no> From: Michael Welzl To: "tcpm@ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 1 Feb 2010 13:48:34 +0100 X-Mailer: Apple Mail (2.935.3) X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 5 sum rcpts/h 7 sum msgs/h 6 total rcpts 5839 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C7D74DC68CF0FCB2376C7013E396A0459820838E X-UiO-SPAM-Test: remote_host: 193.157.176.225 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 739 max/h 12 blacklist 0 greylist 0 ratelimit 0 Subject: [tcpm] ECN Nonce (RFC 3540) implementation for Linux available 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, 01 Feb 2010 12:48:03 -0000 Dear all, I'm sorry, I guess I should have sent this message much earlier - time has passed, and I have simply forgotten about it... I just wanted to inform the group that we have made an updated implementation of the ECN Nonce (RFC 3540) for Linux, and it's available from here: http://heim.ifi.uio.no/michawe/research/projects/spurious/index.html We made that for a follow-up idea, also described on the same page; my plan was to do a follow-up paper with real-life tests, and then (one day... in the unforeseeable future...) suggest updating the ECN spec to include it. To better understand whether it makes any sense to continue working on this at all, I'm curious about the state of things there - does anyone (intend/want to) use the ECN Nonce at all? Is there still anyone out there planning / hoping / wishing that this specification moves forward towards Proposed Standard, given that Bob Briscoe repeatedly stated that it shouldn't? Cheers, Michael From fernando.gont.netbook.win@gmail.com Mon Feb 1 05:14: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 B72FB28C302 for ; Mon, 1 Feb 2010 05:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 s5tR60XQdLqj for ; Mon, 1 Feb 2010 05:14:14 -0800 (PST) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id E894028C2B0 for ; Mon, 1 Feb 2010 05:12:54 -0800 (PST) Received: by ywh38 with SMTP id 38so872351ywh.6 for ; Mon, 01 Feb 2010 05:13:24 -0800 (PST) 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=/J3TXxSjySii45Boev5ZLO9iFyX6Sl1L7rW0F4eSj3I=; b=MdHwO8W96jJGVji3nwbsXL/TtOM0sC+yJ7P/N3S+2gtTIc8hhoYgblzC4F4UV8OguF ZIpsI9lr1ljO6DG6tMtpnkbV2CsvIa6QrEpzMFy4eaGhwcfD8g8XTB+tn0NYrtUBaFm8 2HkfeC8XyeGcwr0syvdCYXmVAJd2/5Ds9grMk= 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=ugGiZAstAVZWDUjAV/Ky/7F6tSH929FdBLQ0MP7WoIJ/g21nwhkMQ3wI5qdIsL/Oyo aKVjuaz8vDBoR9q/b/0Xzn1cjGx0c4MtRJRrAsack8cwqrsQiLSYPZfao525KGRtfCsQ R72AMFo7G1HwSj2FZJLSVg4irDO94E+My51Kg= Received: by 10.101.149.39 with SMTP id b39mr5178155ano.17.1265030003925; Mon, 01 Feb 2010 05:13:23 -0800 (PST) Received: from ?192.168.0.100? (144-174-17-190.fibertel.com.ar [190.17.174.144]) by mx.google.com with ESMTPS id 4sm1746647ywi.54.2010.02.01.05.13.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Feb 2010 05:13:22 -0800 (PST) Sender: Fernando Gont Message-ID: <4B66D363.5070205@gont.com.ar> Date: Mon, 01 Feb 2010 10:13:07 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A3EC.20308@gont.com.ar> <4B6204F7.1070908@gont.com.ar> <50DBEEEC-1EA0-4C8D-8B52-3063F13BAB7B@nokia.com> <729695D0-6DF5-4599-908C-9B375C30E9E8@nokia.com> In-Reply-To: <729695D0-6DF5-4599-908C-9B375C30E9E8@nokia.com> 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 WG" Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 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, 01 Feb 2010 13:14:15 -0000 Hello, Lars, >>>> If yes, then with delayed ACKs (or otherwise in corner cases) >>>> acked_packet_size is actually larger than maxsizesent always. >>> Well, that depends on the amount of data you send. But yes, you >>> could say that "acked_packet_size is actually larger than >>> maxsizesent *usually*". >>> >>>> On second reading, I don't think that's a problem for the >>>> technique, but the name and description of the variable >>>> confused me earlier. >>> Should I add a clarification? >> I think this would make sense. You might also want to change the >> name of the variable. > > this is the only issue I haven't seen addressed in -10. Note that I did add a clarification and tweaked the relevant text (see the diff). I didn't rename the variable, though, as I couldn't come up with a better name (on first thought, at least), and because I thought that the clarification I added would do. But please let me know if you have any thoughts on how to improve this. > I'll start the IETF Last Call based on -10 now; we can work out the > few remaining issues (incl. this one) in parallel. FWIW, in the next rev I would be replacing the current disclaimer with: We note that the counter-measures discussed in this document are not part of standard TCP behavior and this document does not change that state of affairs. The consensus of the TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to document this widespread implementation of TCP behavior and neither to change the TCP standard nor to make any new recommendations herein. (This is Joe's proposed text, leaving out the "non-standard", as agreed by others so far...) Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From wwwrun@core3.amsl.com Mon Feb 1 05:40:52 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8006128C0D7; Mon, 1 Feb 2010 05:40:52 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100201134052.8006128C0D7@core3.amsl.com> Date: Mon, 1 Feb 2010 05:40:52 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-icmp-attacks (ICMP attacks against TCP) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 13:40:52 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'ICMP attacks against TCP ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-02-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14301&rfc_flag=0 From johnwheffner@gmail.com Wed Feb 3 05:25:12 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 41D273A6AFD for ; Wed, 3 Feb 2010 05:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 2hAlaUBij7jH for ; Wed, 3 Feb 2010 05:25:11 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 14AE53A6AF7 for ; Wed, 3 Feb 2010 05:25:10 -0800 (PST) Received: by ewy28 with SMTP id 28so1391279ewy.28 for ; Wed, 03 Feb 2010 05:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k0FQCVrq2906h+hrmB5GBaIlN1MXIjX4Jn4/66hbppM=; b=jX4gQBdL1vMxb1obabRXiPcN89+Wz6Ez+68NkUPmq+SfKxYgKDnybtYMkeu4LIKJ2u WlGZKUa+ZpfWZD1fOwSCg3w2ZGE32fswHg+pZuUE5OBg0UWcR2IAcsNdWy5H/aVkKCV9 JOZbuTQmm6+FbDv+mBK2IU9VHcz4sVjXvHot0= 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:content-transfer-encoding; b=iRFOhw8R51euNKIIQaL3+MM7IfP/U9dJIdd3vjiCCmDyXu5lu3OGSuQSEuZ2TIdg0I Yb2ZkfVgPomQ9U5j8Z3H2vXbYb5XwYzziHXT4xUqHSv/cYwzIvYAIyKa40KmvDQb1iZE CeZOFP/WXOiw557b4OJPt2kSZyvcjxoIW75OU= MIME-Version: 1.0 Received: by 10.216.89.85 with SMTP id b63mr3939348wef.175.1265203548885; Wed, 03 Feb 2010 05:25:48 -0800 (PST) In-Reply-To: <201001290029.BAA11165@TR-Sys.de> References: <201001290029.BAA11165@TR-Sys.de> Date: Wed, 3 Feb 2010 08:25:48 -0500 Message-ID: <1e41a3231002030525p2259759aja3ba9d21a52be825@mail.gmail.com> From: John Heffner To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] your responses to my comments on "the WG" 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, 03 Feb 2010 13:25:12 -0000 I'll agree contribution to this list can be discouraged by some of the more zealous contributors. (But I'm not sure this list is a special case.) However, I also believe there is and should be a very high technical bar for standards to come out of this group. A lot of the drafts submitted to not clear it, and I personally do not think the bar is set too high. It can be a tough call when we have a proposal that we know is flawed, yet is better than nothing. As an implementor, I'll weigh the trade-offs and make a choice -- and usually provide a switch to turn the feature off. When it comes to publishing standards, I'm more conservative. Bad code is easier to change than a bad standard. -John On Thu, Jan 28, 2010 at 7:29 PM, Alfred H=CEnes wrote: > Thanks to all ... > > for the overwhelming consenting and supportive feedback > received so far (off-list) from listeners to the TCPM list, > regarding my comments in item > =A0 =A0(2) "the WG" > of my recent posting [1] ! > > It's really encouraging to see that the "silent majority" > is not _always_ so silent. =A0 :-) > > Please admit that I'll not have the time to respond individually. > > As a matter of course and due diligence, I confirm that I will not > disclose to any other person any names or affiliations of senders. > > Best regards, > =A0Alfred. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes =A0 | =A0Alfred Hoenes =A0 Dipl.-Math., Dipl.-Phys= . =A0| > | Gerlinger Strasse 12 =A0 | =A0Phone: (+49)7156/9635-0, Fax: -18 =A0 =A0= =A0 =A0 | > | D-71254 =A0Ditzingen =A0 =A0 | =A0E-Mail: =A0ah@TR-Sys.de =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > +------------------------+--------------------------------------------+ > > [1] > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From lars.eggert@nokia.com Wed Feb 3 06:28: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 4B0EB3A6C36 for ; Wed, 3 Feb 2010 06:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 pYiw6EpQIspM for ; Wed, 3 Feb 2010 06:28:28 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 3D5A13A6ACE for ; Wed, 3 Feb 2010 06:28:28 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o13ET7x9005629 for ; Wed, 3 Feb 2010 16:29:07 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 16:29:07 +0200 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.3959); Wed, 3 Feb 2010 16:29:06 +0200 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 o13ET5em010730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Feb 2010 16:29:05 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-33--862669653; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 3 Feb 2010 16:28:58 +0200 Message-Id: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> To: "tcpm@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Wed, 03 Feb 2010 16:28:59 +0200 (EET) X-OriginalArrivalTime: 03 Feb 2010 14:29:06.0629 (UTC) FILETIME=[3DDFDF50:01CAA4DD] X-Nokia-AV: Clean Subject: [tcpm] TCP tuning 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, 03 Feb 2010 14:28:29 -0000 --Apple-Mail-33--862669653 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Jerry Chu has recently started the discussion on whether we need to = think about tweaking TCP for the "modern Internet." Just came across = another presentation from (AFAICT) another corner of Google that makes = similar arguments. FYI: = http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Changing_T= CP_Slow_Start.pdf This topic seems to be gaining momentum, and the WG should take some = time considering if there is work here for it. Lars= --Apple-Mail-33--862669653 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 MQ8XDTEwMDIwMzE0Mjg1OVowIwYJKoZIhvcNAQkEMRYEFNUh2X6xX9oWf4UIo5pfX29mbd/VMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCeY1Z6k8w8EzruxGLTvRkXHvFfihGVUZdclH+0/oTLwO9gsSbCKCEuN0yWYU23mwlrJQws b4Zwowt9ARcdfDpBkB7LnBj83F/CWikaw7dwHcHd3RiEpuGtSVs3GSu9O0Pk4aNpJ7ronUePgE8K 6Ddme0izjp1ud/Wr9Qk1X8b+AMwsjYyx+6F+yEtkMWQQgtkV2EeIUYakEk6xlp8osCLkAD9/WVyT elU4NCqELpQ5jld5ep/sgEXwD3T+fZ8rnmKZ7ONqHOW8FG91R9PYt0zqGvBaKSCvOdddLBVBCt5E 8jl5lRDttPN0tlBI6NMLwITE6bMtHd+TehUFSW1c9QLkAAAAAAAA --Apple-Mail-33--862669653-- From alangley@gmail.com Wed Feb 3 06:40:26 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 0482C3A68A7 for ; Wed, 3 Feb 2010 06:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TjfB1wYKhhwX for ; Wed, 3 Feb 2010 06:40:25 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E39E43A691C for ; Wed, 3 Feb 2010 06:40:24 -0800 (PST) Received: by vws13 with SMTP id 13so319301vws.31 for ; Wed, 03 Feb 2010 06:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=1qzd9sxvX8HC0atSC2z5sVlBV5vh1qazKV3EdZcjJGE=; b=t4brd/vH8oTwub7fxYB/XxIxR8g7rh8RpOkVG74UPL7PcHpVj2/PrSL0gs2ZdiQS1Y H5BiAjP25GIx+ks5i5Ip4xcjilQTvJqaXSkan/TmvrotH616C65HPKQngttiLBSMGrkw GVNYh4idVA2GH5YKzzbzzxQanfBhTLU23nkMg= 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=f5GB6DCcYXhy20nRzpt1EEfMuRFgcAb+tDNmWCYFya17CxswcJJEFW3uN2Emx1O9Ev 120Xbu3HSNGFAPu4ABQj4Fp5q1NqvIQHtkzVIeC/iAhNwdgy/10eLr3gUfxLqSo+wsK/ E+DZEv1zssP5peOQyR4O62w9A5Yw/PI/nf3RA= MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.220.124.106 with SMTP id t42mr6546002vcr.32.1265208063549; Wed, 03 Feb 2010 06:41:03 -0800 (PST) In-Reply-To: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> Date: Wed, 3 Feb 2010 09:41:03 -0500 X-Google-Sender-Auth: a4461cbbf5db5f87 Message-ID: <396556a21002030641x41074f9cyef07cadd3cd01666@mail.gmail.com> From: Adam Langley To: Lars Eggert Content-Type: text/plain; charset=UTF-8 Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 14:40:26 -0000 On Wed, Feb 3, 2010 at 9:28 AM, Lars Eggert wrote: > Jerry Chu has recently started the discussion on whether we need to think about tweaking TCP for the "modern Internet." Just came across another presentation from (AFAICT) another corner of Google that makes similar arguments. > > FYI: http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf > > This topic seems to be gaining momentum, and the WG should take some time considering if there is work here for it. The slide format of the presentation possibly isn't the easiest to read, but I hope that it's understandable. If people have questions, please do ask. Mike, Jerry and I are all (mostly) in the same corner of Google although the above file is regarding SPDY, our new HTTP serialisation: http://dev.chromium.org/spdy/spdy-whitepaper Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From michawe@ifi.uio.no Wed Feb 3 06:41: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 7627F3A6A21 for ; Wed, 3 Feb 2010 06:41:57 -0800 (PST) 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 ghjA+jz+QOH0 for ; Wed, 3 Feb 2010 06:41:56 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 8565D3A68A7 for ; Wed, 3 Feb 2010 06:41:56 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1NcgRB-0008IZ-Fd for tcpm@ietf.org; Wed, 03 Feb 2010 15:42:37 +0100 Received: from div-8021x-dhcp216.uio.no ([193.157.176.225]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1NcgRB-0007rl-4Q for tcpm@ietf.org; Wed, 03 Feb 2010 15:42:37 +0100 Message-Id: <81ECEA1A-690F-4EAE-A586-BBC498877DB8@ifi.uio.no> From: Michael Welzl To: "tcpm@ietf.org WG" In-Reply-To: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 3 Feb 2010 15:42:36 +0100 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> X-Mailer: Apple Mail (2.935.3) X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 6 sum msgs/h 4 total rcpts 5913 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 951F7A77DBA8971357A892708791B5DEB694DCB3 X-UiO-SPAM-Test: remote_host: 193.157.176.225 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 784 max/h 12 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 14:41:57 -0000 Hi all, (sorry if this is a bit off topic, as the mentioned presentation is mainly about using a larger initial window) In the context of the discussion that Jerry brought up on parameter tuning, one question that was raised was the initial RTO during the SYN - SYN/ ACK exchange. I understand that we can't recommend to resend SYN's more aggressively because this might cause a server to be overloaded with SYN's, but why do we have to wait extremely long until we resend SYN/ACKs? Back then, when I asked, I got no answer. Both Jerry and I pointed to our measurement results which show that the effect is nonneglible. So I'll use this chance to ask again :-) Cheers, Michael On Feb 3, 2010, at 3:28 PM, Lars Eggert wrote: > Hi, > > Jerry Chu has recently started the discussion on whether we need to > think about tweaking TCP for the "modern Internet." Just came across > another presentation from (AFAICT) another corner of Google that > makes similar arguments. > > FYI: http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf > > This topic seems to be gaining momentum, and the WG should take some > time considering if there is work here for it. > > Lars_______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From Michael.Scharf@alcatel-lucent.com Wed Feb 3 07:16: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 D7FA73A6C44 for ; Wed, 3 Feb 2010 07:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 8Urn-GNg5R3D for ; Wed, 3 Feb 2010 07:16:52 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id AF6613A6991 for ; Wed, 3 Feb 2010 07:16:51 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id o13FHUUe014364 for ; Wed, 3 Feb 2010 16:17:31 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 3 Feb 2010 16:17:29 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP tuning Thread-Index: Acqk3XLzrGK3T9V1Rri9FSyzcg9I/wAAnUiQ References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 15:16:53 -0000 > This topic seems to be gaining momentum, and the WG should=20 > take some time considering if there is work here for it. IMHO there could indeed be room for increasing the initial window. If most data transfers continue to be smaller than 3 MSS, a larger initial window would not necessarily cause harm, as it is seldomly used. Still, this would speed up those data transfers that currently suffer from Slow-Start. In the past, I have played a little bit with an initial window e. g. of 10 MSS, and that worked surprisingly well. Also, one could combine a larger initial window with other mechanisms that would reduce the aggressiveness of the flow startup. Maybe it is indeed time to think about the Slow-Start once again. Michael From v13@v13.gr Wed Feb 3 07:32: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 DB2853A6C22 for ; Wed, 3 Feb 2010 07:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 67cIyn+DJGa7 for ; Wed, 3 Feb 2010 07:32:44 -0800 (PST) Received: from alpha.it.teithe.gr (alpha.it.teithe.gr [195.251.240.232]) by core3.amsl.com (Postfix) with ESMTP id 9C5F33A6C27 for ; Wed, 3 Feb 2010 07:32:42 -0800 (PST) Received: from v.localnet (v.it.teithe.gr [195.251.123.206]) by alpha.it.teithe.gr (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o13FXKVp008744 for ; Wed, 3 Feb 2010 17:33:22 +0200 From: Stefanos Harhalakis To: tcpm@ietf.org Date: Wed, 3 Feb 2010 17:33:21 +0200 User-Agent: KMail/1.12.4 (Linux/2.6.32-trunk-amd64; KDE/4.3.4; x86_64; ; ) References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002031733.21841.v13@v13.gr> Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 15:32:45 -0000 On Wednesday 03 of February 2010, SCHARF, Michael wrote: > In the past, I have played a little bit with an initial window e. g. of > 10 MSS, and that worked surprisingly well. Also, one could combine a > larger initial window with other mechanisms that would reduce the > aggressiveness of the flow startup. Maybe it is indeed time to think > about the Slow-Start once again. IMHO, such a discussion should also consider the user perspective and distinguish two types of TCP connections: Those that result into user- observable delay (e.g. HTTP) and those that don't (e.g. SMTP). Such a modification could be made configurable by applications: Web servers (and browsers) could use a larger initial window while SMTP servers/clients could use the current approach. From kacheong.poon@sun.com Wed Feb 3 08:13:09 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 CA5E33A6B18 for ; Wed, 3 Feb 2010 08:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 tdtZJUK6iZbt for ; Wed, 3 Feb 2010 08:13:08 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id C0CDF3A6AF8 for ; Wed, 3 Feb 2010 08:13:08 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o13GDpTf007251 for ; Wed, 3 Feb 2010 16:13:51 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o13GDnDn195717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Feb 2010 08:13:50 -0800 (PST) Message-ID: <4B69A0BD.2060708@sun.com> Date: Thu, 04 Feb 2010 00:13:49 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100115 Thunderbird/3.0.1 MIME-Version: 1.0 To: tcpm@ietf.org References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 16:13:09 -0000 On 02/ 3/10 11:17 PM, SCHARF, Michael wrote: > In the past, I have played a little bit with an initial window e. g. of > 10 MSS, and that worked surprisingly well. Also, one could combine a > larger initial window with other mechanisms that would reduce the > aggressiveness of the flow startup. Maybe it is indeed time to think > about the Slow-Start once again. FWIW, I've come across traces showing some network equipment uses an initial window as large as 16 segments (some kind of turbo mode). It is probably true many stacks already use a much larger initial window than recommended in the RFC. Just that people have been very quiet about this. -- K. Poon. kacheong.poon@sun.com From touch@ISI.EDU Wed Feb 3 08:33: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 C667028C169 for ; Wed, 3 Feb 2010 08:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 xVoS0sn4edpV for ; Wed, 3 Feb 2010 08:33:42 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 221AF28C163 for ; Wed, 3 Feb 2010 08:33:42 -0800 (PST) Received: from [70.213.181.125] (125.sub-70-213-181.myvzw.com [70.213.181.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13GX2EE009324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 08:33:04 -0800 (PST) Message-ID: <4B69A53E.2050508@isi.edu> Date: Wed, 03 Feb 2010 08:33:02 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> In-Reply-To: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD1BB1C8EA5881D97AA5A4196" X-MailScanner-ID: o13GX2EE009324 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 16:33:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD1BB1C8EA5881D97AA5A4196 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > Hi, >=20 > Jerry Chu has recently started the discussion on whether we need to thi= nk about tweaking TCP for the "modern Internet." Just came across another= presentation from (AFAICT) another corner of Google that makes similar a= rguments. >=20 > FYI: http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Ch= anging_TCP_Slow_Start.pdf I'm curious about the tests described. 200ms seems very high for an RTT. Even over a cell wireless link (3G), I see latencies that are typically half that. I wonder what the improvement is for a 50-80ms RTT. I'm not excited about the prospects of a potential tragedy of the commons issue (i.e., this works now, but may not work as nicely when everyone tries this), especially for a mere 50% improvement in latency. It'd be useful to review the set of proposed mods and claims of impact for each, though the last time we saw this there seemed to be quite a few questions about the experiments presented. Joe --------------enigD1BB1C8EA5881D97AA5A4196 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) iEYEARECAAYFAktppT4ACgkQE5f5cImnZrtqgwCfbMXo4/Ao+8iXphF786LmgC9z kpQAoJDzeG0YNl8eqReG5PwpgsqidQGz =t009 -----END PGP SIGNATURE----- --------------enigD1BB1C8EA5881D97AA5A4196-- From kacheong.poon@sun.com Wed Feb 3 09: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 E603E3A69E2 for ; Wed, 3 Feb 2010 09:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 VuIV73RS2dj3 for ; Wed, 3 Feb 2010 09:04:54 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id DFA6E3A6B2D for ; Wed, 3 Feb 2010 09:04:49 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o13H5WWl020519 for ; Wed, 3 Feb 2010 17:05:32 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o13H5UuP204184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Feb 2010 09:05:32 -0800 (PST) Message-ID: <4B69ACD9.1030105@sun.com> Date: Thu, 04 Feb 2010 01:05:29 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100115 Thunderbird/3.0.1 MIME-Version: 1.0 To: tcpm@ietf.org References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> In-Reply-To: <4B69A53E.2050508@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 17:04:55 -0000 On 02/ 4/10 12:33 AM, Joe Touch wrote: > I'm curious about the tests described. 200ms seems very high for an RTT. > Even over a cell wireless link (3G), I see latencies that are typically > half that. I wonder what the improvement is for a 50-80ms RTT. I suspect that it depends on how your view of Internet is. From where I am physically located, RTT to my company's internal network is around 200ms. It is the normal RTT I live with for doing my day to day work. I hope folks won't take a "country-centric" view on Internet traffic. People all over the world are communicating with each other. The Internet is really not that "small..." -- K. Poon. kacheong.poon@sun.com From touch@ISI.EDU Wed Feb 3 09:12: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 D8F3C28C17B for ; Wed, 3 Feb 2010 09:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a18LvzMwXUKl for ; Wed, 3 Feb 2010 09:11:53 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 8B08E28C191 for ; Wed, 3 Feb 2010 09:11:52 -0800 (PST) Received: from [70.213.181.125] (125.sub-70-213-181.myvzw.com [70.213.181.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13HC46k018128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 09:12:06 -0800 (PST) Message-ID: <4B69AE64.8070608@isi.edu> Date: Wed, 03 Feb 2010 09:12:04 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kacheong Poon References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> In-Reply-To: <4B69ACD9.1030105@sun.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5EFD1BC2FB35887A0F814F68" X-MailScanner-ID: o13HC46k018128 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 17:12:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5EFD1BC2FB35887A0F814F68 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kacheong Poon wrote: > On 02/ 4/10 12:33 AM, Joe Touch wrote: >=20 >> I'm curious about the tests described. 200ms seems very high for an RT= T. >> Even over a cell wireless link (3G), I see latencies that are typicall= y >> half that. I wonder what the improvement is for a 50-80ms RTT. >=20 >=20 > I suspect that it depends on how your view of Internet is. From where > I am physically located, RTT to my company's internal network is > around 200ms. It is the normal RTT I live with for doing my day to > day work. I hope folks won't take a "country-centric" view on Internet= > traffic. People all over the world are communicating with each other. > The Internet is really not that "small..." Agreed. The point is to what extent TCP is modified for fractional benefits for specific communities. TCP is "optimized" to always work, but not to work especially well in any particular environment. Joe --------------enig5EFD1BC2FB35887A0F814F68 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) iEYEARECAAYFAktprmQACgkQE5f5cImnZrtwVwCgyaUa7fRgpMwPVyvZspyIg9/K ZBkAnjvj8br6Z6C+iO03NQsMO2hti/hs =YvES -----END PGP SIGNATURE----- --------------enig5EFD1BC2FB35887A0F814F68-- From michawe@ifi.uio.no Wed Feb 3 09:16: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 CC6BB28C191 for ; Wed, 3 Feb 2010 09:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 cl5+KfPc6f+s for ; Wed, 3 Feb 2010 09:16:16 -0800 (PST) Received: from get-mta-out02.get.basefarm.net (smtp.getmail.no [84.208.15.66]) by core3.amsl.com (Postfix) with ESMTP id 10B4428C186 for ; Wed, 3 Feb 2010 09:16:15 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from smtp.getmail.no ([10.5.16.4]) by get-mta-out02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA006R4009XA60@get-mta-out02.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 18:16:57 +0100 (MET) Received: from [192.168.0.194] ([84.208.136.71]) by get-mta-in02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KX900FCQZZN8Q30@get-mta-in02.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 18:16:57 +0100 (MET) X-PMX-Version: 5.5.3.366731, Antispam-Engine: 2.7.0.366912, Antispam-Data: 2010.2.3.170324 Message-id: <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> From: Michael Welzl To: Joe Touch In-reply-to: <4B69AE64.8070608@isi.edu> Date: Wed, 03 Feb 2010 18:16:35 +0100 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, Kacheong Poon Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 17:16:16 -0000 > Agreed. The point is to what extent TCP is modified for fractional > benefits for specific communities. TCP is "optimized" to always work, > but not to work especially well in any particular environment. Yeah... stupid, isn't it? Cheers, Michael From touch@ISI.EDU Wed Feb 3 09:20: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 0B9C428C186 for ; Wed, 3 Feb 2010 09:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 KG6R57SjGYFj for ; Wed, 3 Feb 2010 09:20:28 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 34CD23A696B for ; Wed, 3 Feb 2010 09:20:28 -0800 (PST) Received: from [70.213.181.125] (125.sub-70-213-181.myvzw.com [70.213.181.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13HJjEw019572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 09:19:46 -0800 (PST) Message-ID: <4B69B030.3000508@isi.edu> Date: Wed, 03 Feb 2010 09:19:44 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Welzl References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> In-Reply-To: <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC13BF058B93D6E9132A303B7" X-MailScanner-ID: o13HJjEw019572 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Kacheong Poon Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 17:20:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC13BF058B93D6E9132A303B7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Welzl wrote: >> Agreed. The point is to what extent TCP is modified for fractional >> benefits for specific communities. TCP is "optimized" to always work, >> but not to work especially well in any particular environment. >=20 > Yeah... stupid, isn't it? I'll trade "always" or even "usually" to "works very well in some places, but not at all in others". Making TCP smarter is fine; doing so at the expense of robustness is not.= Joe --------------enigC13BF058B93D6E9132A303B7 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) iEYEARECAAYFAktpsDEACgkQE5f5cImnZrvEdgCg8f1Thvqgy/3LP3xPJTlZEONZ wM8An0V/82rusSD6H4/U1clnonVhDEeg =cZKe -----END PGP SIGNATURE----- --------------enigC13BF058B93D6E9132A303B7-- From michawe@ifi.uio.no Wed Feb 3 09:32: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 4485828C19D for ; Wed, 3 Feb 2010 09:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 mhB7uedoMrwd for ; Wed, 3 Feb 2010 09:32:19 -0800 (PST) Received: from get-mta-out02.get.basefarm.net (smtp.getmail.no [84.208.15.66]) by core3.amsl.com (Postfix) with ESMTP id 3389728C19C for ; Wed, 3 Feb 2010 09:32:19 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from smtp.getmail.no ([10.5.16.4]) by get-mta-out02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA006KT0R1XA70@get-mta-out02.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 18:33:01 +0100 (MET) Received: from [192.168.0.194] ([84.208.136.71]) by get-mta-in01.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA00I610QF0Z00@get-mta-in01.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 18:33:01 +0100 (MET) X-PMX-Version: 5.5.3.366731, Antispam-Engine: 2.7.0.366912, Antispam-Data: 2010.2.3.171532 Message-id: From: Michael Welzl To: Joe Touch In-reply-to: <4B69B030.3000508@isi.edu> Date: Wed, 03 Feb 2010 18:32:39 +0100 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, Kacheong Poon Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 17:32:21 -0000 > Michael Welzl wrote: >>> Agreed. The point is to what extent TCP is modified for fractional >>> benefits for specific communities. TCP is "optimized" to always >>> work, >>> but not to work especially well in any particular environment. >> >> Yeah... stupid, isn't it? > > I'll trade "always" or even "usually" to "works very well in some > places, but not at all in others". > > Making TCP smarter is fine; doing so at the expense of robustness is > not. Sorry for being so unspecific - I was just thinking out loud... my point was: isn't that actually a stupid situation? Why do we have to worry about TCP over wireless, when so many users know perfectly well that their access link is WiFi? Why do we have to worry so much about raising the window when it's perfectly clear in some cases (at least from the combined knowledge of the stack + its users) that a certain connection is only going to face high bandwidth conditions? In other words, why not harness this knowledge somehow, and develop a customized transport protocol, or ways of customizing what we now have? This is what I was hinting at. Just thoughts... which would be more appropriate in an IRTF than in an IETF list, in fact - sorry. To get back to the point, I'm not seriously suggesting to reduce TCP's robustness and I'm in your camp about the larger window thing. My personal opinion here is that, however, the current slow start is indeed questionable, and questioning it should be done, in large scale thorough experiments. I'm interested in this and started some such work with a master student; I might continue if I get another one (or if I can nicely make that fit as a part of a larger Ph.D. thesis - ideas for how to do that are welcome! :-) ). Cheers, Michael From touch@ISI.EDU Wed Feb 3 09:43:11 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 46DA13A6C8E for ; Wed, 3 Feb 2010 09:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBctb6eu9gZy for ; Wed, 3 Feb 2010 09:43:10 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 69D783A6898 for ; Wed, 3 Feb 2010 09:43:10 -0800 (PST) Received: from [70.213.181.125] (125.sub-70-213-181.myvzw.com [70.213.181.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13Hh9NS026956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 09:43:11 -0800 (PST) Message-ID: <4B69B5AC.1090209@isi.edu> Date: Wed, 03 Feb 2010 09:43:08 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Welzl References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF5D6B57E25A285BCA2BCBCC4" X-MailScanner-ID: o13Hh9NS026956 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Kacheong Poon Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 17:43:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF5D6B57E25A285BCA2BCBCC4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Michael, Michael Welzl wrote: >> Michael Welzl wrote: >>>> Agreed. The point is to what extent TCP is modified for fractional >>>> benefits for specific communities. TCP is "optimized" to always work= , >>>> but not to work especially well in any particular environment. >>> >>> Yeah... stupid, isn't it? >> >> I'll trade "always" or even "usually" to "works very well in some >> places, but not at all in others". >> >> Making TCP smarter is fine; doing so at the expense of robustness is n= ot. >=20 > Sorry for being so unspecific - I was just thinking out loud... > my point was: isn't that actually a stupid situation? >=20 > Why do we have to worry about TCP over wireless, when so > many users know perfectly well that their access link is WiFi? > Why do we have to worry so much about raising the window > when it's perfectly clear in some cases (at least from the > combined knowledge of the stack + its users) that a certain > connection is only going to face high bandwidth conditions? >=20 > In other words, why not harness this knowledge somehow, > and develop a customized transport protocol, or ways of > customizing what we now have? That's been tried in various ways in various IETF efforts. Some try to find the properties of the immediate link, which are expected for some link types to dominate the path. Some try to detect path properties. Some reuse information from past connections. None of that is all that bad. =2E.. > To get back to the point, I'm not seriously suggesting to reduce > TCP's robustness and I'm in your camp about the larger > window thing. My personal opinion here is that, however, > the current slow start is indeed questionable, and questioning > it should be done, in large scale thorough experiments. I'm > interested in this and started some such work with a master > student; I might continue if I get another one (or if I can nicely > make that fit as a part of a larger Ph.D. thesis - ideas for > how to do that are welcome! :-) ) I think revising congestion control to be smarter is already a IRTF effort (aren't you active in that already?): http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG IMO, I would encourage Google to take their work there and get feedback there first. TCPM is a place where mature, vetted ideas should be considered, preferably (IMO). Joe --------------enigF5D6B57E25A285BCA2BCBCC4 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) iEYEARECAAYFAktptawACgkQE5f5cImnZrul4QCglcl4337uhW0+/Ec8HufYE6eK pyAAoIdtn+xFF84BWH2p3aiTRMttg3ZV =vWU5 -----END PGP SIGNATURE----- --------------enigF5D6B57E25A285BCA2BCBCC4-- From alangley@gmail.com Wed Feb 3 09:47: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 787B228C0E3 for ; Wed, 3 Feb 2010 09:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 d+tGpJGQRbPj for ; Wed, 3 Feb 2010 09:47:49 -0800 (PST) Received: from mail-yw0-f201.google.com (mail-yw0-f201.google.com [209.85.211.201]) by core3.amsl.com (Postfix) with ESMTP id 3A0DB3A6C99 for ; Wed, 3 Feb 2010 09:47:41 -0800 (PST) Received: by ywh39 with SMTP id 39so4405428ywh.17 for ; Wed, 03 Feb 2010 09:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=jcqXrr2dyhjz0fdfw37HnMTkKSMnfG/5pKG7V+QJ2sw=; b=QwxLNXS47/oOEtgEoxqSEKK08+IkvJyWNzp/XbJq0JKpVtXB/6TmmKgiLuT2Zv0Jzj ksu7bQqv9Z1Z9FDVuXdRGrd1vqDIKXS7idDlVVeYj2tNRqCYqkAZaKBYhuBtxc1rf/Qw 6fryCtTkhDpNfoMSzERbz9u7V0YCfO8rOk52k= 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=dPqMCmIzHfLv3OZ2NoBQChmrwcp+r4/dFAlELBC4fM7y1pCe9jLrPAHDJIiA2GTfZf vgqBR5wNxQB4MdZ6q2eV7qlTKs/ZXSMB3N8kENYnS8D+PZb2tLI+YZ0AgwWT5juHZmlR 6iY8YOxBXheNUHWwAcM5AhLZ0fIEM7pKS2d20= MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.142.5.24 with SMTP id 24mr5247840wfe.63.1265219300366; Wed, 03 Feb 2010 09:48:20 -0800 (PST) In-Reply-To: <4B69B5AC.1090209@isi.edu> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> Date: Wed, 3 Feb 2010 12:48:20 -0500 X-Google-Sender-Auth: 03c3e252057a2a18 Message-ID: <396556a21002030948s39005503ie8bc96a52b5acb3c@mail.gmail.com> From: Adam Langley To: Joe Touch Content-Type: text/plain; charset=UTF-8 Cc: tcpm@ietf.org, Kacheong Poon , Michael Welzl Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 17:47:50 -0000 On Wed, Feb 3, 2010 at 12:43 PM, Joe Touch wrote: > IMO, I would encourage Google to take their work there and get feedback > there first. TCPM is a place where mature, vetted ideas should be > considered, preferably (IMO). I think an important part of the presentation is that this is already a very well vetted idea: by using multiple subdomains and concurrent connections, HTTP has already increased the initcwnd drastically. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From touch@ISI.EDU Wed Feb 3 09:54: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 E4C0B3A693E for ; Wed, 3 Feb 2010 09:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Irujo4pJ7KOW for ; Wed, 3 Feb 2010 09:54:23 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 09C153A6A7F for ; Wed, 3 Feb 2010 09:54:23 -0800 (PST) Received: from [70.213.181.125] (125.sub-70-213-181.myvzw.com [70.213.181.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13HqG4x000121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 09:52:23 -0800 (PST) Message-ID: <4B69B7CE.1060802@isi.edu> Date: Wed, 03 Feb 2010 09:52:14 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Langley References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> <396556a21002030948s39005503ie8bc96a52b5acb3c@mail.gmail.com> In-Reply-To: <396556a21002030948s39005503ie8bc96a52b5acb3c@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDDD41DA322E48EB4072FFFA4" X-MailScanner-ID: o13HqG4x000121 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Kacheong Poon , Michael Welzl Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 17:54:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDDD41DA322E48EB4072FFFA4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adam Langley wrote: > On Wed, Feb 3, 2010 at 12:43 PM, Joe Touch wrote: >> IMO, I would encourage Google to take their work there and get feedbac= k >> there first. TCPM is a place where mature, vetted ideas should be >> considered, preferably (IMO). >=20 > I think an important part of the presentation is that this is already > a very well vetted idea: by using multiple subdomains and concurrent > connections, HTTP has already increased the initcwnd drastically. By vetted, I would include the experiments and the detailed information available. That vetting should be checked in the IRTF first; that's a better place to review technical material for consideration of past and related work, and verification of methodology. Joe --------------enigDDD41DA322E48EB4072FFFA4 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) iEYEARECAAYFAktpt84ACgkQE5f5cImnZrsuKQCfXXkn79bxNJUkHlEQLq5vN3tq V1cAnjExyu9E/6gCwnq3vpQ4oWFRwSLA =lG4c -----END PGP SIGNATURE----- --------------enigDDD41DA322E48EB4072FFFA4-- From hkchu@google.com Wed Feb 3 10:20: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 19CBE28C1A0 for ; Wed, 3 Feb 2010 10:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 KCyKqP3oJJ1k for ; Wed, 3 Feb 2010 10:20:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 444C128C19E for ; Wed, 3 Feb 2010 10:20:17 -0800 (PST) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o13IKw8r006822 for ; Wed, 3 Feb 2010 18:20:58 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265221259; bh=7hEEqNjlG8Hd9yndvzCBDmxf5Gg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=lDGvlvtzUIZ+fXduD8wcZjDqO0DApNjS0otbgno3/t6HHpeuVaH2NtnY8FPo/YflR hcOEhzxDJOnNEg8xM8Kpw== 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=iW2e/OUkN+DjproZNaUm0h4kuuVs+iyfWHk6PmJK70jRXkd++AZeg6meVHiMcMhtZ cxeY/jGMP5I5sk5HnFx3g== Received: from pxi26 (pxi26.prod.google.com [10.243.27.26]) by kpbe12.cbf.corp.google.com with ESMTP id o13IJbM0020665 for ; Wed, 3 Feb 2010 10:20:57 -0800 Received: by pxi26 with SMTP id 26so1942013pxi.17 for ; Wed, 03 Feb 2010 10:20:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.53.19 with SMTP id f19mr2805698rvk.233.1265221256729; Wed, 03 Feb 2010 10:20:56 -0800 (PST) In-Reply-To: <81ECEA1A-690F-4EAE-A586-BBC498877DB8@ifi.uio.no> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <81ECEA1A-690F-4EAE-A586-BBC498877DB8@ifi.uio.no> Date: Wed, 3 Feb 2010 10:20:56 -0800 Message-ID: From: Jerry Chu To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 18:20:21 -0000 Michael, On Wed, Feb 3, 2010 at 6:42 AM, Michael Welzl wrote: > Hi all, > > (sorry if this is a bit off topic, as the mentioned presentation is mainl= y > about using a larger initial window) > > In the context of the discussion that Jerry brought up on parameter tunin= g, > one question that was raised was the initial RTO during the SYN - SYN/ACK > exchange. I understand that we can't recommend to resend SYN's more > aggressively because this might cause a server to be overloaded with SYN'= s, > but why do we have to wait extremely long until we resend SYN/ACKs? > > Back then, when I asked, I got no answer. Both Jerry and I pointed > to our measurement results which show that the effect is nonneglible. Actually Mark Allman, Vern Paxon and I have been working on revising RFC2988 to reduce the initial RTO from 3secs to 1sec. Will submit the proposal soon! Best, Jerry > > So I'll use this chance to ask again =A0:-) > > Cheers, > Michael > > > On Feb 3, 2010, at 3:28 PM, Lars Eggert wrote: > >> Hi, >> >> Jerry Chu has recently started the discussion on whether we need to thin= k >> about tweaking TCP for the "modern Internet." Just came across another >> presentation from (AFAICT) another corner of Google that makes similar >> arguments. >> >> FYI: >> http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Changing= _TCP_Slow_Start.pdf >> >> This topic seems to be gaining momentum, and the WG should take some tim= e >> considering if there is work here for it. >> >> Lars_______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From michawe@ifi.uio.no Wed Feb 3 10:26: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 688AB28C1A8 for ; Wed, 3 Feb 2010 10:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 CE5HpG+HsoNg for ; Wed, 3 Feb 2010 10:26:47 -0800 (PST) Received: from get-mta-out02.get.basefarm.net (smtp.getmail.no [84.208.15.66]) by core3.amsl.com (Postfix) with ESMTP id 827A228C107 for ; Wed, 3 Feb 2010 10:26:47 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from smtp.getmail.no ([10.5.16.4]) by get-mta-out02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA006MZ39TXAA0@get-mta-out02.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 19:27:29 +0100 (MET) Received: from [192.168.0.194] ([84.208.136.71]) by get-mta-in02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA000B53979W30@get-mta-in02.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 19:27:29 +0100 (MET) X-PMX-Version: 5.5.3.366731, Antispam-Engine: 2.7.0.366912, Antispam-Data: 2010.2.3.180920 Message-id: <8FCC1879-FBA4-4A5F-8ADF-932A6731B7EA@ifi.uio.no> From: Michael Welzl To: Joe Touch In-reply-to: <4B69B5AC.1090209@isi.edu> Date: Wed, 03 Feb 2010 19:27:07 +0100 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, Kacheong Poon Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 18:26:48 -0000 >> In other words, why not harness this knowledge somehow, >> and develop a customized transport protocol, or ways of >> customizing what we now have? > > That's been tried in various ways in various IETF efforts. Some try to > find the properties of the immediate link, which are expected for some > link types to dominate the path. Some try to detect path properties. > Some reuse information from past connections. Really? I'd be curious about a few pointers, what exactly do you have in mind? About reusing information etc., the congestion manager and your TCB sharing stuff comes to mind, but for the rest I'm curious >> To get back to the point, I'm not seriously suggesting to reduce >> TCP's robustness and I'm in your camp about the larger >> window thing. My personal opinion here is that, however, >> the current slow start is indeed questionable, and questioning >> it should be done, in large scale thorough experiments. I'm >> interested in this and started some such work with a master >> student; I might continue if I get another one (or if I can nicely >> make that fit as a part of a larger Ph.D. thesis - ideas for >> how to do that are welcome! :-) ) > > I think revising congestion control to be smarter is already a IRTF > effort (aren't you active in that already?): Yep - I just thought out loud on this list because that's where the discussion happened... > http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG > > IMO, I would encourage Google to take their work there and get > feedback > there first. TCPM is a place where mature, vetted ideas should be > considered, preferably (IMO). I absolutely agree. Cheers, Michael From michawe@ifi.uio.no Wed Feb 3 10:29:08 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 1A4053A690F for ; Wed, 3 Feb 2010 10:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 X0fFqNapr4uF for ; Wed, 3 Feb 2010 10:29:07 -0800 (PST) Received: from get-mta-out02.get.basefarm.net (smtp.getmail.no [84.208.15.66]) by core3.amsl.com (Postfix) with ESMTP id 4B67328C194 for ; Wed, 3 Feb 2010 10:29:07 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from smtp.getmail.no ([10.5.16.4]) by get-mta-out02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA006S53DPXAA0@get-mta-out02.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 19:29:49 +0100 (MET) Received: from [192.168.0.194] ([84.208.136.71]) by get-mta-in02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA000H03D39W30@get-mta-in02.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 19:29:49 +0100 (MET) X-PMX-Version: 5.5.3.366731, Antispam-Engine: 2.7.0.366912, Antispam-Data: 2010.2.3.181516 Message-id: <1CEB1C68-6499-45E1-8A68-5A8A37777272@ifi.uio.no> From: Michael Welzl To: Adam Langley In-reply-to: <396556a21002030948s39005503ie8bc96a52b5acb3c@mail.gmail.com> Date: Wed, 03 Feb 2010 19:29:27 +0100 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> <396556a21002030948s39005503ie8bc96a52b5acb3c@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, Kacheong Poon , Joe Touch Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 18:29:08 -0000 On Feb 3, 2010, at 6:48 PM, Adam Langley wrote: > On Wed, Feb 3, 2010 at 12:43 PM, Joe Touch wrote: >> IMO, I would encourage Google to take their work there and get >> feedback >> there first. TCPM is a place where mature, vetted ideas should be >> considered, preferably (IMO). > > I think an important part of the presentation is that this is already > a very well vetted idea: by using multiple subdomains and concurrent > connections, HTTP has already increased the initcwnd drastically. I would disagree about "well vetted" (at the level that TCPM needs to incorporate such a major change in the protocol) unless I see some very thorough measurements showing that no harm comes from such a change, in various environments, with various possible traffic occurrences coming and going... Talking about this in ICCRG wouldn't be a bad thing at all, it's really a reasonable first step IMO. Cheers, Michael From touch@ISI.EDU Wed Feb 3 11:00: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 B01AE28C20D for ; Wed, 3 Feb 2010 11:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 PY4EpBKaDBiw for ; Wed, 3 Feb 2010 11:00:52 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id BF4A928C217 for ; Wed, 3 Feb 2010 10:42:40 -0800 (PST) Received: from [70.213.181.125] (125.sub-70-213-181.myvzw.com [70.213.181.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13Ifao4012040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 10:41:37 -0800 (PST) Message-ID: <4B69C35F.9080903@isi.edu> Date: Wed, 03 Feb 2010 10:41:35 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Welzl References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> <8FCC1879-FBA4-4A5F-8ADF-932A6731B7EA@ifi.uio.no> In-Reply-To: <8FCC1879-FBA4-4A5F-8ADF-932A6731B7EA@ifi.uio.no> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0DF98CB8B5ADAEE3C9F5848F" X-MailScanner-ID: o13Ifao4012040 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Kacheong Poon Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 19:00:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0DF98CB8B5ADAEE3C9F5848F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Welzl wrote: >>> In other words, why not harness this knowledge somehow, >>> and develop a customized transport protocol, or ways of >>> customizing what we now have? >> >> That's been tried in various ways in various IETF efforts. Some try to= >> find the properties of the immediate link, which are expected for some= >> link types to dominate the path. Some try to detect path properties. >> Some reuse information from past connections. >=20 > Really? I'd be curious about a few pointers, what exactly > do you have in mind? About reusing information etc., the > congestion manager and your TCB sharing stuff comes to > mind, but for the rest I'm curious Spencer Dawkins probably recalls better than I; I think there were numerous BOFs centered around "link indications", including: TRIGTRAN BOF "LinkUp" draft-dawkins-linkup-nevermind LCI BOF (Link Characteristic Information for Mobility) MPTCP WG LEDBAT WG RFC-4709 Joe --------------enig0DF98CB8B5ADAEE3C9F5848F 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) iEYEARECAAYFAktpw18ACgkQE5f5cImnZrur0QCfaCTH0Bp9MCY+xbyw9wSC2dDD +FoAnRA0SIWtVsKfiUeD3gnUxo0CHHit =J25h -----END PGP SIGNATURE----- --------------enig0DF98CB8B5ADAEE3C9F5848F-- From hkchu@google.com Wed Feb 3 11: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 9955C3A690F for ; Wed, 3 Feb 2010 11:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.977 X-Spam-Level: X-Spam-Status: No, score=-103.977 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, 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 Gm0UcFZDsiSw for ; Wed, 3 Feb 2010 11:09:41 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B78F43A67AC for ; Wed, 3 Feb 2010 11:09:41 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o13JAO69005338 for ; Wed, 3 Feb 2010 11:10:24 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265224224; bh=jwYuewI7lcY1qFgUe4xIJN5dQjU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=EkWVLh6sRQxXaVVL0FxXzu43r+pRdBCDfYev/Hns+s6hHkipaWFyCPm06UA/TMqWB AsP0d94Y9sCqd59ddUe5g== 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:x-system-of-record; b=NWxMvZ+k64J5/Y82mPCQyTcGa3K7K3CUR45jw1VmXPonTVXziTyLB54miHii8RVwq O6C639Dy0jvSxWn9JzeSw== Received: from pzk3 (pzk3.prod.google.com [10.243.19.131]) by wpaz17.hot.corp.google.com with ESMTP id o13JAM1i012529 for ; Wed, 3 Feb 2010 11:10:23 -0800 Received: by pzk3 with SMTP id 3so245096pzk.5 for ; Wed, 03 Feb 2010 11:10:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.213.24 with SMTP id p24mr26839rvq.5.1265224222570; Wed, 03 Feb 2010 11:10:22 -0800 (PST) In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> Date: Wed, 3 Feb 2010 11:10:22 -0800 Message-ID: From: Jerry Chu To: "SCHARF, Michael" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 19:09:42 -0000 On Wed, Feb 3, 2010 at 7:17 AM, SCHARF, Michael wrote: >> This topic seems to be gaining momentum, and the WG should >> take some time considering if there is work here for it. > > IMHO there could indeed be room for increasing the initial window. If > most data transfers continue to be smaller than 3 MSS, a larger initial > window would not necessarily cause harm, as it is seldomly used. Still, > this would speed up those data transfers that currently suffer from > Slow-Start. Actually our data points to the contrary - the average web object and page size have been rising steadily. E.g., the majority of our search responses no longer fit in 3 MSS these days. > > In the past, I have played a little bit with an initial window e. g. of > 10 MSS, and that worked surprisingly well. Good to know! >Also, one could combine a > larger initial window with other mechanisms that would reduce the > aggressiveness of the flow startup. Maybe it is indeed time to think > about the Slow-Start once again. We are planning to submit an I-D on raising initcwnd to 10MSS before 3/1 to be included in the upcoming IETF meeting. Jerry > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From hkchu@google.com Wed Feb 3 11: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 507A73A6CD1 for ; Wed, 3 Feb 2010 11:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 W8qsyIjQVhH9 for ; Wed, 3 Feb 2010 11:18:03 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 50EF83A6CCB for ; Wed, 3 Feb 2010 11:18:03 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o13JIjBd018395 for ; Wed, 3 Feb 2010 11:18:45 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265224725; bh=Bz/k5buhhysSexhJxVOGRTWHE8I=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=a56buTmV5CemCnLvQei6AxUs6jw8CDXDLUXfNRYW6RP/ke7EDxZeYN9Pak8Mcu4PU kEfDPK+9gP975EpAxulHQ== 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=ZM/rNYtu/KPMjf+RoIf2rcPu/ArHooj8SvjX3YNtBHqsRhWFdZdAxqZQ+VqxOQoWI 756dwIztsdQ23WDiOr+6Q== Received: from pzk6 (pzk6.prod.google.com [10.243.19.134]) by wpaz21.hot.corp.google.com with ESMTP id o13JIbtY001677 for ; Wed, 3 Feb 2010 11:18:44 -0800 Received: by pzk6 with SMTP id 6so479705pzk.18 for ; Wed, 03 Feb 2010 11:18:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.89.2 with SMTP id r2mr5412747rvl.277.1265224720110; Wed, 03 Feb 2010 11:18:40 -0800 (PST) In-Reply-To: <4B69A0BD.2060708@sun.com> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69A0BD.2060708@sun.com> Date: Wed, 3 Feb 2010 11:18:40 -0800 Message-ID: From: Jerry Chu To: Kacheong Poon 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] TCP tuning 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, 03 Feb 2010 19:18:04 -0000 On Wed, Feb 3, 2010 at 8:13 AM, Kacheong Poon wrote= : > On 02/ 3/10 11:17 PM, SCHARF, Michael wrote: > >> In the past, I have played a little bit with an initial window e. g. of >> 10 MSS, and that worked surprisingly well. Also, one could combine a >> larger initial window with other mechanisms that would reduce the >> aggressiveness of the flow startup. Maybe it is indeed time to think >> about the Slow-Start once again. > > > FWIW, I've come across traces showing some network equipment > uses an initial window as large as 16 segments (some kind of > turbo mode). =A0It is probably true many stacks already use a > much larger initial window than recommended in the RFC. =A0Just > that people have been very quiet about this. Indeed, the percentage of non-compliance can be quite high, as high as ~15% in one dataset reported by an IMC paper "TCP Revisited: A Fresh Look at TCP in the Wild" Jerry > > > > -- > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0K. Poon. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0kacheong.poon@sun.com > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@ISI.EDU Wed Feb 3 11:27: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 EACCB3A68AC for ; Wed, 3 Feb 2010 11:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 EE8rhBBByj6V for ; Wed, 3 Feb 2010 11:27:31 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 445193A6826 for ; Wed, 3 Feb 2010 11:27:31 -0800 (PST) Received: from [70.213.181.125] (125.sub-70-213-181.myvzw.com [70.213.181.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13JQFQ9024139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 11:26:26 -0800 (PST) Message-ID: <4B69CDD7.6060802@isi.edu> Date: Wed, 03 Feb 2010 11:26:15 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jerry Chu References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEE27CBE6B06F8A21D7B1E203" X-MailScanner-ID: o13JQFQ9024139 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 19:27:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEE27CBE6B06F8A21D7B1E203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jerry Chu wrote: > On Wed, Feb 3, 2010 at 7:17 AM, SCHARF, Michael > wrote: >>> This topic seems to be gaining momentum, and the WG should >>> take some time considering if there is work here for it. >> IMHO there could indeed be room for increasing the initial window. If >> most data transfers continue to be smaller than 3 MSS, a larger initia= l >> window would not necessarily cause harm, as it is seldomly used. Still= , >> this would speed up those data transfers that currently suffer from >> Slow-Start. >=20 > Actually our data points to the contrary - the average web object and p= age > size have been rising steadily. E.g., the majority of our search respon= ses > no longer fit in 3 MSS these days. This should be relevant only for the first response from a given IP address; persistent connections should render this moot for subsequent requests. Again, the question arises as to how much this is going to achieve a noticeable impact. Joe --------------enigEE27CBE6B06F8A21D7B1E203 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) iEYEARECAAYFAktpzdcACgkQE5f5cImnZrvN0gCfZdJvd3qz0AQoUlUSijWm00fz LukAniJtwHrGrr9o95/7kVTqsRtigJes =uJb4 -----END PGP SIGNATURE----- --------------enigEE27CBE6B06F8A21D7B1E203-- From hkchu@google.com Wed Feb 3 12:25: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 4A6F93A6CE3 for ; Wed, 3 Feb 2010 12:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, 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 Bz8cYz238K6b for ; Wed, 3 Feb 2010 12:25:21 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BE1AC3A6CE4 for ; Wed, 3 Feb 2010 12:25:19 -0800 (PST) Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id o13KQ1nV019107 for ; Wed, 3 Feb 2010 12:26:02 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265228762; bh=NhxGbAiezSVkq6qbz2Cy+oEfNWg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=S0jwqzMtdHcx7DOGzY4XcOV99QUv3Fvo3c1uC4ImFhdO72zs3PAhIYcvxm2kxdnQX 4NLWA6bgU5MXp1Jfiu7LQ== 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=b4hn4FcwLooyetmIlVaSw306F1uy7pOhjmKUKIFsoIR/Lzou2Bcxis9GUAp69kdOz HgfRgqMayL27acRn7fEgQ== Received: from pzk27 (pzk27.prod.google.com [10.243.19.155]) by spaceape11.eur.corp.google.com with ESMTP id o13KPxbR029248 for ; Wed, 3 Feb 2010 12:26:00 -0800 Received: by pzk27 with SMTP id 27so1855156pzk.33 for ; Wed, 03 Feb 2010 12:25:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.56.2 with SMTP id e2mr83904rva.37.1265228759221; Wed, 03 Feb 2010 12:25:59 -0800 (PST) In-Reply-To: <4B69B5AC.1090209@isi.edu> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> Date: Wed, 3 Feb 2010 12:25:59 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, Kacheong Poon , Michael Welzl Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 20:25:22 -0000 Hi Joe, On Wed, Feb 3, 2010 at 9:43 AM, Joe Touch wrote: > Hi, Michael, > > Michael Welzl wrote: >>> Michael Welzl wrote: >>>>> Agreed. The point is to what extent TCP is modified for fractional >>>>> benefits for specific communities. TCP is "optimized" to always work, >>>>> but not to work especially well in any particular environment. >>>> >>>> Yeah... stupid, isn't it? >>> >>> I'll trade "always" or even "usually" to "works very well in some >>> places, but not at all in others". >>> >>> Making TCP smarter is fine; doing so at the expense of robustness is no= t. >> >> Sorry for being so unspecific - I was just thinking out loud... >> my point was: isn't that actually a stupid situation? >> >> Why do we have to worry about TCP over wireless, when so >> many users know perfectly well that their access link is WiFi? >> Why do we have to worry so much about raising the window >> when it's perfectly clear in some cases (at least from the >> combined knowledge of the stack + its users) that a certain >> connection is only going to face high bandwidth conditions? >> >> In other words, why not harness this knowledge somehow, >> and develop a customized transport protocol, or ways of >> customizing what we now have? > > That's been tried in various ways in various IETF efforts. Some try to > find the properties of the immediate link, which are expected for some > link types to dominate the path. Some try to detect path properties. > Some reuse information from past connections. > > None of that is all that bad. > > ... >> To get back to the point, I'm not seriously suggesting to reduce >> TCP's robustness and I'm in your camp about the larger >> window thing. My personal opinion here is that, however, >> the current slow start is indeed questionable, and questioning >> it should be done, in large scale thorough experiments. I'm >> interested in this and started some such work with a master >> student; I might continue if I get another one (or if I can nicely >> make that fit as a part of a larger Ph.D. thesis - ideas for >> how to do that are welcome! =A0:-) =A0) > > I think revising congestion control to be smarter is already a IRTF > effort (aren't you active in that already?): > > http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG > > IMO, I would encourage Google to take their work there and get feedback > there first. TCPM is a place where mature, vetted ideas should be > considered, preferably (IMO). Sure we can do that and will love to hear feedback from ICCRG. But our preference is IETF simply because we consider a simple, modest increase of the initial window to be more of an engineering project than a research problem. The former is more about engineering tradeoff between cost/risk, benefit and TIMELINESS than a research project to find the best, elegant, risk free solution with little or no time-to-market concern. We are aware of all the great research work being conducted at ICCRG on speeding up slow-start. But none of the proposals seems ready for IETF anytime soon. I'd be happy to be proven wrong here! (Well to be more correct a modest increase of initial window may have already been studied at ICCRG. In that case I'd rephrase it to be the closest to engineering consideration IMHO.) Jerry > > Joe > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From johnwheffner@gmail.com Wed Feb 3 12:31:51 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 96BF63A6C42 for ; Wed, 3 Feb 2010 12:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 6iWoa79CiMfR for ; Wed, 3 Feb 2010 12:31:50 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 8E8ED3A6CE4 for ; Wed, 3 Feb 2010 12:31:50 -0800 (PST) Received: by fxm5 with SMTP id 5so1942156fxm.15 for ; Wed, 03 Feb 2010 12:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=DxMgM2idLIYa5XykQqvTsvX453Tf4kzy5f4KH75ztDA=; b=npcHtF4b0anZrYNPYlat/4T88TwGBdx5DPcFJo5DgAGXJXynjRKKo+ZM21TDmmQea4 6ExdPiiF5sXf59TKYO5X9i1k8x2w0ud+wZFSGjspqRjwDR032kCGRpn6ks0VB993NxdP K5UZp1nUi1JHlfjIC2X2+fepnZBPQv6VsFH4s= 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 :content-type; b=tZs5+M3oj+vBb5jbhfiZWUTMW67SgkzdwvvOPExS501vtsycvP8AhIH1rkkOr4J57v C3BOh4g4+jSoBY4udkLQyhGMW7x48P1zXd4sbYKBE7s33XpFlrcV7UiAO/c4zAyp3Ix2 ebK83Nm5E0OKTCArTQ0mWDeayvlEUC1+VlP2I= MIME-Version: 1.0 Received: by 10.216.163.81 with SMTP id z59mr60490wek.95.1265229149726; Wed, 03 Feb 2010 12:32:29 -0800 (PST) In-Reply-To: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> Date: Wed, 3 Feb 2010 15:32:29 -0500 Message-ID: <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> From: John Heffner To: "tcpm@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 20:31:51 -0000 I would like to see tcpm take on the initial window issue, though as Joe notes we probably do not yet know enough to formally take this on as a charter item. (Or, would this be a tsvwg item due to possible wider impact?) A couple thoughts: - A large initial window should probably only be used by mutual agreement. Maybe via a TCP option during the handshake? - A significant increase to the initial window might benefit from introduction of some form of pacing, since you won't have any ack clock yet. This might help reduce losses and delay jitter. -John On Wed, Feb 3, 2010 at 9:28 AM, Lars Eggert wrote: > Hi, > > Jerry Chu has recently started the discussion on whether we need to think about tweaking TCP for the "modern Internet." Just came across another presentation from (AFAICT) another corner of Google that makes similar arguments. > > FYI: http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf > > This topic seems to be gaining momentum, and the WG should take some time considering if there is work here for it. > > Lars > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From hkchu@google.com Wed Feb 3 12:34: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 8CFAF28C1B8 for ; Wed, 3 Feb 2010 12:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.477 X-Spam-Level: X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, 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 sAQgHzQsDISa for ; Wed, 3 Feb 2010 12:34:30 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 2546828C1B7 for ; Wed, 3 Feb 2010 12:34:29 -0800 (PST) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o13KZB8G031807 for ; Wed, 3 Feb 2010 20:35:11 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265229312; bh=eiD3AFPvGllRXANX9OMapHkdsI8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=MUYgXPJCW3WG9KMettnP04kV29/8nFiedjQXNO1Jc6UltBmatC0Dqo0bUYSZeEZEg 8meeVRHHpANisRTpx+EDA== 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=QVlkKUilsaEl6aCD5+c79ReQQfOtvd/b6/mE6sGWKnZJE3sOCX7n2Hj2zv8JdIMVI ArG98Vq5HlY6EuKP5qtcw== Received: from pzk9 (pzk9.prod.google.com [10.243.19.137]) by kpbe12.cbf.corp.google.com with ESMTP id o13KYx5m002933 for ; Wed, 3 Feb 2010 12:35:10 -0800 Received: by pzk9 with SMTP id 9so2011899pzk.31 for ; Wed, 03 Feb 2010 12:35:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.12.3 with SMTP id p3mr66451rvi.194.1265229309054; Wed, 03 Feb 2010 12:35:09 -0800 (PST) In-Reply-To: References: Date: Wed, 3 Feb 2010 12:35:09 -0800 Message-ID: From: Jerry Chu To: "Biswas, Anumita" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 20:34:31 -0000 On Wed, Feb 3, 2010 at 10:39 AM, Biswas, Anumita wrote: > > >> -----Original Message----- >> From: Jerry Chu [mailto:hkchu@google.com] >> Sent: Wednesday, February 03, 2010 10:21 AM >> To: Michael Welzl >> Cc: tcpm@ietf.org WG >> Subject: Re: [tcpm] TCP tuning >> >> >> Michael, >> >> On Wed, Feb 3, 2010 at 6:42 AM, Michael Welzl >> wrote: >> > Hi all, >> > >> > (sorry if this is a bit off topic, as the mentioned presentation is >> > mainly about using a larger initial window) >> > >> > In the context of the discussion that Jerry brought up on parameter >> > tuning, one question that was raised was the initial RTO during the >> > SYN - SYN/ACK exchange. I understand that we can't >> recommend to resend >> > SYN's more aggressively because this might cause a server to be >> > overloaded with SYN's, but why do we have to wait extremely >> long until >> > we resend SYN/ACKs? >> > >> > Back then, when I asked, I got no answer. Both Jerry and I >> pointed to >> > our measurement results which show that the effect is nonneglible. >> >> Actually Mark Allman, Vern Paxon and I have been working on >> revising RFC2988 to reduce the initial RTO from 3secs to >> 1sec. Will submit the proposal soon! >> > This implies that this proposal brings the intial RTO value to be equal t= o the minimum RTO value of 1 second. Is this true? Correct. > > I am going by RFC 2988, section 2, 2.4. It explicitly states this: > > " (2.4) Whenever RTO is computed, if it is less than 1 second then the > =A0 =A0 =A0 =A0 RTO SHOULD be rounded up to 1 second. > > =A0 =A0 =A0 =A0 Traditionally, TCP implementations use coarse grain clock= s to > =A0 =A0 =A0 =A0 measure the RTT and trigger the RTO, which imposes a larg= e > =A0 =A0 =A0 =A0 minimum value on the RTO. =A0Research suggests that a lar= ge > =A0 =A0 =A0 =A0 minimum RTO is needed to keep TCP conservative and avoid > =A0 =A0 =A0 =A0 spurious retransmissions [AP99]. =A0Therefore, this > =A0 =A0 =A0 =A0 specification requires a large minimum RTO as a conservat= ive > =A0 =A0 =A0 =A0 approach, while at the same time acknowledging that at so= me > =A0 =A0 =A0 =A0 future point, research may show that a smaller minimum RT= O is > =A0 =A0 =A0 =A0 acceptable or superior." > > Is it time to reconsider a smaller minimum RTO as well? Yes this is the 3rd item on my todo list (see http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf) but is not nearly as important as the first two IMO. Jerry > > > > > > >> Best, >> >> Jerry >> >> > >> > So I'll use this chance to ask again =A0:-) >> > >> > Cheers, >> > Michael >> > >> > >> > On Feb 3, 2010, at 3:28 PM, Lars Eggert wrote: >> > >> >> Hi, >> >> >> >> Jerry Chu has recently started the discussion on whether >> we need to >> >> think about tweaking TCP for the "modern Internet." Just >> came across >> >> another presentation from (AFAICT) another corner of Google that >> >> makes similar arguments. >> >> >> >> FYI: >> >> >> http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Chang >> >> ing_TCP_Slow_Start.pdf >> >> >> >> This topic seems to be gaining momentum, and the WG should >> take some >> >> time considering if there is work here for it. >> >> >> >> Lars_______________________________________________ >> >> tcpm mailing list >> >> tcpm@ietf.org >> >> https://www.ietf.org/mailman/listinfo/tcpm >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm >> > >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > From hkchu@google.com Wed Feb 3 12:44: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 7AA3A3A683B for ; Wed, 3 Feb 2010 12:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, 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 IEY2aa-ycfd1 for ; Wed, 3 Feb 2010 12:44:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CC5F328C0CF for ; Wed, 3 Feb 2010 12:43:21 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o13Ki4lu002101 for ; Wed, 3 Feb 2010 12:44:04 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265229844; bh=g/kN5iVCmDmwZ6ZVpUiP/vKETYM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=oRRUbTziekNyl6EL0LzScyr+xgTx+mxdqTctiGzCXoaJj/krlgIMknapHTBztVZFK QKkDwndS3+Skzy3AOuTzA== 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=NRBU+X7B4Wde+jrmFstN4H8E9K5WTH/628w3/mYHLkRgkdFSZkL/3HyyqdLsMeRgu XdDEYrFfSbJ9jAmF9ktqw== Received: from pxi42 (pxi42.prod.google.com [10.243.27.42]) by wpaz24.hot.corp.google.com with ESMTP id o13Ki36P027305 for ; Wed, 3 Feb 2010 12:44:03 -0800 Received: by pxi42 with SMTP id 42so2839641pxi.5 for ; Wed, 03 Feb 2010 12:44:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.12.3 with SMTP id p3mr73847rvi.194.1265229842635; Wed, 03 Feb 2010 12:44:02 -0800 (PST) In-Reply-To: <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> Date: Wed, 3 Feb 2010 12:44:02 -0800 Message-ID: From: Jerry Chu To: John Heffner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 20:44:18 -0000 Hi John, On Wed, Feb 3, 2010 at 12:32 PM, John Heffner wrot= e: > I would like to see tcpm take on the initial window issue, though as > Joe notes we probably do not yet know enough to formally take this on > as a charter item. =A0(Or, would this be a tsvwg item due to possible > wider impact?) > > A couple thoughts: > - A large initial window should probably only be used by mutual > agreement. =A0Maybe via a TCP option during the handshake? This may not be needed. A receiver can effectively constrain the sender's window by advertising a smaller initial receive window. Obviously this works for only the initial window, not the restart window. (Oh, on a second thought this can be made to work for the restart window too.) > - A significant increase to the initial window might benefit from > introduction of some form of pacing, since you won't have any ack > clock yet. =A0This might help reduce losses and delay jitter. Agreed. The question is, what is that threshold of window/burst size beyond which pacing is required. My current guess is > 10. Jerry > > =A0-John > > > > On Wed, Feb 3, 2010 at 9:28 AM, Lars Eggert wrote= : >> Hi, >> >> Jerry Chu has recently started the discussion on whether we need to thin= k about tweaking TCP for the "modern Internet." Just came across another pr= esentation from (AFAICT) another corner of Google that makes similar argume= nts. >> >> FYI: http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Cha= nging_TCP_Slow_Start.pdf >> >> This topic seems to be gaining momentum, and the WG should take some tim= e considering if there is work here for it. >> >> Lars >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From Anumita.Biswas@netapp.com Wed Feb 3 11:00: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 0FE1528C1F5 for ; Wed, 3 Feb 2010 11:00:45 -0800 (PST) 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 bswTAgu2vFzD for ; Wed, 3 Feb 2010 11:00:44 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id AACAF28C1FA for ; Wed, 3 Feb 2010 10:39:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,399,1262592000"; d="scan'208";a="310634435" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 03 Feb 2010 10:39:38 -0800 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 o13IdO7u004047; Wed, 3 Feb 2010 10:39:37 -0800 (PST) Received: from SACMVEXC2-PRD.hq.netapp.com ([10.99.115.18]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 10:39:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Feb 2010 10:39:14 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP tuning Thread-Index: Acqk/alwBu5qsAVXSfWwjdzrXrNC6QAAZMoQ From: "Biswas, Anumita" To: "Jerry Chu" , "Michael Welzl" X-OriginalArrivalTime: 03 Feb 2010 18:39:26.0032 (UTC) FILETIME=[3622E500:01CAA500] X-Mailman-Approved-At: Wed, 03 Feb 2010 12:44:23 -0800 Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 19:00:45 -0000 > -----Original Message----- > From: Jerry Chu [mailto:hkchu@google.com]=20 > Sent: Wednesday, February 03, 2010 10:21 AM > To: Michael Welzl > Cc: tcpm@ietf.org WG > Subject: Re: [tcpm] TCP tuning >=20 >=20 > Michael, >=20 > On Wed, Feb 3, 2010 at 6:42 AM, Michael Welzl=20 > wrote: > > Hi all, > > > > (sorry if this is a bit off topic, as the mentioned presentation is=20 > > mainly about using a larger initial window) > > > > In the context of the discussion that Jerry brought up on parameter=20 > > tuning, one question that was raised was the initial RTO during the=20 > > SYN - SYN/ACK exchange. I understand that we can't=20 > recommend to resend=20 > > SYN's more aggressively because this might cause a server to be=20 > > overloaded with SYN's, but why do we have to wait extremely=20 > long until=20 > > we resend SYN/ACKs? > > > > Back then, when I asked, I got no answer. Both Jerry and I=20 > pointed to=20 > > our measurement results which show that the effect is nonneglible. >=20 > Actually Mark Allman, Vern Paxon and I have been working on=20 > revising RFC2988 to reduce the initial RTO from 3secs to=20 > 1sec. Will submit the proposal soon! >=20 This implies that this proposal brings the intial RTO value to be equal = to the minimum RTO value of 1 second. Is this true?=20 I am going by RFC 2988, section 2, 2.4. It explicitly states this: " (2.4) Whenever RTO is computed, if it is less than 1 second then the RTO SHOULD be rounded up to 1 second. Traditionally, TCP implementations use coarse grain clocks to measure the RTT and trigger the RTO, which imposes a large minimum value on the RTO. Research suggests that a large minimum RTO is needed to keep TCP conservative and avoid spurious retransmissions [AP99]. Therefore, this specification requires a large minimum RTO as a conservative approach, while at the same time acknowledging that at some future point, research may show that a smaller minimum RTO is acceptable or superior." Is it time to reconsider a smaller minimum RTO as well?=20 > Best, >=20 > Jerry >=20 > > > > So I'll use this chance to ask again =A0:-) > > > > Cheers, > > Michael > > > > > > On Feb 3, 2010, at 3:28 PM, Lars Eggert wrote: > > > >> Hi, > >> > >> Jerry Chu has recently started the discussion on whether=20 > we need to=20 > >> think about tweaking TCP for the "modern Internet." Just=20 > came across=20 > >> another presentation from (AFAICT) another corner of Google that=20 > >> makes similar arguments. > >> > >> FYI:=20 > >>=20 > http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Chang > >> ing_TCP_Slow_Start.pdf > >> > >> This topic seems to be gaining momentum, and the WG should=20 > take some=20 > >> time considering if there is work here for it. > >> > >> Lars_______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From hkchu@google.com Wed Feb 3 12:47: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 86CE328C0FC for ; Wed, 3 Feb 2010 12:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, 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 TdeUFb9UAEIq for ; Wed, 3 Feb 2010 12:47:35 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3CE6728C121 for ; Wed, 3 Feb 2010 12:47:35 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o13KmI1n030618 for ; Wed, 3 Feb 2010 12:48:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265230098; bh=ScXiDZvhyQTDISSRsEC1961+TvM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=yWP14AarvATfQISzU7rCwN5hDSPKziGtnomvoeH59JFQW2n07Gv1WCIylviTueU1v 66rClJUI0DoTIZvY0kj8Q== 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=InfA3rexyRZJCjwq2X31WECMq4Uf3u0M6tcGh2VIXQAoX3X77AzQxlgf4IIbSYF+c 83t/5kEiK6WTPD4Zgxm0w== Received: from pxi26 (pxi26.prod.google.com [10.243.27.26]) by kpbe19.cbf.corp.google.com with ESMTP id o13KlIRF026393 for ; Wed, 3 Feb 2010 12:48:17 -0800 Received: by pxi26 with SMTP id 26so2114197pxi.17 for ; Wed, 03 Feb 2010 12:48:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.56.2 with SMTP id e2mr102875rva.37.1265230095387; Wed, 03 Feb 2010 12:48:15 -0800 (PST) In-Reply-To: <4B69C35F.9080903@isi.edu> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> <8FCC1879-FBA4-4A5F-8ADF-932A6731B7EA@ifi.uio.no> <4B69C35F.9080903@isi.edu> Date: Wed, 3 Feb 2010 12:48:15 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, Kacheong Poon , Michael Welzl Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 20:47:36 -0000 On Wed, Feb 3, 2010 at 10:41 AM, Joe Touch wrote: > > > Michael Welzl wrote: >>>> In other words, why not harness this knowledge somehow, >>>> and develop a customized transport protocol, or ways of >>>> customizing what we now have? >>> >>> That's been tried in various ways in various IETF efforts. Some try to >>> find the properties of the immediate link, which are expected for some >>> link types to dominate the path. Some try to detect path properties. >>> Some reuse information from past connections. >> >> Really? I'd be curious about a few pointers, what exactly >> do you have in mind? About reusing information etc., the >> congestion manager and your TCB sharing stuff comes to >> mind, but for the rest I'm curious > > Spencer Dawkins probably recalls better than I; I think there were > numerous BOFs centered around "link indications", including: > =A0 =A0 =A0 =A0TRIGTRAN BOF > =A0 =A0 =A0 =A0"LinkUp" > =A0 =A0 =A0 =A0draft-dawkins-linkup-nevermind > =A0 =A0 =A0 =A0LCI BOF (Link Characteristic Information for Mobility) > =A0 =A0 =A0 =A0MPTCP WG > =A0 =A0 =A0 =A0LEDBAT WG > =A0 =A0 =A0 =A0RFC-4709 The following is quoted from RFC3150 (a BCP): "Implementors should consider the possibility that a host will be directly connected to a low-speed link when choosing default TCP receive window sizes." Jerry > > Joe > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From johnwheffner@gmail.com Wed Feb 3 12:50:24 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 A083B3A6B2E for ; Wed, 3 Feb 2010 12:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 BI5EMbkTCWzs for ; Wed, 3 Feb 2010 12:50:23 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 785C33A6816 for ; Wed, 3 Feb 2010 12:50:23 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so449547eye.51 for ; Wed, 03 Feb 2010 12:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UbDMLj8enJQhLKczCdMnNBtVO38vWbEahsuM4Bcfzus=; b=OplQt9AS+aiYr4hCE1ScgRJenCHYEA+Fo6U1uXwuQ7aBpej11MclIAAqXjJ9HWywpm QrdNs9IZfuGRt0GD9gyaBmlLmWLafiMt88LjoVNTDU25rzJCW7hxONwIIDTfTbfdZnDY aqrazNaBTFUgUqZRf89X5txYMx+2rbYkYLRoI= 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:content-transfer-encoding; b=O3WRFHFg+9KGnAjeooisbqJGzSPcyrO2LHNZSGz3QFB8h+7Eer077Csn0L0U90zdiB 6+M7at/dHyQlS1V84ULtiNZqd4oFZW5NNnq3ow0bJStNrd3u0DcMSuf3aWqNSJ3IsbzP bQwoQXKfSpD3FI+v9+bcgMV6k15BhbJDZMhHU= MIME-Version: 1.0 Received: by 10.216.162.3 with SMTP id x3mr94028wek.21.1265230263398; Wed, 03 Feb 2010 12:51:03 -0800 (PST) In-Reply-To: References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> Date: Wed, 3 Feb 2010 15:51:03 -0500 Message-ID: <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com> From: John Heffner To: Jerry Chu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 20:50:24 -0000 On Wed, Feb 3, 2010 at 3:44 PM, Jerry Chu wrote: > Hi John, > > On Wed, Feb 3, 2010 at 12:32 PM, John Heffner wr= ote: >> A couple thoughts: >> - A large initial window should probably only be used by mutual >> agreement. =A0Maybe via a TCP option during the handshake? > > This may not be needed. A receiver can effectively constrain the > sender's window by advertising a smaller initial receive window. > > Obviously this works for only the initial window, not the restart window. > (Oh, on a second thought this can be made to work for the restart > window too.) A good point, though most receivers (Linux 2.4 and later being the exception) advertise all available window space, not expecting a large initial burst from the sender. I think you need a negotiation for opt-in rather than opt-out. -John From eblanton@cs.ohiou.edu Wed Feb 3 13:07: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 BE7B228C0E1 for ; Wed, 3 Feb 2010 13:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 OKW-SKSwVZF5 for ; Wed, 3 Feb 2010 13:07:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CFB653A6B3F for ; Wed, 3 Feb 2010 13:07:44 -0800 (PST) Received: from [99.52.196.7] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NcmSX-000Hqr-Hf; Wed, 03 Feb 2010 21:08:25 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id CE68C3BCA4; Wed, 3 Feb 2010 16:08:24 -0500 (EST) Date: Wed, 3 Feb 2010 16:08:24 -0500 From: Ethan Blanton To: Alfred =?iso-8859-1?Q?H=F6nes?= Message-ID: <20100203210824.GA23708@colt> Mail-Followup-To: Alfred =?iso-8859-1?Q?H=F6nes?= , tcpm@ietf.org References: <201001281906.UAA10585@TR-Sys.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <201001281906.UAA10585@TR-Sys.de> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: tcpm@ietf.org Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09 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, 03 Feb 2010 21:07:45 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alfred H=F6nes spake unto us the following wisdom: > It cannot be denied that the TCPM processes are broken. > That's a basic, general matter of fact. > Everybody can find evidence in the archives. Well, I try not to get involved in process rants, but you just drug me directly into this one. I will send one message, and one message only, on this topic. I do not presume to speak for my co-authors on RFC 5681. > I've arbitrarily picked a TCPM charter snapshot (from May 2008) : > >=20 > | TCP Maintenance and Minor Extensions (tcpm) > | > | Last Modified: 2008-04-23 > | > | ... > | > | Goals and Milestones: > | > | ... > | > | Oct 2006 Submit revision of RFC 2581 to the IESG for publication > | as a Draft Standard. >=20 > (Sic. In May 2008. Time journey? Hibernation? Honest, at least.) Yes. RFC 5681 took a long time to get out. It was NOT, however, due to any alleged adverse actions of vocal mailing list members. In fact, if anything, the WG's *failure to comment* at various stages slowed the draft down more than any comments we actually received. The mailing list involvement of the working group was, in my opinion, a net positive contribution to the document. If you're looking for someone to blame for the slothful progress of that draft, don't blame comments on the mailing list. Blame, in order: 1) Me 2) General non-participation in WG activities Comments rolling in only after weeks or months of silence, process to be iterated ad nauseam, were a bit of a problem for 5681. That said, we got it done, I think it is a valuable update, and I don't think it arrived anything like too late to be useful. Would it have been better to see it in 2006 than in 2009? Sure. Were useful changes incorporated between Oct of 2006 and the final publication? Absolutely. Could the comments leading to those changes have been sent earlier by the participants who actually engaged the process and caused the WG to function as it should? Probably, but I sure didn't pay them for their time, so as it stands I'm simply grateful that they chose to participate, and that they made the Internet standards body that much more correct and complete. In short, I agree with David Borman's summary of the participation situation. There may be WG issues (I will not take a strong position on this; I'm inclined to agree with the spirit of the argument, but I suspect not the details -- it *should* be difficult to get a controversial change into the TCP standards body), but I want to publicly state that, as an author of a document singled out as an example, I don't feel that over-zealous or ill-conceived feedback was AT ALL responsible for the sluggish progress of 5681. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS2nlyP8fixZ3H8crAQiyQQf/WajgctRt/RO8GxWnf/xRQ1Po4BdWekC1 yU2e0GWpkU7dlswvEG9M8hlp8LAtp1jumESULDw4npru0d33s4RXY1JQXGJnjGGE SLc1Z0693ftoiAbrlGn3F7nJJP9YOvQy7gTxInWkOsxuHYGravYWywneeFjkV3qu nwsUY5f10n1vynvDCwE/MM41+xABsh9g/JCXSgvRaGhBj0EQIK5tOCyq59DVijTb tDMm3ZT8RjNlg/q8nLPgWxF9vziZZhnfTpdwcq5j8MhYQjmUBcTHhkG0UGXNQ9df CwLpUBxMJtKfJ82SN1xqjfCEW7h1jt+UKipg80zaedBJGub9xQ/bGw== =27eC -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From hkchu@google.com Wed Feb 3 13:38: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 BBD0C3A69C5 for ; Wed, 3 Feb 2010 13:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, 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 q9t3yHiEOCgP for ; Wed, 3 Feb 2010 13:38:41 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D48CB3A6996 for ; Wed, 3 Feb 2010 13:38:40 -0800 (PST) Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id o13LdNTY031077 for ; Wed, 3 Feb 2010 13:39:23 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265233164; bh=vkYZqZnBhkHqHPM7QGEyJVPFTPU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=gFDGRRiFXS1WHJe9TQUkWW5YXMIR7lwenOK8QVpbqfcMwazjdx6XSBKF4XKMP/yxu AUFIDZ8v5S4QY5maAh9xw== 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:x-system-of-record; b=VYh/JOlYqMJGzgmq9w0M4E55aTv4hbzQ28A63TB3bkDCUmcEtTcq3Mvgn96pzoPIr avlbgRckIxPSXEepwKblQ== Received: from pzk14 (pzk14.prod.google.com [10.243.19.142]) by spaceape10.eur.corp.google.com with ESMTP id o13LcBt7004718 for ; Wed, 3 Feb 2010 13:39:22 -0800 Received: by pzk14 with SMTP id 14so526764pzk.3 for ; Wed, 03 Feb 2010 13:39:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.179.20 with SMTP id b20mr142531rvf.47.1265233161568; Wed, 03 Feb 2010 13:39:21 -0800 (PST) In-Reply-To: <4B69CDD7.6060802@isi.edu> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> Date: Wed, 3 Feb 2010 13:39:21 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 21:38:41 -0000 On Wed, Feb 3, 2010 at 11:26 AM, Joe Touch wrote: > > > Jerry Chu wrote: >> On Wed, Feb 3, 2010 at 7:17 AM, SCHARF, Michael >> wrote: >>>> This topic seems to be gaining momentum, and the WG should >>>> take some time considering if there is work here for it. >>> IMHO there could indeed be room for increasing the initial window. If >>> most data transfers continue to be smaller than 3 MSS, a larger initial >>> window would not necessarily cause harm, as it is seldomly used. Still, >>> this would speed up those data transfers that currently suffer from >>> Slow-Start. >> >> Actually our data points to the contrary - the average web object and page >> size have been rising steadily. E.g., the majority of our search responses >> no longer fit in 3 MSS these days. > > This should be relevant only for the first response from a given IP > address; persistent connections should render this moot for subsequent > requests. Yes we are well aware of the advantage of maintaining persistent connections. In fact this is one of the reasons holding us back from resurrecting T/TCP (in addition to other security issues). But from our own observation the average HTTP connections just don't persistent that long for some reason. I don't remember the data or all the technical reasons on top of my head, but can surely try to get them for you. There are other limitations of HTTP 1/1: 1. obviously its effectiveness depends on user's web surfing pattern. 2. web browsers have been going down the slope of opening more and more simultaneous connections anyway, partly to circumvent HTTP's serialization, an issue SPDY tries to address. 3. practically web servers have only limited resources. can't hold too many open connections. 4. a web object will make the TCP slow start algorithm to grow its cwnd only upto the size of the object. As such, even with persistent connections, a web object that is larger than any of its predecessors will hit the window limit, and take more than one round trip time to complete. So persistent connections might not be as effective as one might think. > > Again, the question arises as to how much this is going to achieve a > noticeable impact. Quite significant in our study. Will present our result at IETF/Anaheim. Jerry > > Joe > > From Anumita.Biswas@netapp.com Wed Feb 3 13:49: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 0E2C53A6876 for ; Wed, 3 Feb 2010 13:49:49 -0800 (PST) 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=[AWL=0.000, 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 TDxgJsunU+By for ; Wed, 3 Feb 2010 13:49:48 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 155CB3A67FE for ; Wed, 3 Feb 2010 13:49:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,400,1262592000"; d="scan'208";a="310728780" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Feb 2010 13:50:31 -0800 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o13LoVam016344; Wed, 3 Feb 2010 13:50:31 -0800 (PST) Received: from SACMVEXC2-PRD.hq.netapp.com ([10.99.115.18]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 13:50:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Feb 2010 13:50:29 -0800 Message-ID: In-Reply-To: <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP tuning Thread-Index: AcqlEqL9ajeA0srbSgGuDYmBpkbAuAAB2F8Q References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com><1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com> From: "Biswas, Anumita" To: "John Heffner" , "Jerry Chu" X-OriginalArrivalTime: 03 Feb 2010 21:50:31.0317 (UTC) FILETIME=[E7FA8C50:01CAA51A] Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 21:49:49 -0000 > -----Original Message----- > From: John Heffner [mailto:johnwheffner@gmail.com] > Sent: Wednesday, February 03, 2010 12:51 PM > To: Jerry Chu > Cc: tcpm@ietf.org WG > Subject: Re: [tcpm] TCP tuning >=20 > On Wed, Feb 3, 2010 at 3:44 PM, Jerry Chu wrote: > > Hi John, > > > > On Wed, Feb 3, 2010 at 12:32 PM, John Heffner > wrote: > >> A couple thoughts: > >> - A large initial window should probably only be used by mutual > >> agreement. =A0Maybe via a TCP option during the handshake? > > > > This may not be needed. A receiver can effectively constrain the > > sender's window by advertising a smaller initial receive window. > > > > Obviously this works for only the initial window, not the restart > window. > > (Oh, on a second thought this can be made to work for the restart > > window too.) >=20 > A good point, though most receivers (Linux 2.4 and later being the > exception) advertise all available window space, not expecting a large > initial burst from the sender. I think you need a negotiation for > opt-in rather than opt-out. The slow start algorithm tries to probe the network capacity, not the = end node's available window space. The network capacity is dependent on = switch/router queue lengths, among other things and therefore the = initial receive window is not something that can/should be negotiated by = end points.=20 However, I do have reservations with standardizing an increased initial = window assuming that 10 MSS is a good "guess" for what the network can = tolerate. I have seen cases where switches topple over initial receive window = sizes as spec'd out by RFC 3390. In fact, RFC 3390 does state that the = recommended IW value of 4 segments for 1500MSS can cause more loss in = networks with higher segment drop rates. >=20 > -John > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Wed Feb 3 13:59:39 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 5E84B3A695C for ; Wed, 3 Feb 2010 13:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 Is9zahA51O8j for ; Wed, 3 Feb 2010 13:59:38 -0800 (PST) Received: from get-mta-out01.get.basefarm.net (smtp.getmail.no [84.208.15.66]) by core3.amsl.com (Postfix) with ESMTP id 7FB353A6950 for ; Wed, 3 Feb 2010 13:59:38 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from smtp.getmail.no ([10.5.16.4]) by get-mta-out01.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA00KKND4LSUE0@get-mta-out01.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 23:00:21 +0100 (MET) Received: from [192.168.0.194] ([84.208.136.71]) by get-mta-in01.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA00KVKD3XAG30@get-mta-in01.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 23:00:20 +0100 (MET) X-PMX-Version: 5.5.3.366731, Antispam-Engine: 2.7.0.366912, Antispam-Data: 2010.2.3.214821 Message-id: <0F35D991-4C33-45D9-B7C0-4DB6D70A510C@ifi.uio.no> From: Michael Welzl To: Joe Touch In-reply-to: <4B69C35F.9080903@isi.edu> Date: Wed, 03 Feb 2010 22:59:57 +0100 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> <8FCC1879-FBA4-4A5F-8ADF-932A6731B7EA@ifi.uio.no> <4B69C35F.9080903@isi.edu> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, Kacheong Poon Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 21:59:39 -0000 On Feb 3, 2010, at 7:41 PM, Joe Touch wrote: > > > Michael Welzl wrote: >>>> In other words, why not harness this knowledge somehow, >>>> and develop a customized transport protocol, or ways of >>>> customizing what we now have? >>> >>> That's been tried in various ways in various IETF efforts. Some >>> try to >>> find the properties of the immediate link, which are expected for >>> some >>> link types to dominate the path. Some try to detect path properties. >>> Some reuse information from past connections. >> >> Really? I'd be curious about a few pointers, what exactly >> do you have in mind? About reusing information etc., the >> congestion manager and your TCB sharing stuff comes to >> mind, but for the rest I'm curious > > Spencer Dawkins probably recalls better than I; I think there were > numerous BOFs centered around "link indications", including: > TRIGTRAN BOF > "LinkUp" > draft-dawkins-linkup-nevermind > LCI BOF (Link Characteristic Information for Mobility) > MPTCP WG > LEDBAT WG > RFC-4709 Thanks! I was aware about some (I liked trigtran and was sad to see it fail) but definitely not all of these. At least LEDBAT doesn't seem to fit in the list btw Cheers, Michael From hkchu@google.com Wed Feb 3 14:01:20 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 06E1E3A6A2C for ; Wed, 3 Feb 2010 14:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, 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 ZnUXknzNBSCF for ; Wed, 3 Feb 2010 14:01:19 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D71413A6950 for ; Wed, 3 Feb 2010 14:01:18 -0800 (PST) Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id o13M2191011259 for ; Wed, 3 Feb 2010 14:02:01 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265234522; bh=snlE0lehgK7B14k3fsGCif0CZco=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=xCPmL3Z4yeGDcTXy2AOrtHsojKSKFv9K2ldRTqMyMqyNzcpor3j7FSuzyE0iPkS9s Iik+1Q3c+7Tp8yU8BZbsg== 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=WZeluWLbi99U1u78OPA+VczTRKNe0JnI2FxmO4ycOAiCrgAUwEno18Ctb6VcPxs1y 9oMBCG1wGQ+A6yRFTJTmw== Received: from pxi38 (pxi38.prod.google.com [10.243.27.38]) by spaceape8.eur.corp.google.com with ESMTP id o13M1x5V028795 for ; Wed, 3 Feb 2010 14:02:00 -0800 Received: by pxi38 with SMTP id 38so1975176pxi.28 for ; Wed, 03 Feb 2010 14:01:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.88.1 with SMTP id q1mr132148rvl.203.1265234503260; Wed, 03 Feb 2010 14:01:43 -0800 (PST) In-Reply-To: <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com> Date: Wed, 3 Feb 2010 14:01:43 -0800 Message-ID: From: Jerry Chu To: John Heffner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:01:20 -0000 On Wed, Feb 3, 2010 at 12:51 PM, John Heffner wrot= e: > On Wed, Feb 3, 2010 at 3:44 PM, Jerry Chu wrote: >> Hi John, >> >> On Wed, Feb 3, 2010 at 12:32 PM, John Heffner w= rote: >>> A couple thoughts: >>> - A large initial window should probably only be used by mutual >>> agreement. =A0Maybe via a TCP option during the handshake? >> >> This may not be needed. A receiver can effectively constrain the >> sender's window by advertising a smaller initial receive window. >> >> Obviously this works for only the initial window, not the restart window= . >> (Oh, on a second thought this can be made to work for the restart >> window too.) > > A good point, though most receivers (Linux 2.4 and later being the > exception) advertise all available window space, not expecting a large > initial burst from the sender. =A0I think you need a negotiation for > opt-in rather than opt-out. Yes, Linux 2.4 and later constrain its initial receive window per RFC3390, making it harder for any future change to initcwnd to be deployed (i.e., bo= th sides' stack need to change). We're trying to fix this. See http://www.spinics.net/lists/netdev/msg115912.html. The change will also be useful for those hosts behind slow links for purpos= es mentioned before. Jerry > > =A0-John > From MBashyam@OcarinaNetworks.com Wed Feb 3 14:01: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 3E18E3A6B52 for ; Wed, 3 Feb 2010 14:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 e+qBPAqz36OG for ; Wed, 3 Feb 2010 14:01:42 -0800 (PST) Received: from mail.ocarinanetworks.com (mail.ocarinanetworks.com [69.3.29.22]) by core3.amsl.com (Postfix) with ESMTP id 60D913A6A2C for ; Wed, 3 Feb 2010 14:01:42 -0800 (PST) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Wed, 3 Feb 2010 14:03:42 -0800 From: Murali Bashyam To: Jerry Chu , Joe Touch Date: Wed, 3 Feb 2010 14:03:36 -0800 Thread-Topic: [tcpm] TCP tuning Thread-Index: AcqlGYt77DuHGvUCSs6AGQ/i16dKrQAAS4WQ Message-ID: References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> 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 Cc: "tcpm@ietf.org" , "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:01:43 -0000 Any idle period higher than the RTT between HTTP requests tends to reset th= e cwindow down to the restart window. This hurts persistent connections too= . What's the motivation for this, can we have a different slope while reduc= ing the window instead of resetting all the way down? -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Jer= ry Chu Sent: Wednesday, February 03, 2010 1:39 PM To: Joe Touch Cc: tcpm@ietf.org; SCHARF, Michael Subject: Re: [tcpm] TCP tuning On Wed, Feb 3, 2010 at 11:26 AM, Joe Touch wrote: > > > Jerry Chu wrote: >> On Wed, Feb 3, 2010 at 7:17 AM, SCHARF, Michael >> wrote: >>>> This topic seems to be gaining momentum, and the WG should >>>> take some time considering if there is work here for it. >>> IMHO there could indeed be room for increasing the initial window. If >>> most data transfers continue to be smaller than 3 MSS, a larger initial >>> window would not necessarily cause harm, as it is seldomly used. Still, >>> this would speed up those data transfers that currently suffer from >>> Slow-Start. >> >> Actually our data points to the contrary - the average web object and pa= ge >> size have been rising steadily. E.g., the majority of our search respons= es >> no longer fit in 3 MSS these days. > > This should be relevant only for the first response from a given IP > address; persistent connections should render this moot for subsequent > requests. Yes we are well aware of the advantage of maintaining persistent connection= s. In fact this is one of the reasons holding us back from resurrecting T/TCP (in addition to other security issues). But from our own observation the average HTTP connections just don't persistent that long for some reason. I don't remember the data or all the technical reasons on top of my head, but can surely try to get them for you. There are other limitations of HTTP 1/1: 1. obviously its effectiveness depends on user's web surfing pattern. 2. web browsers have been going down the slope of opening more and more simultaneous connections anyway, partly to circumvent HTTP's serialization, an issue SPDY tries to address. 3. practically web servers have only limited resources. can't hold too many open connections. 4. a web object will make the TCP slow start algorithm to grow its cwnd only upto the size of the object. As such, even with persistent connections= , a web object that is larger than any of its predecessors will hit the windo= w limit, and take more than one round trip time to complete. So persistent connections might not be as effective as one might think. > > Again, the question arises as to how much this is going to achieve a > noticeable impact. Quite significant in our study. Will present our result at IETF/Anaheim. Jerry > > Joe > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Wed Feb 3 14:10: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 6C42928C0CF for ; Wed, 3 Feb 2010 14:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 p0O8zzafUxGe for ; Wed, 3 Feb 2010 14:10:30 -0800 (PST) Received: from get-mta-out02.get.basefarm.net (smtp.getmail.no [84.208.15.66]) by core3.amsl.com (Postfix) with ESMTP id B7ADE3A6984 for ; Wed, 3 Feb 2010 14:10:29 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from smtp.getmail.no ([10.5.16.4]) by get-mta-out02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA00D4WDMOUW90@get-mta-out02.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 23:11:13 +0100 (MET) Received: from [192.168.0.194] ([84.208.136.71]) by get-mta-in02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA00659DM3J100@get-mta-in02.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 23:11:12 +0100 (MET) X-PMX-Version: 5.5.3.366731, Antispam-Engine: 2.7.0.366912, Antispam-Data: 2010.2.3.215726 Message-id: <316A6EC9-03FF-4A11-9E1E-084220A8146A@ifi.uio.no> From: Michael Welzl To: Jerry Chu In-reply-to: Date: Wed, 03 Feb 2010 23:10:50 +0100 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, Kacheong Poon , Joe Touch Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:10:32 -0000 Hi, >> http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG >> >> IMO, I would encourage Google to take their work there and get >> feedback >> there first. TCPM is a place where mature, vetted ideas should be >> considered, preferably (IMO). > > Sure we can do that and will love to hear feedback from ICCRG. But our > preference is IETF simply because we consider a simple, modest > increase of the initial window to be more of an engineering project > than > a research problem. The former is more about engineering tradeoff > between > cost/risk, benefit and TIMELINESS than a research project to find > the best, > elegant, risk free solution with little or no time-to-market concern. Without trying to get into a debate on engineering vs. research, I would say that the research community's perception of TCP research is that, indeed, such a change is a valid research question. That's not because of a need to find the "best, elegant, risk free solution", but because of the need to make sure that it's a solution that's safe to deploy. This is indeed at odds with needs for timeliness - but your need for that can't be the basis for lowering the bar about significant changes to TCP in the IETF. > We are aware of all the great research work being conducted at ICCRG > on speeding up slow-start. But none of the proposals seems ready for > IETF anytime soon. I'd be happy to be proven wrong here! (Well to be > more correct a modest increase of initial window may have already been > studied at ICCRG. In that case I'd rephrase it to be the closest to > engineering consideration IMHO.) The proposals that have been made in the ICCRG context were not there because this is the most, or only, appropriate way to do things in ICCRG - they were there because they were proposed. I would love to see proposals for more "IETF-ready" approach there. I don't think that a modest increase of the initial window has been considered in the ICCRG context, and it would fit very well. Cheers, Michael From johnwheffner@gmail.com Wed Feb 3 14:11:03 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 7E0DB3A6B66 for ; Wed, 3 Feb 2010 14:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Mv5EvZvOc0kp for ; Wed, 3 Feb 2010 14:11:02 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 4973E3A6984 for ; Wed, 3 Feb 2010 14:11:02 -0800 (PST) Received: by ewy28 with SMTP id 28so2038677ewy.28 for ; Wed, 03 Feb 2010 14:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9ufjD4zJzj+9oMmRq/JM2ENbDOjbPk9lkkr2eSDfA2Y=; b=pstfolVKlYFaaHjXJPdLwYzuVn/Ca+TiG3VsXPQsVwW2G2fIigO/UK96+F7AWry2bW nm/zHRb6F7Dfj1EkNxBHvqooEZvPNUz31m+Kw3vD3O96piXzbnERx68Lyq49S7wwCKsq 3mWJvuuZlxX3OTboYxtWrZ6h1Bpgj6S9R+l5U= 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:content-transfer-encoding; b=QmdHKVCYWmEyMXBrHtYfxn0OyDywFeiNbD/rUOleF3CLvF551J7Fr0tUYGKwo5SaLa 8L0e232moll/9mrq+DHHQYKTBa6zTaK+oO9YEiKbFxqwN1fGWCizlbiDiCH6eYCzjQR5 dEeFtvhWa6bisr3gJkmySo4wvD46S1qqZMkFQ= MIME-Version: 1.0 Received: by 10.216.91.15 with SMTP id g15mr139467wef.24.1265235102063; Wed, 03 Feb 2010 14:11:42 -0800 (PST) In-Reply-To: References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> Date: Wed, 3 Feb 2010 17:11:41 -0500 Message-ID: <1e41a3231002031411u57a79ffas1fa77988e83343c0@mail.gmail.com> From: John Heffner To: Murali Bashyam Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:11:03 -0000 On Wed, Feb 3, 2010 at 5:03 PM, Murali Bashyam wrote: > Any idle period higher than the RTT between HTTP requests tends to reset = the cwindow down to the restart window. This hurts persistent connections t= oo. What's the motivation for this, can we have a different slope while red= ucing the window instead of resetting all the way down? This is because you lose the ack clock. Otherwise, when resuming sending you'll send a line-rate burst of the full BDP, which will often overflow queues and cause loss and/or large delay spikes. There is currently no pacing mechanism in TCP to smooth out such bursts. -John From touch@ISI.EDU Wed Feb 3 14:21: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 5F95C3A68B0 for ; Wed, 3 Feb 2010 14:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U83RN6bds3Vw for ; Wed, 3 Feb 2010 14:21:26 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 839B93A6876 for ; Wed, 3 Feb 2010 14:21:26 -0800 (PST) Received: from [70.213.251.114] (114.sub-70-213-251.myvzw.com [70.213.251.114]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13MKGNt013028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 14:20:18 -0800 (PST) Message-ID: <4B69F69F.3030503@isi.edu> Date: Wed, 03 Feb 2010 14:20:15 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jerry Chu References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> <8FCC1879-FBA4-4A5F-8ADF-932A6731B7EA@ifi.uio.no> <4B69C35F.9080903@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig393E238C35FC0D9CDCC4C19E" X-MailScanner-ID: o13MKGNt013028 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Kacheong Poon , Michael Welzl Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:21:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig393E238C35FC0D9CDCC4C19E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jerry Chu wrote: =2E.. > The following is quoted from RFC3150 (a BCP): >=20 > "Implementors should consider the possibility that a host will be > directly connected to a low-speed link when choosing default TCP > receive window sizes." Yup. "Be conservative in what you do". Joe --------------enig393E238C35FC0D9CDCC4C19E 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) iEYEARECAAYFAktp9p8ACgkQE5f5cImnZrtsMwCg/l0ZUcTvh/coip93u5UAiL1N bIIAoPkQVP9PWtlv062IKk/OGsxiWyow =8WLK -----END PGP SIGNATURE----- --------------enig393E238C35FC0D9CDCC4C19E-- From touch@ISI.EDU Wed Feb 3 14:25: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 5D3463A695C for ; Wed, 3 Feb 2010 14:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-X448DBOfyv for ; Wed, 3 Feb 2010 14:25:43 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 800B23A6957 for ; Wed, 3 Feb 2010 14:25:43 -0800 (PST) Received: from [70.213.251.114] (114.sub-70-213-251.myvzw.com [70.213.251.114]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13MP022014044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 14:25:23 -0800 (PST) Message-ID: <4B69F7BC.3000204@isi.edu> Date: Wed, 03 Feb 2010 14:25:00 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jerry Chu References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB8C53DE9D8A426DF237BBA15" X-MailScanner-ID: o13MP022014044 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:25:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB8C53DE9D8A426DF237BBA15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jerry Chu wrote: =2E... >>> Actually our data points to the contrary - the average web object and= page >>> size have been rising steadily. E.g., the majority of our search resp= onses >>> no longer fit in 3 MSS these days. >> >> This should be relevant only for the first response from a given IP >> address; persistent connections should render this moot for subsequent= >> requests. >=20 > Yes we are well aware of the advantage of maintaining persistent connec= tions. > In fact this is one of the reasons holding us back from resurrecting T/= TCP > (in addition to other security issues). >=20 > But from our own observation the average HTTP connections just don't > persistent that long for some reason. I don't remember the data or all > the technical reasons on top of my head, but can surely try to get them= for > you. I think having all of that in one place would be a good start. > There are other limitations of HTTP 1/1: Persistent connections predates 1.1, FWIW ;-) > 1. obviously its effectiveness depends on user's web surfing pattern. > 2. web browsers have been going down the slope of opening more and > more simultaneous connections anyway, partly to circumvent HTTP's > serialization, an issue SPDY tries to address. > 3. practically web servers have only limited resources. can't hold too = many > open connections. > 4. a web object will make the TCP slow start algorithm to grow its cwnd= > only upto the size of the object. As such, even with persistent connect= ions, > a web object that is larger than any of its predecessors will hit the w= indow > limit, and take more than one round trip time to complete. So persisten= t > connections might not be as effective as one might think. This all depends on many things - e.g., whether the persistent connection is used for a sequence of requests or whether they are interleaved using HTTP 'chunks', the size of the chunks, etc. It's useful as well to keep in mind that HTTP exists because Tim Berners-Lee thought that FTP would be too inefficient, because 'most of the time you only get one file from a site', and he didn't want to open two connections. I.e., one other alternative is to consider FTP's version of multiplexing as well. >> Again, the question arises as to how much this is going to achieve a >> noticeable impact. >=20 > Quite significant in our study. Will present our result at IETF/Anaheim= =2E We've seen initial work on this before, and had a number of questions that remain unanswered. A good start would be to put this all in a tech report. Presentations at the IETF should not get into deep technical detail; they ought to summarize work available before the meeting and provided on the list IMO. Joe --------------enigB8C53DE9D8A426DF237BBA15 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) iEYEARECAAYFAktp97wACgkQE5f5cImnZruvlgCgmJwIKX21BWqr3jqaoSW3WCwk c2QAn2XM5aHtqOxaqV0NftRuk+Bo/70Z =bCbB -----END PGP SIGNATURE----- --------------enigB8C53DE9D8A426DF237BBA15-- From touch@ISI.EDU Wed Feb 3 14:26:14 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 B1C433A69A3 for ; Wed, 3 Feb 2010 14:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpqDByzXo3Ub for ; Wed, 3 Feb 2010 14:26:14 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id E5BED3A695C for ; Wed, 3 Feb 2010 14:26:13 -0800 (PST) Received: from [70.213.251.114] (114.sub-70-213-251.myvzw.com [70.213.251.114]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13MQLXq014244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 14:26:23 -0800 (PST) Message-ID: <4B69F80D.6060603@isi.edu> Date: Wed, 03 Feb 2010 14:26:21 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Welzl References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> <8FCC1879-FBA4-4A5F-8ADF-932A6731B7EA@ifi.uio.no> <4B69C35F.9080903@isi.edu> <0F35D991-4C33-45D9-B7C0-4DB6D70A510C@ifi.uio.no> In-Reply-To: <0F35D991-4C33-45D9-B7C0-4DB6D70A510C@ifi.uio.no> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEC2206B5C6AD59209935F8D7" X-MailScanner-ID: o13MQLXq014244 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Kacheong Poon Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:26:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC2206B5C6AD59209935F8D7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Welzl wrote: =2E.. >> Spencer Dawkins probably recalls better than I; I think there were >> numerous BOFs centered around "link indications", including: >> TRIGTRAN BOF >> "LinkUp" >> draft-dawkins-linkup-nevermind >> LCI BOF (Link Characteristic Information for Mobility) >> MPTCP WG >> LEDBAT WG >> RFC-4709 >=20 > Thanks! I was aware about some (I liked trigtran and was sad to > see it fail) but definitely not all of these. At least LEDBAT doesn't > seem to fit in the list btw There are some people in LEDBAT who raised the issue that how much and how you background might be related to the path properties. That's the relationship. Note that this is just what I could cull from my email archives in a quick pass; there may be other examples of IETF and other work worth checking, FWIW. Joe --------------enigEC2206B5C6AD59209935F8D7 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) iEYEARECAAYFAktp+A0ACgkQE5f5cImnZrtzpACguLZftS23TLHGdgILn9nBgzE5 4GQAoPeDLC1y1DYQGW6GzEyT4ZxV2EmT =KmJ7 -----END PGP SIGNATURE----- --------------enigEC2206B5C6AD59209935F8D7-- From touch@ISI.EDU Wed Feb 3 14:31: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 C6CC63A6817 for ; Wed, 3 Feb 2010 14:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okKEQzyLgfB2 for ; Wed, 3 Feb 2010 14:31:04 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C086A3A65A6 for ; Wed, 3 Feb 2010 14:31:04 -0800 (PST) Received: from [70.213.251.114] (114.sub-70-213-251.myvzw.com [70.213.251.114]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13MV3uk015155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 14:31:05 -0800 (PST) Message-ID: <4B69F927.5020804@isi.edu> Date: Wed, 03 Feb 2010 14:31:03 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Murali Bashyam References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF5DC139BA70BF8D38AFE872F" X-MailScanner-ID: o13MV3uk015155 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:31:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF5DC139BA70BF8D38AFE872F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Murali Bashyam wrote: > Any idle period higher than the RTT between HTTP requests tends to > reset the cwindow down to the restart window. This was first documented in an extension to Jacobson's 1988 Sigcomm paper, in an appendix. The idea is that if you are idle, you shut the window down. However, a footnote in that doc (unpublished, FWIW) suggests that because TCP is used mostly symmetrically, one can use the "time since last receive" instead of "time since last send". As a result, the request tends to reset the timers, and the server just blasts at line rate. This issue is documented in detail in: John Heidemann, Katia Obraczka, and Joe Touch, "Modeling the Performance of HTTP Over Several Transport Protocols", IEEE/ACM Transactions on Networking, V5, N5, Oct. 1997, pp.616-630. A correction to TCP's behavior was suggested on this list, and we worked on it with Sally Floyd for a while ("slow start restart" was the phrase we used). A number of variations were considered, including 'burst or lose', 'use it or lose it', etc. We put that on the shelf a while ago, though we've been interested in 'restarting' it too ;-) Joe --------------enigF5DC139BA70BF8D38AFE872F 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) iEYEARECAAYFAktp+ScACgkQE5f5cImnZrsdVgCfcBGQ93ON/KoC/btxk4fIezV9 daAAoPbAHhZWOkQwpGzQ5oVGBHLi7waO =JPLZ -----END PGP SIGNATURE----- --------------enigF5DC139BA70BF8D38AFE872F-- From touch@ISI.EDU Wed Feb 3 14:42: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 E46E53A680D for ; Wed, 3 Feb 2010 14:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0mXrYGRs6eS for ; Wed, 3 Feb 2010 14:42:07 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 2E0593A65A6 for ; Wed, 3 Feb 2010 14:42:07 -0800 (PST) Received: from [70.213.251.114] (114.sub-70-213-251.myvzw.com [70.213.251.114]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13Mg3h6017463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 14:42:05 -0800 (PST) Message-ID: <4B69FBBB.70500@isi.edu> Date: Wed, 03 Feb 2010 14:42:03 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: John Heffner References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> In-Reply-To: <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDB3A459F535D7C545C047EAE" X-MailScanner-ID: o13Mg3h6017463 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:42:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDB3A459F535D7C545C047EAE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John Heffner wrote: > I would like to see tcpm take on the initial window issue, though as > Joe notes we probably do not yet know enough to formally take this on > as a charter item. (Or, would this be a tsvwg item due to possible > wider impact?) FWIW, I would expect it would be TSVWG, since it would affect all "TCP-friendly" protocols too... Joe --------------enigDB3A459F535D7C545C047EAE 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) iEYEARECAAYFAktp+7sACgkQE5f5cImnZrvWzgCaA2vbDrXWFTL8Fkf51fue6H7Q z7AAoI/ee2wgdxAc6u5Qp285RV3vIERd =Btag -----END PGP SIGNATURE----- --------------enigDB3A459F535D7C545C047EAE-- From hkchu@google.com Wed Feb 3 14:46: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 0FFB53A6873 for ; Wed, 3 Feb 2010 14:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, 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 t3vsVjb5859a for ; Wed, 3 Feb 2010 14:46:48 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 907C33A685D for ; Wed, 3 Feb 2010 14:46:48 -0800 (PST) Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id o13MlVth002245 for ; Wed, 3 Feb 2010 14:47:31 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265237251; bh=fGAUsEneYe7+e/AZXKQb0RcEWr8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=OuLEyt2Jp7lBcmKjGD6mMF7AayMOTj39TvCA6rXIVXb0UZnAKCIxWRgrlrDwGAq22 hBUIvtb54R8f8dfVYK/Ew== 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=CHpV5iuBiaK+MOLK6SywpbNLKChAQBihWJmlbitfQ5tAG2fdiQoXatdP1WF5j43gw 1LlZN/Eaas9jJEPxOyLKQ== Received: from pxi41 (pxi41.prod.google.com [10.243.27.41]) by spaceape8.eur.corp.google.com with ESMTP id o13MlTIb018498 for ; Wed, 3 Feb 2010 14:47:30 -0800 Received: by pxi41 with SMTP id 41so2075873pxi.27 for ; Wed, 03 Feb 2010 14:47:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.251.10 with SMTP id y10mr181459rvh.112.1265237248932; Wed, 03 Feb 2010 14:47:28 -0800 (PST) In-Reply-To: References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com> Date: Wed, 3 Feb 2010 14:47:28 -0800 Message-ID: From: Jerry Chu To: "Biswas, Anumita" 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] TCP tuning 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, 03 Feb 2010 22:46:50 -0000 Hi Anumita, On Wed, Feb 3, 2010 at 1:50 PM, Biswas, Anumita wrote: > > >> -----Original Message----- >> From: John Heffner [mailto:johnwheffner@gmail.com] >> Sent: Wednesday, February 03, 2010 12:51 PM >> To: Jerry Chu >> Cc: tcpm@ietf.org WG >> Subject: Re: [tcpm] TCP tuning >> >> On Wed, Feb 3, 2010 at 3:44 PM, Jerry Chu wrote: >> > Hi John, >> > >> > On Wed, Feb 3, 2010 at 12:32 PM, John Heffner >> wrote: >> >> A couple thoughts: >> >> - A large initial window should probably only be used by mutual >> >> agreement. =A0Maybe via a TCP option during the handshake? >> > >> > This may not be needed. A receiver can effectively constrain the >> > sender's window by advertising a smaller initial receive window. >> > >> > Obviously this works for only the initial window, not the restart >> window. >> > (Oh, on a second thought this can be made to work for the restart >> > window too.) >> >> A good point, though most receivers (Linux 2.4 and later being the >> exception) advertise all available window space, not expecting a large >> initial burst from the sender. =A0I think you need a negotiation for >> opt-in rather than opt-out. > > The slow start algorithm tries to probe the network capacity, not the end= node's available window space. The network capacity is dependent on switch= /router queue lengths, among other things and therefore the initial receive= window is not something that can/should be negotiated by end points. > > However, I do have reservations with standardizing an increased initial w= indow assuming that 10 MSS is a good "guess" for what the network can toler= ate. > > I have seen cases where switches topple over initial receive window sizes= as spec'd out by RFC 3390. In fact, RFC 3390 does state that the recommend= ed IW value of 4 segments for 1500MSS can cause more loss in networks with = higher segment drop rates. Understood the concern. But sometimes we'll need to take active action in order to break the deadlock - TCP spec relying on switch/router upgrade while equipment vendors waiting for TCP spec to be ratified. In this case a modest increase of initcwnd may well be the right one to get both sides into a healthy lockstep toward a faster Internet. This is because the negative impact (% of access switch/router with tiny buffer) is limited and easy (IMHO) to fix while the gain can be significant for the vast majority. This is a good incentive to encourage those left behind to move up the bandwidth curve. Jerry > >> >> =A0 -John >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From mellia@tlc.polito.it Wed Feb 3 14:56:00 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 337653A686A for ; Wed, 3 Feb 2010 14:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.14 X-Spam-Level: X-Spam-Status: No, score=0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 G5wvsDzukr4C for ; Wed, 3 Feb 2010 14:56:00 -0800 (PST) Received: from polito.it (atena.polito.it [130.192.3.45]) by core3.amsl.com (Postfix) with ESMTP id B727D3A680D for ; Wed, 3 Feb 2010 14:55:59 -0800 (PST) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [151.62.47.151] (account d003516@polito.it HELO [192.168.1.2]) by atena.polito.it (CommuniGate Pro SMTP 5.2.16) with ESMTPSA id 30327958 for tcpm@ietf.org; Wed, 03 Feb 2010 23:56:42 +0100 Received-SPF: none receiver=atena.polito.it; client-ip=151.62.47.151; envelope-from=mellia@tlc.polito.it Message-ID: <4B69FF26.2010802@tlc.polito.it> Date: Wed, 03 Feb 2010 23:56:38 +0100 From: Marco Mellia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: tcpm@ietf.org References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> <316A6EC9-03FF-4A11-9E1E-084220A8146A@ifi.uio.no> In-Reply-To: <316A6EC9-03FF-4A11-9E1E-084220A8146A@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:56:00 -0000 Just to try summarizing some points: - Increasing the initial window can benefit short-lived connections. But it can be dangerous, especially on low speed links, and equipments with small buffers. For example, an adsl modem has definitively a small buffer, which is typically overloaded by uploading p2p traffic... initial bursts of "several packet" (e.g., an email with attachments, a POST command with some data in it, etc.) will cause packet losses with high probability. At the end, the latency will be higher... Note that this will happen on any congested link too... - Reducing the RTO timeout is a possibility to get rid of the initial latency due to packet loss during three-way handshake. 3s seems to be too conservative these days. But there are cases in which RTT can be larger than 2s. E.g., 2.5G GSM networks, or congested 3G networks. And these kind of access networks are today more and more popular... and more and more congested... So this calls for a conservative approach. On the flip side, - someone is already hacking the TCP rules: - google is "retransmitting" the SYN-ACK with a timeout of about 200ms. This causes spurious retransmission on practically all tcp connection on a 2.5G network (I remember a paper from FTW showing this...) - windows O.S. (at least XP) is triggering the fast retransmit at the third ACK, not at the third DUPLICATE ack check http://support.microsoft.com/?scid=kb%3Ben-us%3B224829&x=11&y=11 if you don't believe it! Default value is 2 duplicate packets) - large initial windows are commonly seems. 16kB of initial window can be easily observed in any network. I suspect this is related to TCP Offloading Engines (TOE), that perform segmentation at the NIC, or the use of jumbo ethernet frames (9kB) -- the OS sees a "MSS" of 16kB (or 9kB), the initial windows is 1 segment => 10 (6) packets of 1500B each are then generated by the TOE. This supports the position "at the end, it will work in 95% of the cases". Researchers did a lot of studies about TCP latency. But are typically ignored by IETF. -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Skypeid: mgmellia | | Tel: +39-011-564-4173 | | Cel: +39-331-6714789 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www.telematica.polito.it | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. From touch@ISI.EDU Wed Feb 3 14:57: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 A1BE63A68D5 for ; Wed, 3 Feb 2010 14:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 7tbWG1qa4+Bf for ; Wed, 3 Feb 2010 14:57:44 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 99C273A686A for ; Wed, 3 Feb 2010 14:57:44 -0800 (PST) Received: from [70.213.251.114] (114.sub-70-213-251.myvzw.com [70.213.251.114]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13MvjWR020568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 14:57:47 -0800 (PST) Message-ID: <4B69FF69.8040008@isi.edu> Date: Wed, 03 Feb 2010 14:57:45 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jerry Chu References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1B4F09CED43661DAB6B7A208" X-MailScanner-ID: o13MvjWR020568 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Biswas, Anumita" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:57:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B4F09CED43661DAB6B7A208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jerry Chu wrote: > Hi Anumita, >=20 > On Wed, Feb 3, 2010 at 1:50 PM, Biswas, Anumita > wrote: >> >>> -----Original Message----- >>> From: John Heffner [mailto:johnwheffner@gmail.com] >>> Sent: Wednesday, February 03, 2010 12:51 PM >>> To: Jerry Chu >>> Cc: tcpm@ietf.org WG >>> Subject: Re: [tcpm] TCP tuning >>> >>> On Wed, Feb 3, 2010 at 3:44 PM, Jerry Chu wrote: >>>> Hi John, >>>> >>>> On Wed, Feb 3, 2010 at 12:32 PM, John Heffner >>> wrote: >>>>> A couple thoughts: >>>>> - A large initial window should probably only be used by mutual >>>>> agreement. Maybe via a TCP option during the handshake? >>>> This may not be needed. A receiver can effectively constrain the >>>> sender's window by advertising a smaller initial receive window. >>>> >>>> Obviously this works for only the initial window, not the restart >>> window. >>>> (Oh, on a second thought this can be made to work for the restart >>>> window too.) >>> A good point, though most receivers (Linux 2.4 and later being the >>> exception) advertise all available window space, not expecting a larg= e >>> initial burst from the sender. I think you need a negotiation for >>> opt-in rather than opt-out. >> The slow start algorithm tries to probe the network capacity, not the = end node's available window space. The network capacity is dependent on s= witch/router queue lengths, among other things and therefore the initial = receive window is not something that can/should be negotiated by end poin= ts. >> >> However, I do have reservations with standardizing an increased >> initial window assuming that 10 MSS is a good "guess" for what the >> network can tolerate >>=20 >> I have seen cases where switches topple over initial receive window >> sizes as spec'd out by RFC 3390. In fact, RFC 3390 does state that the= >> recommended IW value of 4 segments for 1500MSS can cause more loss in >> networks with higher segment drop rates. >=20 > Understood the concern. But sometimes we'll need to take active > action in order to break the deadlock - TCP spec relying on > switch/router upgrade while equipment vendors waiting for TCP spec to > be ratified. Let's please be clear that: 1) there is NO *urgent* problem We're talking about an optimization. If we do nothing, standards-compliant implementations will continue to work fine. 2) the benefit and impact need to be considered together, for everyone I doubt any logic that assumes both: a) we NEED to make a change for some AND b) this will HURT some others TCP is designed to *always* work (as much as possible). It's more conservative than it needs to be most of the time. Some implementors take advantage of that, and the tragedy of the commons, and get away with things that the IETF may not want to endorse for widespread use. We really need to see the details to move on. Keep in mind as well that if you're modifying TCP, taking the time to document your proposal (no, an extended set of slides is not documentation) is a good indication of your overall diligence (and vice versa). Joe --------------enig1B4F09CED43661DAB6B7A208 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) iEYEARECAAYFAktp/2kACgkQE5f5cImnZrskHgCg1z9awCHxUpKfT5UG8tmONc2k XesAoLlirPPu+wy+QhlCgPo+HxhoiA1l =g8MD -----END PGP SIGNATURE----- --------------enig1B4F09CED43661DAB6B7A208-- From touch@ISI.EDU Wed Feb 3 14:59: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 67CE63A68D5 for ; Wed, 3 Feb 2010 14:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnsrNedguwVJ for ; Wed, 3 Feb 2010 14:59:56 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 99EFD3A685D for ; Wed, 3 Feb 2010 14:59:56 -0800 (PST) Received: from [70.213.251.114] (114.sub-70-213-251.myvzw.com [70.213.251.114]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13MxMtg020706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 14:59:23 -0800 (PST) Message-ID: <4B69FFC9.8090204@isi.edu> Date: Wed, 03 Feb 2010 14:59:21 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marco Mellia References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> <316A6EC9-03FF-4A11-9E1E-084220A8146A@ifi.uio.no> <4B69FF26.2010802@tlc.polito.it> In-Reply-To: <4B69FF26.2010802@tlc.polito.it> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig903E18CD137E341D71B8CAD3" X-MailScanner-ID: o13MxMtg020706 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 22:59:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig903E18CD137E341D71B8CAD3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marco Mellia wrote: =2E.. > On the flip side, >=20 > - someone is already hacking the TCP rules: >=20 > - google is "retransmitting" the SYN-ACK with a timeout of about > 200ms. This causes spurious retransmission on practically all tcp > connection on a 2.5G network (I remember a paper from FTW showing this.= =2E.) >=20 > - windows O.S. (at least XP) is triggering the fast retransmit at the= > third ACK, not at the third DUPLICATE ack > check http://support.microsoft.com/?scid=3Dkb%3Ben-us%3B224829&x=3D11&y= =3D11 > if you don't believe it! Default value is 2 duplicate packets) >=20 > - large initial windows are commonly seems. 16kB of initial window ca= n > be easily observed in any network. I suspect this is related to TCP > Offloading Engines (TOE), that perform segmentation at the NIC, or the > use of jumbo ethernet frames (9kB) -- the OS sees a "MSS" of 16kB (or > 9kB), the initial windows is 1 segment =3D> 10 (6) packets of 1500B eac= h > are then generated by the TOE. See RFC2525; some of these may be candidates for 2525-bis. Joe --------------enig903E18CD137E341D71B8CAD3 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) iEYEARECAAYFAktp/8kACgkQE5f5cImnZrv7hQCgm8by4MBCEr+kP14OGCxqPwma IKkAoKNea6/FTUFWijZNNV7e1G3EGEkt =6uoq -----END PGP SIGNATURE----- --------------enig903E18CD137E341D71B8CAD3-- From hkchu@google.com Wed Feb 3 15:05: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 7DE4D3A69AB for ; Wed, 3 Feb 2010 15:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, 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 8HyAUTnUMlHD for ; Wed, 3 Feb 2010 15:05:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2ED443A6996 for ; Wed, 3 Feb 2010 15:05:12 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o13N5tpC020273 for ; Wed, 3 Feb 2010 15:05:55 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265238355; bh=rsjm3JTzeYeVP5MEuX9CpfxcyBI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=egl8yht+H7pQikYXj/Bhso+57N1Qf4I0xU3Xag3HJi8UiK8hTHP4z4Duk/bDrd0JX M9BDuJLqtr+tITeLnv10A== 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:x-system-of-record; b=utV96iPxwrZUrYAE/vzNR3ZJKKv52c6q5Yxb0mTeGrlY9VdVO+oIMTNJEbI6s9vff 5sXF6nvP9p2SIdPjiS3YQ== Received: from pxi34 (pxi34.prod.google.com [10.243.27.34]) by wpaz9.hot.corp.google.com with ESMTP id o13N5RIa029628 for ; Wed, 3 Feb 2010 15:05:54 -0800 Received: by pxi34 with SMTP id 34so584753pxi.8 for ; Wed, 03 Feb 2010 15:05:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.15.21 with SMTP id s21mr176979rvi.218.1265238353210; Wed, 03 Feb 2010 15:05:53 -0800 (PST) In-Reply-To: <4B69F7BC.3000204@isi.edu> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <4B69F7BC.3000204@isi.edu> Date: Wed, 3 Feb 2010 15:05:53 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: nanditad@google.com, tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 23:05:13 -0000 +nandita On Wed, Feb 3, 2010 at 2:25 PM, Joe Touch wrote: > > > Jerry Chu wrote: > .... >>>> Actually our data points to the contrary - the average web object and page >>>> size have been rising steadily. E.g., the majority of our search responses >>>> no longer fit in 3 MSS these days. >>> >>> This should be relevant only for the first response from a given IP >>> address; persistent connections should render this moot for subsequent >>> requests. >> >> Yes we are well aware of the advantage of maintaining persistent connections. >> In fact this is one of the reasons holding us back from resurrecting T/TCP >> (in addition to other security issues). >> >> But from our own observation the average HTTP connections just don't >> persistent that long for some reason. I don't remember the data or all >> the technical reasons on top of my head, but can surely try to get them for >> you. > > I think having all of that in one place would be a good start. > >> There are other limitations of HTTP 1/1: > > Persistent connections predates 1.1, FWIW ;-) > >> 1. obviously its effectiveness depends on user's web surfing pattern. >> 2. web browsers have been going down the slope of opening more and >> more simultaneous connections anyway, partly to circumvent HTTP's >> serialization, an issue SPDY tries to address. >> 3. practically web servers have only limited resources. can't hold too many >> open connections. >> 4. a web object will make the TCP slow start algorithm to grow its cwnd >> only upto the size of the object. As such, even with persistent connections, >> a web object that is larger than any of its predecessors will hit the window >> limit, and take more than one round trip time to complete. So persistent >> connections might not be as effective as one might think. > > This all depends on many things - e.g., whether the persistent > connection is used for a sequence of requests or whether they are > interleaved using HTTP 'chunks', the size of the chunks, etc. > > It's useful as well to keep in mind that HTTP exists because Tim > Berners-Lee thought that FTP would be too inefficient, because 'most of > the time you only get one file from a site', and he didn't want to open > two connections. I.e., one other alternative is to consider FTP's > version of multiplexing as well. > >>> Again, the question arises as to how much this is going to achieve a >>> noticeable impact. >> >> Quite significant in our study. Will present our result at IETF/Anaheim. > > We've seen initial work on this before, and had a number of questions > that remain unanswered. A good start would be to put this all in a tech > report. Presentations at the IETF should not get into deep technical > detail; they ought to summarize work available before the meeting and > provided on the list IMO. I'm 100% with you on this, and have been working hard on a detailed report on our experiments done so far to be published in the next few weeks. Jerry > > Joe > > From touch@ISI.EDU Wed Feb 3 15:11: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 3C40A3A6996 for ; Wed, 3 Feb 2010 15:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 MHXIzcHLtQHn for ; Wed, 3 Feb 2010 15:11:19 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 5720B3A6916 for ; Wed, 3 Feb 2010 15:11:19 -0800 (PST) Received: from [70.213.251.114] (114.sub-70-213-251.myvzw.com [70.213.251.114]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13NASvQ023746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 15:10:30 -0800 (PST) Message-ID: <4B6A0264.1050700@isi.edu> Date: Wed, 03 Feb 2010 15:10:28 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jerry Chu References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <4B69F7BC.3000204@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2B3A7D532326776EF9745D86" X-MailScanner-ID: o13NASvQ023746 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: nanditad@google.com, tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 23:11:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2B3A7D532326776EF9745D86 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jerry Chu wrote: =2E.. >> We've seen initial work on this before, and had a number of questions >> that remain unanswered. A good start would be to put this all in a tec= h >> report. Presentations at the IETF should not get into deep technical >> detail; they ought to summarize work available before the meeting and >> provided on the list IMO. >=20 > I'm 100% with you on this, and have been working hard on a detailed rep= ort > on our experiments done so far to be published in the next few weeks. It would be very useful if that work could be available in advance of the IETF, e.g., by the 00 cutoff date (to give us time to take a look at it). It would also be useful, IMO, if the presentation summarized that work, and expected those present to be familiar with it, rather than going through it in detail, FWIW... Joe --------------enig2B3A7D532326776EF9745D86 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) iEYEARECAAYFAktqAmQACgkQE5f5cImnZrsibgCgjqKkiStf4ZuZm7yJjDsYEptm HM0AnRj6ijBabdMYhH4TbcWmuyDx0I6Y =YBSj -----END PGP SIGNATURE----- --------------enig2B3A7D532326776EF9745D86-- From hkchu@google.com Wed Feb 3 15:48:08 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 C313D28C0CF for ; Wed, 3 Feb 2010 15:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.341 X-Spam-Level: X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, 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 WJaoi1lT92X0 for ; Wed, 3 Feb 2010 15:48:08 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BD60228B23E for ; Wed, 3 Feb 2010 15:48:07 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o13Nmouj006139 for ; Wed, 3 Feb 2010 15:48:50 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265240931; bh=g7cADu/2kP9qyyYI5lcmxB1ySHY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ukgvydggCN7A9ET8azB+YtkER3LLclnjAXDz1ZqGpGxZgYk6+it4BKeTdQbfWBXt2 SwQgMVaVp45eG3aYPogDQ== 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:x-system-of-record; b=WIbD5LcsQ2pWd+w9vslobsahN1u6OJV5EzqlqGFILwIioOztfX8Q9Ur5z/spCjRbO hR6dhaP/JwFz50l6psgfw== Received: from pzk4 (pzk4.prod.google.com [10.243.19.132]) by wpaz17.hot.corp.google.com with ESMTP id o13NmnL3003796 for ; Wed, 3 Feb 2010 15:48:50 -0800 Received: by pzk4 with SMTP id 4so2103724pzk.28 for ; Wed, 03 Feb 2010 15:48:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.23.20 with SMTP id a20mr215673rvj.193.1265240929158; Wed, 03 Feb 2010 15:48:49 -0800 (PST) In-Reply-To: <4B6A0264.1050700@isi.edu> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <4B69F7BC.3000204@isi.edu> <4B6A0264.1050700@isi.edu> Date: Wed, 3 Feb 2010 15:48:49 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: nanditad@google.com, tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 03 Feb 2010 23:48:08 -0000 On Wed, Feb 3, 2010 at 3:10 PM, Joe Touch wrote: > > > Jerry Chu wrote: > ... >>> We've seen initial work on this before, and had a number of questions >>> that remain unanswered. A good start would be to put this all in a tech >>> report. Presentations at the IETF should not get into deep technical >>> detail; they ought to summarize work available before the meeting and >>> provided on the list IMO. >> >> I'm 100% with you on this, and have been working hard on a detailed report >> on our experiments done so far to be published in the next few weeks. > > It would be very useful if that work could be available in advance of > the IETF, e.g., by the 00 cutoff date (to give us time to take a look at > it). Yes that's our target date (3/1) for both the I-D and the paper detailing our experimental results. We've been working hard on this for the past 6+ months, with a focus on studying the negative impact, which has been a challenge both due to its small scale, and the limitation imposed by passive measurements. > > It would also be useful, IMO, if the presentation summarized that work, > and expected those present to be familiar with it, rather than going > through it in detail, FWIW... Ok, Jerry > > Joe > > From perfgeek@mac.com Wed Feb 3 19:42:56 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 C1A903A6B27 for ; Wed, 3 Feb 2010 19:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOZGHLJs28ds for ; Wed, 3 Feb 2010 19:42:55 -0800 (PST) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by core3.amsl.com (Postfix) with ESMTP id EA3C83A6A4F for ; Wed, 3 Feb 2010 19:42:55 -0800 (PST) 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 <0KXA0094GT0RG470@asmtp017.mac.com> for tcpm@ietf.org; Wed, 03 Feb 2010 19:43:40 -0800 (PST) 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=5.0.0-0908210000 definitions=main-1002030243 Message-id: From: rick jones To: Joe Touch In-reply-to: <4B69CDD7.6060802@isi.edu> Date: Wed, 03 Feb 2010 19:43:39 -0800 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 03:42:56 -0000 On Feb 3, 2010, at 11:26 AM, Joe Touch wrote: > > > Jerry Chu wrote: >> On Wed, Feb 3, 2010 at 7:17 AM, SCHARF, Michael >> wrote: >>>> This topic seems to be gaining momentum, and the WG should >>>> take some time considering if there is work here for it. >>> IMHO there could indeed be room for increasing the initial window. >>> If >>> most data transfers continue to be smaller than 3 MSS, a larger >>> initial >>> window would not necessarily cause harm, as it is seldomly used. >>> Still, >>> this would speed up those data transfers that currently suffer from >>> Slow-Start. >> >> Actually our data points to the contrary - the average web object >> and page >> size have been rising steadily. E.g., the majority of our search >> responses >> no longer fit in 3 MSS these days. > > This should be relevant only for the first response from a given IP > address; persistent connections should render this moot for subsequent > requests. Modulo slow-start after idle. Such as what one might experience between viewing the Nth and N+1st search result page. rick jones From touch@ISI.EDU Wed Feb 3 19:49: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 142373A6842 for ; Wed, 3 Feb 2010 19:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd7dJq12-+Vp for ; Wed, 3 Feb 2010 19:49:52 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 4A4A43A6809 for ; Wed, 3 Feb 2010 19:49:52 -0800 (PST) Received: from [128.9.176.36] (c1-vpn6.isi.edu [128.9.176.36]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o143nbvo018977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 19:49:38 -0800 (PST) Message-ID: <4B6A43D1.2010706@isi.edu> Date: Wed, 03 Feb 2010 19:49:37 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: rick jones References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5D9F54B8314734CF1086262F" X-MailScanner-ID: o143nbvo018977 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 03:49:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D9F54B8314734CF1086262F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable rick jones wrote: >=20 > On Feb 3, 2010, at 11:26 AM, Joe Touch wrote: >=20 >> >> >> Jerry Chu wrote: >>> On Wed, Feb 3, 2010 at 7:17 AM, SCHARF, Michael >>> wrote: >>>>> This topic seems to be gaining momentum, and the WG should >>>>> take some time considering if there is work here for it. >>>> IMHO there could indeed be room for increasing the initial window. I= f >>>> most data transfers continue to be smaller than 3 MSS, a larger init= ial >>>> window would not necessarily cause harm, as it is seldomly used. Sti= ll, >>>> this would speed up those data transfers that currently suffer from >>>> Slow-Start. >>> >>> Actually our data points to the contrary - the average web object and= >>> page >>> size have been rising steadily. E.g., the majority of our search >>> responses >>> no longer fit in 3 MSS these days. >> >> This should be relevant only for the first response from a given IP >> address; persistent connections should render this moot for subsequent= >> requests. >=20 > Modulo slow-start after idle.=20 I've already cited the work that explains that this doesn't actually happen on web exchanges exactly because the client request is small (doesn't matter that its side was idle), and the client request causes the server to think it wasn't idle either. That's in the ToN paper I cite= d. Yes, if/when that's fixed, it'll be an issue. Not right now, though. Joe --------------enig5D9F54B8314734CF1086262F 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) iEYEARECAAYFAktqQ9EACgkQE5f5cImnZruiewCdH+MPCeedjw6N9lvCmTz8kCqW xPQAnR0wsrsyldi6I+QcV5eFm5w+UZ0X =gicA -----END PGP SIGNATURE----- --------------enig5D9F54B8314734CF1086262F-- From mike@belshe.com Wed Feb 3 20:34: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 E9C6A3A69F4 for ; Wed, 3 Feb 2010 20:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 BpX9LBpPrA-2 for ; Wed, 3 Feb 2010 20:34:34 -0800 (PST) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id 389EC3A69EE for ; Wed, 3 Feb 2010 20:34:34 -0800 (PST) Received: by pzk5 with SMTP id 5so3386047pzk.29 for ; Wed, 03 Feb 2010 20:35:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.60.14 with SMTP id i14mr375338wfa.261.1265258114344; Wed, 03 Feb 2010 20:35:14 -0800 (PST) In-Reply-To: <4B69FF69.8040008@isi.edu> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com> <4B69FF69.8040008@isi.edu> Date: Wed, 3 Feb 2010 20:35:14 -0800 Message-ID: <2a10ed241002032035j53029266wb6d3ecf22148d2bf@mail.gmail.com> From: Mike Belshe To: Joe Touch Content-Type: multipart/alternative; boundary=00504502bcc574678b047ebedcbe Cc: tcpm@ietf.org, "Biswas, Anumita" Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 05:12:41 -0000 --00504502bcc574678b047ebedcbe Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 3, 2010 at 2:57 PM, Joe Touch wrote: > > > Jerry Chu wrote: > > Hi Anumita, > > > > On Wed, Feb 3, 2010 at 1:50 PM, Biswas, Anumita > > wrote: > >> > >>> -----Original Message----- > >>> From: John Heffner [mailto:johnwheffner@gmail.com] > >>> Sent: Wednesday, February 03, 2010 12:51 PM > >>> To: Jerry Chu > >>> Cc: tcpm@ietf.org WG > >>> Subject: Re: [tcpm] TCP tuning > >>> > >>> On Wed, Feb 3, 2010 at 3:44 PM, Jerry Chu wrote: > >>>> Hi John, > >>>> > >>>> On Wed, Feb 3, 2010 at 12:32 PM, John Heffner > >>> wrote: > >>>>> A couple thoughts: > >>>>> - A large initial window should probably only be used by mutual > >>>>> agreement. Maybe via a TCP option during the handshake? > >>>> This may not be needed. A receiver can effectively constrain the > >>>> sender's window by advertising a smaller initial receive window. > >>>> > >>>> Obviously this works for only the initial window, not the restart > >>> window. > >>>> (Oh, on a second thought this can be made to work for the restart > >>>> window too.) > >>> A good point, though most receivers (Linux 2.4 and later being the > >>> exception) advertise all available window space, not expecting a large > >>> initial burst from the sender. I think you need a negotiation for > >>> opt-in rather than opt-out. > >> The slow start algorithm tries to probe the network capacity, not the > end node's available window space. The network capacity is dependent on > switch/router queue lengths, among other things and therefore the initial > receive window is not something that can/should be negotiated by end points. > >> > >> However, I do have reservations with standardizing an increased > >> initial window assuming that 10 MSS is a good "guess" for what the > >> network can tolerate > >> > >> I have seen cases where switches topple over initial receive window > >> sizes as spec'd out by RFC 3390. In fact, RFC 3390 does state that the > >> recommended IW value of 4 segments for 1500MSS can cause more loss in > >> networks with higher segment drop rates. > > > > Understood the concern. But sometimes we'll need to take active > > action in order to break the deadlock - TCP spec relying on > > switch/router upgrade while equipment vendors waiting for TCP spec to > > be ratified. > > Let's please be clear that: > > 1) there is NO *urgent* problem > We're talking about an optimization. If we do > nothing, standards-compliant implementations > will continue to work fine. > 2) the benefit and impact need to be considered together, for everyone > I doubt any logic that assumes both: > a) we NEED to make a change for some > AND > b) this will HURT some others > The hypothesis is that init-cwnd was effectively raised long ago by applications (ahem - HTTP) leveraging multiple connections. I'm interested to hear what others think of the hypothesis and how we can prove it to be either true or false. Assuming the hypothesis is true, it doesn't remove the possibility of (2b) above, but it morphs it in interesting ways: a) The same discussions about increasing initial-cwnd have been around for years. So far, TCP changed little, and instead, applications have adapted. Like it or not, the same thing will likely happen as we move forward as long as there are latency benefits to be had. I know that doesn't sound good - I'm just thinking pragmatically. :-) b) Making changes to initial cwnd today will have a multiplicative effect in current software. I can demonstrate that in some cases, initial cwnd is already 40+ because HTTP is using so many connections. So increasing the official initcwnd from 3 to 10 is effectively increasing cwnd to 100+ in some cases. c) It would be sad if, because HTTP worked around this problem by abusing TCP, that new low-latency protocols would have no choice but to replicate current broken behavior to be competitive. Finally, if there is data needed which chromium can assist with gathering, I volunteer to help make it happen. Mike > > TCP is designed to *always* work (as much as possible). It's more > conservative than it needs to be most of the time. Some implementors > take advantage of that, and the tragedy of the commons, and get away > with things that the IETF may not want to endorse for widespread use. > > We really need to see the details to move on. Keep in mind as well that > if you're modifying TCP, taking the time to document your proposal (no, > an extended set of slides is not documentation) is a good indication of > your overall diligence (and vice versa). > > Joe > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --00504502bcc574678b047ebedcbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 3, 2010 at 2:57 PM, Joe Touch <touch@is= i.edu> wrote:


Jerry Chu wrote:
> Hi Anumita,
>
> On Wed, Feb 3, 2010 at 1:50 PM, Biswas, Anumita
> <Anu= mita.Biswas@netapp.com> wrote:
>>
>>> -----Original Message-----
>>> From: John Heffner [mailto:johnwheffner@gmail.com]
>>> Sent: Wednesday, February 03, 2010 12:51 PM
>>> To: Jerry Chu
>>> Cc: tcpm@ie= tf.org WG
>>> Subject: Re: [tcpm] TCP tuning
>>>
>>> On Wed, Feb 3, 2010 at 3:44 PM, Jerry Chu <hkchu@google.com> wrote:
>>>> Hi John,
>>>>
>>>> On Wed, Feb 3, 2010 at 12:32 PM, John Heffner
>>> <johnwheffner@gmail.com> wrote:
>>>>> A couple thoughts:
>>>>> - A large initial window should probably only be used = by mutual
>>>>> agreement. =A0Maybe via a TCP option during the handsh= ake?
>>>> This may not be needed. A receiver can effectively constra= in the
>>>> sender's window by advertising a smaller initial recei= ve window.
>>>>
>>>> Obviously this works for only the initial window, not the = restart
>>> window.
>>>> (Oh, on a second thought this can be made to work for the = restart
>>>> window too.)
>>> A good point, though most receivers (Linux 2.4 and later being= the
>>> exception) advertise all available window space, not expecting= a large
>>> initial burst from the sender. =A0I think you need a negotiati= on for
>>> opt-in rather than opt-out.
>> The slow start algorithm tries to probe the network capacity, not = the end node's available window space. The network capacity is dependen= t on switch/router queue lengths, among other things and therefore the init= ial receive window is not something that can/should be negotiated by end po= ints.
>>
>> However, I do have reservations with standardizing an increased >> initial window assuming that 10 MSS is a good "guess" fo= r what the
>> network can tolerate
>>
>> I have seen cases where switches topple over initial receive windo= w
>> sizes as spec'd out by RFC 3390. In fact, RFC 3390 does state = that the
>> recommended IW value of 4 segments for 1500MSS can cause more loss= in
>> networks with higher segment drop rates.
>
> Understood the concern. But sometimes we'll need to take active > action in order to break the deadlock - TCP spec relying on
> switch/router upgrade while equipment vendors waiting for TCP spec to<= br> > be ratified.

Let's please be clear that:

1) there is NO *urgent* problem
=A0 =A0 =A0 =A0We're talking about an optimization. If we do
=A0 =A0 =A0 =A0nothing, standards-compliant implementations
=A0 =A0 =A0 =A0will continue to work fine.

2) the benefit and impact need to be considered together, for everyone
=A0 =A0 =A0 =A0I doubt any logic that assumes both:
=A0 =A0 =A0 =A0a) we NEED to make a change for some
=A0 =A0 =A0 =A0AND
=A0 =A0 =A0 =A0b) this will HURT some others

The hypothesis is that init-cwnd was effectively raised long ago by = applications (ahem - HTTP) leveraging multiple connections. =A0I'm inte= rested to hear what others think of the hypothesis and how we can prove it = to be either true or false.

Assuming the hypothesis is true, it doesn't remove = the possibility of (2b) above, but it morphs it in interesting ways:
<= div>=A0=A0 =A0a) The same discussions about increasing initial-cwnd have be= en around for years. =A0So far, TCP changed little, and instead, applicatio= ns have adapted. =A0Like it or not, the same thing will likely happen as we= move forward as long as there are latency benefits to be had. =A0I know th= at doesn't sound good - I'm just thinking pragmatically. :-)

=A0=A0 =A0b) Making changes to initial cwnd today will = have a multiplicative effect in current software. =A0I can demonstrate that= in some cases, initial cwnd is already 40+ because HTTP is using so many c= onnections. =A0So increasing the official initcwnd from 3 to 10 is effectiv= ely increasing cwnd to 100+ in some cases.

=A0=A0 =A0c) It would be sad if, because HTTP worked ar= ound this problem by abusing TCP, that new low-latency protocols would have= no choice but to replicate current broken behavior to be=A0competitive.

Finally, if there is data needed which chromium can assist w= ith gathering, I volunteer to help make it happen.

Mike


=A0

TCP is designed to *always* work (as much as possible). It's more
conservative than it needs to be most of the time. Some implementors
take advantage of that, and the tragedy of the commons, and get away
with things that the IETF may not want to endorse for widespread use.

We really need to see the details to move on. Keep in mind as well that
if you're modifying TCP, taking the time to document your proposal (no,=
an extended set of slides is not documentation) is a good indication of
your overall diligence (and vice versa).

Joe


_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm


--00504502bcc574678b047ebedcbe-- From perfgeek@mac.com Wed Feb 3 21:40: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 896A33A680A for ; Wed, 3 Feb 2010 21:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTuwMgfBWR-j for ; Wed, 3 Feb 2010 21:40:47 -0800 (PST) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by core3.amsl.com (Postfix) with ESMTP id 759C73A67F2 for ; Wed, 3 Feb 2010 21:40:47 -0800 (PST) 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 asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXA00A60YH56630@asmtp011.mac.com> for tcpm@ietf.org; Wed, 03 Feb 2010 21:41:30 -0800 (PST) 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=5.0.0-0908210000 definitions=main-1002030266 Message-id: <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com> From: rick jones To: Joe Touch In-reply-to: <4B6A43D1.2010706@isi.edu> Date: Wed, 03 Feb 2010 21:41:28 -0800 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <4B6A43D1.2010706@isi.edu> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 05:40:48 -0000 On Feb 3, 2010, at 7:49 PM, Joe Touch wrote: > rick jones wrote: >> Modulo slow-start after idle. > > I've already cited the work that explains that this doesn't actually > happen on web exchanges exactly because the client request is small > (doesn't matter that its side was idle), and the client request causes > the server to think it wasn't idle either. That's in the ToN paper I > cited. > > Yes, if/when that's fixed, it'll be an issue. Not right now, though. I'd not looked far ahead enough in my unread mail queue when I sent my message. Still... I have run some netperf TCP_RR tests between my home system: Darwin rick-2 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 and netperf.org: Linux www.netperf.org 2.6.31-15-server #50-Ubuntu SMP Tue Nov 10 15:50:36 UTC 2009 x86_64 GNU/Linux To avoid any issues with TSO clouding the trace, I disabled TSO and GSO on netperf.org. On my home system I did ./configure --enable-intervals then built netperf, and then while running tcpdump on netperf.org executed: src/netperf -l 300 -p 12345 -t TCP_RR -H netperf.org -b 1 -w 1s -- -r 128,16384 -P 23456 TCP REQUEST/RESPONSE TEST from (null) (0.0.0.0) port 23456 AF_INET to netperf.org (192.6.38.59) port 23456 AF_INET : interval Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 131070 262140 128 16384 300.00 1.00 16384 87380 Netperf will send a 128 byte request to netperf.org, which will respond immediately. Netperf then waits one second before sending the next request etc etc... The raw and "cooked" traces from that can be seen at: ftp://ftp.netperf.org/traces There one can also see "nothinktime" raw and cooked traces for: [rick-2:~/netperf2_work] perfgeek% src/netperf -l 30 -p 12345 -t TCP_RR -H netperf.org -- -r 128,16384 -P 23456 TCP REQUEST/RESPONSE TEST from (null) (0.0.0.0) port 23456 AF_INET to netperf.org (192.6.38.59) port 23456 AF_INET : interval tcpLocal /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 131070 262140 128 16384 30.00 7.60 16384 87380 It certainly appears that *something* is holding-back the server in the "thinktime" case - I don't know if it is slowstart after idle, but it is something that does not appear to be holding-back the server in the "nothinktime" case. Hmm... while writing this message, I have remembered there is a sysctl in linux to control slow-start after idle, so there is also a third trace, one with thinktime, and net.ipv4.tcp_slow_start_after_idle = 0. From the look of that trace, and how it compares with the other two, I think that Linux 2.6.31 at least is not actually having the arriving request cause it to think it wasn't idle? happy benchmarking, rick jones PS - I suppose if I'd been thinking more clearly, I'd have also included --enable-historgram in the ./configure command and been able to give a histogram of the response times (adding a -v 2 option to the global command line options), but I suppose that can be guesstimated from the traces. http://homepage.mac.com/perfgeek From perfgeek@mac.com Wed Feb 3 22:08: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 5386B3A6C76 for ; Wed, 3 Feb 2010 22:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CeGwIMoCVgw for ; Wed, 3 Feb 2010 22:08:17 -0800 (PST) Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by core3.amsl.com (Postfix) with ESMTP id EF3C33A63C9 for ; Wed, 3 Feb 2010 22:08:16 -0800 (PST) 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 asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXA00BK9ZR1T140@asmtp013.mac.com> for tcpm@ietf.org; Wed, 03 Feb 2010 22:09:02 -0800 (PST) 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=5.0.0-0908210000 definitions=main-1002030272 Message-id: <443C71B6-1D1A-49CA-B5E4-FB81FDCB7FD1@mac.com> From: rick jones To: rick jones In-reply-to: <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com> Date: Wed, 03 Feb 2010 22:09:00 -0800 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <4B6A43D1.2010706@isi.edu> <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, "SCHARF, Michael" , Joe Touch Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 06:08:18 -0000 On Feb 3, 2010, at 9:41 PM, rick jones wrote: > PS - I suppose if I'd been thinking more clearly, I'd have also > included --enable-historgram in the ./configure command and been > able to give a histogram of the response times (adding a -v 2 option > to the global command line options), but I suppose that can be > guesstimated from the traces. Ok, so perhaps I like running netperf too much :) Here then are the application-level measured response times. The first netperf is with tcp_slow_start_after_idle = 0, the second with it set to 1, I'll leave- out the rest of the netperf output as it is repetitive: tcp_slow_start_after_idle = 0 on server: Histogram of request/response times UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 HUNDRED_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 UNIT_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 TEN_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 HUNDRED_MSEC : 0: 294: 4: 0: 2: 0: 0: 0: 0: 0 UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 >100_SECS: 0 HIST_TOTAL: 300 That means 294 times 100ms <= responsetime < 200ms, 4 times it was 200ms <= responsetime < 300ms etc etc. tcp_slow_start_after_idle = 1 on server: UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 HUNDRED_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 UNIT_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 TEN_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 HUNDRED_MSEC : 0: 0: 0: 290: 10: 0: 0: 0: 0: 0 UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 >100_SECS: 0 HIST_TOTAL: 300 Now it was 290 with 300ms <= responsetime < 400ms Just as a refresher, the request size was 128 bytes, the response size 16384. The ICMP Echo RTT is ~120 ms between my home system and netperf.org: --- netperf.org ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 119.523/120.410/121.248/0.493 ms rick jones Wisdom teeth are impacted, people are affected by the effects of events From touch@ISI.EDU Wed Feb 3 22:26: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 E647A3A6CC3 for ; Wed, 3 Feb 2010 22:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeE91Zm8f-ym for ; Wed, 3 Feb 2010 22:26:37 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 770B43A6CEE for ; Wed, 3 Feb 2010 22:26:09 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o146PCkx009197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 22:25:14 -0800 (PST) Message-ID: <4B6A6848.80904@isi.edu> Date: Wed, 03 Feb 2010 22:25:12 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: rick jones References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <4B6A43D1.2010706@isi.edu> <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com> <443C71B6-1D1A-49CA-B5E4-FB81FDCB7FD1@mac.com> In-Reply-To: <443C71B6-1D1A-49CA-B5E4-FB81FDCB7FD1@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig59DF3D46F3004B033ED9D85A" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 06:26:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig59DF3D46F3004B033ED9D85A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Did you use a netperf option to disable Nagle? There are also many reasons this could happen; it might be easier to see in a plot. Joe rick jones wrote: >=20 > On Feb 3, 2010, at 9:41 PM, rick jones wrote: >> PS - I suppose if I'd been thinking more clearly, I'd have also >> included --enable-historgram in the ./configure command and been able >> to give a histogram of the response times (adding a -v 2 option to the= >> global command line options), but I suppose that can be guesstimated >> from the traces. >=20 > Ok, so perhaps I like running netperf too much :) Here then are the > application-level measured response times. The first netperf is with > tcp_slow_start_after_idle =3D 0, the second with it set to 1, I'll > leave-out the rest of the netperf output as it is repetitive: >=20 > tcp_slow_start_after_idle =3D 0 on server: >=20 > Histogram of request/response times > UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > HUNDRED_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > UNIT_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > TEN_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > HUNDRED_MSEC : 0: 294: 4: 0: 2: 0: 0: 0: 0: = 0 > UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 >>100_SECS: 0 > HIST_TOTAL: 300 >=20 > That means 294 times 100ms <=3D responsetime < 200ms, 4 times it was 20= 0ms > <=3D responsetime < 300ms etc etc. >=20 > tcp_slow_start_after_idle =3D 1 on server: >=20 > UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > HUNDRED_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > UNIT_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > TEN_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > HUNDRED_MSEC : 0: 0: 0: 290: 10: 0: 0: 0: 0: = 0 > UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 > TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: = 0 >>100_SECS: 0 > HIST_TOTAL: 300 >=20 > Now it was 290 with 300ms <=3D responsetime < 400ms >=20 > Just as a refresher, the request size was 128 bytes, the response size > 16384. >=20 > The ICMP Echo RTT is ~120 ms between my home system and netperf.org: >=20 > --- netperf.org ping statistics --- > 10 packets transmitted, 10 packets received, 0% packet loss > round-trip min/avg/max/stddev =3D 119.523/120.410/121.248/0.493 ms >=20 > rick jones > Wisdom teeth are impacted, people are affected by the effects of events= --------------enig59DF3D46F3004B033ED9D85A 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) iEYEARECAAYFAktqaEgACgkQE5f5cImnZru0jQCfdu2efWQ1qjX6VVSldh0yklG4 VwwAnjoKiJApIiopA5PUvgKWKkrEnp50 =DzPV -----END PGP SIGNATURE----- --------------enig59DF3D46F3004B033ED9D85A-- From alexander.zimmermann@nets.rwth-aachen.de Thu Feb 4 00:08:03 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 2B2323A6D30 for ; Thu, 4 Feb 2010 00:08:03 -0800 (PST) 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 Ru9g24sRd84F for ; Thu, 4 Feb 2010 00:08:01 -0800 (PST) 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 B35473A6D2E for ; Thu, 4 Feb 2010 00:08:01 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) 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 <0KXB00KEE5ALDOF0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 04 Feb 2010 09:08:45 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,403,1262559600"; d="scan'208";a="23504053" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Thu, 04 Feb 2010 09:08:45 +0100 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 <0KXB006475AK7150@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 04 Feb 2010 09:08:45 +0100 (CET) From: Alexander Zimmermann In-reply-to: <1e41a3231002031411u57a79ffas1fa77988e83343c0@mail.gmail.com> Date: Thu, 04 Feb 2010 09:08:45 +0100 Message-id: <278B912D-421D-4E25-AC37-5D39C9A37A02@nets.rwth-aachen.de> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <1e41a3231002031411u57a79ffas1fa77988e83343c0@mail.gmail.com> To: John Heffner X-Mailer: Apple Mail (2.1077) Cc: "tcpm@ietf.org" , Murali Bashyam Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 08:08:03 -0000 The motivation for this is RFC 2861: TCP Congestion Window Validation Alex Am 03.02.2010 um 23:11 schrieb John Heffner: > On Wed, Feb 3, 2010 at 5:03 PM, Murali Bashyam > wrote: >> Any idle period higher than the RTT between HTTP requests tends to reset the cwindow down to the restart window. This hurts persistent connections too. What's the motivation for this, can we have a different slope while reducing the window instead of resetting all the way down? > > > This is because you lose the ack clock. Otherwise, when resuming > sending you'll send a line-rate burst of the full BDP, which will > often overflow queues and cause loss and/or large delay spikes. There > is currently no pacing mechanism in TCP to smooth out such bursts. > > -John > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From kacheong.poon@sun.com Thu Feb 4 02:08: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 02F8A3A6D4A for ; Thu, 4 Feb 2010 02:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 1g0pwiBX6uNk for ; Thu, 4 Feb 2010 02:08:15 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 4472B3A6D49 for ; Thu, 4 Feb 2010 02:08:15 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o14A90bJ012732 for ; Thu, 4 Feb 2010 10:09:00 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o14A8wcA341599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Feb 2010 02:09:00 -0800 (PST) Message-ID: <4B6A9CB9.5040603@sun.com> Date: Thu, 04 Feb 2010 18:08:57 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100115 Thunderbird/3.0.1 MIME-Version: 1.0 To: tcpm@ietf.org References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 10:08:16 -0000 On 02/ 4/10 06:03 AM, Murali Bashyam wrote: > Any idle period higher than the RTT between HTTP requests tends to reset the cwindow down to the restart window. This hurts persistent connections too. What's the motivation for this, can we have a different slope while reducing the window instead of resetting all the way down? I believe the restart cwnd is the same as the initial cwnd in most stacks. So are you suggesting that the initial cwnd is not large enough in the restart case? -- K. Poon. kacheong.poon@sun.com From kacheong.poon@sun.com Thu Feb 4 03:37:20 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 7151828C0EF for ; Thu, 4 Feb 2010 03:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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+rPnCggMHEr for ; Thu, 4 Feb 2010 03:37:19 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 8D10728C126 for ; Thu, 4 Feb 2010 03:37:19 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o14Bc4q0023185 for ; Thu, 4 Feb 2010 11:38:04 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o14Bc2lh373456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Feb 2010 03:38:04 -0800 (PST) Message-ID: <4B6AB199.2020701@sun.com> Date: Thu, 04 Feb 2010 19:38:01 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100115 Thunderbird/3.0.1 MIME-Version: 1.0 To: tcpm@ietf.org References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> <316A6EC9-03FF-4A11-9E1E-084220A8146A@ifi.uio.no> In-Reply-To: <316A6EC9-03FF-4A11-9E1E-084220A8146A@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 11:37:20 -0000 On 02/ 4/10 06:10 AM, Michael Welzl wrote: > Without trying to get into a debate on engineering vs. research, I would > say that the research community's perception of TCP research is that, > indeed, such a change is a valid research question. That's not because > of a need to find the "best, elegant, risk free solution", but because > of the need to make sure that it's a solution that's safe to deploy. > > This is indeed at odds with needs for timeliness - but your need for > that can't be the basis for lowering the bar about significant changes > to TCP in the IETF. Something interesting to "chit-chat" during coffee break... I think the history of the current RFC 3390 limit is like the following. Please correct me if I am wrong. The original limit was 1. But because of an implementation mistake in BSD, the reality was actually 2. And IETF accepted the reality. Then folks realized that during slow start, TCP almost always sent a burst of 3 segments because of delayed ACK. So people thought that around 4380 (3 * 1460 bytes which is a common segment size) was fine and came up with a formula as in RFC 3390. Just wondering, if there were no bug, would the initial cwnd be increased almost 10 years ago? Note that I am not trying to start a debate on history nor reality vs research ;-) -- K. Poon. kacheong.poon@sun.com From Michael.Scharf@alcatel-lucent.com Thu Feb 4 05:35: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 AECFA3A6915 for ; Thu, 4 Feb 2010 05:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 zXtbVVzmHgej for ; Thu, 4 Feb 2010 05:35:20 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 92E713A68DE for ; Thu, 4 Feb 2010 05:35:20 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id o14DZxiA017589; Thu, 4 Feb 2010 14:35:59 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Feb 2010 14:35:58 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C025F18D6@SLFSNX.rcs.alcatel-research.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP tuning Thread-Index: AcqlEzZAleF+AsF1QEmyfrio3z7P0AAhaotQ References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com><1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> From: "SCHARF, Michael" To: , "Jerry Chu" X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 13:35:21 -0000 Jerry, > > - A significant increase to the initial window might benefit from=20 > > introduction of some form of pacing, since you won't have any ack=20 > > clock yet. =A0This might help reduce losses and delay jitter. >=20 > Agreed. The question is, what is that threshold of=20 > window/burst size beyond which pacing is required. My current=20 > guess is > 10. I have the same impression, at least from what I have seen in = simulations. Yet, one could think of a very simple form of pacing with a single timer = that changes the Slow-Start only when it "hurts" - I think that I have = mentioned this possibility on this list before: In this approach, the initial window remains at the value given by RFC = 3390. But the sender is allowed to further increase the window after a = certain time (say, 100ms), but only=20 if the RTT is known to be larger than 100ms (as measured e. g. during = handshake), if no ACK has been received until then, and if recently = there have been no signs of congestion to this destination. The advantage of this approach is that TCP uses the larger initial = window only if the RTT is larger than 100ms (or whatever threshold is = defined). On the one hand, this reduces the performance problems that = can be observed for RTTs of the order of 200ms. But, on the other hand, = flows with a smaller RTT would use the existing Slow-Start, i. e., the = faster startup is only used by a small number of flows and thus be much = less disruptive than a general revision of RFC 3390. A simpler variant of this idea is to allow an increased initial window = beyond RFC 3390 if the measured RTT is larger than a certain threshold = such as 100ms. Michael From Michael.Scharf@alcatel-lucent.com Thu Feb 4 05:58: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 4D59F3A683A for ; Thu, 4 Feb 2010 05:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 KBTS1PhNVc-y for ; Thu, 4 Feb 2010 05:58:34 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 49A2C3A680E for ; Thu, 4 Feb 2010 05:58:34 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id o14DxEsq022297; Thu, 4 Feb 2010 14:59:14 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Feb 2010 14:59:13 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C025F18DB@SLFSNX.rcs.alcatel-research.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP tuning Thread-Index: AcqlBUv5EM/mMAFNQkW1dlL1MkDgcwAmobZQ References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> From: "SCHARF, Michael" To: , "Jerry Chu" X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 13:58:35 -0000 Jerry, > Actually our data points to the contrary - the average web=20 > object and page size have been rising steadily. E.g., the=20 > majority of our search responses no longer fit in 3 MSS these days. OK. I looked at some traffic traces from the year 2008, which might not be representative any more. > > In the past, I have played a little bit with an initial=20 > window e. g.=20 > > of 10 MSS, and that worked surprisingly well. >=20 > Good to know! >=20 > >Also, one could combine a > > larger initial window with other mechanisms that would reduce the =20 > >aggressiveness of the flow startup. Maybe it is indeed time=20 > to think =20 > >about the Slow-Start once again. >=20 > We are planning to submit an I-D on raising initcwnd to 10MSS before > 3/1 to be included in the upcoming IETF meeting. Please note that I used the value of 10 MSS just as an example. I'd actually expect that doubling the allowed initial window would be sufficient in order to solve most real-world Slow-Start performance issues. Michael From ayourtch@cisco.com Thu Feb 4 06:08: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 25A973A6DAD for ; Thu, 4 Feb 2010 06:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 I8kZd3biZFEF for ; Thu, 4 Feb 2010 06:08:26 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id B46F13A6915 for ; Thu, 4 Feb 2010 06:08:25 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o14E5FjC002595; Thu, 4 Feb 2010 15:05:15 +0100 (CET) Received: from dhcp-bru-peg2-vl25-144-254-8-234.cisco.com (dhcp-bru-peg2-vl25-144-254-8-234.cisco.com [144.254.8.234]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o14E5CRS021325; Thu, 4 Feb 2010 15:05:12 +0100 (CET) Date: Thu, 4 Feb 2010 15:05:12 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx.stdio.be To: "SCHARF, Michael" In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C025F18D6@SLFSNX.rcs.alcatel-research.de> Message-ID: References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com><1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <133D9897FB9C5E4E9DF2779DC91E947C025F18D6@SLFSNX.rcs.alcatel-research.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-568019070-1265292312=:4145" Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP tuning X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 14:08:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-568019070-1265292312=:4145 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 4 Feb 2010, SCHARF, Michael wrote: > Jerry, > >>> - A significant increase to the initial window might benefit from >>> introduction of some form of pacing, since you won't have any ack >>> clock yet.  This might help reduce losses and delay jitter. >> >> Agreed. The question is, what is that threshold of >> window/burst size beyond which pacing is required. My current >> guess is > 10. > > I have the same impression, at least from what I have seen in simulations. > > Yet, one could think of a very simple form of pacing with a single >timer that changes the Slow-Start only when it "hurts" - I think that I >have mentioned this possibility on this list before: > > In this approach, the initial window remains at the value given by RFC >3390. But the sender is allowed to further increase the window after a >certain time (say, 100ms), but only > if the RTT is known to be larger than 100ms (as measured e. g. during >handshake), if no ACK has been received until then, and if recently there >have been no signs of congestion to this destination. > > The advantage of this approach is that TCP uses the larger initial >window only if the RTT is larger than 100ms (or whatever threshold is >defined). On the one hand, this reduces the performance problems that can >be observed for RTTs of the order of 200ms. But, on the other hand, flows >with a smaller RTT would use the existing Slow-Start, i. e., the faster >startup is only used by a small number of flows and thus be much less >disruptive than a general revision of RFC 3390. > > A simpler variant of this idea is to allow an increased initial window >beyond RFC 3390 if the measured RTT is larger than a certain threshold >such as 100ms. And a possible tweak to this: if we increased the initial window beyond RFC3390, measure the number of retransmits that have to be done for those segments. If the stack had to retransmit, then subsequent connection attempts from the host would need to reduce this "increased" window. I think this could help to take care of the concern about the short queue limits on the access-layer equipment. cheers, andrew > > Michael > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --8323329-568019070-1265292312=:4145-- From touch@ISI.EDU Thu Feb 4 06:34:33 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 98ADD3A6DC8 for ; Thu, 4 Feb 2010 06:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 xx5w9WcCFstC for ; Thu, 4 Feb 2010 06:34:32 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A1D9B3A6836 for ; Thu, 4 Feb 2010 06:34:32 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o14EYQkK029985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2010 06:34:28 -0800 (PST) Message-ID: <4B6ADAF2.9000204@isi.edu> Date: Thu, 04 Feb 2010 06:34:26 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kacheong Poon References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <4B69B5AC.1090209@isi.edu> <316A6EC9-03FF-4A11-9E1E-084220A8146A@ifi.uio.no> <4B6AB199.2020701@sun.com> In-Reply-To: <4B6AB199.2020701@sun.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig725F60F3A3C679FFBFF798C7" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 14:34:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig725F60F3A3C679FFBFF798C7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kacheong Poon wrote: > On 02/ 4/10 06:10 AM, Michael Welzl wrote: >=20 >> Without trying to get into a debate on engineering vs. research, I wou= ld >> say that the research community's perception of TCP research is that, >> indeed, such a change is a valid research question. That's not because= >> of a need to find the "best, elegant, risk free solution", but because= >> of the need to make sure that it's a solution that's safe to deploy. >> >> This is indeed at odds with needs for timeliness - but your need for >> that can't be the basis for lowering the bar about significant changes= >> to TCP in the IETF. >=20 >=20 > Something interesting to "chit-chat" during coffee break... I > think the history of the current RFC 3390 limit is like the > following. Please correct me if I am wrong. >=20 > The original limit was 1. But because of an implementation mistake > in BSD, the reality was actually 2. And IETF accepted the reality. > Then folks realized that during slow start, TCP almost always sent > a burst of 3 segments because of delayed ACK. So people thought that > around 4380 (3 * 1460 bytes which is a common segment size) was fine > and came up with a formula as in RFC 3390. That, and a LOT of simulation analysis. The other alternative was to declare this a bug and recommend against it. > Just wondering, if there were no bug, would the initial cwnd be > increased almost 10 years ago? Note that I am not trying to start > a debate on history nor reality vs research ;-) It's hard to say whether there would have been motivation to look at the issue so deeply were it not for the bug, but ultimately it was the depth of analysis that convinced the group to approve the change. Joe --------------enig725F60F3A3C679FFBFF798C7 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) iEYEARECAAYFAktq2vMACgkQE5f5cImnZruxCACfSJNxu8VcdmnEQ4bVf09DdeKE CoMAn2f4u+s3WdzXT8C7w7BI/hHGdJmB =6g08 -----END PGP SIGNATURE----- --------------enig725F60F3A3C679FFBFF798C7-- From hkchu@google.com Thu Feb 4 07:59: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 3295E28C1A8 for ; Thu, 4 Feb 2010 07:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.54 X-Spam-Level: X-Spam-Status: No, score=-101.54 tagged_above=-999 required=5 tests=[AWL=-1.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_LWHUGE=1.54, 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 AvwKTJTtTlSH for ; Thu, 4 Feb 2010 07:59:03 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1EE983A676A for ; Thu, 4 Feb 2010 07:59:03 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o14FxnfA023616 for ; Thu, 4 Feb 2010 07:59:49 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265299189; bh=VPJPenUxBdzulmhdSkIh25sl0e4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=AA3N1AhMnI0OIB7cYKqAcuyfS46DUeXrJdKEU9GMjpjOsgf+78D4ZdZBmSkH8gdfA M/SzF70Ok0QubBA6Ekocg== 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=FUNOccxFcwxzD7ibSb5OwvUdoDF2t8boN6IicdOV5xBrhq57ZDt82AzJlVaQKv/Yc LLMHlg9KWiA+V6nJjuTIg== Received: from ywh35 (ywh35.prod.google.com [10.192.8.35]) by wpaz37.hot.corp.google.com with ESMTP id o14Fxluq013671 for ; Thu, 4 Feb 2010 07:59:48 -0800 Received: by ywh35 with SMTP id 35so2311658ywh.21 for ; Thu, 04 Feb 2010 07:59:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.175.2 with SMTP id x2mr2234861ybe.180.1265299187390; Thu, 04 Feb 2010 07:59:47 -0800 (PST) In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C025F18D6@SLFSNX.rcs.alcatel-research.de> References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <133D9897FB9C5E4E9DF2779DC91E947C025F18D6@SLFSNX.rcs.alcatel-research.de> Date: Thu, 4 Feb 2010 07:59:47 -0800 Message-ID: From: Jerry Chu To: "SCHARF, Michael" 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] TCP tuning 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, 04 Feb 2010 15:59:04 -0000 Michael, On Thu, Feb 4, 2010 at 5:35 AM, SCHARF, Michael wrote: > Jerry, > >> > - A significant increase to the initial window might benefit from >> > introduction of some form of pacing, since you won't have any ack >> > clock yet. =A0This might help reduce losses and delay jitter. >> >> Agreed. The question is, what is that threshold of >> window/burst size beyond which pacing is required. My current >> guess is > 10. > > I have the same impression, at least from what I have seen in simulations= . > > Yet, one could think of a very simple form of pacing with a single timer = that changes the Slow-Start only when it "hurts" - I think that I have ment= ioned this possibility on this list before: > > In this approach, the initial window remains at the value given by RFC 33= 90. But the sender is allowed to further increase the window after a certai= n time (say, 100ms), but only > if the RTT is known to be larger than 100ms (as measured e. g. during han= dshake), if no ACK has been received until then, and if recently there have= been no signs of congestion to this destination. > > The advantage of this approach is that TCP uses the larger initial window= only if the RTT is larger than 100ms (or whatever threshold is defined). O= n the one hand, this reduces the performance problems that can be observed = for RTTs of the order of 200ms. But, on the other hand, flows with a smalle= r RTT would use the existing Slow-Start, i. e., the faster startup is only = used by a small number of flows and thus be much less disruptive than a gen= eral revision of RFC 3390. > > A simpler variant of this idea is to allow an increased initial window be= yond RFC 3390 if the measured RTT is larger than a certain threshold such a= s 100ms. Thanks for all the interesting ideas. We may need them in the future. We actually spent the first few months testing a more complex algorithm, partly based on Joe Touch's caching idea described in RFC2140. We abandoned that approach later due to a number of problems, low cache hit rate due to server side load balancing being one of them. We have since adopted a two-phase approach. The first phase follows the KISS principle to simply pick a fixed, larger number for initial window that has minimal negative impact for all connections (and I can't believe it can't be bumped up by more than a couple of MSS safely, given the huge growth of average bandwidth and the gradual disappearing of dialup links < 56Kbps. Our test data has confirmed this, detailed in the upcoming paper). This enables a more timely deployment and a faster web experience for most people sooner while we can embark on a second phase to investigate a more elaborate algorithm involving pacing and other non-trivial implementation tasks but can unleash more performance for the regular users with 1.7Mbps, the average b/w globally reported recently by Aktimai. I understand and appreciate the "err on the conservative side" principle. The robustness and ubiquity of the Internet largely came out of it. But at some point it needs to be balanced against the need for improvement. My fear is that IETF might risk becoming irrelevant if it's too conservative, much like California's highway speed limit 20 years ago. It was at 55MPH while hardly anyone drove below that speed. (Of course what is considered "conservative", "risky" can be very subjective. The trick to get to some consensus here...) Jerry > > Michael > > > From perfgeek@mac.com Thu Feb 4 07:59: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 EB9BC3A689B for ; Thu, 4 Feb 2010 07:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUVp9MHWlsk4 for ; Thu, 4 Feb 2010 07:59:56 -0800 (PST) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by core3.amsl.com (Postfix) with ESMTP id 66B1F3A676A for ; Thu, 4 Feb 2010 07:59:56 -0800 (PST) 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 asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXB00ARAR561C60@asmtp022.mac.com> for tcpm@ietf.org; Thu, 04 Feb 2010 08:00:43 -0800 (PST) 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=5.0.0-0908210000 definitions=main-1002040123 Message-id: <6C3B471F-6ACB-467E-9D11-EE68388B3F5B@mac.com> From: rick jones To: Joe Touch In-reply-to: <4B6A6848.80904@isi.edu> Date: Thu, 04 Feb 2010 08:00:42 -0800 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <4B6A43D1.2010706@isi.edu> <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com> <443C71B6-1D1A-49CA-B5E4-FB81FDCB7FD1@mac.com> <4B6A6848.80904@isi.edu> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 15:59:58 -0000 On Feb 3, 2010, at 10:25 PM, Joe Touch wrote: > Did you use a netperf option to disable Nagle? No, there should be no need for that. For a TCP_RR test netperf presents all the data of a request or response to the transport in a single send call, there should be no delays Nagle at all. Further, in this case, there was only ever the one transaction in flight at a time, so at the time of each send() the connection was "idle" in the Nagle sense. > There are also many reasons this could happen; it might be easier to > see > in a plot. Anyone should feel free to grab either the binary (.pcap) or "cooked" (ascii) traces off of netperf.org and run them through whatever post processing tools they like. I would have shoved them into the original email, but didn't want to stuff peoples' inboxes unnecessarily. Still, if you think that copying some examples from the ascii into email would help I'm willing to do that. I'm not the acme of tcpdump trace reading, but it seemed pretty conclusive in the traces - with slowstart after idle, the 2.6.31 server sent the data of each 16K response with what certainly appears to be slow-start behaviour, with that sysctl set to disable slowstart after idle, no such slow start behaviour in the middle of the trace. So, for Linux 2.6.31, as distributed by Ubuntu, it would seem that the arrival of the next request is not going to preclude slowstart after idle behaviour. rick jones > > Joe > > rick jones wrote: >> >> On Feb 3, 2010, at 9:41 PM, rick jones wrote: >>> PS - I suppose if I'd been thinking more clearly, I'd have also >>> included --enable-historgram in the ./configure command and been >>> able >>> to give a histogram of the response times (adding a -v 2 option to >>> the >>> global command line options), but I suppose that can be guesstimated >>> from the traces. >> >> Ok, so perhaps I like running netperf too much :) Here then are the >> application-level measured response times. The first netperf is with >> tcp_slow_start_after_idle = 0, the second with it set to 1, I'll >> leave-out the rest of the netperf output as it is repetitive: >> >> tcp_slow_start_after_idle = 0 on server: >> >> Histogram of request/response times >> UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> HUNDRED_USEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> UNIT_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> TEN_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> HUNDRED_MSEC : 0: 294: 4: 0: 2: 0: 0: 0: >> 0: 0 >> UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >>> 100_SECS: 0 >> HIST_TOTAL: 300 >> >> That means 294 times 100ms <= responsetime < 200ms, 4 times it was >> 200ms >> <= responsetime < 300ms etc etc. >> >> tcp_slow_start_after_idle = 1 on server: >> >> UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> HUNDRED_USEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> UNIT_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> TEN_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> HUNDRED_MSEC : 0: 0: 0: 290: 10: 0: 0: 0: >> 0: 0 >> UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >> TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: >> 0: 0 >>> 100_SECS: 0 >> HIST_TOTAL: 300 >> >> Now it was 290 with 300ms <= responsetime < 400ms >> >> Just as a refresher, the request size was 128 bytes, the response >> size >> 16384. >> >> The ICMP Echo RTT is ~120 ms between my home system and netperf.org: >> >> --- netperf.org ping statistics --- >> 10 packets transmitted, 10 packets received, 0% packet loss >> round-trip min/avg/max/stddev = 119.523/120.410/121.248/0.493 ms >> >> rick jones >> Wisdom teeth are impacted, people are affected by the effects of >> events > Wisdom teeth are impacted, people are affected by the effects of events From kacheong.poon@sun.com Thu Feb 4 08:27: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 B85E73A6B1E for ; Thu, 4 Feb 2010 08:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 7x3E6uYBkL3b for ; Thu, 4 Feb 2010 08:27:57 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id DFEB23A69ED for ; Thu, 4 Feb 2010 08:27:56 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o14GSgo8025404 for ; Thu, 4 Feb 2010 16:28:43 GMT Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o14GSf0K403553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Feb 2010 08:28:42 -0800 (PST) Message-ID: <4B6AF5B8.60607@sun.com> Date: Fri, 05 Feb 2010 00:28:40 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100115 Thunderbird/3.0.1 MIME-Version: 1.0 To: tcpm@ietf.org References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <133D9897FB9C5E4E9DF2779DC91E947C025F18D6@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C025F18D6@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 16:27:57 -0000 On 02/ 4/10 09:35 PM, SCHARF, Michael wrote: > Yet, one could think of a very simple form of pacing with a single timer that changes the Slow-Start only when it "hurts" - I think that I have mentioned this possibility on this list before: > > In this approach, the initial window remains at the value given by RFC 3390. But the sender is allowed to further increase the window after a certain time (say, 100ms), but only > if the RTT is known to be larger than 100ms (as measured e. g. during handshake), if no ACK has been received until then, and if recently there have been no signs of congestion to this destination. For a server, it may just have 1 sample of RTT (the ACK for its SYN/ACK). Is this enough to determine much? Suppose the ACK for the SYN/ACK is lost, and the server gets a request (data + ACK for the SYN/ACK) instead, can it distinguish this case from the case when a client can bundle data in third leg of 3-way handshake? And it seems to defeat much of the benefits of increasing the initial cwnd if the server needs to wait 100ms before sending more. > The advantage of this approach is that TCP uses the larger initial window only if the RTT is larger than 100ms (or whatever threshold is defined). On the one hand, this reduces the performance problems that can be observed for RTTs of the order of 200ms. But, on the other hand, flows with a smaller RTT would use the existing Slow-Start, i. e., the faster startup is only used by a small number of flows and thus be much less disruptive than a general revision of RFC 3390. > > A simpler variant of this idea is to allow an increased initial window beyond RFC 3390 if the measured RTT is larger than a certain threshold such as 100ms. -- K. Poon. kacheong.poon@sun.com From touch@ISI.EDU Thu Feb 4 08:42: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 879B928C0FA for ; Thu, 4 Feb 2010 08:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 S805+Gc0WdST for ; Thu, 4 Feb 2010 08:42:49 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 54A2028C0F4 for ; Thu, 4 Feb 2010 08:42:49 -0800 (PST) Received: from [70.213.22.78] (78.sub-70-213-22.myvzw.com [70.213.22.78]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o14GddxQ003256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2010 08:39:41 -0800 (PST) Message-ID: <4B6AF84A.9080509@isi.edu> Date: Thu, 04 Feb 2010 08:39:38 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: rick jones References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <4B6A43D1.2010706@isi.edu> <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com> <443C71B6-1D1A-49CA-B5E4-FB81FDCB7FD1@mac.com> <4B6A6848.80904@isi.edu> <6C3B471F-6ACB-467E-9D11-EE68388B3F5B@mac.com> In-Reply-To: <6C3B471F-6ACB-467E-9D11-EE68388B3F5B@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig317DAECC8B75F2BBD696D391" X-MailScanner-ID: o14GddxQ003256 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 16:42:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig317DAECC8B75F2BBD696D391 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable rick jones wrote: >=20 > On Feb 3, 2010, at 10:25 PM, Joe Touch wrote: >> Did you use a netperf option to disable Nagle? >=20 > No, there should be no need for that. For a TCP_RR test netperf > presents all the data of a request or response to the transport in a > single send call, there should be no delays Nagle at all. I don't know why this still isn't widely known, but there is *no* correlation between the OS interface and TCP segment emissions per se. Send calls don't correspond to buffer flushes or anything else. All they do is load the buffer. Nagle still needs to be disabled. > Further, in > this case, there was only ever the one transaction in flight at a time,= > so at the time of each send() the connection was "idle" in the Nagle se= nse. Again, "at the time of each send()" is irrelelvant. What's relevant is what's in the buffers. >> There are also many reasons this could happen; it might be easier to s= ee >> in a plot. >=20 > Anyone should feel free to grab either the binary (.pcap) or "cooked" > (ascii) traces off of netperf.org and run them through whatever post > processing tools they like. I would have shoved them into the original= > email, but didn't want to stuff peoples' inboxes unnecessarily. Still,= > if you think that copying some examples from the ascii into email would= > help I'm willing to do that. >=20 > I'm not the acme of tcpdump trace reading, but it seemed pretty > conclusive in the traces - with slowstart after idle, the 2.6.31 server= > sent the data of each 16K response with what certainly appears to be > slow-start behaviour, with that sysctl set to disable slowstart after > idle, no such slow start behaviour in the middle of the trace. So, for= > Linux 2.6.31, as distributed by Ubuntu, it would seem that the arrival > of the next request is not going to preclude slowstart after idle > behaviour. Some versions of Linux may have various tricks implemented. None of them havae been standardized, though. It's worth checking with a few different OS's. Joe --------------enig317DAECC8B75F2BBD696D391 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) iEYEARECAAYFAktq+EsACgkQE5f5cImnZrtsIwCeLJ8W91Qx+fRW6QBTnv94SnOG sygAnRe8mtDERmOmDCO6PyiBxZ99Bsso =JmqF -----END PGP SIGNATURE----- --------------enig317DAECC8B75F2BBD696D391-- From Michael.Scharf@alcatel-lucent.com Thu Feb 4 08:57: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 8545328C180 for ; Thu, 4 Feb 2010 08:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 LEnbKscC5TTH for ; Thu, 4 Feb 2010 08:57:46 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 6282428C175 for ; Thu, 4 Feb 2010 08:57:46 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id o14GwVRZ013367 for ; Thu, 4 Feb 2010 17:58:31 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 4 Feb 2010 17:58:30 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C025F18FA@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <4B6AF5B8.60607@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP tuning Thread-Index: AcqltyJZz01EBYCdQ+6FawMjSm+omAAALEkg References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com><1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com><133D9897FB9C5E4E9DF2779DC91E947C025F18D6@SLFSNX.rcs.alcatel-research.de> <4B6AF5B8.60607@sun.com> From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 16:57:47 -0000 > > Yet, one could think of a very simple form of pacing with a=20 > single timer that changes the Slow-Start only when it "hurts"=20 > - I think that I have mentioned this possibility on this list before: > > > > In this approach, the initial window remains at the value=20 > given by RFC=20 > > 3390. But the sender is allowed to further increase the=20 > window after a certain time (say, 100ms), but only if the RTT=20 > is known to be larger than 100ms (as measured e. g. during=20 > handshake), if no ACK has been received until then, and if=20 > recently there have been no signs of congestion to this destination. >=20 >=20 > For a server, it may just have 1 sample of RTT (the ACK for=20 > its SYN/ACK). Is this enough to determine much? Suppose the=20 > ACK for the SYN/ACK is lost, and the server gets a request=20 > (data + ACK for the SYN/ACK) instead, can it distinguish this=20 > case from the case when a client can bundle data in third leg=20 > of 3-way handshake? Of course, one would not use this mechanism if there is any sign of lost packets. But, obviously, any heuristic can fail. BTW, another problem is a highly congested link resulting in a large RTT. In this case, the algorithm would send additional data to a congested link - but this would also happen if the initial window would be increased. There is no free lunch. > And it seems to defeat much of the benefits of increasing the=20 > initial cwnd if the server needs to wait 100ms before sending more. If the RTT is larger than 100ms (or whatever threshold is used), you would still get a benefit compared to RFC 3390. Maybe that would be just good enough? Michael From perfgeek@mac.com Thu Feb 4 10:17:20 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 F218B28C17D for ; Thu, 4 Feb 2010 10:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5ddJo41UwWv for ; Thu, 4 Feb 2010 10:17:18 -0800 (PST) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by core3.amsl.com (Postfix) with ESMTP id CECA728C167 for ; Thu, 4 Feb 2010 10:17:18 -0800 (PST) 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 asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXB00G8UXHK3U50@asmtp019.mac.com> for tcpm@ietf.org; Thu, 04 Feb 2010 10:17:46 -0800 (PST) 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=5.0.0-0908210000 definitions=main-1002040162 Message-id: <5995012B-4768-4073-A153-1AB8012A84D4@mac.com> From: rick jones To: Joe Touch In-reply-to: <4B6AF84A.9080509@isi.edu> Date: Thu, 04 Feb 2010 10:17:44 -0800 References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <4B6A43D1.2010706@isi.edu> <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com> <443C71B6-1D1A-49CA-B5E4-FB81FDCB7FD1@mac.com> <4B6A6848.80904@isi.edu> <6C3B471F-6ACB-467E-9D11-EE68388B3F5B@mac.com> <4B6AF84A.9080509@isi.edu> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 18:17:20 -0000 On Feb 4, 2010, at 8:39 AM, Joe Touch wrote: > rick jones wrote: >> >> On Feb 3, 2010, at 10:25 PM, Joe Touch wrote: >>> Did you use a netperf option to disable Nagle? >> >> No, there should be no need for that. For a TCP_RR test netperf >> presents all the data of a request or response to the transport in a >> single send call, there should be no delays Nagle at all. > > I don't know why this still isn't widely known, but there is *no* > correlation between the OS interface and TCP segment emissions per se. > Send calls don't correspond to buffer flushes or anything else. All > they > do is load the buffer. > > Nagle still needs to be disabled. > >> Further, in >> this case, there was only ever the one transaction in flight at a >> time, >> so at the time of each send() the connection was "idle" in the >> Nagle sense. > > Again, "at the time of each send()" is irrelelvant. What's relevant is > what's in the buffers. My experience thusfar with netperf benchmarking has been that the single-transaction at a time TCP_RR test has never run into Nagle- induced delays on any stack that wasn't broken, and I cannot recall the last time I encountered such a broken stack. Still, if it will help remove a crimson fish from the sea, I have placed under: ftp://ftp.netperf.org/traces/nonagle another set of traces, this time with the -D option added to netperf to cause it to set TCP_NODELAY on either end. My look at them suggests there has been no change in behaviour from the initial set of traces without TCP_NODELAY set. > Some versions of Linux may have various tricks implemented. None of > them > havae been standardized, though. It's worth checking with a few > different OS's. The cooked traces with and without thinktime, and HP-UX 11.31 as the server are under "hpux_11.31" under the URL above. They too are with TCP_NODELAY set on both ends, and they too seem to show a very slow- start after idle behaviour in the presence of client thinktime. There is no obvious ndd option to disable the behaviour so there is no third trace there. rick jones Wisdom teeth are impacted, people are affected by the effects of events From touch@ISI.EDU Thu Feb 4 10:40: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 A90583A6DEF for ; Thu, 4 Feb 2010 10:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 G-H-G+zEHKH5 for ; Thu, 4 Feb 2010 10:40:36 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 120443A6D5B for ; Thu, 4 Feb 2010 10:40:36 -0800 (PST) Received: from [75.214.242.122] (122.sub-75-214-242.myvzw.com [75.214.242.122]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o14Ic9GP000221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2010 10:38:11 -0800 (PST) Message-ID: <4B6B1410.9010604@isi.edu> Date: Thu, 04 Feb 2010 10:38:08 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: rick jones References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <4B6A43D1.2010706@isi.edu> <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com> <443C71B6-1D1A-49CA-B5E4-FB81FDCB7FD1@mac.com> <4B6A6848.80904@isi.edu> <6C3B471F-6ACB-467E-9D11-EE68388B3F5B@mac.com> <4B6AF84A.9080509@isi.edu> <5995012B-4768-4073-A153-1AB8012A84D4@mac.com> In-Reply-To: <5995012B-4768-4073-A153-1AB8012A84D4@mac.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB09A0D0D38A542B5AA4C9427" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 18:40:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB09A0D0D38A542B5AA4C9427 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable rick jones wrote: =2E.. > My experience thusfar with netperf benchmarking has been that the > single-transaction at a time TCP_RR test has never run into > Nagle-induced delays on any stack that wasn't broken, and I cannot > recall the last time I encountered such a broken stack.=20 What you have seen is consistency in implementations. Such behavior is not required by the specs, so it should not be considered "broken", nor should tests rely on it. Thanks for removing it as an issue, though. There are many other things that could be happening, and as I noted the behavior was never really well spec'd AFAIR. Joe --------------enigB09A0D0D38A542B5AA4C9427 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) iEYEARECAAYFAktrFBAACgkQE5f5cImnZrt31wCg23migqDaHwlw8h3YqQDicaq0 B+kAnRV1rJNre/ltD2kX30UR9axyABAY =6hG4 -----END PGP SIGNATURE----- --------------enigB09A0D0D38A542B5AA4C9427-- From touch@ISI.EDU Thu Feb 4 10:42:39 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 1CD233A6DF6 for ; Thu, 4 Feb 2010 10:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 uvbhE3-zxK1L for ; Thu, 4 Feb 2010 10:42:38 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3A5E73A6DF1 for ; Thu, 4 Feb 2010 10:42:38 -0800 (PST) Received: from [75.214.242.122] (122.sub-75-214-242.myvzw.com [75.214.242.122]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o14IeXco001167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2010 10:40:35 -0800 (PST) Message-ID: <4B6B14A0.7020408@isi.edu> Date: Thu, 04 Feb 2010 10:40:32 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <4B69CDD7.6060802@isi.edu> <4B6A43D1.2010706@isi.edu> <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com> <443C71B6-1D1A-49CA-B5E4-FB81FDCB7FD1@mac.com> <4B6A6848.80904@isi.edu> <6C3B471F-6ACB-467E-9D11-EE68388B3F5B@mac.com> <4B6AF84A.9080509@isi.edu> In-Reply-To: <4B6AF84A.9080509@isi.edu> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E5641F6A5A1438A5C64807E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 04 Feb 2010 18:42:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E5641F6A5A1438A5C64807E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable PS - it might be useful to take a look at the following old (expired) ID on this issue. As I noted, I'd be glad to 'restart' it... Joe http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt --------------enig5E5641F6A5A1438A5C64807E 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) iEYEARECAAYFAktrFKAACgkQE5f5cImnZrshYACeP/wXbT2NgCAHWbwRF7r+ncFn mlIAnjLw8Asdijnwq6fR8c/BLmkrqnSR =7RkC -----END PGP SIGNATURE----- --------------enig5E5641F6A5A1438A5C64807E-- From hkchu@google.com Thu Feb 4 17:29:24 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 155083A6984 for ; Thu, 4 Feb 2010 17:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, 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 A+lohhbwYlLo for ; Thu, 4 Feb 2010 17:29:23 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1BBCB3A68C8 for ; Thu, 4 Feb 2010 17:29:23 -0800 (PST) Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id o151UAFE020226 for ; Thu, 4 Feb 2010 17:30:10 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265333410; bh=ck75PHbs8X3qIy2r1S/5WoeLflE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=PDnH/i05R5YSWM91y4Qll+9x+wrN0xfJD5R+KgWai3/5dYfVJaicvQWP0f+aYILMT cD5dIYOiXZNWBc4Qu8Vfg== 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=Mvi55AW9umML2Bi5chtYeSz5e5UX2XfoQEAej01JA4KeTOifQCpwfOO5IL38f7hRt 4y3Ct1Jx29OJKU5AGGOcg== Received: from pzk30 (pzk30.prod.google.com [10.243.19.158]) by spaceape11.eur.corp.google.com with ESMTP id o151U8GL023175 for ; Thu, 4 Feb 2010 17:30:09 -0800 Received: by pzk30 with SMTP id 30so1732777pzk.11 for ; Thu, 04 Feb 2010 17:30:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.124.18 with SMTP id b18mr1326225rvn.151.1265333407157; Thu, 04 Feb 2010 17:30:07 -0800 (PST) In-Reply-To: References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <133D9897FB9C5E4E9DF2779DC91E947C025F18D6@SLFSNX.rcs.alcatel-research.de> Date: Thu, 4 Feb 2010 17:30:07 -0800 Message-ID: From: Jerry Chu To: ayourtch@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] TCP tuning 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, 05 Feb 2010 01:29:24 -0000 On Thu, Feb 4, 2010 at 6:05 AM, Andrew Yourtchenko wro= te: > > > On Thu, 4 Feb 2010, SCHARF, Michael wrote: > >> Jerry, >> >>>> - A significant increase to the initial window might benefit from >>>> introduction of some form of pacing, since you won't have any ack >>>> clock yet. =A0This might help reduce losses and delay jitter. >>> >>> Agreed. The question is, what is that threshold of >>> window/burst size beyond which pacing is required. My current >>> guess is > 10. >> >> I have the same impression, at least from what I have seen in simulation= s. >> >> Yet, one could think of a very simple form of pacing with a single timer >> that changes the Slow-Start only when it "hurts" - I think that I have >> mentioned this possibility on this list before: >> >> In this approach, the initial window remains at the value given by RFC >> 3390. But the sender is allowed to further increase the window after a >> certain time (say, 100ms), but only >> if the RTT is known to be larger than 100ms (as measured e. g. during >> handshake), if no ACK has been received until then, and if recently ther= e >> have been no signs of congestion to this destination. >> >> The advantage of this approach is that TCP uses the larger initial windo= w >> only if the RTT is larger than 100ms (or whatever threshold is defined).= On >> the one hand, this reduces the performance problems that can be observed= for >> RTTs of the order of 200ms. But, on the other hand, flows with a smaller= RTT >> would use the existing Slow-Start, i. e., the faster startup is only use= d by >> a small number of flows and thus be much less disruptive than a general >> revision of RFC 3390. >> >> A simpler variant of this idea is to allow an increased initial window >> beyond RFC 3390 if the measured RTT is larger than a certain threshold s= uch >> as 100ms. > > And a possible tweak to this: if we increased the initial window beyond > RFC3390, measure the number of retransmits that have to be done for those > segments. If the stack had to retransmit, then subsequent connection > attempts from the host would need to reduce this "increased" window. Yes we have tried something very similar (dubbed "negative cache"), but discovered its effectiveness depends heavily on a high cache hit, which is difficult in a large server farm behind a stateless load balancer. A small tweak included in the upcoming I-D is to back down to rfc3390 on RW if any burst size (during IW or RW) > 4KB incurs pkt loss. Admittedly this is a smaller and less effective tweak but it doesn't need to maintain any history across different connections. Jerry > > I think this could help to take care of the concern about the short queue > limits on the access-layer equipment. > > > cheers, > andrew > >> >> Michael >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From lars.eggert@nokia.com Fri Feb 5 00:36:33 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 DE59B28C122 for ; Fri, 5 Feb 2010 00:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 0Z1pcO2O0PSY for ; Fri, 5 Feb 2010 00:36:33 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 3888F28C10B for ; Fri, 5 Feb 2010 00:36:33 -0800 (PST) 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 o158ahEh020495 for ; Fri, 5 Feb 2010 02:37:22 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 10:36:40 +0200 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.3959); Fri, 5 Feb 2010 10:36:40 +0200 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 o158adl8009076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Feb 2010 10:36:39 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-38--711015402; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 5 Feb 2010 10:36:33 +0200 Message-Id: <6AD928AD-1FFA-4B84-B0FB-252316B31964@nokia.com> To: "tcpm@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Fri, 05 Feb 2010 10:36:33 +0200 (EET) X-OriginalArrivalTime: 05 Feb 2010 08:36:40.0992 (UTC) FILETIME=[56EB3A00:01CAA63E] X-Nokia-AV: Clean Subject: [tcpm] hybi 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, 05 Feb 2010 08:36:34 -0000 --Apple-Mail-38--711015402 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, the HYBI WG in the apps area is discussing the webocket protocol and the = discussion would benefit from the input of folks who understand TCP. See = the "Reliable message delivery" thread there. Lars= --Apple-Mail-38--711015402 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 MQ8XDTEwMDIwNTA4MzYzM1owIwYJKoZIhvcNAQkEMRYEFM6b/kO+P33emNMb7XTRTlHifS/FMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDJ6JVbKJO4WJvqooAMkiRKga0SgaXoIqukUXbAL7u1FNj6K8XSVQwixSuWb2rCIj/bgB80 urIBFhgMYrgYAyCuNa7x7tvWtCUjOpIK/X0AccNC7CD8kbKHtUQ/vc44SdVW8s8mCvUzBoiUO99Q z8U6lHZLQ8n/lmxcXT8cY412w7YJoQlOWwSNziEgmHSoXUfGdl/HzKVIelYBJ+tMFtzixvVl0ZQ9 BflZ9K15S/OOMxbEqCGTb2KofLm9hM1FXzuWovMsuWkBz2RU1q09UMenkwJ5NDiN8RfKo22TjYu1 NugakIavyOl5ydk1vvdYC/IgnjSfE3TIk5W5yq5uTy+kAAAAAAAA --Apple-Mail-38--711015402-- From david.borman@windriver.com Fri Feb 5 11:37: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 21B4628C17F for ; Fri, 5 Feb 2010 11:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 MCaC4D6FFqkD for ; Fri, 5 Feb 2010 11:37:39 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id B1F8E28C0EC for ; Fri, 5 Feb 2010 11:37:39 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o15JcRYT018421; Fri, 5 Feb 2010 11:38:27 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Feb 2010 11:38:17 -0800 Received: from [172.25.34.53] ([172.25.34.53]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Feb 2010 11:40:33 -0800 From: David Borman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Feb 2010 13:38:14 -0600 Message-Id: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> To: "tcpm@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-OriginalArrivalTime: 05 Feb 2010 19:40:34.0228 (UTC) FILETIME=[1560AF40:01CAA69B] Cc: tcpm-chairs@tools.ietf.org, ayourtch@cisco.com, Fernando Gont Subject: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Fri, 05 Feb 2010 19:37:41 -0000 Note: As recent discussions on this list have indicated, we need members = of this mailing list to be involved. Please take the time to read = through this document and send a message to the mailing list either = supporting publishing this document, or commenting on why it is not = ready to be published. This particular document is quite short and easy = to understand. -David Borman, TCPM co-chair. ---------------------------- This is to announce the start of the WG Last Call for: Title : On the implementation of the TCP urgent mechanism Author(s) : F. Gont and A. Yourtchenko Filename : draft-ietf-tcpm-urgent-data-02.txt Pages : 13 Date : November 26, 2009 Intended Status : Proposed Standard http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-02.txt It is our understanding that all the feedback has been incorporated into = this latest version and that there are no known outstanding issues with = this document. Please send feedback to the list. The WGLC will end on Friday, February 19, 2010. From michawe@ifi.uio.no Mon Feb 8 02:31: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 88E793A7352 for ; Mon, 8 Feb 2010 02:31:58 -0800 (PST) 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 o1dE4QX-LqVP for ; Mon, 8 Feb 2010 02:31:56 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 8EDC03A734E for ; Mon, 8 Feb 2010 02:31:55 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1NeQvH-0006nH-UB; Mon, 08 Feb 2010 11:32:55 +0100 Received: from div-8021x-dhcp216.uio.no ([193.157.176.225]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1NeQvH-0006Sh-F8; Mon, 08 Feb 2010 11:32:55 +0100 Message-Id: <61FBA2BB-0432-4556-A2CA-6659B0E1D8E1@ifi.uio.no> From: Michael Welzl To: David Borman In-Reply-To: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 8 Feb 2010 11:32:53 +0100 References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> X-Mailer: Apple Mail (2.935.3) X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 15 sum msgs/h 8 total rcpts 5982 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 26B3B6645A83304338106599593F1EF3A7BCFBF3 X-UiO-SPAM-Test: remote_host: 193.157.176.225 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 825 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org WG" , ayourtch@cisco.com, Fernando Gont Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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, 08 Feb 2010 10:31:58 -0000 Read it, and liked it. Just a few nits: It seems a bit pointless to repeat the same text in the introduction and in section 2.1 - in the first paragraph of the introduction, the part that starts with: "permits a point in the data stream to be designated .... " and ends with: "the TCP must tell user to go into "normal mode" " (which, by the way, misses a "the" before "user".) I think that this part could safely be removed from the introduction and just kept in section 2.1, and the reference at the end of the first paragraph should then be moved there too. Section 3.4: "As a result of the publication of Network Intrusion Detection (NIDs) evasion techniques based on TCP urgent indications [phrack], some middle-boxes clear the urgent indications by clearing the URG flag and setting the Urgent Pointer to zero." => are you 100% sure that this is the result of the publication of these techniques? Otherwise I'd rather state this with "perhaps". a bit further down: "Examples of such middle-boxes are Cisco PIX firewall [Cisco-PIX]." should be "An example of such a middle-box is the ..." next sentence: "This should discourage applications to depend" => "This should discourage applications from depending" (I think - I'm not a native speaker myself) Cheers, Michael On Feb 5, 2010, at 8:38 PM, David Borman wrote: > Note: As recent discussions on this list have indicated, we need > members of this mailing list to be involved. Please take the time > to read through this document and send a message to the mailing list > either supporting publishing this document, or commenting on why it > is not ready to be published. This particular document is quite > short and easy to understand. -David Borman, TCPM co-chair. > ---------------------------- > > This is to announce the start of the WG Last Call for: > > Title : On the implementation of the TCP urgent mechanism > Author(s) : F. Gont and A. Yourtchenko > Filename : draft-ietf-tcpm-urgent-data-02.txt > Pages : 13 > Date : November 26, 2009 > Intended Status : Proposed Standard > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-02.txt > > It is our understanding that all the feedback has been incorporated > into this latest version and that there are no known outstanding > issues with this document. > > Please send feedback to the list. > > The WGLC will end on Friday, February 19, 2010. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From gregory.ietf@gmail.com Mon Feb 8 18:06: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 E600328C1CC for ; Mon, 8 Feb 2010 18:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.08 X-Spam-Level: X-Spam-Status: No, score=-102.08 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 iDrO+-9uZpvM for ; Mon, 8 Feb 2010 18:06:37 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id DA3BF28C1C5 for ; Mon, 8 Feb 2010 18:06:36 -0800 (PST) Received: by bwz19 with SMTP id 19so381937bwz.28 for ; Mon, 08 Feb 2010 18:07:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=Oj2L8IcVis9n0xscYeHWfiy9jcg6frzC+T85W0JHsi8=; b=MIfmiEwoc+sqaS0W+FkwQzzgcpNUMazsiajsZ2RtsVr7PKXpo8oOIJGKF00sjjLPsS shLxVXasDVRNJ+No30l6teIaPnvLdU/YFG1gjjixZywl3tbTNlzkgdWud9GzG6ZeJhjW m6UMO1GeOgr1u48Ne02c9evVUk0+nmsUGKRIs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=teO9D51CZbYvvg31yq36YFPNUDR2bOZfuHkwnpv3QVCxjxShDxd5SNCMgjbDVPvTj+ aripvHT3f7/S+KyAA/NXXF1si4tjT5inNthpPIpc+HwLnUqjrj7rBHP3PwpRR2xEuRoB u394sJEww5Hvk+MNbEtbRG5R5xqPEZDMmVTEw= MIME-Version: 1.0 Received: by 10.204.49.70 with SMTP id u6mr3299283bkf.56.1265681256731; Mon, 08 Feb 2010 18:07:36 -0800 (PST) Date: Mon, 8 Feb 2010 18:07:36 -0800 Message-ID: From: Gregory Lebovitz To: Lars Eggert Content-Type: multipart/alternative; boundary=000325554396b4d462047f21617e Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org, draft-ietf-tcpm-tcp-auth-opt@tools.ietf.org, draft-ietf-tcpm-tcp-ao-crypto@tools.ietf.org Subject: [tcpm] tcp-ao-crypto, only 1 comment (was: Re: I-D Action:draft-ietf-tcpm-tcp-auth-opt-10.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: Tue, 09 Feb 2010 02:06:38 -0000 --000325554396b4d462047f21617e Content-Type: text/plain; charset=ISO-8859-1 Hey all, I'm working on tcp-ao-crypto tonight. I have now read back through the list since just before the WGLC, and I see ONLY 1 comment on this document, that from Brian Weis. I'll fold in his comments, and publish -03. Meanwhile, if you believe you sent comments on -02, and you are not Brian Weis, then you better resend to me, cc'ing the tcpm list, ASAP. Gregory On Thu, Feb 4, 2010 at 7:48 AM, Lars Eggert wrote: > Hi, > > On 2010-2-1, at 2:45, Internet-Drafts@ietf.org wrote: > > Title : The TCP Authentication Option > > Author(s) : J. Touch, et al. > > Filename : draft-ietf-tcpm-tcp-auth-opt-10.txt > > thanks for the update, Joe! > > Gregory: what's the status of -crypto? > > Chairs: When we have the -crypto revision, please check if the WG has > consensus to request publication of the two docs. > > Thanks, > Lars -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000325554396b4d462047f21617e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey all,
I'm working on tcp-ao-crypto tonight. I have now read back= through the list since just before the WGLC, and I see ONLY 1 comment on t= his document, that from Brian Weis.

I'll fold in his= comments, and publish -03.

Meanwhile, if you believe you sent comments on -02, and= you are not Brian Weis, then you better resend to me, cc'ing the tcpm = list, ASAP.=A0

Gregory

On Thu, Feb 4, 2010 at 7:48 AM, Lars Eggert <lars.eggert@nokia.com> wrot= e:
Hi,

On 2010-2-1, at 2:45, Internet-= Drafts@ietf.org wrote:
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The TCP Authentication Option<= br> > =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : J. Touch, et al.
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-tcpm-tcp-auth-opt-10.= txt

thanks for the update, Joe!

Gregory: what's the status of -crypto?

Chairs: When we have the -crypto revision, please check if the WG has conse= nsus to request publication of the two docs.

Thanks,
Lars



--
----
IETF related email from
Gregory M. Lebovitz
Junip= er Networks
--000325554396b4d462047f21617e-- From gregory.ietf@gmail.com Tue Feb 9 13:56: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 263FC28C0F9 for ; Tue, 9 Feb 2010 13:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.076 X-Spam-Level: X-Spam-Status: No, score=-102.076 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 gIORLNowrhIt for ; Tue, 9 Feb 2010 13:56:28 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id CB9CD3A6CD5 for ; Tue, 9 Feb 2010 13:56:27 -0800 (PST) Received: by bwz3 with SMTP id 3so2131673bwz.13 for ; Tue, 09 Feb 2010 13:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DnuZRQJod5VeW8zpoPKdJkJFu29srgfdgnW4RHLxOhQ=; b=XKmDDIpc5BfRKmzYQH02zxiOp3Dvf5oAesGXJQMXfHE5NWoolyxIYdx9qPZHVaGuHP U+3PkCo9o6OiBFJWtbR9TKAy24LZmGXUuz2YJr58PCuhrsiWp42fVCGFRP8iWFnC8U2z gZwEdSj4Y2LCN7gIpDnGwNgoFxeSk0CbaHSmM= 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=Ft0Tt/8y74H/nNMEC0jPrseMVRCXS7Jk6LIu9msF+qT9rvvw0mS/RPcms/5+4jNEkZ /YXJ0KNo3lyhqIzbOvR2LjjOT9GLYzzxq8QPZqWJ7SFsdNUG3FOWOkFkLQDMA4rSzPir 0A8b5wwwsI8IuI9dlmRtq2Jy9AkY3iaBqHC7k= MIME-Version: 1.0 Received: by 10.204.9.6 with SMTP id j6mr2467433bkj.37.1265752648519; Tue, 09 Feb 2010 13:57:28 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Feb 2010 13:57:28 -0800 Message-ID: From: Gregory Lebovitz To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: multipart/alternative; boundary=0015175884aefd0f16047f320006 Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-ao-crypto, only 1 comment (was: Re: I-D Action:draft-ietf-tcpm-tcp-auth-opt-10.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: Tue, 09 Feb 2010 21:56:29 -0000 --0015175884aefd0f16047f320006 Content-Type: text/plain; charset=ISO-8859-1 Thanks, Wes. I missed those. Good catch. I'll update with those. Gregory. On Mon, Feb 8, 2010 at 9:24 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > There were a small number of comments at the tail of my review: > http://www.ietf.org/mail-archive/web/tcpm/current/msg05028.html > > > ------------------------------ > *From:* tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Gregory > Lebovitz [gregory.ietf@gmail.com] > *Sent:* Monday, February 08, 2010 9:07 PM > *To:* Lars Eggert > *Cc:* tcpm-chairs@tools.ietf.org; tcpm@ietf.org; > draft-ietf-tcpm-tcp-auth-opt@tools.ietf.org; > draft-ietf-tcpm-tcp-ao-crypto@tools.ietf.org > *Subject:* [tcpm] tcp-ao-crypto, only 1 comment (was: Re: I-D > Action:draft-ietf-tcpm-tcp-auth-opt-10.txt) > > Hey all, > I'm working on tcp-ao-crypto tonight. I have now read back through the list > since just before the WGLC, and I see ONLY 1 comment on this document, that > from Brian Weis. > > I'll fold in his comments, and publish -03. > > Meanwhile, if you believe you sent comments on -02, and you are not Brian > Weis, then you better resend to me, cc'ing the tcpm list, ASAP. > > Gregory > > On Thu, Feb 4, 2010 at 7:48 AM, Lars Eggert wrote: > >> Hi, >> >> On 2010-2-1, at 2:45, Internet-Drafts@ietf.org wrote: >> > Title : The TCP Authentication Option >> > Author(s) : J. Touch, et al. >> > Filename : draft-ietf-tcpm-tcp-auth-opt-10.txt >> >> thanks for the update, Joe! >> >> Gregory: what's the status of -crypto? >> >> Chairs: When we have the -crypto revision, please check if the WG has >> consensus to request publication of the two docs. >> >> Thanks, >> Lars > > > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0015175884aefd0f16047f320006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Wes. I missed those. Good catch.

I'll update= with those.

Gregory.

On Mon, Feb 8, 2010 at 9:24 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROS= PACE CORP] <= wesley.m.eddy@nasa.gov> wrote:
There we= re a small number of comments at the tail of my review:
=A0
=A0
From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Beha= lf Of Gregory Lebovitz [gregory.ietf@gmail.com]
Sent: Monday, February 08, 2010 9:07 PM
To: Lars Eggert
Cc: = tcpm-chairs@tools.ietf.org; tcpm@ietf.org; draft-ietf-tcpm-tcp-auth-opt@tools.ietf.or= g; draft-ietf-tcpm-tcp-ao-crypto@tools.ietf.org
Subject: [tcpm] tcp-ao-crypto, only 1 comment (was: Re: I-D Action:d= raft-ietf-tcpm-tcp-auth-opt-10.txt)

Hey all,
I'm working on tcp-ao-crypto tonight. I have now read back through= the list since just before the WGLC, and I see ONLY 1 comment on this docu= ment, that from Brian Weis.

I'll fold in his comments, and publish -03.

Meanwhile, if you believe you sent comments on -02, and you are not Br= ian Weis, then you better resend to me, cc'ing the tcpm list, ASAP.=A0<= /div>

Gregory

On Thu, Feb 4, 2010 at 7:48 AM, Lars Eggert <lars.eggert@= nokia.com> wrote:
Hi,

On 2010-2-1, at 2:45, Internet-Drafts@ietf.org wrote:
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The TCP Authentication Option<= br> > =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : J. Touch, et al.
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-tcpm-tcp-auth-opt-10.= txt

thanks for the update, Joe!

Gregory: what's the status of -crypto?

Chairs: When we have the -crypto revision, please check if the WG has conse= nsus to request publication of the two docs.

Thanks,
Lars



--
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks



--
----
IETF related em= ail from
Gregory M. Lebovitz
Juniper Networks
--0015175884aefd0f16047f320006-- From gregory.ietf@gmail.com Wed Feb 10 00:14:24 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 7832A3A73B8 for ; Wed, 10 Feb 2010 00:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DJfRY3XkgF5Z for ; Wed, 10 Feb 2010 00:14:23 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 9C4753A687C for ; Wed, 10 Feb 2010 00:14:22 -0800 (PST) Received: by bwz19 with SMTP id 19so1650449bwz.28 for ; Wed, 10 Feb 2010 00:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=qDo14qNCP7TPbZSXat/0HpMV5OLJqKZbymcqgRJBLgo=; b=J87BeUwu3HltdmarVbYSnbrrMpxBTfHGP+rOCfQkg/sIpMa84A8WJBrrv6EOLGnDSy DBIuBZcXn+u+9uxbSnNqqEelGi9p2wuE8xDgPpIdGKGQgqFunukzrw/gBA9NyNrSBiVW cMtYpj09fCBzqpBTTtWUbWFXWxP8dUWWtvOAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=VOxKyhHWEZq881Tu1dRYZtpWRI0uS7+p7cJk9ulvTs1gTcK/3AgNrYK+dgFk98cHKn ZQNSDV7V0pV+YzTU1taUnQYxAaWbE6Hcbf+PwDtPgChbqHtqRWjLstq43AqTbPgaU/Ro BeRS+gN96wNDzpJ9OZImTM/XdK/1pEiMz/zaU= MIME-Version: 1.0 Received: by 10.204.49.88 with SMTP id u24mr743799bkf.44.1265789728313; Wed, 10 Feb 2010 00:15:28 -0800 (PST) Date: Wed, 10 Feb 2010 00:15:28 -0800 Message-ID: From: Gregory Lebovitz To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , Joe Touch Content-Type: multipart/alternative; boundary=000325556df21dd2d8047f3aa363 Cc: "tcpm@ietf.org" Subject: [tcpm] Wes's edits on tcp-ao-crypto-02 (was: Re: closing WGLC for 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: Wed, 10 Feb 2010 08:14:24 -0000 --000325556df21dd2d8047f3aa363 Content-Type: text/plain; charset=ISO-8859-1 Comments line. Joe, there is one in here for you, where we need to align our two docs. Pls take a quick look below and let me know what you think. Gregory On Tue, Dec 1, 2009 at 1:42 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: --snip-- > > On the AO crypto draft > ====================== > > 1) editorial, in abstract: > "algorithm(s)" -> "algorithms" ? > done > > 2) editorial, in Section 1: > "to TCP-AO [TCP-AO] [I-D.ietf-tcpm-tcp-auth-opt]." > -> > "to TCP-AO [I-D.ietf-tcpm-tcp-auth-opt]." > done > > 3) editorial, in Section 1: > "two key derivations functions" > -> > "two key derivation functions" > done > > 4) editorial, in section 2.2: > "Security Area Directors" > -> > "IETF Security Area Directors" > done > > 5) editorial/technical, in section 2.2: > "especially given that the tags are truncated to 96 bits" > -> > "even though the tags are truncated to 96 bits" > ??? > "especially" is correct. The point is that the SHA-1 output is longer than 96 bits, so it is saying that it is far more than even what is needed. > 6) editorial/technical, in section 2.2: > "aren't practical on SHA-1" > -> > "aren't practical on HMAC-SHA-1" > ??? > SHA-1 is fine here, because we are talking about comparison to the whole family, not simply its HMAC usage. > > 7) editorial, section 7.1: > I think you mean 3.2 of the -crypto doc, and 7.1 of the auth-opt doc, yeah? > use of Output_Length included here is not consistent with > the way that the main auth-opt draft defines this. > >From auth-opt-10, sect 7.1, it uses "Output" as the MAC result itself. Then below that it explains that "output-length" is different than "Output", that: "the output length, so no separate output length parameter is required. This is specified as described in [Le09 ]. " Having said that, I agree that using "Output" is confusing, because in auth-opt 7.1, "OUTPUT: MAC" and in tcp-ao-crypto sect 3.2 "Output" is an element of the definition of each MAC_alg's usage, specifically "Output: The final length of the bits used in the TCP-AO MAC field. This value may be a truncation of the MAC function's original output length." Proposed resolution (1): change auth-opt document, replace "Output" with "Result" in 7.1 another possible resolution (2) is to change -ao-crypto doc, sect 3.2, as follows: s/Output/MAC_Length/ I think (1) is more clear, because in -ao-crypto we use "Output_Length" to mean the KDF key output length, and it is an agrument to the interface of the algo, so that the counter knows if it needs to run more than once. EKR and I talked about this at length and think it best not to mix these two things up. Yet I hat to ask Joe to rev -auth-opt again just for this, so I could do (2) instead. Does that work for you, Joe? I'll rev my doc with (2) above, so we can get it out tonight. If people have issue, we can change it back during the next round of AD reviews. > 8) editorial, section 3.1.1: > "Each" > -> > "" > done > > 9) editorial, figure 1: > formatting of top line is off > > done Thanks again for the feedback, Gregory. > > -- > Wes Eddy > MTI Systems > > > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000325556df21dd2d8047f3aa363 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments line.=A0

Joe, there is one in here for you, where we = need to align our two docs. Pls take a quick look below and let me know wha= t you think.
Gregory

On Tue, Dec 1, 2= 009 at 1:42 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] <we= sley.m.eddy@nasa.gov> wrote:

--snip--

On the AO crypto draft
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1) editorial, in abstract:
"algorithm(s)" -> "algorithms" ?

done
=A0

2) editorial, in Section 1:
"to TCP-AO [TCP-AO] [I-D.ietf-tcpm-tcp-auth-opt]."
->
"to TCP-AO [I-D.ietf-tcpm-tcp-auth-opt]."
done=A0

3) editorial, in Section 1:
"two key derivations functions"
->
"two key derivation functions"

done=A0

4) editorial, in section 2.2:
"Security Area Directors"
->
"IETF Security Area Directors"

done
=A0

5) editorial/technical, in section 2.2:
"especially given that the tags are truncated to 96 bits"
->
"even though the tags are truncated to 96 bits"
???

"especially" is correct. = The point is that the SHA-1 output is longer than 96 bits, so it is saying = that it is far more than even what is needed.


6) editorial/technical, in section 2.2:
"aren't practical on SHA-1"
->
"aren't practical on HMAC-SHA-1"
???
=A0
SHA-1 is fine here, because we are t= alking about comparison to the whole family, not simply its HMAC usage.=A0<= /div>

=A0

7) editorial, section 7.1:

I think you = mean 3.2 of the -crypto doc, and 7.1 of the auth-opt doc, yeah?
= =A0
use of Output_Length included here is not consistent with
the way that the main auth-opt draft defines this.
From auth-opt-10, sect 7.1, it uses "Output" as the M= AC result itself. Then below that it explains that "output-length"= ; is different than "Output", that:

"the output length, so no separate output length paramet= er is required. This is specified as=A0described in [Le09].= =A0"
<= span style=3D"font-family:arial;white-space:normal;font-size:small">
<= span style=3D"font-family:arial;white-space:normal;font-size:small">Having = said that, I agree that using "Output" is confusing, because in a= uth-opt 7.1, "OUTPUT: MAC" and in tcp-ao-crypto sect 3.2 "Ou= tput" is an element of the definition of each MAC_alg's usage, spe= cifically "Output:=A0The final length of t= he bits used in the TCP-AO MAC field. This value may be a truncation of th= e MAC function's original output length."
<= span style=3D"font-family:arial;white-space:normal;font-size:small">
Proposed resolution (1):
change a= uth-opt document, replace "Output" with "Result" in 7.1=

another possible resolution (2) is to change -ao-= crypto doc, sect 3.2, as follows: =A0s/Output/MAC_Length/

I think (1) is more clear, because in -ao-crypto we use= "Output_Length" to mean the KDF key output length, and it is an = agrument to the interface of the algo, so that the counter knows if it need= s to run more than once. EKR and I talked about this at length and think it= best not to mix these two things up. Yet I hat to ask Joe to rev -auth-opt= again just for this, so I could do (2) instead.

=A0Does that work for you, Joe?

I'll rev my doc with (2) above, so we can get it out tonight. If peop= le have issue, we can change it back during the next round of AD reviews.


8) editorial, section 3.1.1:
"Each"
->
""

done
=A0

9) editorial, figure 1:
formatting of top line is off

done=A0

=
Thanks again for the feedback,
Gregory.

--
Wes Eddy
MTI Systems





--
----
IETF rel= ated email from
Gregory M. Lebovitz
Juniper Networks
--000325556df21dd2d8047f3aa363-- From gregory.ietf@gmail.com Wed Feb 10 00:52: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 B120F3A768D for ; Wed, 10 Feb 2010 00:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uLTgs4H9abN9 for ; Wed, 10 Feb 2010 00:52:28 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 1888B3A768B for ; Wed, 10 Feb 2010 00:52:27 -0800 (PST) Received: by bwz19 with SMTP id 19so1674352bwz.28 for ; Wed, 10 Feb 2010 00:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Lt1e0SwFMQxoJmCtIXAtgspWi7WK3Amkom6w5g/ASN0=; b=TF+4QHMjVZa3Et9IP4Z4VFrI/gk4YV+xGTv62b2G+dFDA8Egvg3o5aYZPJT9IbrMfo 8atr3YwWDx2ncLFyCdhHr3kwCqlMFhlN9yJJ4L5jiEXdt0JiAzxjSJQ7k6dSwGT6tInG RzcrRbLLvdrakuYe5W6mLinP+L4llf7E3frpg= 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=DYo/TJyZ/YC9B1MqPqff3pXTs7vomXn1ZRjEFr/OJRrLIjKS752XRXGStZTsZh66uV VKXD8Pu8+HFcVC87aa3/GS2uvIvvLoyG2ftaJG0XeUDTXTam6A8+s8D+H9T5JZzeHlKw DsnhBZsBwR+qQjIWHLy+BrvFp3MKGAwy6+Qjc= MIME-Version: 1.0 Received: by 10.204.5.140 with SMTP id 12mr2471828bkv.36.1265792014139; Wed, 10 Feb 2010 00:53:34 -0800 (PST) In-Reply-To: <2ACBDA51-146B-4E60-8656-2C96F1ADDEA0@cisco.com> References: <2ACBDA51-146B-4E60-8656-2C96F1ADDEA0@cisco.com> Date: Wed, 10 Feb 2010 00:53:34 -0800 Message-ID: From: Gregory Lebovitz To: Brian Weis Content-Type: multipart/alternative; boundary=0015175907dc5cc2c1047f3b2bac Cc: tcpm@ietf.org Subject: Re: [tcpm] Comments on draft-ietf-tcpm-tcp-ao-crypto-01 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, 10 Feb 2010 08:52:29 -0000 --0015175907dc5cc2c1047f3b2bac Content-Type: text/plain; charset=ISO-8859-1 Hey Brian, Thanks a ton for the very thoughtful review. Comments inline.. On Thu, Jan 14, 2010 at 9:49 AM, Brian Weis wrote: > Hi Gregory, > > In prototyping TCP-AO, I noticed the following relatively minor issues with > this draft, but not fixing them has interoperability consequences. > > 1. In order to have an interoperable KDF, the number of bytes for "i" (the > counter) and "Output_length" need to be defined. If one side hashes a 4 byte > value and the other a 1 byte value, the resulting KDF output will differ. I > suggest amending the text something similar to as follows: > > * In the description of "i", after the sentence "A counter, a binary > string that is an input to each > iteration of the PRF in counter mode." add the following sentence: "The > counter is represented in a single octet." > Yup. Great catch. In NIST SP-800-108, this is called "r" and it is a fixed value that must be indicated for a KDF in counter mode, and is defined as "The length of the binary representation of the counter i. " So I'll add your suggested text, with this minor modification: s/counter is/counter "i" is/ done. > * In the description of "Output_length" add a sentence after "The length > in bits of the key that the KDF will produce." add "The Output_length is > represented within two octets." > done. I'm hoping that 2 octets, or 65535 bits, as a max length is enough for a key length 10 or 20 years from now. If not, someone say so and we can change it during IETF last call. > I believe 255 iterations ought to be enough for an KDF, which is why I > suggest one octect for "i". Also, the overall length of key being produce > shouldn't be larger than 65535 bytes. It's length in *bits* not *bytes*, big difference. Still think 65535 bits is big enough to outlast the protocol's useful life on the wire? > If you're concerned with arbitrary limiting the size of the values for all > KDFs that might be defined in the future, you could instead make these > statements part of the definition of KDF_HMAC_SHA1 and KDF_AES_128_CMAC. I > doesn't matter to me, I just have observed that if everyone doesn't do it > the same way there are issues! > > 2. This example in Section 3.1.1 doesn't match SP 800-108: > > Traffic_Key = KDF_alg(Master_Key, 0 || Label || Context || > Output_length) || > KDF_alg(Master_Key, 1 || Label || Context || > Output_length) > > All of the KDFs in SP 800-108 start the counter at "1", not "0". I just read through SP 800-108 again, and you are 100% right, all the KDF examples have "for i = 1 to n". Excellent catch. Not sure where I got "0" from. > It would be very helpful to start the counter here at "1" as well. As one > data point, I could not use my general-purpose KDF that conforms with SP > 800-108 for TCP-AO, which was annoying. I also think this singly > inconsistency could easily lead to errors in implementations that don't > noticed the difference. > Agreed. In 3.1.1 I changed the example you showed above so that s/0/1/ and s/1/2/. I also changed and text in the paragraph ahead of it to match. Last, I added this text to the definition of "i": "i" always starts = 1 Thanks for catching these very small, but enormously imactful little bugs. Much appreciated. Look for -02 to publish shortly after this email is sent. Gregory. > Thanks, > Brian > > -- > Brian Weis > Router/Switch Security Group, ARTG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > > > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0015175907dc5cc2c1047f3b2bac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Brian,
Thanks a ton for the very thoughtful review. Comments inline= ..

On Thu, Jan 14, 2010 at 9:49 AM, Brian= Weis <bew@cisco.com<= /a>> wrote:
Hi Gregory,

In prototyping TCP-AO, I noticed the following relatively minor issues with= this draft, but not fixing them has interoperability consequences.

1. In order to have an interoperable KDF, the number of bytes for "i&q= uot; (the counter) and "Output_length" need to be defined. If one= side hashes a 4 byte value and the other a 1 byte value, the resulting KDF= output will differ. I suggest amending the text something similar to as fo= llows:

=A0* In the description of "i", after the sentence "A counte= r, a binary string that is an input to each
iteration of the PRF in counter mode." add the following sentence: &qu= ot;The counter is represented in a single octet."


So I'll add your suggested text, with this minor mo= dification:
=A0s/counter is/counter "i" is/
<= br>
done.


=A0* In the description of "Output_length" add a sentence after &= quot;The length in bits of the key that the KDF will produce." add &qu= ot;The Output_length is represented within two octets."

done.=A0
I'm hoping that 2 octets, or 655= 35 bits, as a max length is enough for a key length 10 or 20 years from now= . If not, someone say so and we can change it during IETF last call.=A0


I believe 255 iterations ought to be enough for an KDF, which is why I sugg= est one octect for "i". Also, the overall length of key being pro= duce shouldn't be larger than 65535 bytes.

It's length in *bits* not *bytes*, big difference. Still think 655= 35 bits is big enough to outlast the protocol's useful life on the wire= ?
=A0
If you're concerned with arbitrary limiting the size of the values for= all KDFs that might be defined in the future, you could instead make these= statements part of the definition of KDF_HMAC_SHA1 and KDF_AES_128_CMAC. I= doesn't matter to me, I just have observed that if everyone doesn'= t do it the same way there are issues!

2. This example in Section 3.1.1 doesn't match SP 800-108:

=A0 =A0 =A0 Traffic_Key =3D KDF_alg(Master_Key, 0 || Label || Context || O= utput_length) ||
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 KDF_alg(Master_Key, 1 || Label || = Context || Output_length)

All of the KDFs in SP 800-108 start the counter at "1", not "= ;0".

I just read through SP 800-108 ag= ain, and you are 100% right, all the KDF examples have "for i =3D 1 to= n". Excellent catch. Not sure where I got "0" from.=A0
=A0
It would be very helpful to = start the counter here at "1" as well. As one data point, I could= not use my general-purpose KDF that conforms with SP 800-108 for TCP-AO, w= hich was annoying. I also think this singly inconsistency could easily lead= to errors in implementations that don't noticed the difference.

Agreed. In 3.1.1 I changed the example you= showed above so that s/0/1/ and s/1/2/. I also changed and text in the par= agraph ahead of it to match. Last, I added this text to the definition of &= quot;i":
=A0=A0 "i" always starts =3D 1




--
----
IETF rel= ated email from
Gregory M. Lebovitz
Juniper Networks
--0015175907dc5cc2c1047f3b2bac-- From gregory.ietf@gmail.com Wed Feb 10 02:53:20 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 AD54928C11C for ; Wed, 10 Feb 2010 02:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 z9pkov-qD7GN for ; Wed, 10 Feb 2010 02:53:19 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 9254128C1D0 for ; Wed, 10 Feb 2010 02:53:19 -0800 (PST) Received: by bwz19 with SMTP id 19so1762613bwz.28 for ; Wed, 10 Feb 2010 02:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=PQUg/MJUTWUD9iyF32gnDUCzE/zlAswIViO4CoiCazw=; b=sE4kUH5seCWQLSSXP8CL8lLYzfVyPNt8yEmq8XD5GgfJFzRz7F1/AyyShyU5WuPLax gnN0NO7fgIEwWiroXhzg1ugirHuz6G8HyxrZRsvVX8gzhpZg3MBSV1CWFM2uKcDPSnQj 3WwWlFMrU28D33vJ9G91nRoHN5hQg1aDSHyDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=giI9bgJxH7VVIoiKqFEY9862Rvb3muILgiTtfdYGpI2GsqCB3VrG4TUxrFqXj6AgGE S+E1nNaGHVH5/yNmdUzQ/LZS8U4XYArLkBAbkTOzUwtY+MOlMe9jM126plVILtzvsp6r vYFyk7diM843Tc648elNHcyxogl6inXUqYmqI= MIME-Version: 1.0 Received: by 10.204.140.18 with SMTP id g18mr47197bku.47.1265799265968; Wed, 10 Feb 2010 02:54:25 -0800 (PST) Date: Wed, 10 Feb 2010 02:54:25 -0800 Message-ID: From: Gregory Lebovitz To: tcpm@ietf.org, "Eddy, Wesley M. (GRC-RCN0)[Verizon]" Content-Type: multipart/alternative; boundary=0015174c3b0e9ae181047f3cdb59 Cc: David Borman Subject: [tcpm] draft-ietf-tcpm-tcp-ao-crypto-02 posted 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, 10 Feb 2010 10:53:20 -0000 --0015174c3b0e9ae181047f3cdb59 Content-Type: text/plain; charset=ISO-8859-1 Team, The updated version, tcp-ao-crypto-02, is now posted. http://tools.ietf.org/html/draft-ietf-tcpm-tcp-ao-crypto-02 Let's get these documents rolling to IESG. Gregory. PS - xml2rfc is messed up right now. The Trust has released new boilerplates ahead of the tools team, AGAIN!! I had to manually hack the .txt and trial and error it for 2.5 hrs to get it to upload. ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Wed, Feb 10, 2010 at 2:45 AM Subject: New Version Notification for draft-ietf-tcpm-tcp-ao-crypto-02 To: gregory.ietf@gmail.com Cc: ekr@rtfm.com A new version of I-D, draft-ietf-tcpm-tcp-ao-crypto-02.txt has been successfuly submitted by Gregory Lebovitz and posted to the IETF repository. Filename: draft-ietf-tcpm-tcp-ao-crypto Revision: 02 Title: Cryptographic Algorithms for TCP's Authentication Option, TCP-AO Creation_date: 2010-02-10 WG ID: tcpm Number_of_pages: 19 Abstract: 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. The IETF Secretariat. -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0015174c3b0e9ae181047f3cdb59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Team,
The updated version, tcp-ao-crypto-02, is now posted.= =A0


Let's get these documents rolling to IESG.

Gregory.
PS - xml2rfc is messed up right now. T= he Trust has released new boilerplates ahead of the tools team, AGAIN!! I h= ad to manually hack the .txt and trial and error it for 2.5 hrs to get it t= o upload.=A0

---------- Forwarded message ----------
F= rom: IETF I-D Submission Tool <idsubmission@ietf.org= >
Date: Wed, Feb 10, 2010 at 2:45 AM
Subject: New Version Notification for= draft-ietf-tcpm-tcp-ao-crypto-02
To: gregory.ietf@gmail.com
Cc: e= kr@rtfm.com



A new version of I-D, draft-ietf-tcpm-tcp-ao-crypto-02.txt has been success= fuly submitted by Gregory Lebovitz and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-tcpm-tcp-ao-crypto
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Cryptographic Algorithms for TCP's Authentic= ation Option, TCP-AO
Creation_date: =A0 2010-02-10
WG ID: =A0 =A0 =A0 =A0 =A0 tcpm
Number_of_pages: 19

Abstract:
The TCP Authentication Option, TCP-AO, relies on security algorithms
to provide authentication between two end-points. =A0There are many
such algorithms available, and two TCP-AO systems cannot interoperate
unless they are using the same algorithms. =A0This document specifies
the algorithms and attributes that can be used in TCP-AO's current
manual keying mechanism.



The IETF Secretariat.





--
----
IETF related email from
G= regory M. Lebovitz
Juniper Networks
--0015174c3b0e9ae181047f3cdb59-- From root@core3.amsl.com Wed Feb 10 03:00:01 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 6D59D28C155; Wed, 10 Feb 2010 03:00:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100210110001.6D59D28C155@core3.amsl.com> Date: Wed, 10 Feb 2010 03:00:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-ao-crypto-02.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: Wed, 10 Feb 2010 11:00:01 -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 : Cryptographic Algorithms for TCP's Authentication Option, TCP-AO Author(s) : G. Lebovitz, E. Rescorla Filename : draft-ietf-tcpm-tcp-ao-crypto-02.txt Pages : 19 Date : 2010-02-10 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-ao-crypto-02.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-ao-crypto-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-10024535.I-D@ietf.org> --NextPart-- From wesley.m.eddy@nasa.gov Wed Feb 10 07:13: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 AEB033A756D for ; Wed, 10 Feb 2010 07:13:44 -0800 (PST) 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=[AWL=0.000, 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 TehS2M3QdXLt for ; Wed, 10 Feb 2010 07:13:44 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id EF13B3A6EDE for ; Wed, 10 Feb 2010 07:13:43 -0800 (PST) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 6AE32A8FA9 for ; Wed, 10 Feb 2010 09:14:53 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o1AFDjSL030730 for ; Wed, 10 Feb 2010 09:14:54 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Wed, 10 Feb 2010 09:14:29 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Wed, 10 Feb 2010 09:14:28 -0600 Thread-Topic: final check on AO docs Thread-Index: AcqqY7z46z67/jzJRBWVtacVQx4vBA== Message-ID: 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-02-10_11:2010-02-06, 2010-02-10, 2010-02-10 signatures=0 Subject: [tcpm] final check on AO docs 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, 10 Feb 2010 15:13:44 -0000 Now that the AO and AO-crypto drafts are updated, if the WG can take one last quick look to make sure that all WGLC issues have been resolved, we'll plan to send these to the IESG for publication next week: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-10.txt http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-ao-crypto-02.txt -- Wes Eddy MTI Systems From touch@ISI.EDU Wed Feb 10 08:18:12 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 0E33E3A7760 for ; Wed, 10 Feb 2010 08:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.700, 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 pfE7jTUOPvN8 for ; Wed, 10 Feb 2010 08:18:11 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 385C83A775E for ; Wed, 10 Feb 2010 08:18:11 -0800 (PST) Received: from [75.212.101.46] (46.sub-75-212-101.myvzw.com [75.212.101.46]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o1AGIAHF021392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Feb 2010 08:18:13 -0800 (PST) Message-ID: <4B72DC41.3050806@isi.edu> Date: Wed, 10 Feb 2010 08:18:09 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gregory Lebovitz References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig41FEC8961D66DDB2F2AA0E69" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Wes's edits on tcp-ao-crypto-02 (was: Re: closing WGLC for 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: Wed, 10 Feb 2010 16:18:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig41FEC8961D66DDB2F2AA0E69 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable See below. Gregory Lebovitz wrote: > Comments line.=20 >=20 > Joe, there is one in here for you, where we need to align our two docs.= > Pls take a quick look below and let me know what you think. =2E.. > 7) editorial, section 7.1: >=20 > I think you mean 3.2 of the -crypto doc, and 7.1 of the auth-opt doc, y= eah? > =20 > use of Output_Length included here is not consistent with > the way that the main auth-opt draft defines this. >=20 > From auth-opt-10, sect 7.1, it uses "Output" as the MAC result itself. > Then below that it explains that "output-length" is different than > "Output", that: >=20 > "the output length, so no separate output length parameter is required.= > This is specified as described in [Le09 > ].= " >=20 > Having said that, I agree that using "Output" is confusing, because in > auth-opt 7.1, "OUTPUT: MAC" and in tcp-ao-crypto sect 3.2 "Output" is a= n > element of the definition of each MAC_alg's usage, specifically > "Output: The final length of the bits used in the TCP-AO MAC field. Thi= s > value may be a truncation of the MAC function's original output length.= " >=20 > Proposed resolution (1): > change auth-opt document, replace "Output" with "Result" in 7.1 auth-opt uses the term "OUTPUT:" to label and describe the outputs of both the MAC (7.1) and traffic key algorithms (7.2). It's similarly already used in Fig 1 of ao-crypto. The term is used consistently throughout auth-opt as far as I can tell. > another possible resolution (2) is to change -ao-crypto doc, sect 3.2, > as follows: s/Output/MAC_Length/ I read ao-crypto, and the current version appears clear, and appears to use "output" in ways consistent with auth-opt now. IMO, I'd leave this as it currently stands. Joe --------------enig41FEC8961D66DDB2F2AA0E69 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) iEYEARECAAYFAkty3EEACgkQE5f5cImnZrtaVgCgiFr8MPZAJddR2tYEOFRlaoHV RmcAoOTO27GVcXXuR1NxU6F6KcGOGhKD =FivX -----END PGP SIGNATURE----- --------------enig41FEC8961D66DDB2F2AA0E69-- From wesley.m.eddy@nasa.gov Wed Feb 10 10:41: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 324AE3A73C0 for ; Wed, 10 Feb 2010 10:41:41 -0800 (PST) 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=[AWL=0.000, 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 TayNFFjMnr-I for ; Wed, 10 Feb 2010 10:41:40 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0F1F73A73B6 for ; Wed, 10 Feb 2010 10:41:39 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 2EB84D0011; Wed, 10 Feb 2010 12:42:50 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o1AIgoRs015909; Wed, 10 Feb 2010 12:42:50 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Wed, 10 Feb 2010 12:42:49 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: David Borman , Fernando Gont , "ayourtch@cisco.com" Date: Wed, 10 Feb 2010 12:42:49 -0600 Thread-Topic: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt Thread-Index: AcqmmtGeRjmFwy6KSmq7yuQ79ckQvgD42DSA Message-ID: References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> In-Reply-To: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.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-02-10_14:2010-02-06, 2010-02-10, 2010-02-10 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Wed, 10 Feb 2010 18:41:41 -0000 I concur with Michael's suggested edits, plus here are some more comments. Overall, I think it's in good shape and just about ready to publish. A minor update should be all that's needed, but I do want to make sure that one of the recommendations is worded correctly (see final comment below). Editorial: - section 1, paragraph 3: "IT accommodates" -> "it accommodates" ? - section 1, paragraph 3: "using urgent the urgent" -> "using the urgent" - section 1, paragraph 4: "how current TCP implementations" -> "how some current TCP implementations" - section 3.2, paragraph 1: "never reflected into" -> "never was reflected in" Semi-Technical: - section 2.3 - on the allowed length of urgent data, should this mention that obviously there is a limitation due to the length of a sequence number field? You can't send a terabyte of urgent data. - section 6: I think it's not worded correctly when we say that applications using the sockets API MUST set SO_OOBINLINE. What we really want to say is more like: "Even though applications SHOULD NOT employ the urgent mechanism, applications that require the use of urgent data MUST set SO_OOBINLINE." Right? Apps that don't use urgent data shouldn't have to be bothered by the fact that it's broken. -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >David Borman >Sent: Friday, February 05, 2010 2:38 PM >To: tcpm@ietf.org WG >Cc: tcpm-chairs@tools.ietf.org; ayourtch@cisco.com; Fernando Gont >Subject: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt > >Note: As recent discussions on this list have indicated, we need members >of this mailing list to be involved. Please take the time to read >through this document and send a message to the mailing list either >supporting publishing this document, or commenting on why it is not >ready to be published. This particular document is quite short and easy >to understand. -David Borman, TCPM co-chair. >---------------------------- > >This is to announce the start of the WG Last Call for: > >Title : On the implementation of the TCP urgent mechanism >Author(s) : F. Gont and A. Yourtchenko >Filename : draft-ietf-tcpm-urgent-data-02.txt >Pages : 13 >Date : November 26, 2009 >Intended Status : Proposed Standard > >http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-02.txt > >It is our understanding that all the feedback has been incorporated into >this latest version and that there are no known outstanding issues with >this document. > >Please send feedback to the list. > >The WGLC will end on Friday, February 19, 2010. >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From ananth@cisco.com Wed Feb 10 13:36: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 E40DD3A7607 for ; Wed, 10 Feb 2010 13:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 xzBpql9ZCEqP for ; Wed, 10 Feb 2010 13:36:42 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E6BB73A7283 for ; Wed, 10 Feb 2010 13:36:41 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,446,1262563200"; d="scan'208";a="86429005" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 10 Feb 2010 21:37:53 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o1ALbrku023078; Wed, 10 Feb 2010 21:37:54 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 13:37:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Feb 2010 13:37:52 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5808DC645E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt Thread-Index: AcqmmtGeRjmFwy6KSmq7yuQ79ckQvgD42DSAAAZAy7A= References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> From: "Anantha Ramaiah (ananth)" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , "David Borman" , "Fernando Gont" , "Andrew Yourtchenko (ayourtch)" X-OriginalArrivalTime: 10 Feb 2010 21:37:53.0740 (UTC) FILETIME=[4D51B8C0:01CAAA99] Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Wed, 10 Feb 2010 21:36:43 -0000 I had reviewed this document in the earlier versions, just a read again caught this and I am seeking clarification : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5. Advice to new applications employing TCP As a result of the issues discussed in Section 3.4, new applications SHOULD NOT employ the TCP urgent mechanism. However, TCP implementations MUST still include support for the urgent mechanism such that existing applications can still use it. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Why should we be even making this assertion : "new applications SHOULD NOT" employ urgent mechanism due to what is said in sec 3.4. The end-to-end semantics may get broken/altered due to many reasons and not just due to the middlebox fiddling with the URG flag/ptr. I guess my point is that why this document take pains in recommending something as a result of a middlebox behaviour. The best I have seen so far in documents with similar situation is to just mention that middlebox behaviour and leave it, do not make any recos based on the middlebox behaviour.=20 Makes sense? -Anantha PS:- I think this document is ready for LC and the above comment should not be construed in any way as to obstructing the document to its advancement to LC status. =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: Wednesday, February 10, 2010 10:43 AM > To: David Borman; Fernando Gont; Andrew Yourtchenko (ayourtch) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt >=20 > I concur with Michael's suggested edits, plus here are some=20 > more comments. Overall, I think it's in good shape and just=20 > about ready to publish. A minor update should be all that's=20 > needed, but I do want to make sure that one of the=20 > recommendations is worded correctly (see final comment below). >=20 > Editorial: >=20 > - section 1, paragraph 3: > "IT accommodates" -> "it accommodates" ? >=20 > - section 1, paragraph 3: > "using urgent the urgent" -> "using the urgent" >=20 > - section 1, paragraph 4: > "how current TCP implementations" -> > "how some current TCP implementations" >=20 >=20 > - section 3.2, paragraph 1: > "never reflected into" -> "never was reflected in" >=20 >=20 > Semi-Technical: >=20 > - section 2.3 - on the allowed length of urgent data, should this > mention that obviously there is a limitation due to the length > of a sequence number field? You can't send a terabyte of urgent > data. >=20 > - section 6: > I think it's not worded correctly when we say that applications > using the sockets API MUST set SO_OOBINLINE. What we really > want to say is more like: >=20 > "Even though applications SHOULD NOT employ the urgent mechanism, > applications that require the use of urgent data MUST set > SO_OOBINLINE." >=20 > Right? Apps that don't use urgent data shouldn't have to be > bothered by the fact that it's broken. >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 > >-----Original Message----- > >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org]=20 > On Behalf Of=20 > >David Borman > >Sent: Friday, February 05, 2010 2:38 PM > >To: tcpm@ietf.org WG > >Cc: tcpm-chairs@tools.ietf.org; ayourtch@cisco.com; Fernando Gont > >Subject: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt > > > >Note: As recent discussions on this list have indicated, we need=20 > >members of this mailing list to be involved. Please take=20 > the time to=20 > >read through this document and send a message to the mailing list=20 > >either supporting publishing this document, or commenting on=20 > why it is=20 > >not ready to be published. This particular document is=20 > quite short and=20 > >easy to understand. -David Borman, TCPM co-chair. > >---------------------------- > > > >This is to announce the start of the WG Last Call for: > > > >Title : On the implementation of the TCP urgent mechanism > >Author(s) : F. Gont and A. Yourtchenko > >Filename : draft-ietf-tcpm-urgent-data-02.txt > >Pages : 13 > >Date : November 26, 2009 > >Intended Status : Proposed Standard > > > >http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-da > ta-02.txt > > > >It is our understanding that all the feedback has been incorporated=20 > >into this latest version and that there are no known=20 > outstanding issues=20 > >with this document. > > > >Please send feedback to the list. > > > >The WGLC will end on Friday, February 19, 2010. > >_______________________________________________ > >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 >=20 From ayourtch@cisco.com Wed Feb 10 15:36: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 03C0B3A7572 for ; Wed, 10 Feb 2010 15:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 FHJ8aIQ9lV8t for ; Wed, 10 Feb 2010 15:36:56 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 958BE3A748E for ; Wed, 10 Feb 2010 15:36:56 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o1ANc3xI022308; Thu, 11 Feb 2010 00:38:03 +0100 (CET) Received: from ams-ayourtch-8716.cisco.com (ams-ayourtch-8716.cisco.com [10.55.144.247]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o1ANbvec009837; Thu, 11 Feb 2010 00:37:58 +0100 (CET) Date: Thu, 11 Feb 2010 00:37:56 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx.stdio.be To: "Anantha Ramaiah (ananth)" In-Reply-To: <0C53DCFB700D144284A584F54711EC5808DC645E@xmb-sjc-21c.amer.cisco.com> Message-ID: References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <0C53DCFB700D144284A584F54711EC5808DC645E@xmb-sjc-21c.amer.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: tcpm@ietf.org, David Borman , Fernando Gont Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 23:36:58 -0000 Hi Anantha, On Wed, 10 Feb 2010, Anantha Ramaiah (ananth) wrote: > > I had reviewed this document in the earlier versions, just a read again > caught this and I am seeking clarification : > > ============= > 5. Advice to new applications employing TCP > > As a result of the issues discussed in Section 3.4, new applications > SHOULD NOT employ the TCP urgent mechanism. However, TCP > implementations MUST still include support for the urgent mechanism > such that existing applications can still use it. > ================ > > Why should we be even making this assertion : "new applications SHOULD > NOT" employ urgent mechanism due to what is said in sec 3.4. The > end-to-end semantics may get broken/altered due to many reasons and not > just due to the middlebox fiddling with the URG flag/ptr. I guess my > point is that why this document take pains in recommending something as > a result of a middlebox behaviour. The best I have seen so far in > documents with similar situation is to just mention that middlebox > behaviour and leave it, do not make any recos based on the middlebox > behaviour. We should correct the "3.4" to "3" - i.e. not just middleboxes, but any stack that receives the TCP segment with URG flag, will not reliably know how exactly to treat it out of three possible interpretations - so any application that utilises this mechanism will be inherently very fragile. (An example is ABOR with FTP, which does not work correctly most of the time). thanks, andrew > > Makes sense? > > -Anantha > > PS:- I think this document is ready for LC and the above comment should > not be construed in any way as to obstructing the document to its > advancement to LC status. > > > > > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >> Sent: Wednesday, February 10, 2010 10:43 AM >> To: David Borman; Fernando Gont; Andrew Yourtchenko (ayourtch) >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt >> >> I concur with Michael's suggested edits, plus here are some >> more comments. Overall, I think it's in good shape and just >> about ready to publish. A minor update should be all that's >> needed, but I do want to make sure that one of the >> recommendations is worded correctly (see final comment below). >> >> Editorial: >> >> - section 1, paragraph 3: >> "IT accommodates" -> "it accommodates" ? >> >> - section 1, paragraph 3: >> "using urgent the urgent" -> "using the urgent" >> >> - section 1, paragraph 4: >> "how current TCP implementations" -> >> "how some current TCP implementations" >> >> >> - section 3.2, paragraph 1: >> "never reflected into" -> "never was reflected in" >> >> >> Semi-Technical: >> >> - section 2.3 - on the allowed length of urgent data, should this >> mention that obviously there is a limitation due to the length >> of a sequence number field? You can't send a terabyte of urgent >> data. >> >> - section 6: >> I think it's not worded correctly when we say that applications >> using the sockets API MUST set SO_OOBINLINE. What we really >> want to say is more like: >> >> "Even though applications SHOULD NOT employ the urgent mechanism, >> applications that require the use of urgent data MUST set >> SO_OOBINLINE." >> >> Right? Apps that don't use urgent data shouldn't have to be >> bothered by the fact that it's broken. >> >> -- >> Wes Eddy >> MTI Systems >> >> >>> -----Original Message----- >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] >> On Behalf Of >>> David Borman >>> Sent: Friday, February 05, 2010 2:38 PM >>> To: tcpm@ietf.org WG >>> Cc: tcpm-chairs@tools.ietf.org; ayourtch@cisco.com; Fernando Gont >>> Subject: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt >>> >>> Note: As recent discussions on this list have indicated, we need >>> members of this mailing list to be involved. Please take >> the time to >>> read through this document and send a message to the mailing list >>> either supporting publishing this document, or commenting on >> why it is >>> not ready to be published. This particular document is >> quite short and >>> easy to understand. -David Borman, TCPM co-chair. >>> ---------------------------- >>> >>> This is to announce the start of the WG Last Call for: >>> >>> Title : On the implementation of the TCP urgent mechanism >>> Author(s) : F. Gont and A. Yourtchenko >>> Filename : draft-ietf-tcpm-urgent-data-02.txt >>> Pages : 13 >>> Date : November 26, 2009 >>> Intended Status : Proposed Standard >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-da >> ta-02.txt >>> >>> It is our understanding that all the feedback has been incorporated >>> into this latest version and that there are no known >> outstanding issues >>> with this document. >>> >>> Please send feedback to the list. >>> >>> The WGLC will end on Friday, February 19, 2010. >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@ISI.EDU Thu Feb 11 08:51: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 270A028C1FE for ; Thu, 11 Feb 2010 08:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 UPyInoc-2s8q for ; Thu, 11 Feb 2010 08:51:52 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 68C8628C1FC for ; Thu, 11 Feb 2010 08:51:52 -0800 (PST) Received: from [192.168.1.95] (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 o1BGpNxQ022718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Feb 2010 08:51:25 -0800 (PST) Message-ID: <4B74358B.90804@isi.edu> Date: Thu, 11 Feb 2010 08:51:23 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mallman@icir.org References: <20100211164333.7C61C86FAA1@lawyers.icir.org> In-Reply-To: <20100211164333.7C61C86FAA1@lawyers.icir.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6CDCDA25E0850A555368EC4A" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Kacheong Poon , Michael Welzl Subject: Re: [tcpm] TCP tuning 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, 11 Feb 2010 16:51:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6CDCDA25E0850A555368EC4A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: >> Making TCP smarter is fine; doing so at the expense of robustness is >> not.=20 >=20 > I'll agree with this and push back at the same time. I agree that > robustness is important and should be protected. However, I have > increasingly come to view things like initial RTOs and initial cwnds, > and etc. as not buying us much robustness. What buys us robustness is > the reaction---any reaction---to indications there might be problems. > These gross notions are more important than any small parameter change > it seems to me. I agree that changes to initial parameters are much less important than the convergence/reaction mechanism that governs them afterwards - today. That's because of the paradox that most of the connections are short, but most of the bytes belong to long connections. We do need to be careful that whatever we do doesn't overwhelm these assumptions and change the game, however. Regarding init cwnds, I'd like to see a reasonable level of analysis of the impact. It's not enough to drive discussions with "we have to RIGHT NOW!" to satisfy a (often underinformed) perception of need. Joe --------------enig6CDCDA25E0850A555368EC4A 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) iEYEARECAAYFAkt0NYsACgkQE5f5cImnZrtK7ACeO6/trdPu7K+Ze7Rza64YIpiR RnUAnRxAhL0hZaE0O8S3J1AwspYwYffn =SWGs -----END PGP SIGNATURE----- --------------enig6CDCDA25E0850A555368EC4A-- From mike@belshe.com Thu Feb 11 18:19: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 42CE03A7425 for ; Thu, 11 Feb 2010 18:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rrqFmpG6qjU8 for ; Thu, 11 Feb 2010 18:19:53 -0800 (PST) Received: from mail-px0-f178.google.com (mail-px0-f178.google.com [209.85.216.178]) by core3.amsl.com (Postfix) with ESMTP id 2F7063A6842 for ; Thu, 11 Feb 2010 18:19:53 -0800 (PST) Received: by pxi8 with SMTP id 8so1237033pxi.19 for ; Thu, 11 Feb 2010 18:21:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.248.36 with SMTP id v36mr476793wfh.228.1265941266529; Thu, 11 Feb 2010 18:21:06 -0800 (PST) In-Reply-To: <4B74358B.90804@isi.edu> References: <20100211164333.7C61C86FAA1@lawyers.icir.org> <4B74358B.90804@isi.edu> Date: Thu, 11 Feb 2010 18:21:06 -0800 Message-ID: <2a10ed241002111821x97a1f56l20732f70a22d8213@mail.gmail.com> From: Mike Belshe To: Joe Touch Content-Type: multipart/alternative; boundary=00504502c5807f7f5a047f5deb71 Cc: tcpm@ietf.org, Kacheong Poon , Michael Welzl , mallman@icir.org Subject: Re: [tcpm] TCP tuning 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, 12 Feb 2010 02:19:54 -0000 --00504502c5807f7f5a047f5deb71 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 11, 2010 at 8:51 AM, Joe Touch wrote: > > > Mark Allman wrote: > >> Making TCP smarter is fine; doing so at the expense of robustness is > >> not. > > > > I'll agree with this and push back at the same time. I agree that > > robustness is important and should be protected. However, I have > > increasingly come to view things like initial RTOs and initial cwnds, > > and etc. as not buying us much robustness. What buys us robustness is > > the reaction---any reaction---to indications there might be problems. > > These gross notions are more important than any small parameter change > > it seems to me. > > I agree that changes to initial parameters are much less important than > the convergence/reaction mechanism that governs them afterwards - today. > That's because of the paradox that most of the connections are short, > but most of the bytes belong to long connections. > > We do need to be careful that whatever we do doesn't overwhelm these > assumptions and change the game, however. > > Regarding init cwnds, I'd like to see a reasonable level of analysis of > the impact. It's not enough to drive discussions with "we have to RIGHT > NOW!" to satisfy a (often underinformed) perception of need. > Has anyone, on this list or otherwise, suggested that we should change these items "RIGHT NOW" or without a "reasonable level of analysis"? I think we'd all be better served to stipulate that everyone on this list wants to help make smart improvements and stop implying otherwise. Mike > Joe > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --00504502c5807f7f5a047f5deb71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 11, 2010 at 8:51 AM, Joe Tou= ch <touch@isi.edu= > wrote:


Mark Allman wrote:
>> Making TCP smarter is fine; doing so at the expense of robustness = is
>> not.
>
> I'll agree with this and push back at the same time. =A0I agree th= at
> robustness is important and should be protected. =A0However, I have > increasingly come to view things like initial RTOs and initial cwnds,<= br> > and etc. as not buying us much robustness. =A0What buys us robustness = is
> the reaction---any reaction---to indications there might be problems.<= br> > These gross notions are more important than any small parameter change=
> it seems to me.

I agree that changes to initial parameters are much less important than
the convergence/reaction mechanism that governs them afterwards - today. That's because of the paradox that most of the connections are short, but most of the bytes belong to long connections.

We do need to be careful that whatever we do doesn't overwhelm these assumptions and change the game, however.

Regarding init cwnds, I'd like to see a reasonable level of analysis of=
the impact. It's not enough to drive discussions with "we have to = RIGHT
NOW!" to satisfy a (often underinformed) perception of need.

Has anyone, on this list or otherwise, suggested= that we should change these items "RIGHT NOW" or without a "= ;reasonable level of analysis"?

I think we'd all be better served to stipulate that= everyone on this list wants to help make smart improvements and stop imply= ing otherwise.

Mike



Joe


_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm


--00504502c5807f7f5a047f5deb71-- From touch@ISI.EDU Thu Feb 11 18:30: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 8FE2F3A763B for ; Thu, 11 Feb 2010 18:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 ydPQRTMwEpO8 for ; Thu, 11 Feb 2010 18:30:11 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A845E3A7789 for ; Thu, 11 Feb 2010 18:30:10 -0800 (PST) Received: from [192.168.1.95] (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 o1C2ULO9020236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Feb 2010 18:30:23 -0800 (PST) Message-ID: <4B74BD3D.8020407@isi.edu> Date: Thu, 11 Feb 2010 18:30:21 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mike Belshe References: <20100211164333.7C61C86FAA1@lawyers.icir.org> <4B74358B.90804@isi.edu> <2a10ed241002111821x97a1f56l20732f70a22d8213@mail.gmail.com> In-Reply-To: <2a10ed241002111821x97a1f56l20732f70a22d8213@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1B32688369C6715761C215E9" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Kacheong Poon , Michael Welzl , mallman@icir.org Subject: Re: [tcpm] TCP tuning 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, 12 Feb 2010 02:30:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B32688369C6715761C215E9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mike Belshe wrote: =2E.. > Has anyone, on this list or otherwise, suggested that we should change > these items "RIGHT NOW" or without a "reasonable level of analysis"? Yes. I'm referring specifically to the recent discussions on this list, which suggested that either this was urgent (the "right now" part) or that this didn't need analysis ("it's out in the wild") Joe --------------enig1B32688369C6715761C215E9 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) iEYEARECAAYFAkt0vT0ACgkQE5f5cImnZruM4ACfZknUSyFVPP3R4u7WsdAKqXDD WaAAn0vzVaI4F6PbjKvchAjWIGWYfiTt =Q8Rx -----END PGP SIGNATURE----- --------------enig1B32688369C6715761C215E9-- From fernando@gont.com.ar Thu Feb 11 19:43: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 E795828C0FA for ; Thu, 11 Feb 2010 19:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.013 X-Spam-Level: X-Spam-Status: No, score=-3.013 tagged_above=-999 required=5 tests=[AWL=0.587, 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 2Yd1wnCD8MBk for ; Thu, 11 Feb 2010 19:43:31 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 8728028C0EA for ; Thu, 11 Feb 2010 19:43:29 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5ABD46B66EB; Fri, 12 Feb 2010 00:44:49 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1C3idc4032164; Fri, 12 Feb 2010 00:44:41 -0300 Message-ID: <4B74CEA5.2050206@gont.com.ar> Date: Fri, 12 Feb 2010 00:44:37 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Welzl References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <61FBA2BB-0432-4556-A2CA-6659B0E1D8E1@ifi.uio.no> In-Reply-To: <61FBA2BB-0432-4556-A2CA-6659B0E1D8E1@ifi.uio.no> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 12 Feb 2010 00:44:48 -0300 (ART) Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org WG" , David Borman , ayourtch@cisco.com Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Fri, 12 Feb 2010 03:43:32 -0000 Hi, Thanks so much for your feedback! Comments inline.... > It seems a bit pointless to repeat the same text in the introduction and > in section 2.1 - in > the first paragraph of the introduction, the part that starts with: > "permits a point in the data > stream to be designated .... " and ends with: "the TCP must tell user to > go into "normal mode" " > (which, by the way, misses a "the" before "user".) > > I think that this part could safely be removed from the introduction and > just kept in section 2.1, > and the reference at the end of the first paragraph should then be moved > there too. Should I move/collapse the first two paragraphs of Section 1 (Intorduction) to/into Section 2.1? > Section 3.4: > "As a result of the publication of Network Intrusion Detection (NIDs) > evasion techniques based on > TCP urgent indications [phrack], some middle-boxes clear the urgent > indications by clearing the > URG flag and setting the Urgent Pointer to zero." > > => are you 100% sure that this is the result of the publication of these > techniques? Otherwise I'd rather state this with "perhaps". Yes. The source was an inside man. ;-) (FWIW, *me*, I thought it was a result of the infamous windows OOB nuke, but it seems it wasn't the case). > a bit further down: > "Examples of such middle-boxes are Cisco PIX firewall [Cisco-PIX]." > > should be "An example of such a middle-box is the ..." Will fix this. > next sentence: > "This should discourage applications to depend" > => > "This should discourage applications from depending" > (I think - I'm not a native speaker myself) On second read (from me, a non-native English speaker), your text sounds better. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando@gont.com.ar Thu Feb 11 19:52: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 BB25F28C0FA for ; Thu, 11 Feb 2010 19:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=0.556, 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 QvRrLMz-Q1Av for ; Thu, 11 Feb 2010 19:52:39 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 6ED003A74C1 for ; Thu, 11 Feb 2010 19:52:38 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 0E9DC6B65DD; Fri, 12 Feb 2010 00:54:00 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1C3roND001902; Fri, 12 Feb 2010 00:53:51 -0300 Message-ID: <4B74D0CB.5000001@gont.com.ar> Date: Fri, 12 Feb 2010 00:53:47 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 12 Feb 2010 00:53:59 -0300 (ART) Cc: "tcpm@ietf.org" , "ayourtch@cisco.com" , David Borman Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Fri, 12 Feb 2010 03:52:40 -0000 Hello, Wes, Thanks so much for your feedback. COmments in-line.... > Editorial: > > - section 1, paragraph 3: > "IT accommodates" -> "it accommodates" ? Fixed. > - section 1, paragraph 3: > "using urgent the urgent" -> "using the urgent" Thanks :-) > - section 1, paragraph 4: > "how current TCP implementations" -> > "how some current TCP implementations" "how some popular TCP implementations"? (i.e., yes, they are not "all"... but we assessed Linux, BSD's, Cisco, MS...) > - section 3.2, paragraph 1: > "never reflected into" -> "never was reflected in" Fixed. > Semi-Technical: > > - section 2.3 - on the allowed length of urgent data, should this > mention that obviously there is a limitation due to the length > of a sequence number field? You can't send a terabyte of urgent > data. Well, you cannot send a terabyte of normal data, either. :-) I see your point, though... Here we just mentioned what was there in RFC 1122... I think the spirit of the text in RFC 1122 is that the mechanism (flag + pointer) should not limit the amount of urgent data that you can send... (although, as dicussed on the list some time ago, the concept of "urgent data" is flawed. It's more of a "mark of an interesting point in the data stream") > - section 6: > I think it's not worded correctly when we say that applications > using the sockets API MUST set SO_OOBINLINE. What we really > want to say is more like: > > "Even though applications SHOULD NOT employ the urgent mechanism, > applications that require the use of urgent data MUST set > SO_OOBINLINE." > > Right? Apps that don't use urgent data shouldn't have to be > bothered by the fact that it's broken. I fully agree. Thanks for catching this one! Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From david.borman@windriver.com Fri Feb 12 11: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 C27D53A776A for ; Fri, 12 Feb 2010 11:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 kxkKoupWTfIC for ; Fri, 12 Feb 2010 11:22:22 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id B02AD28C1D1 for ; Fri, 12 Feb 2010 11:22:22 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o1CJNbJZ012068; Fri, 12 Feb 2010 11:23:37 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Feb 2010 11:23:37 -0800 Received: from [172.25.44.4] ([172.25.44.4]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Feb 2010 11:23:36 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <4B74D0CB.5000001@gont.com.ar> Date: Fri, 12 Feb 2010 13:23:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <74BB811B-A6CE-404D-A38D-986DC189A9D2@windriver.com> References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <4B74D0CB.5000001@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1077) X-OriginalArrivalTime: 12 Feb 2010 19:23:36.0934 (UTC) FILETIME=[DFEA3060:01CAAC18] Cc: "tcpm@ietf.org" , "ayourtch@cisco.com" Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Fri, 12 Feb 2010 19:22:23 -0000 Fernando and Wes, On Feb 11, 2010, at 9:53 PM, Fernando Gont wrote: > Hello, Wes, >=20 > Thanks so much for your feedback. COmments in-line.... ... >> Semi-Technical: >>=20 >> - section 2.3 - on the allowed length of urgent data, should this >> mention that obviously there is a limitation due to the length >> of a sequence number field? You can't send a terabyte of urgent >> data. >=20 > Well, you cannot send a terabyte of normal data, either. :-) >=20 > I see your point, though... Here we just mentioned what was there in = RFC > 1122... >=20 > I think the spirit of the text in RFC 1122 is that the mechanism (flag = + > pointer) should not limit the amount of urgent data that you can = send... > (although, as dicussed on the list some time ago, the concept of = "urgent > data" is flawed. It's more of a "mark of an interesting point in the > data stream") Ah, you can do both over a TCP connection: send a terabyte of normal = data, and send a terabyte of urgent data. The urgent date is all the = data before the urgent pointer. So, just as TCP cycles through the = sequence space to send a terabyte of normal data, so too it would cycle = through to send everything in urgent mode. Since there is only one = urgent pointer that gets updated with each new packet, as long as the = urgent pointer points beyond the end of the data in any given packet, = the TCP connection will remain in urgent mode until it gets to the end = of the terabyte of data. :-) This is the technique documented in RFC = 2675 "IPv6 Jumbograms", section 5.2. So, there is no limit on how much data you can send while in urgent = mode, from either the application or TCP point of view. -David Borman From wesley.m.eddy@nasa.gov Fri Feb 12 12:19: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 D1CC63A78F7 for ; Fri, 12 Feb 2010 12:19:28 -0800 (PST) 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=[AWL=0.000, 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 QPOFHLwD1fR9 for ; Fri, 12 Feb 2010 12:19:26 -0800 (PST) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 7784F3A78F6 for ; Fri, 12 Feb 2010 12:19:26 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 9AC0E2613ED; Fri, 12 Feb 2010 14:20:44 -0600 (CST) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o1CKKjgk018556; Fri, 12 Feb 2010 14:20:45 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Fri, 12 Feb 2010 14:20:44 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: David Borman , Fernando Gont Date: Fri, 12 Feb 2010 14:20:42 -0600 Thread-Topic: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt Thread-Index: AcqsGOOVMlLQGlKlQdyETAI/Y0VjtAAB3nvA Message-ID: References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <4B74D0CB.5000001@gont.com.ar> <74BB811B-A6CE-404D-A38D-986DC189A9D2@windriver.com> In-Reply-To: <74BB811B-A6CE-404D-A38D-986DC189A9D2@windriver.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-02-12_03:2010-02-06, 2010-02-12, 2010-02-12 signatures=0 Cc: "tcpm@ietf.org" , "ayourtch@cisco.com" Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Fri, 12 Feb 2010 20:19:29 -0000 >-----Original Message----- >From: David Borman [mailto:david.borman@windriver.com] >Sent: Friday, February 12, 2010 2:24 PM >To: Fernando Gont >Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; ayourtch@cisco.com; >tcpm@ietf.org >Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt > > ... > >So, there is no limit on how much data you can send while in urgent >mode, from either the application or TCP point of view. > Agreed; I think we can disregard my WGLC comment on this; I hadn't considered the ability to move the pointer as the sequence space is cycled through. -- Wes Eddy MTI Systems From fernando@gont.com.ar Fri Feb 12 13:30:30 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 D171A28C279 for ; Fri, 12 Feb 2010 13:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.071 X-Spam-Level: X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=0.528, 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 m2uXaVdiHMSd for ; Fri, 12 Feb 2010 13:30:29 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 75DDD28C22D for ; Fri, 12 Feb 2010 13:30:28 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id CA1E16B6AC9; Fri, 12 Feb 2010 18:31:50 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1CLVgui026340; Fri, 12 Feb 2010 18:31:43 -0300 Message-ID: <4B75C8BA.4060204@gont.com.ar> Date: Fri, 12 Feb 2010 18:31:38 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Borman References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <4B74D0CB.5000001@gont.com.ar> <74BB811B-A6CE-404D-A38D-986DC189A9D2@windriver.com> In-Reply-To: <74BB811B-A6CE-404D-A38D-986DC189A9D2@windriver.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 12 Feb 2010 18:31:48 -0300 (ART) Cc: "tcpm@ietf.org" , "ayourtch@cisco.com" Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Fri, 12 Feb 2010 21:30:30 -0000 David, >> I think the spirit of the text in RFC 1122 is that the mechanism >> (flag + pointer) should not limit the amount of urgent data that >> you can send... (although, as dicussed on the list some time ago, >> the concept of "urgent data" is flawed. It's more of a "mark of an >> interesting point in the data stream") > > Ah, you can do both over a TCP connection: send a terabyte of normal > data, and send a terabyte of urgent data. The urgent date is all the > data before the urgent pointer. So, just as TCP cycles through the > sequence space to send a terabyte of normal data, so too it would > cycle through to send everything in urgent mode. Since there is only > one urgent pointer that gets updated with each new packet, as long as > the urgent pointer points beyond the end of the data in any given > packet, the TCP connection will remain in urgent mode until it gets > to the end of the terabyte of data. :-) This is the technique > documented in RFC 2675 "IPv6 Jumbograms", section 5.2. > > So, there is no limit on how much data you can send while in urgent > mode, from either the application or TCP point of view. I was referring to the fact that there's a limit on the amount of data you can send as a result of the size of the Sequence Number field, the TCP window, etc. (i.e., you cannot simply send "any amount of data" without taking care of the sequence numbers wrapping before you get the relevant acks, etc.). I thought *this* was what Wesley was referring to, rather than that of whether it was possible or not to move the UP. Anyway, issue solved, it seems. :-) Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando@gont.com.ar Fri Feb 12 13:32: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 C572428C204 for ; Fri, 12 Feb 2010 13:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.096 X-Spam-Level: X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[AWL=0.503, 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 Tm5x7wjHZmlA for ; Fri, 12 Feb 2010 13:32:50 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 7401B28C281 for ; Fri, 12 Feb 2010 13:32:48 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D79EF6B6B18; Fri, 12 Feb 2010 18:34:11 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1CLY5Z5026731; Fri, 12 Feb 2010 18:34:06 -0300 Message-ID: <4B75C94A.6030907@gont.com.ar> Date: Fri, 12 Feb 2010 18:34:02 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <0C53DCFB700D144284A584F54711EC5808DC645E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5808DC645E@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 12 Feb 2010 18:34:11 -0300 (ART) Cc: tcpm@ietf.org, "Andrew Yourtchenko \(ayourtch\)" , David Borman Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Fri, 12 Feb 2010 21:32:52 -0000 Hello, Anantha, Thanks so much for your feedback. Comments inline.... > Why should we be even making this assertion : "new applications SHOULD > NOT" employ urgent mechanism due to what is said in sec 3.4. The > end-to-end semantics may get broken/altered due to many reasons and not > just due to the middlebox fiddling with the URG flag/ptr. I guess my > point is that why this document take pains in recommending something as > a result of a middlebox behaviour. The best I have seen so far in > documents with similar situation is to just mention that middlebox > behaviour and leave it, do not make any recos based on the middlebox > behaviour. > > Makes sense? The recommendation is based on everything: both the different possible semantics of the UP, and the fact that it's not reliable anymore (due to middle-boxes). Should we clarify this? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From hallam@gmail.com Fri Feb 12 18:26: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 D74E928C263; Fri, 12 Feb 2010 18:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 M4ug-1eXejsy; Fri, 12 Feb 2010 18:26:31 -0800 (PST) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id 3505E28C133; Fri, 12 Feb 2010 18:26:31 -0800 (PST) Received: by pzk5 with SMTP id 5so4689467pzk.29 for ; Fri, 12 Feb 2010 18:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=qQ6bEIjBci1YZ1sOYi8n+vkHY5qL/xkr9QV6t6Vp8Ig=; b=FMGSJBEeVKgbwEdLC4YaEkJivSu12QKM0o73DfewS0Vp7AblFuVyfRzLKJwKSk3Yqh KCBWGTWQFXDG11aE3AzFdJD/z0DIiTdsKGEkHMnPeHcK7mVM5K6h7dKpS7NWryNJ10/A wsdCZpTchVeB26rZa2Ne+A6BY5bq332b3lI0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TukWgUiZY/LQg9PKFD/rSnNEhVY96OHV6C46BSX2JSQS5guawqFjv0E7hHHtrtetLS bbyKTSer2ecgp5paS8Nq4AXP/sbaU5yVydzG27o6uCbnD3T0xzXjw9+fS11AUgX56S45 RHVCKv4gYvEPoVDMyUjs+xwAFMq2Y4QcudB0g= MIME-Version: 1.0 Received: by 10.115.2.20 with SMTP id e20mr1529649wai.50.1266028069451; Fri, 12 Feb 2010 18:27:49 -0800 (PST) Date: Fri, 12 Feb 2010 21:27:49 -0500 Message-ID: From: Phillip Hallam-Baker To: secdir@ietf.org, fernando@gont.com.ar, tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 13 Feb 2010 19:48:19 -0800 Subject: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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: Sat, 13 Feb 2010 02:26:33 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. ICMP is one of those IP layer protocols that we all have some idea exist even if only the network level people understand what they do. This document is designed to describe security issues arising from the ICMP protocol and commonly implemented counter-measures. The principal security risks considered are service risks. ICMP may be used to perform certain denial of service and performance downgrade attacks. As such it probably needs rather more justification than 'we have always done this' when building critical infrastructures. Overall, Given that TCP streams will eventually time-out, I have something of a hard time seeing why we would be using a non-authenticated control protocol at all. Yes, I know the legacy reasons etc. etc. But this is not the way we would approach this problem today. This argument is almost made on page 15. Some statement giving the case for taking notice of ICMP messages at all is in order. It might well be that an appropriate control in certain cases would be to turn off ICMP hard errors and rely on timeouts, I am thinking here of critical infrastructure applications and communications between hosts running BGP functions. In particular I note that the draft says "It is interesting to note that, as ICMP error messages are transmitted unreliably, transport protocols should not depend on them for correct functioning." Given the extreme approach to security of starting from nothing and only adding systems that are essential, this would seem to suggest ICMP is not necessary and could be eliminated. There may be a case to the contrary but it needs to be made before page 15. Page 15/16 The following phrase repeats in a way that suggests an editing oversight: aborting the connection would be to ignore the valuable feature of the Internet that for many internal failures it reconstructs its function without any disruption of the end points Page 24-26 A more general way of describing the mitigation strategy would be to point out the general principle that error messages may be ignored whenever a packet indicating success is received within the timeout window. In other words no final processing decisions should be made on an unauthenticated ICMP packet until after the timeout window expires. -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From lars.eggert@nokia.com Mon Feb 15 00:18:56 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 295A23A7AC4; Mon, 15 Feb 2010 00:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 pKbPBZIl-VNU; Mon, 15 Feb 2010 00:18:54 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AACA43A7AC3; Mon, 15 Feb 2010 00:18:54 -0800 (PST) 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 o1F8Isvr003423; Mon, 15 Feb 2010 02:19:28 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Feb 2010 10:18:57 +0200 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.3959); Mon, 15 Feb 2010 10:18:48 +0200 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 o1F8IkJf002840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Feb 2010 10:18:47 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-1-151906251; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Mon, 15 Feb 2010 10:18:34 +0200 Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 15 Feb 2010 10:18:36 +0200 (EET) X-OriginalArrivalTime: 15 Feb 2010 08:18:48.0662 (UTC) FILETIME=[7FE42760:01CAAE17] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" , "fernando@gont.com.ar" , "secdir@ietf.org" Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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, 15 Feb 2010 08:18:56 -0000 --Apple-Mail-1-151906251 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, authors/WG, please discuss the secdir review. I'll leave the document on the IESG = agenda for Thursday for now. Lars On 2010-2-13, at 4:27, Phillip Hallam-Baker wrote: > Hi, >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > ICMP is one of those IP layer protocols that we all have some idea > exist even if only the network level people understand what they do. > This document is designed to describe security issues arising from the > ICMP protocol and commonly implemented counter-measures. >=20 > The principal security risks considered are service risks. ICMP may be > used to perform certain denial of service and performance downgrade > attacks. As such it probably needs rather more justification than 'we > have always done this' when building critical infrastructures. >=20 >=20 > Overall, >=20 > Given that TCP streams will eventually time-out, I have something of a > hard time seeing why we would be using a non-authenticated control > protocol at all. Yes, I know the legacy reasons etc. etc. But this is > not the way we would approach this problem today. This argument is > almost made on page 15. Some statement giving the case for taking > notice of ICMP messages at all is in order. It might well be that an > appropriate control in certain cases would be to turn off ICMP hard > errors and rely on timeouts, I am thinking here of critical > infrastructure applications and communications between hosts running > BGP functions. >=20 > In particular I note that the draft says "It is interesting to note > that, as ICMP error messages are transmitted unreliably, transport > protocols should not depend on them for correct functioning." >=20 > Given the extreme approach to security of starting from nothing and > only adding systems that are essential, this would seem to suggest > ICMP is not necessary and could be eliminated. There may be a case to > the contrary but it needs to be made before page 15. >=20 >=20 > Page 15/16 >=20 > The following phrase repeats in a way that suggests an editing = oversight: > aborting the > connection would be to ignore the valuable feature of the Internet > that for many internal failures it reconstructs its function without > any disruption of the end points >=20 > Page 24-26 >=20 > A more general way of describing the mitigation strategy would be to > point out the general principle that error messages may be ignored > whenever a packet indicating success is received within the timeout > window. In other words no final processing decisions should be made on > an unauthenticated ICMP packet until after the timeout window expires. >=20 >=20 > --=20 > --=20 > New Website: http://hallambaker.com/ > View Quantum of Stupid podcasts, Tuesday and Thursday each week, > http://quantumofstupid.com/ > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-1-151906251 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 MQ8XDTEwMDIxNTA4MTgzNVowIwYJKoZIhvcNAQkEMRYEFGRqfNZxsPXSd8R905aQjDbIQZoYMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDB29zWeJcgtYF9NqBvol5gBipICjaqcYJE5xGbSrPpw30T8ZFw2qjXXtNqlFbGH/j/lzHD Hzo4tR/PsRM+OQalt/+uHU4VAWkL76FoQA4etf4Y6sVlYujMKszQPyD4W+9+vFUT63OjXW9ieev7 O0vyofJbZiDqHVuH7F+G9JspvJtMq/aWjzEV0hDJ9ZQplsM8wMOmG+p1dWeJDT7ZHK/+Q3gMwCVy Y5nhddlElEGCc4KGc/Q4fCQzTHEEmxCx625GDADU8K3Qx5ziy75Vz3VqwBT3ffYyLhoDbdw1EPXx wL3ZTHWb6Lczz5eSK3kjdMTfu1yL1nUQrOD/E8yLzjDrAAAAAAAA --Apple-Mail-1-151906251-- From fernando@gont.com.ar Mon Feb 15 11:48:12 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 48E4D3A7374; Mon, 15 Feb 2010 11:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=0.545, 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 fMtpGoegie-E; Mon, 15 Feb 2010 11:48:11 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 8FFC73A7372; Mon, 15 Feb 2010 11:48:08 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5C6F26B6752; Mon, 15 Feb 2010 16:49:48 -0300 (ART) Received: from [192.168.0.100] (144-174-17-190.fibertel.com.ar [190.17.174.144]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1FJnX1Q014109; Mon, 15 Feb 2010 16:49:35 -0300 Message-ID: <4B79A54C.7040107@gont.com.ar> Date: Mon, 15 Feb 2010 16:49:32 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 15 Feb 2010 16:49:47 -0300 (ART) Cc: tcpm@ietf.org, secdir@ietf.org Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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, 15 Feb 2010 19:48:12 -0000 Hello, Phillip, Thanks so much for your feedback! See my comments inline.... > The principal security risks considered are service risks. ICMP may be > used to perform certain denial of service and performance downgrade > attacks. As such it probably needs rather more justification than 'we > have always done this' when building critical infrastructures. I fully agree. This I-D has been debated in tcpm form... 6 years now. It was originally meant for Std track, but somehow ended up heading for Informational. What's in the I-D is what most implementation (all the mainstream ones, at least) do. So if *I* had to answer why we don't stress that ICMP should be disregarded in many scenarios, etc., I can just say that this is what the WG has converged to. > Given that TCP streams will eventually time-out, I have something of a > hard time seeing why we would be using a non-authenticated control > protocol at all. Yes, I know the legacy reasons etc. etc. But this is > not the way we would approach this problem today. I fully agree. > This argument is > almost made on page 15. Some statement giving the case for taking > notice of ICMP messages at all is in order. I guess the "statement" that you could get here (tcpm) is "responsiveness". -- with which I'd disagree, for many of the reasons stated in the draft, and because in many other cases it has been argued in this very wg that "tcp is supposed to be robust, it's not optimized for any scenario, etc.". Should I craft some text along the lines of "responsiveness"? > It might well be that an > appropriate control in certain cases would be to turn off ICMP hard > errors and rely on timeouts, I am thinking here of critical > infrastructure applications and communications between hosts running > BGP functions. Most (if not all) real-world implementations already do this. We have lived with this behaviour that you describe for the last..mm.. 20 years (or so) with BSDs... and there's no way that BSDs, or Linux, or Cisco, or whoever are going to change back their implementations to e.g. "resetting connections in response to ICMP hard errors". For instance, they have issued vulnerability advisories in this respect... > In particular I note that the draft says "It is interesting to note > that, as ICMP error messages are transmitted unreliably, transport > protocols should not depend on them for correct functioning." > > Given the extreme approach to security of starting from nothing and > only adding systems that are essential, this would seem to suggest > ICMP is not necessary and could be eliminated. Yes...except for ICMP "frag needed but DF bit set", which is needed for PMTUD. > There may be a case to > the contrary but it needs to be made before page 15. My take is "responsiveness". But I'll let the wg chime in. :-) > Page 15/16 > > The following phrase repeats in a way that suggests an editing oversight: > aborting the > connection would be to ignore the valuable feature of the Internet > that for many internal failures it reconstructs its function without > any disruption of the end points Sorry... I wasn't able to catch the "oversight" you refer to... :-( > Page 24-26 > > A more general way of describing the mitigation strategy would be to > point out the general principle that error messages may be ignored > whenever a packet indicating success is received within the timeout > window. In other words no final processing decisions should be made on > an unauthenticated ICMP packet until after the timeout window expires. Section 7.2 already states: " The described mechanism basically disregards ICMP messages when a connection makes progress, without violating any of the requirements stated in [RFC1191] and [RFC1981]." Please let me know if this text addresses your comment, or whether you think I should craft another paragraph mentioning that of "ignore messages whenever a packet indicating progress is received". Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Mon Feb 15 12:09:03 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 0B20828C20F; Mon, 15 Feb 2010 12:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 qQmg6dXd-e1E; Mon, 15 Feb 2010 12:09:02 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 17A6928C203; Mon, 15 Feb 2010 12:09:02 -0800 (PST) Received: from [192.168.1.95] (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 o1FK8Rwo005716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Feb 2010 12:08:29 -0800 (PST) Message-ID: <4B79A9BA.5050205@isi.edu> Date: Mon, 15 Feb 2010 12:08:26 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B79A54C.7040107@gont.com.ar> In-Reply-To: <4B79A54C.7040107@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig104286DE59925E459E990848" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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, 15 Feb 2010 20:09:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig104286DE59925E459E990848 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Hello, Phillip, >=20 > Thanks so much for your feedback! See my comments inline.... >=20 >=20 >> The principal security risks considered are service risks. ICMP may be= >> used to perform certain denial of service and performance downgrade >> attacks. As such it probably needs rather more justification than 'we >> have always done this' when building critical infrastructures. >=20 > I fully agree. This I-D has been debated in tcpm form... 6 years now. I= t > was originally meant for Std track, but somehow ended up heading for > Informational. That implies the decision was either accidental or unintentional, and neither is the case, FWIW. > What's in the I-D is what most implementation (all the > mainstream ones, at least) do. >=20 > So if *I* had to answer why we don't stress that ICMP should be > disregarded in many scenarios, etc., I can just say that this is what > the WG has converged to. This is what the WG *decided*. "Converged to" similarly implies lack of deliberate decision, which was not the case. >> Given that TCP streams will eventually time-out, I have something of a= >> hard time seeing why we would be using a non-authenticated control >> protocol at all. Yes, I know the legacy reasons etc. etc. But this is >> not the way we would approach this problem today.=20 >=20 > I fully agree. Not all TCP state times out. Connections that don't use keepalives will retain stale state until the state is explicitly flushed by a RST. If the other end never comes back up, the state *never* gets flushed if not for ICMPs. It'd be an interesting question to ask whether we could do without ICMPs altogether, but that is not addressed sufficiently in this doc to make such a conclusion, IMO. >> This argument is >> almost made on page 15. Some statement giving the case for taking >> notice of ICMP messages at all is in order.=20 >=20 > I guess the "statement" that you could get here (tcpm) is > "responsiveness". -- with which I'd disagree, for many of the reasons > stated in the draft, and because in many other cases it has been argued= > in this very wg that "tcp is supposed to be robust, it's not optimized > for any scenario, etc.". >=20 > Should I craft some text along the lines of "responsiveness"? This doc, by WG agreement, focuses on "what is". It is not intended to make broader recommendations or conclusions. >> It might well be that an >> appropriate control in certain cases would be to turn off ICMP hard >> errors and rely on timeouts, I am thinking here of critical >> infrastructure applications and communications between hosts running >> BGP functions. >=20 > Most (if not all) real-world implementations already do this. We have > lived with this behaviour that you describe for the last..mm.. 20 years= > (or so) with BSDs... and there's no way that BSDs, or Linux, or Cisco, > or whoever are going to change back their implementations to e.g. > "resetting connections in response to ICMP hard errors". For instance, > they have issued vulnerability advisories in this respect... KARP is addressing some of these issues. TCP-AO also addresses these issues in the context of BGP. It's difficult to argue for broader controls of ICMPs in the absence of authentication at the IP or TCP level, since RSTs have just as injurious an impact. >> In particular I note that the draft says "It is interesting to note >> that, as ICMP error messages are transmitted unreliably, transport >> protocols should not depend on them for correct functioning." >> >> Given the extreme approach to security of starting from nothing and >> only adding systems that are essential, this would seem to suggest >> ICMP is not necessary and could be eliminated.=20 >=20 > Yes...except for ICMP "frag needed but DF bit set", which is needed for= > PMTUD. Well, if we're going to pick, PMTUD based on ICMP should be replaced with PLPMTUD. However, again, this level of recommendation is out of scope for this doc, IMO. Joe --------------enig104286DE59925E459E990848 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) iEYEARECAAYFAkt5qbsACgkQE5f5cImnZrv78QCgqGvVd2B+ORo1Ln4JHUPA2T6Q QHkAoPaPoUKOk366SPiG2aVVVt/6RXFh =/Ojb -----END PGP SIGNATURE----- --------------enig104286DE59925E459E990848-- From fernando@gont.com.ar Mon Feb 15 12:28: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 4925328C27D; Mon, 15 Feb 2010 12:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.075 X-Spam-Level: X-Spam-Status: No, score=-3.075 tagged_above=-999 required=5 tests=[AWL=0.524, 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 v4tAgCKnMhTm; Mon, 15 Feb 2010 12:28:35 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id D340B28C27A; Mon, 15 Feb 2010 12:28:32 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 778356B6752; Mon, 15 Feb 2010 17:30:14 -0300 (ART) Received: from [192.168.0.100] (144-174-17-190.fibertel.com.ar [190.17.174.144]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1FKU0Su004009; Mon, 15 Feb 2010 17:30:01 -0300 Message-ID: <4B79AEC8.3030506@gont.com.ar> Date: Mon, 15 Feb 2010 17:30:00 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> In-Reply-To: <4B79A9BA.5050205@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 15 Feb 2010 17:30:13 -0300 (ART) Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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, 15 Feb 2010 20:28:36 -0000 Joe Touch wrote: >>> The principal security risks considered are service risks. ICMP may be >>> used to perform certain denial of service and performance downgrade >>> attacks. As such it probably needs rather more justification than 'we >>> have always done this' when building critical infrastructures. >> I fully agree. This I-D has been debated in tcpm form... 6 years now. It >> was originally meant for Std track, but somehow ended up heading for >> Informational. > > That implies the decision was either accidental or unintentional, and > neither is the case, FWIW. Well, if you track the decision, you'll probably go back to an IETF meeting in 2005 (Vancouver), in which, while we were heading for Std. Track, somebody asked "Why not Informational?", and that's what we ended up doing. So... >> So if *I* had to answer why we don't stress that ICMP should be >> disregarded in many scenarios, etc., I can just say that this is what >> the WG has converged to. > > This is what the WG *decided*. "Converged to" similarly implies lack of > deliberate decision, which was not the case. FWIW, this is what was decided (IIRC) at the IETF Vancouver in 2005. And as a result of what I already considered at the time an excessive expenditure of energy :-), didn't fight that much. >>> Given that TCP streams will eventually time-out, I have something of a >>> hard time seeing why we would be using a non-authenticated control >>> protocol at all. Yes, I know the legacy reasons etc. etc. But this is >>> not the way we would approach this problem today. >> I fully agree. > > Not all TCP state times out. Connections that don't use keepalives will > retain stale state until the state is explicitly flushed by a RST. If > the other end never comes back up, the state *never* gets flushed if not > for ICMPs. The TCP spec says that "ICMP hard errors should be processes as RSTs", but never describe a case in which a TCP would send an ICMP hard error instead of a RST. If you ever get an ICMP hard error, it's probably because of a firewall. And many of these devices do not even check the TCP checksum. So you may end up resetting a connection in response to an ICMP hard error elicited by a corrupted TCP segment. That is, honoring ICMPs makes TCP less robust. That said, at this point in time all this has already been discussed. So I just want to finish the I-D. So at this point in time, whatever addresses the raised issues would do for me. And, if you really depend on anything to flush stale connections, you're vulnerable to a bunch of other attacks (Sockstress, and the rest of the stuff that is already discussed in the CPNI TCP security paper). >>> This argument is >>> almost made on page 15. Some statement giving the case for taking >>> notice of ICMP messages at all is in order. >> I guess the "statement" that you could get here (tcpm) is >> "responsiveness". -- with which I'd disagree, for many of the reasons >> stated in the draft, and because in many other cases it has been argued >> in this very wg that "tcp is supposed to be robust, it's not optimized >> for any scenario, etc.". >> >> Should I craft some text along the lines of "responsiveness"? > > This doc, by WG agreement, focuses on "what is". It is not intended to > make broader recommendations or conclusions. This doc has probably been one of the best examples for the recent flood of messages on the WG. > KARP is addressing some of these issues. TCP-AO also addresses these > issues in the context of BGP. > > It's difficult to argue for broader controls of ICMPs in the absence of > authentication at the IP or TCP level, since RSTs have just as injurious > an impact. C'mon, Joe. ICMP must have an in-window TCP SEQ. ICMPs need not. We've been here before. So the ICMP attack vector is the low hanging fruit. >>> Given the extreme approach to security of starting from nothing and >>> only adding systems that are essential, this would seem to suggest >>> ICMP is not necessary and could be eliminated. >> Yes...except for ICMP "frag needed but DF bit set", which is needed for >> PMTUD. > > Well, if we're going to pick, PMTUD based on ICMP should be replaced > with PLPMTUD. However, again, this level of recommendation is out of > scope for this doc, IMO. I already tried this one, and e.g., Linux developers already refused to do so, as a result of "convergence time" reasons. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Mon Feb 15 12:51:20 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 7EE823A79EF; Mon, 15 Feb 2010 12:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 vWioBgP1m3ws; Mon, 15 Feb 2010 12:51:19 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7D2CD3A722A; Mon, 15 Feb 2010 12:51:19 -0800 (PST) Received: from [192.168.1.95] (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 o1FKja0m013907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Feb 2010 12:45:38 -0800 (PST) Message-ID: <4B79B270.5060804@isi.edu> Date: Mon, 15 Feb 2010 12:45:36 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar> In-Reply-To: <4B79AEC8.3030506@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE223615851FE9C8280A451B4" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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, 15 Feb 2010 20:51:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE223615851FE9C8280A451B4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >>>> The principal security risks considered are service risks. ICMP may = be >>>> used to perform certain denial of service and performance downgrade >>>> attacks. As such it probably needs rather more justification than 'w= e >>>> have always done this' when building critical infrastructures. >>> I fully agree. This I-D has been debated in tcpm form... 6 years now.= It >>> was originally meant for Std track, but somehow ended up heading for >>> Informational. >> That implies the decision was either accidental or unintentional, and >> neither is the case, FWIW. >=20 > Well, if you track the decision, you'll probably go back to an IETF > meeting in 2005 (Vancouver), in which, while we were heading for Std. > Track, somebody asked "Why not Informational?", and that's what we ende= d > up doing. So... That decision was discussed at length at multiple IETFs. It didn't happen as an accident or by the direct consequence of a single off-handed suggestion. =2E.. >>>> Given that TCP streams will eventually time-out, I have something of= a >>>> hard time seeing why we would be using a non-authenticated control >>>> protocol at all. Yes, I know the legacy reasons etc. etc. But this i= s >>>> not the way we would approach this problem today.=20 >>> I fully agree. >> >> Not all TCP state times out. Connections that don't use keepalives wil= l >> retain stale state until the state is explicitly flushed by a RST. If >> the other end never comes back up, the state *never* gets flushed if n= ot >> for ICMPs. >=20 > The TCP spec says that "ICMP hard errors should be processes as RSTs", > but never describe a case in which a TCP would send an ICMP hard error > instead of a RST. If frag is needed, you can't get a RST since the packet never gets there. If the port is blocked upstream of the end device, the same thing happens. Your next sentence appears to assert that the latter is the common case. > If you ever get an ICMP hard error, it's probably because of a firewall= =2E If it's after a connection is established, it's likely because of a change in path that has different firewall policy or MTU. > And many of these devices do not even check the TCP checksum. Nor should they. The ICMP packet isn't required to include the entire TCP segment, and when it doesn't it *can't* verify the checksum anyway. =2E.. > And, if you really depend on anything to flush stale connections, you'r= e > vulnerable to a bunch of other attacks (Sockstress, and the rest of the= > stuff that is already discussed in the CPNI TCP security paper). My point was simply that TCP doesn't always clean itself up via timeouts. That could be changed, but requires a change to the TCP spec to, e.g., require all TCP connections to default to "keepalive", and that hasn't been discussed. >>>> This argument is >>>> almost made on page 15. Some statement giving the case for taking >>>> notice of ICMP messages at all is in order.=20 >>> I guess the "statement" that you could get here (tcpm) is >>> "responsiveness". -- with which I'd disagree, for many of the reasons= >>> stated in the draft, and because in many other cases it has been argu= ed >>> in this very wg that "tcp is supposed to be robust, it's not optimize= d >>> for any scenario, etc.". >>> >>> Should I craft some text along the lines of "responsiveness"? >> This doc, by WG agreement, focuses on "what is". It is not intended to= >> make broader recommendations or conclusions. >=20 > This doc has probably been one of the best examples for the recent floo= d > of messages on the WG. >=20 >> KARP is addressing some of these issues. TCP-AO also addresses these >> issues in the context of BGP. >> >> It's difficult to argue for broader controls of ICMPs in the absence o= f >> authentication at the IP or TCP level, since RSTs have just as injurio= us >> an impact. >=20 > C'mon, Joe. ICMP must have an in-window TCP SEQ. ICMPs need not. We've > been here before. So the ICMP attack vector is the low hanging fruit. There are numerous ways to upset a TCP connection by injecting bad data, causing it to emit extra ACKs, etc. And the difference between in and not-in window has become much less relevant. (e.g., if "in window" was sufficient, then you should be arguing to stop work on TCP-SECURE). Joe --------------enigE223615851FE9C8280A451B4 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) iEYEARECAAYFAkt5snAACgkQE5f5cImnZrvAPgCdH7TO1+bEqeguv644nVwYnUmt aN4AmwU0G2u3ccZy2BMciXQCN0wjVi38 =u802 -----END PGP SIGNATURE----- --------------enigE223615851FE9C8280A451B4-- From fernando@gont.com.ar Mon Feb 15 13:07:17 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 BF2743A6870; Mon, 15 Feb 2010 13:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.094 X-Spam-Level: X-Spam-Status: No, score=-3.094 tagged_above=-999 required=5 tests=[AWL=0.505, 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 P2C9ZGdezb-W; Mon, 15 Feb 2010 13:07:16 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 63BBC3A682A; Mon, 15 Feb 2010 13:07:14 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id DF2896B673D; Mon, 15 Feb 2010 18:08:55 -0300 (ART) Received: from [192.168.0.100] (144-174-17-190.fibertel.com.ar [190.17.174.144]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1FL8fm1002804; Mon, 15 Feb 2010 18:08:42 -0300 Message-ID: <4B79B7D9.8080909@gont.com.ar> Date: Mon, 15 Feb 2010 18:08:41 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar> <4B79B270.5060804@isi.edu> In-Reply-To: <4B79B270.5060804@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 15 Feb 2010 18:08:55 -0300 (ART) Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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, 15 Feb 2010 21:07:17 -0000 Joe Touch wrote: >> Well, if you track the decision, you'll probably go back to an IETF >> meeting in 2005 (Vancouver), in which, while we were heading for Std. >> Track, somebody asked "Why not Informational?", and that's what we ended >> up doing. So... > > That decision was discussed at length at multiple IETFs. It didn't > happen as an accident or by the direct consequence of a single > off-handed suggestion. I disagree. But at this point in time, this is off-topic. >> The TCP spec says that "ICMP hard errors should be processes as RSTs", >> but never describe a case in which a TCP would send an ICMP hard error >> instead of a RST. I already argued that the only ICMPs that you really need are the "frag needed" ones. > If frag is needed, you can't get a RST since the packet never gets > there. If the port is blocked upstream of the end device, the same thing > happens. Your next sentence appears to assert that the latter is the > common case. If the packet had elicited an RST if it had been received at the intended destination, the connection will probably time-out (i.e., it was a data segment... unless you're implying that a simple ACK does not fit into the PMTU). >> If you ever get an ICMP hard error, it's probably because of a firewall. > > If it's after a connection is established, it's likely because of a > change in path that has different firewall policy or MTU. Exactly. In which case that should be a *soft* error (who said the path is not going to change back to the old one?). >> And many of these devices do not even check the TCP checksum. > > Nor should they. The ICMP packet isn't required to include the entire > TCP segment, and when it doesn't it *can't* verify the checksum anyway. Exactly. And this hurts the precious TCP robustness you have always been defending. >> And, if you really depend on anything to flush stale connections, you're >> vulnerable to a bunch of other attacks (Sockstress, and the rest of the >> stuff that is already discussed in the CPNI TCP security paper). > > My point was simply that TCP doesn't always clean itself up via > timeouts. That could be changed, but requires a change to the TCP spec > to, e.g., require all TCP connections to default to "keepalive", and > that hasn't been discussed. Keepalives are not even part of the spec. >>> It's difficult to argue for broader controls of ICMPs in the absence of >>> authentication at the IP or TCP level, since RSTs have just as injurious >>> an impact. >> C'mon, Joe. ICMP must have an in-window TCP SEQ. ICMPs need not. We've >> been here before. So the ICMP attack vector is the low hanging fruit. > > There are numerous ways to upset a TCP connection by injecting bad data, > causing it to emit extra ACKs, etc. And the difference between in and > not-in window has become much less relevant. ICMP's are one of the only two vectors that can reset connections without being required a matching SEQ. -- the other one being the ToS and Precedence level, as discussed in the CPNI document. IMO, in-window vs. oo-window does make a difference. For instance, the whole press that these issues got back in 2004 is because people had got the numbers wrong in their calculations of "number of packets needed". This is essentially the "new thing" that Paul Watson pointed out back in 2004. Anyway: For the most part I'm wondering if there's any additional text needed to address Phillip's comments. Thoughts? This should be our focus at this point in time. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ananth@cisco.com Mon Feb 15 14:30: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 DF24B28C108; Mon, 15 Feb 2010 14:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 t6zOZzYd67EZ; Mon, 15 Feb 2010 14:30:46 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 14D2628C10B; Mon, 15 Feb 2010 14:30:46 -0800 (PST) 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: AvsEAKdaeUurRN+K/2dsb2JhbACbFnSlMZcthFsEgxQ X-IronPort-AV: E=Sophos;i="4.49,480,1262563200"; d="scan'208";a="299480644" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 15 Feb 2010 22:32:18 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o1FMWGwK026772; Mon, 15 Feb 2010 22:32:16 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); Mon, 15 Feb 2010 14:32:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Feb 2010 14:32:17 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5808EB58FB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4B79A54C.7040107@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt Thread-Index: AcqueB8CL+zCGYnVRrqOl12O9jscqwAEiDGA References: <4B79A54C.7040107@gont.com.ar> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" , "Phillip Hallam-Baker" X-OriginalArrivalTime: 15 Feb 2010 22:32:18.0218 (UTC) FILETIME=[BB2A48A0:01CAAE8E] Cc: tcpm@ietf.org, secdir@ietf.org Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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, 15 Feb 2010 22:30:47 -0000 =20 Some general comments on this discussion inline... > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Fernando Gont > Sent: Monday, February 15, 2010 11:50 AM > To: Phillip Hallam-Baker > Cc: tcpm@ietf.org; secdir@ietf.org > Subject: Re: [tcpm] SECDIR REVIEW of=20 > draft-ietf-tcpm-icmp-attacks-10.txt >=20 > Hello, Phillip, >=20 > Thanks so much for your feedback! See my comments inline.... >=20 >=20 > > The principal security risks considered are service risks.=20 > ICMP may be=20 > > used to perform certain denial of service and performance downgrade=20 > > attacks. As such it probably needs rather more=20 > justification than 'we=20 > > have always done this' when building critical infrastructures. >=20 > I fully agree. This I-D has been debated in tcpm form... 6=20 > years now. It was originally meant for Std track, but somehow=20 > ended up heading for Informational. What's in the I-D is what=20 > most implementation (all the mainstream ones, at least) do. That is true. Many implementations already do what is being said in this ID.=20 >=20 > So if *I* had to answer why we don't stress that ICMP should=20 > be disregarded in many scenarios, etc., I can just say that=20 > this is what the WG has converged to. I think you should put some text to this effect. IMO, we don't have an overwhelming consensus on whether this document should be informational or standard. To me, I have no issues making this head towards the PS, one of the main reasons being it has been well adopted in the internet today. I also agree that "just being popular" doesn't imply that it needs to become a standard. In this case it is not only popular, these mitigations have more pros than cons. > > This argument is > > almost made on page 15. Some statement giving the case for taking=20 > > notice of ICMP messages at all is in order. >=20 > I guess the "statement" that you could get here (tcpm) is=20 > "responsiveness". -- with which I'd disagree, for many of the=20 > reasons stated in the draft, and because in many other cases=20 > it has been argued in this very wg that "tcp is supposed to=20 > be robust, it's not optimized for any scenario, etc.". >=20 > Should I craft some text along the lines of "responsiveness"? That may be a good idea. >=20 >=20 >=20 > > It might well be that an > > appropriate control in certain cases would be to turn off ICMP hard=20 > > errors and rely on timeouts, I am thinking here of critical=20 > > infrastructure applications and communications between=20 > hosts running=20 > > BGP functions. >=20 > Most (if not all) real-world implementations already do this.=20 > We have lived with this behaviour that you describe for the=20 > last..mm.. 20 years (or so) with BSDs... and there's no way=20 > that BSDs, or Linux, or Cisco, or whoever are going to change=20 > back their implementations to e.g. > "resetting connections in response to ICMP hard errors". For=20 > instance, they have issued vulnerability advisories in this respect... Correct. Thanks, -Anantha From touch@ISI.EDU Tue Feb 16 08:44: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 E619428C0D9; Tue, 16 Feb 2010 08:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 uxkuz9KxOEFZ; Tue, 16 Feb 2010 08:44:06 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 458603A6906; Tue, 16 Feb 2010 08:44:06 -0800 (PST) Received: from [75.215.203.205] (205.sub-75-215-203.myvzw.com [75.215.203.205]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o1GGiOpn025228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Feb 2010 08:44:26 -0800 (PST) Message-ID: <4B7ACB68.9020503@isi.edu> Date: Tue, 16 Feb 2010 08:44:24 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar> <4B79B270.5060804@isi.edu> <4B79B7D9.8080909@gont.com.ar> In-Reply-To: <4B79B7D9.8080909@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3AC637569631BEAA1B5B5101" X-MailScanner-ID: o1GGiOpn025228 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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: Tue, 16 Feb 2010 16:44:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3AC637569631BEAA1B5B5101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: =2E.. > Anyway: For the most part I'm wondering if there's any additional text > needed to address Phillip's comments. Thoughts? This should be our focu= s > at this point in time. There were two separate points raised, IMO: - clarification of the role of this doc's recommendations The WG was aware of this issue, and there was a lot of effort in creating the existing text that already considered this perspective. No change needed. - addressing the larger issue of the role/need of ICMPs This is out of scope for this doc. No change needed. Overall, I think there isn't a need for a change. Joe --------------enig3AC637569631BEAA1B5B5101 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) iEYEARECAAYFAkt6y2gACgkQE5f5cImnZrtvegCg2UesmTQy7A6MAbYUWzWs/7V3 lv4AniuzFJkjbldUlYogdchUnixFj7UB =8+my -----END PGP SIGNATURE----- --------------enig3AC637569631BEAA1B5B5101-- From ananth@cisco.com Tue Feb 16 09:45:30 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 64EE028C1B1; Tue, 16 Feb 2010 09:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 9RVHfUfx0MAT; Tue, 16 Feb 2010 09:45:29 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 72CFB28C0E9; Tue, 16 Feb 2010 09:45:29 -0800 (PST) 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: AvsEAFppekurRN+J/2dsb2JhbACbGXSmCZdmhFsEgxSLEA X-IronPort-AV: E=Sophos;i="4.49,485,1262563200"; d="scan'208";a="299792539" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 16 Feb 2010 17:47:04 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o1GHl4hM002366; Tue, 16 Feb 2010 17:47:04 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); Tue, 16 Feb 2010 09:47:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Feb 2010 09:47:02 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5808EB5C32@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4B7ACB68.9020503@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt Thread-Index: AcqvJ5gXsgopgP/BTROs15hmZLMgUwAAwdzQ References: <4B79A54C.7040107@gont.com.ar><4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar><4B79B270.5060804@isi.edu> <4B79B7D9.8080909@gont.com.ar> <4B7ACB68.9020503@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Fernando Gont" X-OriginalArrivalTime: 16 Feb 2010 17:47:04.0670 (UTC) FILETIME=[0D1BD7E0:01CAAF30] Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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: Tue, 16 Feb 2010 17:45:30 -0000 =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Joe Touch > Sent: Tuesday, February 16, 2010 8:44 AM > To: Fernando Gont > Cc: tcpm@ietf.org; Phillip Hallam-Baker; secdir@ietf.org > Subject: Re: [tcpm] SECDIR REVIEW of=20 > draft-ietf-tcpm-icmp-attacks-10.txt >=20 >=20 >=20 > Fernando Gont wrote: > ... > > Anyway: For the most part I'm wondering if there's any=20 > additional text=20 > > needed to address Phillip's comments. Thoughts? This should be our=20 > > focus at this point in time. >=20 > There were two separate points raised, IMO: >=20 > - clarification of the role of this doc's recommendations > The WG was aware of this issue, and there was > a lot of effort in creating the existing text that > already considered this perspective. No change needed. I would still think there is some text needed which explains (in a sentence or two) the role of this documents recommendations. Atleast explain why the target was chosen to be "informational" at this point of time. Would help a lot of readers/implementers down the line since this question would keep coming. But that's just me, if the consensus is to not add anything I am fine too. -Anantha From touch@ISI.EDU Tue Feb 16 09:52: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 9DF4728C17F; Tue, 16 Feb 2010 09:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 nAbH6B9mRI1t; Tue, 16 Feb 2010 09:52:03 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 67E7A28C100; Tue, 16 Feb 2010 09:52:02 -0800 (PST) Received: from [75.215.203.205] (205.sub-75-215-203.myvzw.com [75.215.203.205]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o1GHpw4i009428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Feb 2010 09:52:01 -0800 (PST) Message-ID: <4B7ADB3E.2060308@isi.edu> Date: Tue, 16 Feb 2010 09:51:58 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <4B79A54C.7040107@gont.com.ar><4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar><4B79B270.5060804@isi.edu> <4B79B7D9.8080909@gont.com.ar> <4B7ACB68.9020503@isi.edu> <0C53DCFB700D144284A584F54711EC5808EB5C32@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5808EB5C32@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEDEC4ACB695A9B50B6227374" X-MailScanner-ID: o1GHpw4i009428 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Phillip Hallam-Baker , Fernando Gont , secdir@ietf.org Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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: Tue, 16 Feb 2010 17:52:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEDEC4ACB695A9B50B6227374 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 >> Behalf Of Joe Touch >> Sent: Tuesday, February 16, 2010 8:44 AM >> To: Fernando Gont >> Cc: tcpm@ietf.org; Phillip Hallam-Baker; secdir@ietf.org >> Subject: Re: [tcpm] SECDIR REVIEW of=20 >> draft-ietf-tcpm-icmp-attacks-10.txt >> >> >> >> Fernando Gont wrote: >> ... >>> Anyway: For the most part I'm wondering if there's any=20 >> additional text=20 >>> needed to address Phillip's comments. Thoughts? This should be our=20 >>> focus at this point in time. >> There were two separate points raised, IMO: >> >> - clarification of the role of this doc's recommendations >> The WG was aware of this issue, and there was >> a lot of effort in creating the existing text that >> already considered this perspective. No change needed. >=20 > I would still think there is some text needed which explains (in a > sentence or two) the role of this documents recommendations. Atleast > explain why the target was chosen to be "informational" at this point o= f > time. Would help a lot of readers/implementers down the line since this= > question would keep coming. But that's just me, if the consensus is to > not add anything I am fine too. The role is basically limited to 'documenting what is deployed', which is summarized fairly directly in the abstract. The specific recommendation made towards the end of the intro reiterates that. I.e., this is not a new issue, and it's something for which there is specific text already. I think it answers the mail on that point. Joe --------------enigEDEC4ACB695A9B50B6227374 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) iEYEARECAAYFAkt62z4ACgkQE5f5cImnZrulAgCg5OyE5+fW8IMDSgtYsh8//cL6 sF4AoN6f9+vP2w9MUb9xNIFczq5Ln5Wj =mFVn -----END PGP SIGNATURE----- --------------enigEDEC4ACB695A9B50B6227374-- From jari.arkko@piuha.net Thu Feb 18 11:03:12 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 C8F3128C0E2 for ; Thu, 18 Feb 2010 11:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 HaAoVKVX4lqj for ; Thu, 18 Feb 2010 11:03:11 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8A6113A8039 for ; Thu, 18 Feb 2010 11:03:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9EBC42D287 for ; Thu, 18 Feb 2010 21:04:54 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvqjKvOlxUXQ for ; Thu, 18 Feb 2010 21:04:54 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 333442D257 for ; Thu, 18 Feb 2010 21:04:54 +0200 (EET) Message-ID: <4B7D8F55.90406@piuha.net> Date: Thu, 18 Feb 2010 21:04:53 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: tcpm@ietf.org References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> In-Reply-To: <4B7D8B9F.1010608@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 18 Feb 2010 19:03:12 -0000 Hi, This document was recently in IESG review. My opinion is that the document should be approved as an RFC. Thanks for writing it. However, I would like to note the following text from the document: The consensus of the TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to document this widespread implementation of nonstandard TCP behavior but to not change the TCP standard. This would seem to imply that the TCPM WG has decided to deviate from the old IETF operating principle of "rough consensus and running code". For at least some of the techniques described in this draft, they are generally accepted and widely implemented on key implementations. I ask what the reason is for divorcing IETF standards from established best practices and actual running code? TCP RFCs are not sacred documents, they should reflect what we want our implementations to do. But maybe there are important use cases for the actual standard TCP behavior in this space, just that I don't know about them. Please educate me about the background for this decision. Jari From touch@ISI.EDU Thu Feb 18 11:19: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 132623A7B46 for ; Thu, 18 Feb 2010 11:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml9iGpp+Moxs for ; Thu, 18 Feb 2010 11:19:54 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2591E3A7D7B for ; Thu, 18 Feb 2010 11:19:54 -0800 (PST) Received: from [75.214.250.14] (14.sub-75-214-250.myvzw.com [75.214.250.14]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o1IJKB72008167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 11:20:14 -0800 (PST) Message-ID: <4B7D92EB.7010407@isi.edu> Date: Thu, 18 Feb 2010 11:20:11 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> In-Reply-To: <4B7D8F55.90406@piuha.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDCD7B130424E94F6E1DBED23" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 18 Feb 2010 19:19:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDCD7B130424E94F6E1DBED23 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > Hi, >=20 > This document was recently in IESG review. My opinion is that the > document should be approved as an RFC. Thanks for writing it. >=20 > However, I would like to note the following text from the document: >=20 > The consensus of the TCPM WG (TCP Maintenance and > Minor Extensions Working Group) was to document this widespread > implementation of nonstandard TCP behavior but to not change the TCP > standard. >=20 > This would seem to imply that the TCPM WG has decided to deviate from > the old IETF operating principle of "rough consensus and running code".= The short answer is that there wasn't rough consensus for these changes in the WG, as explained in the note in the text. Joe --------------enigDCD7B130424E94F6E1DBED23 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) iEYEARECAAYFAkt9kusACgkQE5f5cImnZrs1HgCgt3fivnvbrmKQCH66uq2/1bqL /YkAn0p0G2s0L7PmP/T7PIaONCqtYs9N =2/vl -----END PGP SIGNATURE----- --------------enigDCD7B130424E94F6E1DBED23-- From jari.arkko@piuha.net Thu Feb 18 11:33:03 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 A97BA3A8039 for ; Thu, 18 Feb 2010 11:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 whcC3dY9om-c for ; Thu, 18 Feb 2010 11:33:03 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C245F3A7FF2 for ; Thu, 18 Feb 2010 11:33:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E8C962D287; Thu, 18 Feb 2010 21:34:45 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI1Kjsls5kkc; Thu, 18 Feb 2010 21:34:45 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 77EB12D257; Thu, 18 Feb 2010 21:34:45 +0200 (EET) Message-ID: <4B7D9655.1050804@piuha.net> Date: Thu, 18 Feb 2010 21:34:45 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Joe Touch References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> In-Reply-To: <4B7D92EB.7010407@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 18 Feb 2010 19:33:03 -0000 Joe, > The short answer is that there wasn't rough consensus for these changes > in the WG, as explained in the note in the text. > Ok. And by the way, I didn't mean to imply that all of the changes should be adopted. But at least some of them seem... pretty reasonable and universal. Like ignoring source quench, for instance. But I admit that my knowledge of TCP practices is limited. However, *if* the document is right that the techniques are widely implemented, it is interesting that the WG does not agree that they are universally appropriate. Is (1) the reality different from what the document claims, (2) are these practices causing harm in the real world, or (3) is the working group opinion incorrect? Jari From touch@ISI.EDU Thu Feb 18 11:51: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 7CECC28C110 for ; Thu, 18 Feb 2010 11:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC0qFwZ4yeAo for ; Thu, 18 Feb 2010 11:51:47 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id AFDD328C153 for ; Thu, 18 Feb 2010 11:51:47 -0800 (PST) Received: from [75.214.250.14] (14.sub-75-214-250.myvzw.com [75.214.250.14]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o1IJouii016219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 11:50:59 -0800 (PST) Message-ID: <4B7D9A20.7090403@isi.edu> Date: Thu, 18 Feb 2010 11:50:56 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7D9655.1050804@piuha.net> In-Reply-To: <4B7D9655.1050804@piuha.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5EBCC0CC10FC42C10000F5AD" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 18 Feb 2010 19:51:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5EBCC0CC10FC42C10000F5AD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Jari, Jari Arkko wrote: > Joe, >=20 >> The short answer is that there wasn't rough consensus for these change= s >> in the WG, as explained in the note in the text. >> =20 >=20 > Ok. And by the way, I didn't mean to imply that all of the changes > should be adopted. But at least some of them seem... pretty reasonable > and universal. Like ignoring source quench, for instance. But I admit > that my knowledge of TCP practices is limited. The WG decided to document "what is", and to indicate for each item whether it was consistent with existing specs or not. > However, *if* the document is right that the techniques are widely > implemented, it is interesting that the WG does not agree that they are= > universally appropriate. Is (1) the reality different from what the > document claims, (2) are these practices causing harm in the real world= , > or (3) is the working group opinion incorrect? I don't think anyone wants the IETF to rubber-stamp deployed code for that reason alone (e.g., consider Linux's inclusion of deprecated T/TCP, or use of nonstandard TCP windowing). There are times it's useful to modify the standards accordingly, there are times it's useful to declare it a bug (RFC2525), and there are times - such as this one - where we have no rough consensus on which way to go, but agree that it's useful to know what's actually out there. Joe --------------enig5EBCC0CC10FC42C10000F5AD 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) iEYEARECAAYFAkt9miAACgkQE5f5cImnZruhHQCfUldAmWAOFd0uWbWC3vWP72zK WdUAoOJhhTkFSvIY49pnowI/u1e/Z4Rb =/ull -----END PGP SIGNATURE----- --------------enig5EBCC0CC10FC42C10000F5AD-- From jari.arkko@piuha.net Thu Feb 18 12:04: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 8C2CD3A8044 for ; Thu, 18 Feb 2010 12:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 Vjeqby84eYnj for ; Thu, 18 Feb 2010 12:04:40 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 5B39F3A7D8B for ; Thu, 18 Feb 2010 12:04:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6D9B02D287; Thu, 18 Feb 2010 22:06:16 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16HwnlWgvZlt; Thu, 18 Feb 2010 22:06:16 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CC7F52D257; Thu, 18 Feb 2010 22:06:15 +0200 (EET) Message-ID: <4B7D9DB6.60204@piuha.net> Date: Thu, 18 Feb 2010 22:06:14 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Joe Touch References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7D9655.1050804@piuha.net> <4B7D9A20.7090403@isi.edu> In-Reply-To: <4B7D9A20.7090403@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 18 Feb 2010 20:04:41 -0000 Joe, > I don't think anyone wants the IETF to rubber-stamp deployed code for > that reason alone Agreed. > there are times - such as this one - where we > have no rough consensus on which way to go Sure. I guess my issue was that I did not see why this would be the case in this particular instance. Jari From touch@ISI.EDU Thu Feb 18 13:59: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 0B0903A6F85 for ; Thu, 18 Feb 2010 13:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 BXLyMTNMsr9p for ; Thu, 18 Feb 2010 13:59:37 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 46C443A6849 for ; Thu, 18 Feb 2010 13:59:37 -0800 (PST) Received: from [75.214.20.113] (113.sub-75-214-20.myvzw.com [75.214.20.113]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o1IM08Fk018093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2010 14:00:11 -0800 (PST) Message-ID: <4B7DB867.2000508@isi.edu> Date: Thu, 18 Feb 2010 14:00:07 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7D9655.1050804@piuha.net> <4B7D9A20.7090403@isi.edu> <4B7D9DB6.60204@piuha.net> In-Reply-To: <4B7D9DB6.60204@piuha.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig543B65B7024C172C3E0AD35E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 18 Feb 2010 21:59:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig543B65B7024C172C3E0AD35E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > Joe, >=20 >> I don't think anyone wants the IETF to rubber-stamp deployed code for >> that reason alone >=20 > Agreed. >=20 >> there are times - such as this one - where we >> have no rough consensus on which way to go >=20 > Sure. I guess my issue was that I did not see why this would be the cas= e > in this particular instance. There were various reasons - at least one of which was a desire to address this issue more broadly for all transports, which is outside the scope of TCPM and the focus of documenting this issue. Joe --------------enig543B65B7024C172C3E0AD35E 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) iEYEARECAAYFAkt9uGcACgkQE5f5cImnZrv5RwCg0wDzjNOf3TIrFrFI3oH4S9YZ H7kAn1gMo42L+qzTFmTKw/U7nhVp1x0B =961I -----END PGP SIGNATURE----- --------------enig543B65B7024C172C3E0AD35E-- From fernando@gont.com.ar Thu Feb 18 17:17: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 E001328C197; Thu, 18 Feb 2010 17:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 tagged_above=-999 required=5 tests=[AWL=0.548, 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 cW1RFT8u9+ko; Thu, 18 Feb 2010 17:17:25 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 1221F28C187; Thu, 18 Feb 2010 17:17:01 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 0340F6B673E; Thu, 18 Feb 2010 22:18:32 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1J1HgR8009344; Thu, 18 Feb 2010 22:17:43 -0300 Message-ID: <4B7DE6B7.4080209@gont.com.ar> Date: Thu, 18 Feb 2010 22:17:43 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> In-Reply-To: <4B7D92EB.7010407@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 18 Feb 2010 22:18:24 -0300 (ART) Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 01:17:26 -0000 Joe Touch wrote: >> This would seem to imply that the TCPM WG has decided to deviate from >> the old IETF operating principle of "rough consensus and running code". > > The short answer is that there wasn't rough consensus for these changes > in the WG, as explained in the note in the text. I believe that the short answer is that *you* have done everything that was available to stop this document (and others) from moving forward. Requesting text to be added, then requesting the very same text to be taken out of the I-D. And at some point, we ended up changing the track, changing text, and changing whatever was out there just with the hope that you'd be happy, we'd stop wasting energy, and the document would be eventually published. It is interesting to note that one of the issues with with you have trashed this I-D is that it used vocabulary that could be taken as the draft "recommending" the described counter-measures. Yet, as the editor of the last version of the (close to infamous) TCP A-O effort, you have crafted this text: " There are other mechanisms proposed to reduce the impact of ICMP attacks by further validating ICMP contents and changing the effect of some messages based on TCP state" Note the use of the term "proposed". (that's specifically what I'm referring to). I believe this is the height of irony. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jari.arkko@piuha.net Thu Feb 18 10:47:24 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 4D60028C133 for ; Thu, 18 Feb 2010 10:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 72nidJY53GeX for ; Thu, 18 Feb 2010 10:47:23 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 21D9E3A7FCF for ; Thu, 18 Feb 2010 10:47:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2C3242D287 for ; Thu, 18 Feb 2010 20:49:06 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUEwZQU-cRqR for ; Thu, 18 Feb 2010 20:49:05 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 723032D257 for ; Thu, 18 Feb 2010 20:49:05 +0200 (EET) Message-ID: <4B7D8B9F.1010608@piuha.net> Date: Thu, 18 Feb 2010 20:49:03 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: tcpm@ietf.org References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> In-Reply-To: <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Feb 2010 08:26:27 -0800 Subject: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 18 Feb 2010 18:47:24 -0000 Hi, This document was recently in IESG review. My opinion is that the document should be approved as an RFC. Thanks for writing it. However, I would like to note the following text from the document: The consensus of the TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to document this widespread implementation of nonstandard TCP behavior but to not change the TCP standard. This would seem to imply that the TCPM WG has decided to deviate from the old IETF operating principle of "rough consensus and running code". For at least some of the techniques described in this draft, they are generally accepted and widely implemented on key implementations. I ask what the reason is for divorcing IETF standards from established best practices and actual running code? TCP RFCs are not sacred documents, they should reflect what we want our implementations to do. But maybe there are important use cases for the actual standard TCP behavior in this space, just that I don't know about them. Please educate me about the background for this decision. Jari From ietfdbh@comcast.net Thu Feb 18 20:31:11 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 1113628C0FE for ; Thu, 18 Feb 2010 20:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 A7VmLjhaUd17 for ; Thu, 18 Feb 2010 20:31:10 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 0D8283A7B0D for ; Thu, 18 Feb 2010 20:31:09 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta07.westchester.pa.mail.comcast.net with comcast id jgAn1d0080mv7h057gYwiP; Fri, 19 Feb 2010 04:32:56 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta11.westchester.pa.mail.comcast.net with comcast id jgYv1d005284sdk3XgYvxZ; Fri, 19 Feb 2010 04:32:55 +0000 From: "David Harrington" To: "'Fernando Gont'" , "'Joe Touch'" References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net><4B7D92EB.7010407@isi.edu> <4B7DE6B7.4080209@gont.com.ar> Date: Thu, 18 Feb 2010 23:32:54 -0500 Message-ID: <0ff401cab11c$9ae3ee30$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4B7DE6B7.4080209@gont.com.ar> Thread-Index: AcqxAY13SGgDQ/BjQByfiNIb1GYPQwAGtF2Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailman-Approved-At: Fri, 19 Feb 2010 08:26:28 -0800 Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 04:31:11 -0000 Let's make sure we remain civil, guys. David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf Of Fernando Gont > Sent: Thursday, February 18, 2010 8:18 PM > To: Joe Touch > Cc: tcpm@ietf.org; Jari Arkko; iesg@ietf.org > Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks > > Joe Touch wrote: > > >> This would seem to imply that the TCPM WG has decided to > deviate from > >> the old IETF operating principle of "rough consensus and > running code". > > > > The short answer is that there wasn't rough consensus for > these changes > > in the WG, as explained in the note in the text. > > I believe that the short answer is that *you* have done > everything that > was available to stop this document (and others) from moving forward. > Requesting text to be added, then requesting the very same text to be > taken out of the I-D. And at some point, we ended up changing > the track, > changing text, and changing whatever was out there just with the hope > that you'd be happy, we'd stop wasting energy, and the > document would be > eventually published. > > It is interesting to note that one of the issues with with you have > trashed this I-D is that it used vocabulary that could be taken as the > draft "recommending" the described counter-measures. Yet, as > the editor > of the last version of the (close to infamous) TCP A-O > effort, you have > crafted this text: > > " There are other mechanisms proposed to reduce the impact > of ICMP attacks by further validating ICMP contents and > changing the > effect of some messages based on TCP state" > > Note the use of the term "proposed". (that's specifically what I'm > referring to). > > I believe this is the height of irony. > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > From Donald.Smith@qwest.com Fri Feb 19 08:53:08 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 AB2CB3A8188 for ; Fri, 19 Feb 2010 08:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.798, 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 SpBv2kbpSsP5 for ; Fri, 19 Feb 2010 08:53:07 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id C8B8E28C2A4 for ; Fri, 19 Feb 2010 08:53:07 -0800 (PST) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id o1JGsprx004827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2010 09:54:52 -0700 (MST) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id o1JGsjVE015607; Fri, 19 Feb 2010 10:54:46 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Fri, 19 Feb 2010 09:54:45 -0700 From: "Smith, Donald" To: Joe Touch , Jari Arkko Date: Fri, 19 Feb 2010 09:51:33 -0700 Thread-Topic: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks Thread-Index: Acqw1BnmY4FSYKt4QkStxZmKZAqzoQAr7Co7 Message-ID: References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7D9655.1050804@piuha.net>,<4B7D9A20.7090403@isi.edu> In-Reply-To: <4B7D9A20.7090403@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 16:53:08 -0000 In my opinion; 3. The wg "opinion" is incorrect. Several protocol vulnerabilities that are RFC based have been identified. W= e are supposed to be the group fixing TCP but instead this has become an in= formational RFC when it addresses basic protocol flaws. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe Touch = [touch@ISI.EDU] Sent: Thursday, February 18, 2010 12:50 PM To: Jari Arkko Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks Hi, Jari, Jari Arkko wrote: > Joe, > >> The short answer is that there wasn't rough consensus for these changes >> in the WG, as explained in the note in the text. >> > > Ok. And by the way, I didn't mean to imply that all of the changes > should be adopted. But at least some of them seem... pretty reasonable > and universal. Like ignoring source quench, for instance. But I admit > that my knowledge of TCP practices is limited. The WG decided to document "what is", and to indicate for each item whether it was consistent with existing specs or not. > However, *if* the document is right that the techniques are widely > implemented, it is interesting that the WG does not agree that they are > universally appropriate. Is (1) the reality different from what the > document claims, (2) are these practices causing harm in the real world, > or (3) is the working group opinion incorrect? I don't think anyone wants the IETF to rubber-stamp deployed code for that reason alone (e.g., consider Linux's inclusion of deprecated T/TCP, or use of nonstandard TCP windowing). There are times it's useful to modify the standards accordingly, there are times it's useful to declare it a bug (RFC2525), and there are times - such as this one - where we have no rough consensus on which way to go, but agree that it's useful to know what's actually out there. Joe This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From wesley.m.eddy@nasa.gov Fri Feb 19 09:24:56 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 3FE573A7BE9 for ; Fri, 19 Feb 2010 09:24:56 -0800 (PST) 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=[AWL=0.000, 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 1XYimX68D8F3 for ; Fri, 19 Feb 2010 09:24:55 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 2B2A73A7B4A for ; Fri, 19 Feb 2010 09:24:55 -0800 (PST) Received: from ndjsppt05.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 5D2BA328E0D; Fri, 19 Feb 2010 11:26:42 -0600 (CST) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt05.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o1JHPpWL004756; Fri, 19 Feb 2010 11:26:42 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Fri, 19 Feb 2010 11:26:35 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "Smith, Donald" , Joe Touch , Jari Arkko Date: Fri, 19 Feb 2010 11:26:33 -0600 Thread-Topic: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks Thread-Index: Acqw1BnmY4FSYKt4QkStxZmKZAqzoQAr7Co7AAA07aA= Message-ID: References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7D9655.1050804@piuha.net>,<4B7D9A20.7090403@isi.edu> 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-02-19_10:2010-02-06, 2010-02-19, 2010-02-19 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 17:24:56 -0000 Replying to Donald's message, but not picking on him in particular :) ... I think, as Joe noted, those "flaws" apply to transport protocols in general and not just TCP. I put "flaws" in quotes because I think it's a wrong and misleading word; these are vulnerabilities that have developed based on changing requirements and changing deployment scenarios over multiple decades. The same vulnerabilities impact other transports and would most properly be fixed on the standards track or BCP for all of them, rather than having TCP, SCTP, etc. all play whack-a-mole as people realize the same vulnerabilities exist N times. Instead of debating paltry issues like Informational versus Standards Track for this particular document, I think the discussion should be elevated to consider what the role of these ICMP messages is in the Internet architecture. If we're going to decide that transports should ignore many of them, then should we also decide that hosts routers shouldn't generate them? This discussion involves deprecation of pieces of STD 5, and update of RFCs 1122 and 1812, and is not something TCPM should be doing implicitly, but should really be a bigger-picture discussion between transport and internet areas. In my opinion, it was reasonable to do this as Informational for TCP at this point in time in order to document the implemented behaviors so that they're clear, but there are definitely deployments you could imagine where the vulnerabilities may not be applicable and the ICMP signals may actually be useful to maintain responses to. There are many networks less dangerous than the general Internet where the responsiveness that ICMP provides could be seen as valuable. -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Smith, Donald >Sent: Friday, February 19, 2010 11:52 AM >To: Joe Touch; Jari Arkko >Cc: tcpm@ietf.org >Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks > >In my opinion; > >3. The wg "opinion" is incorrect. >Several protocol vulnerabilities that are RFC based have been >identified. We are supposed to be the group fixing TCP but instead this >has become an informational RFC when it addresses basic protocol flaws. > > >(coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@qwest.com >________________________________________ >From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe >Touch [touch@ISI.EDU] >Sent: Thursday, February 18, 2010 12:50 PM >To: Jari Arkko >Cc: tcpm@ietf.org >Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks > >Hi, Jari, > >Jari Arkko wrote: >> Joe, >> >>> The short answer is that there wasn't rough consensus for these >changes >>> in the WG, as explained in the note in the text. >>> >> >> Ok. And by the way, I didn't mean to imply that all of the changes >> should be adopted. But at least some of them seem... pretty reasonable >> and universal. Like ignoring source quench, for instance. But I admit >> that my knowledge of TCP practices is limited. > >The WG decided to document "what is", and to indicate for each item >whether it was consistent with existing specs or not. > >> However, *if* the document is right that the techniques are widely >> implemented, it is interesting that the WG does not agree that they >are >> universally appropriate. Is (1) the reality different from what the >> document claims, (2) are these practices causing harm in the real >world, >> or (3) is the working group opinion incorrect? > >I don't think anyone wants the IETF to rubber-stamp deployed code for >that reason alone (e.g., consider Linux's inclusion of deprecated T/TCP, >or use of nonstandard TCP windowing). There are times it's useful to >modify the standards accordingly, there are times it's useful to declare >it a bug (RFC2525), and there are times - such as this one - where we >have no rough consensus on which way to go, but agree that it's useful >to know what's actually out there. > >Joe > >This communication is the property of Qwest and may contain confidential >or >privileged information. Unauthorized use of this communication is >strictly >prohibited and may be unlawful. If you have received this communication >in error, please immediately notify the sender by reply e-mail and >destroy >all copies of the communication and any attachments. >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From jari.arkko@piuha.net Fri Feb 19 09:28: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 3216F28C24E for ; Fri, 19 Feb 2010 09:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 RXU69z4Azzfv for ; Fri, 19 Feb 2010 09:28:44 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 3BD6F28C0FA for ; Fri, 19 Feb 2010 09:28:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B9A662D290; Fri, 19 Feb 2010 19:30:30 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8MSPDylNwej; Fri, 19 Feb 2010 19:30:30 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 497EB2D257; Fri, 19 Feb 2010 19:30:30 +0200 (EET) Message-ID: <4B7ECAB5.1040705@piuha.net> Date: Fri, 19 Feb 2010 19:30:29 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Joe Touch References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7D9655.1050804@piuha.net> <4B7D9A20.7090403@isi.edu> <4B7D9DB6.60204@piuha.net> <4B7DB867.2000508@isi.edu> In-Reply-To: <4B7DB867.2000508@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 17:28:45 -0000 Joe , > There were various reasons - at least one of which was a desire to > address this issue more broadly for all transports, which is outside the > scope of TCPM and the focus of documenting this issue. > That might be a good approach. But I will note three things. First, AFAIK we are not presently doing this. Should work be started? Second, it is not immediately obvious to me that everything that we have said about TCP applies to other transports. For instance, IMHO it is obvious that Source Quench can be ignored on TCP. But is this obvious for other protocols, e.g., UDP? Third, we can provide more specific guidance on TCP, such as what the effect of ICMPs referring to already acknowledged sequence numbers might be. Given all this, my personal preference is that we at least specify this for TCP. We should probably start more generic work to update the ICMP processing rules as well, but the TCP is the low-hanging fruit. Jari From touch@ISI.EDU Fri Feb 19 09:36:24 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 0E41B28C201 for ; Fri, 19 Feb 2010 09:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 8qaDsz7rzPWf for ; Fri, 19 Feb 2010 09:36:23 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 1E50328C1B1 for ; Fri, 19 Feb 2010 09:36:23 -0800 (PST) Received: from [192.168.1.97] (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 o1JHap0K010979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 09:36:52 -0800 (PST) Message-ID: <4B7ECC33.9060006@isi.edu> Date: Fri, 19 Feb 2010 09:36:51 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7D9655.1050804@piuha.net> <4B7D9A20.7090403@isi.edu> <4B7D9DB6.60204@piuha.net> <4B7DB867.2000508@isi.edu> <4B7ECAB5.1040705@piuha.net> In-Reply-To: <4B7ECAB5.1040705@piuha.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD6DCC976C8B281DF12814A21" X-MailScanner-ID: o1JHap0K010979 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 17:36:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD6DCC976C8B281DF12814A21 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > Joe , >=20 >> There were various reasons - at least one of which was a desire to >> address this issue more broadly for all transports, which is outside t= he >> scope of TCPM and the focus of documenting this issue. >> =20 >=20 > That might be a good approach. >=20 > But I will note three things. First, AFAIK we are not presently doing > this. Should work be started? Second, it is not immediately obvious to > me that everything that we have said about TCP applies to other > transports. For instance, IMHO it is obvious that Source Quench can be > ignored on TCP. But is this obvious for other protocols, e.g., UDP? > Third, we can provide more specific guidance on TCP, such as what the > effect of ICMPs referring to already acknowledged sequence numbers migh= t > be. That one is simply erroneous, and I and others (Bob Braden) have pointed this out at numerous WGs. ICMPs are not required to be returned in a timely fashion, so expecting the sequence numbers to be in-window is simply incorrect. It may help when under attack, but it also breaks legitimate responses from working. It is definitely not in the spirit of "be liberal in what you accept". > Given all this, my personal preference is that we at least specify this= > for TCP. We should probably start more generic work to update the ICMP > processing rules as well, but the TCP is the low-hanging fruit. If we want to make TCP-specific recommendations, we need to limit them to the subset that may be correct and appropriate: - changing hard to soft during a connection though we do need to examine this in detail; I still feel that there are legitimate cases where this interprets valid messages as attack; we may decide that it's OK to throw that behavior out, but we need to explicitly note that - source quench we've needed to deprecate that one for a while Others are not so easy. If we want to split those out, sure. But that is not what the author wanted to do, and that has caused the problem with this doc. Joe --------------enigD6DCC976C8B281DF12814A21 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) iEYEARECAAYFAkt+zDMACgkQE5f5cImnZrsHNwCgkujiRiPNN3OdxpfzdA0wCkY1 d14AnRz2wz+ZmE41X+ulLYwUoB1xesuO =FwOl -----END PGP SIGNATURE----- --------------enigD6DCC976C8B281DF12814A21-- From touch@ISI.EDU Fri Feb 19 09:37: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 95FFB28C1E0; Fri, 19 Feb 2010 09:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 BsMqAhgIvQWo; Fri, 19 Feb 2010 09:37:49 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id A9F1828C1B1; Fri, 19 Feb 2010 09:37:49 -0800 (PST) Received: from [192.168.1.97] (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 o1JHciWL011274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 09:38:45 -0800 (PST) Message-ID: <4B7ECCA3.5000505@isi.edu> Date: Fri, 19 Feb 2010 09:38:43 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7DE6B7.4080209@gont.com.ar> In-Reply-To: <4B7DE6B7.4080209@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB88E664430C81A4315A80713" X-MailScanner-ID: o1JHciWL011274 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 17:37:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB88E664430C81A4315A80713 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >>> This would seem to imply that the TCPM WG has decided to deviate from= >>> the old IETF operating principle of "rough consensus and running code= ". >> The short answer is that there wasn't rough consensus for these change= s >> in the WG, as explained in the note in the text. >=20 > I believe that the short answer is that *you* have done everything that= > was available to stop this document (and others) from moving forward. The doc contains many items, some of which continue to be completely inappropriate and incorrect (checking TCP sequence numbers), where others are somewhat reasonable (port randomization). One problem is that we never agreed on exactly what to focus on recommending, as well as that TCP isn't the only protocol affected by ICMP issues. Another problem is that some of the responses may be appropriate when under attack, but the overall tone of the document is that if a message is "unexpected" it is malicious. That's the antithesis of "be liberal in what you accept". > It is interesting to note that one of the issues with with you have > trashed this I-D is that it used vocabulary that could be taken as the > draft "recommending" the described counter-measures. Yet, as the editor= > of the last version of the (close to infamous) TCP A-O effort, you have= > crafted this text: >=20 > " There are other mechanisms proposed to reduce the impact > of ICMP attacks by further validating ICMP contents and changing the= > effect of some messages based on TCP state" >=20 > Note the use of the term "proposed". (that's specifically what I'm > referring to). Yes, please do note it. "proposed" doesn't mean recommended. The full text is: There are other mechanisms proposed to reduce the impact of ICMP attacks by further validating ICMP contents and changing the effect of some messages based on TCP state, but these do not provide the level of authentication for ICMP that TCP-AO provides for TCP [Go09]. It goes on to include SOME of the recommendations in this doc (but notably not others, even though widely deployed). Note that these latter changes were included because of *your* input *after* last call. Joe --------------enigB88E664430C81A4315A80713 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) iEYEARECAAYFAkt+zKMACgkQE5f5cImnZrvgdQCgtI1+M2PRnFbGV2LJ68DwERiT xh4AoLtc8cTQ4g/yzsPy9FuJUg+/6ca5 =dUA1 -----END PGP SIGNATURE----- --------------enigB88E664430C81A4315A80713-- From touch@ISI.EDU Fri Feb 19 09:59: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 A74AA28C25C for ; Fri, 19 Feb 2010 09:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 bDqN5Xp++moz for ; Fri, 19 Feb 2010 09:59:15 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id F1A3928C2D2 for ; Fri, 19 Feb 2010 09:59:14 -0800 (PST) Received: from [192.168.1.97] (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 o1JHxd25015065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 10:00:24 -0800 (PST) Message-ID: <4B7ED18B.8070304@isi.edu> Date: Fri, 19 Feb 2010 09:59:39 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jari Arkko References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> In-Reply-To: <4B7D8F55.90406@piuha.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC97ACB21F1F9AAA733F89957" X-MailScanner-ID: o1JHxd25015065 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 17:59:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC97ACB21F1F9AAA733F89957 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Jari, Jari Arkko wrote: > Hi, >=20 > This document was recently in IESG review. My opinion is that the > document should be approved as an RFC. Thanks for writing it. >=20 > However, I would like to note the following text from the document: >=20 > The consensus of the TCPM WG (TCP Maintenance and > Minor Extensions Working Group) was to document this widespread > implementation of nonstandard TCP behavior but to not change the TCP > standard. >=20 > This would seem to imply that the TCPM WG has decided to deviate from > the old IETF operating principle of "rough consensus and running code".= > For at least some of the techniques described in this draft, they are > generally accepted and widely implemented on key implementations. I ask= > what the reason is for divorcing IETF standards from established best > practices and actual running code? TCP RFCs are not sacred documents, > they should reflect what we want our implementations to do. But maybe > there are important use cases for the actual standard TCP behavior in > this space, just that I don't know about them. Please educate me about > the background for this decision. The issue, from my view, in TCPM has been a penchant for trying to upturn a long history of "be liberal in what you receive" to react to a number of specific recent threats to TCP. Much of this "rush to react" has led to a perspective that any incoming packet that isn't expected is an indication of *attack*. That could easily lead to changes to TCP that make it inappropriately complex and fragile, at the expense of protecting every home computer from attacks that are typically waged only at routers or other core network components= =2E I agree with Wes that the role of ICMP in the Internet needs to be re-examined, and some changes made. However, I also believe that many of the current TCPM "rush to react" changes (including tcpsecure, some of the ICMP checks, some parts of the TCP cookie transactions proposal) are a poor substitute for the use of true security (IPsec, TCP-AO), which may also need to include more widely-deployable variants with different levels of protection (e.g., BTNS). Yes, I have been the most vocal proponent of this view on TCPM, and perhaps in TSV. I do not believe I represent only myself, however - if that's the "rough consensus", there are mechanisms to override me anyway. It's also useful to note that some of the most vocal proponents of "it's deployed, so let's change the standard" were involved in their deployment. TCP, IMO, ought to be treated with a lot more careful consideration than that. Joe --------------enigC97ACB21F1F9AAA733F89957 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) iEYEARECAAYFAkt+0YsACgkQE5f5cImnZrtTSgCg7txaxqgxM1Cc3D7yLxUd0P1X 7ZoAoK8NfkWYiaqDJmPKyXbdlBv1FCP3 =f0mG -----END PGP SIGNATURE----- --------------enigC97ACB21F1F9AAA733F89957-- From touch@ISI.EDU Fri Feb 19 10:16: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 C855F28C128; Fri, 19 Feb 2010 10:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 X6pH+3VTV7Yw; Fri, 19 Feb 2010 10:16:02 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 010A13A7D1B; Fri, 19 Feb 2010 10:16:01 -0800 (PST) Received: from [192.168.1.97] (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 o1JIHM8G018859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 10:17:24 -0800 (PST) Message-ID: <4B7ED5B2.7090200@isi.edu> Date: Fri, 19 Feb 2010 10:17:22 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7DE6B7.4080209@gont.com.ar> <4B7ECCA3.5000505@isi.edu> In-Reply-To: <4B7ECCA3.5000505@isi.edu> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE9BED059314080E9E34466A0" X-MailScanner-ID: o1JIHM8G018859 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Fernando Gont , iesg@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 18:16:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE9BED059314080E9E34466A0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joe Touch wrote: =2E.. > The full text is: >=20 > There are other mechanisms proposed to reduce the impact of ICMP > attacks by further validating ICMP contents and changing the effect > of some messages based on TCP state, but these do not provide the > level of authentication for ICMP that TCP-AO provides for TCP [Go09]= =2E >=20 > It goes on to include SOME of the recommendations in this doc (but > notably not others, even though widely deployed). Note that these latte= r > changes were included because of *your* input *after* last call. Also note that the changes are considered appropriate in the context of connections protected by TCP-AO, which is intended to be more conservative in what it accepts than TCP by design. They may or may not be appropriate for TCP in general, or may be appropriate, e.g., only during evidence of a repeated attack. Joe --------------enigE9BED059314080E9E34466A0 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) iEYEARECAAYFAkt+1bIACgkQE5f5cImnZrsJ4gCfaPsgoOXEkEnpKg2rUR/O8ewX iiwAoLOCvuvAdLz9ZWAKK8kvCOlfyREa =Kxrq -----END PGP SIGNATURE----- --------------enigE9BED059314080E9E34466A0-- From fernando@gont.com.ar Fri Feb 19 14:21: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 A82993A8032 for ; Fri, 19 Feb 2010 14:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=0.547, 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 1w4FEsv4xsVk for ; Fri, 19 Feb 2010 14:21:06 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id EA78B3A7F21 for ; Fri, 19 Feb 2010 14:21:04 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 8DC596B67E3; Fri, 19 Feb 2010 19:22:55 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1JMMmi7032353; Fri, 19 Feb 2010 19:22:49 -0300 Message-ID: <4B7F0F37.7010502@gont.com.ar> Date: Fri, 19 Feb 2010 19:22:47 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7ED18B.8070304@isi.edu> In-Reply-To: <4B7ED18B.8070304@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 19 Feb 2010 19:22:54 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 22:21:07 -0000 Joe Touch wrote: > Much of this "rush to react" has led to a perspective that any incoming > packet that isn't expected is an indication of *attack*. That could > easily lead to changes to TCP that make it inappropriately complex and > fragile, at the expense of protecting every home computer from attacks > that are typically waged only at routers or other core network components. Joe, your statement (At least wrt icmp attacks) has no correlation with reality. ICMP reset attacks have been pretty usual since the 90's as IRC nuke attacks. i.e., they have been performed mostly against end users, rather than "core network components". Google for "irc nuke", or the like, and I'm sure you'll find 10+ years old icmp exploits. That said, I would call 5+ years a rush... :-)) > I agree with Wes that the role of ICMP in the Internet needs to be > re-examined, and some changes made. However, I also believe that many of > the current TCPM "rush to react" changes (including tcpsecure, some of > the ICMP checks, some parts of the TCP cookie transactions proposal) are > a poor substitute for the use of true security (IPsec, TCP-AO), They are not a substitute. And the recent support by Ran Atkinson (co-author of previous versions of the IPsec std) should be a good hint. See: http://www.ietf.org/mail-archive/web/ietf/current/msg60159.html I don't really think anybody could call himself a "good engineer" if he enabled IPsec just to mitigate the off-path attacks we have been discussing in the last few years, when there are general and lightweight mitigations for them. > which > may also need to include more widely-deployable variants with different > levels of protection (e.g., BTNS). Side note: I wonder what would be the result if you submitted BTNS to the same level of "correctness evaluation" as you have submitted this I-D... (Maybe the "BTNS" acronym is an implicit acknowledgement of that?) > Yes, I have been the most vocal proponent of this view on TCPM, and > perhaps in TSV. I do not believe I represent only myself, however - if > that's the "rough consensus", there are mechanisms to override me > anyway. It's also useful to note that some of the most vocal proponents > of "it's deployed, so let's change the standard" were involved in their > deployment. Joe, I was involved in the deployment of "ignore source quenches" and the PMTUD fix, only The TCP SEQ check had already been incorporated in Linux years ago, and was incorporated in lots of other stacks as a result of my I-D, rather than my "code". And if you want to "blame" somebody for the hard errors -> soft errors, you should probably "blame" Mike Karels -- me, I'm thankful for his work. FWIW, this behavior has been deployed for more than fifteen years. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando@gont.com.ar Fri Feb 19 14:30:00 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 8803428C175; Fri, 19 Feb 2010 14:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.065 X-Spam-Level: X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=0.534, 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 rjluCFhritpH; Fri, 19 Feb 2010 14:29:59 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 3EF5828C12F; Fri, 19 Feb 2010 14:29:57 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id E94D16B679C; Fri, 19 Feb 2010 19:31:48 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1JMVgYW007383; Fri, 19 Feb 2010 19:31:42 -0300 Message-ID: <4B7F114D.6050409@gont.com.ar> Date: Fri, 19 Feb 2010 19:31:41 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7DE6B7.4080209@gont.com.ar> <4B7ECCA3.5000505@isi.edu> In-Reply-To: <4B7ECCA3.5000505@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 19 Feb 2010 19:31:48 -0300 (ART) Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 22:30:00 -0000 Joe Touch wrote: >> It is interesting to note that one of the issues with with you have >> trashed this I-D is that it used vocabulary that could be taken as the >> draft "recommending" the described counter-measures. Yet, as the editor >> of the last version of the (close to infamous) TCP A-O effort, you have >> crafted this text: >> >> " There are other mechanisms proposed to reduce the impact >> of ICMP attacks by further validating ICMP contents and changing the >> effect of some messages based on TCP state" >> >> Note the use of the term "proposed". (that's specifically what I'm >> referring to). > > Yes, please do note it. "proposed" doesn't mean recommended. Are you serious? Do I really have to go through the mailing-list archive to provide you with a list of all those times in which you trashed the doc for the instances of terms such as "proposed", "propose", etc.? > The full text is: > > There are other mechanisms proposed to reduce the impact of ICMP > attacks by further validating ICMP contents and changing the effect > of some messages based on TCP state, but these do not provide the > level of authentication for ICMP that TCP-AO provides for TCP [Go09]. > > It goes on to include SOME of the recommendations in this doc (but > notably not others, even though widely deployed). Note that these latter > changes were included because of *your* input *after* last call. That's not the point I'm making. I'm saying that TCP-AO says "There are other mechanism proposed". And if *you* were to review TCP-AO with the same perspective with which you have reviewed icmp-attacks, you would have said "NO! icmp-attacks *describes* or *documents*... it doesn't 'propose' anything... blah blah..". I don't care myself about the wording you used. And when it comes to addressing my input, you did a really good job. -- I just wonder why it's hard to have you in the same "operation mode" when you're not the author of the document being discussed. Last, but not least, I made exactly the same comments (wrt TCP-AO and ICMP attacks) ages ago (way before LC)... but you simply ignored my comments, as other people has claimed you ignored theirs' when editing the TCP-AO I-D. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Fri Feb 19 14:35: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 334A328C105 for ; Fri, 19 Feb 2010 14:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 DJPLYKqKH4Ur for ; Fri, 19 Feb 2010 14:35:58 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 5D17728C0DD for ; Fri, 19 Feb 2010 14:35:58 -0800 (PST) Received: from [192.168.1.97] (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 o1JMa89E011021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 14:36:09 -0800 (PST) Message-ID: <4B7F1258.5060301@isi.edu> Date: Fri, 19 Feb 2010 14:36:08 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7ED18B.8070304@isi.edu> <4B7F0F37.7010502@gont.com.ar> In-Reply-To: <4B7F0F37.7010502@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F4FD46CDEC58C34F572EC1D" X-MailScanner-ID: o1JMa89E011021 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 22:35:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F4FD46CDEC58C34F572EC1D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >> Much of this "rush to react" has led to a perspective that any incomin= g >> packet that isn't expected is an indication of *attack*. That could >> easily lead to changes to TCP that make it inappropriately complex and= >> fragile, at the expense of protecting every home computer from attacks= >> that are typically waged only at routers or other core network compone= nts. >=20 > Joe, your statement (At least wrt icmp attacks) has no correlation with= > reality. >=20 > ICMP reset attacks have been pretty usual since the 90's as IRC nuke > attacks. i.e., they have been performed mostly against end users, rathe= r > than "core network components". Google for "irc nuke", or the like, and= > I'm sure you'll find 10+ years old icmp exploits. Useful to include in your doc. Not cited, I note. Yours is not the only document you have accused me of impeding. It would be useful to reconsider my post in the context of the totality of work it addresses (including the comment about being involved in deployment). >> I agree with Wes that the role of ICMP in the Internet needs to be >> re-examined, and some changes made. However, I also believe that many = of >> the current TCPM "rush to react" changes (including tcpsecure, some of= >> the ICMP checks, some parts of the TCP cookie transactions proposal) a= re >> a poor substitute for the use of true security (IPsec, TCP-AO),=20 >=20 > They are not a substitute. And the recent support by Ran Atkinson > (co-author of previous versions of the IPsec std) should be a good hint= =2E > See: http://www.ietf.org/mail-archive/web/ietf/current/msg60159.html Note that he supports this as offered - Informational. >> which >> may also need to include more widely-deployable variants with differen= t >> levels of protection (e.g., BTNS). >=20 > Side note: I wonder what would be the result if you submitted BTNS to > the same level of "correctness evaluation" as you have submitted this I= -D... > (Maybe the "BTNS" acronym is an implicit acknowledgement of that?) BTNS doesn't redefine the core, *non-secure* TCP service for everyone. Joe --------------enig8F4FD46CDEC58C34F572EC1D 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) iEYEARECAAYFAkt/ElgACgkQE5f5cImnZrt/oACfcTi4EDDPje/61gCNCGsWJN6D 6FAAoLNXFcl5VCkqJGkjO3kH9wUS1MQk =hxtr -----END PGP SIGNATURE----- --------------enig8F4FD46CDEC58C34F572EC1D-- From touch@ISI.EDU Fri Feb 19 14:42: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 2D58D28C153; Fri, 19 Feb 2010 14:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 aa-B0lUC5Gp5; Fri, 19 Feb 2010 14:42:37 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 3E2B228C12F; Fri, 19 Feb 2010 14:42:37 -0800 (PST) Received: from [192.168.1.97] (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 o1JMhg6U012432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 14:43:43 -0800 (PST) Message-ID: <4B7F141E.30808@isi.edu> Date: Fri, 19 Feb 2010 14:43:42 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7DE6B7.4080209@gont.com.ar> <4B7ECCA3.5000505@isi.edu> <4B7F114D.6050409@gont.com.ar> In-Reply-To: <4B7F114D.6050409@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6005F8EA60091C29E10DC071" X-MailScanner-ID: o1JMhg6U012432 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 22:42:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6005F8EA60091C29E10DC071 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >>> It is interesting to note that one of the issues with with you have >>> trashed this I-D is that it used vocabulary that could be taken as th= e >>> draft "recommending" the described counter-measures. Yet, as the edit= or >>> of the last version of the (close to infamous) TCP A-O effort, you ha= ve >>> crafted this text: >>> >>> " There are other mechanisms proposed to reduce the impact >>> of ICMP attacks by further validating ICMP contents and changing t= he >>> effect of some messages based on TCP state" >>> >>> Note the use of the term "proposed". (that's specifically what I'm >>> referring to). >> Yes, please do note it. "proposed" doesn't mean recommended. >=20 > Are you serious? Do I really have to go through the mailing-list archiv= e > to provide you with a list of all those times in which you trashed the > doc for the instances of terms such as "proposed", "propose", etc.? There is a difference between "there are mechanisms [that are] proposed" and "this document proposes". The text in AO was unchanged since the -00 version (Nov 2007). You waited until after last call to complain about adding specific calls for ICMP actions. If you want to now complain that we remove the word "proposed" (would you prefer 'described'), I can do that rev. >> The full text is: >> >> There are other mechanisms proposed to reduce the impact of ICMP >> attacks by further validating ICMP contents and changing the effect= >> of some messages based on TCP state, but these do not provide the >> level of authentication for ICMP that TCP-AO provides for TCP [Go09= ]. >> >> It goes on to include SOME of the recommendations in this doc (but >> notably not others, even though widely deployed). Note that these latt= er >> changes were included because of *your* input *after* last call. >=20 > That's not the point I'm making. I'm saying that TCP-AO says "There are= > other mechanism proposed". And if *you* were to review TCP-AO with the > same perspective with which you have reviewed icmp-attacks, you would > have said "NO! icmp-attacks *describes* or *documents*... it doesn't > 'propose' anything... blah blah..". I didn't say "the icmp doc proposes" - I said "[that are] proposed" (i.e., the omitted words are implied). I didn't say who proposed them - they're clearly proposed by someone. In fact, I wouldn't care if your doc says "some people have proposed" or "the implementation in X proposes= ". My objection was "**THIS** document proposes". That ends op saying that the WG proposes, since it was a WG doc. The WG decided *not* to "propose"= =2E I used the same mode here, but the English is admittedly a bit subtle. I admit that I take that for granted as a native speaker, perhaps more than I should. I'd be glad to explain further, either on or off list, if useful. > Last, but not least, I made exactly the same comments (wrt TCP-AO and > ICMP attacks) ages ago (way before LC)... but you simply ignored my > comments, as other people has claimed you ignored theirs' when editing > the TCP-AO I-D. I didn't ignore the comments - they didn't have "rough consensus". Not every proposed change by an individual necessarily makes it into a doc - you and I both know that. Joe --------------enig6005F8EA60091C29E10DC071 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) iEYEARECAAYFAkt/FB4ACgkQE5f5cImnZrtDswCeLKF1/ZMoL1b8snpjP47OyAP9 H6cAnjfB/Aj1i9DhB1LlKKZjQYP8SN90 =LGAO -----END PGP SIGNATURE----- --------------enig6005F8EA60091C29E10DC071-- From fernando@gont.com.ar Fri Feb 19 14:50: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 F2DF328C100 for ; Fri, 19 Feb 2010 14:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.078 X-Spam-Level: X-Spam-Status: No, score=-3.078 tagged_above=-999 required=5 tests=[AWL=0.521, 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 WK9NHCU-b22w for ; Fri, 19 Feb 2010 14:50:41 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id E669B3A7F00 for ; Fri, 19 Feb 2010 14:50:39 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id BB6116B67E7; Fri, 19 Feb 2010 19:52:31 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1JMqPVv017783; Fri, 19 Feb 2010 19:52:25 -0300 Message-ID: <4B7F1628.6030205@gont.com.ar> Date: Fri, 19 Feb 2010 19:52:24 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7ED18B.8070304@isi.edu> <4B7F0F37.7010502@gont.com.ar> <4B7F1258.5060301@isi.edu> In-Reply-To: <4B7F1258.5060301@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 19 Feb 2010 19:52:30 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 22:50:42 -0000 Joe Touch wrote: >>> I agree with Wes that the role of ICMP in the Internet needs to be >>> re-examined, and some changes made. However, I also believe that many of >>> the current TCPM "rush to react" changes (including tcpsecure, some of >>> the ICMP checks, some parts of the TCP cookie transactions proposal) are >>> a poor substitute for the use of true security (IPsec, TCP-AO), >> They are not a substitute. And the recent support by Ran Atkinson >> (co-author of previous versions of the IPsec std) should be a good hint. >> See: http://www.ietf.org/mail-archive/web/ietf/current/msg60159.html > > Note that he supports this as offered - Informational. That's incorrect. Go ask Ran Atkinson. >>> which >>> may also need to include more widely-deployable variants with different >>> levels of protection (e.g., BTNS). >> Side note: I wonder what would be the result if you submitted BTNS to >> the same level of "correctness evaluation" as you have submitted this I-D... >> (Maybe the "BTNS" acronym is an implicit acknowledgement of that?) > > BTNS doesn't redefine the core, *non-secure* TCP service for everyone. icmp-attacks does not, either. It changes a protocol policy. It doesn't redefine any service -- TCP is still a connection-oriented realiable byte-stream protocol. So I don't see your point. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Fri Feb 19 15:01: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 BD3E428C1C3 for ; Fri, 19 Feb 2010 15:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 j-iZUrCPQBTC for ; Fri, 19 Feb 2010 15:01:21 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 7DFB428B23E for ; Fri, 19 Feb 2010 15:01:21 -0800 (PST) Received: from [192.168.1.97] (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 o1JN2WME016041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 15:02:33 -0800 (PST) Message-ID: <4B7F1888.5080907@isi.edu> Date: Fri, 19 Feb 2010 15:02:32 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7ED18B.8070304@isi.edu> <4B7F0F37.7010502@gont.com.ar> <4B7F1258.5060301@isi.edu> <4B7F1628.6030205@gont.com.ar> In-Reply-To: <4B7F1628.6030205@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAC021DE9DEE44F09999DABA5" X-MailScanner-ID: o1JN2WME016041 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 23:01:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAC021DE9DEE44F09999DABA5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >>>> I agree with Wes that the role of ICMP in the Internet needs to be >>>> re-examined, and some changes made. However, I also believe that man= y of >>>> the current TCPM "rush to react" changes (including tcpsecure, some = of >>>> the ICMP checks, some parts of the TCP cookie transactions proposal)= are >>>> a poor substitute for the use of true security (IPsec, TCP-AO),=20 >>> They are not a substitute. And the recent support by Ran Atkinson >>> (co-author of previous versions of the IPsec std) should be a good hi= nt. >>> See: http://www.ietf.org/mail-archive/web/ietf/current/msg60159.html >> Note that he supports this as offered - Informational. >=20 > That's incorrect. Go ask Ran Atkinson. =46rom the URL *you* provided: "I have reviewed this document and I support publishing it as an Informational RFC." >>>> which >>>> may also need to include more widely-deployable variants with differ= ent >>>> levels of protection (e.g., BTNS). >>> Side note: I wonder what would be the result if you submitted BTNS to= >>> the same level of "correctness evaluation" as you have submitted this= I-D... >>> (Maybe the "BTNS" acronym is an implicit acknowledgement of that?) >> BTNS doesn't redefine the core, *non-secure* TCP service for everyone.= >=20 > icmp-attacks does not, either. It changes a protocol policy. It doesn't= > redefine any service -- TCP is still a connection-oriented realiable > byte-stream protocol. So I don't see your point. icmp-attacks discusses changes TCP for everyone, not just for those who enable a particular form, or while under attack. BTNS is a specific variant of IPsec that is not what you get by default. Joe --------------enigAC021DE9DEE44F09999DABA5 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) iEYEARECAAYFAkt/GIgACgkQE5f5cImnZrtATwCcDMFMorHDF6IC702/Ytr0gSeE HBYAn00KkXE1kZyoKjMW8lpdfGj7Y9Yd =h1VS -----END PGP SIGNATURE----- --------------enigAC021DE9DEE44F09999DABA5-- From fernando@gont.com.ar Fri Feb 19 15:02: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 9B1F228C1A1; Fri, 19 Feb 2010 15:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=0.508, 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 3WtEIoDsS1vQ; Fri, 19 Feb 2010 15:02:42 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 4964228B23E; Fri, 19 Feb 2010 15:02:40 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D7E836B67E3; Fri, 19 Feb 2010 20:04:31 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1JN4P2D027112; Fri, 19 Feb 2010 20:04:26 -0300 Message-ID: <4B7F18F9.3030505@gont.com.ar> Date: Fri, 19 Feb 2010 20:04:25 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7DE6B7.4080209@gont.com.ar> <4B7ECCA3.5000505@isi.edu> <4B7F114D.6050409@gont.com.ar> <4B7F141E.30808@isi.edu> In-Reply-To: <4B7F141E.30808@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 19 Feb 2010 20:04:31 -0300 (ART) Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 23:02:43 -0000 Joe Touch wrote: >>> Yes, please do note it. "proposed" doesn't mean recommended. >> Are you serious? Do I really have to go through the mailing-list archive >> to provide you with a list of all those times in which you trashed the >> doc for the instances of terms such as "proposed", "propose", etc.? > > There is a difference between "there are mechanisms [that are] proposed" > and "this document proposes". Don't both of them imply the same thing????!??? :-) > The text in AO was unchanged since the -00 version (Nov 2007). You > waited until after last call to complain about adding specific calls for > ICMP actions. Look at this: http://www.ietf.org/mail-archive/web/tcpm/current/msg04593.html Is June 16th, 2009 what you call last-minute??????? > If you want to now complain that we remove the word > "proposed" (would you prefer 'described'), I can do that rev. No, Joe. That's the game *you* like to play, not me. As far as I'm concerned, you can leave the text "as is". >> Last, but not least, I made exactly the same comments (wrt TCP-AO and >> ICMP attacks) ages ago (way before LC)... but you simply ignored my >> comments, as other people has claimed you ignored theirs' when editing >> the TCP-AO I-D. > > I didn't ignore the comments - they didn't have "rough consensus". Not > every proposed change by an individual necessarily makes it into a doc - > you and I both know that. I could give a long response here... but I have had enough. Anybody that hsa participated in tcpm since its creation can probably guess a (or craft their own ;-) ) response to this comment. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Fri Feb 19 15:12:00 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 9E1573A7B24; Fri, 19 Feb 2010 15:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 FonPek85NxLb; Fri, 19 Feb 2010 15:11:59 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 6AB223A79F4; Fri, 19 Feb 2010 15:11:59 -0800 (PST) Received: from [192.168.1.97] (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 o1JNDEUx017768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 15:13:15 -0800 (PST) Message-ID: <4B7F1B0A.304@isi.edu> Date: Fri, 19 Feb 2010 15:13:14 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7DE6B7.4080209@gont.com.ar> <4B7ECCA3.5000505@isi.edu> <4B7F114D.6050409@gont.com.ar> <4B7F141E.30808@isi.edu> <4B7F18F9.3030505@gont.com.ar> In-Reply-To: <4B7F18F9.3030505@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF92652274AEF061C78813DF2" X-MailScanner-ID: o1JNDEUx017768 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 23:12:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF92652274AEF061C78813DF2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >>>> Yes, please do note it. "proposed" doesn't mean recommended. >>> Are you serious? Do I really have to go through the mailing-list arch= ive >>> to provide you with a list of all those times in which you trashed th= e >>> doc for the instances of terms such as "proposed", "propose", etc.? >> >> There is a difference between "there are mechanisms [that are] propose= d" >> and "this document proposes". >=20 > Don't both of them imply the same thing????!??? :-) No, they do not. The WG cannot prevent others from proposing something, but it makes its own decisions on what to propose. >> The text in AO was unchanged since the -00 version (Nov 2007). You >> waited until after last call to complain about adding specific calls f= or >> ICMP actions.=20 >=20 > Look at this: > http://www.ietf.org/mail-archive/web/tcpm/current/msg04593.html >=20 > Is June 16th, 2009 what you call last-minute??????? It was raised as you cite, discussed at the WG meeting in Stockholm, and we proceeding with the result from that meeting (see slide 8). There was then a last call, at which you did not yet again raise the issue. Joe --------------enigF92652274AEF061C78813DF2 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) iEYEARECAAYFAkt/GwoACgkQE5f5cImnZrspNgCeNW2tN2y5BFrIVBtqp1SsxCS1 qDIAniZvf6nKK3faCIo0SIp2HUSsrmA1 =fFeD -----END PGP SIGNATURE----- --------------enigF92652274AEF061C78813DF2-- From fernando@gont.com.ar Fri Feb 19 15:13:03 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 1D61B3A7B24 for ; Fri, 19 Feb 2010 15:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=0.496, 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 ksn09PkBj494 for ; Fri, 19 Feb 2010 15:13:02 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id B47253A79F4 for ; Fri, 19 Feb 2010 15:13:00 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id BC3B46B65FD; Fri, 19 Feb 2010 20:14:52 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1JNEkhw029970; Fri, 19 Feb 2010 20:14:47 -0300 Message-ID: <4B7F1B65.5080507@gont.com.ar> Date: Fri, 19 Feb 2010 20:14:45 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7ED18B.8070304@isi.edu> <4B7F0F37.7010502@gont.com.ar> <4B7F1258.5060301@isi.edu> <4B7F1628.6030205@gont.com.ar> <4B7F1888.5080907@isi.edu> In-Reply-To: <4B7F1888.5080907@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 19 Feb 2010 20:14:52 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 23:13:03 -0000 Joe Touch wrote: >>>>> I agree with Wes that the role of ICMP in the Internet needs to be >>>>> re-examined, and some changes made. However, I also believe that many of >>>>> the current TCPM "rush to react" changes (including tcpsecure, some of >>>>> the ICMP checks, some parts of the TCP cookie transactions proposal) are >>>>> a poor substitute for the use of true security (IPsec, TCP-AO), >>>> They are not a substitute. And the recent support by Ran Atkinson >>>> (co-author of previous versions of the IPsec std) should be a good hint. >>>> See: http://www.ietf.org/mail-archive/web/ietf/current/msg60159.html >>> Note that he supports this as offered - Informational. >> That's incorrect. Go ask Ran Atkinson. > > From the URL *you* provided: > > "I have reviewed this document and I support publishing it as > an Informational RFC." Again, go and ask Ran about this I-D. Please. BTW, Ran said: "F. Gont has done a tremendous public service in putting together this (and predecessor) documents with risk analyses for various widely deployed protocols." And you have trashed each of the documents he's referring to (including icmp-attacks, draft-ietf-tcpm-tcp-security, etc.). Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From root@core3.amsl.com Fri Feb 19 15:15:02 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 057453A79F4; Fri, 19 Feb 2010 15:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100219231502.057453A79F4@core3.amsl.com> Date: Fri, 19 Feb 2010 15:15:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-security-01.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: Fri, 19 Feb 2010 23:15:02 -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 : Security Assessment of the Transmission Control Protocol (TCP) Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-security-01.txt Pages : 29 Date : 2010-02-19 This document contains a security assessment of the specifications of the Transmission Control Protocol (TCP), and of a number of mechanisms and policies in use by popular TCP implementations. Additionally, it contains best current practices for hardening a TCP implementation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-security-01.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-security-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-19151315.I-D@ietf.org> --NextPart-- From fernando@gont.com.ar Fri Feb 19 15:16:08 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 257C43A6CED; Fri, 19 Feb 2010 15:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=0.485, 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 RBIP8nrOsmWe; Fri, 19 Feb 2010 15:16:07 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 1AC1528C0F9; Fri, 19 Feb 2010 15:16:05 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2059D6B670F; Fri, 19 Feb 2010 20:17:57 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1JNHoPZ030485; Fri, 19 Feb 2010 20:17:51 -0300 Message-ID: <4B7F1C1E.4010605@gont.com.ar> Date: Fri, 19 Feb 2010 20:17:50 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7DE6B7.4080209@gont.com.ar> <4B7ECCA3.5000505@isi.edu> <4B7F114D.6050409@gont.com.ar> <4B7F141E.30808@isi.edu> <4B7F18F9.3030505@gont.com.ar> <4B7F1B0A.304@isi.edu> In-Reply-To: <4B7F1B0A.304@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 19 Feb 2010 20:17:56 -0300 (ART) Cc: tcpm@ietf.org, iesg@ietf.org Subject: [tcpm] TCP-AO (was: Re: TCPM and draft-ietf-tcpm-icmp-attacks) 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, 19 Feb 2010 23:16:08 -0000 Joe Touch wrote: >>> The text in AO was unchanged since the -00 version (Nov 2007). You >>> waited until after last call to complain about adding specific calls for >>> ICMP actions. >> Look at this: >> http://www.ietf.org/mail-archive/web/tcpm/current/msg04593.html >> >> Is June 16th, 2009 what you call last-minute??????? > > It was raised as you cite, discussed at the WG meeting in Stockholm, and > we proceeding with the result from that meeting (see slide 8). We proceeded with the result of that meeting? :-) I thought the mailing-list were important in the IETF process. Maybe I'm just missing something? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Fri Feb 19 15:21:09 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 9A40C3A8030 for ; Fri, 19 Feb 2010 15:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 Bol0AKRSoaDi for ; Fri, 19 Feb 2010 15:21:08 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 9B8D43A802D for ; Fri, 19 Feb 2010 15:21:08 -0800 (PST) Received: from [192.168.1.97] (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 o1JNMnMq019269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 15:22:50 -0800 (PST) Message-ID: <4B7F1D49.10804@isi.edu> Date: Fri, 19 Feb 2010 15:22:49 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7ED18B.8070304@isi.edu> <4B7F0F37.7010502@gont.com.ar> <4B7F1258.5060301@isi.edu> <4B7F1628.6030205@gont.com.ar> <4B7F1888.5080907@isi.edu> <4B7F1B65.5080507@gont.com.ar> In-Reply-To: <4B7F1B65.5080507@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEAA468B4B6F1AE9A1DAEE100" X-MailScanner-ID: o1JNMnMq019269 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 23:21:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEAA468B4B6F1AE9A1DAEE100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >>>>>> I agree with Wes that the role of ICMP in the Internet needs to be= >>>>>> re-examined, and some changes made. However, I also believe that m= any of >>>>>> the current TCPM "rush to react" changes (including tcpsecure, som= e of >>>>>> the ICMP checks, some parts of the TCP cookie transactions proposa= l) are >>>>>> a poor substitute for the use of true security (IPsec, TCP-AO),=20 >>>>> They are not a substitute. And the recent support by Ran Atkinson >>>>> (co-author of previous versions of the IPsec std) should be a good = hint. >>>>> See: http://www.ietf.org/mail-archive/web/ietf/current/msg60159.htm= l >>>> Note that he supports this as offered - Informational. >>> That's incorrect. Go ask Ran Atkinson. >> From the URL *you* provided: >> >> "I have reviewed this document and I support publishing it as >> an Informational RFC." >=20 > Again, go and ask Ran about this I-D. Please. >=20 > BTW, Ran said: "F. Gont has done a tremendous public service in putting= > together this (and predecessor) documents with risk analyses for variou= s > widely deployed protocols." The entire quote has both parts, and directly cites Informational. I have reviewed this document and I support publishing it as an Informational RFC. F. Gont has done a tremendous public service in putting together this (and predecessor) documents with risk analyses for various widely deployed protocols. > And you have trashed each of the documents he's referring to (including= > icmp-attacks, draft-ietf-tcpm-tcp-security, etc.). I have criticized these documents for proposing changes to standards; I do not have an issue with merely documenting those changes. Joe --------------enigEAA468B4B6F1AE9A1DAEE100 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) iEYEARECAAYFAkt/HUkACgkQE5f5cImnZrtsCACgoFpU2/hMtH5EpPIOy8jpWlVx RiQAn1W9iYGiwitC/tTNcr1D5+l5eji3 =Rpj5 -----END PGP SIGNATURE----- --------------enigEAA468B4B6F1AE9A1DAEE100-- From touch@ISI.EDU Fri Feb 19 15:34: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 858363A7A59; Fri, 19 Feb 2010 15:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 z8DtOR+kkWh1; Fri, 19 Feb 2010 15:34:43 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id B14A53A75BD; Fri, 19 Feb 2010 15:34:43 -0800 (PST) Received: from [192.168.1.97] (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 o1JNZNCh020908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 15:35:24 -0800 (PST) Message-ID: <4B7F203B.5080609@isi.edu> Date: Fri, 19 Feb 2010 15:35:23 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7D92EB.7010407@isi.edu> <4B7DE6B7.4080209@gont.com.ar> <4B7ECCA3.5000505@isi.edu> <4B7F114D.6050409@gont.com.ar> <4B7F141E.30808@isi.edu> <4B7F18F9.3030505@gont.com.ar> <4B7F1B0A.304@isi.edu> <4B7F1C1E.4010605@gont.com.ar> In-Reply-To: <4B7F1C1E.4010605@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2B0497FA3156B5A17424CC17" X-MailScanner-ID: o1JNZNCh020908 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] 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: Fri, 19 Feb 2010 23:34:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2B0497FA3156B5A17424CC17 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >>>> The text in AO was unchanged since the -00 version (Nov 2007). You >>>> waited until after last call to complain about adding specific calls= for >>>> ICMP actions.=20 >>> Look at this: >>> http://www.ietf.org/mail-archive/web/tcpm/current/msg04593.html >>> >>> Is June 16th, 2009 what you call last-minute??????? >> It was raised as you cite, discussed at the WG meeting in Stockholm, a= nd >> we proceeding with the result from that meeting (see slide 8).=20 >=20 > We proceeded with the result of that meeting? OK. Let me be *very* specific. The issue was discussed on the list - see my summary of the debate we had and a call for additional input: http://www.ietf.org/mail-archive/web/tcpm/current/msg04604.html Nobody else weighed in. At that point TCP-AO had the same recommendation as IPsec (standards-track), and did not include specific indications (as per your informational-track doc). I asked for input at the WG meeting in Stockholm, and the notes indicate:= - Issues raised =96 ICMP handling o No need to do more than IPsec I raised the issue, and we did not have any additional concerns raised at the meeting. We did not make a new decision on this at the meeting. Joe --------------enig2B0497FA3156B5A17424CC17 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) iEYEARECAAYFAkt/IDsACgkQE5f5cImnZrskLwCfdK8YBRqAHGk3nsMyotdIYzJZ FiQAoPqX0zVrz1fOmcbrO/2mYSqjq3Vb =ylD8 -----END PGP SIGNATURE----- --------------enig2B0497FA3156B5A17424CC17-- From Donald.Smith@qwest.com Fri Feb 19 15:40: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 9191B3A7B89 for ; Fri, 19 Feb 2010 15:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.532, 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 ffqi91iVG+NR for ; Fri, 19 Feb 2010 15:40:31 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id A94043A7A59 for ; Fri, 19 Feb 2010 15:40:31 -0800 (PST) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o1JNgFJl012159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2010 17:42:16 -0600 (CST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id o1JNg9nf028024; Fri, 19 Feb 2010 17:42:10 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Fri, 19 Feb 2010 16:42:09 -0700 From: "Smith, Donald" To: Joe Touch , Fernando Gont Date: Fri, 19 Feb 2010 16:42:08 -0700 Thread-Topic: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks Thread-Index: Acqxun2uqt9+W7kuTEi0QoLz0oLGmwAAW4bd Message-ID: References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7ED18B.8070304@isi.edu> <4B7F0F37.7010502@gont.com.ar> <4B7F1258.5060301@isi.edu> <4B7F1628.6030205@gont.com.ar> <4B7F1888.5080907@isi.edu> <4B7F1B65.5080507@gont.com.ar>,<4B7F1D49.10804@isi.edu> In-Reply-To: <4B7F1D49.10804@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 23:40:32 -0000 Top posting, I too support this as an Informational RFC HOWEVER I would hav= e rather supported it as a standard. So supporting this as an informational RFC does NOT mean Ran or anyone else= would not have supported it as a standard which seems to be the conclusion= Joe is making. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe Touch = [touch@ISI.EDU] Sent: Friday, February 19, 2010 4:22 PM To: Fernando Gont Cc: tcpm@ietf.org Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks Fernando Gont wrote: > Joe Touch wrote: > >>>>>> I agree with Wes that the role of ICMP in the Internet needs to be >>>>>> re-examined, and some changes made. However, I also believe that man= y of >>>>>> the current TCPM "rush to react" changes (including tcpsecure, some = of >>>>>> the ICMP checks, some parts of the TCP cookie transactions proposal)= are >>>>>> a poor substitute for the use of true security (IPsec, TCP-AO), >>>>> They are not a substitute. And the recent support by Ran Atkinson >>>>> (co-author of previous versions of the IPsec std) should be a good hi= nt. >>>>> See: http://www.ietf.org/mail-archive/web/ietf/current/msg60159.html >>>> Note that he supports this as offered - Informational. >>> That's incorrect. Go ask Ran Atkinson. >> From the URL *you* provided: >> >> "I have reviewed this document and I support publishing it as >> an Informational RFC." > > Again, go and ask Ran about this I-D. Please. > > BTW, Ran said: "F. Gont has done a tremendous public service in putting > together this (and predecessor) documents with risk analyses for various > widely deployed protocols." The entire quote has both parts, and directly cites Informational. I have reviewed this document and I support publishing it as an Informational RFC. F. Gont has done a tremendous public service in putting together this (and predecessor) documents with risk analyses for various widely deployed protocols. > And you have trashed each of the documents he's referring to (including > icmp-attacks, draft-ietf-tcpm-tcp-security, etc.). I have criticized these documents for proposing changes to standards; I do not have an issue with merely documenting those changes. Joe This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From touch@ISI.EDU Fri Feb 19 15:49:09 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 EC7DA3A7B89 for ; Fri, 19 Feb 2010 15:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 mCwVkQVaKrAs for ; Fri, 19 Feb 2010 15:49:09 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 35ED93A7A59 for ; Fri, 19 Feb 2010 15:49:09 -0800 (PST) Received: from [192.168.1.97] (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 o1JNofOH023549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 15:50:42 -0800 (PST) Message-ID: <4B7F23D0.9080900@isi.edu> Date: Fri, 19 Feb 2010 15:50:40 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net> <4B7ED18B.8070304@isi.edu> <4B7F0F37.7010502@gont.com.ar> <4B7F1258.5060301@isi.edu> <4B7F1628.6030205@gont.com.ar> <4B7F1888.5080907@isi.edu> <4B7F1B65.5080507@gont.com.ar>, <4B7F1D49.10804@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4D14845530A66147027B44BF" X-MailScanner-ID: o1JNofOH023549 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks 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, 19 Feb 2010 23:49:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4D14845530A66147027B44BF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Smith, Donald wrote: > Top posting, I too support this as an Informational RFC HOWEVER I would= have rather supported it as a standard. > So supporting this as an informational RFC does NOT mean Ran or anyone = else would not have supported it as a standard which seems to be the conc= lusion Joe is making. We would need to ask whether *each* of the changes proposed is something we agree to be standard. As I already noted, and Wes reiterated, there are other reasons for not doing this in the context of this doc - esp. because some of these changes really ought to be considered in the context of all transports, not just TCP, where others are specific to TCP. If we want to go back and split these out, that's a way forward. However, publishing this as informational doesn't preclude that as a separate path Joe --------------enig4D14845530A66147027B44BF 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) iEYEARECAAYFAkt/I9AACgkQE5f5cImnZrsUcwCgqj0/BzGvrSqRovTp2WuRtK68 3YkAoKf4h08zc76VGwG+JUi0r7tkcO8A =XMLK -----END PGP SIGNATURE----- --------------enig4D14845530A66147027B44BF-- From fernando@gont.com.ar Fri Feb 19 16:08: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 CEBA23A787A for ; Fri, 19 Feb 2010 16:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=0.474, 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 66MSc136kcAG for ; Fri, 19 Feb 2010 16:08:58 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id DE2AE3A76D8 for ; Fri, 19 Feb 2010 16:08:56 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id F06836B6807 for ; Fri, 19 Feb 2010 21:10:48 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1K0AgRu027190; Fri, 19 Feb 2010 21:10:43 -0300 Message-ID: <4B7F2881.7000700@gont.com.ar> Date: Fri, 19 Feb 2010 21:10:41 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 19 Feb 2010 21:10:48 -0300 (ART) Subject: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 20 Feb 2010 00:08:58 -0000 Folks, I have just posted a revision (-01) of draft-ietf-tcpm-tcp-security. The document is available at the usual places (including: http://tools.ietf.org/id/draft-ietf-tcpm-tcp-security-01.txt). The current plan is discuss each section of the draft piecemeal (it is a very large document), get consensus on the changes to apply to the existing text, and then move on to the next section. Therefore I'm requesting feedback on all the sections through Section 3.1.2.3. -- this includes the introduction sections, the basic check on the TCP segment size (Section 3) and the discussion of port numbers (Section 3.1 with all its subsections). Please review these sections and submit comments by Friday March 5th, 2010, so that we can move on to the next sections in a timely manner. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From root@core3.amsl.com Fri Feb 19 21:15:02 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 C27613A80AC; Fri, 19 Feb 2010 21:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100220051502.C27613A80AC@core3.amsl.com> Date: Fri, 19 Feb 2010 21:15:02 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-urgent-data-03.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: Sat, 20 Feb 2010 05:15: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 : On the implementation of the TCP urgent mechanism Author(s) : F. Gont, A. Yourtchenko Filename : draft-ietf-tcpm-urgent-data-03.txt Pages : 13 Date : 2010-02-19 This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, provides advice to applications that make use of the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-03.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-urgent-data-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-19211034.I-D@ietf.org> --NextPart-- From alexander.zimmermann@nets.rwth-aachen.de Mon Feb 22 06:38: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 3113428C2FC for ; Mon, 22 Feb 2010 06:38:06 -0800 (PST) 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 HZUajhRWtUGx for ; Mon, 22 Feb 2010 06:38:05 -0800 (PST) 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 0E8CF28C2F3 for ; Mon, 22 Feb 2010 06:38:04 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii 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 <0KY800F7GZEP56H0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 22 Feb 2010 15:40:01 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,518,1262559600"; d="scan'208";a="45999035" 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; Mon, 22 Feb 2010 15:40:02 +0100 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 <0KY800H7QZEPBS20@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 22 Feb 2010 15:40:01 +0100 (CET) From: Alexander Zimmermann Date: Mon, 22 Feb 2010 15:40:03 +0100 Message-id: <6546911B-9EA8-4CD5-B341-AEA8260C5BEF@nets.rwth-aachen.de> To: "tcpm@ietf.org Extensions WG" X-Mailer: Apple Mail (2.1077) Subject: [tcpm] TCP-LCD @ Anaheim 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, 22 Feb 2010 14:38:06 -0000 Hi TCPM folks, at Anaheim I'm going to present the progress of our draft http://tools.ietf.org/html/draft-ietf-tcpm-tcp-lcd-00. The draft addresses all issues raised by the reviewers (Joe, Pasi, and Ilpo). In our opinion the document is feature complete. In particular, we reorganized and heavily extended the discussion section (ambiguity problems, wrapped sequence numbers, packet duplication) and introduced an interoperability issue section (ECN, Tunnels, ICMPv6, ...). For more details please see So. if anyone has the desire/mute/time to read it, please do it. The charter mentioned Okt 2010 for submitting it to IESG. I really would like to "respect" the deadline :-) Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From c.raiciu@cs.ucl.ac.uk Wed Feb 24 02:25: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 95EA43A8400 for ; Wed, 24 Feb 2010 02:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 dcqZfOcXe0+5 for ; Wed, 24 Feb 2010 02:25:42 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 209C73A8360 for ; Wed, 24 Feb 2010 02:25:42 -0800 (PST) Received: from wifi-visiteurs1-71.sri.ucl.ac.be ([130.104.202.199]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1NkDbP-0007ry-Ho for tcpm@ietf.org; Wed, 24 Feb 2010 09:32:19 +0000 From: Costin Raiciu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Feb 2010 11:27:41 +0100 References: <168921C8-87E9-4502-9DD5-119A71F15EF6@cs.ucl.ac.uk> To: tcpm@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [tcpm] Multipath TCP signaling 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, 24 Feb 2010 10:25:47 -0000 Hi, In the multipath TCP working group we are trying to decide which is the = best way to signal multipath specific information between endpoints. We = are writing this message to invite contributions and thoughts from = members of the tcpm list, as we believe that whatever solution we choose = will impact other tcp signaling in the future. Let me briefly tell you what we are trying to do.=20 Multipath works by assigning a data level sequence number to application = data, and sending this data over different "subflows" which look like = tcp over the wire. These subflows have their own sequence numbers too, = on top of the data sequence number.=20 The information multipath needs to get across is: - multipath enabled / join connection - this is only on flow/subflow = startup - data sequence number (each segment must have this to enable the = receiver to reorder data) - add/remove ip to connection (not often) - security negotiation, if needed - subflow policy, etc. We have analyzed the requirements of this control information (e.g. = reliable, in order) and two basic ways of signaling it: - using TCP options - this is the traditional TCP way of signaling = control information; it is unreliable and the space is limited, it will = be a bit difficult to get it through existing middleboxes, but it plays = nice with future "multipath aware" middleboxes. - using the payload - this would use TLV like encoding (as in tls) and = does not have space issues. However, all the control info is now = ordered, congestion controlled and reliably sent - which may not be what = we want. This will get through more middleboxes today, but it is not = nice to future middleboxes: they have to keep state to be able to parse = the control info. Also, the middleboxes cannot easily add control info = (this is contentious, I know, but should be possible). The detailed analysis is in the following doc: = http://www.cs.ucl.ac.uk/staff/C.Raiciu/files/options_vs_payload.pdf What do people think is the best approach? Costin= From alexander.zimmermann@nets.rwth-aachen.de Wed Feb 24 05:01: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 1F8683A84B1 for ; Wed, 24 Feb 2010 05:01:23 -0800 (PST) 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 FlaJWUsM4MuX for ; Wed, 24 Feb 2010 05:01:21 -0800 (PST) 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 E0D9D3A849F for ; Wed, 24 Feb 2010 05:01:17 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii 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 <0KYC00CE5K9MPME0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 24 Feb 2010 14:03:22 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,532,1262559600"; d="scan'208";a="46304959" 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; Wed, 24 Feb 2010 14:03:23 +0100 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 <0KYC00M0VK9MXN80@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 24 Feb 2010 14:03:22 +0100 (CET) From: Alexander Zimmermann Date: Wed, 24 Feb 2010 14:03:23 +0100 Message-id: <88C9959E-A011-4D01-BD42-8CB2112C71A9@nets.rwth-aachen.de> To: "Wesley CORP] Eddy M. (GRC-MS00)[ASRC AEROSPACE" , David Borman X-Mailer: Apple Mail (2.1077) Cc: "tcpm@ietf.org WG Extensions" Subject: [tcpm] Anaheim TCPM draft agenda available? 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, 24 Feb 2010 13:01:23 -0000 Hi Wes, David, is the draft agenda for the upcoming TCPM meeting available? Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From alexander.zimmermann@nets.rwth-aachen.de Wed Feb 24 05:10: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 E0DF128C105 for ; Wed, 24 Feb 2010 05:10:01 -0800 (PST) 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 2PcLoA-u8g-v for ; Wed, 24 Feb 2010 05:10:00 -0800 (PST) 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 B3E773A84D2 for ; Wed, 24 Feb 2010 05:09:59 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) 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 <0KYC00KUGKO5WGC0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 24 Feb 2010 14:12:05 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,532,1262559600"; d="scan'208";a="24853217" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 24 Feb 2010 14:12:05 +0100 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 <0KYC00M6CKO4XN80@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 24 Feb 2010 14:12:05 +0100 (CET) From: Alexander Zimmermann Date: Wed, 24 Feb 2010 14:12:05 +0100 Message-id: <9D701BB3-35C2-49C9-8728-9A9AE079C45D@nets.rwth-aachen.de> To: "tcpm@ietf.org Extensions WG" X-Mailer: Apple Mail (2.1077) Subject: [tcpm] New ID available: RFC2988bis (RTO calculation) 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, 24 Feb 2010 13:10:02 -0000 Hi folks, just seen: the first version of the potential successor of RFC 2988 is available. http://tools.ietf.org/html/draft-paxson-tcpm-rfc2988bis-00 Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From alexander.zimmermann@nets.rwth-aachen.de Wed Feb 24 05:27: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 49F9628C169 for ; Wed, 24 Feb 2010 05:27:58 -0800 (PST) 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 aTOwlUqKfRT9 for ; Wed, 24 Feb 2010 05:27:57 -0800 (PST) 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 25D5328C162 for ; Wed, 24 Feb 2010 05:27:57 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) 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 <0KYC00KFRLI2WGD0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 24 Feb 2010 14:30:02 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,532,1262559600"; d="scan'208";a="24854866" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 24 Feb 2010 14:30:03 +0100 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 <0KYC00MGGLFCXN80@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 24 Feb 2010 14:30:02 +0100 (CET) From: Alexander Zimmermann In-reply-to: <9D701BB3-35C2-49C9-8728-9A9AE079C45D@nets.rwth-aachen.de> Date: Wed, 24 Feb 2010 14:30:03 +0100 Message-id: <280FDB5F-8002-416D-85C0-34AFAB4025F3@nets.rwth-aachen.de> References: <9D701BB3-35C2-49C9-8728-9A9AE079C45D@nets.rwth-aachen.de> To: hkchu@google.com, "mallman@icir.org Allman" , vern@icir.org X-Mailer: Apple Mail (2.1077) Cc: "tcpm@ietf.org Extensions WG" Subject: Re: [tcpm] New ID available: RFC2988bis (RTO calculation) 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, 24 Feb 2010 13:27:58 -0000 Hi, currently the document only suggests lowering the initial RTO. IMHO we should also discuss if we want to lower the minimal RTO, too. Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From Alexander.Zimmermann@nets.rwth-aachen.de Wed Feb 24 06:45: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 332AA28C1A4 for ; Wed, 24 Feb 2010 06:45:06 -0800 (PST) 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 dsojUi2Y4w+v for ; Wed, 24 Feb 2010 06:45:02 -0800 (PST) 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 43D1B28C192 for ; Wed, 24 Feb 2010 06:45:01 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii 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 <0KYC00C4JP2J7Q00@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 24 Feb 2010 15:47:07 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,532,1262559600"; d="scan'208";a="46324258" 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; Wed, 24 Feb 2010 15:47:07 +0100 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 <0KYC00MXFP2IXN90@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 24 Feb 2010 15:47:07 +0100 (CET) From: Alexander Zimmermann In-reply-to: <20100224134512.5510D992427@lawyers.icir.org> Date: Wed, 24 Feb 2010 15:47:07 +0100 Message-id: <504DB33D-1940-461B-9F0A-1460C6B15E06@nets.rwth-aachen.de> References: <20100224134512.5510D992427@lawyers.icir.org> To: "mallman@icir.org" X-Mailer: Apple Mail (2.1077) Cc: "tcpm@ietf.org Extensions WG" , "vern@icir.org" Subject: Re: [tcpm] New ID available: RFC2988bis (RTO calculation) 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, 24 Feb 2010 14:45:06 -0000 Hi Mark, what a quick response :-) Am 24.02.2010 um 14:45 schrieb Mark Allman: > >> currently the document only suggests lowering the initial RTO. >> IMHO we should also discuss if we want to lower the minimal RTO, too. > > I have two responses to this ... > > - First, I sent a technical note to the list on Feb/11 about changing > the min. Sure? On this list...? Anyway, since you appended the text, I can read it. > I am appending that to this note. > > - Second, it seems that we should keep these two questions independent > to me. It seems to me that changing the initRTO is pretty minor and > well-scoped, whereas changing the minRTO has more unknowns. So, I > am not at all opposed to thinking about both changes as you suggest, > but coupling them is likely to hinder progress on the initRTO > (IMO). Yes, full ACK. However, I suggest that we add some text (like your appended note below or your comments here http://www.ietf.org/mail-archive/web/tcpm/current/msg02937.html) to the draft, why we not lower minRTO at this time. Alex > > Just my 2c. > > allman > > > > >> Is it time to reconsider a smaller minimum RTO as well? > > One problem with the minimum is we don't know what to set it at [*]. > The finding in [AP99] is that as you reduce the min you take more > spurious timeouts. The tradeoff seemed fundamental to us. But, given > our methodology (trace driven simulation) we could not really tell the > impact of the spurious timeouts. So, we just sought to minimize them in > the spec. I know some TCP implementations are being pretty aggressive > with the min these days. But, it is not at all clear to me whether this > is a net win or net lose. I.e., is the win in terms of peppiness to > needed retransmits still a win when it is played against the > consequences of a spurious transmit (i.e., setting cwnd = 1)? Perhaps > there is a sweet spot that is < 1sec whereby this tradeoff better > balances and we should be using that. But, it'd take a big experiment > to show that, I think. > > [*] Maybe there is work that I just don't know about and if so I'd like > to be pointed at it. > > Another thing I have wondered about from time to time .... Much like > Early Retransmit could we have some sort of early RTO when the cwnd size > is small? When the window size is small it seems that the downside of > making a bad rexmt decision is not as bad as when the cwnd is large so > it might pay in terms of responsiveness to RTO sooner. Also, as the > cwnd gets larger we have better loss recovery techniques that should > come into play that can repair lots of loss without involving the RTO > and so perhaps by being overly aggressive in the RTO we just hurt > ourselves. Finally, as the cwnd gets bigger that means we are > transferring more data. And, the longer a connection goes the less > important the fine-grained responsiveness matters. Just a random > thought ... > > allman > > > // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From wwwrun@core3.amsl.com Wed Feb 24 09:24:57 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E5AE028C125; Wed, 24 Feb 2010 09:24:57 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100224172457.E5AE028C125@core3.amsl.com> Date: Wed, 24 Feb 2010 09:24:57 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 17:24:58 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'The TCP Authentication Option ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16685&rfc_flag=0 From wwwrun@core3.amsl.com Wed Feb 24 09:25:58 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3B37E28C230; Wed, 24 Feb 2010 09:25:58 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100224172558.3B37E28C230@core3.amsl.com> Date: Wed, 24 Feb 2010 09:25:58 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-ao-crypto (Cryptographic Algorithms for TCP's Authentication Option, TCP-AO) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 17:25:58 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Cryptographic Algorithms for TCP's Authentication Option, TCP-AO ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-ao-crypto-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19032&rfc_flag=0 From hallam@gmail.com Wed Feb 24 09:50:56 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 AF51F28C143; Wed, 24 Feb 2010 09:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 Lb6UZJ+7dllk; Wed, 24 Feb 2010 09:50:55 -0800 (PST) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 90F9C28C15F; Wed, 24 Feb 2010 09:50:55 -0800 (PST) Received: by iwn29 with SMTP id 29so3546105iwn.31 for ; Wed, 24 Feb 2010 09:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=z6JdkGChGB8IJEjQNF3Al98E7LMbV5bXcfQaC+XyoJ0=; b=OTUWQpd8HuP7k1OEvsnXneOmT2tLMe1rIZ3QMrOocDuBqV5Mx1yZ4jMJXt+vma6z/w s+lZG+Equ/6TwhX3VqBBTJlScSjzlfU7ePPkuBXDvAfbAV7B9mvlKebNs3OIeVd7/hPF alQJjqiEe87eonABJPzvggn3HhNF8Yb1PfRrM= 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:content-transfer-encoding; b=X39MbOVvKUWS04sEd9yh9mR0MyzaZobEcSs5OrrHcbRBGrTgpJOxtfN/38BCrmnvOt XfZ4pc/wCs1tktlioaKGteKX4aqGGMSVzTSMOqGrdaLeQ6dGawmbe/GBjIpJU+fk2vyg 4neZlJCZ6O8o0cpD3WYb1H4yxzUETESCwC7cU= MIME-Version: 1.0 Received: by 10.231.167.204 with SMTP id r12mr305328iby.31.1267033979492; Wed, 24 Feb 2010 09:52:59 -0800 (PST) In-Reply-To: <4B7ACB68.9020503@isi.edu> References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar> <4B79B270.5060804@isi.edu> <4B79B7D9.8080909@gont.com.ar> <4B7ACB68.9020503@isi.edu> Date: Wed, 24 Feb 2010 12:52:59 -0500 Message-ID: From: Phillip Hallam-Baker To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org, Fernando Gont , secdir@ietf.org Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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: Wed, 24 Feb 2010 17:50:56 -0000 When a document becomes an RFC it is read as a stand alone document and not in the context of the working group discussions that may have ended years ago. If a particular security issue has not been discussed because it was out of scope, that should be given as the reason that it is not discussed. On Tue, Feb 16, 2010 at 11:44 AM, Joe Touch wrote: > > > Fernando Gont wrote: > ... >> Anyway: For the most part I'm wondering if there's any additional text >> needed to address Phillip's comments. Thoughts? This should be our focus >> at this point in time. > > There were two separate points raised, IMO: > > - clarification of the role of this doc's recommendations > =A0 =A0 =A0 =A0The WG was aware of this issue, and there was > =A0 =A0 =A0 =A0a lot of effort in creating the existing text that > =A0 =A0 =A0 =A0already considered this perspective. No change needed. > > - addressing the larger issue of the role/need of ICMPs > =A0 =A0 =A0 =A0This is out of scope for this doc. No change needed. > > Overall, I think there isn't a need for a change. > > Joe > > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From touch@ISI.EDU Wed Feb 24 10:00:08 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 CF95D28C245; Wed, 24 Feb 2010 10:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 HZPzTypD3Acg; Wed, 24 Feb 2010 10:00:08 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0908528C14B; Wed, 24 Feb 2010 10:00:08 -0800 (PST) Received: from [75.214.31.137] (137.sub-75-214-31.myvzw.com [75.214.31.137]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o1OHxgPs014029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Feb 2010 09:59:44 -0800 (PST) Message-ID: <4B85690D.4050707@isi.edu> Date: Wed, 24 Feb 2010 09:59:41 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar> <4B79B270.5060804@isi.edu> <4B79B7D9.8080909@gont.com.ar> <4B7ACB68.9020503@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB939625BC76FE1BD4643B39E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Fernando Gont , secdir@ietf.org Subject: Re: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.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: Wed, 24 Feb 2010 18:00:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB939625BC76FE1BD4643B39E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote: > When a document becomes an RFC it is read as a stand alone document > and not in the context of the working group discussions that may have > ended years ago. >=20 > If a particular security issue has not been discussed because it was > out of scope, that should be given as the reason that it is not > discussed. That seems worthwhile to include IMO, esp. as a response to SECDIR review= =2E Joe >=20 >=20 > On Tue, Feb 16, 2010 at 11:44 AM, Joe Touch wrote: >> >> Fernando Gont wrote: >> ... >>> Anyway: For the most part I'm wondering if there's any additional tex= t >>> needed to address Phillip's comments. Thoughts? This should be our fo= cus >>> at this point in time. >> There were two separate points raised, IMO: >> >> - clarification of the role of this doc's recommendations >> The WG was aware of this issue, and there was >> a lot of effort in creating the existing text that >> already considered this perspective. No change needed. >> >> - addressing the larger issue of the role/need of ICMPs >> This is out of scope for this doc. No change needed. >> >> Overall, I think there isn't a need for a change. >> >> Joe >> >> >=20 >=20 >=20 --------------enigB939625BC76FE1BD4643B39E 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) iEYEARECAAYFAkuFaQ0ACgkQE5f5cImnZrv/WACgvI2D+I/7gR3TDFKOr904/7+3 2JcAoLC44MjIyLOWYyu9/lFyb0S9TvNc =xJxb -----END PGP SIGNATURE----- --------------enigB939625BC76FE1BD4643B39E-- From root@core3.amsl.com Thu Feb 25 23:00:02 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 D0E6928C51D; Thu, 25 Feb 2010 23:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100226070001.D0E6928C51D@core3.amsl.com> Date: Thu, 25 Feb 2010 23:00:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-11.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: Fri, 26 Feb 2010 07:00:02 -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 : ICMP attacks against TCP Author(s) : F. Gont Filename : draft-ietf-tcpm-icmp-attacks-11.txt Pages : 40 Date : 2010-02-25 This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-11.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-icmp-attacks-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-25225054.I-D@ietf.org> --NextPart-- From Donald.Smith@qwest.com Fri Feb 26 11:42: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 2E8EB28C271; Fri, 26 Feb 2010 11:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.399, 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 j6W2f0jy9D1x; Fri, 26 Feb 2010 11:42:53 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 0BE5928C231; Fri, 26 Feb 2010 11:42:52 -0800 (PST) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id o1QJj7IX011199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2010 12:45:08 -0700 (MST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id o1QJj1cd010193; Fri, 26 Feb 2010 13:45:02 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Fri, 26 Feb 2010 12:45:01 -0700 From: "Smith, Donald" To: "'ietf@ietf.org'" , "'IETF-Announce'" Date: Fri, 26 Feb 2010 12:45:00 -0700 Thread-Topic: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard Thread-Index: Acq1dr1WktkyFAr/QMuSczPTWX4FJQBpRzBA Message-ID: References: <20100224172457.E5AE028C125@core3.amsl.com> In-Reply-To: <20100224172457.E5AE028C125@core3.amsl.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 Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard 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, 26 Feb 2010 19:42:54 -0000 I have commented numerous times that with a paragraph that specifically pro= vides vendors to make "connection-less resets =3D=3D attack packets" this w= ill not get much if any use among ISPs or other bgp speakers. Those statements have pretty much been ignored. I do not support this draft and believe I have wasted my time trying to exp= lain why to someone that is unwilling to compromise with even a "a vendor M= AY maintain state to allow connectionless resets to work". (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of The IESG > Sent: Wednesday, February 24, 2010 10:25 AM > To: IETF-Announce > Cc: tcpm@ietf.org > Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The > TCP Authentication Option) to Proposed Standard > > The IESG has received a request from the TCP Maintenance and Minor > Extensions WG (tcpm) to consider the following document: > > - 'The TCP Authentication Option ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive > comments to the > ietf@ietf.org mailing lists by 2010-03-10. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-o > pt-10.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D16685&rfc_flag=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From wesley.m.eddy@nasa.gov Fri Feb 26 15:16: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 51B7B3A8579; Fri, 26 Feb 2010 15:16:06 -0800 (PST) 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=[AWL=0.000, 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 K7PYlOf+cuWC; Fri, 26 Feb 2010 15:16:04 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id B1B7228C12E; Fri, 26 Feb 2010 15:16:04 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id B54BD108040; Fri, 26 Feb 2010 17:18:20 -0600 (CST) 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 o1QNIKGv012193; Fri, 26 Feb 2010 17:18:20 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Fri, 26 Feb 2010 17:18:20 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "Smith, Donald" , "'ietf@ietf.org'" Date: Fri, 26 Feb 2010 17:18:20 -0600 Thread-Topic: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard Thread-Index: Acq1dr1WktkyFAr/QMuSczPTWX4FJQBpRzBAAAcvoyc= Message-ID: References: <20100224172457.E5AE028C125@core3.amsl.com>, 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-02-26_14:2010-02-06, 2010-02-26, 2010-02-26 signatures=0 Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard 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, 26 Feb 2010 23:16:06 -0000 Hi Donald, as the document shepherd, I need to set the record straight on t= his, as your statement is simply false. In checking that the WGLC comments had been handled in the following docume= nt update, I looked at both the email thread you participated in and the up= dated document. In this case, the editor very clearly responded to your in= puts and made significant changes to the document. You can find an entirely new section (9.7 Connectionless Resets) starting i= n version 09 of the draft, which specifically responds to your comments wit= h resolutions that were discussed on the mailing list. This section discus= ses maintenance of the traffic keys across reboots which answers your conce= rn and makes the practice a "SHOULD" which is stronger even than the "MAY" = that you mention below. I do not understand why you feel like your inputs were ignored, but I hope = that you'll agree that this was not the case. ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Smith, Don= ald [Donald.Smith@qwest.com] Sent: Friday, February 26, 2010 2:45 PM To: 'ietf@ietf.org'; 'IETF-Announce' Cc: 'tcpm@ietf.org' Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP= Authentication Option) to Proposed Standard I have commented numerous times that with a paragraph that specifically pro= vides vendors to make "connection-less resets =3D=3D attack packets" this w= ill not get much if any use among ISPs or other bgp speakers. Those statements have pretty much been ignored. I do not support this draft and believe I have wasted my time trying to exp= lain why to someone that is unwilling to compromise with even a "a vendor M= AY maintain state to allow connectionless resets to work". (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of The IESG > Sent: Wednesday, February 24, 2010 10:25 AM > To: IETF-Announce > Cc: tcpm@ietf.org > Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The > TCP Authentication Option) to Proposed Standard > > The IESG has received a request from the TCP Maintenance and Minor > Extensions WG (tcpm) to consider the following document: > > - 'The TCP Authentication Option ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive > comments to the > ietf@ietf.org mailing lists by 2010-03-10. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-o > pt-10.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D16685&rfc_flag=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm= From Donald.Smith@qwest.com Fri Feb 26 15:27: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 5A8B928C106; Fri, 26 Feb 2010 15:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 vkp5WhyBYujf; Fri, 26 Feb 2010 15:27:52 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 366613A86AE; Fri, 26 Feb 2010 15:27:52 -0800 (PST) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o1QNU7Uk026411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2010 17:30:07 -0600 (CST) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id o1QNU16m017398; Fri, 26 Feb 2010 17:30:02 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Fri, 26 Feb 2010 16:30:01 -0700 From: "Smith, Donald" To: "'Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]'" , "'ietf@ietf.org'" Date: Fri, 26 Feb 2010 16:30:00 -0700 Thread-Topic: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard Thread-Index: Acq1dr1WktkyFAr/QMuSczPTWX4FJQBpRzBAAAcvoycAAJWkgA== Message-ID: References: <20100224172457.E5AE028C125@core3.amsl.com>, 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 Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard 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, 26 Feb 2010 23:27:53 -0000 Hi Wesley, I stand red faced and corrected. The last version I saw did not address this (I think that was either 08 or = 09) and I assumed the .10 didn't either. I withdraw my objection and apologize for having missed this significant re= write!! (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] > [mailto:wesley.m.eddy@nasa.gov] > Sent: Friday, February 26, 2010 4:18 PM > To: Smith, Donald; 'ietf@ietf.org' > Cc: 'tcpm@ietf.org' > Subject: RE: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt > (The TCP Authentication Option) to Proposed Standard > > Hi Donald, as the document shepherd, I need to set the record > straight on this, as your statement is simply false. > > In checking that the WGLC comments had been handled in the > following document update, I looked at both the email thread > you participated in and the updated document. In this case, > the editor very clearly responded to your inputs and made > significant changes to the document. > > You can find an entirely new section (9.7 Connectionless > Resets) starting in version 09 of the draft, which > specifically responds to your comments with resolutions that > were discussed on the mailing list. This section discusses > maintenance of the traffic keys across reboots which answers > your concern and makes the practice a "SHOULD" which is > stronger even than the "MAY" that you mention below. > > I do not understand why you feel like your inputs were > ignored, but I hope that you'll agree that this was not the case. > > > ________________________________________ > From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf > Of Smith, Donald [Donald.Smith@qwest.com] > Sent: Friday, February 26, 2010 2:45 PM > To: 'ietf@ietf.org'; 'IETF-Announce' > Cc: 'tcpm@ietf.org' > Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt > (The TCP Authentication Option) to Proposed Standard > > I have commented numerous times that with a paragraph that > specifically provides vendors to make "connection-less resets > =3D=3D attack packets" this will not get much if any use among > ISPs or other bgp speakers. > > Those statements have pretty much been ignored. > > I do not support this draft and believe I have wasted my time > trying to explain why to someone that is unwilling to > compromise with even a "a vendor MAY maintain state to allow > connectionless resets to work". > > > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@qwest.com gcia > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf Of The IESG > > Sent: Wednesday, February 24, 2010 10:25 AM > > To: IETF-Announce > > Cc: tcpm@ietf.org > > Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The > > TCP Authentication Option) to Proposed Standard > > > > The IESG has received a request from the TCP Maintenance and Minor > > Extensions WG (tcpm) to consider the following document: > > > > - 'The TCP Authentication Option ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, > and solicits > > final comments on this action. Please send substantive > > comments to the > > ietf@ietf.org mailing lists by 2010-03-10. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either > case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-o > > pt-10.txt > > > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > > w_id&dTag=3D16685&rfc_flag=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > This communication is the property of Qwest and may contain > confidential or > privileged information. Unauthorized use of this > communication is strictly > prohibited and may be unlawful. If you have received this > communication > in error, please immediately notify the sender by reply > e-mail and destroy > all copies of the communication and any attachments. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From wesley.m.eddy@nasa.gov Sun Feb 28 22:23: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 4CC0F28C259 for ; Sun, 28 Feb 2010 22:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 xmXB4UvIhulL for ; Sun, 28 Feb 2010 22:23:41 -0800 (PST) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 6444728C0D9 for ; Sun, 28 Feb 2010 22:23:41 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 407B9261330; Mon, 1 Mar 2010 00:23:40 -0600 (CST) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o216Nejk010076; Mon, 1 Mar 2010 00:23:41 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Mon, 1 Mar 2010 00:23:39 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Fernando Gont , "tcpm@ietf.org" Date: Mon, 1 Mar 2010 00:23:38 -0600 Thread-Topic: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security Thread-Index: AcqxwTEKn8/IeFCGQGq1P7hReWVZfAHQ9Qqm Message-ID: References: <4B7F2881.7000700@gont.com.ar> In-Reply-To: <4B7F2881.7000700@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C304DB494AC0C04C87C6A6E2FF5603DB47DE76AE73NDJSSCC01ndcn_" 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-03-01_04:2010-02-06, 2010-03-01, 2010-02-28 signatures=0 Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 01 Mar 2010 06:23:48 -0000 --_000_C304DB494AC0C04C87C6A6E2FF5603DB47DE76AE73NDJSSCC01ndcn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fernando, here are some comments from me as a WG participant (not a co-c= hair): There was mailing list discussion, and seemingly agreement, on Toby's sugge= stion changing the title to reflect the focus on implementation practices, = but the title is not changed. In section 1.1, I think the first 2 paragraphs can be removed without any l= oss of context or content. There is a sentence that can simply be removed without any loss: "For some = reason, much of the effort of the security community on the Internet protoc= ols did not result in official documents (RFCs) being issued by the IETF (I= nternet Engineering Task Force)." This doesn't consider the fact that prot= ocol specifications in the IETF and many (if not most) other SDOs are focus= ed on producing interoperable specifications with implementation detail lef= t to individual vendors to differentiate their products. In the case of ma= ny of these TCP vulnerabilities under discussion, many clearly fall into th= e realm of implementation issues rather than protocol issues, and are thus = outside the traditional scope of IETF process. As nearly all of the vendor= s who have implemented these fixes participate in the IETF, it seems they h= aven't felt a compelling urge to have their implementation practices codifi= ed in RFCs. At least explaining this seems more valuable than the nebulous= "For some reason" which makes it sound like this is just a strange occuren= ce with no clear explanation, though I believe the sentence can just be com= pletely removed without any loss to the document. In the sentence "Producing a secure TCP/IP implementation ...", I think we = should just say "TCP" (and change "protocols" to "protocol and dependencies= or extensions". Also, in this sentence, I'm unclear on what a "security r= oadmap" would look like; should this really be a "threat and mitigation sum= mary"? I believe section 1.2 can be entirely eliminated without any loss. I belie= ve we will cover quite a bit more than just the documents listed in this se= ction anyways. The paragraph beginning with "This document is the result of a security ass= essment of the IETF specifications of the Transmission Control Protocol (TC= P), from a security point of view. Possible threats are identified and, wh= ere possible, countermeasures are proposed." should be replaced with someth= ing to the effect of "This document captures the best current practices in = implementation, configuration, and use of TCP and its supporting protocols = and extensions and has been produced by the IETF's TCP Maintenance and Mino= r Extensions Working Group (TCPM)." Section 2 can be eliminated without any loss. In section 3, an implementation requirement seems to be laid out with a mix= of informal and standards language (it initially uses "should" instead of = MUST, SHOULD, MAY, etc, yet later uses a MUST) and it's not included in the= requirements section like the 3.1.1 recommendations are: """ Therefore, before doing any processing of the TCP header fields, the following check should be performed by TCP on the segments handed by the internet layer: Segment.Size >=3D 20 If a segment does not pass this check, it MUST be dropped. """ Further, I believe that if this document is to contain dozens of recommenda= tions, then these should be better identified and individually numbered rat= her than mixed with prose. In 3.1.1, I think the requirements should be individually numbered (maybe a= s R.1a, R.1b, etc. in this section?) so that they can be referenced individ= ually and used in checklists or compliance matrices. Regarding the requirement: """ If a segment is received with port 0 as the Source Port or the Destination Port, a RST segment SHOULD be sent in response (provided that the incomming segment does not have the RST flag set). """ The rationale indicates that this is to mitigate against OS fingerprinting,= but no discussion motivates this particular response rather than other alt= ernatives e.g. simply ignoring the segment, sending an ICMP port-unreachabl= e, etc. If there is a specific reason that this response is the one chosen= to make all implementations look the same to a fingerprinting attempt, the= n we need to explain that, Regarding the requirement: """ Middle-boxes such as packet filters MUST NOT assume that clients use port numbers from only the Dynamic or Registered port ranges. """ It's not clear to me how this improves security. For high-level discussion, some of these comments are based on a desire to = shorten, simplify, or clarify the presentation of these recommendations. L= ooking at this first batch, it's a mix of things that an implementer may or= may not care about depending on their implementation constraints or deploy= ment environments. For instance, in this first batch alone, some of the re= commendations are for basic robustness to bizarre conditions whereas others= are for making fingerprinting "attacks" less effective. We will need some= way to distinguish the types of attacks that are relevant to each recommen= dation, I think, which could easily be done in a set of lists in an appendi= x if the recommendations were numbered, or could be satisfied by using an o= utline organized by the things you're trying to protect. I bring this opti= on up since the prior thread on outlines didn't seem to drive to a clear co= nsensus on what the next outline would look like, and this update left it a= lmost completely unchanged so I think we need to find a way to deal with th= is type of complexity in mixed relevance of the recommendations going forwa= rd or it will be more difficult to sort out later. But that's just my 2 ce= nts. ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Fernando G= ont [fernando@gont.com.ar] Sent: Friday, February 19, 2010 7:10 PM To: tcpm@ietf.org Subject: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security Folks, I have just posted a revision (-01) of draft-ietf-tcpm-tcp-security. The document is available at the usual places (including: http://tools.ietf.org/id/draft-ietf-tcpm-tcp-security-01.txt). The current plan is discuss each section of the draft piecemeal (it is a very large document), get consensus on the changes to apply to the existing text, and then move on to the next section. Therefore I'm requesting feedback on all the sections through Section 3.1.2.3. -- this includes the introduction sections, the basic check on the TCP segment size (Section 3) and the discussion of port numbers (Section 3.1 with all its subsections). Please review these sections and submit comments by Friday March 5th, 2010, so that we can move on to the next sections in a timely manner. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --_000_C304DB494AC0C04C87C6A6E2FF5603DB47DE76AE73NDJSSCC01ndcn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Fernando, here are some comments from me as a WG= participant (not a co-chair):

There was mailing list discussion, and seemingly agreement, on Toby's sugge= stion changing the title to reflect the focus on implementation practices, = but the title is not changed.

In section 1.1, I think the first 2 paragraphs can be removed without any l= oss of context or content.


There is a sentence that can simply be removed without any loss: "For = some reason, much of the effort of the security community on the Internet p= rotocols did not result in official documents (RFCs) being issued by the IE= TF (Internet Engineering Task Force)."  This doesn't consider the fact that protocol specifications in the IETF an= d many (if not most) other SDOs are focused on producing interoperable spec= ifications with implementation detail left to individual vendors to differe= ntiate their products.  In the case of many of these TCP vulnerabilities under discussion, many clearly fall i= nto the realm of implementation issues rather than protocol issues, and are= thus outside the traditional scope of IETF process.  As nearly all of= the vendors who have implemented these fixes participate in the IETF, it seems they haven't felt a compelling urg= e to have their implementation practices codified in RFCs.  At least e= xplaining this seems more valuable than the nebulous "For some reason&= quot; which makes it sound like this is just a strange occurence with no clear explanation, though I believe the sentence= can just be completely removed without any loss to the document.

In the sentence "Producing a secure TCP/IP implementation ...", I= think we should just say "TCP" (and change "protocols"= to "protocol and dependencies or extensions".  Also, in thi= s sentence, I'm unclear on what a "security roadmap" would look l= ike; should this really be a "threat and mitigation summary"?

I believe section 1.2 can be entirely eliminated without any loss.  I = believe we will cover quite a bit more than just the documents listed in th= is section anyways.

The paragraph beginning with "This document is the result of a securit= y assessment of the IETF specifications of the Transmission Control Protoco= l (TCP), from a security point of view.  Possible threats are identifi= ed and, where possible, countermeasures are proposed." should be replaced with something to the effect of "T= his document captures the best current practices in implementation, configu= ration, and use of TCP and its supporting protocols and extensions and has = been produced by the IETF's TCP Maintenance and Minor Extensions Working Group (TCPM)."

Section 2 can be eliminated without any loss.

In section 3, an implementation requirement seems to be laid out with a mix= of informal and standards language (it initially uses "should" i= nstead of MUST, SHOULD, MAY, etc, yet later uses a MUST) and it's not inclu= ded in the requirements section like the 3.1.1 recommendations are:
"""
Therefore, before doing any processing of the TCP header fields, the
   following check should be performed by TCP on the segments han= ded by
   the internet layer:

            &nb= sp;            =     Segment.Size >=3D 20
   If a segment does not pass this check, it MUST be dropped.
"""
Further, I believe that if this document is to contain dozens of recommenda= tions, then these should be better identified and individually numbered rat= her than mixed with prose.

In 3.1.1, I think the requirements should be individually numbered (maybe a= s R.1a, R.1b, etc. in this section?) so that they can be referenced individ= ually and used in checklists or compliance matrices.

Regarding the requirement:
"""
   If a segment is received with port 0 as
   the Source Port or the Destination Port, a RST segment SHOULD = be sent
   in response (provided that the incomming segment does not have= the
   RST flag set).
"""
The rationale indicates that this is to mitigate against OS fingerprinting,= but no discussion motivates this particular response rather than other alt= ernatives e.g. simply ignoring the segment, sending an ICMP port-unreachabl= e, etc.  If there is a specific reason that this response is the one chosen to make all implementations lo= ok the same to a fingerprinting attempt, then we need to explain that,

Regarding the requirement:
"""
   Middle-boxes such as packet filters MUST NOT assume that clien= ts use
   port numbers from only the Dynamic or Registered port ranges.<= br> """
It's not clear to me how this improves security.

For high-level discussion, som= e of these comments are based on a desire to shorten, simplify, or clarify&= nbsp;the presentation of these recommendations.  Looking at this first= batch, it's a mix of things that an implementer may or may not care about depending on their implementation cons= traints or deployment environments.  For instance, in this first batch= alone, some of the recommendations are for basic robustness to bizarre con= ditions whereas others are for making fingerprinting "attacks" less effective.  We will need some way to disting= uish the types of attacks that are relevant to each recommendation, I think= , which could easily be done in a set of lists in an appendix if the recomm= endations were numbered, or could be satisfied by using an outline organized by the things you're trying to protect. = ; I bring this option up since the prior thread on outlines didn't seem to = drive to a clear consensus on what the next outline would look like, and th= is update left it almost completely unchanged so I think we need to find a way to deal with this type of complexity in m= ixed relevance of the recommendations going forward or it will be more diff= icult to sort out later.  But that's just my 2 cents.



________________________________________
From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Fernando G= ont [fernando@gont.com.ar]
Sent: Friday, February 19, 2010 7:10 PM
To: tcpm@ietf.org
Subject: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security

Folks,

I have just posted a revision (-01) of draft-ietf-tcpm-tcp-security. The document is available at the usual places (including:
http://tools.ietf.org/id/draft-ietf-tcpm-tcp-security-01.txt).

The current plan is discuss each section of the draft piecemeal (it is a very large document), get consensus on the changes to apply to the
existing text, and then move on to the next section.

Therefore I'm requesting feedback on all the sections through Section
3.1.2.3. -- this includes the introduction sections, the basic
check on the TCP segment size (Section 3) and the discussion of port
numbers (Section 3.1 with all its subsections).

Please review these sections and submit comments by Friday March 5th,
2010, so that we can move on to the next sections in a timely manner.

Thanks!

Kind regards,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--_000_C304DB494AC0C04C87C6A6E2FF5603DB47DE76AE73NDJSSCC01ndcn_--