From Michael.Scharf@alcatel-lucent.com Wed Dec 1 00: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 F08453A6CE8 for ; Wed, 1 Dec 2010 00:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, HELO_EQ_DE=0.35, PLING_QUERY=1.39, 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 DLrbrus0Bju8 for ; Wed, 1 Dec 2010 00:27:57 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 84A773A69D3 for ; Wed, 1 Dec 2010 00:27:55 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id oB18T41k008331; Wed, 1 Dec 2010 09:29:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Dec 2010 09:28:20 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C045EF44D@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <20101130190504.28FC1265B986@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) Thread-Index: AcuQwYa/x1V0nRPNSx+L5DbD1Wid8QAbjHSw References: <20101130190504.28FC1265B986@lawyers.icir.org> From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Cc: tcpm@ietf.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) 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, 01 Dec 2010 08:27:58 -0000 > This is not a month's long measurement plan. This is how you=20 > run your stack. From now on. I.e., it puzzles through what=20 > IW is right for your situation (connectivity, mix of traffic,=20 > etc.) on a continual month-by-month basis. (Or, whatever=20 > time period we agree on.) The monitoring is the price of=20 > using an IW bigger than RFC5681 allows. Just a thought about that: Why not to use a limit of the number of connections, instead of a time period? Or, somethink like: "min(10000 connections, 1 month)" ? The potential harm of a too large IW somehow scales with the number of connections that actually use it. Michael From lars.eggert@nokia.com Wed Dec 1 04:01: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 E965A3A6BB6 for ; Wed, 1 Dec 2010 04:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.867 X-Spam-Level: X-Spam-Status: No, score=-101.867 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, PLING_QUERY=1.39, 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 QFaPizVOvQQX for ; Wed, 1 Dec 2010 04:01:26 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 3E0403A6B3F for ; Wed, 1 Dec 2010 04:01:26 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oB1C2Swl017092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Dec 2010 14:02:29 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-37--634872302; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <20101130190504.28FC1265B986@lawyers.icir.org> Date: Wed, 1 Dec 2010 14:02:20 +0200 Message-Id: References: <20101130190504.28FC1265B986@lawyers.icir.org> To: X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 01 Dec 2010 14:02:26 +0200 (EET) X-Nokia-AV: Clean Cc: tcpm@ietf.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) 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, 01 Dec 2010 12:01:27 -0000 --Apple-Mail-37--634872302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-11-30, at 21:05, Mark Allman wrote: > This is not a month's long measurement plan. This is how you run your > stack. =46rom now on. I.e., it puzzles through what IW is right for = your > situation (connectivity, mix of traffic, etc.) on a continual > month-by-month basis. (Or, whatever time period we agree on.) The > monitoring is the price of using an IW bigger than RFC5681 allows. That's an interesting way forward. I wonder if we could encourage some sort of back channel, so the WG gets = some information about what IWs are being settled on over time. Not-even-half-baked idea: Each month, the stack does a DNS query to = iw..tcp.ietf.org and we stat those.... Lars= --Apple-Mail-37--634872302 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIwMTEyMDIyMFowIwYJKoZIhvcNAQkE MRYEFLQbDHKgVs3i6/3v6KdmhjSwkz/oMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AHgJMzgWA30Zt5syZJ8x38HoWUolcl77+WhmtlAS3TIK4SR5smC6UZYRq2ibQytXxzpa5QCG5SjU CP8h/S0hwJ1A3nUlVyv6uxiUcZmaBQjcrf9Y33DsV5s1fJcTUrVgV81lQFG6Avp7BMA25S3WJdLk RlR8aruSSmwmwXN2nHUhn8zdXeNO2/a4G8kYG07OT3sF/mWYmDyDBmu+UyWU7M4jnRyyoH4X7Xqr WK1MX7T231ktoC1uRzOVBZCDwO/ujzBDO78RZaR2mrYP3iPZUdIMxGkGYi7imt9LOw7s50q4w8j0 LxPw3MTTnNwQvLIkOPktTm9X2l8ASdBiM68wDMAAAAAAAAA= --Apple-Mail-37--634872302-- From mallman@icir.org Wed Dec 1 04:27: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 B55ED3A6A7C for ; Wed, 1 Dec 2010 04:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.428 X-Spam-Level: X-Spam-Status: No, score=-105.428 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, 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 LOJ2Tas-FCyy for ; Wed, 1 Dec 2010 04:27:19 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id B966A3A69ED for ; Wed, 1 Dec 2010 04:27:18 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oB1CSTX3006364; Wed, 1 Dec 2010 04:28:30 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 902DB268362E; Wed, 1 Dec 2010 07:28:29 -0500 (EST) To: "SCHARF, Michael" From: Mark Allman In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C045EF44D@SLFSNX.rcs.alcatel-research.de> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dance the Night Away MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma16235-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 01 Dec 2010 07:28:29 -0500 Sender: mallman@icir.org Message-Id: <20101201122829.902DB268362E@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 12:27:22 -0000 ----------ma16235-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Just a thought about that: Why not to use a limit of the number of > connections, instead of a time period? Or, somethink like: "min(10000 > connections, 1 month)" ? > > The potential harm of a too large IW somehow scales with the number of > connections that actually use it. Four answers: + I think it'd be fine to make *decrease* decisions every N connections. But, conservativeness makes me think that you shouldn't get to increase IW every N connections, but that should be based on some amount of time. (Perhaps if N is not 1K, but 100K then this would be basically equivalent.) + The whole idea is that we limit the "potential harm" by the way we develop IW to begin with. So, even if IW=X is not working particularly well it isn't causing massive harm because IW=X-1 worked fine the month before. We can come up with examples where this is not the case because a host gets dumped in a new situation or something, but in the aggregate this seems like a reasonable way to look at "potential harm". + As I noted in my email, I think it'd be perfectly fine for a host to make a local policy decision that makes it more conservative than allowed. I.e., trying to short-circuit (i.e., before the end of the time period) using an IW increase that turns out to not be useful. + I don't think we need to over-engineer this to somehow try for optimality. The overall point is to arrive at an initial parameter that is reasonable for a given situation. allman ----------ma16235-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz2P20ACgkQWyrrWs4yIs7jkwCfVBJ66UmZWBev5oxXGopvnbb7 Br8An3g+dmbaLvLjeUk/kHt+0qIUP7vI =VMxI -----END PGP SIGNATURE----- ----------ma16235-1-- From L.Wood@surrey.ac.uk Wed Dec 1 04:52: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 85DE83A6AAD for ; Wed, 1 Dec 2010 04:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.904 X-Spam-Level: X-Spam-Status: No, score=-5.904 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, PLING_QUERY=1.39, 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 R4fMbyUzWNXu for ; Wed, 1 Dec 2010 04:52:09 -0800 (PST) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 050B13A6C07 for ; Wed, 1 Dec 2010 04:52:08 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-9.tower-82.messagelabs.com!1291208001!29700722!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 25691 invoked from network); 1 Dec 2010 12:53:21 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-9.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 1 Dec 2010 12:53:21 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Wed, 1 Dec 2010 12:53:21 +0000 From: To: , Date: Wed, 1 Dec 2010 12:53:20 +0000 Thread-Topic: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) Thread-Index: AcuRVL+kTuDpO7g1QyOSM8L1ADHDyAAAerZg Message-ID: References: <133D9897FB9C5E4E9DF2779DC91E947C045EF44D@SLFSNX.rcs.alcatel-research.de> <20101201122829.902DB268362E@lawyers.icir.org> In-Reply-To: <20101201122829.902DB268362E@lawyers.icir.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) 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, 01 Dec 2010 12:52:11 -0000 =20 > + I don't think we need to over-engineer this to somehow try for > optimality.=20 Agreed, but doesn't it render the entire discussion moot? From touch@isi.edu Wed Dec 1 06:54: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 8BF5728C134 for ; Wed, 1 Dec 2010 06:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.904 X-Spam-Level: X-Spam-Status: No, score=-101.904 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, PLING_QUERY=1.39, 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 ZF769Hh0bQBw for ; Wed, 1 Dec 2010 06:54:39 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id BB46F28C12F for ; Wed, 1 Dec 2010 06:54:39 -0800 (PST) Received: from [75.195.130.150] (150.sub-75-195-130.myvzw.com [75.195.130.150]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oB1EtDbn000184 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 1 Dec 2010 06:55:23 -0800 (PST) Message-ID: <4CF661D0.9000200@isi.edu> Date: Wed, 01 Dec 2010 06:55:12 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Lars Eggert References: <20101130190504.28FC1265B986@lawyers.icir.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) 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, 01 Dec 2010 14:54:40 -0000 Hi, Lars, On 12/1/2010 4:02 AM, Lars Eggert wrote: > On 2010-11-30, at 21:05, Mark Allman wrote: >> This is not a month's long measurement plan. This is how you run your >> stack. From now on. I.e., it puzzles through what IW is right for your >> situation (connectivity, mix of traffic, etc.) on a continual >> month-by-month basis. (Or, whatever time period we agree on.) The >> monitoring is the price of using an IW bigger than RFC5681 allows. > > That's an interesting way forward. > > I wonder if we could encourage some sort of back channel, so the WG > gets some information about what IWs are being settled on over time. I had proposed this early in the discussion, FWIW, but have abandoned it...(see below) > Not-even-half-baked idea: Each month, the stack does a DNS query to > iw..tcp.ietf.org and we stat those.... There are numerous problems: - privacy concerns - opportunity for spoofer poisoning the data (more on that in the doc) - using a DNS query is a bad idea - requires every TCP stack support DNS queries - requires a resolution step in addition to the reporting - could cause the kernel to block on a timeout - biased reporting if cellphones (e.g.) never do this, we won't know about a potentially large percent of endpoints Much as I would love to know what's going on, we have no precedent for doing this in the stack, and I don't want to start with a core protocol. Joe From hkchu@google.com Thu Dec 2 03:58: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 823F528C0D9 for ; Thu, 2 Dec 2010 03:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.869 X-Spam-Level: X-Spam-Status: No, score=-109.869 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi0wj8iTk3I6 for ; Thu, 2 Dec 2010 03:58:05 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 3B1B928C0F7 for ; Thu, 2 Dec 2010 03:58:04 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id oB2BxInh026838 for ; Thu, 2 Dec 2010 03:59:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291291159; bh=p6LgZn4OIQHqejSnGfmPePDCqxI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=XUN4pKQpZFLgSpkNGnutrCQWnRco3UwHhaXRAFoZF8Vf9+cv5jO2LzplqySR9Gste xIoALucZJ4hUI6dK/KtUw== Received: from gwj16 (gwj16.prod.google.com [10.200.10.16]) by wpaz1.hot.corp.google.com with ESMTP id oB2BxHNB029581 for ; Thu, 2 Dec 2010 03:59:17 -0800 Received: by gwj16 with SMTP id 16so3720570gwj.6 for ; Thu, 02 Dec 2010 03:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nJeHTJ4MdLH7zEFU4JdRVEuiMOmbft7+mX5vlvSQehM=; b=vCPg4HznPnOb9KGM0gOAKwuBxE6ChEbLjqCdS3jMhDyWAAjzEimcRmcltWJ/i4njj4 HPuL9N5i9pXFV3l1hwtg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NlTsapNKrRJ3o3aVY4sIC2ZK1KBQf2eFTb5pyvpXc1Y2Sk2Hmztbo9uDAgObtuQphD n/Onui/tk+kbo6U3moEA== MIME-Version: 1.0 Received: by 10.150.147.3 with SMTP id u3mr1289280ybd.234.1291291156845; Thu, 02 Dec 2010 03:59:16 -0800 (PST) Received: by 10.151.158.13 with HTTP; Thu, 2 Dec 2010 03:59:16 -0800 (PST) In-Reply-To: <4CF26596.7010500@isi.edu> References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <4CF26596.7010500@isi.edu> Date: Thu, 2 Dec 2010 03:59:16 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: multipart/alternative; boundary=000e0cdf1440b4972204966c26e7 X-System-Of-Record: true Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal 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, 02 Dec 2010 11:58:06 -0000 --000e0cdf1440b4972204966c26e7 Content-Type: text/plain; charset=ISO-8859-1 Joe, On Sun, Nov 28, 2010 at 6:22 AM, Joe Touch wrote: > > Jerry, > > In short: > > a) the receive window is an indication of the receiver's ability to reorder > out-of-order packets; it limits what is sent primarily to avoid useless > transmissions that the receiver will drop, not as a congestion control > mechanism > Wrong. The main purpose of the receive window is to flow control a sender so a faster sender won't overrun a slow receiver, period. > > yes, I find it odd that you are injecting control of the > receive window to correct for IW issues in your draft > What's wrong with that? Please give a specific badness of it? It works very effectively. In fact, I can't claim to be the inventor of this technique. It has been mentioned in plenty of RFCs. E.g., see RFC3150. > > 2) NO AMOUNT of in-connection adjustment of CWND has any effect on the > impact of a poor choice of IW > Yes it has. It limits the damage as Mark has poiinted out. > > consider that if this were not true, then you would > not need to propose a new IW value; just as you do not > want to wait for the connection to converge, I am > concerned about the network impact until that convergence > > I have made the second point repeatedly. It would be useful to know if your > continued misdirection of the issue is because don't agree with it, or some > other reason. > Yes I can read and I understand you point. I guess it's more of the less your subjective definition of "impact". But in any case the impact of IW has gotten worst by applications opening many concurrent connections. I wish you had been as passionate stopping that trend as opposing a larger IW. > Joe > > --000e0cdf1440b4972204966c26e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joe,

On Sun, Nov 28, 2010 at 6:22 AM, Joe= Touch <touch@isi.edu> wrote:

Jerry,

In short:

a) the receive window is an indication of the receiver's ability to reo= rder out-of-order packets; it limits what is sent primarily to avoid useles= s transmissions that the receiver will drop, not as a congestion control me= chanism

Wrong. The main purpose of the receive win= dow is to flow control a sender so a faster sender
won't over= run a slow receiver, period.
=A0

=A0 =A0 =A0 =A0yes, I find it odd that you are injecting control of the =A0 =A0 =A0 =A0receive window to correct for IW issues in your draft

What's wrong with that? Please give a sp= ecific badness of it? It works very effectively. In
fact, I can&#= 39;t claim to be the inventor of this technique. It has been mentioned in p= lenty of
RFCs. E.g., see RFC3150.
=A0

2) NO AMOUNT of in-connection adjustment of CWND has any effect on =A0the i= mpact of a poor choice of IW

Yes it has= . It limits the damage as Mark has poiinted out.
=A0

=A0 =A0 =A0 =A0consider that if this were not true, then you would
=A0 =A0 =A0 =A0not need to propose a new IW value; just as you do not
=A0 =A0 =A0 =A0want to wait for the connection to converge, I am
=A0 =A0 =A0 =A0concerned about the network impact until that convergence
I have made the second point repeatedly. It would be useful to know if your= continued misdirection of the issue is because don't agree with it, or= some other reason.

Yes I can read and = I understand you point. I guess it's more of the less your subjective
definition of=A0"impact". But in any case the impact of IW h= as gotten worst by applications
opening many concurrent connectio= ns. I wish you had been as passionate stopping that
trend as oppo= sing a larger IW.



Joe


--000e0cdf1440b4972204966c26e7-- From hkchu@google.com Thu Dec 2 04:58: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 A616628C0FE for ; Thu, 2 Dec 2010 04:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.881 X-Spam-Level: X-Spam-Status: No, score=-108.881 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7LYDsfvKsyG for ; Thu, 2 Dec 2010 04:58:22 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 67BFD28C0F5 for ; Thu, 2 Dec 2010 04:58:21 -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 oB2CxZii004130 for ; Thu, 2 Dec 2010 04:59:35 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291294776; bh=Lzjip4BvKwBTfYsLRncKl1xPUC0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=u+Ep5sKTUp1N7FfCpWx0dZlwfkpgCh1SJMw02V6KwpzJbOnz7dRIRvSjgXkP6cYcL SoJFAXQxMkko6iDoXGzSA== Received: from gyd10 (gyd10.prod.google.com [10.243.49.202]) by wpaz21.hot.corp.google.com with ESMTP id oB2CxYrS003963 for ; Thu, 2 Dec 2010 04:59:34 -0800 Received: by gyd10 with SMTP id 10so4090557gyd.16 for ; Thu, 02 Dec 2010 04:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xwvvxAPXTAECgVVij9xOOlibVN4fFZC5k5R0P0cCVeI=; b=JHenGg5JU5liU9cEYNVJV7O2JO6wAr/j7II4f1RpxQyVeK0/KdxfWRLANuVfovx7Ek D22cEBwixxVWw4Vx7qQA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gjQPC44hc/4zEnVNkCppCGvaXSwdlaKCp3vjHrgYGSxtMmTG0C8Ah0Ov5N6SiE1Awp OTzTBp6wS+s0x2eaoBKg== MIME-Version: 1.0 Received: by 10.150.218.21 with SMTP id q21mr1206978ybg.177.1291294773819; Thu, 02 Dec 2010 04:59:33 -0800 (PST) Received: by 10.151.158.13 with HTTP; Thu, 2 Dec 2010 04:59:33 -0800 (PST) In-Reply-To: <20101201122829.902DB268362E@lawyers.icir.org> References: <133D9897FB9C5E4E9DF2779DC91E947C045EF44D@SLFSNX.rcs.alcatel-research.de> <20101201122829.902DB268362E@lawyers.icir.org> Date: Thu, 2 Dec 2010 04:59:33 -0800 Message-ID: From: Jerry Chu To: mallman@icir.org Content-Type: multipart/alternative; boundary=000e0cd406504b37c004966cfea2 X-System-Of-Record: true Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) 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, 02 Dec 2010 12:58:23 -0000 --000e0cd406504b37c004966cfea2 Content-Type: text/plain; charset=ISO-8859-1 Mark, This is an interesting proposal, and if this is what it must take to get to a WG consensus, then... so be it. But as I've pointed out before, the optimal IW is really a property of the path to the remote peer, not a single global value per server. But for a per destination cwnd cache to work, two conditions must be met: 1) previous connections have sent enough data to grow the cwnd near its optimal value, 2) a new connection finds a cache hit in the cwnd cache. Unfortunately the above two conditions often weren't met in our large scale tests, rendering the default IW (i.e., 3) for most of the connections, forcing us to find alternative solutions. One alternative solution we tried briefly to get around the low cwnd cache hit problem was to turn the default around to use IW10, unless it's a hit on the cwnd cache. We dubbed this scheme "negative cache". The rationale is IW10 can only cause damage to a remote peer at most once per server. I wonder what people think about this scheme. The per IW global tracking how IW-N has done so far has a flaw in that it glosses over all the data in a single sum, losing the per-path nature of IW. Ultimately it seems to be effectively limiting the damage a larger IW may have to no more than 5% (or whatever threshold) of remote peers. This may work well for some specific cases, e.g., hosts that are behind slow or highly multiplex links with insufficient egress buffer. But for the vast majority of computing devices on the Internet our large scale data already show that IW10 potentially hurt << 5% of peers. If our data can be generalized, it will mean this active per IW monitoring is mostly moot. E.g., our servers will likely never fail the IW10 test. Oh, I see it does point to a growth path to go beyond IW10. But then have people changed their minds now to tolerate the potential damage to, e.g., 5% of users? Also once an IW value is validated for an extended period of time, it should stick (i.e., no need to continue the validation of the same IW value). Jerry On Wed, Dec 1, 2010 at 4:28 AM, Mark Allman wrote: > > > Just a thought about that: Why not to use a limit of the number of > > connections, instead of a time period? Or, somethink like: "min(10000 > > connections, 1 month)" ? > > > > The potential harm of a too large IW somehow scales with the number of > > connections that actually use it. > > Four answers: > > + I think it'd be fine to make *decrease* decisions every N > connections. But, conservativeness makes me think that you > shouldn't get to increase IW every N connections, but that should be > based on some amount of time. (Perhaps if N is not 1K, but 100K > then this would be basically equivalent.) > > + The whole idea is that we limit the "potential harm" by the way we > develop IW to begin with. So, even if IW=X is not working > particularly well it isn't causing massive harm because IW=X-1 > worked fine the month before. We can come up with examples where > this is not the case because a host gets dumped in a new situation > or something, but in the aggregate this seems like a reasonable way > to look at "potential harm". > > + As I noted in my email, I think it'd be perfectly fine for a host to > make a local policy decision that makes it more conservative than > allowed. I.e., trying to short-circuit (i.e., before the end of the > time period) using an IW increase that turns out to not be useful. > > + I don't think we need to over-engineer this to somehow try for > optimality. The overall point is to arrive at an initial parameter > that is reasonable for a given situation. > > allman > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --000e0cd406504b37c004966cfea2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark,

This is an interesting proposal, and if this is wh= at it must take to get to a WG
consensus,=A0then... so be it. But= as I've pointed out before, the optimal IW is
really a prope= rty of the path to the remote peer, not a single global value per
server.

But for a per destination cwnd cache = to work, two conditions must be met:
1) previous connections have= sent enough data to=A0grow the cwnd near its optimal=A0
value, 2= ) a new connection finds a cache hit=A0in the cwnd cache.

Unfortunately the above two conditions often weren'= t met in our large scale tests,
rendering the default IW (i.e., 3= ) for most of the connections,=A0forcing us to find
alternative s= olutions.

One alternative solution we tried briefly to get around= the low cwnd cache hit
problem was to turn the default around to= use IW10, unless it's a hit on the
cwnd cache. We dubbed thi= s scheme "negative=A0cache". The rationale is IW10
can only cause damage to a remote peer at most=A0once per server. I wo= nder
what people think about this scheme.

The per IW global tracking how IW-N has done so far has a flaw in that it=
glosses=A0over all the data in a single sum, losing the per-path natur= e of IW.
Ultimately it seems to be effectively limiting the damag= e a larger IW may
have to no more than 5% (or whatever threshold)= of remote peers. This
may work well for some specific cases, e.g., hosts that are behind slo= w or
highly=A0multiplex links with insufficient egress buffer. Bu= t for the vast majority
of computing devices on the Internet our = large scale data already show that
IW10 potentially hurt << 5% of peers. If our data can be general= ized, it will
mean this active per IW monitoring is mostly moot. = E.g., our servers will
likely never fail the IW10 test. Oh, I see= it does point to a growth path to go
beyond=A0IW10. But then have people changed their minds now to tolerat= e the
potential damage to, e.g., 5% of users?

Also once an IW value is validated for an extended period of time, it= should
stick (i.e., no need to continue the validation of the same IW value).=

Jerry

On= Wed, Dec 1, 2010 at 4:28 AM, Mark Allman <mallman@icir.org> wrote:

> Just a thought about that: Why not to use a limit of the number of
> connections, instead of a time period? Or, somethink like: "min(1= 0000
> connections, 1 month)" ?
>
> The potential harm of a too large IW somehow scales with the number of=
> connections that actually use it.

Four answers:

=A0+ I think it'd be fine to make *decrease* decisions every N
=A0 =A0connections. =A0But, conservativeness makes me think that you
=A0 =A0shouldn't get to increase IW every N connections, but that shou= ld be
=A0 =A0based on some amount of time. =A0(Perhaps if N is not 1K, but 100K<= br> =A0 =A0then this would be basically equivalent.)

=A0+ The whole idea is that we limit the "potential harm" by the= way we
=A0 =A0develop IW to begin with. =A0So, even if IW=3DX is not working
=A0 =A0particularly well it isn't causing massive harm because IW=3DX-= 1
=A0 =A0worked fine the month before. =A0We can come up with examples where=
=A0 =A0this is not the case because a host gets dumped in a new situation<= br> =A0 =A0or something, but in the aggregate this seems like a reasonable way=
=A0 =A0to look at "potential harm".

=A0+ As I noted in my email, I think it'd be perfectly fine for a host= to
=A0 =A0make a local policy decision that makes it more conservative than =A0 =A0allowed. =A0I.e., trying to short-circuit (i.e., before the end of = the
=A0 =A0time period) using an IW increase that turns out to not be useful.<= br>
=A0+ I don't think we need to over-engineer this to somehow try for =A0 =A0optimality. =A0The overall point is to arrive at an initial paramet= er
=A0 =A0that is reasonable for a given situation.

allman





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


--000e0cd406504b37c004966cfea2-- From mallman@icir.org Thu Dec 2 06:03: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 79CD528C13C for ; Thu, 2 Dec 2010 06:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.694 X-Spam-Level: X-Spam-Status: No, score=-105.694 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, PLING_QUERY=1.39, 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 8R2cGZdO8KOO for ; Thu, 2 Dec 2010 06:03:46 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 26E7B28C13A for ; Thu, 2 Dec 2010 06:03:46 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oB2E4vNs015033; Thu, 2 Dec 2010 06:04:57 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 014E2269656B; Thu, 2 Dec 2010 09:04:56 -0500 (EST) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: On the Cover of the Rolling Stone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma42887-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 02 Dec 2010 09:04:56 -0500 Sender: mallman@icir.org Message-Id: <20101202140457.014E2269656B@lawyers.icir.org> Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 14:03:47 -0000 ----------ma42887-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Jerry- > This is an interesting proposal, and if this is what it must take to > get to a WG consensus, then... so be it. Note, I have seen enough evidence to support IW=10. For me this isn't a fallback to "if we can't get 10 we can get something". For me this is simply a *better* proposal. > But as I've pointed out before, the optimal IW is really a property of > the path to the remote peer, not a single global value per server. We should forget the notion of an "optimal IW". As I sketched in the note at the beginning of this thread, o There is not likely a one-size-fits-all set of initial parameters for TCP. o We have traditionally addressed this heterogeneity by picking initial parameters that are "safe" in the overwhelming majority of the cases. I don't think those are radical statements. To the contrary, I think they are widely held views. > The per IW global tracking how IW-N has done so far has a flaw in that > it glosses over all the data in a single sum, losing the per-path > nature of IW. If that is a "flaw" of the proposal I sketched (again, really Joe's idea at the heart of it) then I claim it is a "flaw" in your proposal, too. In other words, your proposal (IW=10) and my old RFCs (IW=3) both also gloss over all situations with a single value and so they too "[lose] the per-path nature of IW". I think if you want to flag this as a "flaw" then you need to tell me how your proposal addresses it. I think you're just not thinking about this the right way. In both proposals we are trying to do *the same thing*: find a reasonable and general initial starting point for TCP. You did a lot of work, took a lot of measurements, etc. to arrive at IW=10 as something you have posited as reasonable. The proposed adaption scheme just says we should not codify *your answer*, but we should codify a *process* that arrives at a reasonable answer. And, it is largely the process you have gone through---i.e., try some new value, measure how it works, decide it is reasonable. And, it is largely the process we went through in developing RFC2414. > Ultimately it seems to be effectively limiting the damage a larger IW > may have to no more than 5% (or whatever threshold) of remote > peers. *Exactly*. That is one of the two basic points. We cannot move on IW=10 because we have not yet arrived at consensus that it doesn't somehow "hurt too much" (whatever that means). So, the idea of adaption spins things around. Instead of trying to find that value that is "safe" for broad use we punt and what we codify is our *tolerance for problems*. You can use any IW you want as long as you're within this tolerance level. > This may work well for some specific cases, e.g., hosts that are > behind slow or highly multiplex links with insufficient egress > buffer. But for the vast majority of computing devices on the Internet > our large scale data already show that IW10 potentially hurt << 5% of > peers. If our data can be generalized, it will mean this active per IW > monitoring is mostly moot. E.g., our servers will likely never fail > the IW10 test. Oh, I see it does point to a growth path to go beyond > IW10. But then have people changed their minds now to tolerate the > potential damage to, e.g., 5% of users? And, that's the other point. Yes, I understand you have gone through great effort within Google to figure out that for Google IW=10 is fine. But, who else has? And, do we want everyone to have to go to such effort? And, further, in a few years do you want to go through the effort again for IW=20? What the proposal asks people to do is to stop thinking about this problem as one of choosing an initial parameter value, but rather think about it in terms of choosing a process for picking an initial parameter, as well as choosing a particular tolerance for harm. Have people changed their minds? I don't know. I have. > Also once an IW value is validated for an extended period of time, it > should stick (i.e., no need to continue the validation of the same IW > value). Well... perhaps. I view the validation is O(free) and it isn't hard to conjure schemes whereby changes to a host's situation could cause the long-term validated IW to fail (e.g., change of ISP, change of traffic management policy, etc.). I understand your world is racks and racks of hosts that don't change their context, but the world is a heterogeneous and messy place and this monitoring doesn't seem like a particularly steep price to me. allman ----------ma42887-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz3p4gACgkQWyrrWs4yIs5nVQCgjI2V+FqFPucBDqWaUg7xJm7p AC0An2PdadP/JfdtntxWRIMaJmB+BXap =Idcc -----END PGP SIGNATURE----- ----------ma42887-1-- From ilpo.jarvinen@helsinki.fi Thu Dec 2 06:05: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 1241328C131 for ; Thu, 2 Dec 2010 06:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.604 X-Spam-Level: X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, PLING_QUERY=1.39, 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 KYHpWvpVH2Al for ; Thu, 2 Dec 2010 06:04:59 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 7967628C142 for ; Thu, 2 Dec 2010 06:04:58 -0800 (PST) Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 02 Dec 2010 16:06:12 +0200 id 00093E50.4CF7A7D4.00000EBE Date: Thu, 2 Dec 2010 16:06:12 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi To: Jerry Chu In-Reply-To: Message-ID: References: <133D9897FB9C5E4E9DF2779DC91E947C045EF44D@SLFSNX.rcs.alcatel-research.de> <20101201122829.902DB268362E@lawyers.icir.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1099979375-1291298772=:11898" Cc: tcpm@ietf.org, "SCHARF, Michael" , mallman@icir.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) 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, 02 Dec 2010 14:05:01 -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-1099979375-1291298772=:11898 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 2 Dec 2010, Jerry Chu wrote: > This is an interesting proposal, and if this is what it must take to get to > a WG > consensus, then... so be it. But as I've pointed out before, the optimal IW > is > really a property of the path to the remote peer, not a single global value > per > server. I don't think anybody questions that, the aim of the proposal is not the solve problems that occur for one path, but prevent problems when they start to show up for most or significant amount of paths. There are two independent cases here, one which affect all paths and the other which affect an individual path, and this 5% proposal is supposed to solve only the first one. > But for a per destination cwnd cache to work, two conditions must be met: > 1) previous connections have sent enough data to grow the cwnd near its > optimal  > value, 2) a new connection finds a cache hit in the cwnd cache. > > Unfortunately the above two conditions often weren't met in our large scale > tests, > rendering the default IW (i.e., 3) for most of the connections, forcing us > to find > alternative solutions. I don't remember how quickly the entries from the cache were removed in your tests but here the time (in cache) is expected to be significantly longer in time. Therefore likelyhoods are increased that the particular path in use for a single connection has its previous "vote" counted into the statistics (of course with a rather negligible share though). > One alternative solution we tried briefly to get around the low cwnd cache > hit > problem was to turn the default around to use IW10, unless it's a hit on the > cwnd cache. We dubbed this scheme "negative cache". The rationale is IW10 > can only cause damage to a remote peer at most once per server. I wonder > what people think about this scheme. So you'd put a flow into this negative cache whenever a problem shows up? I doubt that a single indication of a loss in IW would really correlate to all flows to that particular destination will lose with IW10. ...I also doubt that this really works because it is subject to the same low hit rate problem and need to replace older entries. ...It would be once per some cache recycle time per server at best. Btw, such a technique would be more conservative and therefore certainly allowed if there's green light from the 5% proposal for IW10. So nothing prevents you to deploy it if you want in addition to 5% proposal (I doubt that provides any real benefits though). > The per IW global tracking how IW-N has done so far has a flaw in that it > glosses over all the data in a single sum, losing the per-path nature of IW. > Ultimately it seems to be effectively limiting the damage a larger IW may > have to no more than 5% (or whatever threshold) of remote peers. This > may work well for some specific cases, e.g., hosts that are behind slow or > highly multiplex links with insufficient egress buffer. But for the vast > majority > of computing devices on the Internet our large scale data already show that > IW10 potentially hurt << 5% of peers. If our data can be generalized, it > will > mean this active per IW monitoring is mostly moot. E.g., our servers will > likely never fail the IW10 test. Oh, I see it does point to a growth path to > go > beyond IW10. But then have people changed their minds now to tolerate the > potential damage to, e.g., 5% of users? I was thinking that there wouldn't be real and significant problems because of losses due to larger IW. ...So I fail to understand your position now, why those 5% of users suddently get "damaged"? They might get (more) losses but what/where is the damage? On the other hand, I think that the delay impact is much worse than losses, esp. in a case where losses didn't happen, but it is not detected by the 5% proposal at all. I agree with you that for the cases you've measured on Google's servers, it is sure to be moot technique, however, I'm not sure if that can be generalized to all servers/senders. > Also once an IW value is validated for an extended period of time, it should > stick (i.e., no need to continue the validation of the same IW value). I don't agree with you... Also load in the whole Internet would have to remain the same if this is to hold... Besides, if the higher IW is sustainable, continuing the validation does no harm right? -- i. --8323329-1099979375-1291298772=:11898-- From hkchu@google.com Thu Dec 2 07:28: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 6546628C125 for ; Thu, 2 Dec 2010 07:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.125 X-Spam-Level: X-Spam-Status: No, score=-109.125 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8buE0JYwq1lY for ; Thu, 2 Dec 2010 07:28:35 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1221B28C115 for ; Thu, 2 Dec 2010 07:28:34 -0800 (PST) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id oB2FTnRg012406 for ; Thu, 2 Dec 2010 07:29:49 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291303790; bh=KH9A0TXsd7L5xNKW9tIk7IVtjxE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=RqgLmiakCWWqceMW6IRnYtPo4kMgLX4aAQ+ki0RMTcK7nQiFy9nPSCXV7Bu9l8LhE otn+Bgp6KJTKhXxJhqbSg== Received: from gyd5 (gyd5.prod.google.com [10.243.49.197]) by kpbe20.cbf.corp.google.com with ESMTP id oB2FTa3K009156 for ; Thu, 2 Dec 2010 07:29:48 -0800 Received: by gyd5 with SMTP id 5so4403009gyd.11 for ; Thu, 02 Dec 2010 07:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PSgIG1ifVVaMLTsWwIq3z5Bhk1WikRP7+kdc1OOAtGc=; b=xcrGI/ZeBinMLD8j6QJMXcy987exAs51HTBlmmI/rCnHqvCdoSU6731j+pa8eDHrdo oTdBhleUb34toLZmhN1w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n3V7faPg6AufezD3owAQF3/SWxqyVQ1FbYv7oZUbUOmIlHTC9kJv94Ft3Y5GrHm3Xf F32cyGN0V2wb20h+r76Q== MIME-Version: 1.0 Received: by 10.151.13.13 with SMTP id q13mr1638843ybi.291.1291303787462; Thu, 02 Dec 2010 07:29:47 -0800 (PST) Received: by 10.151.158.13 with HTTP; Thu, 2 Dec 2010 07:29:47 -0800 (PST) In-Reply-To: <20101202140457.014E2269656B@lawyers.icir.org> References: <20101202140457.014E2269656B@lawyers.icir.org> Date: Thu, 2 Dec 2010 07:29:47 -0800 Message-ID: From: Jerry Chu To: mallman@icir.org Content-Type: multipart/alternative; boundary=000e0cd6a9308c832c04966f17d0 X-System-Of-Record: true Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) 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, 02 Dec 2010 15:28:37 -0000 --000e0cd6a9308c832c04966f17d0 Content-Type: text/plain; charset=ISO-8859-1 Mark, On Thu, Dec 2, 2010 at 6:04 AM, Mark Allman wrote: > > Jerry- > > > This is an interesting proposal, and if this is what it must take to > > get to a WG consensus, then... so be it. > > Note, I have seen enough evidence to support IW=10. For me this isn't a > fallback to "if we can't get 10 we can get something". For me this is > simply a *better* proposal. > > > But as I've pointed out before, the optimal IW is really a property of > > the path to the remote peer, not a single global value per server. > > We should forget the notion of an "optimal IW". As I sketched in the > note at the beginning of this thread, > > o There is not likely a one-size-fits-all set of initial > parameters for TCP. > > o We have traditionally addressed this heterogeneity by picking > initial parameters that are "safe" in the overwhelming majority > of the cases. > > I don't think those are radical statements. To the contrary, I think > they are widely held views. > > > The per IW global tracking how IW-N has done so far has a flaw in that > > it glosses over all the data in a single sum, losing the per-path > > nature of IW. > > If that is a "flaw" of the proposal I sketched (again, really Joe's idea > at the heart of it) then I claim it is a "flaw" in your proposal, too. > In other words, your proposal (IW=10) and my old RFCs (IW=3) both also > gloss over all situations with a single value and so they too "[lose] > the per-path nature of IW". I think if you want to flag this as a > "flaw" then you need to tell me how your proposal addresses it. > No, by "flaw" I meant the new proposal is flawed as the old (IW10) one, and I thought this flaw was why Joe was against the old one so why the new one is any better now? I'm assuming one reason why Joe was against IW10 was because it might penalize a small percentage of users and Joe wanted a solution that worked for all users. If that's his position then no single, fixed IW beyond some value will ever work. Or perhaps you and Joe are now saying penalizing a small percentage of users is acceptable? But we've already shown in our extensive tests IW10 only penalize a very small percentage of users. Or perhaps the active monitoring mechanism you propose is considered more robust, which I don't disagree? One perhaps the active monitor can help capturing some special cases, e.g., those hosts behind very slow link where IW-N with N > 1 is universally bad? > > I think you're just not thinking about this the right way. In both > proposals we are trying to do *the same thing*: find a reasonable and > general initial starting point for TCP. You did a lot of work, took a > lot of measurements, etc. to arrive at IW=10 as something you have > posited as reasonable. The proposed adaption scheme just says we should > not codify *your answer*, but we should codify a *process* that arrives > at a reasonable answer. And, it is largely the process you have gone > through---i.e., try some new value, measure how it works, decide it is > reasonable. And, it is largely the process we went through in > developing RFC2414. > Understood. I saw this part later as I said previously "it does point to a growth path to go beyond IW10". > > Ultimately it seems to be effectively limiting the damage a larger IW > > may have to no more than 5% (or whatever threshold) of remote > > peers. > > *Exactly*. That is one of the two basic points. We cannot move on > IW=10 because we have not yet arrived at consensus that it doesn't > somehow "hurt too much" (whatever that means). So, the idea of adaption > spins things around. Instead of trying to find that value that is > "safe" for broad use we punt and what we codify is our *tolerance for > problems*. You can use any IW you want as long as you're within this > tolerance level. > > > This may work well for some specific cases, e.g., hosts that are > > behind slow or highly multiplex links with insufficient egress > > buffer. But for the vast majority of computing devices on the Internet > > our large scale data already show that IW10 potentially hurt << 5% of > > peers. If our data can be generalized, it will mean this active per IW > > monitoring is mostly moot. E.g., our servers will likely never fail > > the IW10 test. Oh, I see it does point to a growth path to go beyond > > IW10. But then have people changed their minds now to tolerate the > > potential damage to, e.g., 5% of users? > > And, that's the other point. Yes, I understand you have gone through > great effort within Google to figure out that for Google IW=10 is fine. > But, who else has? And, do we want everyone to have to go to such > effort? And, further, in a few years do you want to go through the > effort again for IW=20? > > What the proposal asks people to do is to stop thinking about this > problem as one of choosing an initial parameter value, but rather think > about it in terms of choosing a process for picking an initial > parameter, as well as choosing a particular tolerance for harm. Have > people changed their minds? I don't know. I have. > Points taken, as long as people feel penalizing 5% of users is an acceptable cost. I certainly do. > > Also once an IW value is validated for an extended period of time, it > > should stick (i.e., no need to continue the validation of the same IW > > value). > > Well... perhaps. I view the validation is O(free) and it isn't hard to > conjure schemes whereby changes to a host's situation could cause the > long-term validated IW to fail (e.g., change of ISP, change of traffic > management policy, etc.). I understand your world is racks and racks of > hosts that don't change their context, but the world is a heterogeneous > and messy place and this monitoring doesn't seem like a particularly > steep price to me. > Ok. Jerry > > allman > > > > --000e0cd6a9308c832c04966f17d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mark,

On Thu, Dec 2, 2010 at 6:04 AM, Mark Allman = <mallman@icir.org<= /a>> wrote:

Jerry-

> This is an interesting proposal, and if this is what it must take to > get to a WG consensus, then... so be it.

Note, I have seen enough evidence to support IW=3D10. =A0For me this = isn't a
fallback to "if we can't get 10 we can get something". =A0For= me this is
simply a *better* proposal.

> But as I've pointed out before, the optimal IW is really a propert= y of
> the path to the remote peer, not a single global value per server.

We should forget the notion of an "optimal IW". =A0As I ske= tched in the
note at the beginning of this thread,

=A0o There is not likely a one-size-fits-all set of initial
=A0 =A0parameters for TCP.

=A0o We have traditionally addressed this heterogeneity by picking
=A0 =A0initial parameters that are "safe" in the overwhelming ma= jority
=A0 =A0of the cases.

I don't think those are radical statements. =A0To the contrary, I= think
they are widely held views.

> The per IW global tracking how IW-N has done so far has a flaw in that=
> it glosses over all the data in a single sum, losing the per-path
> nature of IW.

If that is a "flaw" of the proposal I sketched (again, real= ly Joe's idea
at the heart of it) then I claim it is a "flaw" in your proposal,= too.
In other words, your proposal (IW=3D10) and my old RFCs (IW=3D3) both also<= br> gloss over all situations with a single value and so they too "[lose]<= br> the per-path nature of IW". =A0I think if you want to flag this as a "flaw" then you need to tell me how your proposal addresses it.

No, by "flaw" I meant the new = proposal is flawed as the old (IW10)
one, and I thought this flaw= was why Joe was against the old one
so why the new one is any better now? I'm assuming one reason
why Joe was against IW10 was because it might penalize a small
<= div>percentage of users and Joe wanted a solution that worked for all
users. If that's his position then no single, fixed IW beyond some=
value will ever work.

Or perhaps you an= d Joe are now saying penalizing a small percentage
of=A0users=A0i= s acceptable? But we've already shown in our extensive tests
IW10=A0only penalize a very small percentage of users.

<= /div>
Or=A0perhaps the active monitoring mechanism you propose is consi= dered
more robust, which I don't disagree? One perhaps the ac= tive monitor
can help capturing some special cases, e.g., those hosts behind very
slow=A0link where IW-N with N > 1 is universally bad?
=A0

I think you're just not thinking about this the right way. =A0In both proposals we are trying to do *the same thing*: find a reasonable and
general initial starting point for TCP. =A0You did a lot of work, took a lot of measurements, etc. to arrive at IW=3D10 as something you have
posited as reasonable. =A0The proposed adaption scheme just says we should<= br> not codify *your answer*, but we should codify a *process* that arrives
at a reasonable answer. =A0And, it is largely the process you have gone
through---i.e., try some new value, measure how it works, decide it is
reasonable. =A0And, it is largely the process we went through in
developing RFC2414.

Understood. I saw t= his part later as I said previously "it does point to a
grow= th path to go=A0beyond IW10".


> Ultimately it seems to be effectively limiting the damage a larger IW<= br> > may have to no more than 5% (or whatever threshold) of remote
> peers.

*Exactly*. =A0That is one of the two basic points. =A0We cannot move = on
IW=3D10 because we have not yet arrived at consensus that it doesn't somehow "hurt too much" (whatever that means). =A0So, the idea of= adaption
spins things around. =A0Instead of trying to find that value that is
"safe" for broad use we punt and what we codify is our *tolerance= for
problems*. =A0You can use any IW you want as long as you're within this=
tolerance level.

> This may work well for some specific cases, e.g., hosts that are
> behind slow or highly multiplex links with insufficient egress
> buffer. But for the vast majority of computing devices on the Internet=
> our large scale data already show that IW10 potentially hurt << = 5% of
> peers. If our data can be generalized, it will mean this active per IW=
> monitoring is mostly moot. E.g., our servers will likely never fail > the IW10 test. =A0Oh, I see it does point to a growth path to go beyon= d
> IW10. But then have people changed their minds now to tolerate the
> potential damage to, e.g., 5% of users?

And, that's the other point. =A0Yes, I understand you have gone t= hrough
great effort within Google to figure out that for Google IW=3D10 is fine. But, who else has? =A0And, do we want everyone to have to go to such
effort? =A0And, further, in a few years do you want to go through the
effort again for IW=3D20?

What the proposal asks people to do is to stop thinking about this
problem as one of choosing an initial parameter value, but rather think
about it in terms of choosing a process for picking an initial
parameter, as well as choosing a particular tolerance for harm. =A0Have
people changed their minds? =A0I don't know. =A0I have.

Points taken, as long as people feel penalizing 5% of = users is an acceptable
cost. I certainly do.


> Also once an IW value is validated for an extended period of time, it<= br> > should stick (i.e., no need to continue the validation of the same IW<= br> > value).

Well... perhaps. =A0I view the validation is O(free) and it isn't= hard to
conjure schemes whereby changes to a host's situation could cause the long-term validated IW to fail (e.g., change of ISP, change of traffic
management policy, etc.). =A0I understand your world is racks and racks of<= br> hosts that don't change their context, but the world is a heterogeneous=
and messy place and this monitoring doesn't seem like a particularly steep price to me.

Ok.

Jerry
=A0

allman




--000e0cd6a9308c832c04966f17d0-- From mallman@icir.org Thu Dec 2 07:44:34 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 6551B28C183 for ; Thu, 2 Dec 2010 07:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.675 X-Spam-Level: X-Spam-Status: No, score=-105.675 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, PLING_QUERY=1.39, 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 5HE+4Ij3tHFA for ; Thu, 2 Dec 2010 07:44:32 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id A7E3328C18E for ; Thu, 2 Dec 2010 07:44:32 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oB2FjiNF023371; Thu, 2 Dec 2010 07:45:44 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F08C62698AB3; Thu, 2 Dec 2010 10:45:43 -0500 (EST) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: On the Cover of the Rolling Stone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma48935-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 02 Dec 2010 10:45:43 -0500 Sender: mallman@icir.org Message-Id: <20101202154543.F08C62698AB3@lawyers.icir.org> Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 15:44:34 -0000 ----------ma48935-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Points taken, as long as people feel penalizing 5% of users is an > acceptable cost. I certainly do. If there is no "acceptable cost" then the WG should remove this item From=20its plate, we should all forget about it and not talk about it any more. The adaption proposal codifies this acceptable cost (forget 5%---that was out of thin air; maybe its 10%, maybe its 2%...I dunno). It does not strictly limit the cost, but tries to manage it. That is, just because > 95% worked on my machine last month doesn't necessarily mean > 95% will work this month, but last month's data is not for nothin' either.=20=20 That is a **whole lot** better than what you can say about a static IW=3D10 rule. You can say something like "well, for Google in early 2010 IW=3D10 worked for > X%" (etc.). But, how does that extrapolate to my host? Or, to mid-2011? While I think your measurements are suggestive that IW=3D10 does in fact generalize to being "safe enough", you clearly have not convinced the WG yet. If instead of trying to gather up enough anecdotes to convince ourselves the specific value is "safe enough" lets just define what "safe enough" means and leave it at that. allman ----------ma48935-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz3vycACgkQWyrrWs4yIs5+qwCfbV3hSXa9a9VGgZpnwL/lglLh 1tUAnR5EwUIZnBlukMcldMoaiRs4uV+w =nujN -----END PGP SIGNATURE----- ----------ma48935-1-- From hkchu@google.com Thu Dec 2 07:54: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 F0F3728C115 for ; Thu, 2 Dec 2010 07:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.981 X-Spam-Level: X-Spam-Status: No, score=-104.981 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, PLING_QUERY=1.39, 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 MxO1IkyWz2+w for ; Thu, 2 Dec 2010 07:54:13 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 56D4F28C148 for ; Thu, 2 Dec 2010 07:54:13 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id oB2FtSRx032380 for ; Thu, 2 Dec 2010 07:55:28 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291305328; bh=iMGi/Jw+f3D7wxB8jh9wuNIWrww=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=W67Tbnc62Kif8FI6mIaElRrHOXEKSTbHkKQqgE7TVKqpCNCOEY1QQbXWjDp1Qnp4H Hgn2OyjAsXHwVlSttKuOg== Received: from gwb17 (gwb17.prod.google.com [10.200.2.17]) by kpbe18.cbf.corp.google.com with ESMTP id oB2FskQv025401 for ; Thu, 2 Dec 2010 07:55:09 -0800 Received: by gwb17 with SMTP id 17so4978307gwb.2 for ; Thu, 02 Dec 2010 07:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tLpwoz/H1v7smFRz7bgRnVmjmoje6ANqd70urqLDFG8=; b=ryRD0zPLcIpSf4zE47BNJr+zLyNlR4TWD/j6XwFQoHCgD/K+rqxo2sOYw4H2oZrDmQ S/D/Trf70pQg+kTZbCow== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rMbomTEbKZIn3qf8iWnpWdvNA1IEGY1Ih5H2h+5+Q5thC9P5kNveaujr4toENtK9lL xrQrxtGC/6WOrVtTHAZg== MIME-Version: 1.0 Received: by 10.151.150.4 with SMTP id c4mr1823395ybo.6.1291305303849; Thu, 02 Dec 2010 07:55:03 -0800 (PST) Received: by 10.151.158.13 with HTTP; Thu, 2 Dec 2010 07:55:03 -0800 (PST) In-Reply-To: References: <133D9897FB9C5E4E9DF2779DC91E947C045EF44D@SLFSNX.rcs.alcatel-research.de> <20101201122829.902DB268362E@lawyers.icir.org> Date: Thu, 2 Dec 2010 07:55:03 -0800 Message-ID: From: Jerry Chu To: =?ISO-8859-1?Q?Ilpo_J=E4rvinen?= Content-Type: multipart/alternative; boundary=00151750d8caeebe6404966f7152 X-System-Of-Record: true Cc: tcpm@ietf.org, "SCHARF, Michael" , mallman@icir.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) 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, 02 Dec 2010 15:54:16 -0000 --00151750d8caeebe6404966f7152 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ilpo, On Thu, Dec 2, 2010 at 6:06 AM, Ilpo J=E4rvinen = wrote: > On Thu, 2 Dec 2010, Jerry Chu wrote: > > > This is an interesting proposal, and if this is what it must take to ge= t > to > > a WG > > consensus, then... so be it. But as I've pointed out before, the optima= l > IW > > is > > really a property of the path to the remote peer, not a single global > value > > per > > server. > > I don't think anybody questions that, the aim of the proposal is not the > solve problems that occur for one path, but prevent problems when they > start to show up for most or significant amount of paths. > > There are two independent cases here, one which affect all paths and the > other which affect an individual path, and this 5% proposal is supposed t= o > solve only the first one. > > > But for a per destination cwnd cache to work, two conditions must be me= t: > > 1) previous connections have sent enough data to grow the cwnd near its > > optimal > > value, 2) a new connection finds a cache hit in the cwnd cache. > > > > Unfortunately the above two conditions often weren't met in our large > scale > > tests, > > rendering the default IW (i.e., 3) for most of the connections, forcing > us > > to find > > alternative solutions. > > I don't remember how quickly the entries from the cache were removed in > This is tunable but even if we set the cache to infinity (assuming infinite amount of memory) many connections just don't come back to the same server due to load balancing across large amount of servers. > your tests but here the time (in cache) is expected to be significantly > longer in time. Therefore likelyhoods are increased that the particular > path in use for a single connection has its previous "vote" counted into > the statistics (of course with a rather negligible share though). > In the new scheme a vote will always be counted (not sure what you meant). > > > One alternative solution we tried briefly to get around the low cwnd > cache > > hit > > problem was to turn the default around to use IW10, unless it's a hit o= n > the > > cwnd cache. We dubbed this scheme "negative cache". The rationale is IW= 10 > > can only cause damage to a remote peer at most once per server. I wonde= r > > what people think about this scheme. > > So you'd put a flow into this negative cache whenever a problem shows up? > I doubt that a single indication of a loss in IW would really correlate t= o > all flows to that particular destination will lose with IW10. ...I also > doubt that this really works because it is subject to the same low hit > rate problem and need to replace older entries. ...It would be once per > Correct. some cache recycle time per server at best. > > Btw, such a technique would be more conservative and therefore certainly > allowed if there's green light from the 5% proposal for IW10. So nothing > prevents you to deploy it if you want in addition to 5% proposal (I doubt > that provides any real benefits though). > > > The per IW global tracking how IW-N has done so far has a flaw in that = it > > glosses over all the data in a single sum, losing the per-path nature o= f > IW. > > Ultimately it seems to be effectively limiting the damage a larger IW m= ay > > have to no more than 5% (or whatever threshold) of remote peers. This > > may work well for some specific cases, e.g., hosts that are behind slow > or > > highly multiplex links with insufficient egress buffer. But for the vas= t > > majority > > of computing devices on the Internet our large scale data already show > that > > IW10 potentially hurt << 5% of peers. If our data can be generalized, i= t > > will > > mean this active per IW monitoring is mostly moot. E.g., our servers wi= ll > > likely never fail the IW10 test. Oh, I see it does point to a growth pa= th > to > > go > > beyond IW10. But then have people changed their minds now to tolerate t= he > > potential damage to, e.g., 5% of users? > > I was thinking that there wouldn't be real and significant problems > because of losses due to larger IW. ...So I fail to understand your > position now, why those 5% of users suddently get "damaged"? They might > get (more) losses but what/where is the damage? > By damage I meant possibly more losses. Again see my reply to Mark. I'm saying why is the new scheme any better than the old (IW10). Guess the answer is it's more robust, and providing a dynamic path to higher IW. > > On the other hand, I think that the delay impact is much worse than > losses, esp. in a case where losses didn't happen, but it is not detected > by the 5% proposal at all. > So what can you do about it? > > I agree with you that for the cases you've measured on Google's servers, > it is sure to be moot technique, however, I'm not sure if that can be > generalized to all servers/senders. > Understood. > > > Also once an IW value is validated for an extended period of time, it > should > > stick (i.e., no need to continue the validation of the same IW value). > > I don't agree with you... Also load in the whole Internet would have to > remain the same if this is to hold... Besides, if the higher IW is > sustainable, continuing the validation does no harm right? > Correct. I'm just thinking to spare some complexity to those simple stack (e.g., running on TinyOS). E.g., at some point IETF can endorse, e.g., IW10 universally. I guess there is room for refinement but it's not critical right now. Jerry > > > -- > i. --00151750d8caeebe6404966f7152 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ilpo,

On Thu, Dec 2, 2010 at 6:06 AM, Ilpo J=E4= rvinen <i= lpo.jarvinen@helsinki.fi> wrote:
On Thu, 2 Dec 2010, Jerry Chu wrote:

> This is an interesting proposal, and if this is what it must take to g= et to
> a WG
> consensus,=A0then... so be it. But as I've pointed out before, the= optimal IW
> is
> really a property of the path to the remote peer, not a single global = value
> per
> server.

I don't think anybody questions that, the aim of the proposal is = not the
solve problems that occur for one path, but prevent problems when they
start to show up for most or significant amount of paths.

There are two independent cases here, one which affect all paths and the other which affect an individual path, and this 5% proposal is supposed to<= br> solve only the first one.

> But for a per destination cwnd cache to work, two conditions must be m= et:
> 1) previous connections have sent enough data to=A0grow the cwnd near = its
> optimal=A0
> value, 2) a new connection finds a cache hit=A0in the cwnd cache.
>
> Unfortunately the above two conditions often weren't met in our la= rge scale
> tests,
> rendering the default IW (i.e., 3) for most of the connections,=A0forc= ing us
> to find
> alternative solutions.

I don't remember how quickly the entries from the cache were remo= ved in

This is tunable but even if we s= et the cache to infinity (assuming infinite amount
of memory) man= y connections just don't come back to the same server due to
load balancing across large amount of servers.
=A0
your tests but here the time (in cache) is expected to be significantly
longer in time. Therefore likelyhoods are increased that the particular
path in use for a single connection has its previous "vote" count= ed into
the statistics (of course with a rather negligible share though).

In the new scheme a vote will always be counted = (not sure what you meant).
=A0

> One alternative solution we tried briefly to get around the low cwnd c= ache
> hit
> problem was to turn the default around to use IW10, unless it's a = hit on the
> cwnd cache. We dubbed this scheme "negative=A0cache". The ra= tionale is IW10
> can only cause damage to a remote peer at most=A0once per server. I wo= nder
> what people think about this scheme.

So you'd put a flow into this negative cache whenever a problem s= hows up?
I doubt that a single indication of a loss in IW would really correlate to<= br> all flows to that particular destination will lose with IW10. ...I also
doubt that this really works because it is subject to the same low hit
rate problem and need to replace older entries. ...It would be once per
=

Correct.

some cache recycle time per server at best.

Btw, such a technique would be more conservative and therefore certainly allowed if there's green light from the 5% proposal for IW10. So nothin= g
prevents you to deploy it if you want in addition to 5% proposal (I doubt that provides any real benefits though).

> The per IW global tracking how IW-N has done so far has a flaw in that= it
> glosses=A0over all the data in a single sum, losing the per-path natur= e of IW.
> Ultimately it seems to be effectively limiting the damage a larger IW = may
> have to no more than 5% (or whatever threshold) of remote peers. This<= br> > may work well for some specific cases, e.g., hosts that are behind slo= w or
> highly=A0multiplex links with insufficient egress buffer. But for the = vast
> majority
> of computing devices on the Internet our large scale data already show= that
> IW10 potentially hurt << 5% of peers. If our data can be general= ized, it
> will
> mean this active per IW monitoring is mostly moot. E.g., our servers w= ill
> likely never fail the IW10 test. Oh, I see it does point to a growth p= ath to
> go
> beyond=A0IW10. But then have people changed their minds now to tolerat= e the
> potential damage to, e.g., 5% of users?

I was thinking that there wouldn't be real and significant proble= ms
because of losses due to larger IW. ...So I fail to understand your
position now, why those 5% of users suddently get "damaged"? They= might
get (more) losses but what/where is the damage?

By damage I meant possibly more losses. Again see my reply to Mark= . I'm saying
why is the new scheme any better than the old (I= W10). Guess the answer is it's
more robust, and providing a dynamic path to higher IW.
=A0<= /div>

On the other hand, I think that the delay impact is much worse than
losses, esp. in a case where losses didn't happen, but it is not detect= ed
by the 5% proposal at all.

So what can = you do about it?
=A0

I agree with you that for the cases you've measured on Google's ser= vers,
it is sure to be moot technique, however, I'm not sure if that can be generalized to all servers/senders.

Und= erstood.
=A0

> Also once an IW value is validated for an extended period of time, it = should
> stick (i.e., no need to continue the validation of the same IW value).=

I don't agree with you... Also load in the whole Internet would h= ave to
remain the same if this is to hold... Besides, if the higher IW is
sustainable, continuing the validation does no harm right?
=

Correct. I'm just thinking to spare some complexity= to those simple stack (e.g.,
running on TinyOS). E.g., at some p= oint IETF can endorse, e.g., IW10 universally.
I guess there is room for refinement but it's not critical right n= ow.

Jerry
=A0


--
=A0i.

--00151750d8caeebe6404966f7152-- From mallman@icir.org Thu Dec 2 08:08: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 9552A28C13A for ; Thu, 2 Dec 2010 08:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.657 X-Spam-Level: X-Spam-Status: No, score=-105.657 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, PLING_QUERY=1.39, 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 dhO8+e2Auryt for ; Thu, 2 Dec 2010 08:08:25 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id CAC4028C115 for ; Thu, 2 Dec 2010 08:08:25 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oB2G9U7q025691; Thu, 2 Dec 2010 08:09:30 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6323A26996B7; Thu, 2 Dec 2010 11:09:29 -0500 (EST) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: On the Cover of the Rolling Stone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma50361-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 02 Dec 2010 11:09:29 -0500 Sender: mallman@icir.org Message-Id: <20101202160929.6323A26996B7@lawyers.icir.org> Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 16:08:26 -0000 ----------ma50361-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I'm saying why is the new scheme any better than the old (IW10). Guess > the answer is it's more robust, and providing a dynamic path to higher > IW. Exactly. If IW=10 is the right answer for your situation then the new scheme gets you here. But, it adds robustness if that is not the right answer. And, it adds the ability to adapt to larger values in the future. To me that is "better". If you feel that is needless complexity then we can just disagree. > Correct. I'm just thinking to spare some complexity to those simple > stack (e.g., running on TinyOS). Nothing says a stack *has* to do this. There is an IW for them. Its documented in RFC5681. Yes, there is a cost for moving to a higher IW. There is a cost associated with more effective loss recovery via SACK, too (as but one additional example). Its a choice whether you want to pay that cost or not. (That said, even for TinyOS this seems like a really trivial cost.) allman ----------ma50361-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz3xLkACgkQWyrrWs4yIs4HegCeJWEr5ujRVp3tMMFNalZcjc2U Hz8AoJP/8qEGbwmjGhf83ixGMo0g/aVD =Al8/ -----END PGP SIGNATURE----- ----------ma50361-1-- From touch@isi.edu Thu Dec 2 08:31:34 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 C2E4F28C165; Thu, 2 Dec 2010 08:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.05 X-Spam-Level: X-Spam-Status: No, score=-102.05 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 w73zOM40x59l; Thu, 2 Dec 2010 08:31:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id B392128C18B; Thu, 2 Dec 2010 08:29:27 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oB2GReEW024892 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 2 Dec 2010 08:27:40 -0800 (PST) Message-ID: <4CF70D65.7030306@isi.edu> Date: Wed, 01 Dec 2010 19:07:17 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: David Borman References: <78DB0ABC-24D1-41E1-BCC5-F70A950AD9C0@windriver.com> <2BFC5B36-F3B2-410B-845B-6F71B212EE8A@weston.borman.com> In-Reply-To: <2BFC5B36-F3B2-410B-845B-6F71B212EE8A@weston.borman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" , TSV Dir Subject: Re: [tcpm] Side meeting to discuss TCP Security document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 16:31:34 -0000 Dave, I've asked repeatedly off-list, so I'll ask on-list. Will there be a summary of the results of this meeting posted to the list? Joe On 11/9/2010 4:43 PM, David Borman wrote: > We have Diamond 2 reserved from 1:00-3:00 today, Wednesday. Anyone who is interested is welcome. > > -David Borman, TCPM co-chair > > On Nov 7, 2010, at 10:20 PM, David Borman wrote: > >> In Anaheim we had a small session to look at the TCP Security document, attended by a hand full of people. We are interested in doing this again here in Beijing. The goal is to go through some more of the document and come up with some recommendations for how to move forward with revising/editing the document, which will then be brought back to the list. >> >> So, there are 2 questions: >> 1) Who is interested in attending? >> 2) When should we meet? My recommendations for possibilities are, in order of preference: >> 1) Tuesday morning (NFSv4 meets at this time) >> 2) Wednesday after lunch (No TSV groups meet at this time) >> 3) Thursday morning (Congestion Exposure WG meets at this time) >> Please reply to me or the list if you are interested in this, and if so, which of those 3 periods you are available. Once we see who is interested and when they would be available, I'll see about finding a place to meet, but it won't be a regular session room, i.e. there won't be any remote participation. >> >> -David Borman, TCPM co-chair >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From ka-cheong.poon@oracle.com Thu Dec 2 08:32: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 9E04228C19F for ; Thu, 2 Dec 2010 08:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.904 X-Spam-Level: X-Spam-Status: No, score=-5.904 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, PLING_QUERY=1.39, 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 4sr9SmVufZ6K for ; Thu, 2 Dec 2010 08:32:06 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id F20D928C1A2 for ; Thu, 2 Dec 2010 08:32:05 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oB2GX6WJ008498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Dec 2010 16:33:08 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oB26XiPN026369 for ; Thu, 2 Dec 2010 16:33:05 GMT Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 837866521291307521; Thu, 02 Dec 2010 08:32:01 -0800 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Dec 2010 08:32:00 -0800 Message-ID: <4CF7C9FC.10906@oracle.com> Date: Fri, 03 Dec 2010 00:31:56 +0800 From: Kacheong Poon User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: tcpm@ietf.org References: <20101130170500.ED5732657E7F@lawyers.icir.org> In-Reply-To: <20101130170500.ED5732657E7F@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) 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, 02 Dec 2010 16:32:07 -0000 On 12/ 1/10 01:05 AM, Mark Allman wrote: > So, off-list I framed this to Joe and Aki. Its basically Joe's > idea, but with a few more details. As such, Joe will no doubt > correct it. :) So, do something like this: > > o On Jul/1 set IW=3 [i.e., RFC5681]. Also, start two counters for > each possible IW, 1--3: total number of connections using the > given IW and number of connections using that IW that > experienced loss in the initial window. Using this proposal, does it mean that a host randomly picks a value from 1 to IW_cur as the IW every time it starts a new TCP connection (assuming no cache hit)? Assuming IW=3 is really good for every one. This proposal automatically penalizes 2/3 of all the connections as they use a sub-optimal IW value comparing to the current default value. Does anyone really think that IW < 3 makes sense in today's Internet? Still assuming IW=3 is good for every one. Suppose IW_cur is 4 and 5% of all connections are not doing good at IW=4. Using this proposal, only 23.75% (24% * 95%) of all connections benefit from the IW increase and the rest is penalized. 50% of all connections are worse than the current situation. And then in the next month, IW_cur will be decremented to 3. Again 2/3 of all connections are penalized comparing to today's Internet. Then in the following month, IW_cur is incremented to 4 again. Story goes on. I probably misunderstood this proposal. The above cannot be right since the goal is to make the overall user experience better than today's situation, not worse.... Or are people really thinking that IW=3 is too aggressive even though TCP almost always send in burst of 3 or more segments? -- K. Poon. ka-cheong.poon@oracle.com From touch@isi.edu Thu Dec 2 08:38: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 837BB28C1A1 for ; Thu, 2 Dec 2010 08:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 rSmM8n3ik4XV for ; Thu, 2 Dec 2010 08:38:36 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id E45BF28C181 for ; Thu, 2 Dec 2010 08:38:30 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oB2GcZB0028023 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 2 Dec 2010 08:38:36 -0800 (PST) Message-ID: <4CF7CB8B.1030807@isi.edu> Date: Thu, 02 Dec 2010 08:38:35 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jerry Chu References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <4CF26596.7010500@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal 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, 02 Dec 2010 16:38:38 -0000 Jerry, On 12/2/2010 3:59 AM, Jerry Chu wrote: > Joe, > > On Sun, Nov 28, 2010 at 6:22 AM, Joe Touch > wrote: > > > Jerry, > > In short: > > a) the receive window is an indication of the receiver's ability to > reorder out-of-order packets; it limits what is sent primarily to > avoid useless transmissions that the receiver will drop, not as a > congestion control mechanism > > Wrong. The main purpose of the receive window is to flow control a > sender so a faster sender > won't overrun a slow receiver, period. The receive window is for reordering AND also allows large bandwidth-delay products to have outstanding data during the round-trip delay until ACKs are received. Neither of which has anything to do with the speed of the receiver per se. A fast receiver on a low-RTT link doesn't need a large receive window. > yes, I find it odd that you are injecting control of the > receive window to correct for IW issues in your draft > > > What's wrong with that? Please give a specific badness of it? You are confusing flow control with congestion control. > It works > very effectively. In > fact, I can't claim to be the inventor of this technique. It has been > mentioned in plenty of > RFCs. E.g., see RFC3150. That RFC makes the same error. The fact that you're using a hammer to drive in a screw doesn't make it a nail. > 2) NO AMOUNT of in-connection adjustment of CWND has any effect on > the impact of a poor choice of IW > > Yes it has. It limits the damage as Mark has pointed out. That's true ONLY for connections that last long enough to get that feedback. The curious thing is that a) such short connections is the reason you want to do this b) yet you seem to continue to want to ignore it as a factor If anyone else on the list needs more info on these points, I'll be glad to followup, but at this point further exchanges with you on these points don't seem productive. Joe From hkchu@google.com Thu Dec 2 09:00:46 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D948C28C11B for ; Thu, 2 Dec 2010 09:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.788 X-Spam-Level: X-Spam-Status: No, score=-109.788 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ykwc9FeznhNr for ; Thu, 2 Dec 2010 09:00:45 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 5818828C11A for ; Thu, 2 Dec 2010 09:00:45 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id oB2H20ve022849 for ; Thu, 2 Dec 2010 09:02:00 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291309320; bh=6W5+MFMrB+U2LtFQaF5fJKk9T+Y=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=GGpuTdiRpgHVlIbzO5x9k2njVW7yOt1j2HPSYVdSvBDk2/fScJPpuFtc4Z6eDSWzR MGyPG352T9ZKIqr8ITv7w== Received: from gyg8 (gyg8.prod.google.com [10.243.50.136]) by wpaz29.hot.corp.google.com with ESMTP id oB2H1w2Z022534 for ; Thu, 2 Dec 2010 09:01:59 -0800 Received: by gyg8 with SMTP id 8so4800756gyg.38 for ; Thu, 02 Dec 2010 09:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QL/XZ84LFzKnpSZGmjTUp8q3fJGKtAsgbUdtJOW+ZME=; b=PsQV5cdpfYJ1d6td1oEsDxXVi3l5W6dfiF/kVavffNOA/WB2vhUHrbRrknP9J3VUvw YG94/DU44xl3+ItRLuew== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RQ5E7ZAI2CpPdyOvg+v/5HpBKYJrkfSB0ifJRbn0tS0kHTXPNdbTCaWDylXkROwyvP Hnf2B0c1emfeoLxocChQ== MIME-Version: 1.0 Received: by 10.151.13.13 with SMTP id q13mr1803917ybi.291.1291309318487; Thu, 02 Dec 2010 09:01:58 -0800 (PST) Received: by 10.151.158.13 with HTTP; Thu, 2 Dec 2010 09:01:58 -0800 (PST) In-Reply-To: <4CF7CB8B.1030807@isi.edu> References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <4CF26596.7010500@isi.edu> <4CF7CB8B.1030807@isi.edu> Date: Thu, 2 Dec 2010 09:01:58 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: multipart/alternative; boundary=000e0cd6a9303944770496706139 X-System-Of-Record: true Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal 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, 02 Dec 2010 17:00:47 -0000 --000e0cd6a9303944770496706139 Content-Type: text/plain; charset=ISO-8859-1 Joe, you don't need to preach TCP 101 to someone who has worked on TCP for almost 20 years. Regardless, my being here is get some kind of larger IW proposal done. As long that can be achieved I am happy to acknowledge everything you said is gospel :) Best, Jerry On Thu, Dec 2, 2010 at 8:38 AM, Joe Touch wrote: > Jerry, > > > On 12/2/2010 3:59 AM, Jerry Chu wrote: > >> Joe, >> >> On Sun, Nov 28, 2010 at 6:22 AM, Joe Touch > > wrote: >> >> >> Jerry, >> >> In short: >> >> a) the receive window is an indication of the receiver's ability to >> reorder out-of-order packets; it limits what is sent primarily to >> avoid useless transmissions that the receiver will drop, not as a >> congestion control mechanism >> >> Wrong. The main purpose of the receive window is to flow control a >> sender so a faster sender >> won't overrun a slow receiver, period. >> > > The receive window is for reordering AND also allows large bandwidth-delay > products to have outstanding data during the round-trip delay until ACKs are > received. > > Neither of which has anything to do with the speed of the receiver per se. > A fast receiver on a low-RTT link doesn't need a large receive window. > > > yes, I find it odd that you are injecting control of the >> receive window to correct for IW issues in your draft >> >> >> What's wrong with that? Please give a specific badness of it? >> > > You are confusing flow control with congestion control. > > > It works > >> very effectively. In >> fact, I can't claim to be the inventor of this technique. It has been >> mentioned in plenty of >> RFCs. E.g., see RFC3150. >> > > That RFC makes the same error. The fact that you're using a hammer to drive > in a screw doesn't make it a nail. > 2) NO AMOUNT of in-connection adjustment of CWND has any effect on >> the impact of a poor choice of IW >> >> Yes it has. It limits the damage as Mark has pointed out. >> > > That's true ONLY for connections that last long enough to get that > feedback. The curious thing is that > a) such short connections is the reason you want to do this > b) yet you seem to continue to want to ignore it as a factor > > If anyone else on the list needs more info on these points, I'll be glad to > followup, but at this point further exchanges with you on these points don't > seem productive. > > Joe > --000e0cd6a9303944770496706139 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joe, you don't need to preach TCP 101 to someone who has worked on= TCP for almost
20=A0years.=A0Regardless, my being here is get so= me kind of larger IW proposal done. As
long that=A0can be=A0achie= ved I am happy to acknowledge everything you said is gospel :)

Best,

Jerry

On Thu, Dec 2, 2010 at 8:38 AM, Joe Touch <touch@isi.edu> wrote:
Jerry,


On 12/2/2010 3:59 AM, Jerry Chu wrote:
Joe,

On Sun, Nov 28, 2010 at 6:22 AM, Joe Touch <touch@isi.edu
<mailto:touch@isi.edu= >> wrote:


=A0 =A0Jerry,

=A0 =A0In short:

=A0 =A0a) the receive window is an indication of the receiver's abilit= y to
=A0 =A0reorder out-of-order packets; it limits what is sent primarily to =A0 =A0avoid useless transmissions that the receiver will drop, not as a =A0 =A0congestion control mechanism

Wrong. The main purpose of the receive window is to flow control a
sender so a faster sender
won't overrun a slow receiver, period.

The receive window is for reordering AND also allows large bandwidth-delay = products to have outstanding data during the round-trip delay until ACKs ar= e received.

Neither of which has anything to do with the speed of the receiver per se. = A fast receiver on a low-RTT link doesn't need a large receive window.<= div class=3D"im">

=A0 =A0 =A0 =A0 =A0 =A0yes, I find it odd that you are injecting control o= f the
=A0 =A0 =A0 =A0 =A0 =A0receive window to correct for IW issues in your dra= ft


What's wrong with that? Please give a specific badness of it?

You are confusing flow control with congestion control.=A0


> It works
very effectively. In
fact, I can't claim to be the inventor of this technique. It has been mentioned in plenty of
RFCs. E.g., see RFC3150.

That RFC makes the same error. The fact that you're using a hammer to d= rive in a screw doesn't make it a nail.=A0

=A0 =A02) NO AMOUNT of in-connection adjustment of CWND has any effect on<= br> =A0 =A0 =A0the impact of a poor choice of IW

Yes it has. It limits the damage as Mark has pointed out.

That's true ONLY for connections that last long enough to get that feed= back. The curious thing is that
=A0 =A0 =A0 =A0a) such short connections is the reason you want to do this=
=A0 =A0 =A0 =A0b) yet you seem to continue to want to ignore it as a facto= r

If anyone else on the list needs more info on these points, I'll be gla= d to followup, but at this point further exchanges with you on these points= don't seem productive.

Joe

--000e0cd6a9303944770496706139-- From mallman@icir.org Thu Dec 2 09:28: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 5FF4F28C1E3 for ; Thu, 2 Dec 2010 09:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.64 X-Spam-Level: X-Spam-Status: No, score=-105.64 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, PLING_QUERY=1.39, 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 vakxphrz1bcs for ; Thu, 2 Dec 2010 09:28:56 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 4898528C1D6 for ; Thu, 2 Dec 2010 09:28:56 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oB2HUBTr004178; Thu, 2 Dec 2010 09:30:12 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A764B2699F1D; Thu, 2 Dec 2010 12:30:11 -0500 (EST) To: Kacheong Poon From: Mark Allman In-Reply-To: <4CF7C9FC.10906@oracle.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: On the Cover of the Rolling Stone MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma55201-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 02 Dec 2010 12:30:11 -0500 Sender: mallman@icir.org Message-Id: <20101202173011.A764B2699F1D@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 17:28:57 -0000 ----------ma55201-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > o On Jul/1 set IW=3 [i.e., RFC5681]. Also, start two counters for > > each possible IW, 1--3: total number of connections using the > > given IW and number of connections using that IW that > > experienced loss in the initial window. > > Using this proposal, does it mean that a host randomly picks a > value from 1 to IW_cur as the IW every time it starts a new TCP > connection (assuming no cache hit)? No. It means that given that there is a natural variance in the amount of data that will be available for transmission in the initial cwnd we'll naturally end up with data at the different points. (And, maybe there is some small bit we have to do that says if we have total connections like this ... IW=1 3 IW=2 5 IW=3 20K IW=4 30K and things work fine at IW=3 and IW=4 then we can discount IW={1,2} because there isn't enough data there. But, you get the idea ... we're not turning the IW into a random variable. allman ----------ma55201-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz316MACgkQWyrrWs4yIs72GwCgmTcONmB2HfR9eNx+8gXkOICD gPEAnAkBRThrbeRlbXTFBlnS8d6x71Or =5XN2 -----END PGP SIGNATURE----- ----------ma55201-1-- From ka-cheong.poon@oracle.com Thu Dec 2 09:49: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 5CD4C3A69A0 for ; Thu, 2 Dec 2010 09:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.557 X-Spam-Level: X-Spam-Status: No, score=-5.557 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, PLING_QUERY=1.39, 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 UFqEnZfSXEhJ for ; Thu, 2 Dec 2010 09:49:24 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 33FAC3A699F for ; Thu, 2 Dec 2010 09:49:24 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oB2HocEg018901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Dec 2010 17:50:40 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oB26AR8P026521 for ; Thu, 2 Dec 2010 17:50:37 GMT Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 821600301291312214; Thu, 02 Dec 2010 09:50:14 -0800 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Dec 2010 09:50:14 -0800 Message-ID: <4CF7DC52.3030103@oracle.com> Date: Fri, 03 Dec 2010 01:50:10 +0800 From: Kacheong Poon Organization: Oracle Corporation User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: tcpm@ietf.org References: <20101202173011.A764B2699F1D@lawyers.icir.org> In-Reply-To: <20101202173011.A764B2699F1D@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) 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, 02 Dec 2010 17:49:25 -0000 On 12/ 3/10 01:30 AM, Mark Allman wrote: > No. It means that given that there is a natural variance in the amount > of data that will be available for transmission in the initial cwnd > we'll naturally end up with data at the different points. (And, maybe > there is some small bit we have to do that says if we have total > connections like this ... Then I suppose this proposal probably boils down to only checking IW_cur (the max) in most, if not all, hosts which increasing the IW matters. Otherwise, there is no reason to increase it in the first place. With Jerry's data, IW=10 is the correct number for Google since it affects ~5% (don't remember the exact number) of all connections. So maybe this WG can just tell folks to use whatever IW value your site sees fit. IETF only recommends IW=3 to be used if your site does not know anything better. You know what value of IW to use better than anyone else on this list. There is no single good way which fits all sites on how to determine the correct value of IW. So use whatever reasonable method which fits your site to decide on the value. -- K. Poon. ka-cheong.poon@oracle.com From hkchu@google.com Thu Dec 2 11:41: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 68DF03A6979 for ; Thu, 2 Dec 2010 11:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.067 X-Spam-Level: X-Spam-Status: No, score=-105.067 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, PLING_QUERY=1.39, 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 OxHxNA6cXsLO for ; Thu, 2 Dec 2010 11:41:51 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 103F93A69D5 for ; Thu, 2 Dec 2010 11:41:50 -0800 (PST) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id oB2Jh6LQ011264 for ; Thu, 2 Dec 2010 11:43:06 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291318986; bh=LShfo63VgVoIftBVJ3u23m9ePAI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=jh1DfaYqQB0fMPjE4ioiH+s8dwb1L6wkQOHtSevzS6ZxB4WEoV3vvoTvLE0AIw/qf bIoQTB12nQNxtmYMFyzoQ== Received: from gyg10 (gyg10.prod.google.com [10.243.50.138]) by hpaq3.eem.corp.google.com with ESMTP id oB2JgYjI023810 for ; Thu, 2 Dec 2010 11:43:05 -0800 Received: by gyg10 with SMTP id 10so18889822gyg.0 for ; Thu, 02 Dec 2010 11:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4VrRBPWj3CsYBWo2PSK901JIy8iK422+EiNCOLC3aZE=; b=RBK6tb53ywPdJDo3Ncy/Pu60nBfER9RDu2229eBeUgbaUx0fm93uQ88502YuHafkfV QWxMOhrUTILGKN+q0fYw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qtGXg/CkadMafeTWGoRo/TXJt8cDT3D+G8Bj+fO6/XAXUKACZLgdvirEXNXDH65Wcg I2ghjYngcMbmPT1YsFwA== MIME-Version: 1.0 Received: by 10.151.13.13 with SMTP id q13mr2070344ybi.291.1291318984038; Thu, 02 Dec 2010 11:43:04 -0800 (PST) Received: by 10.151.158.13 with HTTP; Thu, 2 Dec 2010 11:43:03 -0800 (PST) In-Reply-To: <4CF7DC52.3030103@oracle.com> References: <20101202173011.A764B2699F1D@lawyers.icir.org> <4CF7DC52.3030103@oracle.com> Date: Thu, 2 Dec 2010 11:43:03 -0800 Message-ID: From: Jerry Chu To: Kacheong Poon Content-Type: multipart/alternative; boundary=000e0cd6a93055daf0049672a123 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) 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, 02 Dec 2010 19:41:52 -0000 --000e0cd6a93055daf0049672a123 Content-Type: text/plain; charset=ISO-8859-1 Hey Kacheong, nice to hear from you! On Thu, Dec 2, 2010 at 9:50 AM, Kacheong Poon wrote: > On 12/ 3/10 01:30 AM, Mark Allman wrote: > > No. It means that given that there is a natural variance in the amount >> of data that will be available for transmission in the initial cwnd >> we'll naturally end up with data at the different points. (And, maybe >> there is some small bit we have to do that says if we have total >> connections like this ... >> > > > Then I suppose this proposal probably boils down to only > checking IW_cur (the max) in most, if not all, hosts which > increasing the IW matters. Otherwise, there is no reason > to increase it in the first place. With Jerry's data, IW=10 > is the correct number for Google since it affects ~5% (don't > remember the exact number) of all connections. > That's how I feel too. I.e., you'll need only two counters rather than IW*2 counters to track those connections that send the maxIW. In case it eventually goes up to e.g., IW16 but then problem starts showing up for IW15 due to, e.g., the rest of world switches to IW16, you'll probably see that in connections using IW16. Yes going back down a few steps (e.g., back to IW12) may take a while but the chance of that happening is small. Jerry > So maybe this WG can just tell folks to use whatever IW > value your site sees fit. IETF only recommends IW=3 to > be used if your site does not know anything better. You > know what value of IW to use better than anyone else on this > list. There is no single good way which fits all sites on > how to determine the correct value of IW. So use whatever > reasonable method which fits your site to decide on the value. > > > > > > -- > > K. Poon. > ka-cheong.poon@oracle.com > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000e0cd6a93055daf0049672a123 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Kacheong, nice to hear from you!

On T= hu, Dec 2, 2010 at 9:50 AM, Kacheong Poon <ka-cheong.poon@oracle.com> = wrote:
On 12/ 3/10 01:30 AM, Mar= k Allman wrote:

No. =A0It means that given that there is a natural variance in the amount of data that will be available for transmission in the initial cwnd
we'll naturally end up with data at the different points. =A0(And, mayb= e
there is some small bit we have to do that says if we have total
connections like this ...


Then I suppose this proposal probably boils down to only
checking IW_cur (the max) in most, if not all, hosts which
increasing the IW matters. =A0Otherwise, there is no reason
to increase it in the first place. =A0With Jerry's data, IW=3D10
is the correct number for Google since it affects ~5% (don't
remember the exact number) of all connections.

That's how I feel too. I.e., you'll need only two counters = rather
than IW*2 counters to track those connections that send th= e maxIW.
In case it eventually goes up to e.g., IW16 but then problem starts
showing up for IW15 due to, e.g., the rest of world switches to IW1= 6,
you'll probably see that in connections using IW16. Yes go= ing
back down a few steps (e.g., back to IW12) may take a while but the
chance of that happening is=A0small.

Jerry=


So maybe this WG can just tell folks to use whatever IW
value your site sees fit. =A0IETF only recommends IW=3D3 to
be used if your site does not know anything better. =A0You
know what value of IW to use better than anyone else on this
list. =A0There is no single good way which fits all sites on
how to determine the correct value of IW. =A0So use whatever
reasonable method which fits your site to decide on the value.





--

=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 =A0ka-ch= eong.poon@oracle.com
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--000e0cd6a93055daf0049672a123-- From dab@weston.borman.com Thu Dec 2 13:51: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 EC1703A6A00; Thu, 2 Dec 2010 13:51:32 -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 0jY6XIis+Oko; Thu, 2 Dec 2010 13:51:32 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id D01D73A69F5; Thu, 2 Dec 2010 13:51:31 -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 oB2LqlZM029388; Thu, 2 Dec 2010 13:52:47 -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); Thu, 2 Dec 2010 13:52:47 -0800 Received: from [172.25.34.36] ([172.25.34.36]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Dec 2010 13:52:47 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <4CF70D65.7030306@isi.edu> Date: Thu, 2 Dec 2010 15:52:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <78DB0ABC-24D1-41E1-BCC5-F70A950AD9C0@windriver.com> <2BFC5B36-F3B2-410B-845B-6F71B212EE8A@weston.borman.com> <4CF70D65.7030306@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 02 Dec 2010 21:52:47.0546 (UTC) FILETIME=[41EDF1A0:01CB926B] Cc: "tcpm@ietf.org Extensions" , TSV Dir Subject: Re: [tcpm] Side meeting to discuss TCP Security document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:51:33 -0000 Joe, On Dec 1, 2010, at 9:07 PM, Joe Touch wrote: > Dave, >=20 > I've asked repeatedly off-list, so I'll ask on-list. >=20 > Will there be a summary of the results of this meeting posted to the = list? See the meeting minutes: http://www.ietf.org/proceedings/79/minutes/tcpm.txt -David >=20 > Joe >=20 > On 11/9/2010 4:43 PM, David Borman wrote: >> We have Diamond 2 reserved from 1:00-3:00 today, Wednesday. Anyone = who is interested is welcome. >>=20 >> -David Borman, TCPM co-chair >>=20 >> On Nov 7, 2010, at 10:20 PM, David Borman wrote: >>=20 >>> In Anaheim we had a small session to look at the TCP Security = document, attended by a hand full of people. We are interested in doing = this again here in Beijing. The goal is to go through some more of the = document and come up with some recommendations for how to move forward = with revising/editing the document, which will then be brought back to = the list. >>>=20 >>> So, there are 2 questions: >>> 1) Who is interested in attending? >>> 2) When should we meet? My recommendations for possibilities are, = in order of preference: >>> 1) Tuesday morning (NFSv4 meets at this time) >>> 2) Wednesday after lunch (No TSV groups meet at this time) >>> 3) Thursday morning (Congestion Exposure WG meets at this time) >>> Please reply to me or the list if you are interested in this, and if = so, which of those 3 periods you are available. Once we see who is = interested and when they would be available, I'll see about finding a = place to meet, but it won't be a regular session room, i.e. there won't = be any remote participation. >>>=20 >>> -David Borman, TCPM co-chair >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Thu Dec 2 13:58: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 751733A6A0A; Thu, 2 Dec 2010 13:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, 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 OXBy95rYTJE1; Thu, 2 Dec 2010 13:58:13 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 4911528C150; Thu, 2 Dec 2010 13:58:13 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oB2Lx28o012121 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 2 Dec 2010 13:59:02 -0800 (PST) Message-ID: <4CF816A6.6070202@isi.edu> Date: Thu, 02 Dec 2010 13:59:02 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: David Borman References: <78DB0ABC-24D1-41E1-BCC5-F70A950AD9C0@windriver.com> <2BFC5B36-F3B2-410B-845B-6F71B212EE8A@weston.borman.com> <4CF70D65.7030306@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" , TSV Dir Subject: Re: [tcpm] Side meeting to discuss TCP Security document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 21:58:14 -0000 Hi, Dave, Thanks. I wouldn't have looked for it there, but glad to see the notes. What I have not seen yet is a discussion of a few key issues: 1) the numerous errors in the doc 2) the confusion between issues specification issues implementation issues operational issues 3) the large amount of this document that can be compressed to a single simple statement of general good programming practice, that is already implicit or explicit in most specifications: check values before you act on them If the doc would separate the issues, fix the errors, and omit the 'good programming platitudes', it might be useful. That won't happen, IMO, one section at a time. Joe On 12/2/2010 1:52 PM, David Borman wrote: > Joe, > > On Dec 1, 2010, at 9:07 PM, Joe Touch wrote: > >> Dave, >> >> I've asked repeatedly off-list, so I'll ask on-list. >> >> Will there be a summary of the results of this meeting posted to the list? > > See the meeting minutes: > http://www.ietf.org/proceedings/79/minutes/tcpm.txt > -David > >> >> Joe >> >> On 11/9/2010 4:43 PM, David Borman wrote: >>> We have Diamond 2 reserved from 1:00-3:00 today, Wednesday. Anyone who is interested is welcome. >>> >>> -David Borman, TCPM co-chair >>> >>> On Nov 7, 2010, at 10:20 PM, David Borman wrote: >>> >>>> In Anaheim we had a small session to look at the TCP Security document, attended by a hand full of people. We are interested in doing this again here in Beijing. The goal is to go through some more of the document and come up with some recommendations for how to move forward with revising/editing the document, which will then be brought back to the list. >>>> >>>> So, there are 2 questions: >>>> 1) Who is interested in attending? >>>> 2) When should we meet? My recommendations for possibilities are, in order of preference: >>>> 1) Tuesday morning (NFSv4 meets at this time) >>>> 2) Wednesday after lunch (No TSV groups meet at this time) >>>> 3) Thursday morning (Congestion Exposure WG meets at this time) >>>> Please reply to me or the list if you are interested in this, and if so, which of those 3 periods you are available. Once we see who is interested and when they would be available, I'll see about finding a place to meet, but it won't be a regular session room, i.e. there won't be any remote participation. >>>> >>>> -David Borman, TCPM co-chair >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From ayourtch@cisco.com Fri Dec 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 5680D3A69B8 for ; Fri, 3 Dec 2010 14:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.871, 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 IfHh0oCti+zD for ; Fri, 3 Dec 2010 14:57:44 -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 1ED223A659C for ; Fri, 3 Dec 2010 14:57:43 -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 oB3Mx12Z016678 for ; Fri, 3 Dec 2010 23:59:01 +0100 (CET) Received: from sweet-brew-7.cisco.com (sweet-brew-7.cisco.com [144.254.10.208]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oB3Mx1jj020054; Fri, 3 Dec 2010 23:59:01 +0100 (CET) Date: Fri, 3 Dec 2010 23:59:01 +0100 (CET) From: Andrew Yourtchenko To: tcpm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ananth@cisco.com Subject: [tcpm] A proposal for two-party adaptive initial congestion window 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, 03 Dec 2010 22:57:45 -0000 Hi all, we've submitted the (one more) proposal to look at in terms of gracefully increasing the initial congestion window - basically around the thread I had with Joe the other week. https://datatracker.ietf.org/doc/draft-yourtchenko-two-party-initial-window/ We think that it should take care both of the conservative part (avoiding the excessive loss on poorer links) and of the progressive part (use a larger IW where you can). We are thankful for your comments on this. thanks, andrew From muraris@microsoft.com Sat Dec 4 09:02: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 9647E3A6ABA for ; Sat, 4 Dec 2010 09:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdHQEUPFOhrD for ; Sat, 4 Dec 2010 09:02:20 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4D2CB3A6AB4 for ; Sat, 4 Dec 2010 09:02:20 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 4 Dec 2010 09:03:28 -0800 Received: from TK5EX14MBXC104.redmond.corp.microsoft.com ([169.254.1.35]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0255.003; Sat, 4 Dec 2010 09:03:27 -0800 From: Murari Sridharan To: "Anantha Ramaiah (ananth)" , Joe Touch , "Scheffenegger, Richard" Thread-Topic: [tcpm] dctcp Thread-Index: AcuBltbo7I+MgezEQZ2g0gAvp3gRgQBUTjsAACtPzoAAh6NokAOIOqOZ Date: Sat, 4 Dec 2010 17:03:26 +0000 Message-ID: References: <5FDC413D5FA246468C200652D63E627A0B65CA86@LDCMVEXC1-PRD.hq.netapp.com> <4CDD9E20.8030308@isi.edu> <0C53DCFB700D144284A584F54711EC580B2CD428@xmb-sjc-21c.amer.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm , Andrew McGregor Subject: Re: [tcpm] dctcp 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, 04 Dec 2010 17:02:21 -0000 Ok here is how i plan to proceed. I will submit DCTCP as an experimental c= ontroller but make it general enough that it isnt strictly tied to any one = congestion control (based on Wes' suggestion) to ICCRG. I will submit the I= PR disclosures that protect DCTCP as well. If it moves to TCPM and there is= interest towards a standards track then we can resubmit to TCP as a TCP ex= tension.=20 Thanks Murari=20 ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of Murari Sri= dharan [muraris@microsoft.com] Sent: Tuesday, November 16, 2010 9:39 AM To: Anantha Ramaiah (ananth); Joe Touch; Scheffenegger, Richard Cc: tcpm; Andrew McGregor Subject: Re: [tcpm] dctcp I agree. We believe that DCTCP has certain properties that are generally ap= plicable and personally I see DCTCP as an enabler for ECN even if in privat= e or enterprise networks as it makes the switch side configuration rather t= rivial. I also think the ideas in the paper have broad applicability which = is the reason why I wanted to present this to TCPM. Our goal has been to de= sign DCTCP such that without ECN marks it behaves exactly like New Reno or = whatever congestion control it is built on. In our case we built it as a mo= dification to New Reno, I therefore think it is very much in scope for disc= ussion. Whether it is in TCPM or ICCRG (treating DCTCP as an alternative co= ngestion control algorithm) is for the WG to decide. Remember if you are in a multi-tenant datacenter, algorithms like DCTCP are= most effective especially at the switches only if all the senders are conf= ormant to DCTCP, in that vein it is worth discussing at IETF. If the WG and the chairs agree I intend to submit an ID explaining the chan= ges. I propose two alternatives. One way to think of this is as a modificat= ion to the ECN RFC, to say that instead of halving in response to the *pres= ence* of congestion; react to the *extent* of congestion by averaging the E= CN marks which is what DCTCP does. Personally I believe this is a better ap= proach however the alternative option is to submit DCTCP as a new congestio= n control algorithm. Thoughts? Thanks Murari -----Original Message----- From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] Sent: Saturday, November 13, 2010 8:46 AM To: Joe Touch; Scheffenegger, Richard Cc: Murari Sridharan; tcpm; Andrew McGregor Subject: RE: [tcpm] dctcp Well, My thoughts here are :- - If someone is using a protocol defined by IETF, then it is desirable to a= bide by the standards, irrespective of the type of network. - interoperability across different devices (may be coming from different v= endors), using the same protocol, is one of the reason you need standards! - From an implementation perspective you don't want "private TCP" and "pub= lic TCP" in the same stack since the same stack needs to cater to TCP conne= ctions from *both* private and public networks! - The problems and the solutions which are posed by the data center environ= ments may not be unique. The question to ask is : "what is the problem and = whether the problems and solutions would have a generic applicability. - Also how do you draw a boundary as to a what is private network and what = isn't ? Why is data center environment considered a "private network" ? IMO, it is an issue that can be well addressed (if there is a need) by the = IETF, if changes are being planned with TCP protocol, yes TCPM is the righ= t place for such efforts. $0.02, -Anantha -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe= Touch Sent: Friday, November 12, 2010 12:06 PM To: Scheffenegger, Richard Cc: Murari Sridharan; tcpm; Andrew McGregor Subject: Re: [tcpm] dctcp On 11/11/2010 3:51 AM, Scheffenegger, Richard wrote: ... > Reading the TSVAREA material, it was also pointed out (storage teaser - > NFSv4, iSCSI) that TCPM may need to look closer at datacenter > environments rather soon. Tuning TCP for private networks (i.e., not using the Internet, or competing= with Internet flows) seems out of scope for TCPM. It might not even be relevant elsewhere in the IETF, except as an issue of = common interest. Protocols running over private networks don't need to adhe= re to standards. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm= From mallman@icir.org Mon Dec 6 19:23: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 669D028C0F5 for ; Mon, 6 Dec 2010 19:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.32 X-Spam-Level: X-Spam-Status: No, score=-106.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYYeGZaTcwQC for ; Mon, 6 Dec 2010 19:23:39 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 1215928C0F6 for ; Mon, 6 Dec 2010 19:23:29 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oB73OQMK016454; Mon, 6 Dec 2010 19:24:27 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BED2C2714F13; Mon, 6 Dec 2010 22:24:26 -0500 (EST) To: Andrew Yourtchenko From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Tom Sawyer MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma43242-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 06 Dec 2010 22:24:26 -0500 Sender: mallman@icir.org Message-Id: <20101207032426.BED2C2714F13@lawyers.icir.org> Cc: tcpm@ietf.org, ananth@cisco.com Subject: Re: [tcpm] A proposal for two-party adaptive initial congestion window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 03:23:41 -0000 ----------ma43242-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > https://datatracker.ietf.org/doc/draft-yourtchenko-two-party-initial-window/ I read through this. I think its overkill and likely doesn't solve any sort of real problem. It at least doesn't offer any argument that it does. The basic idea is that we take the sender IW adaption scheme that has been sketched on the list and augment it with receiver information. So, then, several things: - The basic premise of the sender adaption scheme is to setup a tolerance for problems caused by the IW burst. My sketch said 5%. I.e., an IW works if at least 95% of the IWs are sent without loss. (It could be 2% and still IW=10 would work according to the Google data. As a data point.) Given this, *at most* including receiver side information is only of assistance in a low percentage of the cases because that is the failure rate of the sender-side scheme. - The two party scheme supposes that the receiver has insight that would be helpful on picking an initial window. That may or may not be the case. We have no idea where the issues with larger IWs might crop up (sender, receiver or middle). But, given that the issues are not likely to all be at the receiver this further chops down the cases where this two-party adaption could possibly have any impact. - If the receiver knows a peer sending a larger initial burst is going to cause problems then that receiver can advertise a smaller window. It has a control that can be applied already. - Trying to tightly engineer the IW is pretty meaningless because even if you get the receiver to help the sender in choosing a proper value the sender is going to then double the cwnd and probably blow it in the next RTT if the path is really ratty. We need something *reasonable* as an initial setting, not optimal. - I don't find the simulations in the document to be particularly insightful. The efficacy of the mechanism is based on how often there are persistent problems that (a) will fall within the sender's tolerance for problems and (b) are at the receiver such that the receiver can alert the sender of the issues. To figure that out would require an empirical study not a series of simulations. And, a nit: - Your sketch of Quick Start is wrong. If the entire path does not approve of a given rate then the sender falls back to the standard IW and *does not* "use the full proposed bandwidth". FWIW. allman ----------ma43242-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz9qOoACgkQWyrrWs4yIs6HSwCbB2Xwc3LSfkwM3J31rp6lY2gE PZkAn003Qemt/bfVj2mklvMqpUDL96dF =bKV2 -----END PGP SIGNATURE----- ----------ma43242-1-- From mallman@icir.org Mon Dec 6 19:32:34 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 19E7B3A68F3 for ; Mon, 6 Dec 2010 19:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.329 X-Spam-Level: X-Spam-Status: No, score=-106.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA+N33yBkkhO for ; Mon, 6 Dec 2010 19:32:32 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 58B3D3A68F1 for ; Mon, 6 Dec 2010 19:32:32 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oB73Xu4V017739 for ; Mon, 6 Dec 2010 19:33:57 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 439642715136 for ; Mon, 6 Dec 2010 22:33:56 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Tom Sawyer MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma43812-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 06 Dec 2010 22:33:56 -0500 Sender: mallman@icir.org Message-Id: <20101207033356.439642715136@lawyers.icir.org> Subject: [tcpm] new version of 2988bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 03:32:34 -0000 ----------ma43812-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- We posted a new version of the 2988bis I-D today. It is: draft-paxson-tcpm-rfc2988bis-01.txt The big change is a new set of empirical results that pertain to dropping the initial RTO from 3sec to 1sec is now given (along with the previous results from Google) in the appendix. Generally speaking, these results show it is pretty safe to drop the initial RTO. Have a look. I believe the authors are pretty happy with this document at this point. allman ----------ma43812-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz9qyQACgkQWyrrWs4yIs6onwCeJBDYRMLjW6MvS2vigD34pWfm iHsAn2JdAQ/RsZTiSJXI/a6T5kXWfbp/ =A7Og -----END PGP SIGNATURE----- ----------ma43812-1-- From lars.eggert@nokia.com Tue Dec 7 00:27: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 6F4F73A6942 for ; Tue, 7 Dec 2010 00:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, 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 fjK7hngI69Nu for ; Tue, 7 Dec 2010 00:27:41 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 455573A6940 for ; Tue, 7 Dec 2010 00:27:41 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oB78SxfJ019369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2010 10:29:01 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-48--129275698; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Tue, 7 Dec 2010 10:28:56 +0200 Message-Id: <64021CF9-294A-434E-B56A-F272B0FC6009@nokia.com> References: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> <4CEBF5A1.3090601@isi.edu> <4CEC3411.1030300@isi.edu> <4CEC3CB5.5030205@isi.edu> To: Fernando Gont X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 07 Dec 2010 10:28:57 +0200 (EET) X-Nokia-AV: Clean Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-timestamps-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: Tue, 07 Dec 2010 08:27:42 -0000 --Apple-Mail-48--129275698 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The IETF last call completed with no further comments. I'll wait for the = revision that addresses the AD Review comments and then move the = document to IESG Review. Lars= --Apple-Mail-48--129275698 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIwNzA4Mjg1N1owIwYJKoZIhvcNAQkE MRYEFHNuiOzgaOphsIemqcNsGzRCIRWjMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB ADUjqy98nEyjJHIVTml7aLHOPfBOpdfY9VG4ThCEfk//r23BLiu1N2JleRaOnh055xEqFJCLk3rS /G05T3H5gfdIrI72Brf0waMrUYeHgcAxmoTEt9byxsp240lecG6uwtvo3nd88v/h3ZjQxzBuC7DV eMfLN1iyOjasrlIZJwwAAX47bZ0h4kAkSeaYL2aLiE1emk/VEqLhHpR5zR1ezdaiK8anj9o+5o2v dZ5xre5bX2+NEfpT5AMPkFSKA+7FNOpl2vSk5xwq7zieS36Kj8Fum9wJPrbzwZh8cBDIM8dBfXBM VJ5j5Cp8KHM4WC9+qo5qVhTEIe0JDIE5SiFeq7MAAAAAAAA= --Apple-Mail-48--129275698-- From fernando.gont.netbook.win@gmail.com Tue Dec 7 04:53: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 C74113A696B for ; Tue, 7 Dec 2010 04:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 OUxiPfqO0moR for ; Tue, 7 Dec 2010 04:53:05 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by core3.amsl.com (Postfix) with ESMTP id DBC4B3A6774 for ; Tue, 7 Dec 2010 04:53:04 -0800 (PST) Received: by yxd5 with SMTP id 5so1532532yxd.1 for ; Tue, 07 Dec 2010 04:54:30 -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=iFvKSShelxZD4WdHRA8YqkIfryxnuQwG2MqmlvLfQFQ=; b=eklIZMd3B5cligH+CU9OLPYsWpOtnnXJlBL5keisDcNmSEnbNCFoBGz/zxLlwF+wC+ S7QDIyFOgQ3OKERfKr8d9qEiV/OU06nQHLFncMAL4MYPX0jOBFpXCShcUnp6wJw6EByr IiNM7mohO2dZBz6xBXv337E+4v/6nX0nIxQLE= 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=v+B4l557dGkSFDtETREoXyc4cbgfgGn9IQbVpwKJoMV7mHnuz2ZBmcr6er7rv9P1s8 SaVNvkOBw599gYjCvKccy3AlvvkIidiIxWYT2jiCuqz/GzYa7cNjY2UPooZYbW9qUHc+ aK+gkFNp4wHDt8aHOkpfzucW8C8erSUZhI280= Received: by 10.151.48.6 with SMTP id a6mr1787028ybk.7.1291726470131; Tue, 07 Dec 2010 04:54:30 -0800 (PST) Received: from [192.168.1.110] (92-172-17-190.fibertel.com.ar [190.17.172.92]) by mx.google.com with ESMTPS id f46sm3835140yhc.33.2010.12.07.04.54.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Dec 2010 04:54:29 -0800 (PST) Sender: Fernando Gont Message-ID: <4CFE2E5F.4090609@gont.com.ar> Date: Tue, 07 Dec 2010 09:53:51 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Lars Eggert References: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> <4CEBF5A1.3090601@isi.edu> <4CEC3411.1030300@isi.edu> <4CEC3CB5.5030205@isi.edu> <64021CF9-294A-434E-B56A-F272B0FC6009@nokia.com> In-Reply-To: <64021CF9-294A-434E-B56A-F272B0FC6009@nokia.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-timestamps-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: Tue, 07 Dec 2010 12:53:05 -0000 Hi, Lars, I've just posted a revision of the aforementioned I-D, that addresses your AD Review comments. Thanks! Kind regards, Fernando On 07/12/2010 05:28 a.m., Lars Eggert wrote: > The IETF last call completed with no further comments. I'll wait for > the revision that addresses the AD Review comments and then move the > document to IESG Review. > > Lars > > > > _______________________________________________ tcpm mailing list > tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From Internet-Drafts@ietf.org Tue Dec 7 05:00: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 608AA3A6958; Tue, 7 Dec 2010 05:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 vJU8R9wAad9v; Tue, 7 Dec 2010 05:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84B13A6765; Tue, 7 Dec 2010 05:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101207130001.9339.6284.idtracker@localhost> Date: Tue, 07 Dec 2010 05:00:01 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-timestamps-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: Tue, 07 Dec 2010 13: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 : Reducing the TIME-WAIT state using TCP timestamps Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-timestamps-02.txt Pages : 11 Date : 2010-12-07 This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-timestamps-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-timestamps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-07045232.I-D@ietf.org> --NextPart-- From alexander.zimmermann@comsys.rwth-aachen.de Wed Dec 8 00: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 0C5333A6875 for ; Wed, 8 Dec 2010 00:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.741 X-Spam-Level: X-Spam-Status: No, score=-4.741 tagged_above=-999 required=5 tests=[AWL=0.060, 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 CVCV5kaPrCiI for ; Wed, 8 Dec 2010 00:00:43 -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 BD8173A67AB for ; Wed, 8 Dec 2010 00:00:43 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LD3005LYNNL5DB0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 08 Dec 2010 09:02:09 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.59,315,1288566000"; d="sig'?scan'208";a="84466092" 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, 08 Dec 2010 09:02:09 +0100 Received: from [137.226.12.58] ([unknown] [137.226.12.58]) 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 <0LD300MW0NNLA640@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 08 Dec 2010 09:02:09 +0100 (CET) From: Alexander Zimmermann Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-16--44480378 Content-transfer-encoding: 7bit Date: Wed, 08 Dec 2010 09:02:12 +0100 Message-id: <1E4A5D7E-70D0-4F4E-8479-4030C9887769@comsys.rwth-aachen.de> To: tcpm WG , Jerry Chu , " Allman" , Joe Touch , "lars.eggert@nokia.com Eggert" , "Wesley (GRC-MS00)[ASRC AEROSPACE CORP] Eddy M." , Ilpo J?rvinen X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Subject: [tcpm] Linux* opinion about IW=10 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, 08 Dec 2010 08:00:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-16--44480378 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii http://vger.kernel.org/~davem/davem_ibm2010.pdf See in particular slide 12 *David Miller's? // // 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-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-16--44480378 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz/O4QACgkQdyiq39b9uS7rGgCg6vvkStSNTVR4S8Pe+LjapvfZ KnYAn3MAT0328IrJBTBmUpfrCs7ZBEce =uP67 -----END PGP SIGNATURE----- --Apple-Mail-16--44480378-- From touch@isi.edu Wed Dec 8 04:57:01 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4323A692A for ; Wed, 8 Dec 2010 04:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehEYvFBacGRs for ; Wed, 8 Dec 2010 04:57:00 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1B1EF3A693B for ; Wed, 8 Dec 2010 04:57:00 -0800 (PST) Received: from [10.2.237.194] ([12.154.31.2]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oB8CvX7d026943 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 8 Dec 2010 04:57:43 -0800 (PST) Message-ID: <4CFF80B3.4050700@isi.edu> Date: Wed, 08 Dec 2010 04:57:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alexander Zimmermann References: <1E4A5D7E-70D0-4F4E-8479-4030C9887769@comsys.rwth-aachen.de> In-Reply-To: <1E4A5D7E-70D0-4F4E-8479-4030C9887769@comsys.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm WG , " Allman" Subject: Re: [tcpm] Linux* opinion about IW=10 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, 08 Dec 2010 12:57:01 -0000 Linux ignores IETF standards. We already know that. Joe On 12/8/2010 12:02 AM, Alexander Zimmermann wrote: > http://vger.kernel.org/~davem/davem_ibm2010.pdf > > See in particular slide 12 > > > *David Miller's? > > // > // 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-22222 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > From ilpo.jarvinen@helsinki.fi Wed Dec 8 06:09: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 B1F6C3A6948 for ; Wed, 8 Dec 2010 06:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 TnwxS1FOGwQl for ; Wed, 8 Dec 2010 06:09:21 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id C82163A6907 for ; Wed, 8 Dec 2010 06:09:19 -0800 (PST) Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 08 Dec 2010 16:10:45 +0200 id 00093E63.4CFF91E5.00003A4D Date: Wed, 8 Dec 2010 16:10:45 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi To: Joe Touch In-Reply-To: <4CFF80B3.4050700@isi.edu> Message-ID: References: <1E4A5D7E-70D0-4F4E-8479-4030C9887769@comsys.rwth-aachen.de> <4CFF80B3.4050700@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm WG , " Allman" Subject: Re: [tcpm] Linux* opinion about IW=10 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, 08 Dec 2010 14:09:22 -0000 On Wed, 8 Dec 2010, Joe Touch wrote: > Linux ignores IETF standards. Perhaps you're right on "standards" (literal), however in this particular matter it's quite the opposite what one could pick up from those slides alone, see eg. (which is relatively recent one): http://kerneltrap.org/mailarchive/linux-kernel/2010/7/14/4594120 I suspect that only once the discussion in IETF turned into "I've this and this (hypotetical) case which is something that will certainly not work with the larger IW", not some core Linux net devs are that interested anymore. -- i. > On 12/8/2010 12:02 AM, Alexander Zimmermann wrote: > > http://vger.kernel.org/~davem/davem_ibm2010.pdf > > > > See in particular slide 12 > > > > > > *David Miller's? From lars.eggert@nokia.com Fri Dec 10 02:04: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 85C5A3A6C9B; Fri, 10 Dec 2010 02:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.624 X-Spam-Level: X-Spam-Status: No, score=-103.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, GB_I_LETTER=-2, 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 crgIBPKYpHnu; Fri, 10 Dec 2010 02:04:31 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 67C9E3A6C99; Fri, 10 Dec 2010 02:04:31 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBAA5rjc005429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Dec 2010 12:05:54 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-132-135738128; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <201012100923.oBA9NZPm091282@givry.fdupont.fr> Date: Fri, 10 Dec 2010 12:05:50 +0200 Message-Id: <91DF5801-03D2-42B2-BA3E-5EFD7D01A2F4@nokia.com> References: <201012100923.oBA9NZPm091282@givry.fdupont.fr> To: Francis Dupont X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Fri, 10 Dec 2010 12:05:50 +0200 (EET) X-Nokia-AV: Clean Cc: draft-ietf-tcpm-tcp-timestamps.all@tools.ietf.org, General Area Review Team , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [Gen-art] review of draft-ietf-tcpm-tcp-timestamps-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, 10 Dec 2010 10:04:32 -0000 --Apple-Mail-132-135738128 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, thanks for the review. Fernando, please see if you want to address any = of these in your working copy. (But don't post a new revision until = after the document has been discussed by the IESG.) Thanks, Lars On 2010-12-10, at 11:23, Francis Dupont wrote: > (note: I was a bit late to send the review so I updated it to the new > version which was published between review time and today) >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at < > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >=20 > Please resolve these comments along with any other Last Call comments = you > may receive. >=20 > Document: draft-ietf-tcpm-tcp-timestamps-02.txt > Reviewer: Francis Dupont > Review Date: 2010-12-06 / 2010-12-10 > IETF LC End Date: 2010-12-07 > IESG Telechat date: unknown >=20 > Summary: Ready with Nits >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: > - ToC page 2 and 7 page 8: Acknowledgements -> Acknowledgments > (BTW the american for "honour" is "honor" too, ask the RFC Editor > to change honour spelling if he wants) >=20 > - 1 page 3: in > "The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP > to include a timestamp value in its segments, that can be used to" >=20 > perhaps there is a missing word (like "speaker") after "TCP"? >=20 > - 2 pages 4 and 5: I don't understand where the difference between > these two texts comes from: >=20 > "the Sequence Number of the incoming SYN segment > is larger than the last sequence number seen on the previous > incarnation of the connection (for that direction of the data > transfer), then honour the connection request (creating a > connection in the SYN-RECEIVED state)." > "the Sequence Number of the incoming SYN > segment is larger than the last sequence number seen on the > previous incarnation of the connection (for the same direction > of the data transfer), then honour the incoming connection > request (even if the sequence number of the incoming SYN > segment falls within the receive window of the previous > incarnation of the connection)." >=20 > i.e., I can easily tell whether the small variations between similar > specifications are just to make reading less boring or are about > real differences. >=20 > - 2 page 6: KB/s -> kbytes/s or kilobytes/s (at least K (Kelvin) -> > k (kilo) and B -> bytes in letters) >=20 > - 4 page 7: I guess it is a typo: >=20 > "[CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme > which results in monotonically-increasing timestamps across > ^^^^^^^^^^ ISNs > connections that are not easily-predictable by an off-path attacker." >=20 > - 8.2 page 9 [INFOCOM-99] and [Silbersack]]: ' .' -> '.' >=20 > Thanks >=20 > Francis.Dupont@fdupont.fr > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail-132-135738128 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIxMDEwMDU1MVowIwYJKoZIhvcNAQkE MRYEFAvIPkS/BdAx7+j21Xwtcuszrs+SMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB ACTzfUGaCGSFHjVlYg/XWn1K2PkSCoLTypve4GVKhx8wa6wOy/ZKvvasU2GhSmJ4EUtspuAXxROk J1a1pTls14MelqVBUsxEbT+4n6AkuS5ypWPXW4OrckQqFyj1JsVJex2KBhDLdnGgxwfyR7gEMdxT vHMzEhlog5n07yGxj2GUjgs4tL0sJHbInoHn+H3+XoMFhuQC8fIM1IP2Bv6z3AGUU0ckFFFUtV7r bUrNTk7wOlRZ9yqfSj8VqFBZwlOgNRBbPydcr9N8lFr9md9D23xyoXtaPpVXkmuZ6LHECLt0/6+N zFebqprV+a0r0UvJNru5Q+gdmyQzeVButQPzZOUAAAAAAAA= --Apple-Mail-132-135738128-- From fernando.gont.netbook.win@gmail.com Fri Dec 10 09:10: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 BF70928C0D9; Fri, 10 Dec 2010 09:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 V6DlGl1PIOPZ; Fri, 10 Dec 2010 09:10:44 -0800 (PST) Received: from mail-bw0-f66.google.com (mail-bw0-f66.google.com [209.85.214.66]) by core3.amsl.com (Postfix) with ESMTP id DE3E83A6CB6; Fri, 10 Dec 2010 09:10:43 -0800 (PST) Received: by bwz7 with SMTP id 7so1664012bwz.1 for ; Fri, 10 Dec 2010 09:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=g/zW24TnIo8vbVgNTyZ3xstD7p8JPdEyxZROYCiuekY=; b=Qco5jC40vGOZVz1t+S/dpulrE/iwU0EiFa+40qUr9N10gvWRjNroft3zvbZe8aQaHd et/EdEFiz/YklyUyi7qiwgCD8Z/kfIX+ZAOZNh86jqM9JY90wX/gJ0t19opM0AENt8D/ XXM5A1FLsxho6kY81teeKxXh4xNexQ1nzkiTE= 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=mOgM+cqHEHOkL4GsR3LyWV7L0S+mR4y8rQ8vy3kj9KuWn+SGuURm0w6HxAAIZTh4/C RhV8DaMdylrOj+ghiElsdw3HafaxiCtH5O4aD2d3pxdb3nwWIJ9bEq6meC4d+Z+sE+Mm qTOTJn77x6vBh2t1oKECZuexDAsD57aopD6Lk= MIME-Version: 1.0 Received: by 10.204.56.14 with SMTP id w14mr1046603bkg.27.1292001134850; Fri, 10 Dec 2010 09:12:14 -0800 (PST) Sender: fernando.gont.netbook.win@gmail.com Received: by 10.204.72.3 with HTTP; Fri, 10 Dec 2010 09:12:14 -0800 (PST) In-Reply-To: <91DF5801-03D2-42B2-BA3E-5EFD7D01A2F4@nokia.com> References: <201012100923.oBA9NZPm091282@givry.fdupont.fr> <91DF5801-03D2-42B2-BA3E-5EFD7D01A2F4@nokia.com> Date: Fri, 10 Dec 2010 14:12:14 -0300 X-Google-Sender-Auth: qfl9ULVTCsmv8qmJjlEhvmkgt18 Message-ID: From: Fernando Gont To: Lars Eggert Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-tcpm-tcp-timestamps.all@tools.ietf.org, "tcpm@ietf.org Extensions" , General Area Review Team , Francis Dupont Subject: Re: [tcpm] [Gen-art] review of draft-ietf-tcpm-tcp-timestamps-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, 10 Dec 2010 17:10:45 -0000 Hi, Lars, I will respond to Francis' comments this weekend and address his comments shortly. Thanks! Kind regards, Fernando On 12/10/10, Lars Eggert wrote: > Hi, > > thanks for the review. Fernando, please see if you want to address any of > these in your working copy. (But don't post a new revision until after the > document has been discussed by the IESG.) > > Thanks, > Lars > > On 2010-12-10, at 11:23, Francis Dupont wrote: > >> (note: I was a bit late to send the review so I updated it to the new >> version which was published between review time and today) >> >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at < >> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Please resolve these comments along with any other Last Call comments you >> may receive. >> >> Document: draft-ietf-tcpm-tcp-timestamps-02.txt >> Reviewer: Francis Dupont >> Review Date: 2010-12-06 / 2010-12-10 >> IETF LC End Date: 2010-12-07 >> IESG Telechat date: unknown >> >> Summary: Ready with Nits >> >> Major issues: None >> >> Minor issues: None >> >> Nits/editorial comments: >> - ToC page 2 and 7 page 8: Acknowledgements -> Acknowledgments >> (BTW the american for "honour" is "honor" too, ask the RFC Editor >> to change honour spelling if he wants) >> >> - 1 page 3: in >> "The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP >> to include a timestamp value in its segments, that can be used to" >> >> perhaps there is a missing word (like "speaker") after "TCP"? >> >> - 2 pages 4 and 5: I don't understand where the difference between >> these two texts comes from: >> >> "the Sequence Number of the incoming SYN segment >> is larger than the last sequence number seen on the previous >> incarnation of the connection (for that direction of the data >> transfer), then honour the connection request (creating a >> connection in the SYN-RECEIVED state)." >> "the Sequence Number of the incoming SYN >> segment is larger than the last sequence number seen on the >> previous incarnation of the connection (for the same direction >> of the data transfer), then honour the incoming connection >> request (even if the sequence number of the incoming SYN >> segment falls within the receive window of the previous >> incarnation of the connection)." >> >> i.e., I can easily tell whether the small variations between similar >> specifications are just to make reading less boring or are about >> real differences. >> >> - 2 page 6: KB/s -> kbytes/s or kilobytes/s (at least K (Kelvin) -> >> k (kilo) and B -> bytes in letters) >> >> - 4 page 7: I guess it is a typo: >> >> "[CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme >> which results in monotonically-increasing timestamps across >> ^^^^^^^^^^ ISNs >> connections that are not easily-predictable by an off-path attacker." >> >> - 8.2 page 9 [INFOCOM-99] and [Silbersack]]: ' .' -> '.' >> >> Thanks >> >> Francis.Dupont@fdupont.fr >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art > > -- 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@rfc-editor.org Mon Dec 13 12:31: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 189BA28C15E; Mon, 13 Dec 2010 12:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, NO_RELAYS=-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 sPvbcTWsp6oE; Mon, 13 Dec 2010 12:31:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 2D5AB28C15D; Mon, 13 Dec 2010 12:31:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 04163130003; Mon, 13 Dec 2010 12:32:49 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101213203250.04163130003@rfc-editor.org> Date: Mon, 13 Dec 2010 12:32:49 -0800 (PST) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 6069 on Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) 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, 13 Dec 2010 20:31:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6069 Title: Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) Author: A. Zimmermann, A. Hannemann Status: Experimental Stream: IETF Date: December 2010 Mailbox: zimmermann@cs.rwth-aachen.de, hannemann@nets.rwth-aachen.de Pages: 23 Characters: 59600 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-tcp-lcd-03.txt URL: http://www.rfc-editor.org/rfc/rfc6069.txt Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission. This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions. This document defines an Experimental Protocol for the Internet community. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From alexander.zimmermann@comsys.rwth-aachen.de Wed Dec 15 01:42: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 7DA0C28C131 for ; Wed, 15 Dec 2010 01:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_05=-1.11, 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 njNb8uM0kUuo for ; Wed, 15 Dec 2010 01:42:03 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 369B93A7010 for ; Wed, 15 Dec 2010 01:42:02 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LDG00CTCR0VG560@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 15 Dec 2010 10:43:43 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.59,347,1288566000"; d="sig'?scan'208";a="85411297" 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, 15 Dec 2010 10:43:44 +0100 Received: from [137.226.12.58] ([unknown] [137.226.12.58]) 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 <0LDG00B9PR0VUL20@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 15 Dec 2010 10:43:43 +0100 (CET) From: Alexander Zimmermann Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-8-566409714 Content-transfer-encoding: 7bit Date: Wed, 15 Dec 2010 10:43:42 +0100 Message-id: To: tcpm WG X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Subject: [tcpm] OT: Allegations regarding OpenBSD IPSEC 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, 15 Dec 2010 09:42:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-8-566409714 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii http://permalink.gmane.org/gmane.os.openbsd.tech/22557 // // 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-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-8-566409714 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk0Ijc4ACgkQdyiq39b9uS74gACfXWCC15RkjbyVV8zXdL1WobX5 C4AAoJC/GjOXVyysaLiiTFw2QKUEWMCl =yBjm -----END PGP SIGNATURE----- --Apple-Mail-8-566409714-- From Internet-Drafts@ietf.org Sun Dec 19 22:45:34 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 5E2083A69FD; Sun, 19 Dec 2010 22:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, 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 sLZB7TY-VQbG; Sun, 19 Dec 2010 22:45:27 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B57E3A69FA; Sun, 19 Dec 2010 22:45:27 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101220064522.11218.61811.idtracker@localhost> Date: Sun, 19 Dec 2010 22:45:22 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-timestamps-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: Mon, 20 Dec 2010 06:45:34 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Reducing the TIME-WAIT state using TCP timestamps Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-timestamps-03.txt Pages : 11 Date : 2010-12-19 This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-timestamps-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-tcp-timestamps-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-19223135.I-D@ietf.org> --NextPart-- From per.hurtig@gmail.com Wed Dec 22 01: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 620023A69CB for ; Wed, 22 Dec 2010 01:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 AadOvd8KzSxc for ; Wed, 22 Dec 2010 01:14:14 -0800 (PST) Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by core3.amsl.com (Postfix) with ESMTP id 3D9873A69AF for ; Wed, 22 Dec 2010 01:14:14 -0800 (PST) Received: by fxm18 with SMTP id 18so4935368fxm.16 for ; Wed, 22 Dec 2010 01:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Gv80eDR08HGGROdMiz9uhBOIs+X0kTnJnXbfwDGbWx4=; b=u+zfDXg/QtpIhJq+648mrHTCdbKSWbTIKDeIjJgmCDbMSE8jDUkVKEoGqVE3y+0Bha Rn4FY9nGE2RzOlNzs6t6MNEfdT70UiYyuVgkMWnCMe0l7jhzZDA9NMppbEaPwfGF14Wk kcyReYOHNAjfp5A3+bOCuo4nAI4ojJWWbTWoo= 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 :content-transfer-encoding; b=gGsRatsnhyY5r1IlsaAOyxmTgOSljZkTL5nGmcPMMZ8ne/g9RDDeOgmV0v3LcS1MzC odbw5iolcqt7Ai5vNgAlGOkgGyzUCZgpKMWHGHPJPRu1jR3G2JYip5rnETMTxbc5tJCu 3FFqk5bFQEjzRKcWfXSvkmh3A/FPLC0oycB78= MIME-Version: 1.0 Received: by 10.223.85.204 with SMTP id p12mr6956904fal.146.1293009369217; Wed, 22 Dec 2010 01:16:09 -0800 (PST) Sender: per.hurtig@gmail.com Received: by 10.223.102.70 with HTTP; Wed, 22 Dec 2010 01:16:09 -0800 (PST) In-Reply-To: <20101207033356.439642715136@lawyers.icir.org> References: <20101207033356.439642715136@lawyers.icir.org> Date: Wed, 22 Dec 2010 10:16:09 +0100 X-Google-Sender-Auth: a1dAWMEr4zXSKdIkDIxZ-3Wdax8 Message-ID: From: "Per Hurtig (work)" To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mallman@icir.org Subject: Re: [tcpm] new version of 2988bis 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, 22 Dec 2010 09:16:26 -0000 Hi all, we have submitted an I-D that summarizes an alternate way to restart the TCP/SCTP RTO timer: http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt The difference between this approach and RFC2988(bis)'s approach is the way outstanding segments are considered. We're happy to receive any comments on the draft. Regards, Per H On Tue, Dec 7, 2010 at 04:33, Mark Allman wrote: > > Folks- > > We posted a new version of the 2988bis I-D today. =A0It is: > > =A0draft-paxson-tcpm-rfc2988bis-01.txt > > The big change is a new set of empirical results that pertain to > dropping the initial RTO from 3sec to 1sec is now given (along with the > previous results from Google) in the appendix. =A0Generally speaking, > these results show it is pretty safe to drop the initial RTO. > > Have a look. =A0I believe the authors are pretty happy with this document > at this point. > > allman > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From rs@netapp.com Wed Dec 22 03:39: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 222743A6AD9 for ; Wed, 22 Dec 2010 03:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.284 X-Spam-Level: X-Spam-Status: No, score=-10.284 tagged_above=-999 required=5 tests=[AWL=0.315, 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 psoO-UwOtOJj for ; Wed, 22 Dec 2010 03:39:14 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id D311C3A6846 for ; Wed, 22 Dec 2010 03:39:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,212,1291622400"; d="scan'208";a="227756109" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 22 Dec 2010 03:41:10 -0800 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oBMBfArO012249; Wed, 22 Dec 2010 03:41:10 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Dec 2010 12:41:09 +0100 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, 22 Dec 2010 11:41:03 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0C0A2FD4@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] new version of 2988bis Thread-Index: AcuhuTjSTmoCrh2MRJmPQYbjcBwTzwAEsknw References: <20101207033356.439642715136@lawyers.icir.org> From: "Scheffenegger, Richard" To: "Per Hurtig (work)" , X-OriginalArrivalTime: 22 Dec 2010 11:41:09.0995 (UTC) FILETIME=[20BF0BB0:01CBA1CD] Cc: mallman@icir.org Subject: Re: [tcpm] new version of 2988bis 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, 22 Dec 2010 11:39:15 -0000 Hmm... How do you deal with multiple lost segments in the same window? Your = draft says 2. Proposed Modifications The document proposes an update of step 5.3 in Section 5 of [RFC2988] to (and a similar update of step R3 in section 6.3.2 of [RFC4960]): When an ACK is received that acknowledges new data, restart the retransmission timer so that it will expire RTO seconds after the earliest outstanding segment was transmitted (for the current value of RTO). The update requires TCP implementations to track the time elapsed since sending the last unacknowledged segment. In practice, this could be achieved by adding one variable to the transmission control block. But wouldn't you really need to track the sending time of *each* = segment, to always be able to calculate the true T_earliest? I can not = see how a singular, global TCPCB variable addresses this - perhaps I'm = missing something? Wouldn't there be an opportunity to use this feature synergistically = with RFC1323 Timestamps also? (The ACK with new data should reflect the = sender's TCP clock (or a well derived value thereof) at the time the = segment was sent. Perhaps that information can help reducing additional = per-segment state in the sender?) Best regards, Richard Scheffenegger > -----Original Message----- > From: Per Hurtig (work) [mailto:per.hurtig@kau.se] > Sent: Mittwoch, 22. Dezember 2010 10:16 > To: tcpm@ietf.org > Cc: mallman@icir.org > Subject: Re: [tcpm] new version of 2988bis >=20 > Hi all, >=20 > we have submitted an I-D that summarizes an alternate way to restart > the TCP/SCTP RTO timer: >=20 > http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt >=20 > The difference between this approach and RFC2988(bis)'s approach is > the way outstanding segments are > considered. We're happy to receive any comments on the draft. >=20 >=20 > Regards, Per H >=20 >=20 >=20 >=20 > On Tue, Dec 7, 2010 at 04:33, Mark Allman wrote: > > > > Folks- > > > > We posted a new version of the 2988bis I-D today. =A0It is: > > > > =A0draft-paxson-tcpm-rfc2988bis-01.txt > > > > The big change is a new set of empirical results that pertain to > > dropping the initial RTO from 3sec to 1sec is now given (along with > the > > previous results from Google) in the appendix. =A0Generally = speaking, > > these results show it is pretty safe to drop the initial RTO. > > > > Have a look. =A0I believe the authors are pretty happy with this > document > > at this point. > > > > allman > > > > > > > > > > > > _______________________________________________ > > 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 Dec 23 15:36: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 364243A68BA for ; Thu, 23 Dec 2010 15:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, 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 fNF4sTNVSfIf for ; Thu, 23 Dec 2010 15:36:28 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7BB9C3A68BD for ; Thu, 23 Dec 2010 15:36:28 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oBNNcAK5004305 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 23 Dec 2010 15:38:10 -0800 (PST) Message-ID: <4D13DD62.3080103@isi.edu> Date: Thu, 23 Dec 2010 15:38:10 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] Automatic IW draft 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: Thu, 23 Dec 2010 23:36:29 -0000 Hi, all, A preliminary draft has been posted: http://www.ietf.org/id/draft-touch-tcpm-automatic-iw-00.txt It includes the algorithm and a lot of other details, some fleshed out (the intro), others as a list. The goal is to use this as a basis of initial discussion. (I have not determined the author list yet, so it says TBD right now...) Joe From hkchu@google.com Sun Dec 26 12:55: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 9E7CB3A67EB for ; Sun, 26 Dec 2010 12:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.723 X-Spam-Level: X-Spam-Status: No, score=-105.723 tagged_above=-999 required=5 tests=[AWL=0.254, 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 Dn0R91XT5iE6 for ; Sun, 26 Dec 2010 12:55: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 DC1713A67E9 for ; Sun, 26 Dec 2010 12:55:11 -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 oBQKvFrn013225 for ; Sun, 26 Dec 2010 12:57:15 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293397036; bh=nNSNrjRxZ5N5ewgfGqrHz3QvtA4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=T26Ds49PzJfgoWLn54UKG99JB/KsVEznr5IoIP/ONiw551dCM+HJRNoXB51NhTFZo repqrWZnmxRYV5rGTZcBQ== Received: from gyg4 (gyg4.prod.google.com [10.243.50.132]) by kpbe19.cbf.corp.google.com with ESMTP id oBQKvBWc014701 for ; Sun, 26 Dec 2010 12:57:11 -0800 Received: by gyg4 with SMTP id 4so3353845gyg.8 for ; Sun, 26 Dec 2010 12:57:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OJUbEbJuhcsN+UPjT+1IhqcwftkcjP87fwcfrSFx5UY=; b=fhQfV/em6fTOQbmeDmSuIKqGzYRYWUnQUhPPxVWxVn7OP6KOqrD5NQUD3X5hreAYFz 60prn8wuMRNYx4hlzLcQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=t7iP6KPs/qAbfWp19mF/Nz1tj0+refos/nvI6g8J9UHuCvs3g5yCRgnuQY3/UEUkrv 8mGfxhuhIVfri683Hjng== MIME-Version: 1.0 Received: by 10.150.217.6 with SMTP id p6mr16090781ybg.63.1293397029649; Sun, 26 Dec 2010 12:57:09 -0800 (PST) Received: by 10.151.26.9 with HTTP; Sun, 26 Dec 2010 12:57:09 -0800 (PST) In-Reply-To: <4D13DD62.3080103@isi.edu> References: <4D13DD62.3080103@isi.edu> Date: Sun, 26 Dec 2010 12:57:09 -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" Subject: Re: [tcpm] Automatic IW draft 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: Sun, 26 Dec 2010 20:55:14 -0000 Hi Joe, Thanks for the writeup. Your proposal seems like a good step toward finding a permanent solution to the IW problem. The following are my comments: 1. The long check period (e.g., one month) is necessary to allow enough samples to avoid false negative/postives and ensure stability/convergence. But many hosts today won't survive that long period without a reboot, hence losing all the IW/counter statistics and have to start over again. This includes not only most of the client devices but many servers as well. What this implies is basically the algorithm will never (or rarely) have enough time to move IW, either up or down. Even it did, upon the next reboot the latest IW is lost. Does it start from scatch then? 2. To fix the above problem requires either some local persitent storage or some external (e.g., through the network) storage to save counters more frequently. This is certainly doable, but will introduce a lot of complexity, basically ruining the simplicity of the algorithm you proposed. For some hosts the above may not even be feasible. 3. The proposed check "if (IWnotchecked && ((ISN - seqno)/MSS < IW))) {" under "3. During a retransmission,...", although simple (hence meeting the KISS requirement), counts against IW even though the initial burst may be smaller than IW. OTOH, tracking the actual burst sizes more accurately and counting them against 3..IW buckets as Mark Allman described earlier adde more complexity. Is it really necessary? For a web server the size distribution of the HTTP responses drops off quickly after certain threshold. Assuming we decide our loss tolerant level is 5%. When the IW is bumped to certain leve, e.g., 20, there may be less than 5% of HTTP responses that are greater than 20*1460 = 30KB. Assuming IW <= 20 is all good but IW > 20 is all badness, lumping all the counters together under a single IW may never fail the 95% check, hence allowing IW to grow unbounded even though those connections with response sizes greater than 16 always suffer. One may argue the small percentage of connections sort of justifying fudging it out. But if one judges from the volume (of just the initial bursts) it may not be insignificant. A good compromise may be to track only connections with burst sizes = IW, or >= IW minus some threshold, relying on the fact that the ones below IW minus some threshold have been verified before so it's not too risky not to continue to validate them. This does unfortunately require some code, although minimal, to be added to the fast path to check the initial burst size. In some implementations it may not even be easy to accurately delineate/ compute the "burst" size, but one can always fudge in that case. 4. The proposal makes an assumption that the choice of IW is to be blamed if the percentage of connection experiencing pkt loss during its IW is greater than some threshold. But this may not be true. A host may experience high loss percentage regardless of IW. E.g., IW3 performs as bad as IW10. If the losses are spread across a large percentage of connections, then one can argue it's moot whether an optimal IW is picked because performance will suck for most connections anyway (assuming a high loss threshold of, e.g., 5%). But if the losses concentrate on only 5% of remote peers and these peers suffer real high pkt loss rate, this false positive will forbid IW to ever grow, and hence deprives the rest 95% connections of the benefit of a larger IW. I have no idea how often this false positive case might exist but if it turns out to be a large percentage then the proposal will be worthless in terms of addressing the small IW problem. 5. A possible fix may be to use two sets of counters rather than one. One tracks the loss rate of all the initial burst sizes <= 3. The other tracks the rest upto IW. Then compare the two, and allow IW to increase if the loss rate of the second set is within some threshold (either absolute or some percentage) of the first one. But one problem with the above is that the number of the base case (IW3) may have been negatively affected by other hosts moving up to a higher IW. 6. Regarding te sequence number wrap around problem, one can add a simple check to reset IWnotchecked when seqno goes beyond IW but this requres adding a check to the past path. I agree this issue is tiny that may be ignored and just allow the false positive. 7. [Ch10] - misses N. Dukkipati as a co-author. Jerry On Thu, Dec 23, 2010 at 3:38 PM, Joe Touch wrote: > Hi, all, > > A preliminary draft has been posted: > > http://www.ietf.org/id/draft-touch-tcpm-automatic-iw-00.txt > > It includes the algorithm and a lot of other details, some fleshed out (the > intro), others as a list. The goal is to use this as a basis of initial > discussion. > > (I have not determined the author list yet, so it says TBD right now...) > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From hkchu@google.com Tue Dec 28 14:19: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 6F3363A68E8 for ; Tue, 28 Dec 2010 14:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=-3.823, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 U+6wtARKmHE7 for ; Tue, 28 Dec 2010 14:19:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 175063A68E7 for ; Tue, 28 Dec 2010 14:19:13 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id oBSMLHsl024261 for ; Tue, 28 Dec 2010 14:21:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293574878; bh=jjVOFdh5+z8DtArdnksYToVLX2s=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ofp0bWDD8G8lYcfXQV+XW7iM7hnU1RBNxORo1XWux1KuIjUzthbQ+58YODvSNCjmU Mwg89bv4qNgISOqMyPU+Q== Received: from gye5 (gye5.prod.google.com [10.243.50.5]) by wpaz33.hot.corp.google.com with ESMTP id oBSMKuYr030806 for ; Tue, 28 Dec 2010 14:21:16 -0800 Received: by gye5 with SMTP id 5so4891521gye.18 for ; Tue, 28 Dec 2010 14:21:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+VOoX8GuGL2/gmYHHYM/3nANYY2X8dVdJTPz7jbItpI=; b=RbtkOcxmmlI/9QiFc9G9szqT9yp7Te1KrJl9bV+vbJaPY3DCt2AD5XjO8B24dGkTKb b58BgGOPsUFNWfN/Gq8A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tnGlqH94BupakUzdTuoyX73oUTW06s1i1n4x7jfFWW1zGihcd2A94s5znA94FId9jt KYuObmX0Y2JOiTOm4MJQ== MIME-Version: 1.0 Received: by 10.150.218.21 with SMTP id q21mr18120343ybg.177.1293574876341; Tue, 28 Dec 2010 14:21:16 -0800 (PST) Received: by 10.151.26.9 with HTTP; Tue, 28 Dec 2010 14:21:16 -0800 (PST) In-Reply-To: References: <20101207033356.439642715136@lawyers.icir.org> Date: Tue, 28 Dec 2010 14:21:16 -0800 Message-ID: From: Jerry Chu To: "Per Hurtig (work)" Content-Type: multipart/alternative; boundary=000e0cd40650fea7c504987fde36 X-System-Of-Record: true Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] new version of 2988bis 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, 28 Dec 2010 22:19:15 -0000 --000e0cd40650fea7c504987fde36 Content-Type: text/plain; charset=ISO-8859-1 Hi, Have you tried your proposed change on slow links (e.g., 56Kbps dialup)? Your proposal assumes RTTs for pkts in a burst are statistically independent of each other's existence. This may be true for fast links but not for slower links when the serialization delay dominates the round trip time for transmitting a packet. E.g., when you have a micro burst of n packets, the RTT for the m'th packet will include the serialization delay of itself and all the preceding packets. Your proposed change may cause a lot of spurious RTOs for later packets in a burst, including the ones in a large IW. The current paragraph in RFC2988 of restarting the RTO timer afresh upon each ack, although more conservative, limits the additive effect of serialization delay to the RTT to at most 2 packets (due to delayed acks). Best, Jerry On Wed, Dec 22, 2010 at 1:16 AM, Per Hurtig (work) wrote: > Hi all, > > we have submitted an I-D that summarizes an alternate way to restart > the TCP/SCTP RTO timer: > > http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt > > The difference between this approach and RFC2988(bis)'s approach is > the way outstanding segments are > considered. We're happy to receive any comments on the draft. > > > Regards, Per H > > > > > On Tue, Dec 7, 2010 at 04:33, Mark Allman wrote: > > > > Folks- > > > > We posted a new version of the 2988bis I-D today. It is: > > > > draft-paxson-tcpm-rfc2988bis-01.txt > > > > The big change is a new set of empirical results that pertain to > > dropping the initial RTO from 3sec to 1sec is now given (along with the > > previous results from Google) in the appendix. Generally speaking, > > these results show it is pretty safe to drop the initial RTO. > > > > Have a look. I believe the authors are pretty happy with this document > > at this point. > > > > allman > > > > > > > > > > > > _______________________________________________ > > 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 > --000e0cd40650fea7c504987fde36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Have you tried your proposed change on slow links (e= .g., 56Kbps dialup)?

Your proposal assumes RTTs fo= r pkts in a burst are statistically independent
of each other'= ;s existence. This may be true for fast links but not for slower links
when the serialization delay dominates the round trip time for transmi= tting a
packet. E.g., when you have a micro burst of n packets, t= he RTT for the m'th
packet will include the serialization del= ay of itself and all the preceding packets.
Your proposed change may cause a lot of spurious RTOs for later packet= s in a
burst, including the ones in a large IW.

The current paragraph in RFC2988 of restarting the RTO timer afresh= upon each
ack,=A0although more conservative, limits=A0the additive effect of ser= ialization delay
to the RTT to at most 2 packets=A0(due to delaye= d acks).

Best,

Jerry

On Wed, Dec 22, 2010 at 1:16 AM, Per Hurtig = (work) <per.hurti= g@kau.se> wrote:
Hi all,

we have submitted an I-D that summarizes an alternate way to restart
the TCP/SCTP RTO timer:

http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt

The difference between this approach and RFC2988(bis)'s approach is
the way outstanding segments are
considered. We're happy to receive any comments on the draft.


Regards, Per H




On Tue, Dec 7, 2010 at 04:33, Mark Allman <mallman@icir.org> wrote:
>
> Folks-
>
> We posted a new version of the 2988bis I-D today. =A0It is:
>
> =A0draft-paxson-tcpm-rfc2988bis-01.txt
>
> The big change is a new set of empirical results that pertain to
> dropping the initial RTO from 3sec to 1sec is now given (along with th= e
> previous results from Google) in the appendix. =A0Generally speaking,<= br> > these results show it is pretty safe to drop the initial RTO.
>
> Have a look. =A0I believe the authors are pretty happy with this docum= ent
> at this point.
>
> allman
>
>
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--000e0cd40650fea7c504987fde36-- From per.hurtig@gmail.com Wed Dec 29 01:51: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 0FE2B3A68BC for ; Wed, 29 Dec 2010 01:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 YoxfiEzof53M for ; Wed, 29 Dec 2010 01:51:55 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 93B853A689D for ; Wed, 29 Dec 2010 01:51:55 -0800 (PST) Received: by fxm9 with SMTP id 9so9776058fxm.31 for ; Wed, 29 Dec 2010 01:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=qhU1rI5vzQQadA9enunl3VLYZgw1kg9FMgwoSc0YQJQ=; b=fsGFG76h1K0hv00tsaDermi+AH4JQPRct3mXRMyzpqWdi6OrNMrTnAqUf56wDnD/xv UaVRxjau7MMQ0HcxhHRUxEnAXiNasQ/DhCzAgtgcCtaBMAwWTIrt2c8DliH8TGu4s5OA wOC8DO9g1oVb8EkAv6VSln9QDc7FTEsyrZzMI= 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 :content-transfer-encoding; b=Uj5gc2AbIz3vvd9L5cKlGiRvYJJ1+pq5VcvqH6vqiZbjFsPB2Y3dzUhVfgTNhxnXZy Mm52HI/3m5Du2jawt2a3v7yyLbGHt/RNWPqdvjjYTxXwAqhdzpt30SnAPTIux9b+7wBm B2EVOS/rbefeLOC2F38Lmj0F8z0ZaKGe56100= MIME-Version: 1.0 Received: by 10.223.85.203 with SMTP id p11mr133553fal.108.1293616440264; Wed, 29 Dec 2010 01:54:00 -0800 (PST) Sender: per.hurtig@gmail.com Received: by 10.223.97.14 with HTTP; Wed, 29 Dec 2010 01:54:00 -0800 (PST) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0C0A2FD4@LDCMVEXC1-PRD.hq.netapp.com> References: <20101207033356.439642715136@lawyers.icir.org> <5FDC413D5FA246468C200652D63E627A0C0A2FD4@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 29 Dec 2010 10:54:00 +0100 X-Google-Sender-Auth: No4oH4qGkTywthmgZ6Aw1I3alkI Message-ID: From: "Per Hurtig (work)" To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] new version of 2988bis 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, 29 Dec 2010 09:51:57 -0000 I don't see why it should be necessary to track all unacked segments (or maybe I'm just not seeing it...). The only difference between this proposal and the original approach is that you account for the sending time of the earliest outstanding segment. The restart only happens when a pure cumulative acknowledgment arrives. Can you exemplify when the approach would fail? // Per On Wed, Dec 22, 2010 at 12:41, Scheffenegger, Richard wrote= : > > Hmm... > > How do you deal with multiple lost segments in the same window? Your draf= t says > > =A02. =A0Proposed Modifications > > =A0 The document proposes an update of step 5.3 in Section 5 of [RFC2988] > =A0 to (and a similar update of step R3 in section 6.3.2 of [RFC4960]): > > =A0 =A0 =A0When an ACK is received that acknowledges new data, restart th= e > =A0 =A0 =A0retransmission timer so that it will expire RTO seconds after = the > =A0 =A0 =A0earliest outstanding segment was transmitted (for the current > =A0 =A0 =A0value of RTO). > > =A0 The update requires TCP implementations to track the time elapsed > =A0 since sending the last unacknowledged segment. =A0In practice, this > =A0 could be achieved by adding one variable to the transmission control > =A0 block. > > But wouldn't you really need to track the sending time of *each* segment,= to always be able to calculate the true T_earliest? I can not see how a si= ngular, global TCPCB variable addresses this - perhaps I'm missing somethin= g? > > Wouldn't there be an opportunity to use this feature synergistically with= RFC1323 Timestamps also? (The ACK with new data should reflect the sender'= s TCP clock (or a well derived value thereof) at the time the segment was s= ent. Perhaps that information can help reducing additional per-segment stat= e in the sender?) > > Best regards, > =A0 Richard Scheffenegger > > >> -----Original Message----- >> From: Per Hurtig (work) [mailto:per.hurtig@kau.se] >> Sent: Mittwoch, 22. Dezember 2010 10:16 >> To: tcpm@ietf.org >> Cc: mallman@icir.org >> Subject: Re: [tcpm] new version of 2988bis >> >> Hi all, >> >> we have submitted an I-D that summarizes an alternate way to restart >> the TCP/SCTP RTO timer: >> >> http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt >> >> The difference between this approach and RFC2988(bis)'s approach is >> the way outstanding segments are >> considered. We're happy to receive any comments on the draft. >> >> >> Regards, Per H >> >> >> >> >> On Tue, Dec 7, 2010 at 04:33, Mark Allman wrote: >> > >> > Folks- >> > >> > We posted a new version of the 2988bis I-D today. =A0It is: >> > >> > =A0draft-paxson-tcpm-rfc2988bis-01.txt >> > >> > The big change is a new set of empirical results that pertain to >> > dropping the initial RTO from 3sec to 1sec is now given (along with >> the >> > previous results from Google) in the appendix. =A0Generally speaking, >> > these results show it is pretty safe to drop the initial RTO. >> > >> > Have a look. =A0I believe the authors are pretty happy with this >> document >> > at this point. >> > >> > allman >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 per.hurtig@gmail.com Wed Dec 29 02:11: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 210E43A68D3 for ; Wed, 29 Dec 2010 02:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 T7m8d3PnNeey for ; Wed, 29 Dec 2010 02:11:52 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 004F23A68BC for ; Wed, 29 Dec 2010 02:11:51 -0800 (PST) Received: by fxm9 with SMTP id 9so9786496fxm.31 for ; Wed, 29 Dec 2010 02:13:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=DwKxMO1Ca69E3ER1l5mbXT8/wGxdI0R3/4DQ5KUWOPc=; b=mrsgHSHqBX7uEdege/97SkBxi3TJR9sxPuDSnJ6UEVPbIbOD6ZWUSjfz/MzR2Vlu3X 1Hy+VGpb25K6l7FsiFNNHHCAaov0X3S0VYKQmW0QEuNbCkXYf3lOP+lj76//US12/ADr 9htyiCwLmb92DSZP1yDCFW7OvMqQLJnNglW60= 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 :content-transfer-encoding; b=X/Ywe+/xcph8G9HZyTyL3lJLJdgLpRFPCJFlTDdETWG3yih4s1/lNbGus4T6CoQpjn xpFMtfjNmzdQRMYhQbRNXCWdV+2C8W5AbTmJUT+BCrPGo7x7hkN4CWQtuSPjtVD957U6 phKHsX6uyGUoO6k/Tp2YjuTRQ+L4s7xpt6fls= MIME-Version: 1.0 Received: by 10.223.85.203 with SMTP id p11mr150350fal.108.1293617636778; Wed, 29 Dec 2010 02:13:56 -0800 (PST) Sender: per.hurtig@gmail.com Received: by 10.223.97.14 with HTTP; Wed, 29 Dec 2010 02:13:56 -0800 (PST) In-Reply-To: References: <20101207033356.439642715136@lawyers.icir.org> Date: Wed, 29 Dec 2010 11:13:56 +0100 X-Google-Sender-Auth: RJY5aS53Ex0f8Eavnmv6ut-u18Q Message-ID: From: "Per Hurtig (work)" To: Jerry Chu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] new version of 2988bis 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, 29 Dec 2010 10:11:53 -0000 Hi, we have not yet experimented with slow links, but we will. Maybe there will be an increased amount of unnecessary RTOs due to serialization delay, but that will also depend on: * the RTOmin -- if set to 1s it will surely protect a subset of the slow connections, * and # of RTT samples per window -- if more than one sample, the RTT variation could compensate for the serialization delay Regards, Per On Tue, Dec 28, 2010 at 23:21, Jerry Chu wrote: > Hi, > Have you tried your proposed change on slow links (e.g., 56Kbps dialup)? > Your proposal assumes RTTs for pkts in a burst are statistically independ= ent > of each other's existence. This may be true for fast links but not for > slower links > when the serialization delay dominates the round trip time for transmitti= ng > a > packet. E.g., when you have a micro burst of n packets, the RTT for the m= 'th > packet will include the serialization delay of itself and all the precedi= ng > packets. > Your proposed change may cause a lot of spurious RTOs for later packets i= n a > burst, including the ones in a large IW. > The current paragraph in RFC2988 of restarting the RTO timer afresh upon > each > ack,=A0although more conservative, limits=A0the additive effect of serial= ization > delay > to the RTT to at most 2 packets=A0(due to delayed acks). > Best, > Jerry > On Wed, Dec 22, 2010 at 1:16 AM, Per Hurtig (work) > wrote: >> >> Hi all, >> >> we have submitted an I-D that summarizes an alternate way to restart >> the TCP/SCTP RTO timer: >> >> http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt >> >> The difference between this approach and RFC2988(bis)'s approach is >> the way outstanding segments are >> considered. We're happy to receive any comments on the draft. >> >> >> Regards, Per H >> >> >> >> >> On Tue, Dec 7, 2010 at 04:33, Mark Allman wrote: >> > >> > Folks- >> > >> > We posted a new version of the 2988bis I-D today. =A0It is: >> > >> > =A0draft-paxson-tcpm-rfc2988bis-01.txt >> > >> > The big change is a new set of empirical results that pertain to >> > dropping the initial RTO from 3sec to 1sec is now given (along with th= e >> > previous results from Google) in the appendix. =A0Generally speaking, >> > these results show it is pretty safe to drop the initial RTO. >> > >> > Have a look. =A0I believe the authors are pretty happy with this docum= ent >> > at this point. >> > >> > allman >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 Dec 29 11:11: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 C391B3A686D for ; Wed, 29 Dec 2010 11:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[AWL=-3.622, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Yack-wMPgYNS for ; Wed, 29 Dec 2010 11:11:31 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8595B3A6867 for ; Wed, 29 Dec 2010 11:11:27 -0800 (PST) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id oBTJDVl6008800 for ; Wed, 29 Dec 2010 11:13:32 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293650012; bh=qFK6BFS+l1xN9FJVmpJQRW6HZUU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=rM24gtAT7DT40oPzseQ7Wo34FxM826OcEYp4YeJ6KbPy8cVHhB26jeXdDvspNZU6X nfnTIihBRdzj/GPGAOSiQ== Received: from gxk25 (gxk25.prod.google.com [10.202.11.25]) by kpbe20.cbf.corp.google.com with ESMTP id oBTJDToL001972 for ; Wed, 29 Dec 2010 11:13:30 -0800 Received: by gxk25 with SMTP id 25so2039153gxk.9 for ; Wed, 29 Dec 2010 11:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=bTd3FumAwWVgvHTSTlZGi9sxHTmSCG5mS2MmxPHaAD4=; b=ZeYKmDIdVxwQRjki1zTIc0BqAhZ4/BtMd3tCrnpITARhY9uDjcsxofRWJajH/mSmmn kVQz549ze+vJy3qAMpDA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Pg43cvykUiMTFgLjFUF+OwlWRZ1vIbF9tgnztPrL8XDyT47sXFEzsX9Ecm4z3FYIOg 7uC5Bhv5TZW0IA4OJ6Gw== MIME-Version: 1.0 Received: by 10.91.15.17 with SMTP id s17mr5975935agi.24.1293650008033; Wed, 29 Dec 2010 11:13:28 -0800 (PST) Received: by 10.151.26.9 with HTTP; Wed, 29 Dec 2010 11:13:27 -0800 (PST) In-Reply-To: References: <20101207033356.439642715136@lawyers.icir.org> <5FDC413D5FA246468C200652D63E627A0C0A2FD4@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 29 Dec 2010 11:13:27 -0800 Message-ID: From: Jerry Chu To: "Per Hurtig (work)" Content-Type: multipart/alternative; boundary=0016364d2e873149a40498915d0e X-System-Of-Record: true Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] new version of 2988bis 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, 29 Dec 2010 19:11:35 -0000 --0016364d2e873149a40498915d0e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 29, 2010 at 1:54 AM, Per Hurtig (work) wrote: > I don't see why it should be necessary to track all unacked segments > (or maybe I'm just not seeing it...). The only difference between this > proposal and the original approach is that you account for the sending > time of the earliest outstanding segment. The restart only happens > But doesn't that require one to record the sending time of each segment? BTW, Linux already does this (i.e., timestamping each skb before sending, regardless of the timestamp option). Dunno about other OSes. Jerry > when a pure cumulative acknowledgment arrives. Can you exemplify when > the approach would fail? > > // Per > > On Wed, Dec 22, 2010 at 12:41, Scheffenegger, Richard > wrote: > > > > Hmm... > > > > How do you deal with multiple lost segments in the same window? Your > draft says > > > > 2. Proposed Modifications > > > > The document proposes an update of step 5.3 in Section 5 of [RFC2988] > > to (and a similar update of step R3 in section 6.3.2 of [RFC4960]): > > > > When an ACK is received that acknowledges new data, restart the > > retransmission timer so that it will expire RTO seconds after the > > earliest outstanding segment was transmitted (for the current > > value of RTO). > > > > The update requires TCP implementations to track the time elapsed > > since sending the last unacknowledged segment. In practice, this > > could be achieved by adding one variable to the transmission control > > block. > > > > But wouldn't you really need to track the sending time of *each* segment, > to always be able to calculate the true T_earliest? I can not see how a > singular, global TCPCB variable addresses this - perhaps I'm missing > something? > > > > Wouldn't there be an opportunity to use this feature synergistically with > RFC1323 Timestamps also? (The ACK with new data should reflect the sender's > TCP clock (or a well derived value thereof) at the time the segment was > sent. Perhaps that information can help reducing additional per-segment > state in the sender?) > > > > Best regards, > > Richard Scheffenegger > > > > > >> -----Original Message----- > >> From: Per Hurtig (work) [mailto:per.hurtig@kau.se] > >> Sent: Mittwoch, 22. Dezember 2010 10:16 > >> To: tcpm@ietf.org > >> Cc: mallman@icir.org > >> Subject: Re: [tcpm] new version of 2988bis > >> > >> Hi all, > >> > >> we have submitted an I-D that summarizes an alternate way to restart > >> the TCP/SCTP RTO timer: > >> > >> http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt > >> > >> The difference between this approach and RFC2988(bis)'s approach is > >> the way outstanding segments are > >> considered. We're happy to receive any comments on the draft. > >> > >> > >> Regards, Per H > >> > >> > >> > >> > >> On Tue, Dec 7, 2010 at 04:33, Mark Allman wrote: > >> > > >> > Folks- > >> > > >> > We posted a new version of the 2988bis I-D today. It is: > >> > > >> > draft-paxson-tcpm-rfc2988bis-01.txt > >> > > >> > The big change is a new set of empirical results that pertain to > >> > dropping the initial RTO from 3sec to 1sec is now given (along with > >> the > >> > previous results from Google) in the appendix. Generally speaking, > >> > these results show it is pretty safe to drop the initial RTO. > >> > > >> > Have a look. I believe the authors are pretty happy with this > >> document > >> > at this point. > >> > > >> > allman > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 > --0016364d2e873149a40498915d0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Dec 29, 2010 at 1:54 AM, Per Hurtig (work) <per.hurtig@kau.se> wrote:<= br>
I don't see why it should be necessary to track all unacked segments (or maybe I'm just not seeing it...). The only difference between this<= br> proposal and the original approach is that you account for the sending
time of the earliest outstanding segment. The restart only happens

But doesn't that require one to record the = sending time of each segment?

BTW, Linux already d= oes this (i.e., timestamping each skb before sending, regardless
of the timestamp option). Dunno about other OSes.

=
Jerry
=A0
when a pure cumulative acknowledgment arrives. Can you exemplify when
the approach would fail?

// Per

On Wed, Dec 22, 2010 at 12:41, Scheffenegger, Richard <rs@netapp.com> wrote:
>
> Hmm...
>
> How do you deal with multiple lost segments in the same window? Your d= raft says
>
> =A02. =A0Proposed Modifications
>
> =A0 The document proposes an update of step 5.3 in Section 5 of [RFC29= 88]
> =A0 to (and a similar update of step R3 in section 6.3.2 of [RFC4960])= :
>
> =A0 =A0 =A0When an ACK is received that acknowledges new data, restart= the
> =A0 =A0 =A0retransmission timer so that it will expire RTO seconds aft= er the
> =A0 =A0 =A0earliest outstanding segment was transmitted (for the curre= nt
> =A0 =A0 =A0value of RTO).
>
> =A0 The update requires TCP implementations to track the time elapsed<= br> > =A0 since sending the last unacknowledged segment. =A0In practice, thi= s
> =A0 could be achieved by adding one variable to the transmission contr= ol
> =A0 block.
>
> But wouldn't you really need to track the sending time of *each* s= egment, to always be able to calculate the true T_earliest? I can not see h= ow a singular, global TCPCB variable addresses this - perhaps I'm missi= ng something?
>
> Wouldn't there be an opportunity to use this feature synergistical= ly with RFC1323 Timestamps also? (The ACK with new data should reflect the = sender's TCP clock (or a well derived value thereof) at the time the se= gment was sent. Perhaps that information can help reducing additional per-s= egment state in the sender?)
>
> Best regards,
> =A0 Richard Scheffenegger
>
>
>> -----Original Message-----
>> From: Per Hurtig (work) [mailto:per.hurtig@kau.se]
>> Sent: Mittwoch, 22. Dezember 2010 10:16
>> To: tcpm@ietf.org
>> Cc: mallman@icir.org
>> Subject: Re: [tcpm] new version of 2988bis
>>
>> Hi all,
>>
>> we have submitted an I-D that summarizes an alternate way to resta= rt
>> the TCP/SCTP RTO timer:
>>
>> http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-= 00.txt
>>
>> The difference between this approach and RFC2988(bis)'s approa= ch is
>> the way outstanding segments are
>> considered. We're happy to receive any comments on the draft.<= br> >>
>>
>> Regards, Per H
>>
>>
>>
>>
>> On Tue, Dec 7, 2010 at 04:33, Mark Allman <mallman@icir.org> wrote:
>> >
>> > Folks-
>> >
>> > We posted a new version of the 2988bis I-D today. =A0It is: >> >
>> > =A0draft-paxson-tcpm-rfc2988bis-01.txt
>> >
>> > The big change is a new set of empirical results that pertain= to
>> > dropping the initial RTO from 3sec to 1sec is now given (alon= g with
>> the
>> > previous results from Google) in the appendix. =A0Generally s= peaking,
>> > these results show it is pretty safe to drop the initial RTO.=
>> >
>> > Have a look. =A0I believe the authors are pretty happy with t= his
>> document
>> > at this point.
>> >
>> > allman
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--0016364d2e873149a40498915d0e-- From rs@netapp.com Thu Dec 30 05:28: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 368D63A67A6 for ; Thu, 30 Dec 2010 05:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8lx8sXzCShD1 for ; Thu, 30 Dec 2010 05:28:42 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 8F8193A680A for ; Thu, 30 Dec 2010 05:28:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,249,1291622400"; d="scan'208,217";a="228738389" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 30 Dec 2010 05:30:46 -0800 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oBUDUjv0019401; Thu, 30 Dec 2010 05:30:45 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Dec 2010 14:30:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBA825.C316FEE2" Date: Thu, 30 Dec 2010 13:28:17 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0C2CA4C2@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] new version of 2988bis Thread-Index: AcunjH6T043Vg8YdSLuryDR+g5TFygAlp7qA References: <20101207033356.439642715136@lawyers.icir.org><5FDC413D5FA246468C200652D63E627A0C0A2FD4@LDCMVEXC1-PRD.hq.netapp.com> From: "Scheffenegger, Richard" To: "Jerry Chu" , "Per Hurtig (work)" X-OriginalArrivalTime: 30 Dec 2010 13:30:45.0802 (UTC) FILETIME=[C38990A0:01CBA825] Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] new version of 2988bis 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, 30 Dec 2010 13:28:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBA825.C316FEE2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Thank you Jerry! =20 Per, =20 The sender cannot know which segment will eventually be covered in a cumulative ACK (it could be any segment in the current window), thus a singular variable in tcpcb doesn't appear to be able to hold enough information. =20 Of course, if you have additional side information for each segment (ie. Linux TCP stack) or carried back for each segment (such as timestamps reflecting the TCP sender clock perfectly), you can get away with much less state in the sender. (I think the TS option would be the only viable way for BSD-derived TCP stacks). =20 =20 Also, I am very interested in learning your results on the slow-link - if the variability inducted by the serialization delay would be enough to prevent undue spurious RTOs. Note that RFC1323 rules out the usability of timestamps for RTT calculation during a window containing loss... Thus I strongly suspect, that if you are sending a burst of data, and loose one early segment (where serialization delay is still low), the sender will not be able to adjust the RTTM (and varability) properly - resulting exactly in the scenario described by Jerry (much higher spurious RTOs). =20 Also, even though the RFCs have minRTO at 1 sec, all available stacks violate this today per default, afaik. Typical minRTO is between 100 and 400 msec, and there are stacks with a default minRTO is in the low 10s of msec... =20 Thus it might be more prudent to verify if the timeliness of latency feedback to the sender is enough, to work with the current RTTM / RTO tunables (sRTT + 4* varRTT), or if that formula needs to be adjusted... =20 Or, if the RFC1323 guidance of *not* using RTT feedback during loss events need to be reviewed to allow a more tight estimation of RTT and varRTT under all circumstances, in turn allowing more tight RTO values... =20 Happy new year, Richard =20 =20 From: Jerry Chu [mailto:hkchu@google.com]=20 Sent: Mittwoch, 29. Dezember 2010 20:13 To: Per Hurtig (work) Cc: Scheffenegger, Richard; tcpm@ietf.org; mallman@icir.org Subject: Re: [tcpm] new version of 2988bis =20 On Wed, Dec 29, 2010 at 1:54 AM, Per Hurtig (work) wrote: I don't see why it should be necessary to track all unacked segments (or maybe I'm just not seeing it...). The only difference between this proposal and the original approach is that you account for the sending time of the earliest outstanding segment. The restart only happens =20 But doesn't that require one to record the sending time of each segment? =20 BTW, Linux already does this (i.e., timestamping each skb before sending, regardless of the timestamp option). Dunno about other OSes. =20 Jerry =20 when a pure cumulative acknowledgment arrives. Can you exemplify when the approach would fail? =09 // Per =09 On Wed, Dec 22, 2010 at 12:41, Scheffenegger, Richard wrote: > > Hmm... > > How do you deal with multiple lost segments in the same window? Your draft says > > 2. Proposed Modifications > > The document proposes an update of step 5.3 in Section 5 of [RFC2988] > to (and a similar update of step R3 in section 6.3.2 of [RFC4960]): > > When an ACK is received that acknowledges new data, restart the > retransmission timer so that it will expire RTO seconds after the > earliest outstanding segment was transmitted (for the current > value of RTO). > > The update requires TCP implementations to track the time elapsed > since sending the last unacknowledged segment. In practice, this > could be achieved by adding one variable to the transmission control > block. > > But wouldn't you really need to track the sending time of *each* segment, to always be able to calculate the true T_earliest? I can not see how a singular, global TCPCB variable addresses this - perhaps I'm missing something? > > Wouldn't there be an opportunity to use this feature synergistically with RFC1323 Timestamps also? (The ACK with new data should reflect the sender's TCP clock (or a well derived value thereof) at the time the segment was sent. Perhaps that information can help reducing additional per-segment state in the sender?) > > Best regards, > Richard Scheffenegger > > >> -----Original Message----- >> From: Per Hurtig (work) [mailto:per.hurtig@kau.se] >> Sent: Mittwoch, 22. Dezember 2010 10:16 >> To: tcpm@ietf.org >> Cc: mallman@icir.org >> Subject: Re: [tcpm] new version of 2988bis >> >> Hi all, >> >> we have submitted an I-D that summarizes an alternate way to restart >> the TCP/SCTP RTO timer: >> >> http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt >> >> The difference between this approach and RFC2988(bis)'s approach is >> the way outstanding segments are >> considered. We're happy to receive any comments on the draft. >> >> >> Regards, Per H >> >> >> >> >> On Tue, Dec 7, 2010 at 04:33, Mark Allman wrote: >> > >> > Folks- >> > >> > We posted a new version of the 2988bis I-D today. It is: >> > >> > draft-paxson-tcpm-rfc2988bis-01.txt >> > >> > The big change is a new set of empirical results that pertain to >> > dropping the initial RTO from 3sec to 1sec is now given (along with >> the >> > previous results from Google) in the appendix. Generally speaking, >> > these results show it is pretty safe to drop the initial RTO. >> > >> > Have a look. I believe the authors are pretty happy with this >> document >> > at this point. >> > >> > allman >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 ------_=_NextPart_001_01CBA825.C316FEE2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Thank you Jerry!

 

Per,

 

The sender cannot know which segment will eventually be covered in a = cumulative ACK (it could be any segment in the current window), thus a = singular variable in tcpcb doesn’t appear to be able to hold = enough information.

 

Of course, if you have additional side information for each segment = (ie. Linux TCP stack) or carried back for each segment (such as = timestamps reflecting the TCP sender clock perfectly), you can get away = with much less state in the sender. (I think the TS option would be the = only viable way for BSD-derived TCP stacks).

 

 

Also, I am very interested in learning your results on the slow-link = – if the variability inducted by the serialization delay would be = enough to prevent undue spurious RTOs. Note that RFC1323 rules out the = usability of timestamps for RTT calculation during a window containing = loss…

Thus I strongly suspect, that if you are sending a burst of data, and = loose one early segment (where serialization delay is still low), the = sender will not be able to adjust the RTTM (and varability) properly = – resulting exactly in the scenario described by Jerry (much = higher spurious RTOs).

 

Also, even though the RFCs have minRTO at 1 sec, all available stacks = violate this today per default, afaik. Typical minRTO is between 100 and = 400 msec, and there are stacks with a default minRTO is in the low 10s = of msec…

 

Thus it might be more prudent to verify if the timeliness of latency = feedback to the sender is enough, to work with the current RTTM / RTO = tunables (sRTT + 4* varRTT), or if that formula needs to be = adjusted…

 

Or, if the RFC1323 guidance of *not* using RTT feedback during = loss events need to be reviewed to allow a more tight estimation of RTT = and varRTT under all circumstances, in turn allowing more tight RTO = values…

 

Happy new year,

   Richard

 

 

From:= Jerry Chu = [mailto:hkchu@google.com]
Sent: Mittwoch, 29. Dezember 2010 = 20:13
To: Per Hurtig (work)
Cc: Scheffenegger, = Richard; tcpm@ietf.org; mallman@icir.org
Subject: Re: [tcpm] = new version of 2988bis

 

On Wed, Dec = 29, 2010 at 1:54 AM, Per Hurtig (work) <per.hurtig@kau.se> = wrote:

I don't = see why it should be necessary to track all unacked segments
(or = maybe I'm just not seeing it...). The only difference between = this
proposal and the original approach is that you account for the = sending
time of the earliest outstanding segment. The restart only = happens

 

But doesn't that require one to record the sending = time of each segment?

 

BTW, Linux already does this (i.e., timestamping each = skb before sending, regardless

of the timestamp option). Dunno about other = OSes.

 

Jerry

 

when a = pure cumulative acknowledgment arrives. Can you exemplify when
the = approach would fail?

// = Per


On Wed, Dec = 22, 2010 at 12:41, Scheffenegger, Richard <rs@netapp.com> = wrote:
>
> Hmm...
>
> How do you deal with = multiple lost segments in the same window? Your draft = says
>
>  2.  Proposed = Modifications
>
>   The document proposes an update of = step 5.3 in Section 5 of [RFC2988]
>   to (and a similar = update of step R3 in section 6.3.2 of [RFC4960]):
>
>   =    When an ACK is received that acknowledges new data, restart = the
>      retransmission timer so that it will = expire RTO seconds after the
>      earliest = outstanding segment was transmitted (for the current
>   =    value of RTO).
>
>   The update requires = TCP implementations to track the time elapsed
>   since = sending the last unacknowledged segment.  In practice, this
> =   could be achieved by adding one variable to the transmission = control
>   block.
>
> But wouldn't you really = need to track the sending time of *each* segment, to always be able to = calculate the true T_earliest? I can not see how a singular, global = TCPCB variable addresses this - perhaps I'm missing = something?
>
> Wouldn't there be an opportunity to use this = feature synergistically with RFC1323 Timestamps also? (The ACK with new = data should reflect the sender's TCP clock (or a well derived value = thereof) at the time the segment was sent. Perhaps that information can = help reducing additional per-segment state in the = sender?)
>
> Best regards,
>   Richard = Scheffenegger
>
>
>> -----Original = Message-----
>> From: Per Hurtig (work) [mailto:per.hurtig@kau.se]
>> = Sent: Mittwoch, 22. Dezember 2010 10:16
>> To: tcpm@ietf.org
>> Cc: mallman@icir.org
>> = Subject: Re: [tcpm] new version of 2988bis
>>
>> Hi = all,
>>
>> we have submitted an I-D that summarizes an = alternate way to restart
>> the TCP/SCTP RTO = timer:
>>
>> http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.= txt
>>
>> The difference between this approach and = RFC2988(bis)'s approach is
>> the way outstanding segments = are
>> considered. We're happy to receive any comments on the = draft.
>>
>>
>> Regards, Per = H
>>
>>
>>
>>
>> On Tue, = Dec 7, 2010 at 04:33, Mark Allman <mallman@icir.org> = wrote:
>> >
>> > Folks-
>> = >
>> > We posted a new version of the 2988bis I-D today. =  It is:
>> >
>> > =  draft-paxson-tcpm-rfc2988bis-01.txt
>> >
>> = > The big change is a new set of empirical results that pertain = to
>> > dropping the initial RTO from 3sec to 1sec is now = given (along with
>> the
>> > previous results from = Google) in the appendix.  Generally speaking,
>> > = these results show it is pretty safe to drop the initial = RTO.
>> >
>> > Have a look.  I believe the = authors are pretty happy with this
>> document
>> > = at this point.
>> >
>> > allman
>> = >
>> >
>> >
>> >
>> = >
>> > = _______________________________________________
>> > tcpm = mailing list
>> > tcpm@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tcpm
>&= gt; >
>> = _______________________________________________
>> tcpm mailing = list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
><= br>>
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

 

------_=_NextPart_001_01CBA825.C316FEE2-- From per.hurtig@gmail.com Thu Dec 30 07:36:28 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 A137B3A6846 for ; Thu, 30 Dec 2010 07:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 YaV+4Yixlgjc for ; Thu, 30 Dec 2010 07:36:27 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 044913A684D for ; Thu, 30 Dec 2010 07:36:26 -0800 (PST) Received: by fxm9 with SMTP id 9so10818894fxm.31 for ; Thu, 30 Dec 2010 07:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=RKeNf3NeIcS+UJVsCXN7QyTlnp8udMrHVW+AdUn15kg=; b=SnOum6u3ODw6xPQ6u0fDqIJdJm050Eg+WVNUpKQshkyhVTHmuYOOk4o48O4H0/kgiA pBLQgUOE+Mr+UMqjpR2DtcWHRZWIlcDf9l/WcfQU4/OoqnGFN13ZHiwh9FgoNOBHb/AW mS9CveOOYzytaVb1WzMf11yqG4Xh5h2dknSUQ= 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 :content-transfer-encoding; b=Ah7cCmP9a+eqkE71nzz9p5RwFFWuhZE8tfz0DXPOxw9WwgU7tDVJmL+wjtv/D4NWHW xJpZxoNXM2aQHZm/S9MZcEj4ruQ4I0z6XBFrszWiFQtMZOOzPjv3CCEv49FrlJwAYQiW V0DIcOue1FWLa1kMVGtJLRp5Iqhm9BnypIGo8= MIME-Version: 1.0 Received: by 10.223.116.1 with SMTP id k1mr58795faq.51.1293723511425; Thu, 30 Dec 2010 07:38:31 -0800 (PST) Sender: per.hurtig@gmail.com Received: by 10.223.97.14 with HTTP; Thu, 30 Dec 2010 07:38:31 -0800 (PST) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0C2CA4C2@LDCMVEXC1-PRD.hq.netapp.com> References: <20101207033356.439642715136@lawyers.icir.org> <5FDC413D5FA246468C200652D63E627A0C0A2FD4@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C2CA4C2@LDCMVEXC1-PRD.hq.netapp.com> Date: Thu, 30 Dec 2010 16:38:31 +0100 X-Google-Sender-Auth: AQG3ewWaKawyJFtRXdgT3fhLt7E Message-ID: From: "Per Hurtig (work)" To: "Scheffenegger, Richard" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] new version of 2988bis 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, 30 Dec 2010 15:36:28 -0000 Hi and thanks for all the comments, all of you are, of course, correct in that a single variable isn't enough. I don't understand why I put it like that in the ID, and why I felt that it would work =3D) I've implemented this approach a long time ago in FreeBSD (for SCTP), and there I had the sending time of each message stored in the internal packet structure (just like Jerry pointed out for linux TCP). An alternative approach could be to set RTO =3D RTO-RTT upon each restart of the timer. This is not equally exact as the delayed ack timer of the receiver will impact the rtt. I also agree in that there are a number of things that could affect this approach, including the de facto minRTOs and the rtt sampling rules. I'll, however, carry out some experiments fairly soon to investigate this further. Happy new year, Per On Thu, Dec 30, 2010 at 14:28, Scheffenegger, Richard wrote= : > > > Thank you Jerry! > > > > Per, > > > > The sender cannot know which segment will eventually be covered in a > cumulative ACK (it could be any segment in the current window), thus a > singular variable in tcpcb doesn=92t appear to be able to hold enough > information. > > > > Of course, if you have additional side information for each segment (ie. > Linux TCP stack) or carried back for each segment (such as timestamps > reflecting the TCP sender clock perfectly), you can get away with much le= ss > state in the sender. (I think the TS option would be the only viable way = for > BSD-derived TCP stacks). > > > > > > Also, I am very interested in learning your results on the slow-link =96 = if > the variability inducted by the serialization delay would be enough to > prevent undue spurious RTOs. Note that RFC1323 rules out the usability of > timestamps for RTT calculation during a window containing loss=85 > > Thus I strongly suspect, that if you are sending a burst of data, and loo= se > one early segment (where serialization delay is still low), the sender wi= ll > not be able to adjust the RTTM (and varability) properly =96 resulting ex= actly > in the scenario described by Jerry (much higher spurious RTOs). > > > > Also, even though the RFCs have minRTO at 1 sec, all available stacks > violate this today per default, afaik. Typical minRTO is between 100 and = 400 > msec, and there are stacks with a default minRTO is in the low 10s of mse= c=85 > > > > Thus it might be more prudent to verify if the timeliness of latency > feedback to the sender is enough, to work with the current RTTM / RTO > tunables (sRTT + 4* varRTT), or if that formula needs to be adjusted=85 > > > > Or, if the RFC1323 guidance of *not* using RTT feedback during loss event= s > need to be reviewed to allow a more tight estimation of RTT and varRTT un= der > all circumstances, in turn allowing more tight RTO values=85 > > > > Happy new year, > > =A0=A0 Richard > > > > > > From: Jerry Chu [mailto:hkchu@google.com] > Sent: Mittwoch, 29. Dezember 2010 20:13 > To: Per Hurtig (work) > Cc: Scheffenegger, Richard; tcpm@ietf.org; mallman@icir.org > > Subject: Re: [tcpm] new version of 2988bis > > > > On Wed, Dec 29, 2010 at 1:54 AM, Per Hurtig (work) > wrote: > > I don't see why it should be necessary to track all unacked segments > (or maybe I'm just not seeing it...). The only difference between this > proposal and the original approach is that you account for the sending > time of the earliest outstanding segment. The restart only happens > > > > But doesn't that require one to record the sending time of each segment? > > > > BTW, Linux already does this (i.e., timestamping each skb before sending, > regardless > > of the timestamp option). Dunno about other OSes. > > > > Jerry > > > > when a pure cumulative acknowledgment arrives. Can you exemplify when > the approach would fail? > > // Per > > On Wed, Dec 22, 2010 at 12:41, Scheffenegger, Richard wro= te: >> >> Hmm... >> >> How do you deal with multiple lost segments in the same window? Your dra= ft >> says >> >> =A02. =A0Proposed Modifications >> >> =A0 The document proposes an update of step 5.3 in Section 5 of [RFC2988= ] >> =A0 to (and a similar update of step R3 in section 6.3.2 of [RFC4960]): >> >> =A0 =A0 =A0When an ACK is received that acknowledges new data, restart t= he >> =A0 =A0 =A0retransmission timer so that it will expire RTO seconds after= the >> =A0 =A0 =A0earliest outstanding segment was transmitted (for the current >> =A0 =A0 =A0value of RTO). >> >> =A0 The update requires TCP implementations to track the time elapsed >> =A0 since sending the last unacknowledged segment. =A0In practice, this >> =A0 could be achieved by adding one variable to the transmission control >> =A0 block. >> >> But wouldn't you really need to track the sending time of *each* segment= , >> to always be able to calculate the true T_earliest? I can not see how a >> singular, global TCPCB variable addresses this - perhaps I'm missing >> something? >> >> Wouldn't there be an opportunity to use this feature synergistically wit= h >> RFC1323 Timestamps also? (The ACK with new data should reflect the sende= r's >> TCP clock (or a well derived value thereof) at the time the segment was >> sent. Perhaps that information can help reducing additional per-segment >> state in the sender?) >> >> Best regards, >> =A0 Richard Scheffenegger >> >> >>> -----Original Message----- >>> From: Per Hurtig (work) [mailto:per.hurtig@kau.se] >>> Sent: Mittwoch, 22. Dezember 2010 10:16 >>> To: tcpm@ietf.org >>> Cc: mallman@icir.org >>> Subject: Re: [tcpm] new version of 2988bis >>> >>> Hi all, >>> >>> we have submitted an I-D that summarizes an alternate way to restart >>> the TCP/SCTP RTO timer: >>> >>> http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt >>> >>> The difference between this approach and RFC2988(bis)'s approach is >>> the way outstanding segments are >>> considered. We're happy to receive any comments on the draft. >>> >>> >>> Regards, Per H >>> >>> >>> >>> >>> On Tue, Dec 7, 2010 at 04:33, Mark Allman wrote: >>> > >>> > Folks- >>> > >>> > We posted a new version of the 2988bis I-D today. =A0It is: >>> > >>> > =A0draft-paxson-tcpm-rfc2988bis-01.txt >>> > >>> > The big change is a new set of empirical results that pertain to >>> > dropping the initial RTO from 3sec to 1sec is now given (along with >>> the >>> > previous results from Google) in the appendix. =A0Generally speaking, >>> > these results show it is pretty safe to drop the initial RTO. >>> > >>> > Have a look. =A0I believe the authors are pretty happy with this >>> document >>> > at this point. >>> > >>> > allman >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 > >