From micchie@sfc.wide.ad.jp Sat Oct 2 16:30:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780D83A6CED; Sat, 2 Oct 2010 16:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.763 X-Spam-Level: ** X-Spam-Status: No, score=2.763 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Nr5Dv+SHpvW; Sat, 2 Oct 2010 16:30:22 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 7A64A3A6D77; Sat, 2 Oct 2010 16:30:22 -0700 (PDT) Received: from [192.168.0.100] (cpc10-dals15-2-0-cust3.hari.cable.virginmedia.com [62.31.43.4]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C93BA2780AF; Sun, 3 Oct 2010 08:31:01 +0900 (JST) From: Michio Honda Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Oct 2010 00:30:57 +0100 Message-Id: <985BFFF5-B9DB-4F68-8837-24E434FD08AD@sfc.wide.ad.jp> To: Multipath TCP Mailing List , tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: Mark Handley Subject: [tcpm] Call for contribution to middlebox survey X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 02 Oct 2010 23:30:24 -0000 Hi,=20 We are surveying middleboxes affecting TCP in the Internet, and we'd = like you to contribute to this work by running 1 python script at your = available networks, because we want data of as many paths as possible. = =20 This script generates test TCP traffic to a server node, and detects = various middlebox behavior, for example, it detects how unknown TCP = options are treated and if sequence number is rewritten. =20 - Overview of script This generates test TCP traffic by using raw socket or pcap.=20 Destinations of the test traffic are port 80, 443 and 34343 on = vinson3.sfc.wide.ad.jp, which is located in Japan.=20 The total amount of test traffic is approximately 90 connections (not = parallel), and each of them uses approximately maximum 2048Byte. =20 - System requirement Our script works on Mac OSX 10.5 or 10.6, Linux (kernel 2.6) and FreeBSD = (7.0 or higher). This also requires python 2.5 or higher, and libpcap NOTE. if you try in a virtual machine on Windows, please connect the = guest OS via not NAT but bridge. =20 How to run experiment is described below per-OS basis. =20 After the experiment, you will find 3 log files (logxxxxxxxxx.txt) in = the same directory as the experiment. =20 Please send them to us (micchie@sfc.wide.ad.jp) and tell me your network = information as much as you know (e.g., product name of the broadband = router, ISP name, product name of firewall appliance etc...)=20 In addition, let us know if you have hesitation to open these = information. =20 This experiment doesn't collect traffic information other than those our = script generated. =20 ***** How to run the experiment (Mac OSX) ***** 1. Filtering RST TCP segment from OS Execute a following command by root: ipfw add 101 deny tcp from any to vinson3.sfc.wide.ad.jp dst-port = 34343,80,443 tcpflags rst NOTE: if you are already running ipfw, please add equivalent rules After the experiment, you can revert by "ipfw delete 101" 2. Executing script Download script from = http://www.micchie.net/software/tcpexposure/for_distrib.tar.gz, and = decompress it to anywhere you like (e.g., tar xzf for_distrib.tar.gz by = command line) In the for_distrib directory, execute a following command by root: sh run-bsd2.sh (This will take approximately 30 min.) ***** How to run the experiment (Linux) ***** 1. Filtering RST TCP segment from OS Execute following command by root: /sbin/iptables -A OUTPUT -p tcp -d vinson3.sfc.wide.ad.jp --tcp-flags = RST RST -m multiport --dports 34343,80,443 -j DROP NOTE: if you are already running iptables, please add equivalent rules After the experiment, you can revert by opposite commands - using -D = instead of -A 2. Executing script Download script from = http://www.micchie.net/software/tcpexposure/for_distrib.tar.gz, and = decompress it to anywhere you like (e.g., tar xzf for_distrib.tar.gz) In the for_distrib directory, execute a following command by root: sh run-linux2.sh (This will take approximately 30 min.) ***** How to run the script (FreeBSD) ***** 1. Filtering RST TCP segment from OS =20 If you are using neither ipfw nor pf:=20 Load pf kernel module with a following command by root: kldload /boot/kernel/pf.ko Add following 2 lines to /etc/pf.conf (please replace IFNAME to your = outgoing interface name (e.g., em0): pass out all block out quick on IFNAME proto tcp to vinson3.sfc.wide.ad.jp port = {34343,80,443} flags R/R Execute following command by root: pfctl -e -f /etc/pf.conf If you are already running pf, please add equivalent rules After the experiment, you can revert settings by cleaning up = /etc/pf.conf and executing "pfctl -d" by root If you are already using ipfw: Please add a following rule to ipfw configuration: deny tcp from any to vinson3.sfc.wide.ad.jp dst-port 34343,80,443 = tcpflags rst 2. Executing script Download script from = http://www.micchie.net/software/tcpexposure/for_distrib.tar.gz, and = decompress it to anywhere you like (e.g., tar xzf for_distrib.tar.gz) In the for_distrib directory, execute a following command by root: sh run-bsd2.sh (This will take approximately 30 min.) Best regards, - Michio From lars.eggert@nokia.com Tue Oct 5 01:32: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 5E5673A6EE4 for ; Tue, 5 Oct 2010 01:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.218 X-Spam-Level: X-Spam-Status: No, score=-103.218 tagged_above=-999 required=5 tests=[AWL=-0.619, 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 7dQoKpqYLv+u for ; Tue, 5 Oct 2010 01:32:11 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 06D513A6E2C for ; Tue, 5 Oct 2010 01:32:10 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o958X71u022447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Oct 2010 11:33:07 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-133-870218580; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> Date: Tue, 5 Oct 2010 10:33:00 +0200 Message-Id: <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> To: Ronald Bonica , Jari Arkko X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 05 Oct 2010 11:33:01 +0300 (EEST) X-Nokia-AV: Clean Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org, "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Oct 2010 08:32:12 -0000 --Apple-Mail-133-870218580 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, folks, where are we with resolving the DISCUSSes on this document? Thanks, Lars --Apple-Mail-133-870218580 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAwNTA4 MzMwMFowIwYJKoZIhvcNAQkEMRYEFEvWxXihsI7D/iwjo/jdgKr1ELstMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAJ8giL+5ya/jU+ajPvuLk2HukAsi6xtSxzo1ngr7ilWLJO9nrTr6 Mptjki/I+dHqkbqPdP8GwsMx5NqArMW38ate2L82bbDx/MDpkNoqv9jNre2y+Fq91R6kQV3fa7hS Irlkwe9GbGoQdjl6n7o0j7zg/twyGuxA3ZDW9n4QMe67HkYVFCzDK043Xc6Pn+48Mlvf+z8DTclX RinlnTn+hH6TFu1ASM4YVa8XUXu5FtsIId6RsTjErMLGZ8N+wKLfocIFO8asUVwMZJNJ/cljl5Jh odPvgIDecxyBzrRcwY0Jg2Za1IQQJYqbj0bBVcHA0sc7inxu55I6sVCfBxbhEHQAAAAAAAA= --Apple-Mail-133-870218580-- From rbonica@juniper.net Tue Oct 5 07:17: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 22B363A6FCC for ; Tue, 5 Oct 2010 07:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 GFtPY3qGmtE4 for ; Tue, 5 Oct 2010 07:16:50 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 6D4183A6F6F for ; Tue, 5 Oct 2010 07:16:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTKszgECFqmDX4etFgOTg6TZ6Ydj+YOvd@postini.com; Tue, 05 Oct 2010 07:17:46 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 5 Oct 2010 07:17:30 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 5 Oct 2010 10:17:29 -0400 From: Ronald Bonica To: Lars Eggert , Jari Arkko Date: Tue, 5 Oct 2010 10:17:28 -0400 Thread-Topic: [tcpm] draft-ietf-tcpm-urgent-data-06 Thread-Index: ActkaBEnKtcFq1nRQNeIYNxLZ+DSOQAL+edw Message-ID: <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> In-Reply-To: <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-tcpm-urgent-data.all@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 05 Oct 2010 14:17:02 -0000 I cleared, assuming that Jari would hold my discuss. Ron > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: Tuesday, October 05, 2010 4:33 AM > To: Ronald Bonica; Jari Arkko > Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org; tcpm@ietf.org > Extensions > Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 >=20 > Hi, folks, >=20 > where are we with resolving the DISCUSSes on this document? >=20 > Thanks, > Lars From root@core3.amsl.com Tue Oct 5 23:00:11 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C11603A7020; Tue, 5 Oct 2010 23:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101006060010.C11603A7020@core3.amsl.com> Date: Tue, 5 Oct 2010 23:00:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-initcwnd-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 06:00:11 -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 : Increasing TCP's Initial Window Author(s) : J. Chu, et al. Filename : draft-ietf-tcpm-initcwnd-00.txt Pages : 17 Date : 2010-10-05 This document proposes an increase in the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without risking congestion collapse. Finally, it outlines a list of concerns to be addressed in future tests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-initcwnd-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-initcwnd-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-05224705.I-D@ietf.org> --NextPart-- From alexander.zimmermann@comsys.rwth-aachen.de Wed Oct 6 02:53:59 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19BA23A6EEB for ; Wed, 6 Oct 2010 02:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pc5cYfqnKOYJ for ; Wed, 6 Oct 2010 02:53:51 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 769213A6B2A for ; Wed, 6 Oct 2010 02:53:48 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L9V00FIJ4VBUJ00@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 06 Oct 2010 11:54:47 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.57,289,1283724000"; d="sig'?scan'208";a="75227700" 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, 06 Oct 2010 11:54:48 +0200 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 <0L9V00MC74VBBJ80@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 06 Oct 2010 11:54:47 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-8-961532012 From: Alexander Zimmermann In-reply-to: <0D0CEA97-722C-4329-86E9-BFDFDC01E04A@windriver.com> Date: Wed, 06 Oct 2010 11:54:53 +0200 Content-transfer-encoding: 7bit Message-id: <445AB538-6439-4B8C-BB2F-6342F47451F3@comsys.rwth-aachen.de> References: <512991AB-CB0C-4A49-994E-644276299BFD@windriver.com> <0D0CEA97-722C-4329-86E9-BFDFDC01E04A@windriver.com> To: David Borman X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] TCP window max size? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Oct 2010 09:54:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-8-961532012 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi David, we had recently also a discussion here in our group about max window size. What I understand form your example that a size of 2^31 is not possible since your example stated that it would fail. But in theory (regardless the scaling factor) what is the maximal possible window size so that everything would go ok? (2^31)-1? Another question that comes in my mind: TCP says sequence number x < y <=> 0 < y-x < 2^31. Why do we say here 2^31 and not for example 2^32-20? Alex Am 25.08.2010 um 00:07 schrieb David Borman: > > On Aug 24, 2010, at 4:22 PM, David Borman wrote: > >> This reasoning is explained in RFC 1323, section 2.3, at the bottom of >> page 10 and the top of page 11: >> >> TCP determines if a data segment is "old" or "new" by testing >> whether its sequence number is within 2**31 bytes of the left edge >> of the window, and if it is not, discarding the data as "old". To >> insure that new data is never mistakenly considered old and vice- >> versa, the left edge of the sender's window has to be at most >> 2**31 away from the right edge of the receiver's window. >> Similarly with the sender's right edge and receiver's left edge. >> Since the right and left edges of either the sender's or >> receiver's window differ by the window size, and since the sender >> and receiver windows can be out of phase by at most the window >> size, the above constraints imply that 2 * the max window size >> must be less than 2**31, or >> >> max window < 2**30 >> >> Since the max window is 2**S (where S is the scaling shift count) >> times at most 2**16 - 1 (the maximum unscaled window), the maximum >> window is guaranteed to be < 2*30 if S <= 14. Thus, the shift >> count must be limited to 14 (which allows windows of 2**30 = 1 >> Gbyte)... > > And what I forgot to ask was whether you or someone else disagreed with > this logic, but this is why it is 14. However, even if the logic is > faulty, the max value will remain at 14, the only way to change it would > be via a new TCP option number. > > But mostly the place for trouble is at the boundary conditions, and if > you had a 2^31 window and the sender/receiver windows were fully skewed, > any outstanding packet from before left edge of the senders window could > show up at the receiver and be viewed as new data at the right edge of > the receivers window, which would be a bad thing. > > 1) Sender has a full 2^31 window of unacknowledged data, > receiver is a full 2^31 ahead of the sender. > 2) Sender retransmits a packet at left edge of it's window. > 3) In-transit Ack from Receiver arrives, acks all data, and > advances window by 2^31. > 4) Sender sends a new packet. > 5) New packet gets reordered in transit with the retransmitted packet. > 6) New packet arrives, and receiver advances window. > 7) Retransmitted packet arrives, and it now appears to be at the > right edge of the receivers window as new data. > > A 2^14 max window keeps things well away from those boundary conditions. > > // // 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-961532012 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkysR20ACgkQdyiq39b9uS7tSQCgvm+U6BNy8Zm9X3wjpwangg89 J2MAoL7osQxeFBHof+yqTaDaCH1gHfse =dFyD -----END PGP SIGNATURE----- --Apple-Mail-8-961532012-- From steven.sommars@alcatel-lucent.com Wed Oct 6 08:06: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 ADA603A7196 for ; Wed, 6 Oct 2010 08:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woCJ6p+3O8rZ for ; Wed, 6 Oct 2010 08:06:03 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id D12CB3A719B for ; Wed, 6 Oct 2010 08:06:00 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o96F70dc012212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Oct 2010 10:07:00 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o96F706D023689 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 6 Oct 2010 10:07:00 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 6 Oct 2010 10:07:00 -0500 From: "Sommars, Steven E (Steven)" To: "tcpm@ietf.org" Date: Wed, 6 Oct 2010 10:07:19 -0500 Thread-Topic: missequenced TCP segments Thread-Index: ActlaCvjj8LsMSRFQqiMVOIoE0AnxA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [tcpm] missequenced TCP segments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Oct 2010 15:06:04 -0000 Vern Paxson suggested this forum for discussing an RFC793 ambiguity. RFC793 section 3.4 says: Reset Generation ... 3. If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state. The problem comes with a bidirectional TCP flow (both directions carrying p= ayload) in the presence of IP missequencing.=20 Sender transmits Seq 1, Ack 15 Seq 2, Ack 16 Seq 3, Ack 17 Seq 4, Ack 18 Due to packet reordering receiver sees Seq 4, Ack 18 Seq 1, Ack 15 << Ack out of window Seq 3, Ack 17 << Ack out of window Seq 2, Ack 16 << Ack out of window The cited RFC793 section suggests that when the Acks are out of window the = accompanying data segment should not be processed. That strategy can lead= to undesirable TCP stalls.=20 I cannot find a clarification in other RFCs. Is an erratum appropriate? From v13@v13.gr Wed Oct 6 08:31: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 1050E3A713B for ; Wed, 6 Oct 2010 08:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuG7adMdaZDZ for ; Wed, 6 Oct 2010 08:31:47 -0700 (PDT) Received: from alpha.it.teithe.gr (alpha.it.teithe.gr [195.251.240.232]) by core3.amsl.com (Postfix) with ESMTP id 5B4083A7138 for ; Wed, 6 Oct 2010 08:31:45 -0700 (PDT) Received: from v.localnet (v.it.teithe.gr [195.251.123.206]) by alpha.it.teithe.gr (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o96FWSNv007615; Wed, 6 Oct 2010 18:32:30 +0300 From: Stefanos Harhalakis To: tcpm@ietf.org Date: Wed, 6 Oct 2010 18:33:18 +0300 User-Agent: KMail/1.13.5 (Linux/2.6.35-trunk-amd64; KDE/4.5.1; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010061833.18985.v13@v13.gr> Cc: "Sommars, Steven E \(Steven\)" Subject: Re: [tcpm] missequenced TCP segments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Oct 2010 15:31:50 -0000 Hello, On Wednesday 06 of October 2010, Sommars, Steven E (Steven) wrote: > Vern Paxson suggested this forum for discussing an RFC793 ambiguity. > > RFC793 section 3.4 says: > Reset Generation > ... > 3. If the connection is in a synchronized state (ESTABLISHED, > FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), > any unacceptable segment (out of window sequence number or > unacceptible acknowledgment number) must elicit only an empty > acknowledgment segment containing the current send-sequence number > and an acknowledgment indicating the next sequence number expected > to be received, and the connection remains in the same state. [...] > Due to packet reordering receiver sees > Seq 4, Ack 18 > Seq 1, Ack 15 << Ack out of window > Seq 3, Ack 17 << Ack out of window > Seq 2, Ack 16 << Ack out of window > > The cited RFC793 section suggests that when the Acks are out of window the > accompanying data segment should not be processed. That strategy can > lead to undesirable TCP stalls. While I'm not an expert, from what I understand, as you quoted, RFC states "unacceptable acknowledgment number" and not "out of window". It also states that "the connection remains in the same state" and not that it rejects the data. Both of those statements are valid if you just accept the data. In fact, assuming that all ACKs with ACK# >= last_ack-2^31 are valid/acceptable, should be OK. From david.borman@windriver.com Wed Oct 6 09:32:56 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5CC13A6F9B for ; Wed, 6 Oct 2010 09:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.055 X-Spam-Level: X-Spam-Status: No, score=-103.055 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, 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 LcyYru5mFWTr for ; Wed, 6 Oct 2010 09:32:55 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 4C09A3A6F72 for ; Wed, 6 Oct 2010 09:32:54 -0700 (PDT) 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 o96GXnee024605; Wed, 6 Oct 2010 09:33:49 -0700 (PDT) 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); Wed, 6 Oct 2010 09:33:48 -0700 Received: from msp-dhcp42.wrs.com ([172.25.34.42]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Oct 2010 09:33:48 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: Date: Wed, 6 Oct 2010 11:33:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Sommars, Steven E (Steven)" X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 06 Oct 2010 16:33:48.0690 (UTC) FILETIME=[40BC8720:01CB6574] Cc: "tcpm@ietf.org" Subject: Re: [tcpm] missequenced TCP segments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Oct 2010 16:32:57 -0000 On Oct 6, 2010, at 10:07 AM, Sommars, Steven E (Steven) wrote: > Vern Paxson suggested this forum for discussing an RFC793 ambiguity. >=20 > RFC793 section 3.4 says: > Reset Generation > ... > 3. If the connection is in a synchronized state (ESTABLISHED, > FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), > any unacceptable segment (out of window sequence number or > unacceptible acknowledgment number) must elicit only an empty > acknowledgment segment containing the current send-sequence number > and an acknowledgment indicating the next sequence number expected > to be received, and the connection remains in the same state. >=20 > The problem comes with a bidirectional TCP flow (both directions = carrying payload) in the presence of IP missequencing.=20 >=20 > Sender transmits > Seq 1, Ack 15 > Seq 2, Ack 16 > Seq 3, Ack 17 > Seq 4, Ack 18 > Due to packet reordering receiver sees > Seq 4, Ack 18 > Seq 1, Ack 15 << Ack out of window > Seq 3, Ack 17 << Ack out of window > Seq 2, Ack 16 << Ack out of window >=20 > The cited RFC793 section suggests that when the Acks are out of window = the accompanying data segment should not be processed. That strategy = can lead to undesirable TCP stalls. It says unacceptable ACKs, not out of window ACKs. On page 72: If SND.UNA < SEG.ACK =3D< SND.NXT then, set SND.UNA <- = SEG.ACK. Any segments on the retransmission queue which are thereby entirely acknowledged are removed. Users should receive positive acknowledgments for buffers which have been SENT and fully acknowledged (i.e., SEND buffer should be returned with "ok" response). If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return. I.e., duplicate ACKs are acceptable. The only thing that is = unacceptable is an ACK for data that hasn't been sent. I'll also take this opportunity to mention that if an out-of-order = packet arrives, either due to a gap or duplicate data, the ACK field = should be processed anyway. On bi-directional connections, failure to = process the ACK field in a packet that is purely duplicate data can lead = to ACK wars on the connection, e.g. in crossing zero window probes. -David Borman >=20 > I cannot find a clarification in other RFCs. Is an erratum = appropriate? > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From alexander.zimmermann@comsys.rwth-aachen.de Wed Oct 6 09:56: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 A5C6F3A6F35 for ; Wed, 6 Oct 2010 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_33=0.6, 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 b9NmcOqriUFV for ; Wed, 6 Oct 2010 09:56:39 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 30D193A6F81 for ; Wed, 6 Oct 2010 09:56:39 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) 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 <0L9V004GEOG20R10@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 06 Oct 2010 18:57:38 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.57,290,1283724000"; d="sig'?scan'208";a="40129915" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 06 Oct 2010 18:57:39 +0200 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 <0L9V008XHOFZIY60@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 06 Oct 2010 18:57:38 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-9-986910739 From: Alexander Zimmermann In-reply-to: Date: Wed, 06 Oct 2010 18:57:52 +0200 Content-transfer-encoding: 7bit Message-id: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> References: To: David Borman X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Cc: "tcpm@ietf.org" , "Sommars, Steven E \(Steven\)" Subject: Re: [tcpm] missequenced TCP segments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Oct 2010 16:56:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-9-986910739 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi David, Am 06.10.2010 um 18:33 schrieb David Borman: >=20 > On Oct 6, 2010, at 10:07 AM, Sommars, Steven E (Steven) wrote: >=20 >> Vern Paxson suggested this forum for discussing an RFC793 ambiguity. >>=20 >> RFC793 section 3.4 says: >> Reset Generation >> ... >> 3. If the connection is in a synchronized state (ESTABLISHED, >> FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), >> any unacceptable segment (out of window sequence number or >> unacceptible acknowledgment number) must elicit only an empty >> acknowledgment segment containing the current send-sequence number >> and an acknowledgment indicating the next sequence number expected >> to be received, and the connection remains in the same state. >>=20 >> The problem comes with a bidirectional TCP flow (both directions = carrying payload) in the presence of IP missequencing.=20 >>=20 >> Sender transmits >> Seq 1, Ack 15 >> Seq 2, Ack 16 >> Seq 3, Ack 17 >> Seq 4, Ack 18 >> Due to packet reordering receiver sees >> Seq 4, Ack 18 >> Seq 1, Ack 15 << Ack out of window >> Seq 3, Ack 17 << Ack out of window >> Seq 2, Ack 16 << Ack out of window >>=20 >> The cited RFC793 section suggests that when the Acks are out of = window the accompanying data segment should not be processed. That = strategy can lead to undesirable TCP stalls. >=20 > It says unacceptable ACKs, not out of window ACKs. On page 72: > If SND.UNA < SEG.ACK =3D< SND.NXT then, set SND.UNA <- = SEG.ACK. > Any segments on the retransmission queue which are thereby > entirely acknowledged are removed. Users should receive > positive acknowledgments for buffers which have been SENT and > fully acknowledged (i.e., SEND buffer should be returned with > "ok" response). If the ACK is a duplicate > (SEG.ACK < SND.UNA), it can be ignored. If the ACK acks > something not yet sent (SEG.ACK > SND.NXT) then send an ACK, > drop the segment, and return. > I.e., duplicate ACKs are acceptable. The only thing that is = unacceptable is an ACK for data that hasn't been sent. Hmm... IMO an DUPACK is not an acceptable ACK. An acceptable ACK is an ACK, which acks perviously unacknowledged data. I like the term "valid" here... >=20 > I'll also take this opportunity to mention that if an out-of-order = packet arrives, either due to a gap or duplicate data, the ACK field = should be processed anyway. On bi-directional connections, failure to = process the ACK field in a packet that is purely duplicate data can lead = to ACK wars on the connection, e.g. in crossing zero window probes. >=20 > -David Borman >=20 >>=20 >> I cannot find a clarification in other RFCs. Is an erratum = appropriate? >> _______________________________________________ >> 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 // // 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-9-986910739 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkysqpAACgkQdyiq39b9uS5UGQCgl4zruFyHH41+iCUqcBvtGGtk UjgAoL+dp7/5ML4rvigqH8glIODFG2z0 =sV30 -----END PGP SIGNATURE----- --Apple-Mail-9-986910739-- From david.borman@windriver.com Wed Oct 6 11:05: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 7E3E03A6F9A for ; Wed, 6 Oct 2010 11:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.049 X-Spam-Level: X-Spam-Status: No, score=-103.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, 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 4UsiUcK42CN1 for ; Wed, 6 Oct 2010 11:05:20 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 2FDBF3A6DD4 for ; Wed, 6 Oct 2010 11:05:19 -0700 (PDT) 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 o96I6AcW014838; Wed, 6 Oct 2010 11:06:10 -0700 (PDT) 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); Wed, 6 Oct 2010 11:06:10 -0700 Received: from msp-dhcp42.wrs.com ([172.25.34.42]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Oct 2010 11:06:10 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> Date: Wed, 6 Oct 2010 13:06:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> To: Alexander Zimmermann X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 06 Oct 2010 18:06:10.0296 (UTC) FILETIME=[27CA7F80:01CB6581] Cc: "tcpm@ietf.org" , "Sommars, Steven E \(Steven\)" Subject: Re: [tcpm] missequenced TCP segments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 06 Oct 2010 18:05:21 -0000 On Oct 6, 2010, at 11:57 AM, Alexander Zimmermann wrote: > Hi David, >=20 > Am 06.10.2010 um 18:33 schrieb David Borman: >=20 >>=20 >> On Oct 6, 2010, at 10:07 AM, Sommars, Steven E (Steven) wrote: >>=20 >>> Vern Paxson suggested this forum for discussing an RFC793 ambiguity. >>>=20 >>> RFC793 section 3.4 says: >>> Reset Generation >>> ... >>> 3. If the connection is in a synchronized state (ESTABLISHED, >>> FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), >>> any unacceptable segment (out of window sequence number or >>> unacceptible acknowledgment number) must elicit only an empty >>> acknowledgment segment containing the current send-sequence number >>> and an acknowledgment indicating the next sequence number expected >>> to be received, and the connection remains in the same state. >>>=20 >>> The problem comes with a bidirectional TCP flow (both directions = carrying payload) in the presence of IP missequencing.=20 >>>=20 >>> Sender transmits >>> Seq 1, Ack 15 >>> Seq 2, Ack 16 >>> Seq 3, Ack 17 >>> Seq 4, Ack 18 >>> Due to packet reordering receiver sees >>> Seq 4, Ack 18 >>> Seq 1, Ack 15 << Ack out of window >>> Seq 3, Ack 17 << Ack out of window >>> Seq 2, Ack 16 << Ack out of window >>>=20 >>> The cited RFC793 section suggests that when the Acks are out of = window the accompanying data segment should not be processed. That = strategy can lead to undesirable TCP stalls. >>=20 >> It says unacceptable ACKs, not out of window ACKs. On page 72: >> If SND.UNA < SEG.ACK =3D< SND.NXT then, set SND.UNA <- = SEG.ACK. >> Any segments on the retransmission queue which are thereby >> entirely acknowledged are removed. Users should receive >> positive acknowledgments for buffers which have been SENT and >> fully acknowledged (i.e., SEND buffer should be returned with >> "ok" response). If the ACK is a duplicate >> (SEG.ACK < SND.UNA), it can be ignored. If the ACK acks >> something not yet sent (SEG.ACK > SND.NXT) then send an ACK, >> drop the segment, and return. >> I.e., duplicate ACKs are acceptable. The only thing that is = unacceptable is an ACK for data that hasn't been sent. >=20 > Hmm... IMO an DUPACK is not an acceptable ACK. > An acceptable ACK is an ACK, which acks perviously unacknowledged = data. > I like the term "valid" here... Ok, if you are going to wordsmith, look at it this way: an acceptable = ACK is one that the TCP state machine knows how to properly process, and = that includes duplicate ACKs. It is only ACKs for data that hasn't been = sent that TCP can't deal with, since that situation shouldn't occur, = hence those are the unacceptable ACKs, the ones that cause the packet to = be dropped, an ACK to be sent back to the other side, and the state of = the connection is left unchanged. Certainly you aren't arguing that it is unacceptable to receive = duplicate ACKs. :-) -David Borman >=20 >>=20 >> I'll also take this opportunity to mention that if an out-of-order = packet arrives, either due to a gap or duplicate data, the ACK field = should be processed anyway. On bi-directional connections, failure to = process the ACK field in a packet that is purely duplicate data can lead = to ACK wars on the connection, e.g. in crossing zero window probes. >>=20 >> -David Borman >>=20 >>>=20 >>> I cannot find a clarification in other RFCs. Is an erratum = appropriate? >>> _______________________________________________ >>> 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 >=20 > // > // 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 > // >=20 From viniciusromao@gmail.com Wed Oct 6 22:15: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 428543A70AB for ; Wed, 6 Oct 2010 22:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKmI5xi-kU89 for ; Wed, 6 Oct 2010 22:15:45 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 22B873A708C for ; Wed, 6 Oct 2010 22:15:44 -0700 (PDT) Received: by pwi3 with SMTP id 3so87063pwi.31 for ; Wed, 06 Oct 2010 22:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=FXxMEaTou9SVkrjQAHVETvPCsixlukewPC8IdnbBS/Y=; b=PG5vVWirouvw5mXNeE0Dn+RLqnAJsQNT2HiAWX5yRyXxDJPwWosVPDO3Uqjk06pUt3 4dcgwpN2aGpLc1AGUAILz+DGZZO9rcAGpUWJGcCAXg/42sv2S8/2PiQroCCVAsLzhRbr Tsa8igfWdj4weeK1qoq7rIlBySdci06PciiRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=C3cL+iN4sIJrS+GZodl9KCOX5SpBmvRm2TRHoTrFc3y5LvDZMrVqvvRD/uJLHteCtF fIVy6ZGFUVNMmOpkkleI3GTPDt7lR6HIi9vGQfSDtGqXD+duprd22JB0hoBpgCgf8q9t aZgfkdqX490eqTcp739MInMszNCOVFaXM8rBA= MIME-Version: 1.0 Received: by 10.142.148.15 with SMTP id v15mr208273wfd.225.1286428606324; Wed, 06 Oct 2010 22:16:46 -0700 (PDT) Received: by 10.142.44.9 with HTTP; Wed, 6 Oct 2010 22:16:46 -0700 (PDT) In-Reply-To: <445AB538-6439-4B8C-BB2F-6342F47451F3@comsys.rwth-aachen.de> References: <512991AB-CB0C-4A49-994E-644276299BFD@windriver.com> <0D0CEA97-722C-4329-86E9-BFDFDC01E04A@windriver.com> <445AB538-6439-4B8C-BB2F-6342F47451F3@comsys.rwth-aachen.de> Date: Thu, 7 Oct 2010 02:16:46 -0300 Message-ID: From: =?ISO-8859-1?Q?Vinicius_Rom=E3o?= To: Alexander Zimmermann Content-Type: multipart/alternative; boundary=000e0cd3287a1be0c1049200003c Cc: "tcpm@ietf.org WG" , David Borman Subject: Re: [tcpm] TCP window max size? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 07 Oct 2010 05:15:47 -0000 --000e0cd3287a1be0c1049200003c Content-Type: text/plain; charset=ISO-8859-1 Alexander, Despite I'm not an expert, I commented the second question: 2010/10/6 Alexander Zimmermann > Hi David, > > we had recently also a discussion here in our group about > max window size. What I understand form your example that > a size of 2^31 is not possible since your example stated that it > would fail. But in theory (regardless the scaling factor) what > is the maximal possible window size so that everything would go ok? > (2^31)-1? > > Another question that comes in my mind: TCP says sequence number > x < y <=> 0 < y-x < 2^31. Why do we say here 2^31 and not for example > 2^32-20? The TCP uses 2's complement arithmetic to verify if a number y is greater than x. This way, y must be at most 2^31 away from x to be considered a new data, otherwise it will be considered older (duplicated). The 2's complement (Modular Arithmetic) is used to handle the wrap around problem of a finite sequence number space (32 bits). You can find a good explanation in the section 24.7 TCP Sequence Numbers from Stevens, W., and Gary Wright. *TCP/IP Illustrated, Vol. 2: The Implementation*. Addison-Wesley Pub. Co, 1994. > Alex > > Am 25.08.2010 um 00:07 schrieb David Borman: > > > > > On Aug 24, 2010, at 4:22 PM, David Borman wrote: > > > >> This reasoning is explained in RFC 1323, section 2.3, at the bottom of > >> page 10 and the top of page 11: > >> > >> TCP determines if a data segment is "old" or "new" by testing > >> whether its sequence number is within 2**31 bytes of the left edge > >> of the window, and if it is not, discarding the data as "old". To > >> insure that new data is never mistakenly considered old and vice- > >> versa, the left edge of the sender's window has to be at most > >> 2**31 away from the right edge of the receiver's window. > >> Similarly with the sender's right edge and receiver's left edge. > >> Since the right and left edges of either the sender's or > >> receiver's window differ by the window size, and since the sender > >> and receiver windows can be out of phase by at most the window > >> size, the above constraints imply that 2 * the max window size > >> must be less than 2**31, or > >> > >> max window < 2**30 > >> > >> Since the max window is 2**S (where S is the scaling shift count) > >> times at most 2**16 - 1 (the maximum unscaled window), the maximum > >> window is guaranteed to be < 2*30 if S <= 14. Thus, the shift > >> count must be limited to 14 (which allows windows of 2**30 = 1 > >> Gbyte)... > > > > And what I forgot to ask was whether you or someone else disagreed with > > this logic, but this is why it is 14. However, even if the logic is > > faulty, the max value will remain at 14, the only way to change it would > > be via a new TCP option number. > > > > But mostly the place for trouble is at the boundary conditions, and if > > you had a 2^31 window and the sender/receiver windows were fully skewed, > > any outstanding packet from before left edge of the senders window could > > show up at the receiver and be viewed as new data at the right edge of > > the receivers window, which would be a bad thing. > > > > 1) Sender has a full 2^31 window of unacknowledged data, > > receiver is a full 2^31 ahead of the sender. > > 2) Sender retransmits a packet at left edge of it's window. > > 3) In-transit Ack from Receiver arrives, acks all data, and > > advances window by 2^31. > > 4) Sender sends a new packet. > > 5) New packet gets reordered in transit with the retransmitted packet. > > 6) New packet arrives, and receiver advances window. > > 7) Retransmitted packet arrives, and it now appears to be at the > > right edge of the receivers window as new data. > > > > A 2^14 max window keeps things well away from those boundary conditions. > > > > > > // > // 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 > // > > --000e0cd3287a1be0c1049200003c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0=A0 Alexander,

=A0=A0 Despite I'm not an expert, I commen= ted the second question:

2010/10/6 Alexan= der Zimmermann <alexander.zimmermann@comsys.rwth-aachen.de><= /span>
Hi David,

we had recently also a discussion here in our group about
max window size. What I understand form your example that
a size of 2^31 is not possible since your example stated that it
would fail. But in theory (regardless the scaling factor) what
is the maximal possible window size so that everything would go ok?
(2^31)-1?

Another question that comes in my mind: TCP says sequence number
x < y <=3D> 0 < y-x < 2^31. Why do we say here 2^31 and not = for example
2^32-20?=A0 =09

The TCP uses 2's complement arithmetic to verify if a number y is greater than x. This way, y must be at most 2^31 away from x to be considered a new data, otherwise it will be considered older (duplicated).


The 2's complement (Modular Arithmetic) is used to handle the wrap around problem of a finite sequence number space (32 bits).


You can find a good explanation in the section 24.7 TCP Sequence Numbers from Stevens, W., and = Gary Wright. TCP/IP Illustrated, Vol. 2: The Implementation. Addison-Wesley Pub. Co, 1994.



Alex

Am 25.08.2010 um 00:07 schrieb David Borman:

>
> On Aug 24, 2010, at 4:22 PM, David Borman wrote:
>
>> This reasoning is explained in RFC 1323, section 2.3, at the botto= m of
>> page 10 and the top of page 11:
>>
>> =A0 TCP determines if a data segment is "old" or "n= ew" by testing
>> =A0 whether its sequence number is within 2**31 bytes of the left = edge
>> =A0 of the window, and if it is not, discarding the data as "= old". =A0To
>> =A0 insure that new data is never mistakenly considered old and vi= ce-
>> =A0 versa, the left edge of the sender's window has to be at m= ost
>> =A0 2**31 away from the right edge of the receiver's window. >> =A0 Similarly with the sender's right edge and receiver's = left edge.
>> =A0 Since the right and left edges of either the sender's or >> =A0 receiver's window differ by the window size, and since the= sender
>> =A0 and receiver windows can be out of phase by at most the window=
>> =A0 size, the above constraints imply that 2 * the max window size=
>> =A0 must be less than 2**31, or
>>
>> =A0 =A0 =A0 =A0max window < 2**30
>>
>> =A0 Since the max window is 2**S (where S is the scaling shift cou= nt)
>> =A0 times at most 2**16 - 1 (the maximum unscaled window), the max= imum
>> =A0 window is guaranteed to be < 2*30 if S <=3D 14. =A0Thus,= the shift
>> =A0 count must be limited to 14 (which allows windows of 2**30 =3D= 1
>> =A0 Gbyte)...
>
> And what I forgot to ask was whether you or someone else disagreed wit= h
> this logic, but this is why it is 14. =A0However, even if the logic is=
> faulty, the max value will remain at 14, the only way to change it wou= ld
> be via a new TCP option number.
>
> But mostly the place for trouble is at the boundary conditions, and if=
> you had a 2^31 window and the sender/receiver windows were fully skewe= d,
> any outstanding packet from before left edge of the senders window cou= ld
> show up at the receiver and be viewed as new data at the right edge of=
> the receivers window, which would be a bad thing.
>
> 1) Sender has a full 2^31 window of unacknowledged data,
> =A0 receiver is a full 2^31 ahead of the sender.
> 2) Sender retransmits a packet at left edge of it's window.
> 3) In-transit Ack from Receiver arrives, acks all data, and
> =A0 advances window by 2^31.
> 4) Sender sends a new packet.
> 5) New packet gets reordered in transit with the retransmitted packet.=
> 6) New packet arrives, and receiver advances window.
> 7) Retransmitted packet arrives, and it now appears to be at the
> =A0 right edge of the receivers window as new data.
>
> A 2^14 max window keeps things well away from those boundary condition= 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.rwt= h-aachen.de
// web: http://www.u= mic-mesh.net
//


--000e0cd3287a1be0c1049200003c-- From rs@netapp.com Fri Oct 8 07:36: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 353EB3A68BB for ; Fri, 8 Oct 2010 07:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bKrnWAWPhI5 for ; Fri, 8 Oct 2010 07:36:49 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 8D45A3A68E2 for ; Fri, 8 Oct 2010 07:36:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,302,1283756400"; d="scan'208";a="219388985" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 08 Oct 2010 07:37:33 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o98EZwZt015467; Fri, 8 Oct 2010 07:37:07 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Oct 2010 15:37:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Oct 2010 15:36:59 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) Thread-Index: ActlgTP7d4/yn90sTOulJTT3Nyvw8gBYd1yg References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> From: "Scheffenegger, Richard" To: , "Matthew Mathis" , X-OriginalArrivalTime: 08 Oct 2010 14:37:00.0642 (UTC) FILETIME=[4470C420:01CB66F6] Subject: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 08 Oct 2010 14:36:54 -0000 Hello members of the TCPM group, Matt, Mark, I'm currently looking into the loss recovery behavior of TCP SACK - especially at the end-of-stream. End-of-stream (case 2) of the small congestion window, as per RFC5827) is of particular interest, as there are synchronous IO loads over TCP, that will only deliver additional data to the socket once an application level acknowledgement has been received. To be precise, single threaded, synchronous NFS read/write IOs. However that application layer Ack will only be sent by the receiver, once the complete App IO was received, thus any stalls can tremendeously delay the IO on the application.=20 The analogy would be TCP (with a large MTU) within TCP (with a small MTU) - which is known to behave sub-optimal. It appears that RFC2018 has codified behavior, which makes TCP SACK perform less optimal compared with TCP NewReno, when loss occurs directly at the last segments of the stream. " 5. Interpreting the Sack Option and Retransmission Strategy: Data Sender Behavior : : After the SACKed bit is turned on (as the result of processing a received SACK option), the data sender will skip that segment during any later retransmission. Any segment that has the SACKed bit turned off and is less than the highest SACKed segment is available for retransmission. " This definition leaves out the range [snd_fack .. snd_nxt (at loss recovery initiation time)]. There is no explanation as to why that omission was done (other than snd_fack not being defined at the time).=20 As RFC5827 is only concerned about detection and entering loss recovery, it too gives no advice in this regard. Consider a sequence of 4 Segments sent, S1 .. S4; S2 and S4 get dropped. Early Retransmit (RFC5827) will allow entering loss recovery.=20 Depending on TCP SACK, or TCP NewReno, the behavior will be different: NewReno will retransmit S2; The ACK for S3 will trigger retransmission of S4 (and nobody got hurt) SACK will retransmit S2; The ACK for S3 will *not* trigger a retransmit of S4 (it falls outside the boundary defined in RFC2018). Only a RTO will recover S4, and the stream might continue (as applications resume operation). Of course, S4 could be any number of packets, just prior to the end-of-stream. And the same sequence of events can happen without Early Retransmit and large cwnds... With infinite data to send, after SACK finished loss recovery - at the highest SACKed (snd_fack) block - the sender would resume sending starting from snd_nxt (and most likely in slow start). As soon as 3 new segments would be received, this missing segment chain (snd_fack .. Former snd_nxt) could be detected and recovered. Of course, counting this as one additional congestion event (unlike what NewReno would do). Or are SACK implementations which silently ignore the hole between snd_fack and snd_nxt (when loss recovery is entered) broken? =20 I would like to learn what you think would be the proper behavior. From my point of view, this appears to have been a simple oversight in RFC2018, and changing the statement to=20 " 5. Interpreting the Sack Option and Retransmission Strategy: Data Sender Behavior : : After the SACKed bit is turned on (as the result of processing a received SACK option), the data sender will skip that segment during any later retransmission. Any segment that has the SACKed bit turned off and is less than the highest sent segment at the beginning of the SACK recovery episode is available for retransmission. " The fix would be simply add an implicit hole (or an implicit SACK block) up to snd_nxt. If none of these tailing segments was lost, they will be covered in an SACK eventually. That would happen before the sender could retransmit those segments, as cwnd is also reduced thus limiting the sending rate.=20 Richard Scheffenegger From lars.eggert@nokia.com Mon Oct 11 01:16:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247D23A67A3 for ; Mon, 11 Oct 2010 01:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=-0.582, 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 INkpGF4FTbXn for ; Mon, 11 Oct 2010 01:16:43 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 025EA3A6784 for ; Mon, 11 Oct 2010 01:16:42 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9B8HrMU014604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2010 11:17:53 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-3--759778615; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> Date: Mon, 11 Oct 2010 11:17:46 +0300 Message-Id: References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 11 Oct 2010 11:17:47 +0300 (EEST) X-Nokia-AV: Clean Cc: "draft-ietf-tcpm-urgent-data.all@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Oct 2010 08:16:44 -0000 --Apple-Mail-3--759778615 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-10-5, at 17:17, Ronald Bonica wrote: > I cleared, assuming that Jari would hold my discuss. thanks, Ron. Editors, chairs, WG: are we clear on what needs to happen to the ID to = address the discuss? When will we see a revision? Thanks, Lars= --Apple-Mail-3--759778615 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxMTA4 MTc0N1owIwYJKoZIhvcNAQkEMRYEFIa6dQTAgKr8YfWZwhFb0Qzf4XX1MIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAJsrc3GV0X7oRFOSft7AAzLpq6Dp80nwu1gsE+uTg5UIYHMgMhAh we+swtLMlnQdtUiCyAwKQ9GL8gDqbJLKaFgImM2DlMJB28cmaVXEFvnf/1y4tvnIgFXAFyYWNHj8 OInNhQFCSphhebTr7kMWHKGqHZjJcTO5nsUxJaZ9fQMkOpItTrA/IuQVp+/ruY13tCjmgomS0Vud L7pzRurX34whO8H5NMTaUE30aFhJiZ5OPB493bdgKJBf9h+yYVRUrw9QD2fEkcYO+rAgm/4f42fu pTfVPpiNNQwE5rJ8qfxCvugpfUNRIUJyFwaOX6o93ClllPU9RknXGpMQOBSSzzgAAAAAAAA= --Apple-Mail-3--759778615-- From fernando.gont.netbook.win@gmail.com Mon Oct 11 07:26: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 18F673A6A6A for ; Mon, 11 Oct 2010 07:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqPSZ54TCtQ0 for ; Mon, 11 Oct 2010 07:26:22 -0700 (PDT) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by core3.amsl.com (Postfix) with ESMTP id 08B763A6805 for ; Mon, 11 Oct 2010 07:26:21 -0700 (PDT) Received: by yxk8 with SMTP id 8so887511yxk.1 for ; Mon, 11 Oct 2010 07:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=DSsrcBZFTGHsk/82R+ZMHRh757y7hN3ZqpwVDyXfMx0=; b=lQ86jaceTWtbm18BwN92+egOLtpn3kvTutchORgD2XjYEzIV597OeGkEVgCZehq2Gd 5x2K1F+WnkdRWysIiHiQBUETJuR1WwpoZtYhqPDjAouZJXebh0lWr3M9OBsgm4CjMwwh LAYOFCVzhFJT4887BffWWp4Go5g5go/N8CWJY= 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=QFLb3EqyoEgAYFwjecovwit+eZz8rz1V6KT4H9OGdOSWHSlbH5D/RnN1u6V8cryoj4 WcAcFef65r8dk9XjUEVBhOAnXo24NmBzJNUeJDpejjAdD7ACROtCOPY7OEJNdbupwKIK aMhS2D7ut0enhojsi8xX+7ya8m/9gdeWnm0SM= Received: by 10.100.195.15 with SMTP id s15mr1711591anf.124.1286807253587; Mon, 11 Oct 2010 07:27:33 -0700 (PDT) Received: from [192.168.123.100] ([190.48.248.19]) by mx.google.com with ESMTPS id g6sm8807807anh.11.2010.10.11.07.27.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Oct 2010 07:27:32 -0700 (PDT) Sender: Fernando Gont Message-ID: <4CB31ECF.6040307@gont.com.ar> Date: Mon, 11 Oct 2010 11:27:27 -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: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-tcpm-urgent-data.all@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Oct 2010 14:26:23 -0000 Hi, Lars, Thanks so much for following this one closely. Comments inline.... On 11/10/2010 05:17 a.m., Lars Eggert wrote: > Hi, > > On 2010-10-5, at 17:17, Ronald Bonica wrote: >> I cleared, assuming that Jari would hold my discuss. > > thanks, Ron. > > Editors, chairs, WG: are we clear on what needs to happen to the ID > to address the discuss? When will we see a revision? It's clear that there are two different positions on this DISCUSS: David's, and Jari/Ron's (probably shared by Joe, too). But it's not clear to me whether I should simply modify the document as indicated by Jari/Ron, or whether there's a middle-ground that could possibly make both parties happy (I'm assuming that sticking to David's position is not an option). (FWIW, me, I agree with David's position... but for obvious reasons I might be biased... hence my request for advice on how to proceed). Thoughts? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From lars.eggert@nokia.com Mon Oct 11 08:50:31 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35E23A69DF for ; Mon, 11 Oct 2010 08:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.179 X-Spam-Level: X-Spam-Status: No, score=-103.179 tagged_above=-999 required=5 tests=[AWL=-0.580, 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 XYqL-tOIQR5K for ; Mon, 11 Oct 2010 08:50:30 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 1CD3E3A6927 for ; Mon, 11 Oct 2010 08:50:29 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9BFpbLc016046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2010 18:51:37 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-20--732559250; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4CB31ECF.6040307@gont.com.ar> Date: Mon, 11 Oct 2010 18:51:25 +0300 Message-Id: <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 11 Oct 2010 18:51:31 +0300 (EEST) X-Nokia-AV: Clean Cc: "draft-ietf-tcpm-urgent-data.all@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 11 Oct 2010 15:50:32 -0000 --Apple-Mail-20--732559250 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-10-11, at 17:27, Fernando Gont wrote: > It's clear that there are two different positions on this DISCUSS: > David's, and Jari/Ron's (probably shared by Joe, too). But it's not > clear to me whether I should simply modify the document as indicated = by > Jari/Ron, or whether there's a middle-ground that could possibly make > both parties happy (I'm assuming that sticking to David's position is > not an option). if you can find a middle ground that addresses the discusses, that would = obviously also be a way forward. Please suggest one. > (FWIW, me, I agree with David's position... but for obvious reasons I > might be biased... hence my request for advice on how to proceed). I'm mostly agreeing with David as well, but a significant fraction of = the IESG does not.=20 Lars= --Apple-Mail-20--732559250 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxMTE1 NTEyNlowIwYJKoZIhvcNAQkEMRYEFN82HiMo0vtze5C+Rtyrbr1pC+yTMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAKIjx2RnjTdXhnNuZy09SVImovoGaeCrCH5euwmYxAULKHMvoI8w 2sXDM7CqnS6P0PXiE+FstWgrN/pn31/bFd5AMHHS8xaWiolqTrkUpMoxLp/1ZVk4ga46G6c8cB8B J90RcyN9DqP2StlxSjtsmaLUiapoh+SWivytxB26BUA3bQMyqGHYj25Xybmtf5AaHy1P5SMNdBEU hl3ijS2V+kZav+VXxLFc4Qgk22lyUmKdcB4bH10Utf6AhVW1vsLZWM9zAAo8wx+El5S4eFi9fMKQ BDCz/pn3ozcs0rtyAaabepR9NXTM4UVWl/HCj4OP6Oy2rs+ofx4WbnfE+SoqV+YAAAAAAAA= --Apple-Mail-20--732559250-- From wesley.m.eddy@nasa.gov Mon Oct 11 17:28: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 461F33A6BA2 for ; Mon, 11 Oct 2010 17:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.355 X-Spam-Level: X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=0.244, 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 H73GLyEyn2qH for ; Mon, 11 Oct 2010 17:28:27 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 40C293A6863 for ; Mon, 11 Oct 2010 17:28:27 -0700 (PDT) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 05DDCA80F4; Mon, 11 Oct 2010 19:29:40 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o9C0TdI0031627; Mon, 11 Oct 2010 19:29:39 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Mon, 11 Oct 2010 19:29:39 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Lars Eggert , Fernando Gont Date: Mon, 11 Oct 2010 19:24:40 -0500 Thread-Topic: [tcpm] draft-ietf-tcpm-urgent-data-06 Thread-Index: ActpXDetW+xP7l0VTtitqeU4gid0CgAR6RgX Message-ID: References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> In-Reply-To: <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-11_13:2010-10-11, 2010-10-11, 1970-01-01 signatures=0 Cc: "draft-ietf-tcpm-urgent-data.all@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Oct 2010 00:28:28 -0000 For what it's worth, I also agree with the position that David presented. = I don't think it's necessarily worth spending a lot of time and energy to d= ebate, though. ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Lars Egger= t [lars.eggert@nokia.com] Sent: Monday, October 11, 2010 11:51 AM To: Fernando Gont Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org; tcpm@ietf.org Extension= s Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 ... > (FWIW, me, I agree with David's position... but for obvious reasons I > might be biased... hence my request for advice on how to proceed). I'm mostly agreeing with David as well, but a significant fraction of the I= ESG does not. Lars= From touch@isi.edu Mon Oct 11 19:48: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 B4AF73A68A5 for ; Mon, 11 Oct 2010 19:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 lhUChhay81oz for ; Mon, 11 Oct 2010 19:48:52 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 5F4BE3A6863 for ; Mon, 11 Oct 2010 19:48:51 -0700 (PDT) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id o9C2nUkW021865 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 11 Oct 2010 19:49:39 -0700 (PDT) Message-ID: <4CB3CCBB.1030400@isi.edu> Date: Mon, 11 Oct 2010 19:49:31 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "draft-ietf-tcpm-urgent-data.all@tools.ietf.org" , "tcpm@ietf.org Extensions" , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Oct 2010 02:48:53 -0000 Hi, all, I can't speak for the IESG, but I can explain my reasoning: The doc presents two pieces of info: - update the spec - change use to SHOULD NOT Given we don't have apps breaking all over the place, the second one seems to be more dramatic in its impact to the community. The document presents the second one in an almost ancillary way. IMO, if this doc is really about updating the spec, and we don't really have issue with new uses of the feature, then the SHOULD NOT should be dropped. If the SHOULD NOT is kept, I can't see how it's not more prominent (and thus warrants doc restructuring as suggested). Joe On 10/11/2010 5:24 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > For what it's worth, I also agree with the position that David presented. I don't think it's necessarily worth spending a lot of time and energy to debate, though. > > ________________________________________ > From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Lars Eggert [lars.eggert@nokia.com] > Sent: Monday, October 11, 2010 11:51 AM > To: Fernando Gont > Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org; tcpm@ietf.org Extensions > Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 > > ... > >> (FWIW, me, I agree with David's position... but for obvious reasons I >> might be biased... hence my request for advice on how to proceed). > > I'm mostly agreeing with David as well, but a significant fraction of the IESG does not. > > Lars > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From bruno.mongazon-cazavet@alcatel-lucent.com Tue Oct 12 07:40: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 A5EBC3A68FD for ; Tue, 12 Oct 2010 07:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvkaysYvACDq for ; Tue, 12 Oct 2010 07:40:46 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 1E3E23A6823 for ; Tue, 12 Oct 2010 07:40:45 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9CEfvPC023648 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 12 Oct 2010 16:41:59 +0200 Received: from [172.27.205.223] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Oct 2010 16:41:44 +0200 Message-ID: <4CB473A8.3070001@alcatel-lucent.com> Date: Tue, 12 Oct 2010 16:41:44 +0200 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [tcpm] I-D Action:draft-mongazon-tcpm-tcp-rehash-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 14:40:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TCP Rehash Author(s) : B. Mongazon-Cazavet Filename : draft-mongazon-tcpm-tcp-rehash-00.txt Pages : 13 Date : 2010-10-11 The present specification describes a light extension of the TCP protocol [RFC793] that allows a TCP transport connection to be maintained operational whenever the underlying IP network address of its end-points changes. This includes situations where a single- interface host changes its IP address or where a multiple-interface host diverts a connection from one interface to another. The mechanism used to maintain a transport connection in such situations is based on the capability of both end-points to "Rehash" a TCP connection (rebuild its lookup key) with a new IP address in a fast and reliable manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mongazon-tcpm-tcp-rehash-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-mongazon-tcpm-tcp-rehash-00.txt From david.borman@windriver.com Tue Oct 12 07:57:47 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C9A3A699F for ; Tue, 12 Oct 2010 07:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.344 X-Spam-Level: X-Spam-Status: No, score=-103.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ct60xY65HuWP for ; Tue, 12 Oct 2010 07:57:46 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 91EB73A68E4 for ; Tue, 12 Oct 2010 07:57:46 -0700 (PDT) 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 o9CEwpU9025338; Tue, 12 Oct 2010 07:58:52 -0700 (PDT) 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); Tue, 12 Oct 2010 07:58:51 -0700 Received: from [172.25.34.3] ([172.25.34.3]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Oct 2010 07:58:51 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <4CB3CCBB.1030400@isi.edu> Date: Tue, 12 Oct 2010 09:58:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> To: Joe Touch , Fernando Gont X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 12 Oct 2010 14:58:51.0258 (UTC) FILETIME=[FB47E5A0:01CB6A1D] Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org, "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Oct 2010 14:57:47 -0000 On Oct 11, 2010, at 9:49 PM, Joe Touch wrote: > Hi, all, >=20 > I can't speak for the IESG, but I can explain my reasoning: >=20 > The doc presents two pieces of info: >=20 > - update the spec > - change use to SHOULD NOT >=20 > Given we don't have apps breaking all over the place, the second one = seems to be more dramatic in its impact to the community. The document = presents the second one in an almost ancillary way. >=20 > IMO, if this doc is really about updating the spec, and we don't = really have issue with new uses of the feature, then the SHOULD NOT = should be dropped. =46rom my viewpoint, the issue is to 1) make application developers = aware of the problems cause by the potential of OS's having different = definitions of the urgent pointer, and 2) tell them NOT to use the = broken bsd socket() OOB mechanism, by setting SO_OOBINLINE. The goal = isn't to say that applications can't use the Urgent pointer, but to warn = of the potential issues in a generic environment. As you said, we don't have applications breaking all over the place. = Also, the goal of this document isn't to change all the current Urgent = pointer implementations, but to match the spec to the majority of = implementations. The WG did not put forth this document to deprecate the Urgent pointer, = but to clarify it and warn of the interoperability issues. So perhaps the "SHOULD NOT" should be changed to a "MAY", meaning you = can still use it, but be aware of the issues and make sure you design = around them. It is entirely possible to reliably make use of the urgent = pointer in an application, even with different OS definitions. The = application can the test urgent pointer at the beginning of the = connection by sending a known piece of data and observing how it gets = delivered to the receiver, the application can then adjust accordingly = and use it reliably. Perhaps combine section 5 & 6 into a single section like: 5. Advice on using and implementing the TCP urgent mechanism As a result of the issues discussed in Section 3.2 and Section 3.4, using the TCP urgent mechanism has the potential to be unreliable. New applications MAY use the TCP urgent mechanism, but should be robust against these issues. In addition, applications MUST set the SO_OOBINLINE socket option, such that "urgent data" is delivered inline, as intended by the IETF specifications. TCP implementations MUST include support for the urgent mechanism such that existing applications can still use it. -David Borman >=20 > If the SHOULD NOT is kept, I can't see how it's not more prominent = (and thus warrants doc restructuring as suggested). >=20 > Joe >=20 > On 10/11/2010 5:24 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] = wrote: >> For what it's worth, I also agree with the position that David = presented. I don't think it's necessarily worth spending a lot of time = and energy to debate, though. >>=20 >> ________________________________________ >> From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Lars = Eggert [lars.eggert@nokia.com] >> Sent: Monday, October 11, 2010 11:51 AM >> To: Fernando Gont >> Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org; tcpm@ietf.org = Extensions >> Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 >>=20 >> ... >>=20 >>> (FWIW, me, I agree with David's position... but for obvious reasons = I >>> might be biased... hence my request for advice on how to proceed). >>=20 >> I'm mostly agreeing with David as well, but a significant fraction of = the IESG does not. >>=20 >> Lars >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Tue Oct 12 09:12: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 A808B3A6834 for ; Tue, 12 Oct 2010 09:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 1GBcq8TDbX1x for ; Tue, 12 Oct 2010 09:12:37 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id D26E63A69CF for ; Tue, 12 Oct 2010 09:12:04 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o9CGCYvm007791 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Oct 2010 09:12:34 -0700 (PDT) Message-ID: <4CB488F2.1070800@isi.edu> Date: Tue, 12 Oct 2010 09:12:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Borman References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> In-Reply-To: <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o9CGCYvm007791 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org, "tcpm@ietf.org Extensions" , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Oct 2010 16:12:53 -0000 Hi, Dave, On 10/12/2010 7:58 AM, David Borman wrote: > As you said, we don't have applications breaking all over the place. > Also, the goal of this document isn't to change all the current Urgent > pointer implementations, but to match the spec to the majority of > implementations. > > The WG did not put forth this document to deprecate the Urgent > pointer, but to clarify it and warn of the interoperability issues. > > So perhaps the "SHOULD NOT" should be changed to a "MAY", meaning > you can still use it, but be aware of the issues and make sure you > design around them. It's sufficient to delete Sec 5 then. It's already a "MAY" for users in RFC793 (though 2119 language isn't used, the intent is there). We definitely should not restate requirements already sufficiently stated. > It is entirely possible to reliably make use of > the urgent pointer in an application, even with different OS > definitions. The application can the test urgent pointer at the > beginning of the connection by sending a known piece of data and > observing how it gets delivered to the receiver, the application can > then adjust accordingly and use it reliably. That's not in the doc anywhere. No current app I've ever heard of does this, and it doesn't seem practical for most apps (esp. since it's not backward compatible; the test data would appear in the data stream). I'm not sure this is a useful consideration for this discussion at all. > Perhaps combine section 5& 6 into a single section like: > 5. Advice on using and implementing the TCP urgent mechanism > > As a result of the issues discussed in Section 3.2 and Section 3.4, > using the TCP urgent mechanism has the potential to be unreliable. > New applications MAY use the TCP urgent mechanism, but should be > robust against these issues. The above simply isn't required; it's already part of RFC793. > In addition, applications MUST set > the SO_OOBINLINE socket option, such that "urgent data" is delivered > inline, as intended by the IETF specifications. SO_OOBINLINE and its behavior isn't defined in RFC793. The fact that urgent data is inline needs to be defined and explained. Then the requirement stated that urgent pointer data is inline, as is all TCP data. It may be useful to note that the way to do this in some implementations is to set this socket option, and that this particular option should default to ON (and note that it isn't, so apps should set it), but 2119 language isn't appropriate. The discussion shouldn't use 2119 language in reference to an implementation of the API that isn't required. > TCP implementations MUST include support for the urgent mechanism > such that existing applications can still use it. That's not necessary either; it's in 793, and it's already required therein. Again, I don't think this doc should restate existing requirements. Joe From touch@isi.edu Tue Oct 12 09:32: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 8DF3F3A6910 for ; Tue, 12 Oct 2010 09:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 AlWY7W+BxsjI for ; Tue, 12 Oct 2010 09:32:40 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id E2DB13A68FF for ; Tue, 12 Oct 2010 09:32:39 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o9CGXIC8013385 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Oct 2010 09:33:18 -0700 (PDT) Message-ID: <4CB48DCE.7010606@isi.edu> Date: Tue, 12 Oct 2010 09:33:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Borman References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> In-Reply-To: <4CB488F2.1070800@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o9CGXIC8013385 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org, "tcpm@ietf.org Extensions" , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 12 Oct 2010 16:32:45 -0000 PS - to summarize my suggestions to wrap this up: - delete section 5 - revise section 6 to explain what inline vs. out-of-band data is, and remind users that urgent is NOT an out-of-band signal -- that the data indicated by the urgent pointer MUST NOT be extricated from the data byte stream presented to the user via means indicated in RFC793 (e.g., read calls). This would also note that in some implementations this is requires overriding the default, and setting SO_OOBINLINE=1. Joe On 10/12/2010 9:12 AM, Joe Touch wrote: > Hi, Dave, > > On 10/12/2010 7:58 AM, David Borman wrote: > >> As you said, we don't have applications breaking all over the place. >> Also, the goal of this document isn't to change all the current Urgent >> pointer implementations, but to match the spec to the majority of >> implementations. >> >> The WG did not put forth this document to deprecate the Urgent >> pointer, but to clarify it and warn of the interoperability issues. >> >> So perhaps the "SHOULD NOT" should be changed to a "MAY", meaning >> you can still use it, but be aware of the issues and make sure you >> design around them. > > It's sufficient to delete Sec 5 then. It's already a "MAY" for users in > RFC793 (though 2119 language isn't used, the intent is there). We > definitely should not restate requirements already sufficiently stated. > >> It is entirely possible to reliably make use of >> the urgent pointer in an application, even with different OS >> definitions. The application can the test urgent pointer at the >> beginning of the connection by sending a known piece of data and >> observing how it gets delivered to the receiver, the application can >> then adjust accordingly and use it reliably. > > That's not in the doc anywhere. No current app I've ever heard of does > this, and it doesn't seem practical for most apps (esp. since it's not > backward compatible; the test data would appear in the data stream). I'm > not sure this is a useful consideration for this discussion at all. > >> Perhaps combine section 5& 6 into a single section like: >> 5. Advice on using and implementing the TCP urgent mechanism >> >> As a result of the issues discussed in Section 3.2 and Section 3.4, >> using the TCP urgent mechanism has the potential to be unreliable. >> New applications MAY use the TCP urgent mechanism, but should be >> robust against these issues. > > The above simply isn't required; it's already part of RFC793. > >> In addition, applications MUST set >> the SO_OOBINLINE socket option, such that "urgent data" is delivered >> inline, as intended by the IETF specifications. > > SO_OOBINLINE and its behavior isn't defined in RFC793. > > The fact that urgent data is inline needs to be defined and explained. > Then the requirement stated that urgent pointer data is inline, as is > all TCP data. > > It may be useful to note that the way to do this in some implementations > is to set this socket option, and that this particular option should > default to ON (and note that it isn't, so apps should set it), but 2119 > language isn't appropriate. The discussion shouldn't use 2119 language > in reference to an implementation of the API that isn't required. > >> TCP implementations MUST include support for the urgent mechanism >> such that existing applications can still use it. > > That's not necessary either; it's in 793, and it's already required > therein. Again, I don't think this doc should restate existing > requirements. > > Joe From jari.arkko@piuha.net Fri Oct 15 14:02: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 BBA863A6CEF for ; Fri, 15 Oct 2010 14:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 klhQ3Q9MBO63 for ; Fri, 15 Oct 2010 14:02:56 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id DF7123A6BCC for ; Fri, 15 Oct 2010 14:02:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 763DF2CC31; Sat, 16 Oct 2010 00:04:16 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOLQipFGZiG9; Sat, 16 Oct 2010 00:04:15 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id BA76A2CC2F; Sat, 16 Oct 2010 00:04:15 +0300 (EEST) Message-ID: <4CB8C1CF.1020106@piuha.net> Date: Sat, 16 Oct 2010 00:04:15 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "tcpm@ietf.org Extensions" References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> In-Reply-To: <4CB48DCE.7010606@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Borman , Fernando Gont , Joe Touch Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Oct 2010 21:02:57 -0000 All, We discussed this yesterday in the IESG conference call. I would like to summarize my thinking about it and suggest a way forward. (There are a few other ADs who have similar but perhaps not exactly the same thoughts, but I'm the one who representing these thoughts with the Discuss.) The main concern is that at least in my view, urgent data seems pretty badly broken. It has potential interop problems if out of band mode is used, mismatch of recommendations wrt real world implementations that mostly use out of band mode as the default, etc. As far as I understand, when out of band mode is used the two end points have to agree about the semantics of the urgent pointer. It is reassuring that most implementations that you tested actually use the same semantics, but we an implementation that we do not know about or a middlebox could disrupt an application's understanding of the correct order and place of TCP data from the other end. With this background, I felt that the document stopped short of making clear enough recommendations about the use of this feature. In the IESG we talked about what the right level of "health warning" should be, and there were different opinions ranging from text at the beginning of the document to formal deprecation of the feature. I have a proposal below that takes the warning text approach. Note that I'm not really changing anything substantive from what the document was already saying, but if we publish a new RFC on urgent indications, it seems reasonable to make it very clear that there are issues. If these changes were made to the document I would be happy to clear my Discuss, though I do know that Ron would probably would like to see an even more drastic action. What does the working group think? Jari Change Abstract: OLD: This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, provides advice to applications that make use of the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. NEW: This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet and recommends against the use of the urgent indications (but provides advice to applications in case that they do). Change Introduction: OLD: This document analyzes how some current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect the processing of urgent indications by hosts. This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC 1122 [RFC1122] such that they accommodate current practice in processing TCP urgent indications, provides advice to applications using the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. NEW: This document analyzes how some current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect the processing of urgent indications by hosts. This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC 1122 [RFC1122] such that they accommodate current practice in processing TCP urgent indications, provides advice to applications using the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. Given the above issues and potential interoperability issues with respect to the currently common default mode operation, it is strongly recommended that applications do not employ urgent indications. Nevertheless, urgent indications are still retained as a mandatory part of the TCP protocol to support the few legacy applications that employ them. However, it is expected that even these applications will have difficulties in environments with middle-boxes. From rbonica@juniper.net Fri Oct 15 14:07:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDCE3A6AF4 for ; Fri, 15 Oct 2010 14:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 f7CYHO3oxZQX for ; Fri, 15 Oct 2010 14:07:47 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 8F9F83A6BCC for ; Fri, 15 Oct 2010 14:07:47 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTLjC5rbQBwKbXn4aWAosMjeE7RlNqLF8@postini.com; Fri, 15 Oct 2010 14:09:10 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 15 Oct 2010 14:07:27 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 15 Oct 2010 17:07:26 -0400 From: Ronald Bonica To: Jari Arkko , "tcpm@ietf.org Extensions" Date: Fri, 15 Oct 2010 17:07:25 -0400 Thread-Topic: [tcpm] draft-ietf-tcpm-urgent-data-06 Thread-Index: ActsrK9FyiS8C990TxaUdi0Nsb+GfQAAEPXA Message-ID: <13205C286662DE4387D9AF3AC30EF456B020F14FEB@EMBX01-WF.jnpr.net> References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> In-Reply-To: <4CB8C1CF.1020106@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: David Borman , Fernando Gont , Joe Touch Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Oct 2010 21:07:49 -0000 Looks good to me. > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Jari Arkko > Sent: Friday, October 15, 2010 5:04 PM > To: tcpm@ietf.org Extensions > Cc: David Borman; Fernando Gont; Joe Touch > Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 >=20 > All, >=20 > We discussed this yesterday in the IESG conference call. I would like > to > summarize my thinking about it and suggest a way forward. (There are a > few other ADs who have similar but perhaps not exactly the same > thoughts, but I'm the one who representing these thoughts with the > Discuss.) >=20 > The main concern is that at least in my view, urgent data seems pretty > badly broken. It has potential interop problems if out of band mode is > used, mismatch of recommendations wrt real world implementations that > mostly use out of band mode as the default, etc. As far as I > understand, > when out of band mode is used the two end points have to agree about > the > semantics of the urgent pointer. It is reassuring that most > implementations that you tested actually use the same semantics, but we > an implementation that we do not know about or a middlebox could > disrupt > an application's understanding of the correct order and place of TCP > data from the other end. With this background, I felt that the document > stopped short of making clear enough recommendations about the use of > this feature. In the IESG we talked about what the right level of > "health warning" should be, and there were different opinions ranging > from text at the beginning of the document to formal deprecation of the > feature. >=20 > I have a proposal below that takes the warning text approach. Note that > I'm not really changing anything substantive from what the document was > already saying, but if we publish a new RFC on urgent indications, it > seems reasonable to make it very clear that there are issues. If these > changes were made to the document I would be happy to clear my Discuss, > though I do know that Ron would probably would like to see an even more > drastic action. What does the working group think? >=20 > Jari >=20 > Change Abstract: >=20 > OLD: > This document analyzes how current TCP implementations process TCP > urgent indications, and how the behavior of some widely-deployed > middle-boxes affect how urgent indications are processed by end > systems. This document updates the relevant specifications such > that > they accommodate current practice in processing TCP urgent > indications, provides advice to applications that make use of the > urgent mechanism, and raises awareness about the reliability of TCP > urgent indications in the current Internet. > NEW: > This document analyzes how current TCP implementations process TCP > urgent indications, and how the behavior of some widely-deployed > middle-boxes affect how urgent indications are processed by end > systems. This document updates the relevant specifications such that > they accommodate current practice in processing TCP urgent > indications, raises awareness about the reliability of TCP > urgent indications in the Internet and recommends against the use of > the > urgent indications (but provides advice to applications in case that > they do). >=20 > Change Introduction: >=20 > OLD: > This document analyzes how some current TCP implementations process > TCP urgent indications, and how the behavior of some widely-deployed > middle-boxes affect the processing of urgent indications by hosts. > This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC > 1122 [RFC1122] such that they accommodate current practice in > processing TCP urgent indications, provides advice to applications > using the urgent mechanism, and raises awareness about the > reliability of TCP urgent indications in the current Internet. > NEW: > This document analyzes how some current TCP implementations process > TCP urgent indications, and how the behavior of some widely-deployed > middle-boxes affect the processing of urgent indications by hosts. > This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC > 1122 [RFC1122] such that they accommodate current practice in > processing TCP urgent indications, provides advice to applications > using the urgent mechanism, and raises awareness about the > reliability of TCP urgent indications in the current Internet. >=20 > Given the above issues and potential interoperability issues with > respect to the > currently common default mode operation, it is strongly recommended > that > applications do not employ urgent indications. Nevertheless, urgent > indications > are still retained as a mandatory part of the TCP protocol to > support the > few legacy applications that employ them. However, it is expected > that even > these applications will have difficulties in environments with > middle-boxes. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From stpeter@stpeter.im Fri Oct 15 14:11: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 0BB963A6D1B for ; Fri, 15 Oct 2010 14:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 q9SHWZQCkeAe for ; Fri, 15 Oct 2010 14:11:39 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 944613A6D2D for ; Fri, 15 Oct 2010 14:11:32 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1AEC540337; Fri, 15 Oct 2010 15:19:54 -0600 (MDT) Message-ID: <4CB8C3D4.9000500@stpeter.im> Date: Fri, 15 Oct 2010 15:12:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Jari Arkko References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> In-Reply-To: <4CB8C1CF.1020106@piuha.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070902070600010201060500" Cc: "tcpm@ietf.org Extensions" , David Borman , Fernando Gont , Joe Touch Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Oct 2010 21:11:42 -0000 This is a cryptographically signed message in MIME format. --------------ms070902070600010201060500 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 -- that seems to be an accurate summary of what folks think this document is saying or should be saying. On 10/15/10 3:04 PM, Jari Arkko wrote: > All, >=20 > We discussed this yesterday in the IESG conference call. I would like t= o > summarize my thinking about it and suggest a way forward. (There are a > few other ADs who have similar but perhaps not exactly the same > thoughts, but I'm the one who representing these thoughts with the > Discuss.) >=20 > The main concern is that at least in my view, urgent data seems pretty > badly broken. It has potential interop problems if out of band mode is > used, mismatch of recommendations wrt real world implementations that > mostly use out of band mode as the default, etc. As far as I understand= , > when out of band mode is used the two end points have to agree about th= e > semantics of the urgent pointer. It is reassuring that most > implementations that you tested actually use the same semantics, but we= > an implementation that we do not know about or a middlebox could disrup= t > an application's understanding of the correct order and place of TCP > data from the other end. With this background, I felt that the document= > stopped short of making clear enough recommendations about the use of > this feature. In the IESG we talked about what the right level of > "health warning" should be, and there were different opinions ranging > from text at the beginning of the document to formal deprecation of the= > feature. >=20 > I have a proposal below that takes the warning text approach. Note that= > I'm not really changing anything substantive from what the document was= > already saying, but if we publish a new RFC on urgent indications, it > seems reasonable to make it very clear that there are issues. If these > changes were made to the document I would be happy to clear my Discuss,= > though I do know that Ron would probably would like to see an even more= > drastic action. What does the working group think? >=20 > Jari >=20 > Change Abstract: >=20 > OLD: > This document analyzes how current TCP implementations process TCP > urgent indications, and how the behavior of some widely-deployed > middle-boxes affect how urgent indications are processed by end > systems. This document updates the relevant specifications such that= > they accommodate current practice in processing TCP urgent > indications, provides advice to applications that make use of the > urgent mechanism, and raises awareness about the reliability of TCP > urgent indications in the current Internet. > NEW: > This document analyzes how current TCP implementations process TCP > urgent indications, and how the behavior of some widely-deployed > middle-boxes affect how urgent indications are processed by end > systems. This document updates the relevant specifications such that > they accommodate current practice in processing TCP urgent > indications, raises awareness about the reliability of TCP > urgent indications in the Internet and recommends against the use of = the > urgent indications (but provides advice to applications in case that > they do). >=20 > Change Introduction: >=20 > OLD: > This document analyzes how some current TCP implementations process > TCP urgent indications, and how the behavior of some widely-deployed > middle-boxes affect the processing of urgent indications by hosts. > This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC > 1122 [RFC1122] such that they accommodate current practice in > processing TCP urgent indications, provides advice to applications > using the urgent mechanism, and raises awareness about the > reliability of TCP urgent indications in the current Internet. > NEW: > This document analyzes how some current TCP implementations process > TCP urgent indications, and how the behavior of some widely-deployed > middle-boxes affect the processing of urgent indications by hosts. > This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC > 1122 [RFC1122] such that they accommodate current practice in > processing TCP urgent indications, provides advice to applications > using the urgent mechanism, and raises awareness about the > reliability of TCP urgent indications in the current Internet. >=20 > Given the above issues and potential interoperability issues with > respect to the > currently common default mode operation, it is strongly recommended t= hat > applications do not employ urgent indications. Nevertheless, urgent > indications > are still retained as a mandatory part of the TCP protocol to support= the > few legacy applications that employ them. However, it is expected tha= t > even > these applications will have difficulties in environments with > middle-boxes. --------------ms070902070600010201060500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAx NTIxMTI1MlowIwYJKoZIhvcNAQkEMRYEFF8+Te93YdUq4P6cxr6TaGRo8y9qMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQA6glppZHeDth0AcY1toh+1rh/HVNYoHgRqJxJbk2a8paNitThak58ijN4A 8w4WEFoll3joSxPPrmbo0E4htLtr1zPAhdKx7IXZ/0M1PZ5tPWMv9S1AQ67NtcNhaS4oaU8x 7Wp6nvg1eiiYMKULADvF900Q+G3aqI0UFGzDBhgG+Lj0p8U7y89NgedBqrrgy3nAMwTbEY28 2GDOqPutrql6b7TWc6TMnb6faiq+hx2qvEVi35zqvUijzIpKLV8e6Cmvx43Hqh3zheqw2Qcm 09+EnK0eYEVHhrgUKpeXF4AuWtwm8KemJtCjJShLlRIFyE5hszFryMcvvcfGI0P9pPs8AAAA AAAA --------------ms070902070600010201060500-- From david.borman@windriver.com Fri Oct 15 14:40: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 178273A6D01 for ; Fri, 15 Oct 2010 14:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 87F8EoiHNmc9 for ; Fri, 15 Oct 2010 14:40:31 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 96CE13A6BCC for ; Fri, 15 Oct 2010 14:40:25 -0700 (PDT) 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 o9FLfUWF007803; Fri, 15 Oct 2010 14:41:30 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Oct 2010 14:41:30 -0700 Received: from [172.25.34.7] ([172.25.34.7]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Oct 2010 14:41:30 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <4CB8C1CF.1020106@piuha.net> Date: Fri, 15 Oct 2010 16:41:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.com> References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 15 Oct 2010 21:41:30.0210 (UTC) FILETIME=[BA60AC20:01CB6CB1] Cc: "tcpm@ietf.org Extensions" , Fernando Gont , Joe Touch Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Oct 2010 21:40:34 -0000 Jari, This seems to be a reasonable compromise for the differing points of = view, and a way to get past this issue. Thanks. -David On Oct 15, 2010, at 4:04 PM, Jari Arkko wrote: > All, >=20 > We discussed this yesterday in the IESG conference call. I would like = to summarize my thinking about it and suggest a way forward. (There are = a few other ADs who have similar but perhaps not exactly the same = thoughts, but I'm the one who representing these thoughts with the = Discuss.) >=20 > The main concern is that at least in my view, urgent data seems pretty = badly broken. It has potential interop problems if out of band mode is = used, mismatch of recommendations wrt real world implementations that = mostly use out of band mode as the default, etc. As far as I understand, = when out of band mode is used the two end points have to agree about the = semantics of the urgent pointer. It is reassuring that most = implementations that you tested actually use the same semantics, but we = an implementation that we do not know about or a middlebox could disrupt = an application's understanding of the correct order and place of TCP = data from the other end. With this background, I felt that the document = stopped short of making clear enough recommendations about the use of = this feature. In the IESG we talked about what the right level of = "health warning" should be, and there were different opinions ranging = from text at the beginning of the document to formal deprecation of the = feature. >=20 > I have a proposal below that takes the warning text approach. Note = that I'm not really changing anything substantive from what the document = was already saying, but if we publish a new RFC on urgent indications, = it seems reasonable to make it very clear that there are issues. If = these changes were made to the document I would be happy to clear my = Discuss, though I do know that Ron would probably would like to see an = even more drastic action. What does the working group think? >=20 > Jari >=20 > Change Abstract: >=20 > OLD: > This document analyzes how current TCP implementations process TCP > urgent indications, and how the behavior of some widely-deployed > middle-boxes affect how urgent indications are processed by end > systems. This document updates the relevant specifications such that > they accommodate current practice in processing TCP urgent > indications, provides advice to applications that make use of the > urgent mechanism, and raises awareness about the reliability of TCP > urgent indications in the current Internet. > NEW: > This document analyzes how current TCP implementations process TCP > urgent indications, and how the behavior of some widely-deployed > middle-boxes affect how urgent indications are processed by end > systems. This document updates the relevant specifications such that > they accommodate current practice in processing TCP urgent > indications, raises awareness about the reliability of TCP > urgent indications in the Internet and recommends against the use of = the > urgent indications (but provides advice to applications in case that = they do). >=20 > Change Introduction: >=20 > OLD: > This document analyzes how some current TCP implementations process > TCP urgent indications, and how the behavior of some widely-deployed > middle-boxes affect the processing of urgent indications by hosts. > This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC > 1122 [RFC1122] such that they accommodate current practice in > processing TCP urgent indications, provides advice to applications > using the urgent mechanism, and raises awareness about the > reliability of TCP urgent indications in the current Internet. > NEW: > This document analyzes how some current TCP implementations process > TCP urgent indications, and how the behavior of some widely-deployed > middle-boxes affect the processing of urgent indications by hosts. > This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC > 1122 [RFC1122] such that they accommodate current practice in > processing TCP urgent indications, provides advice to applications > using the urgent mechanism, and raises awareness about the > reliability of TCP urgent indications in the current Internet. >=20 > Given the above issues and potential interoperability issues with = respect to the > currently common default mode operation, it is strongly recommended = that > applications do not employ urgent indications. Nevertheless, urgent = indications > are still retained as a mandatory part of the TCP protocol to support = the > few legacy applications that employ them. However, it is expected = that even > these applications will have difficulties in environments with = middle-boxes. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Fri Oct 15 14:48: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 BD6B53A6B4D for ; Fri, 15 Oct 2010 14:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 7+gRR1dbj+-p for ; Fri, 15 Oct 2010 14:48:06 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 913CE3A68E0 for ; Fri, 15 Oct 2010 14:48:06 -0700 (PDT) Received: from [128.9.184.172] ([128.9.184.172]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id o9FLmpOo022499 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 15 Oct 2010 14:48:51 -0700 (PDT) Message-ID: <4CB8CC43.8080305@isi.edu> Date: Fri, 15 Oct 2010 14:48:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Borman References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.com> In-Reply-To: <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.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" , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Oct 2010 21:48:07 -0000 Hi, all, FWIW, this skirts the key questions: 1) should this doc include any particular 2119 language on the urgent option? - IMO, it should not repeat or restate existing requirements - based on the note from Jari, I can't tell whether the doc is recommending SHOULD NOT for new apps or not if it is, then the doc should definitely be revised to lead with that issue; if not, then such revision isn't needed 2) how should this doc address the in/out of band issue? Right now, it explains it solely by reference to the implementation of a Unix API. That doesn't seem sufficient, as per the note I already posted. It'd be useful to understand what the note below says to these two points. Joe On 10/15/2010 2:41 PM, David Borman wrote: > Jari, > This seems to be a reasonable compromise for the differing points of view, and a way to get past this issue. Thanks. > -David > > On Oct 15, 2010, at 4:04 PM, Jari Arkko wrote: > >> All, >> >> We discussed this yesterday in the IESG conference call. I would like to summarize my thinking about it and suggest a way forward. (There are a few other ADs who have similar but perhaps not exactly the same thoughts, but I'm the one who representing these thoughts with the Discuss.) >> >> The main concern is that at least in my view, urgent data seems pretty badly broken. It has potential interop problems if out of band mode is used, mismatch of recommendations wrt real world implementations that mostly use out of band mode as the default, etc. As far as I understand, when out of band mode is used the two end points have to agree about the semantics of the urgent pointer. It is reassuring that most implementations that you tested actually use the same semantics, but we an implementation that we do not know about or a middlebox could disrupt an application's understanding of the correct order and place of TCP data from the other end. With this background, I felt that the document stopped short of making clear enough recommendations about the use of this feature. In the IESG we talked about what the right level of "health warning" should be, and there were different opinions ranging from text at the beginning of the document to formal deprecation of the feat ure. >> >> I have a proposal below that takes the warning text approach. Note that I'm not really changing anything substantive from what the document was already saying, but if we publish a new RFC on urgent indications, it seems reasonable to make it very clear that there are issues. If these changes were made to the document I would be happy to clear my Discuss, though I do know that Ron would probably would like to see an even more drastic action. What does the working group think? >> >> Jari >> >> Change Abstract: >> >> OLD: >> This document analyzes how current TCP implementations process TCP >> urgent indications, and how the behavior of some widely-deployed >> middle-boxes affect how urgent indications are processed by end >> systems. This document updates the relevant specifications such that >> they accommodate current practice in processing TCP urgent >> indications, provides advice to applications that make use of the >> urgent mechanism, and raises awareness about the reliability of TCP >> urgent indications in the current Internet. >> NEW: >> This document analyzes how current TCP implementations process TCP >> urgent indications, and how the behavior of some widely-deployed >> middle-boxes affect how urgent indications are processed by end >> systems. This document updates the relevant specifications such that >> they accommodate current practice in processing TCP urgent >> indications, raises awareness about the reliability of TCP >> urgent indications in the Internet and recommends against the use of the >> urgent indications (but provides advice to applications in case that they do). >> >> Change Introduction: >> >> OLD: >> This document analyzes how some current TCP implementations process >> TCP urgent indications, and how the behavior of some widely-deployed >> middle-boxes affect the processing of urgent indications by hosts. >> This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC >> 1122 [RFC1122] such that they accommodate current practice in >> processing TCP urgent indications, provides advice to applications >> using the urgent mechanism, and raises awareness about the >> reliability of TCP urgent indications in the current Internet. >> NEW: >> This document analyzes how some current TCP implementations process >> TCP urgent indications, and how the behavior of some widely-deployed >> middle-boxes affect the processing of urgent indications by hosts. >> This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC >> 1122 [RFC1122] such that they accommodate current practice in >> processing TCP urgent indications, provides advice to applications >> using the urgent mechanism, and raises awareness about the >> reliability of TCP urgent indications in the current Internet. >> >> Given the above issues and potential interoperability issues with respect to the >> currently common default mode operation, it is strongly recommended that >> applications do not employ urgent indications. Nevertheless, urgent indications >> are still retained as a mandatory part of the TCP protocol to support the >> few legacy applications that employ them. However, it is expected that even >> these applications will have difficulties in environments with middle-boxes. >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From jari.arkko@piuha.net Fri Oct 15 14:58: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 704083A6A67 for ; Fri, 15 Oct 2010 14:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 Yf7l9-QVzn3Y for ; Fri, 15 Oct 2010 14:58:44 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 3CA913A6917 for ; Fri, 15 Oct 2010 14:58:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D059B2CC31; Sat, 16 Oct 2010 01:00:02 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0ZkWURbs4Xm; Sat, 16 Oct 2010 01:00:02 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 56F862CC2F; Sat, 16 Oct 2010 01:00:02 +0300 (EEST) Message-ID: <4CB8CEE1.8070408@piuha.net> Date: Sat, 16 Oct 2010 01:00:01 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Joe Touch References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.com> <4CB8CC43.8080305@isi.edu> In-Reply-To: <4CB8CC43.8080305@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" , David Borman , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 15 Oct 2010 21:58:45 -0000 Joe, Just a quick response on one point: > - based on the note from Jari, I can't tell whether the > doc is recommending SHOULD NOT for new apps or not My text did not change that aspect in any way. The new text is in the introduction and has no keywords. The formal requirement is later in the document. IIRC the current text there says SHOULD NOT for new apps. Jari From root@core3.amsl.com Fri Oct 15 18:15:03 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0BF333A6A6C; Fri, 15 Oct 2010 18:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101016011503.0BF333A6A6C@core3.amsl.com> Date: Fri, 15 Oct 2010 18:15:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-urgent-data-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 01:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : On the implementation of the TCP urgent mechanism Author(s) : F. Gont, A. Yourtchenko Filename : draft-ietf-tcpm-urgent-data-07.txt Pages : 14 Date : 2010-10-15 This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet and recommends against the use of the urgent indications (but provides advice to applications in case that they do). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-urgent-data-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-15181437.I-D@ietf.org> --NextPart-- From wesley.m.eddy@nasa.gov Sun Oct 17 19:04: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 0515D3A6C43 for ; Sun, 17 Oct 2010 19:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.363 X-Spam-Level: X-Spam-Status: No, score=-106.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 hJKYjeNwW82F for ; Sun, 17 Oct 2010 19:04:46 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 1A4853A6A3E for ; Sun, 17 Oct 2010 19:04:46 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 0DAB5180792 for ; Sun, 17 Oct 2010 21:06:13 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o9I26CsX031927 for ; Sun, 17 Oct 2010 21:06:12 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Sun, 17 Oct 2010 21:06:12 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Sun, 17 Oct 2010 21:06:12 -0500 Thread-Topic: 3517 update w/ SACK-entry draft Thread-Index: AQHLbmkJkFW6St6p+EGMvHn+gLVFNw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-10-18_01:2010-10-18, 2010-10-17, 1970-01-01 signatures=0 Subject: [tcpm] 3517 update w/ SACK-entry draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Oct 2010 02:04:47 -0000 As Markku mentioned on the mailing list some time ago, and discussed in Ana= heim, the authors of draft-ietf-tcpm-sack-recovery and RFC 3517 have discus= sed merging the changes that the sack-recovery draft introduces into an upd= ate to RFC 3517. This makes a lot of sense, and simplifies the document tr= ee we create a bit. At this point, they're almost ready to submit the merged document, and want= to confirm this path with the working group so they can figure out what to= name it (draft-ietf-tcpm, or draft-lastname-tcpm). We know that in Anahei= m, Lars was concerned with the timeframe this merging might take, but there= are no errata on 3517, and the sack-recovery work is felt to be complete b= y the authors, so the merging has good odds of completing quickly. If there are any objections to the merged document in preparation replacing= the sack-recovery working group draft (as a working group item), please br= ing them up in the next couple weeks.= From rs@netapp.com Mon Oct 18 09:54: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 92C6E3A6BA6 for ; Mon, 18 Oct 2010 09:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6SkftuBxx0t for ; Mon, 18 Oct 2010 09:54:04 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 5B8403A6B8B for ; Mon, 18 Oct 2010 09:54:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,345,1283756400"; d="scan'208";a="213091124" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 18 Oct 2010 09:55:31 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (ldcrsexc1-prd.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9IGtOgb027243; Mon, 18 Oct 2010 09:55:30 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Oct 2010 17:55:29 +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: Mon, 18 Oct 2010 17:55:27 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0AE614B6@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] 3517 update w/ SACK-entry draft Thread-Index: AQHLbmkJkFW6St6p+EGMvHn+gLVFN5NG6xzw References: From: "Scheffenegger, Richard" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , X-OriginalArrivalTime: 18 Oct 2010 16:55:29.0230 (UTC) FILETIME=[44E02EE0:01CB6EE5] Subject: Re: [tcpm] 3517 update w/ SACK-entry draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Oct 2010 16:54:05 -0000 The only comment I would like to make is about my recent find, where TCP SACK loss recovery implementations currently don't recover from loss of last segement in the stream.=20 It might be a good idea to add some paragraph talking about the expected behavior so that SACK will never exhibit worst performance than NewReno? Regards,=20 Richard Scheffenegger =20 > -----Original Message----- > From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]=20 > [mailto:wesley.m.eddy@nasa.gov]=20 > Sent: Sonntag, 17. Oktober 2010 22:06 > To: tcpm@ietf.org > Subject: [tcpm] 3517 update w/ SACK-entry draft >=20 > As Markku mentioned on the mailing list some time ago, and=20 > discussed in Anaheim, the authors of=20 > draft-ietf-tcpm-sack-recovery and RFC 3517 have discussed=20 > merging the changes that the sack-recovery draft introduces=20 > into an update to RFC 3517. This makes a lot of sense, and=20 > simplifies the document tree we create a bit. >=20 > At this point, they're almost ready to submit the merged=20 > document, and want to confirm this path with the working=20 > group so they can figure out what to name it=20 > (draft-ietf-tcpm, or draft-lastname-tcpm). We know that in=20 > Anaheim, Lars was concerned with the timeframe this merging=20 > might take, but there are no errata on 3517, and the=20 > sack-recovery work is felt to be complete by the authors, so=20 > the merging has good odds of completing quickly. >=20 > If there are any objections to the merged document in=20 > preparation replacing the sack-recovery working group draft=20 > (as a working group item), please bring them up in the next=20 > couple weeks. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From eblanton@cs.ohiou.edu Mon Oct 18 10:22:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B48E3A6B8D for ; Mon, 18 Oct 2010 10:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=1.995, 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 BKVBVUjtTwd6 for ; Mon, 18 Oct 2010 10:22:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A0EFF3A6A75 for ; Mon, 18 Oct 2010 10:22:38 -0700 (PDT) Received: from 99-52-196-7.lightspeed.crmlin.sbcglobal.net ([99.52.196.7] helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P7tRM-000HB3-Mz; Mon, 18 Oct 2010 17:24:04 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id C530F3BCA8; Mon, 18 Oct 2010 13:24:03 -0400 (EDT) Date: Mon, 18 Oct 2010 13:24:03 -0400 From: Ethan Blanton To: "Scheffenegger, Richard" Message-ID: <20101018172403.GB12426@colt> Mail-Followup-To: "Scheffenegger, Richard" , "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , tcpm@ietf.org References: <5FDC413D5FA246468C200652D63E627A0AE614B6@LDCMVEXC1-PRD.hq.netapp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" Content-Disposition: inline In-Reply-To: <5FDC413D5FA246468C200652D63E627A0AE614B6@LDCMVEXC1-PRD.hq.netapp.com> X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Cc: tcpm@ietf.org Subject: Re: [tcpm] 3517 update w/ SACK-entry draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Oct 2010 17:22:39 -0000 --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Scheffenegger, Richard spake unto us the following wisdom: > The only comment I would like to make is about my recent find, where TCP > SACK loss recovery implementations currently don't recover from loss of > last segement in the stream.=20 RFC3517 SACK certainly handles this recovery, it simply requires an RTO. This is a well-known limitation, and stems from the strict observation of conservation of packets which is made possible by the pipe algorithm. Note that this behavior is described *both* in RFC 2018 (where it is not prescriptive) and in RFC 3517 (where it is prescriptive for any TCP implementating purporting to implement 3517), and that our present draft of 3517bis does not change this behavior. This situation is a corner case, and while it may have real-world implications, I am fairly sure that we do not want to tackle it in what is otherwise a *very* minor update. Triggering this corner case requires that *two* segments in the same window of data are lost, and that they are separated by at least three segments (required to trigger Fast Retransmit, in the absence of ER). As an author of 3517bis, I strongly prefer to address this issue in a different document, if at all. I also don't think this bears on whether or not SACK-based entry to loss recovery should be accepted as a WG document or not. The SACK-based entry document forwarded by Markku and Ilpo is already an accepted WG document, and the only question is whether its new status as 3517bis is also accepted. Our sense (as authors) is that it was generally accepted by the WG that 3517bis is a good path forward on this front based on previous discussions. Ethan --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTLyCs/8fixZ3H8crAQj8jggAkFJJHIEA6/Yd+KrA2r/SUI9BVSQw7amZ ber+1sOPUBOnRP+p9FgthMZVxBGYrVXswpukI6dTw3Ak1+e87qLsIhiXbRwO8M0f 2q1Zx/ODAAu8caIU8jAovbhPmcvx6DGVZKbOtVRvDMe64NdzKSEIjMl33jtuE8x7 fVB34aG8i1c95yf4YGczy9j+WEBmscbM1HWGypvggtCCtVhfOYp5wpzEC368b/Ke 9WKUgWAYFfdbtZ1fTeu6fOclxYoCbIvnYCrT0ejJXrrPRqnRszPfOJ/A+CGu/Y6r D5NATCQKk3/6d9REIgp+euhMLx9JWu7XjBuQmuiHA2FI+oZ6u8dPDw== =LNZO -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0-- From rs@netapp.com Mon Oct 18 10:32:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D063A69DB for ; Mon, 18 Oct 2010 10:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 VIGitmby0Eeg for ; Mon, 18 Oct 2010 10:32:43 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id D379B3A6DE0 for ; Mon, 18 Oct 2010 10:32:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,345,1283756400"; d="scan'208";a="221518508" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 18 Oct 2010 10:34:10 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (ldcrsexc2-prd.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9IHYAMa002117; Mon, 18 Oct 2010 10:34:10 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Oct 2010 18:34:10 +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: Mon, 18 Oct 2010 18:34:08 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0AE614CB@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20101018172403.GB12426@colt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] 3517 update w/ SACK-entry draft Thread-Index: Actu6VLJB480j6dOSZiSSaZM+sbyaAAAER/w References: <5FDC413D5FA246468C200652D63E627A0AE614B6@LDCMVEXC1-PRD.hq.netapp.com> <20101018172403.GB12426@colt> From: "Scheffenegger, Richard" To: "Ethan Blanton" X-OriginalArrivalTime: 18 Oct 2010 17:34:10.0248 (UTC) FILETIME=[AC4F6C80:01CB6EEA] Cc: tcpm@ietf.org Subject: Re: [tcpm] 3517 update w/ SACK-entry draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 18 Oct 2010 17:32:44 -0000 Ethan, Thank you for your feedback! I agree, that particular case is a corner case; from a conservation of packets point of view, a full ACK (no SACK entries) below SND.MAX would be a valid indication, IMHO - just like in NewReno. At least to address this corner case without any undue superflous retransmits (if additional segments are sent out, the 2nd loss in the window will eventually recovered by the information gathered from SACK entries. This case SACK can already cover.). I'm already trying to prepare an I-D with this (and the lost retransmission detection) as a "less conservative" SACK recovery method. So I'm fine with not merging this with the pending changes of 3517bis, and split it off into an (expirimental?) draft. Richard Scheffenegger =20 > -----Original Message----- > From: Ethan Blanton [mailto:eblanton@cs.ohiou.edu]=20 > Sent: Montag, 18. Oktober 2010 13:24 > To: Scheffenegger, Richard > Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; tcpm@ietf.org > Subject: Re: [tcpm] 3517 update w/ SACK-entry draft >=20 > Scheffenegger, Richard spake unto us the following wisdom: > > The only comment I would like to make is about my recent=20 > find, where=20 > > TCP SACK loss recovery implementations currently don't recover from=20 > > loss of last segement in the stream. >=20 > RFC3517 SACK certainly handles this recovery, it simply=20 > requires an RTO. This is a well-known limitation, and stems=20 > from the strict observation of conservation of packets which=20 > is made possible by the pipe algorithm. >=20 > Note that this behavior is described *both* in RFC 2018=20 > (where it is not prescriptive) and in RFC 3517 (where it is=20 > prescriptive for any TCP implementating purporting to=20 > implement 3517), and that our present draft of 3517bis does=20 > not change this behavior. >=20 > This situation is a corner case, and while it may have=20 > real-world implications, I am fairly sure that we do not want=20 > to tackle it in what is otherwise a *very* minor update. =20 > Triggering this corner case requires that *two* segments in=20 > the same window of data are lost, and that they are separated=20 > by at least three segments (required to trigger Fast=20 > Retransmit, in the absence of ER). As an author of 3517bis,=20 > I strongly prefer to address this issue in a different=20 > document, if at all. >=20 > I also don't think this bears on whether or not SACK-based=20 > entry to loss recovery should be accepted as a WG document or=20 > not. The SACK-based entry document forwarded by Markku and=20 > Ilpo is already an accepted WG document, and the only=20 > question is whether its new status as 3517bis is also=20 > accepted. Our sense (as authors) is that it was generally=20 > accepted by the WG that 3517bis is a good path forward on=20 > this front based on previous discussions. >=20 > Ethan >=20 From ycheng@google.com Mon Oct 18 18:13: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 905643A6AB6 for ; Mon, 18 Oct 2010 18:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.481 X-Spam-Level: X-Spam-Status: No, score=-105.481 tagged_above=-999 required=5 tests=[AWL=0.497, 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 veFwRsNPh7kH for ; Mon, 18 Oct 2010 18:13:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 06C423A6A98 for ; Mon, 18 Oct 2010 18:13:12 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o9J1EfAj004057 for ; Mon, 18 Oct 2010 18:14:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287450882; bh=+p9g4UNL7WQE7dZLn7Dv527m2W0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=JAueImL5lwvxsuPJe4sN5UyCDGErxKjdGVcpwWQ9NJwbBZnYBQNdoERH5SnMBaFmn kQQ/x0Cx3C1LL/3dZY+Mg== Received: from qyk1 (qyk1.prod.google.com [10.241.83.129]) by hpaq14.eem.corp.google.com with ESMTP id o9J1EGek012273 for ; Mon, 18 Oct 2010 18:14:40 -0700 Received: by qyk1 with SMTP id 1so1653047qyk.4 for ; Mon, 18 Oct 2010 18:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=xTFq29G/vgciDlU9u/WhPLrvZ5tCNXFOYND7/rXLy0A=; b=PUFLhdTyG16ZLYiG4Y4hPxndDEARYelBYlthR2/j7j/uNVP/2KajGXZFq13NyX8Lat 8EYwdMwepJCKJ2EKUxww== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=l59jiuYm79dz+LcMX8Z+7JtqUOhs9fxJDuQl4PwcKRDEYhxtpBFL2y3fSlKLgv3gmP aepTsSW1XYgqOBraPT3w== Received: by 10.224.218.74 with SMTP id hp10mr3585037qab.41.1287450879730; Mon, 18 Oct 2010 18:14:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.83.13 with HTTP; Mon, 18 Oct 2010 18:14:18 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Mon, 18 Oct 2010 18:14:18 -0700 Message-ID: To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 3517 update w/ SACK-entry draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Oct 2010 01:13:15 -0000 The updates look good to me. It would be better if the bis explicitly defines FlightSize or explicitly cites the RFC5681's definition: FLIGHT SIZE: The amount of data that has been sent but not yet _cumulatively_ acknowledged. Some readers (at least myself) mistakenly think that the FlightSize is the estimated amount of outstanding packets/bytes in the network (=3D=3D the pipe var. in the RFC). Cheers, Yuchung On Sun, Oct 17, 2010 at 7:06 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > > As Markku mentioned on the mailing list some time ago, and discussed in A= naheim, the authors of draft-ietf-tcpm-sack-recovery and RFC 3517 have disc= ussed merging the changes that the sack-recovery draft introduces into an u= pdate to RFC 3517. =A0This makes a lot of sense, and simplifies the documen= t tree we create a bit. > > At this point, they're almost ready to submit the merged document, and wa= nt to confirm this path with the working group so they can figure out what = to name it (draft-ietf-tcpm, or draft-lastname-tcpm). =A0We know that in An= aheim, Lars was concerned with the timeframe this merging might take, but t= here are no errata on 3517, and the sack-recovery work is felt to be comple= te by the authors, so the merging has good odds of completing quickly. > > If there are any objections to the merged document in preparation replaci= ng the sack-recovery working group draft (as a working group item), please = bring them up in the next couple weeks. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Tue Oct 19 15:09: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 F2C7E3A68E3 for ; Tue, 19 Oct 2010 15:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 Unr3yrduUgfu for ; Tue, 19 Oct 2010 15:09:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 09A633A68A8 for ; Tue, 19 Oct 2010 15:09:12 -0700 (PDT) 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 o9JMA1AQ002261 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 19 Oct 2010 15:10:01 -0700 (PDT) Message-ID: <4CBE1739.6040203@isi.edu> Date: Tue, 19 Oct 2010 15:10:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Jari Arkko References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.com> <4CB8CC43.8080305@isi.edu> <4CB8CEE1.8070408@piuha.net> In-Reply-To: <4CB8CEE1.8070408@piuha.net> 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" , David Borman , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Oct 2010 22:09:14 -0000 On 10/15/2010 3:00 PM, Jari Arkko wrote: > Joe, > > Just a quick response on one point: > >> - based on the note from Jari, I can't tell whether the >> doc is recommending SHOULD NOT for new apps or not > > My text did not change that aspect in any way. The new text is in the > introduction and has no keywords. The formal requirement is later in the > document. IIRC the current text there says SHOULD NOT for new apps. Correct. In that case, the note was not responsive to the thread I raised discussing the point that this is a new and substantial change, one that I feel suggests that the title, abstract, and overall structure should be inverted to focus on SHOULD NOT as the key point. It's hard to understand a doc that basically focuses on a change to the spec, and includes the SHOULD NOT almost parenthetically. Joe From jari.arkko@piuha.net Tue Oct 19 15:13:16 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB8D3A6953 for ; Tue, 19 Oct 2010 15:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP6PoQDqpn3Z for ; Tue, 19 Oct 2010 15:13:14 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C217D3A68E3 for ; Tue, 19 Oct 2010 15:13:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BEBBB2CC31; Wed, 20 Oct 2010 01:14:44 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugrUoTX6KItS; Wed, 20 Oct 2010 01:14:44 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B0C9E2CC2F; Wed, 20 Oct 2010 01:14:43 +0300 (EEST) Message-ID: <4CBE1853.9020502@piuha.net> Date: Wed, 20 Oct 2010 01:14:43 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Joe Touch References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.com> <4CB8CC43.8080305@isi.edu> <4CB8CEE1.8070408@piuha.net> <4CBE1739.6040203@isi.edu> In-Reply-To: <4CBE1739.6040203@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" , David Borman , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Oct 2010 22:13:17 -0000 Joe, I think I agree with you. I was not planning on holding on to a Discuss for that part, however. Jari Joe Touch kirjoitti: > > > On 10/15/2010 3:00 PM, Jari Arkko wrote: >> Joe, >> >> Just a quick response on one point: >> >>> - based on the note from Jari, I can't tell whether the >>> doc is recommending SHOULD NOT for new apps or not >> >> My text did not change that aspect in any way. The new text is in the >> introduction and has no keywords. The formal requirement is later in the >> document. IIRC the current text there says SHOULD NOT for new apps. > > Correct. In that case, the note was not responsive to the thread I > raised discussing the point that this is a new and substantial change, > one that I feel suggests that the title, abstract, and overall > structure should be inverted to focus on SHOULD NOT as the key point. > > It's hard to understand a doc that basically focuses on a change to > the spec, and includes the SHOULD NOT almost parenthetically. > > Joe > From touch@isi.edu Tue Oct 19 15:21:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3581C3A6914 for ; Tue, 19 Oct 2010 15:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 l72kQXqRBLJ0 for ; Tue, 19 Oct 2010 15:21:01 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id F08043A6868 for ; Tue, 19 Oct 2010 15:21:00 -0700 (PDT) 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 o9JMMJII004761 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 19 Oct 2010 15:22:19 -0700 (PDT) Message-ID: <4CBE1A1B.6040306@isi.edu> Date: Tue, 19 Oct 2010 15:22:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Jari Arkko References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.com> <4CB8CC43.8080305@isi.edu> <4CB8CEE1.8070408@piuha.net> <4CBE1739.6040203@isi.edu> <4CBE1853.9020502@piuha.net> In-Reply-To: <4CBE1853.9020502@piuha.net> Content-Type: multipart/mixed; boundary="------------040206020807040400090603" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" , David Borman , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 19 Oct 2010 22:21:03 -0000 This is a multi-part message in MIME format. --------------040206020807040400090603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hmm. That was the issue that the discuss I thought that Ron was holding was focused on (see attached) Ron? Joe On 10/19/2010 3:14 PM, Jari Arkko wrote: > Joe, I think I agree with you. I was not planning on holding on to a > Discuss for that part, however. > > Jari > > Joe Touch kirjoitti: >> >> >> On 10/15/2010 3:00 PM, Jari Arkko wrote: >>> Joe, >>> >>> Just a quick response on one point: >>> >>>> - based on the note from Jari, I can't tell whether the >>>> doc is recommending SHOULD NOT for new apps or not >>> >>> My text did not change that aspect in any way. The new text is in the >>> introduction and has no keywords. The formal requirement is later in the >>> document. IIRC the current text there says SHOULD NOT for new apps. >> >> Correct. In that case, the note was not responsive to the thread I >> raised discussing the point that this is a new and substantial change, >> one that I feel suggests that the title, abstract, and overall >> structure should be inverted to focus on SHOULD NOT as the key point. >> >> It's hard to understand a doc that basically focuses on a change to >> the spec, and includes the SHOULD NOT almost parenthetically. >> >> Joe >> --------------040206020807040400090603 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id o8RJo4kH025419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 27 Sep 2010 12:50:04 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by vapor.isi.edu (8.13.8/8.13.8) with SMTP id o8RJnNYH027920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 27 Sep 2010 12:49:34 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTKD1QvTQMKGRRi6fO5HFG2cMhZywJSTc@postini.com; Mon, 27 Sep 2010 12:49:34 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 27 Sep 2010 12:49:07 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 27 Sep 2010 15:49:07 -0400 From: Ronald Bonica To: Joe Touch , John Heffner CC: "tcpm@ietf.org" Date: Mon, 27 Sep 2010 15:49:05 -0400 Subject: RE: [tcpm] draft-ietf-tcpm-urgent-data-06 Thread-Topic: [tcpm] draft-ietf-tcpm-urgent-data-06 Thread-Index: ActbjsFGrv3wolLlSYWW7g6qi3MO7AC7dyCQ Message-ID: <13205C286662DE4387D9AF3AC30EF456B018164416@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456B0172D9C98@EMBX01-WF.jnpr.net> <4C9C0A49.1000502@isi.edu> In-Reply-To: <4C9C0A49.1000502@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: rbonica@juniper.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id o8RJo4kH025419 Joe, I think that you have hit the nail on the head. Reading through Sections 1-5, I thought that we were trying to fix the feature. Only in Section 6 did I realize that we really wanted to drive a stake through its heart. Maybe if we changed the title and added some test to the abstract and introduction, this would be better. Otherwise, people may spend time and money fixing the TCP Urgent option instead of just avoiding it. > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Thursday, September 23, 2010 10:18 PM > To: John Heffner > Cc: Ronald Bonica; tcpm@ietf.org > Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 > > > > On 9/23/2010 6:00 PM, John Heffner wrote: > > My understanding is that deprecating urgent data is exactly what this > > document is doing. In section 5: "... new applications SHOULD NOT > > employ the TCP urgent mechanism." The rest of the document is > largely > > a justification for deprecating the mechanism. > > And a clarification as to what byte the urgent data actually starts at. > The spec doesn't match any of the implementations, and since there's no > benefit to either variant, the WG decided to change the spec to match > the extant implementations. See section 4. > > This is NOT an enhancement, and is NOT intended to make future apps > more > likely to use the urgent mechanism. See section 6, which deprecates the > feature. > > Is there a question that, e.g., the title be updated to reflect the > primary intent, i.e.,"Deprecating TCP's Urgent Mechanism", with a few > other related changes (e.g., update the abstract/intro, move section 6 > forward, and then explain that the remainder of the doc is to document > how existing apps work?)? > > I could see how the current doc reads more like "we're updating the > spec > first. oh yeah, and don't use this", which seems inverted; the WG > conclusion was more like "deprecate this. and oh yeah, here's how it > really works in the few apps that we know of that actually use it" > > Joe > > > > > -John > > > > > > On Thu, Sep 23, 2010 at 5:10 PM, Ronald Bonica > wrote: > >> Folks, > >> > >> The purpose of this email is to encourage the TCPM working group to > deprecate the feature described in draft-ietf-tcpm-urgent-data-06. > >> > >> I understand the following statements to be true: > >> > >> - The WG discourages new applications from using the feature. > >> - Many middle-boxes defeat the feature by removing the urgent data > indicator. Therefore, when an application indicates that data is > urgent, it is never sure that that indication will reach the remote > TCP. > >> - Only three applications have been identified as using the feature. > These are a proprietary application, telnet and ftp. More elegant > mechanisms are available to Telnet and FTP. > >> - The feature is rarely implemented as specified. > >> > >> Finally, there are more elegant ways to bring urgent data to > applications. > >> > >> IMHO, this feature should be deprecated, not enhanced. Let's not > pass up this opportunity to simplify the TCP stack. > >> > >> Ron > >> > >> _______________________________________________ > >> 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 --------------040206020807040400090603-- From rbonica@juniper.net Tue Oct 19 17:47: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 A94F43A690F for ; Tue, 19 Oct 2010 17:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 FDuezSgOyLvH for ; Tue, 19 Oct 2010 17:47:25 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 4263F3A6976 for ; Tue, 19 Oct 2010 17:47:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTL48aUaVXZd8T6WSiHsLopaDVfhL7NjI@postini.com; Tue, 19 Oct 2010 17:48:58 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Oct 2010 17:46:01 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 19 Oct 2010 20:46:00 -0400 From: Ronald Bonica To: Joe Touch , Jari Arkko Date: Tue, 19 Oct 2010 20:45:58 -0400 Thread-Topic: [tcpm] draft-ietf-tcpm-urgent-data-06 Thread-Index: Actv3CHEFMqbUCe7Tw64aJjjolTCAAAE/mLQ Message-ID: <13205C286662DE4387D9AF3AC30EF456B021143F22@EMBX01-WF.jnpr.net> References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.com> <4CB8CC43.8080305@isi.edu> <4CB8CEE1.8070408@piuha.net> <4CBE1739.6040203@isi.edu> <4CBE1853.9020502@piuha.net> <4CBE1A1B.6040306@isi.edu> In-Reply-To: <4CBE1A1B.6040306@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" , David Borman , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Oct 2010 00:47:26 -0000 I cleared, letting Jari hold the DISCUSS. Ron > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, October 19, 2010 6:22 PM > To: Jari Arkko > Cc: David Borman; tcpm@ietf.org Extensions; Fernando Gont > Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 >=20 > Hmm. That was the issue that the discuss I thought that Ron was holding > was focused on (see attached) >=20 > Ron? >=20 > Joe >=20 > On 10/19/2010 3:14 PM, Jari Arkko wrote: > > Joe, I think I agree with you. I was not planning on holding on to a > > Discuss for that part, however. > > > > Jari > > > > Joe Touch kirjoitti: > >> > >> > >> On 10/15/2010 3:00 PM, Jari Arkko wrote: > >>> Joe, > >>> > >>> Just a quick response on one point: > >>> > >>>> - based on the note from Jari, I can't tell whether the doc is > >>>> recommending SHOULD NOT for new apps or not > >>> > >>> My text did not change that aspect in any way. The new text is in > >>> the introduction and has no keywords. The formal requirement is > >>> later in the document. IIRC the current text there says SHOULD NOT > for new apps. > >> > >> Correct. In that case, the note was not responsive to the thread I > >> raised discussing the point that this is a new and substantial > >> change, one that I feel suggests that the title, abstract, and > >> overall structure should be inverted to focus on SHOULD NOT as the > key point. > >> > >> It's hard to understand a doc that basically focuses on a change to > >> the spec, and includes the SHOULD NOT almost parenthetically. > >> > >> Joe > >> From david.borman@windriver.com Tue Oct 19 19:17:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9CAC3A697B for ; Tue, 19 Oct 2010 19:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.424 X-Spam-Level: X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 pACqJ3ijNVZg for ; Tue, 19 Oct 2010 19:17:23 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id B21F43A693E for ; Tue, 19 Oct 2010 19:17:23 -0700 (PDT) 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 o9K2IoMt004360; Tue, 19 Oct 2010 19:18:51 -0700 (PDT) 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); Tue, 19 Oct 2010 19:18:50 -0700 Received: from [172.25.44.11] ([172.25.44.11]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Oct 2010 19:18:50 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <4CBE1739.6040203@isi.edu> Date: Tue, 19 Oct 2010 21:18:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.com> <4CB8CC43.8080305@isi.edu> <4CB8CEE1.8070408@piuha.net> <4CBE1739.6040203@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 20 Oct 2010 02:18:50.0736 (UTC) FILETIME=[228E6F00:01CB6FFD] Cc: "tcpm@ietf.org Extensions" , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Oct 2010 02:17:24 -0000 On Oct 19, 2010, at 5:10 PM, Joe Touch wrote: >=20 >=20 > On 10/15/2010 3:00 PM, Jari Arkko wrote: >> Joe, >>=20 >> Just a quick response on one point: >>=20 >>> - based on the note from Jari, I can't tell whether the >>> doc is recommending SHOULD NOT for new apps or not >>=20 >> My text did not change that aspect in any way. The new text is in the >> introduction and has no keywords. The formal requirement is later in = the >> document. IIRC the current text there says SHOULD NOT for new apps. >=20 > Correct. In that case, the note was not responsive to the thread I = raised discussing the point that this is a new and substantial change, = one that I feel suggests that the title, abstract, and overall structure = should be inverted to focus on SHOULD NOT as the key point. >=20 > It's hard to understand a doc that basically focuses on a change to = the spec, and includes the SHOULD NOT almost parenthetically. We're not trying to deprecate the URGENT pointer. The goal is to first = align the spec with the implementations, and then point out issues with = the URGENT pointer, which is how the doc is currently structured. I = don't want the "SHOULD NOT" to be the main point of this document, it is = a secondary point due to the issues listed. The SHOULD NOT applies to = new applications, and it means "If you really want to make use of the = URGENT pointer, make sure you understand and have addressed all the = issues pointed out in this document." The SHOULD NOT for application writers using the URGENT pointer, not for = the URGENT pointer support in the TCP implementations. I have no = objections to the additional highlighting of this, but that doesn't make = it the key point of the document. I say leave the document as it is. -David Borman >=20 > Joe From touch@isi.edu Tue Oct 19 21:42:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60C23A69A8 for ; Tue, 19 Oct 2010 21:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 lMJdBZRVodhb for ; Tue, 19 Oct 2010 21:42:37 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id CE6173A69A3 for ; Tue, 19 Oct 2010 21:42:37 -0700 (PDT) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o9K4hBQK018289 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 19 Oct 2010 21:43:21 -0700 (PDT) Message-ID: <4CBE735E.7040501@isi.edu> Date: Tue, 19 Oct 2010 21:43:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Borman References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.com> <4CB8CC43.8080305@isi.edu> <4CB8CEE1.8070408@piuha.net> <4CBE1739.6040203@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" , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Oct 2010 04:42:39 -0000 Hi, Dave, One additional point (while I wait to see if Ron agrees with your summary); the current discussion of in-line data still needs to be revised to avoid relying primarily on the definition of a particular interface (SO_OOBINLINE). As to your point, IMO *every* aspect of a protocol is SHOULD NOT by your definition, i.e., every capability should not be used unless its implications, side-effects, and nuances are understood. To me, SHOULD NOT on an existing, required protocol capability effectively relegates it to "deprecated", i.e., there to support legacy apps. There's no point in a MUST NOT on such a capability - MUST NOT would mistakenly suggest that the capability need not be implemented anymore. Joe On 10/19/2010 7:18 PM, David Borman wrote: > > On Oct 19, 2010, at 5:10 PM, Joe Touch wrote: > >> >> >> On 10/15/2010 3:00 PM, Jari Arkko wrote: >>> Joe, >>> >>> Just a quick response on one point: >>> >>>> - based on the note from Jari, I can't tell whether the >>>> doc is recommending SHOULD NOT for new apps or not >>> >>> My text did not change that aspect in any way. The new text is in the >>> introduction and has no keywords. The formal requirement is later in the >>> document. IIRC the current text there says SHOULD NOT for new apps. >> >> Correct. In that case, the note was not responsive to the thread I raised discussing the point that this is a new and substantial change, one that I feel suggests that the title, abstract, and overall structure should be inverted to focus on SHOULD NOT as the key point. >> >> It's hard to understand a doc that basically focuses on a change to the spec, and includes the SHOULD NOT almost parenthetically. > > We're not trying to deprecate the URGENT pointer. The goal is to first align the spec with the implementations, and then point out issues with the URGENT pointer, which is how the doc is currently structured. I don't want the "SHOULD NOT" to be the main point of this document, it is a secondary point due to the issues listed. The SHOULD NOT applies to new applications, and it means "If you really want to make use of the URGENT pointer, make sure you understand and have addressed all the issues pointed out in this document." > > The SHOULD NOT for application writers using the URGENT pointer, not for the URGENT pointer support in the TCP implementations. I have no objections to the additional highlighting of this, but that doesn't make it the key point of the document. I say leave the document as it is. > > -David Borman > >> >> Joe > From jari.arkko@piuha.net Tue Oct 19 23:15:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27BFB3A6403 for ; Tue, 19 Oct 2010 23:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Neh-QjjP6LIp for ; Tue, 19 Oct 2010 23:15:37 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 127093A69CA for ; Tue, 19 Oct 2010 23:15:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 453072CC43; Wed, 20 Oct 2010 09:17:08 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDOVoNF42cry; Wed, 20 Oct 2010 09:17:07 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B62A82CC2F; Wed, 20 Oct 2010 09:17:07 +0300 (EEST) Message-ID: <4CBE8962.8020602@piuha.net> Date: Wed, 20 Oct 2010 09:17:06 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Joe Touch References: <201009301549.RAA14282@TR-Sys.de> <13205C286662DE4387D9AF3AC30EF456B01839E20B@EMBX01-WF.jnpr.net> <31679F6B-0ACA-421F-8131-DA05B764A4A9@nokia.com> <13205C286662DE4387D9AF3AC30EF456B0201C2D1C@EMBX01-WF.jnpr.net> <4CB31ECF.6040307@gont.com.ar>, <1D4E3C6E-B0BF-4CAC-A01E-EC9CDAC14EE0@nokia.com> <4CB3CCBB.1030400@isi.edu> <675AC39A-0E6D-4014-850B-2A05389577C4@windriver.com> <4CB488F2.1070800@isi.edu> <4CB48DCE.7010606@isi.edu> <4CB8C1CF.1020106@piuha.net> <30410F46-8F64-4988-B6ED-73ECFB7F59E9@windriver.com> <4CB8CC43.8080305@isi.edu> <4CB8CEE1.8070408@piuha.net> <4CBE1739.6040203@isi.edu> <4CBE1853.9020502@piuha.net> <4CBE1A1B.6040306@isi.edu> In-Reply-To: <4CBE1A1B.6040306@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" , David Borman , Fernando Gont Subject: Re: [tcpm] draft-ietf-tcpm-urgent-data-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 20 Oct 2010 06:15:39 -0000 Joe, Yes, there were several concerned ADs. After a discussion on the list and in the IESG it was my opinion that the changes that I suggested were a sufficient compromise to make the document acceptable. I would personally (and Ron too) wanted to go further, indeed make the SHOULD NOT a major point in the document. But I chose not to make that a part of a blocking comment. It is of course always tricky when one AD is representing concerns from others as well as himself. It was my interpretation that what we did is an acceptable way forward, but it could of course happen that Ron or others feel strongly and want to Discuss further. Jari From mattmathis@google.com Thu Oct 21 11:12: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 83F563A6A2F for ; Thu, 21 Oct 2010 11:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.463 X-Spam-Level: X-Spam-Status: No, score=-105.463 tagged_above=-999 required=5 tests=[AWL=0.514, 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 bumvW15x-1O0 for ; Thu, 21 Oct 2010 11:12:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8E03A3A6452 for ; Thu, 21 Oct 2010 11:12:47 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o9LIEMNe027026 for ; Thu, 21 Oct 2010 11:14:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287684863; bh=yrWTs3IdORtilR3UQNR31z6EI6Q=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=WnRsfFn9t4ybeprzq/PiQdp4HchAxj3oXH+5C+vmFy5BQz6ZflUv1XoFpWqjaIefa klcrgSaZebbolJ/PsVyEQ== Received: from ewy28 (ewy28.prod.google.com [10.241.103.28]) by kpbe18.cbf.corp.google.com with ESMTP id o9LIDKIL002670 for ; Thu, 21 Oct 2010 11:14:21 -0700 Received: by ewy28 with SMTP id 28so337380ewy.41 for ; Thu, 21 Oct 2010 11:14:21 -0700 (PDT) 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 :content-transfer-encoding; bh=zer1pRkKUCdGX5qmscjAZD2lQJWqkApjYB+CMyEGnLI=; b=gpk5n6bfMJ1Z7ZEsUbk7pWSE/UR+Wn3a1dogrooMDmleqphCigyJC1sDG3gfQuN1vq ouN32gQqKG2VZHKazBfQ== 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:content-transfer-encoding; b=Iu3GrFqS9gATT2DPGMe9xxM4bWiNhMcy+f1jRNDEMRrTOt+8Y6TBO6/iBLchbAT5fN sL9q/JTJKyzAshL75HIg== MIME-Version: 1.0 Received: by 10.213.21.133 with SMTP id j5mr2087413ebb.95.1287684859645; Thu, 21 Oct 2010 11:14:19 -0700 (PDT) Received: by 10.213.20.2 with HTTP; Thu, 21 Oct 2010 11:14:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Oct 2010 11:14:19 -0700 Message-ID: From: Matt Mathis To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: TCP Maintenance and Minor Extensions WG Subject: Re: [tcpm] 3517 update w/ SACK-entry draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Oct 2010 18:12:53 -0000 A couple of comments: =A0There is an errata against 2018 about the requirement that timeouts MUST clear the score board. =A0 From the errata: "At least one OS (Linux) violates the MUST to good effect: Even when timeou= t driven, it keeps old SACK data so it can avoid retransmitting data already = at the receiver. Thus even under severe bandwidth exhaustion, 100% of the data delivered to the receiver causes forward progress and the system is not sub= ject to classical congestion collapse (that is, congestion collapse from unnecessarily-retransmitted packets)." It would be better to update section 5.1 of 3517bis to reflect this. Note that the errata introduces several caveats and and additional issues that need to be addressed. Also there is another issue that should be introduced in the security considerations section: Traditional recovery mechanism serve to protect the Internet from implementers who change congestion control to make it too aggressive, because doing so tends to increase the probability of timeouts, and often reduces overall throuthput. This creates a strong disincentive to deploying extra aggressive congestion control. As recovery algorithms improve, this disincentive is reduced. In the limit an ideal recovery mechanism might never suffer from a timeout except after losing an entire window of data or ACKs. Such a recovery algorithm might create an incentive to deploy arbitrarily aggressive congestion control. The algorithms presented in this document are are believed to reduce the negative consequence of making congestion control more aggressive than permitted by RFC 5681. -- On other issue: would this be an appropriate time (and doc) to introduce some other ideas from our rate halving work from ages ago? Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay On Sun, Oct 17, 2010 at 10:06 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > As Markku mentioned on the mailing list some time ago, and discussed in A= naheim, the authors of draft-ietf-tcpm-sack-recovery and RFC 3517 have disc= ussed merging the changes that the sack-recovery draft introduces into an u= pdate to RFC 3517. =A0This makes a lot of sense, and simplifies the documen= t tree we create a bit. > > At this point, they're almost ready to submit the merged document, and wa= nt to confirm this path with the working group so they can figure out what = to name it (draft-ietf-tcpm, or draft-lastname-tcpm). =A0We know that in An= aheim, Lars was concerned with the timeframe this merging might take, but t= here are no errata on 3517, and the sack-recovery work is felt to be comple= te by the authors, so the merging has good odds of completing quickly. > > If there are any objections to the merged document in preparation replaci= ng the sack-recovery working group draft (as a working group item), please = bring them up in the next couple weeks. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From rs@netapp.com Thu Oct 21 15:21: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 A3F833A63EC for ; Thu, 21 Oct 2010 15:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.464 X-Spam-Level: X-Spam-Status: No, score=-8.464 tagged_above=-999 required=5 tests=[AWL=2.135, 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 hTfkCAS32Q85 for ; Thu, 21 Oct 2010 15:21:03 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id E95AB3A63C9 for ; Thu, 21 Oct 2010 15:21:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,219,1286175600"; d="scan'208";a="222203338" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 21 Oct 2010 15:22:38 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9LMMbuj016488; Thu, 21 Oct 2010 15:22:37 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Oct 2010 23:22:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2010 23:22:36 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0AF5C2CA@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] 3517 update w/ SACK-entry draft Thread-Index: ActxS9ao3bceY6/8QOCcTid88nfscwAH5AGA References: From: "Scheffenegger, Richard" To: "Matt Mathis" X-OriginalArrivalTime: 21 Oct 2010 22:22:38.0189 (UTC) FILETIME=[77E2E1D0:01CB716E] Cc: TCP Maintenance and Minor Extensions WG Subject: Re: [tcpm] 3517 update w/ SACK-entry draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Oct 2010 22:21:04 -0000 =20 > -----Original Message----- > From: Matt Mathis [mailto:mattmathis@google.com]=20 >=20 > As recovery algorithms improve, this disincentive is reduced.=20 > In the limit an ideal recovery mechanism might never suffer=20 > from a timeout except after losing an entire window of data=20 > or ACKs. Such a recovery algorithm might create an incentive=20 > to deploy arbitrarily aggressive congestion control. The=20 > algorithms presented in this document are are believed to=20 > reduce the negative consequence of making congestion control=20 > more aggressive than permitted by RFC 5681. Based on this statement, what does that mean for lost retransmission detection, as implemented and deployed by Linux? Would such a more ideal recovery mechanism be considered unfit for adoption as an RFC then? > -- > On other issue: would this be an appropriate time (and doc)=20 > to introduce some other ideas from our rate halving work from=20 > ages ago? >=20 As you know, my viewpoint is, that rate halving (which is implemented in some form in Linux and also current BSD stacks) should at least be (informally) documented - just like lost retransmission detection (either the way Linux is doing it, or in an idealized model). Following up on my recent email, I'm currently investigating the special case of loss recovery close to the end of stream, where SACK (and LRD) fail to prevent RTOs reliably. Using SACK and timestamp information, LRD can be made to work near optimal (no superfluous retransmits), improving upon what Linux is already doing... However, I would welcome any guidance the members of this group would like to provide, before submitting my I-D on end-of-stream SACK (LRD) behavior. Thanks a lot, Richard From ycheng@google.com Thu Oct 21 18:12:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B6E3A6821 for ; Thu, 21 Oct 2010 18:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.577 X-Spam-Level: X-Spam-Status: No, score=-103.577 tagged_above=-999 required=5 tests=[AWL=2.400, 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 bKhNYmIosbgo for ; Thu, 21 Oct 2010 18:12:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7BD853A67DB for ; Thu, 21 Oct 2010 18:12:28 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o9M1E4bP028205 for ; Thu, 21 Oct 2010 18:14:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287710044; bh=Gb8H4DjrftByzXDA4BxYwHLesbs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=sbVN96inTzJtVRamzivKV4V8S+6C8cRyLOzO96vIMddt9wqTKl6b26FDNwxF6hPY7 c4UBefkSUKW9ewEQNO40w== Received: from gyd12 (gyd12.prod.google.com [10.243.49.204]) by hpaq13.eem.corp.google.com with ESMTP id o9M1E3tT005944 for ; Thu, 21 Oct 2010 18:14:03 -0700 Received: by gyd12 with SMTP id 12so161041gyd.30 for ; Thu, 21 Oct 2010 18:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=OuCyKQpS4pfhY7Tj59ZvPbcWwDUQescjMslNf8vkEb0=; b=qwDhQ41b9Himnrj64wtkKQRnNrspABcbhIztqqLAFZkqdnMI45e/dD601fS+BKk6ao 814Fw94Yx7iKCCfGZltg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=SrRpMW/X3tfqWr46DXgMXfHqgwZM0oP69ldWWNjrBcXJWs7uoDW1WlQRFw2lYRLB0h RSNTK6BRTnHUSquiDqpw== Received: by 10.42.209.143 with SMTP id gg15mr1186034icb.467.1287710042738; Thu, 21 Oct 2010 18:14:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.191.10 with HTTP; Thu, 21 Oct 2010 18:13:42 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> From: Yuchung Cheng Date: Thu, 21 Oct 2010 18:13:42 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tcpm@ietf.org, Matthew Mathis , mallman@icir.org Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Oct 2010 01:12:40 -0000 On Fri, Oct 8, 2010 at 7:36 AM, Scheffenegger, Richard wrote: > > Consider a sequence of 4 Segments sent, S1 .. S4; S2 and S4 get dropped. > > Early Retransmit (RFC5827) will allow entering loss recovery. > > Depending on TCP SACK, or TCP NewReno, the behavior will be different: > > NewReno will retransmit S2; > The ACK for S3 will trigger retransmission of S4 (and nobody got hurt) NewReno will not retransmit S4 because the ACK elicited by S3 is a DUP-ACK, not a partial ACK (Step 5 in RFC 2582). W/o additional intelligence, I don't think it's a good idea to retransmit S4 because the DUP-ACK sacking S4 often come right after the ACK of S2. Cheers, Yuchung From rs@netapp.com Thu Oct 21 19:54: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 DCBD13A682F for ; Thu, 21 Oct 2010 19:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.529 X-Spam-Level: X-Spam-Status: No, score=-8.529 tagged_above=-999 required=5 tests=[AWL=2.070, 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 fa7wJlB5hBCz for ; Thu, 21 Oct 2010 19:54:43 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 3281B3A67FA for ; Thu, 21 Oct 2010 19:54:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,221,1286175600"; d="scan'208";a="222233400" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 21 Oct 2010 19:56:19 -0700 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 o9M2uIZn004022; Thu, 21 Oct 2010 19:56:18 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Oct 2010 04:56:18 +0200 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: Fri, 22 Oct 2010 03:56:13 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0AF5C2D2@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) Thread-Index: Actxhm25UQr+pDQnSD6MgKMyPqQnTwACoVTw References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> From: "Scheffenegger, Richard" To: "Yuchung Cheng" X-OriginalArrivalTime: 22 Oct 2010 02:56:18.0837 (UTC) FILETIME=[B35AEC50:01CB7194] Cc: tcpm@ietf.org, Matthew Mathis , mallman@icir.org Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Oct 2010 02:54:46 -0000 Yuchung, > > Consider a sequence of 4 Segments sent, S1 .. S4; S2 and S4=20 > > get dropped.=20 sorry for the appreviated example. A more complete example would have been S1..S6 with S2 and S6 getting = lost, and a window of >=3D6 when recovery is triggered, to avoid any = confusion. > > NewReno will retransmit S2; > > The ACK for S3 will trigger retransmission of S4 (and=20 > > nobody got hurt) >=20 > NewReno will not retransmit S4 because the ACK elicited by S3=20 > is a DUP-ACK, not a partial ACK (Step 5 in RFC 2582). The initial S3 will cause a DUP-ACK (of S1) > W/o additional intelligence, I don't think it's a good idea=20 > to retransmit S4 because the DUP-ACK sacking S4 often come=20 > right after the ACK of S2. The retransmission of S2 will cause a Full Ack of S3, that will trigger = the retransmission of S4 (with NewReno). There won't be any ACK for S2; = only S1;S1;S3 (and eventually S4). Let me paste two traces, both between the same hosts, same network, same = drop pattern (93001 (newreno)/95001(sack) and 99001 are dropped at first = transmit). Only difference is NewReno vs. SACK. These were recorded on = the receiver side, and timed such that the sender would end up in = recovery mode until after the last segment of the stream.=20 Note the time-delta when 99001 is retransmitted.... NewReno IS retransmitting the S4 in the original example, while SACK is = not... NewReno: 0.000009 A -> B TCP 93001 1 5888 48709 > 5001 [ACK] Seq=3D93001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D375481555 TSecr=3D15736607 [drop] 0.000005 A -> B TCP 94001 1 5888 48709 > 5001 [ACK] Seq=3D94001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D375481555 TSecr=3D15736607 0.000012 B -> A TCP 1 93001 990528 5001 > 48709 [ACK] Seq=3D1 = Ack=3D93001 Win=3D990528 Len=3D0 TSval=3D15736608 TSecr=3D375481555 0.000029 A -> B TCP 95001 1 5888 48709 > 5001 [ACK] Seq=3D95001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D375481555 TSecr=3D15736607 0.000012 B -> A TCP 1 93001 990528 5001 > 48709 [ACK] Seq=3D1 = Ack=3D93001 Win=3D990528 Len=3D0 TSval=3D15736608 TSecr=3D375481555 [TCP = Dup ACK 150#1] 0.000044 A -> B TCP 96001 1 5888 48709 > 5001 [ACK] Seq=3D96001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D375481555 TSecr=3D15736607 0.000011 B -> A TCP 1 93001 990528 5001 > 48709 [ACK] Seq=3D1 = Ack=3D93001 Win=3D990528 Len=3D0 TSval=3D15736608 TSecr=3D375481555 [TCP = Dup ACK 150#2]=20 0.000078 A -> B TCP 97001 1 5888 48709 > 5001 [ACK] Seq=3D97001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D375481555 TSecr=3D15736608 0.000012 B -> A TCP 1 93001 990528 5001 > 48709 [ACK] Seq=3D1 = Ack=3D93001 Win=3D990528 Len=3D0 TSval=3D15736608 TSecr=3D375481555 [TCP = Dup ACK 150#3]=20 0.000029 A -> B TCP 98001 1 5888 48709 > 5001 [ACK] Seq=3D98001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D375481555 TSecr=3D15736608 0.000011 B -> A TCP 1 93001 990528 5001 > 48709 [ACK] Seq=3D1 = Ack=3D93001 Win=3D990528 Len=3D0 TSval=3D15736608 TSecr=3D375481555 [TCP = Dup ACK 150#4]=20 0.000029 A -> B TCP 99001 1 5888 48709 > 5001 [FIN, PSH, ACK] = Seq=3D99001 Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D375481555 = TSecr=3D15736608 [drop] 0.000099 B -> A TCP 1 93001 998720 5001 > 48709 [ACK] Seq=3D1 = Ack=3D93001 Win=3D998720 Len=3D0 TSval=3D15736608 TSecr=3D375481555 [TCP = Window Update] 0.000151 B -> A TCP 1 93001 1006912 5001 > 48709 [ACK] Seq=3D1 = Ack=3D93001 Win=3D1006912 Len=3D0 TSval=3D15736608 TSecr=3D375481555 = [TCP Window Update]=20 0.000126 A -> B TCP 93001 1 5888 48709 > 5001 [ACK] Seq=3D93001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D375481555 TSecr=3D15736608 [TCP = Out-Of-Order] 0.000017 B -> A TCP 1 99001 1000960 5001 > 48709 [ACK] Seq=3D1 = Ack=3D99001 Win=3D1000960 Len=3D0 TSval=3D15736609 TSecr=3D375481555 0.000116 B -> A TCP 1 99001 1009152 5001 > 48709 [ACK] Seq=3D1 = Ack=3D99001 Win=3D1009152 Len=3D0 TSval=3D15736609 TSecr=3D375481555 = [TCP Window Update] 0.000151 B -> A TCP 1 99001 1017344 5001 > 48709 [ACK] Seq=3D1 = Ack=3D99001 Win=3D1017344 Len=3D0 TSval=3D15736609 TSecr=3D375481555 = [TCP Window Update] 0.000119 A -> B TCP 99001 1 5888 48709 > 5001 [FIN, PSH, ACK] = Seq=3D99001 Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D375481555 = TSecr=3D15736609 [TCP Out-Of-Order] 0.000016 B -> A TCP 1 100002 1016320 5001 > 48709 [ACK] Seq=3D1 = Ack=3D100002 Win=3D1016320 Len=3D0 TSval=3D15736609 TSecr=3D375481555 0.000125 B -> A TCP 1 100002 1024512 5001 > 48709 [ACK] Seq=3D1 = Ack=3D100002 Win=3D1024512 Len=3D0 TSval=3D15736609 TSecr=3D375481555 = [TCP Window Update]=20 0.000150 B -> A TCP 1 100002 1032704 5001 > 48709 [ACK] Seq=3D1 = Ack=3D100002 Win=3D1032704 Len=3D0 TSval=3D15736609 TSecr=3D375481555 = [TCP Window Update]=20 0.000148 B -> A TCP 1 100002 1040896 5001 > 48709 [ACK] Seq=3D1 = Ack=3D100002 Win=3D1040896 Len=3D0 TSval=3D15736609 TSecr=3D375481555 = [TCP Window Update]=20 0.000166 B -> A TCP 1 100002 1048960 5001 > 48709 [ACK] Seq=3D1 = Ack=3D100002 Win=3D1048960 Len=3D0 TSval=3D15736610 TSecr=3D375481555 = [TCP Window Update]=20 0.000206 B -> A TCP 1 100002 1048960 5001 > 48709 [FIN, ACK] Seq=3D1 = Ack=3D100002 Win=3D1048960 Len=3D0 TSval=3D15736610 TSecr=3D375481555 0.001338 A -> B TCP 100002 2 5888 48709 > 5001 [ACK] Seq=3D100002 = Ack=3D2 Win=3D5888 Len=3D0 TSval=3D375481556 TSecr=3D15736610 SACK: 0.000006 A -> B TCP 95001 1 5888 60934 > 5001 [ACK] Seq=3D95001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D367716224 TSecr=3D3613608261 = [drop] 0.000006 A -> B TCP 96001 1 5888 60934 > 5001 [ACK] Seq=3D96001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D367716224 TSecr=3D3613608261 0.000005 A -> B TCP 97001 1 5888 60934 > 5001 [ACK] Seq=3D97001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D367716224 TSecr=3D3613608261 0.000006 A -> B TCP 98001 1 5888 60934 > 5001 [ACK] Seq=3D98001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D367716224 TSecr=3D3613608261 0.000066 A -> B TCP 99001 1 5888 60934 > 5001 [FIN, PSH, ACK] = Seq=3D99001 Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D367716224 = TSecr=3D3613608261 [drop] 0.003322 B -> A TCP 1 90001 1046976 5001 > 60934 [ACK] Seq=3D1 = Ack=3D90001 Win=3D1046976 Len=3D0 TSval=3D3613608265 TSecr=3D367716224 0.000078 B -> A TCP 1 92001 1044992 5001 > 60934 [ACK] Seq=3D1 = Ack=3D92001 Win=3D1044992 Len=3D0 TSval=3D3613608265 TSecr=3D367716224 0.000032 B -> A TCP 1 94001 1042944 5001 > 60934 [ACK] Seq=3D1 = Ack=3D94001 Win=3D1042944 Len=3D0 TSval=3D3613608265 TSecr=3D367716224 0.000032 B -> A TCP 1 95001 1041984 5001 > 60934 [ACK] Seq=3D1 = Ack=3D95001 Win=3D1041984 Len=3D0 TSval=3D3613608265 TSecr=3D367716224 = SLE=3D96001 SRE=3D97001 0.000032 B -> A TCP 1 95001 1041984 5001 > 60934 [ACK] Seq=3D1 = Ack=3D95001 Win=3D1041984 Len=3D0 TSval=3D3613608265 TSecr=3D367716224 = SLE=3D96001 SRE=3D98001 [TCP Dup ACK 163#1]=20 0.000032 B -> A TCP 1 95001 1041984 5001 > 60934 [ACK] Seq=3D1 = Ack=3D95001 Win=3D1041984 Len=3D0 TSval=3D3613608265 TSecr=3D367716224 = SLE=3D96001 SRE=3D99001 [TCP Dup ACK 163#2]=20 0.000032 B -> A TCP 1 95001 1048960 5001 > 60934 [ACK] Seq=3D1 = Ack=3D95001 Win=3D1048960 Len=3D0 TSval=3D3613608265 TSecr=3D367716224 = SLE=3D96001 SRE=3D99001 [TCP Window Update]=20 0.000434 A -> B TCP 95001 1 5888 60934 > 5001 [ACK] Seq=3D95001 = Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D367716225 TSecr=3D3613608265 [TCP = Retransmission]=20 0.003328 B -> A TCP 1 99001 1044992 5001 > 60934 [ACK] Seq=3D1 = Ack=3D99001 Win=3D1044992 Len=3D0 TSval=3D3613608269 TSecr=3D367716225 0.000084 B -> A TCP 1 99001 1048960 5001 > 60934 [ACK] Seq=3D1 = Ack=3D99001 Win=3D1048960 Len=3D0 TSval=3D3613608269 TSecr=3D367716225 = [TCP Window Update]=20 0.202595 A -> B TCP 99001 1 5888 60934 > 5001 [FIN, PSH, ACK] = Seq=3D99001 Ack=3D1 Win=3D5888 Len=3D1000 TSval=3D367716277 = TSecr=3D3613608269 [TCP Retransmission] 0.003322 B -> A TCP 1 100002 1048000 5001 > 60934 [ACK] Seq=3D1 = Ack=3D100002 Win=3D1048000 Len=3D0 TSval=3D3613608475 TSecr=3D367716277 0.000078 B -> A TCP 1 100002 1048960 5001 > 60934 [FIN, ACK] Seq=3D1 = Ack=3D100002 Win=3D1048960 Len=3D0 TSval=3D3613608475 TSecr=3D367716277 0.000473 A -> B TCP 100002 2 5888 60934 > 5001 [ACK] Seq=3D100002 = Ack=3D2 Win=3D5888 Len=3D0 TSval=3D367716277 TSecr=3D3613608475 Richard Scheffenegger Storage Infrastructure Architect Area Deutsche Telekom=20 NetApp rs@netapp.com +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 EURO PLAZA Geb=E4ude G, Stiege 7, 3.OG Am Euro Platz 2 A-1120 Wien =20 > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com]=20 > Sent: Donnerstag, 21. Oktober 2010 21:14 > To: Scheffenegger, Richard > Cc: tcpm@ietf.org; Matthew Mathis; mallman@icir.org > Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) >=20 > On Fri, Oct 8, 2010 at 7:36 AM, Scheffenegger, Richard=20 > wrote: > > > > Consider a sequence of 4 Segments sent, S1 .. S4; S2 and S4=20 > get dropped. > > > > Early Retransmit (RFC5827) will allow entering loss recovery. > > > > Depending on TCP SACK, or TCP NewReno, the behavior will be=20 > different: > > > > NewReno will retransmit S2; > > The ACK for S3 will trigger retransmission of S4 (and=20 > nobody got hurt) >=20 > NewReno will not retransmit S4 because the ACK elicited by S3=20 > is a DUP-ACK, not a partial ACK (Step 5 in RFC 2582). >=20 > W/o additional intelligence, I don't think it's a good idea=20 > to retransmit S4 because the DUP-ACK sacking S4 often come=20 > right after the ACK of S2. >=20 > Cheers, >=20 > Yuchung >=20 From yoshifumi.nishida@gmail.com Fri Oct 22 01:41: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 318473A6800 for ; Fri, 22 Oct 2010 01:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.558 X-Spam-Level: X-Spam-Status: No, score=-101.558 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rcm0V7ep0jtJ for ; Fri, 22 Oct 2010 01:41:48 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 66FB83A6873 for ; Fri, 22 Oct 2010 01:41:48 -0700 (PDT) Received: by wwe15 with SMTP id 15so542548wwe.13 for ; Fri, 22 Oct 2010 01:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=pLaL+xbfbHKtQ3gALwV0o6QmOacLGJI/6CaenaYGcMg=; b=EmZnRlv07X+QpcZN5UejIRmgdJahRfkKmu0cFtLmdSw7/AJSDSFAbNJOsM2xPhcEOy X1julq4/3+ZhOux+xsxK8Rcb9vVlAK+OJ4xcjuixj5BYnq6cxUR67WqgwzhJz6UCbuDR C1/hXuH2grI4qWZPbXFuMVgMnWU5h0fjQBeZQ= 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=Y2fasMwVvenSeEE6D9kdAwG9yqMF0t7BkwK1i/QdpPgUSa/2gzoriQigU27uz8ztjl Hxe8ZgUGV+iG5RquCW1WcpBymMsr+2bHRepNhSlZ16cf18YN1r6YB+UbxE37kcqN2cvZ OB/d2bXBRsKmJgdNrnc6r2tTJ0Ye9UdP6wvvA= MIME-Version: 1.0 Received: by 10.227.152.17 with SMTP id e17mr2421610wbw.95.1287737005289; Fri, 22 Oct 2010 01:43:25 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.216.170.199 with HTTP; Fri, 22 Oct 2010 01:43:25 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> Date: Fri, 22 Oct 2010 01:43:25 -0700 X-Google-Sender-Auth: EEWXZwSGXjXJn56UKB6QSDjmen0 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Oct 2010 08:41:50 -0000 Hello Richard, I think this discussion should be based on rfc3517 since it describes a loss recovery algorithm for TCP SACK. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2010/10/8 Scheffenegger, Richard : > > Hello members of the TCPM group, Matt, Mark, > > > I'm currently looking into the loss recovery behavior of TCP SACK - > especially at the end-of-stream. > > > End-of-stream (case 2) of the small congestion window, as per RFC5827) > is of particular interest, as there are synchronous IO loads over TCP, > that will only deliver additional data to the socket once an application > level acknowledgement has been received. To be precise, single threaded, > synchronous NFS read/write IOs. However that application layer Ack will > only be sent by the receiver, once the complete App IO was received, > thus any stalls can tremendeously delay the IO on the application. > > The analogy would be TCP (with a large MTU) within TCP (with a small > MTU) - which is known to behave sub-optimal. > > > > It appears that RFC2018 has codified behavior, which makes TCP SACK > perform less optimal compared with TCP NewReno, when loss occurs > directly at the last segments of the stream. > > " > 5. Interpreting the Sack Option and Retransmission Strategy: Data > =A0 Sender Behavior > : > : > =A0 After the SACKed bit is turned on (as the result of processing a > =A0 received SACK option), the data sender will skip that segment during > =A0 any later retransmission. =A0Any segment that has the SACKed bit turn= ed > =A0 off and is less than the highest SACKed segment is available for > =A0 retransmission. > " > > This definition leaves out the range [snd_fack .. snd_nxt (at loss > recovery initiation time)]. There is no explanation as to why that > omission was done (other than snd_fack not being defined at the time). > > > As RFC5827 is only concerned about detection and entering loss recovery, > it too gives no advice in this regard. > > Consider a sequence of 4 Segments sent, S1 .. S4; S2 and S4 get dropped. > > Early Retransmit (RFC5827) will allow entering loss recovery. > > Depending on TCP SACK, or TCP NewReno, the behavior will be different: > > NewReno will retransmit S2; > The ACK for S3 will trigger retransmission of S4 (and nobody got hurt) > > SACK will retransmit S2; > The ACK for S3 will *not* trigger a retransmit of S4 (it falls outside > the boundary defined in RFC2018). > Only a RTO will recover S4, and the stream might continue (as > applications resume operation). > > Of course, S4 could be any number of packets, just prior to the > end-of-stream. And the same sequence of events can happen without Early > Retransmit and large cwnds... > > With infinite data to send, after SACK finished loss recovery - at the > highest SACKed (snd_fack) block - the sender would resume sending > starting from snd_nxt (and most likely in slow start). As soon as 3 new > segments would be received, this missing segment chain (snd_fack .. > Former snd_nxt) could be detected and recovered. Of course, counting > this as one additional congestion event (unlike what NewReno would do). > > > Or are SACK implementations which silently ignore the hole between > snd_fack and snd_nxt (when loss recovery is entered) broken? > > > > > I would like to learn what you think would be the proper behavior. From > my point of view, this appears to have been a simple oversight in > RFC2018, and changing the statement to > > > " > 5. Interpreting the Sack Option and Retransmission Strategy: Data > =A0 Sender Behavior > : > : > =A0 After the SACKed bit is turned on (as the result of processing a > =A0 received SACK option), the data sender will skip that segment during > =A0 any later retransmission. =A0Any segment that has the SACKed bit turn= ed > =A0 off and is less than the highest sent segment at the beginning of the > > =A0 SACK recovery episode is available for retransmission. > " > > The fix would be simply add an implicit hole (or an implicit SACK block) > up to snd_nxt. If none of these tailing segments was lost, they will be > covered in an SACK eventually. That would happen before the sender could > retransmit those segments, as cwnd is also reduced thus limiting the > sending rate. > > > > > Richard Scheffenegger > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From wwwrun@core3.amsl.com Fri Oct 22 06:56:06 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6D84528C0E9; Fri, 22 Oct 2010 06:56:06 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20101022135606.6D84528C0E9@core3.amsl.com> Date: Fri, 22 Oct 2010 06:56:06 -0700 (PDT) Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Protocol Action: 'On the implementation of the TCP urgent mechanism' to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 13:56:06 -0000 The IESG has approved the following document: - 'On the implementation of the TCP urgent mechanism ' as a Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact person is Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-07.txt Technical Summary This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, provides advice to applications that make use of the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. Working Group Summary Nothing exceptional occurred during the working group process for this document. Document Quality This document specifically is aimed at bringing the specification and existing implementations into line clearly with each other. The implementation practices in this document have been adopted in multiple implementations and this document provides guidance to aid in future compatibility with applications in new and old TCP implementations. Personnel Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed this document for the IESG. From rs@netapp.com Fri Oct 22 11:24: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 E7AD23A68D1 for ; Fri, 22 Oct 2010 11:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.289 X-Spam-Level: X-Spam-Status: No, score=-8.289 tagged_above=-999 required=5 tests=[AWL=1.710, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 MFmoro1qK3FZ for ; Fri, 22 Oct 2010 11:24:06 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 5AA983A6920 for ; Fri, 22 Oct 2010 11:24:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,224,1286175600"; d="scan'208";a="214505014" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 22 Oct 2010 11:25:43 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (ldcrsexc1-prd.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9MIPhKu014320; Fri, 22 Oct 2010 11:25:43 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Oct 2010 19:25:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Oct 2010 19:25:41 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0B02D269@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) Thread-Index: ActxxTaDbZNyqL9zTZiLEe7ihv+2QQARs11A References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de><49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com><5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> From: "Scheffenegger, Richard" To: "Yoshifumi Nishida" X-OriginalArrivalTime: 22 Oct 2010 18:25:43.0215 (UTC) FILETIME=[8983BBF0:01CB7216] Cc: tcpm@ietf.org Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Oct 2010 18:24:08 -0000 Thank you Yoshifumi-san, I agree; it's the combination of SACK signalling (as defined in RFC2018), which segments are elegibe for SACK-based retransmission, and RFC3517 (how to actually behave during SACK loss recovery). Unfortunately, neiter of which covers the corner case of loosing the last segment(s) of a stream [while already in loss recovery]. With NewReno, every FullAck below SND.MAX causes the retransmission of one segment (after the ACK), before continuing with the next segment after SND.MAX... But my findings so far indicate, that such a FullACK (no SACK entries) below SND.MAX doesn't trigger the retransmission of the next segment. Obviously, with a continous stream of data, this is not a big issue, as eventually you will have a SACK entry again, making the lost, previously last, segment elegible for retransmission under RFC2018/3517. Would there be any support by the group for an I-D, which addresses this particular corner case?=20 Richard Scheffenegger > -----Original Message----- > From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]=20 > Sent: Freitag, 22. Oktober 2010 04:43 > To: Scheffenegger, Richard > Cc: tcpm@ietf.org > Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) >=20 > Hello Richard, >=20 > I think this discussion should be based on rfc3517 since it=20 > describes a loss recovery algorithm for TCP SACK. >=20 > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp >=20 From mattmathis@google.com Fri Oct 22 12:20: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 DBC923A67FD for ; Fri, 22 Oct 2010 12:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.677 X-Spam-Level: X-Spam-Status: No, score=-103.677 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, 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 J-IIDdkgZshv for ; Fri, 22 Oct 2010 12:20:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9EA833A68BF for ; Fri, 22 Oct 2010 12:20:23 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o9MJM16o028511 for ; Fri, 22 Oct 2010 12:22:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287775321; bh=YI2R9i+hBN6mzb+zk5LMv7htjG4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=idob3F3WNNRQP7pck6X44PzN2ZNMWXbaj1fc2m5kk/j2GNmONqI2VMHa+gTXkirg9 7lu+H/b4+MFNUCtjkAc3g== Received: from ewy25 (ewy25.prod.google.com [10.241.103.25]) by hpaq3.eem.corp.google.com with ESMTP id o9MJLwX4022275 for ; Fri, 22 Oct 2010 12:22:00 -0700 Received: by ewy25 with SMTP id 25so878277ewy.28 for ; Fri, 22 Oct 2010 12:21:58 -0700 (PDT) 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 :content-transfer-encoding; bh=OliqLlNnyWF7Cw9AXMRfSffGEU+MBvb92Kq5lnYyZB8=; b=KhUqhNTEqqJcTtrNKFAKBX2qnN2CfcScoEEHO4mxcDuClQbOcVOBY0gxITBtnorRTX SqTFwmoyFmc6PNizsuzg== 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:content-transfer-encoding; b=vbefnVPtsqCPM/XGcwa5pvEQijZuqA+uVbyoWvF6cTMICBQJ6NIWdyCw/62LXDboru gRAioBUxZ/HXhwzRsTgA== MIME-Version: 1.0 Received: by 10.213.2.200 with SMTP id 8mr3690270ebk.73.1287775316554; Fri, 22 Oct 2010 12:21:56 -0700 (PDT) Received: by 10.213.31.83 with HTTP; Fri, 22 Oct 2010 12:21:56 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0B02D269@LDCMVEXC1-PRD.hq.netapp.com> References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0B02D269@LDCMVEXC1-PRD.hq.netapp.com> Date: Fri, 22 Oct 2010 12:21:56 -0700 Message-ID: From: Matt Mathis To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Oct 2010 19:20:26 -0000 I think it would be better to try to get it into 3517bis, but if that doesn't work, a separate ID will do. My rational: If the very last segment is lost, the partial ACK for the preceding segment will not include a SACK block because the receiver mistakenly thinks the data is complete. I would characterize this situation as leaving SACK recovery prematurely, which why it should be in scope for 3517bis. Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay On Fri, Oct 22, 2010 at 11:25 AM, Scheffenegger, Richard wr= ote: > > Thank you Yoshifumi-san, > > I agree; it's the combination of SACK signalling (as defined in > RFC2018), which segments are elegibe for SACK-based retransmission, and > RFC3517 (how to actually behave during SACK loss recovery). > > Unfortunately, neiter of which covers the corner case of loosing the > last segment(s) of a stream [while already in loss recovery]. > > With NewReno, every FullAck below SND.MAX causes the retransmission of > one segment (after the ACK), before continuing with the next segment > after SND.MAX... > > But my findings so far indicate, that such a FullACK (no SACK entries) > below SND.MAX doesn't trigger the retransmission of the next segment. > > Obviously, with a continous stream of data, this is not a big issue, as > eventually you will have a SACK entry again, making the lost, previously > last, segment elegible for retransmission under RFC2018/3517. > > > > Would there be any support by the group for an I-D, which addresses this > particular corner case? > > > Richard Scheffenegger > >> -----Original Message----- >> From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] >> Sent: Freitag, 22. Oktober 2010 04:43 >> To: Scheffenegger, Richard >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) >> >> Hello Richard, >> >> I think this discussion should be based on rfc3517 since it >> describes a loss recovery algorithm for TCP SACK. >> >> Thanks, >> -- >> Yoshifumi Nishida >> nishida@sfc.wide.ad.jp >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From ycheng@google.com Fri Oct 22 14:13:00 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27DB03A6970 for ; Fri, 22 Oct 2010 14:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.756 X-Spam-Level: X-Spam-Status: No, score=-103.756 tagged_above=-999 required=5 tests=[AWL=1.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 SZSbaB6EVaqJ for ; Fri, 22 Oct 2010 14:12:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 30E503A6918 for ; Fri, 22 Oct 2010 14:12:58 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o9MLEa1V008539 for ; Fri, 22 Oct 2010 14:14:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287782076; bh=9o305Tq85LNsh/LDNZnBBzOr+qM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=rVjBAz+F786K2J4noIcrDk4km5X/afpKlo2qcWOUlg/mjrttypE5snSzxRzZMGvnl JeIO4ewZg+emBLUq0UXfQ== Received: from ywc21 (ywc21.prod.google.com [10.192.3.21]) by hpaq14.eem.corp.google.com with ESMTP id o9MLDk3S007461 for ; Fri, 22 Oct 2010 14:14:35 -0700 Received: by ywc21 with SMTP id 21so37170ywc.13 for ; Fri, 22 Oct 2010 14:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=I2DE1INbIxlDq+dg6MrB82+ZB+RvQGobWViiglC2r4w=; b=bFdKbp222UYua6wzUcF4FroKtv2Ty4kwbBrvA/9Vi/xAlUttE7uvzFPOtFFVEfoK9A bobPwcoGOuVljFCKcylg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=juaAWlGRe5W3q/FUkYhZYvv4j2V3oMiJ3Q0blk5am08dM+UuKKtfk6rvO4qJrzfbEX h7apOV82TfStkPafNdjA== Received: by 10.42.205.198 with SMTP id fr6mr2420876icb.516.1287782074803; Fri, 22 Oct 2010 14:14:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.191.10 with HTTP; Fri, 22 Oct 2010 14:14:14 -0700 (PDT) In-Reply-To: References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0B02D269@LDCMVEXC1-PRD.hq.netapp.com> From: Yuchung Cheng Date: Fri, 22 Oct 2010 14:14:14 -0700 Message-ID: To: Matt Mathis Content-Type: multipart/alternative; boundary=20cf3040e76a1de78e04933b219b X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Oct 2010 21:13:00 -0000 --20cf3040e76a1de78e04933b219b Content-Type: text/plain; charset=ISO-8859-1 The example Richard gave makes lots of sense; it should improve loss recovery latency for web traffic as well. I also suggest revising RFC3517 about this case. My rational is simply TCP has too many RFCs on similar subjects. It's nightmare for developers (at least me) to follow up. but I disagree it's receiver's mistake: the receiver has no way to tell in this case! unless we put SND_NXT in the sender packets. On Fri, Oct 22, 2010 at 12:21 PM, Matt Mathis wrote: > I think it would be better to try to get it into 3517bis, but if that > doesn't work, a separate ID will do. > > My rational: If the very last segment is lost, the partial ACK for > the preceding segment will not include a SACK block because the > receiver mistakenly thinks the data is complete. I would characterize > this situation as leaving SACK recovery prematurely, which why it > should be in scope for 3517bis. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > On Fri, Oct 22, 2010 at 11:25 AM, Scheffenegger, Richard > wrote: > > > > Thank you Yoshifumi-san, > > > > I agree; it's the combination of SACK signalling (as defined in > > RFC2018), which segments are elegibe for SACK-based retransmission, and > > RFC3517 (how to actually behave during SACK loss recovery). > > > > Unfortunately, neiter of which covers the corner case of loosing the > > last segment(s) of a stream [while already in loss recovery]. > > > > With NewReno, every FullAck below SND.MAX causes the retransmission of > > one segment (after the ACK), before continuing with the next segment > > after SND.MAX... > > > > But my findings so far indicate, that such a FullACK (no SACK entries) > > below SND.MAX doesn't trigger the retransmission of the next segment. > > > > Obviously, with a continous stream of data, this is not a big issue, as > > eventually you will have a SACK entry again, making the lost, previously > > last, segment elegible for retransmission under RFC2018/3517. > > > > > > > > Would there be any support by the group for an I-D, which addresses this > > particular corner case? > > > > > > Richard Scheffenegger > > > >> -----Original Message----- > >> From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] > >> Sent: Freitag, 22. Oktober 2010 04:43 > >> To: Scheffenegger, Richard > >> Cc: tcpm@ietf.org > >> Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) > >> > >> Hello Richard, > >> > >> I think this discussion should be based on rfc3517 since it > >> describes a loss recovery algorithm for TCP SACK. > >> > >> Thanks, > >> -- > >> Yoshifumi Nishida > >> nishida@sfc.wide.ad.jp > >> > > _______________________________________________ > > 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 > --20cf3040e76a1de78e04933b219b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The example Richard gave makes lots of sense; it should improve loss recove= ry latency for web traffic as well.=A0I also suggest revising RFC3517 about= this case. My rational=A0is simply TCP has too many RFCs on similar subjec= ts. It's nightmare for developers (at least me) to follow up.

but I disagree it's receiver's mistake: the receiver= has no way to tell in this case! unless we put SND_NXT in the sender packe= ts.

On Fri, Oct 22, 2010 at 12:21 = PM, Matt Mathis <mattmathis@google.com> wrote:
I think it would be better to try to get it= into 3517bis, but if that
doesn't work, a separate ID will do.

My rational: =A0If the very last segment is lost, the partial ACK for
the preceding segment will not include a SACK block because the
receiver mistakenly thinks the data is complete. =A0I would characterize this situation as leaving SACK recovery prematurely, which why it
should be in scope for 3517bis.

Thanks,
--MM--
The best way to predict the future is to create it. =A0- Alan Kay

On Fri, Oct 22, 2010 at 11:25 AM, Scheffenegger, Richard <rs@netapp.com> wrote:
>
> Thank you Yoshifumi-san,
>
> I agree; it's the combination of SACK signalling (as defined in > RFC2018), which segments are elegibe for SACK-based retransmission, an= d
> RFC3517 (how to actually behave during SACK loss recovery).
>
> Unfortunately, neiter of which covers the corner case of loosing the > last segment(s) of a stream [while already in loss recovery].
>
> With NewReno, every FullAck below SND.MAX causes the retransmission of=
> one segment (after the ACK), before continuing with the next segment > after SND.MAX...
>
> But my findings so far indicate, that such a FullACK (no SACK entries)=
> below SND.MAX doesn't trigger the retransmission of the next segme= nt.
>
> Obviously, with a continous stream of data, this is not a big issue, a= s
> eventually you will have a SACK entry again, making the lost, previous= ly
> last, segment elegible for retransmission under RFC2018/3517.
>
>
>
> Would there be any support by the group for an I-D, which addresses th= is
> particular corner case?
>
>
> Richard Scheffenegger
>
>> -----Original Message-----
>> From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
>> Sent: Freitag, 22. Oktober 2010 04:43
>> To: Scheffenegger, Richard
>> Cc: tcpm@ietf.org
>> Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK erra= ta?)
>>
>> Hello Richard,
>>
>> I think this discussion should be based on rfc3517 since it
>> describes a loss recovery algorithm for TCP SACK.
>>
>> Thanks,
>> --
>> Yoshifumi Nishida
>> nishida@sfc.wide.ad.jp
>>
> _______________________________________________
> 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

--20cf3040e76a1de78e04933b219b-- From rs@netapp.com Fri Oct 22 16:06: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 982853A6774 for ; Fri, 22 Oct 2010 16:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.038 X-Spam-Level: X-Spam-Status: No, score=-8.038 tagged_above=-999 required=5 tests=[AWL=1.360, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, 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 oVK0aFNOJVxH for ; Fri, 22 Oct 2010 16:06:51 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id B51973A672F for ; Fri, 22 Oct 2010 16:06:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,225,1286175600"; d="scan'208,217";a="214552849" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 22 Oct 2010 16:08:26 -0700 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 o9MN8Qmv005863; Fri, 22 Oct 2010 16:08:26 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 Oct 2010 01:08:25 +0200 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_01CB723E.07278410" Date: Sat, 23 Oct 2010 00:08:23 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0B02D293@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) Thread-Index: ActyLiQd1k6rS6gTQja+8DHM+IGYrQAA9lnA References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0B02D269@LDCMVEXC1-PRD.hq.netapp.com> From: "Scheffenegger, Richard" To: "Yuchung Cheng" , "Matt Mathis" , "Ethan Blanton" X-OriginalArrivalTime: 22 Oct 2010 23:08:25.0387 (UTC) FILETIME=[07C1C7B0:01CB723E] Cc: tcpm@ietf.org Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 22 Oct 2010 23:06:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB723E.07278410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ethan, Mattis, Yuchung and Yoshifuma, =20 Let me state the conclusion of the below thoughts first: =20 A Full ACK (no SACK blocks) of SND.FACK should be a strong enough trigger to start retransmit of all segments between SND.FACK and SND.MAX. With the nice side effect that no additional state needs to be kept or saved in the senders TCP when entering SACK loss recovery...=20 =20 =20 =20 =20 Some thoughts w.r.t. conservation of packets when such a problem happens; please correct me, if any of these assumptions don't hold: =20 o) worst case scenario would be making one window minus 4 (initial loss, 3 delivered to trigger sack loss recovery, remaining segments heavily delayed) segments elegible for retransmissions. =20 o) would require delay (reordering) of all of these segments for at least one RTT (delivery after S2 is received on the receiver side). =20 o) due to the loss of the ACK clock, no more than at most dupthresh segments would be sent spurious after receiving an FullACK, while the remaining segments are still delayed. =20 o) depending on implementation details, up to (cwnd-4)*7/12 segments may be retransmitted unneccessarly, but nicely clocked out by ACKs. (With delayed ACKs, that might only be (cwnd-4)*3/12 segments). =20 =20 However, if the reordering delay would be higher than 1 RTT, even RTO based loss recovery would sent spurious retransmits.... but potentially even more than allowing SACK loss recovery to continue: (cwnd-4) - and by doing a slow start. =20 =20 Overall, for low RTT environment, I would argue that the benefit of addressing this RTO far outweights the potential, worst case cost.=20 =20 For high RTT environment, the current behavior can already be worse (slow-starting (bursts) after RTO, bursting out potentially delayed segments) than the worst case behavior of addressing this corner case - provided my back of the envelope sketch above holds any merit. =20 The scenario to end up with worst case violation of conservation of packets seem pretty extreme (LIFO delivery, exactly timed, adjusted to the cwnd....), so in a normal heavy reordering scenario, only very few segments may be retransmitted unnecessarily... =20 =20 A Full ACK (no SACK blocks) of SND.FACK should be a strong enough trigger to start retransmit of all segments between SND.FACK and SND.MAX. With the nice side effect that no additional state needs to be kept or saved when entering SACK loss recovery...=20 =20 ACKs with (higher) SACK entries received after starting the retransmission of that SND.FACK .. SND.MAX range may only cause a reduction of unnecessarily transmitted segments (IIRC, ACKs with SACK entries that don't ack any previously unacked segment, are not counting against the rate-halving scheme, or the rfc3517 pipe calculation...). =20 Richard Scheffenegger ________________________________ From: Yuchung Cheng [mailto:ycheng@google.com]=20 Sent: Freitag, 22. Oktober 2010 17:14 To: Matt Mathis Cc: Scheffenegger, Richard; tcpm@ietf.org Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) =09 =09 The example Richard gave makes lots of sense; it should improve loss recovery latency for web traffic as well. I also suggest revising RFC3517 about this case. My rational is simply TCP has too many RFCs on similar subjects. It's nightmare for developers (at least me) to follow up.=20 but I disagree it's receiver's mistake: the receiver has no way to tell in this case! unless we put SND_NXT in the sender packets. On Fri, Oct 22, 2010 at 12:21 PM, Matt Mathis wrote: =09 I think it would be better to try to get it into 3517bis, but if that doesn't work, a separate ID will do. =09 My rational: If the very last segment is lost, the partial ACK for the preceding segment will not include a SACK block because the receiver mistakenly thinks the data is complete. I would characterize this situation as leaving SACK recovery prematurely, which why it should be in scope for 3517bis. =09 Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay =09 On Fri, Oct 22, 2010 at 11:25 AM, Scheffenegger, Richard wrote: > > Thank you Yoshifumi-san, > > I agree; it's the combination of SACK signalling (as defined in > RFC2018), which segments are elegibe for SACK-based retransmission, and > RFC3517 (how to actually behave during SACK loss recovery). > > Unfortunately, neiter of which covers the corner case of loosing the > last segment(s) of a stream [while already in loss recovery]. > > With NewReno, every FullAck below SND.MAX causes the retransmission of > one segment (after the ACK), before continuing with the next segment > after SND.MAX... > > But my findings so far indicate, that such a FullACK (no SACK entries) > below SND.MAX doesn't trigger the retransmission of the next segment. > > Obviously, with a continous stream of data, this is not a big issue, as > eventually you will have a SACK entry again, making the lost, previously > last, segment elegible for retransmission under RFC2018/3517. > > > > Would there be any support by the group for an I-D, which addresses this > particular corner case? > > > Richard Scheffenegger > >> -----Original Message----- >> From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] >> Sent: Freitag, 22. Oktober 2010 04:43 >> To: Scheffenegger, Richard >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) >> >> Hello Richard, >> >> I think this discussion should be based on rfc3517 since it >> describes a loss recovery algorithm for TCP SACK. >> >> Thanks, >> -- >> Yoshifumi Nishida >> nishida@sfc.wide.ad.jp >> > _______________________________________________ > 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 =09 ------_=_NextPart_001_01CB723E.07278410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ethan, Mattis, Yuchung and=20 Yoshifuma,
 
Let me state the conclusion of the below thoughts=20 first:
 
A Full ACK (no SACK blocks) of SND.FACK = should be a=20 strong enough trigger to start retransmit of all segments between = SND.FACK=20 and SND.MAX. With the nice side effect that no additional state needs to = be kept=20 or saved in the senders TCP when entering SACK loss = recovery...=20
 
 
 
 
Some thoughts w.r.t. conservation of = packets when=20 such a problem happens; please correct me, if any of these assumptions = don't=20 hold:
 
o) worst case scenario would be making one = window minus 4=20 (initial loss, 3 delivered to trigger sack loss recovery, remaining = segments=20 heavily delayed) segments elegible for = retransmissions.
 
o) would require delay (reordering) of all of = these=20 segments for at least one RTT (delivery after S2 is = received on=20 the receiver side).
 
o) due to the loss of the ACK clock, no more than = at most=20 dupthresh segments would be sent spurious after receiving an FullACK, = while the=20 remaining segments are
still delayed.
 
o) depending on implementation details, up to = (cwnd-4)*7/12=20 segments may be retransmitted unneccessarly, but nicely clocked out by = ACKs.=20 (With delayed ACKs, that might only be (cwnd-4)*3/12=20 segments).
 
 
However, if the reordering delay would be higher = than 1 RTT,=20 even RTO based loss recovery would sent spurious retransmits.... but = potentially=20 even more than allowing SACK loss recovery to continue: (cwnd-4) - and = by doing=20 a slow start.
 
 
Overall, for low RTT environment, I would = argue that the=20 benefit of addressing this RTO far outweights the potential, worst case = cost.=20
 
For high RTT environment, the current behavior can = already be=20 worse (slow-starting (bursts) after RTO, bursting out potentially = delayed=20 segments) than the worst case behavior of addressing this corner = case -=20 provided my back of the envelope sketch above holds any=20 merit.
 
The scenario to end up with worst case violation = of=20 conservation of packets seem pretty extreme (LIFO delivery, exactly = timed,=20 adjusted to the cwnd....), so in a normal heavy reordering scenario, = only very=20 few segments may be retransmitted unnecessarily...
 
 
A Full ACK (no SACK blocks) of SND.FACK = should be a=20 strong enough trigger to start retransmit of all segments between = SND.FACK=20 and SND.MAX. With the nice side effect that no additional state needs to = be kept=20 or saved when entering SACK loss recovery... =
 
ACKs with (higher) SACK entries received after = starting the=20 retransmission of that SND.FACK ..  SND.MAX range may only cause a=20 reduction of unnecessarily transmitted segments (IIRC, ACKs with SACK = entries=20 that don't ack any previously unacked segment, are not counting against = the=20 rate-halving scheme, or the rfc3517 pipe = calculation...).
 

Richard=20 Scheffenegger


From: Yuchung Cheng = [mailto:ycheng@google.com]=20
Sent: Freitag, 22. Oktober 2010 17:14
To: Matt=20 Mathis
Cc: Scheffenegger, Richard; = tcpm@ietf.org
Subject:=20 Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK=20 errata?)

The example Richard gave makes lots of sense; it should = improve=20 loss recovery latency for web traffic as well. I also suggest = revising=20 RFC3517 about this case. My rational is simply TCP has too many = RFCs on=20 similar subjects. It's nightmare for developers (at least me) to = follow up.

but I disagree it's receiver's mistake: the receiver has no way = to tell=20 in this case! unless we put SND_NXT in the sender packets.

On Fri, Oct 22, 2010 at 12:21 PM, Matt Mathis = <mattmathis@google.com>=20 wrote:
I think it would be better to try to get it into = 3517bis,=20 but if that
doesn't work, a separate ID will do.

My = rational:=20  If the very last segment is lost, the partial ACK for
the = preceding=20 segment will not include a SACK block because the
receiver = mistakenly=20 thinks the data is complete.  I would characterize
this = situation as=20 leaving SACK recovery prematurely, which why it
should be in = scope for=20 3517bis.

Thanks,
--MM--
The best way to predict the = future is=20 to create it.  - Alan Kay

On Fri, Oct 22, 2010 at 11:25 AM, Scheffenegger, = Richard=20 <rs@netapp.com>=20 wrote:
>
> Thank you Yoshifumi-san,
>
> I = agree;=20 it's the combination of SACK signalling (as defined in
> = RFC2018),=20 which segments are elegibe for SACK-based retransmission, = and
>=20 RFC3517 (how to actually behave during SACK loss = recovery).
>
>=20 Unfortunately, neiter of which covers the corner case of loosing = the
>=20 last segment(s) of a stream [while already in loss=20 recovery].
>
> With NewReno, every FullAck below SND.MAX = causes=20 the retransmission of
> one segment (after the ACK), before = continuing=20 with the next segment
> after SND.MAX...
>
> But = my=20 findings so far indicate, that such a FullACK (no SACK = entries)
>=20 below SND.MAX doesn't trigger the retransmission of the next=20 segment.
>
> Obviously, with a continous stream of data, = this is=20 not a big issue, as
> eventually you will have a SACK entry = again,=20 making the lost, previously
> last, segment elegible for=20 retransmission under RFC2018/3517.
>
>
>
> = Would=20 there be any support by the group for an I-D, which addresses = this
>=20 particular corner case?
>
>
> Richard=20 Scheffenegger
>
>> -----Original = Message-----
>>=20 From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
>= ;>=20 Sent: Freitag, 22. Oktober 2010 04:43
>> To: Scheffenegger, = Richard
>> Cc: tcpm@ietf.org
>> Subject: = Re:=20 [tcpm] end-of-stream loss recovery (RFC2018 SACK=20 errata?)
>>
>> Hello = Richard,
>>
>> I=20 think this discussion should be based on rfc3517 since = it
>>=20 describes a loss recovery algorithm for TCP = SACK.
>>
>>=20 Thanks,
>> --
>> Yoshifumi Nishida
>> nishida@sfc.wide.ad.jp
>= >
>=20 _______________________________________________
> tcpm mailing = list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>_______________________________________________
tcpm=20 mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
<= /DIV>

------_=_NextPart_001_01CB723E.07278410-- From eblanton@cs.ohiou.edu Fri Oct 22 18:29:09 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B176328C0E2 for ; Fri, 22 Oct 2010 18:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.998, 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 nSKgSqyR52jV for ; Fri, 22 Oct 2010 18:29:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 101DB3A6804 for ; Fri, 22 Oct 2010 18:29:06 -0700 (PDT) Received: from 99-52-196-7.lightspeed.crmlin.sbcglobal.net ([99.52.196.7] helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P9SwV-0008ZU-SI; Sat, 23 Oct 2010 01:30:44 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id E3B633BD61; Fri, 22 Oct 2010 21:30:42 -0400 (EDT) Date: Fri, 22 Oct 2010 21:30:42 -0400 From: Ethan Blanton To: Matt Mathis Message-ID: <20101023013042.GC12426@colt> Mail-Followup-To: Matt Mathis , "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , TCP Maintenance and Minor Extensions WG References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw" Content-Disposition: inline In-Reply-To: X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Cc: TCP Maintenance and Minor Extensions WG Subject: Re: [tcpm] 3517 update w/ SACK-entry draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Oct 2010 01:29:10 -0000 --jy6Sn24JjFx/iggw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Matt. Matt Mathis spake unto us the following wisdom: > A couple of comments: =A0There is an errata against 2018 about the > requirement that timeouts MUST clear the score board. =A0 From the > errata: >=20 > "At least one OS (Linux) violates the MUST to good effect: Even when time= out > driven, it keeps old SACK data so it can avoid retransmitting data alread= y at > the receiver. Thus even under severe bandwidth exhaustion, 100% of the da= ta > delivered to the receiver causes forward progress and the system is not s= ubject > to classical congestion collapse (that is, congestion collapse from > unnecessarily-retransmitted packets)." We have discussed this, actually. We prefer *not* to address it as part of 3517bis for a number of reasons (my coauthors will hopefully correct me if I misrepresent anything): 1) 3517 really only addresses the "fast recovery" portion of loss recovery, and has little to say about the RTO and what follows. The text in Section 5.1 dealing with the RTO is more or less just reiterating what 2018 says, and then pointing out some obvious ways to deal with incoming SACK data. Note that it doesn't even specify precisely how a sender uses SACK data during slow start, except to point out that NextSeg () isn't really appropriate. 2) 3517bis is a *tiny* delta from 3517. Look at Section 9 to see this. Introducing larger changes at this point is really not something we want to see. We would much rather see larger changes standardized separately, their kinks worked out, and then roll them int o 3517bis-bis if appropriate. 3517 is subtle, and we really feel like we got it Right in a lot of ways. We do not want to introduce bugs in what is supposed to be a straightforward rev to improve a single, well-understood point (entry into loss recovery). 3) We do not envision RFC 3517 as being the *only* SACK algorithm out there. In particular, we recognize that FACK is already in use, as well as variants of both 3517 and FACK. We envision 3517 as *one*, sane and well-understood, way to deal with SACK information. > It would be better to update section 5.1 of 3517bis to reflect this. > Note that the errata introduces several caveats and and additional > issues that need to be addressed. Things like these caveats and additional issues are precisely what I want to avoid! > Also there is another issue that should be introduced in the security > considerations section: >=20 > Traditional recovery mechanism serve to protect the Internet from > implementers who change congestion control to make it too aggressive, > because doing so tends to increase the probability of timeouts, and > often reduces overall throuthput. This creates a strong disincentive > to deploying extra aggressive congestion control. >=20 > As recovery algorithms improve, this disincentive is reduced. In the > limit an ideal recovery mechanism might never suffer from a timeout > except after losing an entire window of data or ACKs. Such a recovery > algorithm might create an incentive to deploy arbitrarily aggressive > congestion control. The algorithms presented in this document are are > believed to reduce the negative consequence of making congestion > control more aggressive than permitted by RFC 5681. OK; I agree with your point above entirely. We will have to think about this with respect to 3517bis. It is absolutely the case that smarter loss recovery makes it more feasible to back off aggressively. I'm not completely sure this is 3517's problem, though. > -- > On other issue: would this be an appropriate time (and doc) to > introduce some other ideas from our rate halving work from ages ago? I would prefer to see this in an additional document, and I think my coauthors would agree. Ethan --jy6Sn24JjFx/iggw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTMI6wv8fixZ3H8crAQiQ6gf/YCwQMcVgAs2Y38lrm5jtRjZmyq8BucWw 1MwGNGmfpzq+gBqdnoyZn6v9ii5iIZZM32jRI1T9aw83kNK7kMDRK2QYul85zsZ6 eQdLVoAH2pgePQL+Do4FJwIvP4LDOZ6f/7Bkk8DufTdva21mf8ZN3wXDWrpbgkb5 noCRBdITV34fbZ9KLDY2sspP4Gmx3edbjUJLZ1B+0H9K/eT3V4Lnx83rhbTp32yq bgMpWb6x3HM4AnlT+qeYBk0Tej+DEs9qQ2kkpyyrIg6prOL5y0NoSIvHkIZN/7OG 0fBOCqTZ8wJVMobfVd7Yrkh77q7zuvbV+EOX8UwVn2U3mUBbmKHyDA== =Obms -----END PGP SIGNATURE----- --jy6Sn24JjFx/iggw-- From eblanton@cs.ohiou.edu Fri Oct 22 18:40: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 54D763A69C1 for ; Fri, 22 Oct 2010 18:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.665, 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 QBcJND7ynpHo for ; Fri, 22 Oct 2010 18:40:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CFBC93A69B9 for ; Fri, 22 Oct 2010 18:40:24 -0700 (PDT) Received: from 99-52-196-7.lightspeed.crmlin.sbcglobal.net ([99.52.196.7] helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P9T7R-0009Eb-7G; Sat, 23 Oct 2010 01:42:01 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id 2CC663BD61; Fri, 22 Oct 2010 21:42:00 -0400 (EDT) Date: Fri, 22 Oct 2010 21:42:00 -0400 From: Ethan Blanton To: Matt Mathis Message-ID: <20101023014200.GD12426@colt> Mail-Followup-To: Matt Mathis , "Scheffenegger, Richard" , tcpm@ietf.org References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0B02D269@LDCMVEXC1-PRD.hq.netapp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iVCmgExH7+hIHJ1A" Content-Disposition: inline In-Reply-To: X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Cc: tcpm@ietf.org Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Oct 2010 01:40:28 -0000 --iVCmgExH7+hIHJ1A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Matt Mathis spake unto us the following wisdom: > I think it would be better to try to get it into 3517bis, but if that > doesn't work, a separate ID will do. See my response to the 3517bis thread for my response to this, too. ;-) I prefer to see this in separate ID. > My rational: If the very last segment is lost, the partial ACK for > the preceding segment will not include a SACK block because the > receiver mistakenly thinks the data is complete. I would characterize > this situation as leaving SACK recovery prematurely, which why it > should be in scope for 3517bis. I largely agree with this characterization. There may be some potential for confusion if the segment immediately preceding the incoming cumulative ACK was retransmitted, where loss recovery is indeed complete and the next segment *should not* be retransmitted. Due to this and other possible issues, I'd much rather see this hammered out carefully and integrated later, while 3517bis is pushed through and finished in the meantime. It sounds to me like there's room for a document (or maybe two documents) which says: 1) There's a corner case where a specific loss pattern which involves at least two segment losses in a single window of data separated by at least three intervening segments causes SACK to perform worse than NewReno. 2) There is a related set of corner cases with general losses at the end of the window where, under some circumstances, it may be beneficial to retransmit a packet a bit "early". --- possible document break 3) There are better ways to handle SACK data on RTO than flushing it blindly. In particular, Josh Blanton documented as part of his Masters thesis a scheme which reliably disambiguates reneging on SACK information from other behaviors. Then, at some later point in time, it may make sense to roll these algorithms into the RFC 3517 lineage. In particular, I believe that points 1) and 2) are more subtle than this thread suggests. I think 3) is probably more straightforward. Ethan --iVCmgExH7+hIHJ1A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTMI9Z/8fixZ3H8crAQgZNAgAljKWuALCmcq+6u2fEdzmIlRRH4oZy0e0 gWJdNfg+yc541wTBl5yhZIUTkugSkc+TfFDGHcfDLnmf0hX6sQko0JG/FLTFrlFP H0gV5ICu8bGk1Qis+KgYvyS7uRBujbFkeVNSegoUFbu2LpHq9u5UCiElkiJnp1lJ daicvppy2V8bUJv6cximlAvd6m6zHd20bS4+7scThbKcWeki1E9iMJlezbjxzNYn ilWRvQFIoh9H7uxVVmQYatk2o3sHgnwGsKZpYfzjyDvnPQZJn+mleE8XYV6wW3Ww QcGsASENyd5rhUUTGDAL3C0DzqkUmg/vWbr3p8p9PPLBPwcvUFDDgw== =VFOH -----END PGP SIGNATURE----- --iVCmgExH7+hIHJ1A-- From eblanton@cs.ohiou.edu Sat Oct 23 06:24: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 5A9E43A68DC for ; Sat, 23 Oct 2010 06:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.499, 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 1Ms1S672uO22 for ; Sat, 23 Oct 2010 06:23:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A08003A6855 for ; Sat, 23 Oct 2010 06:23:51 -0700 (PDT) Received: from 99-52-196-7.lightspeed.crmlin.sbcglobal.net ([99.52.196.7] helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P9e6D-0004bL-8d; Sat, 23 Oct 2010 13:25:30 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id 2B3933BD08; Sat, 23 Oct 2010 09:25:27 -0400 (EDT) Date: Sat, 23 Oct 2010 09:25:27 -0400 From: Ethan Blanton To: "Scheffenegger, Richard" Message-ID: <20101023132527.GE12426@colt> Mail-Followup-To: "Scheffenegger, Richard" , tcpm@ietf.org References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0B02D269@LDCMVEXC1-PRD.hq.netapp.com> <20101023014200.GD12426@colt> <5FDC413D5FA246468C200652D63E627A0B02D296@LDCMVEXC1-PRD.hq.netapp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xA/XKXTdy9G3iaIz" Content-Disposition: inline In-Reply-To: <5FDC413D5FA246468C200652D63E627A0B02D296@LDCMVEXC1-PRD.hq.netapp.com> X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Cc: tcpm@ietf.org Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Oct 2010 13:24:07 -0000 --xA/XKXTdy9G3iaIz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Richard, I'm pulling this back to the list, because I suspect you're not the only reader who didn't follow ... my original example was too terse. Scheffenegger, Richard spake unto us the following wisdom: > Unfortunately, I'm afraid I am not following what you wanted to describe > here: It requires three losses, and your change of rules. > > I largely agree with this characterization. There may be some > > potential for confusion if the segment immediately preceding the > > incoming cumulative ACK was retransmitted, where loss recovery is > > indeed complete and the next segment *should not* be retransmitted. > > Due to this and other possible issues, I'd much rather see this > > hammered out carefully and integrated later, while 3517bis is pushed > > through and finished in the meantime. [snip your example] S1 ... S7 are sent. S1, S6, and S7 are lost. The sender retransmits S1, gets a cumulative ACK for S6, retransmits S6, then gets a cumulative ACK for S7. Should it retransmit S7? Did the original transmission or the retransmission trigger the cum ACK for S7? Consider the case were S6 was not lost in the first place, but delayed in the network for ~1RTT. Now consider interaction with timestamps, DSACK, etc. where this potentially *can* be disambiguated. My point isn't that this is the end of the world, or that it's the only potential problem, or even that it's a problem worth worrying about (it might just be a corner case), it's simply that someone needs to sit down and carefully think about all of the scenarios, and I don't think this rev of 3517 is the time to do it. It took more than two years to get 3517 published, and (for which I take some blame) poor Ilpo and Markku have been sitting on their sack-entry draft for many months now already. This change to 3517 is small, easily understood, has been understood and "approved" by many involved parties since the time that 3517 was originally published, and represents a real benefit. I would very much prefer to see you explore the options for this end-of-window loss scenario, including situations where it fails and where the retransmission should be stifled (if any). I think you'll find that it's *not* as easy as looking for a cumulative ACK for the highest SACKed octet + 1. (Or, rather, it may be that it *is* that simple for the *first* retransmission, but possibly not later retransmissions.) Ethan --xA/XKXTdy9G3iaIz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTMLiRv8fixZ3H8crAQjsogf+NK+vKjAQVqh5fr+IaZ3ltP/2T66vXoCt btmmPdPnMu2h5erC8VpieiO4UW2N9D8Zq+q+67bFyPmBpoNa0xHoJeloonLTmGi7 CA3nJfGNvBtSRXoVV/EvIn9wwyAb32ZoNR9oJPijWMwI85JqWK5xN4EJl1RkZ8qw 7uzE+t7VcS+ZCfVyE0ZfV6D/wSKhLYnZe22FVTf0F/Wkxb4TwZPFx3R7dIjReUWg tT0kdGR3NmlXiVkGRci/66oN9dR7n/+pjNPRbTT/tkkyXQbIHJQDvxrsIS3x89Ew ABhbAYT4T/9Yhnd2NTwTeNlLEZORwN+LQ/14YrAZw5BCkastbI352w== =oJV7 -----END PGP SIGNATURE----- --xA/XKXTdy9G3iaIz-- From mattmathis@google.com Sat Oct 23 10:34:00 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21033A68A8 for ; Sat, 23 Oct 2010 10:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.566 X-Spam-Level: X-Spam-Status: No, score=-105.566 tagged_above=-999 required=5 tests=[AWL=0.411, 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 ye4dXJupZSyG for ; Sat, 23 Oct 2010 10:33:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3A0973A680E for ; Sat, 23 Oct 2010 10:33:58 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o9NHZc9o015787 for ; Sat, 23 Oct 2010 10:35:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287855338; bh=oqZtrYvCmGwKlUk4ftkRPXCX3A8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type:Content-Transfer-Encoding; b=NJXI6o0imbLX3Je8WzND/6TL8YJ0ZPiUzeCEf/zPlTXd48/cx71Jp06F27VOYTvZO Ts6ByBCzJNkRmdkL4b6Gw== Received: from ewy10 (ewy10.prod.google.com [10.241.103.10]) by wpaz33.hot.corp.google.com with ESMTP id o9NHZbXw009943 for ; Sat, 23 Oct 2010 10:35:37 -0700 Received: by ewy10 with SMTP id 10so1260180ewy.40 for ; Sat, 23 Oct 2010 10:35:36 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=0gEh7pWxOqd+fuKpfzdF1/cRWyCHL2bov/nx5+cbsoM=; b=m0FpbIPERFuBy+hQtHibQY6rSTSr6UCy2kmnnOr7XRqbroLA9YeLHI+gdRvbvWvv8T OISh4YJIlUpALNtEwHwQ== 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 :content-type:content-transfer-encoding; b=RZ5RZ0P/cKUWVMwKaQGPaz1EjhNmkVaqA56BoWRXrZ1WL/DS4s7OHl8JumvBTmryX9 xohjUhpXPCSmUNoIXxOw== MIME-Version: 1.0 Received: by 10.213.34.79 with SMTP id k15mr4417166ebd.26.1287855336573; Sat, 23 Oct 2010 10:35:36 -0700 (PDT) Received: by 10.213.31.83 with HTTP; Sat, 23 Oct 2010 10:35:36 -0700 (PDT) In-Reply-To: <20101023013042.GC12426@colt> References: <20101023013042.GC12426@colt> Date: Sat, 23 Oct 2010 13:35:36 -0400 Message-ID: From: Matt Mathis To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , TCP Maintenance and Minor Extensions WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Subject: Re: [tcpm] 3517 update w/ SACK-entry draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Oct 2010 17:34:00 -0000 Inline On Fri, Oct 22, 2010 at 9:30 PM, Ethan Blanton wrot= e: > Hi, Matt. > > Matt Mathis spake unto us the following wisdom: >> A couple of comments: =A0There is an errata against 2018 about the >> requirement that timeouts MUST clear the score board. =A0 From the >> errata: >> >> "At least one OS (Linux) violates the MUST to good effect: Even when tim= eout >> driven, it keeps old SACK data so it can avoid retransmitting data alrea= dy at >> the receiver. Thus even under severe bandwidth exhaustion, 100% of the d= ata >> delivered to the receiver causes forward progress and the system is not = subject >> to classical congestion collapse (that is, congestion collapse from >> unnecessarily-retransmitted packets)." > > We have discussed this, actually. =A0We prefer *not* to address it as > part of 3517bis for a number of reasons (my coauthors will hopefully > correct me if I misrepresent anything): Fair enough, but then please don't strengthen the incorrect language in 2018 by citing or repeating it, especially without mentioning the errata. There isn't a trivial fix here, because the real problem is that section 5.1 conflates two separate issues: what to do on a timeout, and what to do when clearing the scoreboard due to reneging or other events (such as timeouts as incorrectly required by 2018). I think these should be two separate sections. I am not aware of any existing description of how to handle a timeout w/o clearing the scoreboard. The current text clashes badly with existing, well functioning implementations. Insisting on keeping it will hurt the credibility of the entire document. >> Also there is another issue that should be introduced in the security >> considerations section: >> >> Traditional recovery mechanism serve to protect the Internet from >> implementers who change congestion control to make it too aggressive, >> because doing so tends to increase the probability of timeouts, and >> often reduces overall throuthput. =A0This creates a strong disincentive >> to deploying extra aggressive congestion control. >> >> As recovery algorithms improve, this disincentive is reduced. =A0In the >> limit an ideal recovery mechanism might never suffer from a timeout >> except after losing an entire window of data or ACKs. =A0Such a recovery >> algorithm might create an incentive to deploy arbitrarily aggressive >> congestion control. =A0The algorithms presented in this document are are >> believed to reduce the negative consequence of making congestion >> control more aggressive than permitted by RFC 5681. > > OK; I agree with your point above entirely. =A0We will have to think > about this with respect to 3517bis. =A0It is absolutely the case that > smarter loss recovery makes it more feasible to back off aggressively. > I'm not completely sure this is 3517's problem, though. It is in scope for 3517bis, because this issue is entirely about Fast Recovery strengthening TCP's self clock during recovery, which I believe is an explicitly stated goal of the algorithm. For the record, I think more aggressive CC is a good thing. Part of my motivation for wanting this language here is to set the stage for some future more aggressive CC algorithms. This language explicitly connects the future evolution in congestion control to the current evolution in recovery algorithms. Although as I reread it, I may have suggested text that is just a bit too strong. Thanks, --MM-- From rs@netapp.com Sat Oct 23 11:29:55 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4584E3A68CB for ; Sat, 23 Oct 2010 11:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.076 X-Spam-Level: X-Spam-Status: No, score=-8.076 tagged_above=-999 required=5 tests=[AWL=1.323, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_34=0.6, 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 pJapsuJ3oE-y for ; Sat, 23 Oct 2010 11:29:54 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 7001E3A68BC for ; Sat, 23 Oct 2010 11:29:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,228,1286175600"; d="scan'208";a="214753824" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 23 Oct 2010 11:31:32 -0700 Received: from amsrsexc1-prd.hq.netapp.com (amsrsexc1-prd.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9NIVVB0010918; Sat, 23 Oct 2010 11:31:31 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 Oct 2010 20:31:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Oct 2010 19:31:29 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0B02D2AE@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20101023132527.GE12426@colt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) Thread-Index: ActyteW0R5YCefgzTNGUBbWMKJRbcAAIdxmA References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0B02D269@LDCMVEXC1-PRD.hq.netapp.com> <20101023014200.GD12426@colt> <5FDC413D5FA246468C200652D63E627A0B02D296@LDCMVEXC1-PRD.hq.netapp.com> <20101023132527.GE12426@colt> From: "Scheffenegger, Richard" To: "Ethan Blanton" X-OriginalArrivalTime: 23 Oct 2010 18:31:31.0826 (UTC) FILETIME=[83B74D20:01CB72E0] Cc: tcpm@ietf.org Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 23 Oct 2010 18:29:55 -0000 Thank you Ethan! I'll skip the discussion about whether it should be in 3517bis or a seperate document. Obviously, if S6 + S7 are lost, the sender should retransmit, right? (But the sender and receiver lack the information to be 100% sure about that).=20 If S6 (or S7 for that matter) are delayed by more than 1 RTT, RTO would also trigger the resending of those frames - potentially prematurely [assuming RTT > RTO(min)].=20 This scheme would only cause the sending of one of the segments earlier, than RTO may have done. If either one is delayed by less than RTT, an ACK with a SACK entry would move SND.FACK forward, preventing undue retransmissions in time. Some goes if we are not at the end of stream, and new (S8) segments are injected that are not delayed. Regarding the timing/ordering of the retransmissions: A cumulative ACK (with no SACK entries) should trigger the retransmission of only a single further packet presumed lost at the end of stream. In your example, the sender could fill the pipe by immedately sending S6 + S7. A conservate sender should however still wait a little more for S7 to arrive, if it was heavy delayed by the network. Thank you for bringing up that point. That way, the sender is allowing for 1 RTT reordering delay for S6, but 2 RTT reordering delay for S7 (and so forth). Assuming, of course, RTT < RTO(min). If RTT is larger than RTO(min), and reordering delay larger than 1 RTT, RTO will trigger retransmission of segments sooner than the cumulative ACK for S6 could cause sack loss recovery to retransmit under that scheme. Since this would also happen currently, we end up no worse than without the modification. And yes, I'm quite sure that there will be corner cases, where simply using cumulative ACK for the highest SACKed octet + 1 may cause superfluous retransmits. I use superfluous here in order to discreminate from spurious retransmits, which are preceeded by an undue entering of loss recovery. Here we are always in loss recovery. (If I may, being interested primarily in low-latency, high bandwidth environment where boundary synchronized traffic is encountered, the timely recovery (few RTT) is of more criticality than absolute conservation of packets. There are other means in TCP to address environments, where heavy reordering is dominant, and I would argue that once loss recovery started, this is out of scope.) I think the above arguments can be interpreted such that o) If RTT > RTO(min), and reordering delay >=3D RTT: No change in the way the sender behaves (all these delayed segments may end up retransmitted unnecessarily, under both schemes, due to RTO) o) If RTT < RTO(min), and reordering delay between RTT and RTO(min): Some few superfluous retransmits can happen. This is bounded, however, by (cwnd-4)*7/12 segments, if my calculations yesterday were correct; with delayed ACK enabled, the upper bound can be as low as (cwnd-4)*3/12, even under pathological worst case scenarios (such as LIFO reordering and exact timing). o) If reordering delay < RTT: The sender will not see a cumulative ACK without SACK entries, thus not prematurely retransmit delayed segments. If there is indeed loss, and RTT < RTO(min), full recovery will takes n*RTT with n the number of segments lost prior to end-of-stream. Even that "lengthy" recovery time will typically beat RTO by orders of magnitude in local networks. If more then (cwnd-3)/2 is lost, the ACK clock will eventually stall, and only a RTO + slow start can get the flow going again.=20 Obviously, the above statements are not as thorough as you probably would like them to be. I tried to flesh out a scenario yesterday, which would result in the *most* superfluous retransmissions possible - excluding additional information such as DSACK, delayed ACKs, Timestamps, but taking the reduction of the congestion window into account (and the variants of rate halving, that seem to be running in the lastest BSD and Linux stacks). Best regards, Richard Scheffenegger =20 > -----Original Message----- > From: Ethan Blanton [mailto:eblanton@cs.ohiou.edu]=20 > Sent: Samstag, 23. Oktober 2010 09:25 > To: Scheffenegger, Richard > Cc: tcpm@ietf.org > Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) >=20 > Richard, I'm pulling this back to the list, because I suspect=20 > you're not the only reader who didn't follow ... my original=20 > example was too terse. >=20 > Scheffenegger, Richard spake unto us the following wisdom: > > Unfortunately, I'm afraid I am not following what you wanted to=20 > > describe > > here: >=20 > It requires three losses, and your change of rules. >=20 > > > I largely agree with this characterization. There may be some=20 > > > potential for confusion if the segment immediately preceding the=20 > > > incoming cumulative ACK was retransmitted, where loss recovery is=20 > > > indeed complete and the next segment *should not* be=20 > retransmitted. > > > Due to this and other possible issues, I'd much rather see this=20 > > > hammered out carefully and integrated later, while=20 > 3517bis is pushed=20 > > > through and finished in the meantime. >=20 > [snip your example] >=20 > S1 ... S7 are sent. S1, S6, and S7 are lost. The sender=20 > retransmits S1, gets a cumulative ACK for S6, retransmits S6,=20 > then gets a cumulative ACK for S7. Should it retransmit S7? =20 > Did the original transmission or the retransmission trigger=20 > the cum ACK for S7? > Consider the case were S6 was not lost in the first place,=20 > but delayed in the network for ~1RTT. Now consider=20 > interaction with timestamps, DSACK, etc. where this=20 > potentially *can* be disambiguated. >=20 > My point isn't that this is the end of the world, or that=20 > it's the only potential problem, or even that it's a problem=20 > worth worrying about (it might just be a corner case), it's=20 > simply that someone needs to sit down and carefully think=20 > about all of the scenarios, and I don't think this rev of=20 > 3517 is the time to do it. It took more than two years to get=20 > 3517 published, and (for which I take some blame) poor Ilpo=20 > and Markku have been sitting on their sack-entry draft for=20 > many months now already. This change to 3517 is small,=20 > easily understood, has been understood and "approved" by many=20 > involved parties since the time that 3517 was originally=20 > published, and represents a real benefit. >=20 > I would very much prefer to see you explore the options for=20 > this end-of-window loss scenario, including situations where=20 > it fails and where the retransmission should be stifled (if=20 > any). I think you'll find that it's *not* as easy as looking=20 > for a cumulative ACK for the highest SACKed octet + 1. (Or,=20 > rather, it may be that it *is* that simple for the *first*=20 > retransmission, but possibly not later > retransmissions.) >=20 > Ethan >=20 From ananth@cisco.com Sat Oct 23 19:41:54 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340F43A67C3 for ; Sat, 23 Oct 2010 19:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 f+7Dm1DL-fif for ; Sat, 23 Oct 2010 19:41:52 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5EF033A676A for ; Sat, 23 Oct 2010 19:41:52 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIo6w0yrR7H+/2dsb2JhbAChbnGfDpsthUgEhFSJBQ X-IronPort-AV: E=Sophos;i="4.58,230,1286150400"; d="scan'208";a="205654899" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 24 Oct 2010 02:43:34 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9O2hYOg006288 for ; Sun, 24 Oct 2010 02:43:34 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 23 Oct 2010 19:43:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Oct 2010 19:43:32 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580AFDD963@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Readiness of "draft-ietf-tcpm-persist-00.txt" for last call. Thread-Index: ActzJT9QGtH7B9o5SQqL8a5TsmkFAw== From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 24 Oct 2010 02:43:33.0939 (UTC) FILETIME=[40444030:01CB7325] Subject: [tcpm] Readiness of "draft-ietf-tcpm-persist-00.txt" for last call. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Oct 2010 02:41:54 -0000 Hi, =20 Following is the summary (from the authors perspective) as to where we stand w.r.t this draft. We believe, this short and harmless draft is ready for the last call. =20 During the last review of the persist draft, some folks were not happy about the API section (section 7) of the document. The authors discussed this concern among themselves and also have received some other reviews (both internal and external) and are kind of confused as to why the presence of an API guideline (for illustration purpose mainly) should be of any concern. Following reasons as to why we think why some illustration (like API) would be nicer to have :- - This is an informational draft. The purpose of the API section is to illustrate what how an application can do something about connections which are stuck in persist state. The objective is NOT to recommend any sockets API syntax or format (again we are not standardizing anything), it is purely there to illustrate the essence of the draft. - There was some talk about SO_LINGER API etc.,. I think we have clarified earlier that SO_LINGER comes into play only when the application tries to close the socket. SO_LINGER with 0 value is like causing an abort of the TCP connection. Here we acknowledge that there is a way (possibly more ways) that exists which can be used to abort the TCP connection. This is orthogonal to the current API discussion which we are having which simply illustrates how an application can abort the TCP connection without violating any RFC (793 or 1122) In a nutshell, we don't see any reason why mentioning an API example is violation of the RFC. We believe adding an API example would not deter that simplicity in any way, but that is just our take. Maybe there is some scope to rewrite that section if folks think otherwise. We would like to move forward on getting closure on this aspect as this seems to be the last hurdle in getting this draft to the last call process.=20 Sorry about the delay in getting back. Thanks, -Anantha From yoshifumi.nishida@gmail.com Sat Oct 23 23:39: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 D91373A67BD for ; Sat, 23 Oct 2010 23:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.574 X-Spam-Level: X-Spam-Status: No, score=-101.574 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJctvP6rwbLr for ; Sat, 23 Oct 2010 23:39:19 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 42E4E3A67B2 for ; Sat, 23 Oct 2010 23:39:19 -0700 (PDT) Received: by wyb28 with SMTP id 28so2255607wyb.31 for ; Sat, 23 Oct 2010 23:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=0cO7bDJM/lhmdk8A6H9NOjpbsPMEK6yGh7fYz0hsS2Y=; b=uH12AjJVkg6CW3ZCiZRTkWcxo9uzykNFVvi1vJtyZcu4lRG58RRnEpQp83PIrdItHz AIrZKthiWQu8DyWwRCNqBsPOSNWKX8UeqJofneHUclBgBVIfUxQBLlq5LJYbJx/u4i9x vhlpY0eFyi+XdcR9x1wUD09vAVNfqczqpAUeU= 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:content-type :content-transfer-encoding; b=nFr8LQXc0h6kfOMCDKPpqjmBehrwpM0mNOxEcbZvbIwxth6ccNOLdo/Z+v49qjhh+6 GmhvkgSzMehBbyTieR7HsKeh9jQAE9mUNWeJPROdi0ViMkvK3rcTeC2322cFLvHMnaGS PZGkaXkxH4jWgsWeuJWsNdZtnDspRUdm7lojo= MIME-Version: 1.0 Received: by 10.216.143.163 with SMTP id l35mr4185403wej.68.1287902460582; Sat, 23 Oct 2010 23:41:00 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.216.170.199 with HTTP; Sat, 23 Oct 2010 23:41:00 -0700 (PDT) In-Reply-To: <20101023132527.GE12426@colt> References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de> <49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com> <5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0B02D269@LDCMVEXC1-PRD.hq.netapp.com> <20101023014200.GD12426@colt> <5FDC413D5FA246468C200652D63E627A0B02D296@LDCMVEXC1-PRD.hq.netapp.com> <20101023132527.GE12426@colt> Date: Sat, 23 Oct 2010 23:41:00 -0700 X-Google-Sender-Auth: 4bZ4hkCrOgopAq4hfHGPTLlx8OA Message-ID: From: Yoshifumi Nishida To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Oct 2010 06:39:22 -0000 2010/10/23 Ethan Blanton : > S1 ... S7 are sent. =A0S1, S6, and S7 are lost. =A0The sender retransmits > S1, gets a cumulative ACK for S6, retransmits S6, then gets a > cumulative ACK for S7. =A0Should it retransmit S7? =A0Did the original > transmission or the retransmission trigger the cum ACK for S7? > Consider the case were S6 was not lost in the first place, but delayed > in the network for ~1RTT. =A0Now consider interaction with timestamps, > DSACK, etc. where this potentially *can* be disambiguated. In my feeling, this depends on the pipe size. if cwnd - pipe >=3D 1 SMSS, we can send at least 1 packet. In this example, S8 will be sent. ( rule (2) in NextSeg() will be applied) If S8 can arrive at the receiver successfully, the sender can get good estimation for lost packets by the ACK for S8. Then, it can retransmit proper packets. However, as Richard already pointed out, if this is the end of transmission, there is no S8. In this case, I think retransmitting S7 will not be harmful so much. If this is not the end of transmission (e.g. application stall), I'm not very sure whether we should retransmit a packet. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp