From tcpm-bounces@ietf.org Wed Sep 13 07:42:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNT6s-000637-7D; Wed, 13 Sep 2006 07:40:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNT6q-00061I-UM for tcpm@ietf.org; Wed, 13 Sep 2006 07:40:53 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNT6p-0008A7-9d for tcpm@ietf.org; Wed, 13 Sep 2006 07:40:52 -0400 Received: from lars.local (unknown [131.114.190.222]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 9C8011BAC4D; Wed, 13 Sep 2006 13:40:48 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id B490521B8BB; Wed, 13 Sep 2006 13:40:46 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Jabber-Id: lars.eggert@jabber.netlab.nec.de Message-Id: <41E932BF-B860-4AC8-9370-F240D33155CE@netlab.nec.de> From: Lars Eggert Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-03.txt Date: Wed, 13 Sep 2006 13:40:45 +0200 To: tcpm@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Godred Fairhurst X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0723470758==" Errors-To: tcpm-bounces@ietf.org --===============0723470758== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17--548180224; protocol="application/pkcs7-signature" --Apple-Mail-17--548180224 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Jul 20, 2006, at 0:50, wrote: > Title : TCP User Timeout Option > Author(s) : L. Eggert, F. Gont > Filename : draft-ietf-tcpm-tcp-uto-03.txt we haven't received any comments on this last version, which attempts to address the review comments from Gorry and others on -02. Could I ask the WG to take a look and see if it is happy with this revision? Thanks, Lars ID: http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-tcp-uto/draft-ietf- tcpm-tcp-uto-03.txt Diff: http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-tcp-uto/draft- ietf-tcpm-tcp-uto-03-from-02.diff.html -- Lars Eggert NEC Network Laboratories --Apple-Mail-17--548180224 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwOTEz MTE0MDQ2WjAjBgkqhkiG9w0BCQQxFgQUM0pqe5Abxci0+dlZ3Lk/RxNU6bkwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAFZzDjsG5gEfI862Zej5 JTOZjRoYsqyADMfWriCBQMj9U4leehABIEXps457YAXzkvHXvx4VO7I4YkWX6SVnby6MM/yM4Bsa Q0g02vW/U9Z/cc+OAuJFwmqYB6TGbe5b/VpbPjh5yyj2POi3Nio/JZtz0AgtTqWeCC7SjvdWaBmN v6QxU7RTjUXc48u/xzNjK4plRPKKhqszJL36+HEQ68gRqCzWfw9DKwAYMNafJMetZf1FwB0vaNyO TMRYeaNnqfgvZzCrn8QTRKwBbi+adU0Ze+SbEDuWCZfFilR20Y2FiOhKDOxmtsE4k4IM3VZjcpK7 bnTposQKpiNT2/+VcHoAAAAAAAA= --Apple-Mail-17--548180224-- --===============0723470758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0723470758==-- From tcpm-bounces@ietf.org Wed Sep 13 10:17:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNVXx-0005uq-37; Wed, 13 Sep 2006 10:17:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNVXu-0005uE-IU; Wed, 13 Sep 2006 10:16:58 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNVXu-00036h-Cb; Wed, 13 Sep 2006 10:16:58 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5824226E18; Wed, 13 Sep 2006 14:16:58 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GNVXu-0001yO-87; Wed, 13 Sep 2006 10:16:58 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 13 Sep 2006 10:16:58 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tcpm@ietf.org, rddp@ietf.org Subject: [tcpm] Last Call: 'Marker PDU Aligned Framing for TCP Specification' to Proposed Standard (draft-ietf-rddp-mpa) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org The IESG has received a request from the Remote Direct Data Placement WG to consider the following document: - 'Marker PDU Aligned Framing for TCP Specification ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-29. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rddp-mpa-06.txt _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 13 17:13:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNc1r-0000Es-Qs; Wed, 13 Sep 2006 17:12:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNc1o-0000EX-Mm; Wed, 13 Sep 2006 17:12:16 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNc1n-0000Xa-Aq; Wed, 13 Sep 2006 17:12:16 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k8DLCElt026914; Wed, 13 Sep 2006 14:12:14 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k8DLCEfa026913; Wed, 13 Sep 2006 14:12:14 -0700 Date: Wed, 13 Sep 2006 14:12:14 -0700 Message-Id: <200609132112.k8DLCEfa026913@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 4614 on A Roadmap for Transmission Control Protocol (TCP) Specification Documents X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4614 Title: A Roadmap for Transmission Control Protocol (TCP) Specification Documents Author: M. Duke, R. Braden, W. Eddy, E. Blanton Status: Informational Date: September 2006 Mailbox: martin.duke@boeing.com, braden@isi.edu, weddy@grc.nasa.gov, eblanton@cs.purdue.edu Pages: 33 Characters: 75645 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-tcp-roadmap-06.txt URL: http://www.rfc-editor.org/rfc/rfc4614.txt This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This memo provides information for the Internet community. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 13 17:18:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNc7u-0004lC-JZ; Wed, 13 Sep 2006 17:18:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNc7t-0004ks-6m for tcpm@ietf.org; Wed, 13 Sep 2006 17:18:33 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNc7i-0002PX-Lg for tcpm@ietf.org; Wed, 13 Sep 2006 17:18:33 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Wed, 13 Sep 2006 14:18:13 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 28B1E2AF; Wed, 13 Sep 2006 14:18:13 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 02BC32AE; Wed, 13 Sep 2006 14:18:12 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EEZ77881; Wed, 13 Sep 2006 14:18:10 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 3CFE320501; Wed, 13 Sep 2006 14:18:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-03.txt Date: Wed, 13 Sep 2006 14:18:09 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F196420B@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <41E932BF-B860-4AC8-9370-F240D33155CE@netlab.nec.de> Thread-Topic: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-03.txt Thread-Index: AcbXKcBCPtp/UrhqR1SOa6qvmdlVgAAT7wDw From: "Caitlin Bestler" To: "Lars Eggert" , tcpm@ietf.org X-TMWD-Spam-Summary: TS=20060913211814; SEV=2.0.2; DFV=A2006091308; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230342E34353038373345302E303032342D412D; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: A2006091308_4.00.0004_4.0-8 X-WSS-ID: 6916AA1F2301043157-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Godred Fairhurst X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Lars Eggert wrote: > Hi, >=20 > On Jul 20, 2006, at 0:50, > wrote: >> Title : TCP User Timeout Option >> Author(s) : L. Eggert, F. Gont >> Filename : draft-ietf-tcpm-tcp-uto-03.txt >=20 > we haven't received any comments on this last version, which > attempts to address the review comments from Gorry and others on -02. >=20 > Could I ask the WG to take a look and see if it is happy with > this revision? >=20 At the time that the passive side responds to a SYN request the allocated resource, if any, might not be capable of recording the remote peer's hint. A statement that the passive side MAY ignore the UTO option on a SYN is of course unneeded, since the draft is quite clear that either side MAY ignore the UTO option on any packet. But it might be useful to suggest that the active side SHOULD provide the initial UTO in the first non-SYN rather than assuming it was remembered from the SYN. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 13 17:47:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNcZJ-0001gG-E2; Wed, 13 Sep 2006 17:46:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNcZH-0001g1-SE for tcpm@ietf.org; Wed, 13 Sep 2006 17:46:51 -0400 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNcZF-0003o4-CK for tcpm@ietf.org; Wed, 13 Sep 2006 17:46:51 -0400 Received: (qmail 24958 invoked from network); 13 Sep 2006 21:30:12 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Sep 2006 21:30:12 -0000 Message-ID: <45087C3A.4000602@freebsd.org> Date: Wed, 13 Sep 2006 23:46:34 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [tcpm] FYI: Extended TCP syncookies in FreeBSD-current X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I have committed an extended version of TCP syncookies to FreeBSD-current today. FreeBSD-current the development version which will become the new stable FreeBSD 7.0 platform by mid of next year. This gives plenty of time to shake out bugs and problems. The main addition is the use of the RFC1323 timestamp field to store additional state (send/receive windows, SACK allowed) allowing the full setup of an syncookie accepted connection. Read for yourself the comments replicated from the source code. Any comments and problem reports of the theory or implementation welcome. /* * The purpose of SYN cookies is to avoid keeping track of all SYN's we * receive and to be able to handle SYN floods from bogus source addresses * (where we will never receive any reply). SYN floods try to exhaust all * our memory and available slots in the SYN cache table to cause a denial * of service to legitimate users of the local host. * * The idea of SYN cookies is to encode and include all necessary information * about the connection setup state within the SYN-ACK we send back and thus * to get along without keeping any local state until the ACK to the SYN-ACK * arrives (if ever). Everything we need to know should be available from * the information we encoded in the SYN-ACK. * * More information about the theory behind SYN cookies and its first * discussion and specification can be found at: * http://cr.yp.to/syncookies.html (overview) * http://cr.yp.to/syncookies/archive (gory details) * * This implementation extends the orginal idea and first implementation * of FreeBSD by using not only the initial sequence number field to store * information but also the timestamp field if present. This way we can * keep track of the entire state we need to know to recreate the session in * its original form. Almost all TCP speakers implement RFC1323 timestamps * these days. For those that do not we still have to live with the known * shortcomings of the ISN only SYN cookies. * * Cookie layers: * * Initial sequence number we send: * 31|................................|0 * DDDDDDDDDDDDDDDDDDDDDDDDDMMMRRRP * D = MD5 Digest (first dword) * M = MSS index * R = Rotation of secret * P = Odd or Even secret * * The MD5 Digest is computed with over following parameters: * a) randomly rotated secret * b) struct in_conninfo containing the remote/local ip/port (IPv4&IPv6) * c) the received initial sequence number from remote host * d) the rotation offset and odd/even bit * * Timestamp we send: * 31|................................|0 * DDDDDDDDDDDDDDDDDDDDDDSSSSRRRRA5 * D = MD5 Digest (third dword) (only as filler) * S = Requested send window scale * R = Requested receive window scale * A = SACK allowed * 5 = TCP-MD5 enabled (not implemented yet) * XORed with MD5 Digest (forth dword) * * The timestamp isn't cryptographically secure and doesn't need to be. * The double use of the MD5 digest dwords ties it to a specific remote/ * local host/port, remote initial sequence number and our local time * limited secret. A received timestamp is reverted (XORed) and then * the contained MD5 dword is compared to the computed one to ensure the * timestamp belongs to the SYN-ACK we sent. The other parameters may * have been tampered with but this isn't different from supplying bogus * values in the SYN in the first place. * * Some problems with SYN cookies remain however: * Consider the problem of a recreated (and retransmitted) cookie. If the * original SYN was accepted, the connection is established. The second * SYN is inflight, and if it arrives with an ISN that falls within the * receive window, the connection is killed. * * Notes: * A heuristic to determine when to accept syn cookies is not necessary. * An ACK flood would cause the syncookie verification to be attempted, * but a SYN flood causes syncookies to be generated. Both are of equal * cost, so there's no point in trying to optimize the ACK flood case. * Also, if you don't process certain ACKs for some reason, then all someone * would have to do is launch a SYN and ACK flood at the same time, which * would stop cookie verification and defeat the entire purpose of syncookies. */ The actual implementation source code provides additional hints: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c?rev=1.99&content-type=text/x-cvsweb-markup -- Andre andre@freebsd.org FreeBSD Developer _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 15 06:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOBGi-0008UY-0z; Fri, 15 Sep 2006 06:50:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOBGg-0008PZ-93 for tcpm@ietf.org; Fri, 15 Sep 2006 06:49:58 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOBGd-0006x9-58 for tcpm@ietf.org; Fri, 15 Sep 2006 06:49:58 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2DA0DF0C562; Fri, 15 Sep 2006 07:52:40 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k8FAmisa029402; Fri, 15 Sep 2006 07:49:25 -0300 Message-Id: <7.0.1.0.0.20060915053023.06212108@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 15 Sep 2006 05:39:17 -0300 To: "Caitlin Bestler" , "Lars Eggert" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-03.txt In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F196420B@NT-SJCA-0751.brcm.a d.broadcom.com> References: <41E932BF-B860-4AC8-9370-F240D33155CE@netlab.nec.de> <54AD0F12E08D1541B826BE97C98F99F196420B@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.9 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Godred Fairhurst X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 18:18 13/09/2006, Caitlin Bestler wrote: >At the time that the passive side responds to a SYN request >the allocated resource, if any, might not be capable of recording >the remote peer's hint. You mean, eg., an implementation of SYN cookies? >A statement that the passive side MAY ignore the UTO option on >a SYN is of course unneeded, since the draft is quite clear >that either side MAY ignore the UTO option on any packet. > >But it might be useful to suggest that the active side >SHOULD provide the initial UTO in the first non-SYN >rather than assuming it was remembered from the SYN. Makes sense to me. (I was just about to say that with SYN cookies in place, there are lots of enhancements that are lost... but I just read Andre's post, so... ;-) ) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 15 11:56:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOG2S-0002EW-6f; Fri, 15 Sep 2006 11:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOG2Q-0002E2-M1 for tcpm@ietf.org; Fri, 15 Sep 2006 11:55:34 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOG2O-0004A7-9S for tcpm@ietf.org; Fri, 15 Sep 2006 11:55:34 -0400 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 15 Sep 2006 08:55:15 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 257522AF; Fri, 15 Sep 2006 08:55:15 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id F3A202AE; Fri, 15 Sep 2006 08:55:14 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EFD30789; Fri, 15 Sep 2006 08:55:14 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 15C0620502; Fri, 15 Sep 2006 08:55:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-03.txt Date: Fri, 15 Sep 2006 08:55:08 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1964438@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <7.0.1.0.0.20060915053023.06212108@gont.com.ar> Thread-Topic: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-03.txt Thread-Index: AcbYtLh2BhAqdYYKQYylQTD7ryYm9wAKf+rg From: "Caitlin Bestler" To: "Fernando Gont" , "Lars Eggert" , tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006091505; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230352E34353041434232312E303035422D412D; ENG=IBF; TS=20060915155518; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006091505_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 691413693CC7166941-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Godred Fairhurst X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > At 18:18 13/09/2006, Caitlin Bestler wrote: >=20 >> At the time that the passive side responds to a SYN request the >> allocated resource, if any, might not be capable of recording the >> remote peer's hint. >=20 > You mean, eg., an implementation of SYN cookies? >=20 >=20 The passive side naturally seeks economy in the representation of potential-connection state in response to a single SYN packet that has not yet been otherwise validated. SYN Cookies are just one method of doing so. Whatever method is used, it is preferable from a protocol viewpoint to minimize adding to the information that should be retained in this state. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Sep 18 16:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQAt-0002XD-RF; Mon, 18 Sep 2006 16:57:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPQAr-0002X8-UD for tcpm@ietf.org; Mon, 18 Sep 2006 16:57:05 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPQAq-00030o-HV for tcpm@ietf.org; Mon, 18 Sep 2006 16:57:05 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id E25A4F0C497; Mon, 18 Sep 2006 18:00:27 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k8IKsYw9003939; Mon, 18 Sep 2006 17:56:52 -0300 Message-Id: <7.0.1.0.0.20060918172739.07aa7930@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 18 Sep 2006 17:31:00 -0300 To: "Caitlin Bestler" , "Lars Eggert" , tcpm@ietf.org From: Fernando Gont Subject: RE: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-03.txt In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1964438@NT-SJCA-0751.brcm.a d.broadcom.com> References: <7.0.1.0.0.20060915053023.06212108@gont.com.ar> <54AD0F12E08D1541B826BE97C98F99F1964438@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Godred Fairhurst X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 12:55 15/09/2006, Caitlin Bestler wrote: >The passive side naturally seeks economy in the representation >of potential-connection state in response to a single SYN >packet that has not yet been otherwise validated. I think this is a good principle to follow. However, I'm not sure this principle is currently followed by TCP, though. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 20 12:08:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4bC-0005Jo-7t; Wed, 20 Sep 2006 12:06:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4bA-0005Jj-UC for tcpm@ietf.org; Wed, 20 Sep 2006 12:06:56 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ4b9-0006M1-GC for tcpm@ietf.org; Wed, 20 Sep 2006 12:06:56 -0400 Received: from [139.133.207.157] (dhcp-207-157.erg.abdn.ac.uk [139.133.207.157]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k8KG6UZt003521; Wed, 20 Sep 2006 17:06:30 +0100 (BST) Message-ID: <45116707.9050301@erg.abdn.ac.uk> Date: Wed, 20 Sep 2006 17:06:31 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> In-Reply-To: <43A02978.4020809@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Lars Eggert , tcpm@ietf.org, Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando, Thanks for generating a new revision, and appologies for taking a little while to get back to you on the changes that you made. It seems you have responded to most (if not all) my substantial comments, and also tightened the language, I like these improvements, and to me, this seems much safer in this respect. I would like to check one point: Section 3.1: /Very short user timeout values can affect TCP transmissions over high-delay paths. If the user timeout occurs before an acknowledgment for an outstanding segment arrives, possibly due to ..../ - This rev of the draft also includes a change to mandate the minimum value to be at least the RTO value, which should at least help in this case? and note two minor NiTs below. Best wishes, Gorry --- End of section 1: I think phrase below is good guidance, but could be strengthened: /If such a system-wide toggle were provided, it would default to "off". Perhaps some text something like: An implementation that provides a system-wide toggle, should assign the default value to disable this feature. --- /It must be noted that the two endpoints of the connection will not necesarilly adopt the same user timeout./ - Could be better worded, but agreed. ---- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 21 11:04:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQQ5L-0000oP-CP; Thu, 21 Sep 2006 11:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQQ5K-0000oE-AF for tcpm@ietf.org; Thu, 21 Sep 2006 11:03:30 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQQ58-00072S-Fb for tcpm@ietf.org; Thu, 21 Sep 2006 11:03:30 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A6684115BAF7; Thu, 21 Sep 2006 12:06:48 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k8LF310d028042; Thu, 21 Sep 2006 12:03:01 -0300 Message-Id: <7.0.1.0.0.20060920170030.05da7c80@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 20 Sep 2006 17:23:44 -0300 To: gorry@erg.abdn.ac.uk, gorry@erg.abdn.ac.uk From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: <45116707.9050301@erg.abdn.ac.uk> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> <45116707.9050301@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Lars Eggert , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Gorry, Thanks so much for your comments. You'll find my responses inline.... >It seems you have responded to most (if not all) my substantial >comments, and also tightened the >language, I like these improvements, and to me, this seems much >safer in this respect. > >I would like to check one point: >Section 3.1: > >/Very short user timeout values can affect TCP transmissions over >high-delay paths. If the user timeout occurs before an >acknowledgment for an outstanding segment arrives, possibly due to ..../ > >- This rev of the draft also includes a change to mandate >the minimum value to be at least the RTO value, which should at >least help in this case? Agreed. However, the document argues to enforce a minimum *L_LIMIT* value of at least one RTO, with L_LIMIT being a parameter of the RECOMMENDED (ie, not mandatory) scheme for selecting the user timeout. So two possible ways to fix this would be: a) State that the minimum allowed value for the user timeout is one RTO (in any case.... not just in the recommended scheme) b) Make the recommended scheme mandatory. I would personally argue in favour of (a). But well, opinions are welcome. >End of section 1: > >I think phrase below is good guidance, but could be strengthened: >/If such a system-wide toggle were provided, it would default to "off". > >Perhaps some text something like: > >An implementation that provides a system-wide toggle, should assign >the default value to disable this feature. How about: "An implementation that provides a system-wide toggle, SHOULD assign the default value to disable this feature" (ie, RFC2119 speak) >/It must be noted that the two endpoints of the connection will not >necesarilly adopt the same user timeout./ > >- Could be better worded, but agreed. Any suggestions? Thanks so much! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 22 00:05:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQcHH-0003tG-GX; Fri, 22 Sep 2006 00:04:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQcHG-0003t4-3n for tcpm@ietf.org; Fri, 22 Sep 2006 00:04:38 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQcHE-0006o3-OE for tcpm@ietf.org; Fri, 22 Sep 2006 00:04:38 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id k8M44FqA006199; Thu, 21 Sep 2006 21:04:15 -0700 (PDT) Message-ID: <451360BE.20608@isi.edu> Date: Thu, 21 Sep 2006 21:04:14 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> <45116707.9050301@erg.abdn.ac.uk> <7.0.1.0.0.20060920170030.05da7c80@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060920170030.05da7c80@gont.com.ar> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: gorry@erg.abdn.ac.uk, Lars Eggert , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1888029575==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1888029575== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig087091911DC12B584321D639" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig087091911DC12B584321D639 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =2E.. >> An implementation that provides a system-wide toggle, should assign >> the default value to disable this feature. >=20 > How about: > "An implementation that provides a system-wide toggle, SHOULD assign th= e > default value to disable this feature" > (ie, RFC2119 speak) It would be useful to omit the comma. It doesn't parse otherwise ;-) "An implementation that provides a system-wide toggle SHOULD assign the default value to disable this feature" However, this still reads oddly; I'd prefer: "If an implementation provides a system-wide toggle to enable/disable UTO, that toggle SHOULD be initialized to disable UTO." Joe --------------enig087091911DC12B584321D639 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFE2C+E5f5cImnZrsRAitKAJ47DCQ1lX3vUfKSppGHSC72kFofzACdFS+f f5LuAZPdsRW851xyibGbEJM= =E1Nv -----END PGP SIGNATURE----- --------------enig087091911DC12B584321D639-- --===============1888029575== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1888029575==-- From tcpm-bounces@ietf.org Fri Sep 22 08:25:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk5Y-0006Iz-Jf; Fri, 22 Sep 2006 08:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQk5X-0006Iu-Vu for tcpm@ietf.org; Fri, 22 Sep 2006 08:25:03 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQk5U-0003Wi-RO for tcpm@ietf.org; Fri, 22 Sep 2006 08:25:03 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 1973CF0C51E; Fri, 22 Sep 2006 09:28:50 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k8MCOroL011647; Fri, 22 Sep 2006 09:24:55 -0300 Message-Id: <7.0.1.0.0.20060922083417.066de878@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 22 Sep 2006 08:35:46 -0300 To: Joe Touch From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: <451360BE.20608@isi.edu> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> <45116707.9050301@erg.abdn.ac.uk> <7.0.1.0.0.20060920170030.05da7c80@gont.com.ar> <451360BE.20608@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: gorry@erg.abdn.ac.uk, Lars Eggert , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 01:04 22/09/2006, Joe Touch wrote: >"An implementation that provides a system-wide toggle SHOULD assign the > default value to disable this feature" > >However, this still reads oddly; I'd prefer: > >"If an implementation provides a system-wide toggle to enable/disable >UTO, that toggle SHOULD be initialized to disable UTO." Okay, taken. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Sep 22 09:06:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQkiy-00006y-2e; Fri, 22 Sep 2006 09:05:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQkiw-00005w-3X for tcpm@ietf.org; Fri, 22 Sep 2006 09:05:46 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQkiu-0008Bf-ML for tcpm@ietf.org; Fri, 22 Sep 2006 09:05:46 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 3672AF0C3F1 for ; Fri, 22 Sep 2006 10:09:38 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k8MD5e0H024337 for ; Fri, 22 Sep 2006 10:05:44 -0300 Message-Id: <7.0.1.0.0.20060922095541.07838cf8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 22 Sep 2006 10:00:13 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [tcpm] TCP soft errors draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, Last month I posted a revision of the "TCP's reaction to soft errors" draft. The revised draft addresses the feedback from Ron Bonica (which had agreed at the 65th IETF to review the draft). I'd appreciate any input on this last revision. The draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-01.txt Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Sep 26 12:44:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSG1M-0003kO-03; Tue, 26 Sep 2006 12:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSG1K-0003kJ-Di for tcpm@ietf.org; Tue, 26 Sep 2006 12:42:58 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSG1I-0006Wn-Ui for tcpm@ietf.org; Tue, 26 Sep 2006 12:42:58 -0400 Received: from [139.133.207.154] (dhcp-207-154.erg.abdn.ac.uk [139.133.207.154]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k8QGgLTa025266; Tue, 26 Sep 2006 17:42:22 +0100 (BST) Message-ID: <4519586D.1080509@erg.abdn.ac.uk> Date: Tue, 26 Sep 2006 17:42:21 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> <45116707.9050301@erg.abdn.ac.uk> <7.0.1.0.0.20060920170030.05da7c80@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060920170030.05da7c80@gont.com.ar> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Lars Eggert , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Gont wrote: > Gorry, > > Thanks so much for your comments. You'll find my responses inline.... > > >> It seems you have responded to most (if not all) my substantial >> comments, and also tightened the >> language, I like these improvements, and to me, this seems much safer >> in this respect. >> >> I would like to check one point: >> Section 3.1: >> >> /Very short user timeout values can affect TCP transmissions over >> high-delay paths. If the user timeout occurs before an >> acknowledgment for an outstanding segment arrives, possibly due to ..../ >> >> - This rev of the draft also includes a change to mandate the minimum >> value to be at least the RTO value, which should at least help in this >> case? > > > Agreed. However, the document argues to enforce a minimum *L_LIMIT* > value of at least one RTO, with L_LIMIT being a parameter of the > RECOMMENDED (ie, not mandatory) scheme for selecting the user timeout. > > So two possible ways to fix this would be: > > a) State that the minimum allowed value for the user timeout is one RTO > (in any case.... not just in the recommended scheme) > b) Make the recommended scheme mandatory. > > I would personally argue in favour of (a). But well, opinions are welcome. > > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > It is only necessary to mandate an algorithm, if things break without it. This doesn't seem to be what you are saying, so I'd suggest (a) too. I'd prefer to say that the used value MUST be larger than the measured RTO. So does that imply if RTO increases above the current user time out that something needs to happen, we need to get the correct language here. Any suggestions? Gorry _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 27 23:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmGB-0005pM-KP; Wed, 27 Sep 2006 23:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmGB-0005pC-1y for tcpm@ietf.org; Wed, 27 Sep 2006 23:08:27 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSmG8-0008UQ-LY for tcpm@ietf.org; Wed, 27 Sep 2006 23:08:27 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5EA54F0C9D3 for ; Thu, 28 Sep 2006 00:13:01 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k8S38IeY011125 for ; Thu, 28 Sep 2006 00:08:28 -0300 Message-Id: <7.0.1.0.0.20060927231914.08095ec0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 27 Sep 2006 23:28:10 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [tcpm] UTO: SHOULD send option in first segment after the SYN? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, Caitlin Bestler proposed that a host implementing the UTO SHOULD send an UTO on the first (data?) packet after the SYN. This avoids requiring systems to keep UTO-related information for connections that have not yet been established. And would likely make things work better in the presence of mechanisms such as SYN cookies. We would like to hear what others think on this issue. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 27 23:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmGB-0005pH-FE; Wed, 27 Sep 2006 23:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmGA-0005p7-HK for tcpm@ietf.org; Wed, 27 Sep 2006 23:08:26 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSmG8-0008UO-3b for tcpm@ietf.org; Wed, 27 Sep 2006 23:08:26 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 6160AF0C92F; Thu, 28 Sep 2006 00:13:00 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k8S38IeW011125; Thu, 28 Sep 2006 00:08:25 -0300 Message-Id: <7.0.1.0.0.20060927230203.08077e98@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 27 Sep 2006 23:15:11 -0300 To: gorry@erg.abdn.ac.uk From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: <4519586D.1080509@erg.abdn.ac.uk> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> <45116707.9050301@erg.abdn.ac.uk> <7.0.1.0.0.20060920170030.05da7c80@gont.com.ar> <4519586D.1080509@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Lars Eggert , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 13:42 26/09/2006, Gorry Fairhurst wrote: >It is only necessary to mandate an algorithm, if things break >without it. This doesn't seem to be what you are saying, so I'd >suggest (a) too. Agreed. Will update the draft accordingly, then. >I'd prefer to say that the used value MUST be larger than the >measured RTO. So does that imply if RTO increases above the current >user time out that something needs to happen, we need to get the >correct language here. Any suggestions? I think there are two possible ways to go here: a) Enforcing a minimum UTO of a RTO only when *choosing* the UTO. (i., connections establishment, API call from the application, or receipt of an UTO from the remote endpoint). After all, the UTO is meant more to increase the User Timeout than to decrease it (therefore, users are expected to use long UTOs, rather than short ones). And this keeps things simple... b) Everytime the RTO is updated, it should be rounded to the next higher value in seconds. If the current User Timeout is less than this value, the User Timeout should be updated, and an UTO should be sent to the remote TCP endpoint. This is probably "the right thing to do". But makes things a little more complicated. Any thoughts? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 27 23:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmGB-0005pM-KP; Wed, 27 Sep 2006 23:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmGB-0005pC-1y for tcpm@ietf.org; Wed, 27 Sep 2006 23:08:27 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSmG8-0008UQ-LY for tcpm@ietf.org; Wed, 27 Sep 2006 23:08:27 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5EA54F0C9D3 for ; Thu, 28 Sep 2006 00:13:01 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k8S38IeY011125 for ; Thu, 28 Sep 2006 00:08:28 -0300 Message-Id: <7.0.1.0.0.20060927231914.08095ec0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 27 Sep 2006 23:28:10 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [tcpm] UTO: SHOULD send option in first segment after the SYN? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, Caitlin Bestler proposed that a host implementing the UTO SHOULD send an UTO on the first (data?) packet after the SYN. This avoids requiring systems to keep UTO-related information for connections that have not yet been established. And would likely make things work better in the presence of mechanisms such as SYN cookies. We would like to hear what others think on this issue. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Sep 27 23:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmGB-0005pH-FE; Wed, 27 Sep 2006 23:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSmGA-0005p7-HK for tcpm@ietf.org; Wed, 27 Sep 2006 23:08:26 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSmG8-0008UO-3b for tcpm@ietf.org; Wed, 27 Sep 2006 23:08:26 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 6160AF0C92F; Thu, 28 Sep 2006 00:13:00 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k8S38IeW011125; Thu, 28 Sep 2006 00:08:25 -0300 Message-Id: <7.0.1.0.0.20060927230203.08077e98@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 27 Sep 2006 23:15:11 -0300 To: gorry@erg.abdn.ac.uk From: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 In-Reply-To: <4519586D.1080509@erg.abdn.ac.uk> References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> <45116707.9050301@erg.abdn.ac.uk> <7.0.1.0.0.20060920170030.05da7c80@gont.com.ar> <4519586D.1080509@erg.abdn.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Lars Eggert , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 13:42 26/09/2006, Gorry Fairhurst wrote: >It is only necessary to mandate an algorithm, if things break >without it. This doesn't seem to be what you are saying, so I'd >suggest (a) too. Agreed. Will update the draft accordingly, then. >I'd prefer to say that the used value MUST be larger than the >measured RTO. So does that imply if RTO increases above the current >user time out that something needs to happen, we need to get the >correct language here. Any suggestions? I think there are two possible ways to go here: a) Enforcing a minimum UTO of a RTO only when *choosing* the UTO. (i., connections establishment, API call from the application, or receipt of an UTO from the remote endpoint). After all, the UTO is meant more to increase the User Timeout than to decrease it (therefore, users are expected to use long UTOs, rather than short ones). And this keeps things simple... b) Everytime the RTO is updated, it should be rounded to the next higher value in seconds. If the current User Timeout is less than this value, the User Timeout should be updated, and an UTO should be sent to the remote TCP endpoint. This is probably "the right thing to do". But makes things a little more complicated. Any thoughts? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 28 16:47:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT2m8-0000D6-AY; Thu, 28 Sep 2006 16:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT2m6-0000CZ-RU for tcpm@ietf.org; Thu, 28 Sep 2006 16:46:30 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT2m5-0005P1-95 for tcpm@ietf.org; Thu, 28 Sep 2006 16:46:30 -0400 Received: from [139.133.207.154] (dhcp-207-154.erg.abdn.ac.uk [139.133.207.154]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k8SKjnjK021024; Thu, 28 Sep 2006 21:45:49 +0100 (BST) Message-ID: <451C347D.3030200@erg.abdn.ac.uk> Date: Thu, 28 Sep 2006 21:45:49 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] UTO: SHOULD send option in first segment after the SYN? References: <7.0.1.0.0.20060927231914.08095ec0@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060927231914.08095ec0@gont.com.ar> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Is it OK to set the option in a later segment, when the option was not first negotiated in a SYN? Gorry Fernando Gont wrote: > Folks, > > Caitlin Bestler proposed that a host implementing the UTO SHOULD send > an UTO on the first (data?) packet after the SYN. > > This avoids requiring systems to keep UTO-related information for > connections that have not yet been established. > And would likely make things work better in the presence of mechanisms > such as SYN cookies. > > We would like to hear what others think on this issue. > > Thanks! > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 28 17:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT39s-0005ma-SP; Thu, 28 Sep 2006 17:11:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT39q-0005kA-KD for tcpm@ietf.org; Thu, 28 Sep 2006 17:11:02 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT39G-0001Ep-JK for tcpm@ietf.org; Thu, 28 Sep 2006 17:10:27 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Thu, 28 Sep 2006 14:10:15 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 405FB2AF; Thu, 28 Sep 2006 14:10:15 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 177B72AE; Thu, 28 Sep 2006 14:10:15 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EGC81040; Thu, 28 Sep 2006 14:10:12 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 59E2320502; Thu, 28 Sep 2006 14:10:12 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] UTO: SHOULD send option in first segment after the SYN? Date: Thu, 28 Sep 2006 14:10:11 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1A315F2@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <451C347D.3030200@erg.abdn.ac.uk> Thread-Topic: [tcpm] UTO: SHOULD send option in first segment after the SYN? Thread-Index: AcbjP2GH15uVo2q1SgaLiq+5kJ6SJgAAUkgw From: "Caitlin Bestler" To: gorry@erg.abdn.ac.uk, "Fernando Gont" X-TMWD-Spam-Summary: TS=20060928211017; SEV=2.0.2; DFV=A2006092806; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230332E34353143334132422E303031322D412D; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: A2006092806_4.00.0004_4.0-8 X-WSS-ID: 6902E5BD1MO281859-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Gorry Fairhurst wrote: > Is it OK to set the option in a later segment, when the > option was not first negotiated in a SYN? >=20 As I understand UTO, it is not a "negotiation": > Note that an exchange of TCP User Timeout Options between peers is > not a binding negotiation. Transmission of a TCP User Timeout Option > is an advisory suggestion that the peer consider adapting its local > user timeout. And more to the point: > A host that supports the TCP User Timeout Option SHOULD include one > in each packet that carries a SYN flag, but need not. [MEDINA] has > shown that unknown options are correctly handled by the vast majority > of modern TCP stacks. It is thus not necessary to require > negotiation of the use of the TCP User Timeout Option during the > three-way handshake of a connection. However, including a TCP User > Timeout Option in each segment that has the SYN flag set will result > in TCP being able to adopt a user timeout with knowledge of that used > by the peer TCP, since the beginning of the data transfer phase. The connection initiating SYN packet is not really a part of the data transfer phase, and connection related timers are not necessarily identical from the state where only a SYN has been received to after the connection is fully established. SYN Cookies are just one implementation strategy where the distinction between these states is extremely obvious. Given that there is no need to pre-validate support for UTO, and that the suggestion UTO value may be ignored on a SYN, I think placing the initial UTO value on the first data carrying packet makes more sense. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Sep 28 17:17:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT3G8-0000Z3-Px; Thu, 28 Sep 2006 17:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT3AI-0005xg-25 for tcpm@ietf.org; Thu, 28 Sep 2006 17:11:30 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT2wF-0007T4-6i for tcpm@ietf.org; Thu, 28 Sep 2006 16:56:59 -0400 Received: from [139.133.207.154] (dhcp-207-154.erg.abdn.ac.uk [139.133.207.154]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k8SKuULU021757; Thu, 28 Sep 2006 21:56:30 +0100 (BST) Message-ID: <451C36FF.3000801@erg.abdn.ac.uk> Date: Thu, 28 Sep 2006 21:56:31 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-tcp-uto-02 References: <6.2.0.14.0.20051201035418.0323fc48@localhost> <4390569C.6050004@erg.abdn.ac.uk> <6.2.0.14.0.20051202201002.048b5de8@localhost> <20051208222808.GB22920@hut.isi.edu> <6.2.0.14.0.20051208164304.041ead70@localhost> <20051209182531.GC1177@hut.isi.edu> <439D7400.20902@erg.abdn.ac.uk> <20051212235603.GB1156@hut.isi.edu> <6.2.0.14.0.20051213012758.048ed298@localhost> <43A02978.4020809@erg.abdn.ac.uk> <45116707.9050301@erg.abdn.ac.uk> <7.0.1.0.0.20060920170030.05da7c80@gont.com.ar> <4519586D.1080509@erg.abdn.ac.uk> <7.0.1.0.0.20060927230203.08077e98@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060927230203.08077e98@gont.com.ar> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Lars Eggert , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org You're correct. My concern on this issue was always what happened when a host used first a short delay path and an app chose a short UTO. The host/path then changed to to one that had very significant delay. So, I believe that (a) is a MUST - things break quickly if you do this, and it should not be made this way. (b) Seems perfectly valid, but could be troublesome to mandate to implement. So... just to backtrack to an earlier discussion on this: Using the recommended algorithm you say" Consequently, the lower limit (L_LIMIT) SHOULD be set to at least 100 seconds." Is there a reason why we don't specify a required minimum UTO value for all cases? A value of 100 seconds seems big for an RTO, over a normal Internet path. Gorry Fernando Gont wrote: > At 13:42 26/09/2006, Gorry Fairhurst wrote: > >> It is only necessary to mandate an algorithm, if things break without >> it. This doesn't seem to be what you are saying, so I'd suggest (a) too. > > > Agreed. Will update the draft accordingly, then. > > >> I'd prefer to say that the used value MUST be larger than the measured >> RTO. So does that imply if RTO increases above the current user time >> out that something needs to happen, we need to get the correct >> language here. Any suggestions? > > > I think there are two possible ways to go here: > > a) Enforcing a minimum UTO of a RTO only when *choosing* the UTO. (i., > connections establishment, API call from the application, or receipt of > an UTO from the remote endpoint). After all, the UTO is meant more to > increase the User Timeout than to decrease it (therefore, users are > expected to use long UTOs, rather than short ones). And this keeps > things simple... > > b) Everytime the RTO is updated, it should be rounded to the next higher > value in seconds. If the current User Timeout is less than this value, > the User Timeout should be updated, and an UTO should be sent to the > remote TCP endpoint. This is probably "the right thing to do". But makes > things a little more complicated. > > Any thoughts? > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm