From nobody Fri Dec 2 07:58:50 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C91129435; Fri, 2 Dec 2016 07:58:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148069432846.29651.13027058992513141015.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 07:58:48 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-cubic-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 15:58:48 -0000 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 of the IETF. Title : CUBIC for Fast Long-Distance Networks Authors : Injong Rhee Lisong Xu Sangtae Ha Alexander Zimmermann Lars Eggert Richard Scheffenegger Filename : draft-ietf-tcpm-cubic-03.txt Pages : 15 Date : 2016-12-02 Abstract: CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase of the current TCP standards to improve scalability and stability under fast and long distance networks. BIC-TCP, a predecessor of CUBIC, has been a default TCP adopted by Linux since year 2005 and has already been deployed globally and in use for several years by the Internet community at large. CUBIC is using a similar window growth function as BIC-TCP and is designed to be less aggressive and fairer to TCP in bandwidth usage than BIC-TCP while maintaining the strengths of BIC- TCP such as stability, window scalability and RTT fairness. Through extensive testing in various Internet scenarios, we believe that CUBIC is safe for deployment and testing in the global Internet. The intent of this document is to provide the protocol specification of CUBIC for a third party implementation and solicit the community feedback through experimentation on the performance of CUBIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-cubic-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-cubic-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 2 08:06:29 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9909D12954D; Fri, 2 Dec 2016 08:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfqn-3s68Gey; Fri, 2 Dec 2016 08:06:24 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0049.outbound.protection.outlook.com [207.46.163.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191C01294C7; Fri, 2 Dec 2016 08:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ASM9WHYgmMIeMOCaYedoMCE4BpbMMH7vULgxiDkzX74=; b=DSEIbV16Av/njx4TdHB26lQV3/I+Pz3vMzSnU4VzGCcbIkzqx+a5x+9E9qRxH/TzC6UycPz0zOwEB171bJe0ZhIPM24j5/7XqrCMtrgMj18kFqoz1O4syxbItrB4NEnUGd0azen/GCjhSHDn/l2aEHKB71WT7OYxwyrXB+FJjRM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [10.211.131.14] (129.93.4.25) by CY4PR08MB2519.namprd08.prod.outlook.com (10.172.156.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Fri, 2 Dec 2016 16:06:22 +0000 To: References: <7910_1470581922_u77Ewfxw007346_85d0d695-d8f1-e404-d0e5-23b13963bfd9@unl.edu> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: Date: Fri, 2 Dec 2016 10:06:20 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <7910_1470581922_u77Ewfxw007346_85d0d695-d8f1-e404-d0e5-23b13963bfd9@unl.edu> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.93.4.25] X-ClientProxiedBy: DM3PR19CA0036.namprd19.prod.outlook.com (10.164.243.174) To CY4PR08MB2519.namprd08.prod.outlook.com (10.172.156.140) X-MS-Office365-Filtering-Correlation-Id: 7fa6cdea-3271-4c1c-d21b-08d41acd294b X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR08MB2519; X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2519; 3:OQykXIYjA+ikDecBaCxQfxRe4e+RXAUO5ZQ+EM+oxM7DhibREyPr0xRtO3yKvTlk4vn/nZE4oPZQd1s5TFGQaj8vQqQemp+B0D5vpdWiWNGgxeUc3mig3EUiPib90GKmqCwCGh1Cwl3lItAcgAHOFkBftxE0BVAQBwS/pwYWYZRqHLXWbryd8o/yjgFw2WHABTNb+3vgJN+ftWjDzjpiJ6YVCe2Fgw2Va88BOxcWIlgTNMSKexJlbOySrc+t/o41r6+rsfzgpUorMXBzWdMhpg== X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2519; 25:tdSV5dDg2uZyd9DTQOSPi32u/I2bMAHlLsQro51NBD3SKG7LtDPlRMBfZeaRF8ncMQG+M9XnJAX8+Z8xglbSGZn2Vq9dishkTwxJEJ91pyWI3j6I9FTvFCiX4cqATRzww2SGz+1S4xx2XQ2g4tdFFoTiC7F/H6fXM8XC0+F75cfjYzoUEyXyhJ/oDR/RhKHO7xOHi5ItyzkrZm3adyKa0YQxGuyDNZU7PAYCzJwNJmKpa1CRlBLpCpNoFDubDHurQwlbSsErI6ODD6wWpnKiS78jQXqr2dgXEceQYi5ZOYnDg57HozM1He0Ap38IQDW+nBquBnGAvZn3NahD3G3/yPIP9EAzNuJbR5Zn6y7mynERb7jM+6FbNZjgzyrBap7meqeLj42Ym5B7AkIb9TNBpd59ujEwDPLNQ9NZGqYxxPCvR1dygt6+zvsN8g75pYADiEQLFg4DPoIfqAiHLhryRpYeP9uuNZztFBwWWEhGgRmJNsOJDI8dvib/+q0rjClSDenGxXuj+wxO4ukSZSLXT9PTT7fhXIKlcAu76NlkBpt21ptJ1zNmML24IU8pQhU9s/4GEzlLgGLYWRNaRD6JCZeJ+QFWc5UIgHW+fAvJ11rvpDaleRwjk8qbayviLVkvd/WQWGm0J3K6MkofPgUN7MxD1JkyEhPeYaRFjVdeR0OWoHPVfRGbXVvnFqkzpqvBsx/aqyw859RsSZH71ha+c4vrlGED0YfxLPJ9Sf/GwAMFYOrOQbHf1mtJ594A8GjUYwNDAotTRBq8L7H1qFH6V9jVdtUAl711f2RBaBOMSp9GGQski7eSp2UWveoLZDMgAYy72exddsPFkFI0Kh8HEbzqOtMgS+kYulHdQtPoZLXh/YaR5R5ArBdOQhrgRDYn X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2519; 31:9LXeowD34JmzzMOzemclDA5mYpcuQxP0ecnKfDA40JT38CDyxrRIDfJTmabKResNWRd5jnpaBbgwPZJYkHE8NYSB4iGeVR/vFxlTg2NXmDaGAOyi4qQziT48G/bw69L2Vp0ymi49LnPzwDci07T0hJxL5j2nq2hyrjP5xGsdoGI/M4ePptrOOXGzvDqO1JPuTUoX3CLgVc/AVq2v0Eu7yW0k8l4LDFVRF/IPWu7OFDPUftJF/KbaoD8J3Qy6oxZG3chQAUAZhGHJ5sVU2/kpew==; 20:nFSpjLnQmkTc/bns4O5CKrnQ/v/OSql8JujCG/YWaxFHmbCtUm+Tg7HNxNiWvi+J6gpLq7wIiBnYXScWdBhvFAXXu7zyWqWA34y04ElgaUiJfjXMMVcDiWmHMFnFl5+/+zHNlCpzpS6rONFIf2EsgQFEHoek/ZA7/hmNsWaADs1jIKD1Jj9f9WBPXvuWlCIxez57zng89jwmiULwZMZk2vtraQqJSRf5ENbflYDDKvxUcGj7dS6ecTq2dREXswWFKRCUu4jEsv6cCnbVFRRbEPmy2jzp2oHzAXJ5YexWllb22v+NIl4BXPETH65PrDXNWOJQfeBgftkRvrb9+yFNFDY+zTxB46DFU5wpnJe2xIEJdolpJxiKQriAntvSG/7ZoZ29sTfznApdO8NUlF+F1Gvaiy5F+aJR5fOseE6DKmxBdkHMAv5dF/RQQ/ieI9J8JVAg8LhdCJKWaI0k0PE/1XSF5HAEsNI9NkdANBYM5xA6jtWAe6RX6lLvdCB/RwmP X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123558021)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR08MB2519; BCL:0; PCL:0; RULEID:; SRVR:CY4PR08MB2519; X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2519; 4:Ce1oMLHNGV5SaVETeHuRFj3/GedK0cHim4vWnEn2VWbjhR/dUEHyElC/AVqLygB5RSnbd8Hqnpsd01Tn6NtQyA1DnL3gpMWFBlj4MiDS6yY6ZlYjtPQSkfpYLoP4PimdX5gE1vbtoGXmQM7tDykYjhcd5zAHJfUElePhQOu3hzvXWsburDSxRE8CGaF66Xh8YcmLBoTgeb6zhJjj4D7cSWSmtPkh62e1nYrkIniEscPxjLoCsXKxzYWCa/V+reH3L6oNy8133/rFND6ll0zl10tcDFcDYnweUf5Tani/0dgFpgXh9+6+brAgOfRmsaWKFmhE7ZQe1Ev+5AToTV2CUIGjerdWiiNPLUA2vof/hzZuDSeXYYBLnDilkc2aURiHxjDPll9fNaE7SxWryVtEWZ1gzBXVxRfiI/XhqWd8kZ7z1spd/ORxV/1pVr/JzQ1PK4394mRjduOchXC4M4yxX9nFgHvC/VJdz8o3P5Y5YZ3zrlYF6AJYMV4gyV5+XQDE5eztbkIrTN7nJ1VhN/PFLuzsm2kicKH+kmbOGIkMH8pebaxDlvKSkUQqDzYf7L3+gzzvegMNnoW5mL+uCs9KSXUdULy76QJjdPT36PK63Q4= X-Forefront-PRVS: 0144B30E41 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(189002)(199003)(54356999)(6116002)(3846002)(31696002)(90366009)(89122001)(47776003)(86362001)(7736002)(7846002)(4326007)(2906002)(101416001)(76176999)(23676002)(75432002)(90282001)(230700001)(83506001)(33646002)(88552002)(39410400001)(5660300001)(6916009)(733004)(2950100002)(110136003)(65826007)(64126003)(81166006)(39450400002)(65806001)(50466002)(305945005)(50986999)(2351001)(77096006)(6486002)(65956001)(189998001)(97736004)(81156014)(38730400001)(42186005)(31686004)(66066001)(92566002)(106356001)(4001350100001)(105586002)(36756003)(8676002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR08MB2519; H:[10.211.131.14]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjA4TUIyNTE5OzIzOk43bVBPNmlnMm9OcmVxSnRlU1Ivd2RPaENQ?= =?utf-8?B?Z3pHS0JRQzlPczhFbTFhcWM1Y2FJUUdqS3NNV1FIZDlkdlJac3ZHUUlyRm5I?= =?utf-8?B?d0hDMmFqa0lzWlBIVmxRcVhKTm44SzY1YXdmekRtejdlcnRGYWF0azFQbGRQ?= =?utf-8?B?dEtWY3dhR01mcmp3MmU2OWJBUThzajJoQ2NHK3NQNXplb1JnVU1xZzNRcGtN?= =?utf-8?B?WnNHZWl6czg5RE5haHZQbE5CR2VaNEpBOFlPOWR6aUxPeThGWmhxNmhISXpG?= =?utf-8?B?UzZ6bUc1Ry9vSHExdWw4QUhxb1FGODhwWkFrUXQzY2FXYVYzMHNaVHVveG5O?= =?utf-8?B?NjRqLzcvZStsQWt1QnBUNzZyWCtnUWs1eFlMRVZsTXoyME9JTU5OYVpWd1NS?= =?utf-8?B?QnhzSVNibmE3TkpjZ3ZEb01UMXJrbEtyck9hQXVSNnhxS0dMQVV5a1NycHIz?= =?utf-8?B?WldKWkNZMmc1bmlLYnNVa0FLWHRJZ2FraXdhRnVlbWpTbHJFRDFNc1BPZG1K?= =?utf-8?B?dXljM3pWTk1ITkt3UWR1WGc2YzRXSlZwUTViYU0yY0lVQzJTMTJqQldmVXlq?= =?utf-8?B?V2VPaUFSTkx0c1ZHVnhYVW9tMWs4WW5MT3NrK3poVEtSU3lmT1hHUTJwNzZQ?= =?utf-8?B?VWdGVU5IS09aYTNLQ3QwNWJPb1B5dmFvT0p1ZXQycXlUREdoK3Y5M0tsdE9h?= =?utf-8?B?YkcrTW83a3FSOEpDTlZZVitjQ3l1UkhvTXBjMlNOSW5tTU5jVFg0YW9RVTVT?= =?utf-8?B?djhEVm52ZHdtcVVRNTQ3d1FMNWpVNXFhVGFwQ0s3cmY1YnFrNWh3dDZhRmo2?= =?utf-8?B?Z0M2dXY0dG9EbVZXbWdmMDhFMDlVUFBLa1FBNHNqa0hvZXRxamlyQXd0VWY4?= =?utf-8?B?eG42RlpQdUJGOVc2QllmaERVVmN2ek50d3B2ZDV5MmRHanNUOUFMNy9UdENU?= =?utf-8?B?VkdpamdKZGRPc1dqK1kwYUxtT29UYU1iYWlvOW5GeTZvYXR6TkcveFhsdTlB?= =?utf-8?B?a2JQbFdWczZRS09Cc3dMcm05VWxKNkV1RllwWHowTktXMHZjdXZ0M2t0bGlK?= =?utf-8?B?cjJCamRKbUFxQ1Z6NGpmUmdsMm5RS09BQ1ZzOWR4alc0Nm1PV1F0cmF5eWx4?= =?utf-8?B?ak5UV3lQQkcyWjJheG4zaHRZNGNjSmgzMEpYNS8zcmxraU9FR3VFQ1BJMHFF?= =?utf-8?B?SUcvYVMwM0lIbVJKSFFtbnNXNkVIdGJLZGhnRjliNFhQdGo5Mmt5VklMeWFG?= =?utf-8?B?NWNtajczbm5PVTFZUlhnaXlOR3ZuRXZLWDJTRm93cEtVUDRFL3haRmFpL1Qy?= =?utf-8?B?SVFTZXpWdUM1WXNLeXJ3eGN2OUxjR1lwUnFzNllSd1ZaWWE4NTI0dTJ4c1pK?= =?utf-8?B?aW5SSktia3RBMi9wdS9zbS93aTBYWVdvQTVUZVNERk9JS3JlSHFrNmN3QVhh?= =?utf-8?B?cUgwZVVhV0FmZitPTXE2c3NzQUoyMEJYZW1nU3dYK01CMkVhOGF3MktRZlRi?= =?utf-8?B?c2tORE9nMzFscFVyOUd3VFdvOXk4VnpUR005S24wblJ1UkpCZWtkSEQ1MG03?= =?utf-8?B?aE9VTFZ6Wk02UENVcy9ieWhvZExpeEVYbjVMTitNLzJvSmdwamtYMW5mTVpG?= =?utf-8?B?SzJaWS9yNUhLWVlRVTJhQmlxTXdhV0JveXF5U2dzQ0lTdFpUZEpVRGpYNENP?= =?utf-8?B?SmZvNTg1YkVzSFdkZ29OZm1uM2ZMWlE2K0Jva3JZTkhzbWhiYVpqRk0rSUhp?= =?utf-8?B?NmdtUWV6Q1hXSGg5emVieGtXRTBOdHpMV1JhUGNGZWJPQ0tMRmZXK3FZQ1Zt?= =?utf-8?B?VDhhZis1Z1labEJPN3UxcjJhMm16K25BeVovOG5vS0tuYmxRYWJYRW5jQk1v?= =?utf-8?Q?VCH0ZkrrMH0jFyPQ61y5iOC5ELKoXVdC?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2519; 6:vv3tzzwwy6pHb50G1OaOf4aOd5yCXOJoMVqwE1X+sQc6ShhQrA3ctZ7cVRyma1e9SZZEO+kdYRoQ1cxvM+EW46T0iCH5Uy2VsGjsagxgGg1W2/tPg5rG9cDL+h7bXQsHR/+qAhCiJW0U2yAdBKTLMHd8k+unIBHo1kEbwqvz7VGJ/lmXuQckiTwXXRkYxe4UtALhE/3t1vfXcjPRZ4uSbkceCar6pPN/cPhePkB5Pd2JJuW56wPVth9fpU09Sdb2Dz3rNH1PRBOhzcxdvE2luII6W78dxHHk/V1LwQ+6fNu3b3aoFIXSIQWpBgZWJJfd8EgoKo+nJj1QG0ckv9f+w/IN0waVvGVzJq+Pt6pkOAs/1GAA7GQPx4KeMJR0UTWzEKtM00OHHcXkWCDLw3bAH7aj8B/hmRx0nYobE0/jJkMrdrD+luts4MEC/u8nGILxtN2J0IUT3z4JsRxaw0wuPQ==; 5:4iBABy+m+1azW7nNF1V03+au9EnbU95cQuQ+4xHKMvCWAb90FTzs3zvIFg4POwvYC9DKHG2f1rZulwKetSnFignyiaP33s5LFqw37/Zk+vZAZovfyQ8anE2La5B5VnZfXTFI2KVTcT8/4iPAcYb5Vrw2O7dYKC+qyJXopiSttW8=; 24:CwJ9h99Lx/EsLePaOKObH67ave+HLeNoxSMge2YaFw0jdoE929oYk3IqHX18vRSOYrZnyv/YBNaEk09jmowTCYhNVmyzwzUtvWgTWbyV3jE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR08MB2519; 7:hzZbmvXWSXiJKjoJ+2z3BD/CAuwrqLnUmQNDaurv6TcutslGnf2e9/9M/P9/wz+zdRypcBaHl1diZYtPWjd4WSSOwnBAZqatioGCD2rJ8y/6BrDuNFHTM4c9fI4IQjSr6zGBqyz5N7rIiHiFPxjHDp1FVC5qa6AktXWF+QVhgz/l+4VYSGg18ZWwdshA0aJu/z+SkbxfdT5X2fevPMH7StP+0qrTGI5Xua0R5Gi+4WDP3QwqF+9QXSmo/2cewPi+t5P2nktNeaUXFkDqQ+lAt7QLR9GwZNcMBFifhB3md0V0YOD7HwTb7OfQGcCRdGt14x0xJircwOxmrmYJ7vpDKchNNrPin/ufc8TybI25GA5zxy8Hm2Eqe3gIvg4JOAJhDoWQ2j1/dZhRjIO/irHvm8zbmaZazZ522Ccjx96ni9sjSRx9CUIrYZgCrexmMqnVvGoB+RaCG7EMAgUtxPhzjg== X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2016 16:06:22.5972 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR08MB2519 Archived-At: Cc: draft-ietf-tcpm-cubic@ietf.org, tcpm-chairs@ietf.org Subject: [tcpm] A new Internet draft for TCP Cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 02 Dec 2016 16:06:27 -0000 Greetings, We just submitted a new Internet draft for TCP Cubic available at the following link. https://tools.ietf.org/html/draft-ietf-tcpm-cubic-03 In this new version, we made the following changes based on the comments received on tcpm-dubic@ietf.org in September and October 2016. * Updated the contact information of two authors * Section 1: Briefly explain that the throughput of a TCP is equal to "approximately, window/RTT". As there was some confusion about the window size and throughput of TCP. * Section 3.1: + Add explanation of W_cubic(0)=W_max*beta_cubic + Add explanation about RTT "where RTT is the weighed average RTT calculated by the standard TCP" * Section 3.2: Add a new paragraph to explain intuitively about the TCP friendly region. "Standard TCP performs well in certain types of networks, for example, under short RTT and small bandwidth (or small BDP) networks. In these networks, we use the TCP-friendly region to ensure that CUBIC achieves at least the same throughput as the standard TCP." * Sections 3.3 and 3.4: Add "where W_cubic(t+RTT) is calculated using Eq. 1". * Section 3.5: add slow start threshold calculation "ssthresh = cwnd * beta_cubic; // new slow start threshold" * Section 4.3: Remove sentence "It is not designed for wireless networks" to avoid some confusion about the types of wireless networks, types of problems in wireless networks, and the potential problems of CUBIC in wireless networks. * Section 4.5: changes from "In case that there is congestion collapse, CUBIC behaves likely standard TCP" to "With regard to the potential of causing congestion collapse, CUBIC behaves like standard TCP" * Section 4.8: changes from "In cases of idle periods, t in Eq. 1 should not include the idle time" to "In cases of idle periods, t in Eq. 1 MUST NOT include the idle time" * Revised the whole draft to clearly distinguish between the loss events detected by dup ack and the timeouts. + Section 1: from "after a loss event" to "during congestion avoidance" + Section 1: from "following a loss event" to "following a loss event detected by duplicate ACKs" + Section 1: from "since the last loss event" to "since the beginning of congestion avoidance" + Section 3.1: from "when a packet loss occurs" to "when a packet loss (detected by duplicate ACKs) occurs" + Section 3.5: from "when a packet loss occurs" to "when a packet loss (detected by duplicate ACKs) occurs" + Add a new section 3.7 to describe the behavior of CUBIC in timeout: "In case of timeout, CUBIC follows the standard TCP to reduce cwnd, but sets ssthresh using beta_cubic (same as in Section 3.5)." Thanks Lisong From nobody Fri Dec 2 09:26:30 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDD31295D5 for ; Fri, 2 Dec 2016 09:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKKIlb0DzlLu for ; Fri, 2 Dec 2016 09:26:25 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1931D1295B6 for ; Fri, 2 Dec 2016 09:26:25 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id m5so355398280ioe.3 for ; Fri, 02 Dec 2016 09:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YCEhvqWGfiMsg7yahR5+dr46ebrBP4OW4VcttxqC9BM=; b=kC5Oexg39HycNR84KrAoav7YGABoozvQzOph4KD+egB3mi6bRZDB/bHKcE6z1b6g4n fW6NWcLnBN13VM65hghF5w+z5JhYQp0TXuUDTonevUiAzjqpQY2k1Y1LUEN0nXO0tuoh jEj++EDSR0VEWTAM6gl2P9d8Me7RRBN5eFg8woEWACd5IGVvW44Wxn1xlMWVvmg4Mf9r 0LLs5YUW83zKHViua9CbauOnW+/DDN7a2839eZt+SuDVXL6X2OeXUr1uSp8RUGNMJYxU Yrmty94M1ExlpJfBUBWcJmBO+txg8RT48x2GaFyBKAexJiRr0TRQl61uUFsyVJJuxcDV p79w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YCEhvqWGfiMsg7yahR5+dr46ebrBP4OW4VcttxqC9BM=; b=XQgINGkfxJTVAQEvX+aLER9GZFBE7mpekvIAo0DpebNZC8hG6kz0/lvpWBO/0yxwiK iPcdrd+1DIL4y2ioss8MQW5sp2uewttxz5FD2GFzhnfZvlEGWXDU1lvciMjjO5s81ZGo pVNHQJxf1fAnBPSwuoblkQD26/BaSeMmgfTYa9h1UQocfPXV2vLkBvHa5askl+jq4ZEK sfYsOqPJt8ziFh6xUcLOAX4x+Ih1udwCxz8UlOKTXx1OTFnnZ/Nb1z9XBlFEWJk7fr2O zpTuVjugUr+/dPoaBO0AfV8q8b1R1XWT4vXs276S+NjYat6uBjztwU4ptUV4F94ibEXS L6YA== X-Gm-Message-State: AKaTC02HIFdR4/lI+ntKp0K9dIGm4+AkkQBFyvRt+FlYHWC9MGVh6OLmuAnlCLsZFoadHZjNoJNPzHuRmtCD/SRd X-Received: by 10.107.18.230 with SMTP id 99mr36540576ios.41.1480699584153; Fri, 02 Dec 2016 09:26:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.169.33 with HTTP; Fri, 2 Dec 2016 09:25:43 -0800 (PST) In-Reply-To: References: <7910_1470581922_u77Ewfxw007346_85d0d695-d8f1-e404-d0e5-23b13963bfd9@unl.edu> From: Yuchung Cheng Date: Fri, 2 Dec 2016 09:25:43 -0800 Message-ID: To: Lisong Xu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org Extensions" , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] A new Internet draft for TCP Cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 02 Dec 2016 17:26:28 -0000 Hi Lisong, The new draft looks much better. For clarity, I suggest the draft explicitly mentions the interactions with (classic) ECN, even RFC3168 already mandates treating ECN as a loss. If Cubic only reset the elapsed time "t" only on loss but not (classic) ECN, then even if it reduces window by beta on ECE ACKs, it'll still grow the window too rapidly afterwards. Current draft says: The window growth function of CUBIC uses the following function: W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1) where C is a constant fixed to determine the aggressiveness of window growth in high BDP networks, t is the elapsed time from the last window reduction (measured right after the fast recovery) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Fortunately, Linux does implement this tricky part correctly. Not sure about other implementations tho. On Fri, Dec 2, 2016 at 8:06 AM, Lisong Xu wrote: > Greetings, > > We just submitted a new Internet draft for TCP Cubic available at the > following link. > > https://tools.ietf.org/html/draft-ietf-tcpm-cubic-03 > > In this new version, we made the following changes based on the comments > received on tcpm-dubic@ietf.org in September and October 2016. > > * Updated the contact information of two authors > > * Section 1: Briefly explain that the throughput of a TCP is equal to > "approximately, window/RTT". As there was some confusion about the window > size and throughput of TCP. > > * Section 3.1: > + Add explanation of W_cubic(0)=W_max*beta_cubic > + Add explanation about RTT "where RTT is the weighed average RTT > calculated by the standard TCP" > > * Section 3.2: Add a new paragraph to explain intuitively about the TCP > friendly region. "Standard TCP performs well in certain types of networks, > for example, under short RTT and small bandwidth (or small BDP) networks. In > these networks, we use the TCP-friendly region to ensure that CUBIC achieves > at least the same throughput as the standard TCP." > > * Sections 3.3 and 3.4: Add "where W_cubic(t+RTT) is calculated using Eq. > 1". > > * Section 3.5: add slow start threshold calculation "ssthresh = cwnd * > beta_cubic; // new slow start threshold" > > * Section 4.3: Remove sentence "It is not designed for wireless networks" to > avoid some confusion about the types of wireless networks, types of problems > in wireless networks, and the potential problems of CUBIC in wireless > networks. > > * Section 4.5: changes > from "In case that there is congestion collapse, CUBIC behaves likely > standard TCP" > to "With regard to the potential of causing congestion collapse, CUBIC > behaves like standard TCP" > > * Section 4.8: changes > from "In cases of idle periods, t in Eq. 1 should not include the idle > time" > to "In cases of idle periods, t in Eq. 1 MUST NOT include the idle time" > > * Revised the whole draft to clearly distinguish between the loss events > detected by dup ack and the timeouts. > + Section 1: from "after a loss event" to "during congestion avoidance" > + Section 1: from "following a loss event" to "following a loss event > detected by duplicate ACKs" > + Section 1: from "since the last loss event" to "since the beginning of > congestion avoidance" > + Section 3.1: from "when a packet loss occurs" to "when a packet loss > (detected by duplicate ACKs) occurs" > + Section 3.5: from "when a packet loss occurs" to "when a packet loss > (detected by duplicate ACKs) occurs" > + Add a new section 3.7 to describe the behavior of CUBIC in timeout: "In > case of timeout, CUBIC follows the standard TCP to reduce cwnd, but sets > ssthresh using beta_cubic (same as in Section 3.5)." > > Thanks > Lisong > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Dec 2 11:21:45 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4451296DB; Fri, 2 Dec 2016 11:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmzOMzCbiHY0; Fri, 2 Dec 2016 11:21:41 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0021.outbound.protection.outlook.com [216.32.181.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705331295BA; Fri, 2 Dec 2016 11:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=H5SFPj+wXTlKP5EfnL7/TViEJj3lfhR1h5yqapszTF8=; b=CuXODkyAXSJu9ydZMUwEIBgmn8xtUFEukpivtYqVYyWM9bK+tkssiUXPvK7D6WJln7Q5SAVeczDfH1bt7XxETaLOfsQxm1/wEguZamKl9r3PlTyFNpckGVRJ5Q5OQSFN/gCIcaoM6UWpsfANFzoxi9dqXgSOBJKhY/MACO4kK+A= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [10.211.131.14] (129.93.4.25) by BN6PR08MB2516.namprd08.prod.outlook.com (10.172.147.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Fri, 2 Dec 2016 19:21:38 +0000 To: Yuchung Cheng References: <7910_1470581922_u77Ewfxw007346_85d0d695-d8f1-e404-d0e5-23b13963bfd9@unl.edu> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <4c74f432-37d4-31bf-8a94-3d1d497f1303@unl.edu> Date: Fri, 2 Dec 2016 13:21:37 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.93.4.25] X-ClientProxiedBy: DM3PR19CA0011.namprd19.prod.outlook.com (10.164.243.149) To BN6PR08MB2516.namprd08.prod.outlook.com (10.172.147.138) X-MS-Office365-Filtering-Correlation-Id: e473ddc8-7a66-45f4-ee13-08d41ae870bf X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR08MB2516; X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 3:zqhn72F5i4jd2s19poItNnujY6be6TmKnbzgPK3HjcIhcn5FypXErTFDgDIu9MVtzbzYzcSzCXjvdk/YAGMCCZFWR1ftKp/Yro0zXOxXF9Uz8qXCyI70fKESsGdCfrzr+dAGyGRfz/F0bKfpi7XrLk2VNfanEGWv0gYDfS7rwj5KWPaEySTXeXFsv8luq5Zrwwgdxj19QTBVwNtPzoDoKeSWobJRQRnnvw4SEchEU2e6JCGVujysOPpZwBEQLk5tHTx5NF1rSLRpWYvHbcl36A== X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 25:UFXLbh/lM3b6AavelB3wKPNrykHGEVX7xd0Zens3vZ87nVMc3z+9marnG+9vnFGIkGV8PbSUHl7JGIySkGilmLlFbkpf9WlNcIw4DC5jmmvhEx4pw+ifvwkojaN5Bd2QnvtBzs9ahQ83VM9jMarvJq1pStPSldtpgNm2bt4cBVani4KrNjFYsnxj6aErZxvlrB5N1isUjHnG9LEVirBIcqoKf2ab0fhU+wN7NMb+5NRit9K5enNzQatcTG/8xs5mGq+nIx+KGkENEup/XfscwPte8rOe5w7Le3M1gdVTTK7HIUZhgbqYzLRC5r5pkxpNilcXqFkDkhYCDg3pZf3I1Fv2LlkufDZulOOTGQk9boWz1fDwsIjVXu5+R7+Zgq5dDIQh7Z1xWTrV2haGlwuWyYJRZKNM7No+1IZYivYXGBaI+kGQlrdg8pZY/NHVwR2s2ONbmPf+mW1JH09ZGdmKptfku4dJeU4gWhcuJcRqmCx2uxMMkhILKn7ixo5QooEmpm6BD++DAcEa12NQdhVxLD1doIMn9pk7PgH2LbDIWGjUUTicT1x3q6m6mqxXe5nx64Afx4tWrtdUWuop2KvhB/QBUN2SWM8Da2TwZ3AoqBsPmP4BdwqKAqA5fLqnO1RDpk+upWtFWa8UH5im7pVbHdkNyiQlrz4FfHgJ4Bilk35N0t2Oa18SHNitzkxD22IS398DapvvwhuZophNpE5bBwlVFDfkqgELPQn6RwkN4+UuxAa2m1CbRTcYjGpdc2MTOLDKNdwYt65PvXuLSrdNzo5AMD/4/rImhiH+hHZBCMbrDranRN/Vb6IpsjGq4EAOVJHGc1lqur4kq8ppMvMdNkluVZQXcz4oV3iRxY+FO1d7L7GCRf54y2s8raxr5kJ0vnmbDHG+QEAnMnR3tFoFFQ== X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 31:dT+MxzdpSor2U9p4o08p+wWdf3H1e98qubncsW9RXDWl9t7EBgl9j9J2AXxaIQSyaQz1PBdhDXKrWA9pwTO/glrGg8jmLRtyzj9K5QPGW4zv2u60ZRS+J5vABrDqo/3TCXIs47pREiTN57t6FqArMPSry/L0QharHCLcaburx60QoF/KiG5GOmgBTHTXfUcl8lHqfFpWN+8Phh+9dNwOI3UxJuG7VExP4+LtlFp1tOidG712vQwtYJwasogh+H2qMms4hvt524Qn+KrQV/sMYg==; 20:ogS+c92n0Qkg61w9yrs052iWY0V6w7pYk4M0YnkfBbfvNFOibn8ZVugTPYgjjBuyt8oGiWjnNpQKw5msq+QLEI1akoKew3GeWPKfhjeXeBNcp5rEGCJ9Bpy1H5fuEGH0uyKzIrV2GU9FhAGhYyHuq80M19ZfdobGnet/2Bj7yIIjONWcykipPJ3K8I5/j5g1CAWqU5yETxj4w99snINEde6tJHutUiCKjDEiN4DIfEmnqQlsFAvmk/xYkBXfZwx2vAoo3eRBZmsTyleMiqheVKZN1+IGeHg0ubiX8N43c8NsKfrCsqf3CqIfJFfjXDzC9Ip8ZQk2nrXAE8x8Dft9m++2UxwC5OLDuLsy7xiJSHYjuYCwihPHBqTmtEWSAjxn8aZMyRqL/cZUrri+Kv3QxtheHmSV3GrmYnJag8OrCMq6Xd2dwg6Wz+FI5R5bdFygCOqVwHZh72UDgNjgIcv4EbSAs+bFYf673rFb9rH41Bp4L2+W2LGNZQURg7KiT3nG X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6042181)(6072148); SRVR:BN6PR08MB2516; BCL:0; PCL:0; RULEID:; SRVR:BN6PR08MB2516; X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 4:E088QbI3i0GbfCpDU3NDMn11CN6rzMsh77f5x4w74xOfW+SLEX4GMzoLLvVJPBe1PKyQCxBLYW2zQYFTli1d9bG+pWzhL9WH0i0bLatIzV2ohqK8xRxU/aDsB2WP0jqdGBZ6dGhlTQ+j1uLsADFijAlHOj3VN8+4WbivhFkJAteeYv+1DPqPV4iNaGkAVpus1XdotEswBeQSSxj+tmGIaED4WPtC5QefdaT4PTjP1wcL26cqVebq0EMxmIssBWWMLQG/3zZ93GxAxRSC/9xW8h9ZldkbcPjMyeB507JSz56tVe8kLl0s6MU/qQSIFJAhlTPXEiv51nOobIiHObckNCwIz+++erc68b4Fwosh0qVw4w1Cq3c8dZDaWSwH2kFdUZMFZItiTewwpgeAHU2iPFZD8CgafIrRBMp2WZfhHqayKbC0wLXF/Uy6KBKUmXrrFEK4t6+nieAHsqlClsR81v6boWgo0t2ze61BdauE0SfhRhfoeyxcIh/cUx6+joxfdXaaHsgMIkSo0ZZHlgOCKl9BjnVGT3/je24F1yihJzusA2iEuy+xLdnmY1pOZ0N8bSeSC08zNNPpHP7lj0hpxebARst9dhUmDNktKXmExbc= X-Forefront-PRVS: 0144B30E41 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(199003)(189002)(24454002)(377454003)(77096006)(66066001)(189998001)(97736004)(90366009)(305945005)(81156014)(75432002)(4001350100001)(86362001)(81166006)(88552002)(64126003)(23676002)(50466002)(31696002)(2906002)(230700001)(3846002)(4326007)(6116002)(83506001)(33646002)(68736007)(2950100002)(229853002)(7736002)(54356999)(65826007)(5660300001)(50986999)(76176999)(65806001)(65956001)(47776003)(6486002)(8676002)(42186005)(38730400001)(101416001)(92566002)(105586002)(89122001)(110136003)(36756003)(31686004)(7846002)(733004)(106356001)(6916009)(90282001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR08MB2516; H:[10.211.131.14]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjA4TUIyNTE2OzIzOlZNTkd6RXJHMGhjbTBER25ZNDVLUEI4L0JB?= =?utf-8?B?alFIalh6cFBjc2p2TkNKTi9wRnpmKzJDS0ZUM3JVNC9YUnhDMEZLSzYwWXQw?= =?utf-8?B?QlR0RmxBU1k4U0pXL0p4c2NzV05FRExURWFLdjJ1Nys1VHA3eTlOS0o0a2Z3?= =?utf-8?B?UTF3T3M3dXJxbUdKMWQ5d2dYV21HNWJOMWQ3YzlndHJxc0lDZC9IdHYwWndp?= =?utf-8?B?SDhzc3k3RVM1c3VTVmJxd1B2SlM5SG5USTBRRU9TV0pZbjdPMGVVY1ZOMWFh?= =?utf-8?B?ek0rWGg2MHU1WHBmbGN0WVU4R0tjbG1DbFdpTWsyRjA2MkhXbFVZbzN3bGVY?= =?utf-8?B?Z0ROOCtkZzdKWldYSGlkclBKOGppL1l1c0tiTDU3ZHlFZWMrZUY2VU5xOXdW?= =?utf-8?B?WktQM0F3eFNNUmxLako2M1BBNk9PbDh1SDRHRFJsWHdxU1FteHRjV0tLMUpN?= =?utf-8?B?aVU0RmFrcnBxS2FXcCsvcklpM1N6dm8wdHVFSU8wY1BQalhvT3lHQzhDWGF0?= =?utf-8?B?NUk1VWpiL21yOTNwcEFMOThvSzE0TlRLRWlkbDhySzFKdTlEdmF0bTlxeDZn?= =?utf-8?B?VXpNbko0UFZRc0NCUEU4MnQ4RGordno0OG5YdmgveTB5VjFCNUFPSmNvOUpD?= =?utf-8?B?WWNNc3dVTkdxRXZiTHd0RkwvdTNiamhmWUZyS2dINCtGNzg0VlZZQW9hWGZq?= =?utf-8?B?QnIrSjlaQWxvUUgrL1RtcWpJcFJSQm1GTEtTbUJHMUlYdVZUMzBQcHplb2pS?= =?utf-8?B?aUxkK09qZW8xeWZlMTZLSFRiZkhZeVhOdHpUOVF4QXFKT0hjL1dxRGlhVzlI?= =?utf-8?B?Mk9McGxNU0p3bm9UcG1BM2I4NG9ES2tlUFpZNXJLSWpPSi85NXg5dzB2RzA4?= =?utf-8?B?MUN2ejhqdnh4WU0yNkRPWHIvOURFVmY3eGhLTDlnTm9WUW1hRGdNeUVxNCtS?= =?utf-8?B?MFM5Q1VHcXlTMUhqYWFnOFNZT0xIcGhOMGI5b2NFT2xFWUs4V3pBN1lvSzNk?= =?utf-8?B?YXNjRXNINXdSbGg1Wm12eTg1ZTRIQ2RVdlBRTmRuMTZUWUxKOHRTOHU2QTlj?= =?utf-8?B?bnA2NWZneVdtZU5iUE4wUEFOWmpSd2RjTjk4Y1ZSYzF5cU9ROE9EK29hdlh5?= =?utf-8?B?Vm01Wkg2L2I4SEs4K1Y0R3lLdzJKRnBsZmc4MzBsRUJCRDNGcTdjc2M4citw?= =?utf-8?B?RG5WOEJxc25hbDB2YjBjVjVYUDBReUxlSFFYVnVZc1dXMk50SzcyaHZjd2lP?= =?utf-8?B?TVBDMnZEejdaanB1NG9rS1F2ajRwczNXSmZVdWt6d1ZoSGloQlZhZmEvQk02?= =?utf-8?B?VS9yMW55Wm0wOEUvbDZWZWZDTGNYclRpM05Yd0JLd0xBTElNOVZaYnphZEtW?= =?utf-8?B?U3E2MGovVnp0YnRoSkVndlpPbTFYc245ektoS1VadmZyeTY4dEtDblhnckh0?= =?utf-8?B?Qy9ueHN6YllaMHpzNG9Udjk5WHp4bGZLVE9CWko2d252RUVFbVdiUFJtQ0Ft?= =?utf-8?B?ZnFzUlNUUG1HSCtPVlpBVUtpWmQyNVVsM2tDaE16aEZsVFRxcnJNbHRMSmNW?= =?utf-8?B?RHBKNlluNTJUZXYxdjRGdnNzQzhINVJXL3RGNEJTdkdwSzFYRmt3VGZDZldH?= =?utf-8?B?Z3pvd3l6c1JheVdkbWRvUGFsWVBOUit6MFJjTHJRUXgyT3VZVDVDNExmSHQw?= =?utf-8?B?Qm96a0F0ZVV1d2JiM08xK2Juc0cwNTZmdlZNem44M2NReVp2ZkI1SkF5NCsv?= =?utf-8?B?OEV6Z3RqUWp0R0VMb1U0RGZGYVdKSzhNcUI3MUxWYXlKQjJrWWZXZXBFYjVS?= =?utf-8?B?ME14b1c5R0ZQN21kMUpuRXBRQ2liQ3JDMS8zR21zaGNsNnZycTdmam9TeXRk?= =?utf-8?Q?Uxguy4ikC9T4sx14Bpozym3kUcLisDBH?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 6:QGLAifmUXSkCeSmyGT0VTiZTCgnv55ecWRWeXieIvK9n3vzgD2ZqXDv9VyGmZI9VS+zWa+Uezuli4mYy6PT/Va6WpiE8zFsuo3FJZ3fNTM/1bcC6BgPC03G60e95ZvPo5YV4ChDNFoOOygQqtfS1JlX0PYtTciosCJmQwnHH1ssFtB/mqb8lB6odtuCa7qA3sZNLMSmHkCJz2pIA1RwCV3WPVeJKWRNDN2uyY62i9sOqP+zl18kSxTGRygUAHJYgUPZkFYq+Z0sUy5ynQWNxUQE6g4KfYq0GPzjCdMI1u8HA0gUZK7SkwXdV2OmFoF7T40JgUv/hX6HU6GxkSsi6z4eWryQpaXeZ4w6BeeWMsaI6wUJ7df/0eTBrzEptVv6yaSNwvXuHp9Rj55WOj6kGlduYa48NBALZgmoygRDKxJ4=; 5:+RjkwsAqnZcinfgIUZgcBb1/U8v3B6nC6qdO2BymZHL0sbIjrf/SKJmliW7OHBUcZcqSqV54xkhT3LlchZ0OpZXVWrrM2q/QCd25PlFvY7SRCLzfHkS66n+vUda3FQKDRazSTY2WToyc4n8oG40BeL9GIkq1FHZVPmKUoUNTvPo=; 24:5+4FYMBiEPJ7/z/M+NWIG0XUrcvzcjg99KR/t4jrgWZgPPZD5bEXlSvbq90Q2wOb22XhmJOvgX9GLGO/e2gYzL6PIqNDH1vroBwVDLJ52uU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2516; 7:wU1YfpfhO2EhnOKVY43NBiKzcU1kbX906WQHDZtwE4BuAICVfTqR15bJQngfnQLxRhvk3ZDu7JEZTxk34KUKiZAw5cz26w/+2m7qk1Kj5Cg8zNUao3fRKQR1tyXZbqPPi2f23kyUJ/+BYvssPpYVo7QVBzkOt8PRbhLS14HV/xhYn5Wmnf1Mo3O/qNng9W9VLeZkNFiDzTnoTSEfXc5T/ijwWD9hS1gmKHVV4Xyw+Fj9EHVYkspzIVDRsWZC54JGXYBW3XtjlaLgJo9nYmbnWi3B3aawrDo8Ykv+PRKexNu/IddzeD6zZ8Z4X1HBiOCtsVpQ17UXVQ0u7f14c8rQFwORvy6ByqAHELhO6zCN2NSKmZkeJouHRTEPkFvn5itHGWNK9H1U32Iq4OMj8oMGov5IrWvEO88PuDBKYiEsjWMzr/IDV6DTwjh86CEBSL1AOcX2y0jG+ll7yhx8qukSFQ== X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2016 19:21:38.8410 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR08MB2516 Archived-At: Cc: "tcpm@ietf.org Extensions" , draft-ietf-tcpm-cubic@ietf.org Subject: Re: [tcpm] A new Internet draft for TCP Cubic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 02 Dec 2016 19:21:44 -0000 Thanks, Yuchung. Will change it in the next version. Lisong On 12/2/2016 11:25 AM, Yuchung Cheng wrote: > Hi Lisong, > > The new draft looks much better. For clarity, I suggest the draft > explicitly mentions the interactions with (classic) ECN, even RFC3168 > already mandates treating ECN as a loss. If Cubic only > reset the elapsed time "t" only on loss but not (classic) ECN, then even if it > reduces window by beta on ECE ACKs, it'll still grow the window too > rapidly afterwards. > > Current draft says: > > The window growth function of CUBIC uses the following function: > > W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1) > > where C is a constant fixed to determine the aggressiveness of window > growth in high BDP networks, t is the elapsed time from the last > window reduction (measured right after the fast recovery) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Fortunately, Linux does implement this tricky part correctly. Not sure > about other implementations tho. > > > On Fri, Dec 2, 2016 at 8:06 AM, Lisong Xu wrote: >> Greetings, >> >> We just submitted a new Internet draft for TCP Cubic available at the >> following link. >> >> https://tools.ietf.org/html/draft-ietf-tcpm-cubic-03 >> >> In this new version, we made the following changes based on the comments >> received on tcpm-dubic@ietf.org in September and October 2016. >> >> * Updated the contact information of two authors >> >> * Section 1: Briefly explain that the throughput of a TCP is equal to >> "approximately, window/RTT". As there was some confusion about the window >> size and throughput of TCP. >> >> * Section 3.1: >> + Add explanation of W_cubic(0)=W_max*beta_cubic >> + Add explanation about RTT "where RTT is the weighed average RTT >> calculated by the standard TCP" >> >> * Section 3.2: Add a new paragraph to explain intuitively about the TCP >> friendly region. "Standard TCP performs well in certain types of networks, >> for example, under short RTT and small bandwidth (or small BDP) networks. In >> these networks, we use the TCP-friendly region to ensure that CUBIC achieves >> at least the same throughput as the standard TCP." >> >> * Sections 3.3 and 3.4: Add "where W_cubic(t+RTT) is calculated using Eq. >> 1". >> >> * Section 3.5: add slow start threshold calculation "ssthresh = cwnd * >> beta_cubic; // new slow start threshold" >> >> * Section 4.3: Remove sentence "It is not designed for wireless networks" to >> avoid some confusion about the types of wireless networks, types of problems >> in wireless networks, and the potential problems of CUBIC in wireless >> networks. >> >> * Section 4.5: changes >> from "In case that there is congestion collapse, CUBIC behaves likely >> standard TCP" >> to "With regard to the potential of causing congestion collapse, CUBIC >> behaves like standard TCP" >> >> * Section 4.8: changes >> from "In cases of idle periods, t in Eq. 1 should not include the idle >> time" >> to "In cases of idle periods, t in Eq. 1 MUST NOT include the idle time" >> >> * Revised the whole draft to clearly distinguish between the loss events >> detected by dup ack and the timeouts. >> + Section 1: from "after a loss event" to "during congestion avoidance" >> + Section 1: from "following a loss event" to "following a loss event >> detected by duplicate ACKs" >> + Section 1: from "since the last loss event" to "since the beginning of >> congestion avoidance" >> + Section 3.1: from "when a packet loss occurs" to "when a packet loss >> (detected by duplicate ACKs) occurs" >> + Section 3.5: from "when a packet loss occurs" to "when a packet loss >> (detected by duplicate ACKs) occurs" >> + Add a new section 3.7 to describe the behavior of CUBIC in timeout: "In >> case of timeout, CUBIC follows the standard TCP to reduce cwnd, but sets >> ssthresh using beta_cubic (same as in Section 3.5)." >> >> Thanks >> Lisong >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Dec 5 01:01:39 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3011293F8 for ; Mon, 5 Dec 2016 01:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tieto.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqVThYUjZDDI for ; Mon, 5 Dec 2016 01:01:36 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68885129850 for ; Mon, 5 Dec 2016 01:01:32 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id c21so541196659ioj.1 for ; Mon, 05 Dec 2016 01:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc; bh=ULlONz2MUIrIMxQmSHyf4EjTVy3qs0aRCthVocCBkGg=; b=3+kwHGLNWRd3Ec3DGhIkyHqq2CepuusXCkcoLKikcaDUjDuG4aEyUNmUL46U+LH2La 7v/NRjDodY7KiFwDbUSflyecqb58658pzJrVjIJB4ACN92MJuGuXz/WsGKAKAGjm+4NU dM42e9xPdMmx76Se4ZJ7VQTsscbR0XnxCbL8E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc; bh=ULlONz2MUIrIMxQmSHyf4EjTVy3qs0aRCthVocCBkGg=; b=iBRxVVpxNg/FCZAkXtzbPdV/WgoV2w0uGiNByb2zI+gOhQX2zW3Oi0BmMnSyJ5wEV1 XVczo9yTjjjMlTXd4ZrSQ1S9Deg2XDPDnLVeKmsSLfYRBAPHQT5BgmnObZdyF4bzrIq1 n37WmXgi2FCmw0pQm/R3nhlezbMa8PGr4AiQMV4UPgn1gfPpoTS5E1wF47jga7OgZuWB kfeOc9bBjzLYTxYysBDKyULZTo/f5g/lPQZOGF+Z4gXkoE7cGLuyqWb3W8yVo10+cLUv XjZV0hiNCqv+JjdHiNh78IIoyh4xHUSh4lpEXhM9aczSLNPIeBQMnBNx3q/dMCYpNhUa MNnA== X-Gm-Message-State: AKaTC02Ng1crPL6g6mGSrqyUvWFj47HRmzI6PilaG8wlpXVDbou6RQXwNEypefa/HpfrunCo/ylXnWp0V8ce1qpKtrTA6bdlVp6kmZLv56kxwzy2zkzVF1LRfcX3iYM3+zRmF3E= X-Received: by 10.107.59.87 with SMTP id i84mr44693756ioa.204.1480928491288; Mon, 05 Dec 2016 01:01:31 -0800 (PST) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdJO1ioNLUmk0y5KTGaYO1zuvkZf8g== Date: Mon, 5 Dec 2016 10:01:29 +0100 Message-ID: To: tsvwg@ietf.org, draft-black-tsvwg-ecn-experimentation@ietf.org, "Black, David" Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] DCTCP and draft-black-tsvwg-ecn-experimentation ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 05 Dec 2016 09:01:37 -0000 Hi, This very likely has been discussed length and I just missed it (Sorry). Why is dctcp, https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-03, not mentioned in this draft ? Even if it does not fall within the 4ls experiments (not sure about the answer to this) then it might be useful to add a few lines explaining the status of DCTCP in this respect ? Something else entirely then are mechanisms like DCQCN, not specified by IETF, but relying generally on ECN markings in UDP transport, though not following neither the classical nor the l4s approach. Such mechanisms as is, whether they use ECT(0) or ECT(1), remain to be treated as alians (or plainly as not compliant with standards) at this time in stage. Correct ? BR, Karen From nobody Tue Dec 6 08:40:25 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440A6129A28; Tue, 6 Dec 2016 08:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=KHODv/6L; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=nqRB2z1U Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgGW6RomCdhE; Tue, 6 Dec 2016 08:40:21 -0800 (PST) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0964F129A5C; Tue, 6 Dec 2016 08:39:24 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=VzNTsqtQLTA/99F+cPc100Tmbobf9C5OG6Fgge8aYNtnc/a3d8mvDVvd nEQWt90+yUURJ60p9e/GJ1uxUkoNhyKLAl5os9SRGKxMRCcz/wnDmrNd6 E2v8ArElhLtG4yOvjsj94/wCYnCGxjfdejErcjV4Ujscre1L6K0P7lf2Q Q=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1481042365; x=1512578365; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sBsNwIEw9aLozrAjqGLTi5Hoys514LFnyDOv7ox1ctA=; b=KHODv/6LKDnCn2lQF0uF8achfI95+YqgfhrudtxjOKEbfqUo0azWFU2U a528fmgdQ4hU9z6lChubJHp+7c+Yv6TzbkS4TsM7l/76j61fJYLFfm3Fw SOWaS06piQxLywa3HfVANzCcJtb+VX+jbBfxDuzgJNhKgHvjENRBS6JDR A=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2016 10:39:23 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2016 22:39:22 +0600 Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uB6GdGJk016067 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Dec 2016 11:39:20 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com uB6GdGJk016067 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1481042361; bh=ePygJ55xssuDckrXYIkhFdg26D0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=nqRB2z1UNt38ihpgV4859wW9oREvB8QoTY20Y41l66EPtrft0HI2wJTsziElRujvJ VKfGtNr7s5DyL2ZxtLzwvu580Hz+KUNa52IPnb9UqkW39wSrQTkMrHLEkUGRwhzN+A 5Sz0uGKd+vPuyCla275d1NCCFE3ARrhIuCmGCy8Y= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com uB6GdGJk016067 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Tue, 6 Dec 2016 11:38:54 -0500 Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uB6Gd2oD004730 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 6 Dec 2016 11:39:03 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0266.001; Tue, 6 Dec 2016 11:39:02 -0500 To: Karen Elisabeth Egede Nielsen , "tsvwg@ietf.org" , "draft-black-tsvwg-ecn-experimentation@ietf.org" Thread-Topic: DCTCP and draft-black-tsvwg-ecn-experimentation ? Thread-Index: AdJO1ioNLUmk0y5KTGaYO1zuvkZf8gBBdCMw Date: Tue, 6 Dec 2016 16:39:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "tcpm@ietf.org" , "Black, David" Subject: Re: [tcpm] DCTCP and draft-black-tsvwg-ecn-experimentation ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 06 Dec 2016 16:40:24 -0000 SGkgS2FyZW4sDQoNCj4gV2h5IGlzIGRjdGNwLCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi10Y3BtLWRjdGNwLTAzLCBub3QgbWVudGlvbmVkIGluIHRoaXMgZHJhZnQgPw0K DQpTaG9ydGFnZSBvZiAiY29waW91cyBzcGFyZSB0aW1lIiA6LSkuDQoNCkknbSBoYXBweSBhZGQg c29tZSBtZW50aW9uIG9mIERDVENQIGluIGVkaXRpbmcgYWZ0ZXIgd2UgZGV0ZXJtaW5lIHdoZXRo ZXINCnRoZSBXRyBhZG9wdHMgdGhlIEVDTiBFeHBlcmltZW50YXRpb24gZHJhZnQuICBUaGUgbWVu dGlvbiBjb3VsZCBiZSB0aGF0IERDVENQDQppcyBhbm90aGVyIGV4YW1wbGUgb2YgdGVjaG5vbG9n eSB3aGVyZSBleHBlcmltZW50YXRpb24gaXMgZW5hYmxlZCAoZS5nLiwgYXMgdGhlDQpUQ1BNIERD VENQIGRyYWZ0IGlzIGludGVuZGVkIHRvIGJlIEluZm9ybWF0aW9uYWwsIGFuZCB3YXJucyBhYm91 dCAgcHJvYmxlbXMNCmluIGNvZXhpc3Rpbmcgd2l0aCBjb252ZW50aW9uYWwgVENQIGNvbmdlc3Rp b24gY29udHJvbCAtIHVzZSBvZiBFQ1QoMSkgYW5kIHNlcGFyYXRlDQpxdWV1ZXMgY291bGQgYmUg aW50ZXJlc3RpbmcpLg0KDQo+IFNvbWV0aGluZyBlbHNlIGVudGlyZWx5IHRoZW4gYXJlIG1lY2hh bmlzbXMgbGlrZSBEQ1FDTiwgbm90IHNwZWNpZmllZCBieQ0KPiBJRVRGLCBidXQgcmVseWluZyBn ZW5lcmFsbHkgb24gRUNOIG1hcmtpbmdzIGluIFVEUCB0cmFuc3BvcnQsDQo+IHRob3VnaCBub3Qg Zm9sbG93aW5nIG5laXRoZXIgdGhlIGNsYXNzaWNhbCBub3IgdGhlIGw0cyBhcHByb2FjaC4NCj4g U3VjaCBtZWNoYW5pc21zIGFzIGlzLCB3aGV0aGVyIHRoZXkgdXNlIEVDVCgwKSBvciBFQ1QoMSks IHJlbWFpbiB0byBiZQ0KPiB0cmVhdGVkIGFzIGFsaWVucyAob3IgcGxhaW5seSBhcyBub3QgY29t cGxpYW50IHdpdGggc3RhbmRhcmRzKSBhdCB0aGlzIHRpbWUNCj4gaW4gc3RhZ2UuIENvcnJlY3Qg Pw0KDQogSSB0aGluayBzby4gIFRvIHB1dCB0aGlzIGluIG90aGVyIHdvcmRzLCBpZiB0aGUgRENR Q04gcHJvcG9uZW50cyBhcmUgaW50ZXJlc3RlZA0KaW4gYW4gRXhwZXJpbWVudGFsIFJGQywgdGhl IEVDTiBleHBlcmltZW50YXRpb24gZHJhZnQncyBwcm9wb3NlZCBjaGFuZ2VzDQphcmUgbGlrZWx5 IHRvIGhlbHAgaW4gdGhhdCBlbmRlYXZvciwgYnV0IGZvciBub3csIHRoZXkgKGxpa2UgRENUQ1Ap IGhhdmUNCm5vbi1zdGFuZGFyZCBFQ04gdXNhZ2UuDQoNClRoYW5rcywgLS1EYXZpZA0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEthcmVuIEVsaXNhYmV0aCBFZ2VkZSBO aWVsc2VuIFttYWlsdG86a2FyZW4ubmllbHNlbkB0aWV0by5jb21dDQo+IFNlbnQ6IE1vbmRheSwg RGVjZW1iZXIgMDUsIDIwMTYgNDowMSBBTQ0KPiBUbzogdHN2d2dAaWV0Zi5vcmc7IGRyYWZ0LWJs YWNrLXRzdndnLWVjbi1leHBlcmltZW50YXRpb25AaWV0Zi5vcmc7IEJsYWNrLA0KPiBEYXZpZA0K PiBDYzogdGNwbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBEQ1RDUCBhbmQgZHJhZnQtYmxhY2stdHN2 d2ctZWNuLWV4cGVyaW1lbnRhdGlvbiA/DQo+IA0KPiBIaSwNCj4gDQo+IFRoaXMgdmVyeSBsaWtl bHkgaGFzIGJlZW4gZGlzY3Vzc2VkIGxlbmd0aCBhbmQgSSBqdXN0IG1pc3NlZCBpdCAoU29ycnkp Lg0KPiANCj4gV2h5IGlzIGRjdGNwLCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi10Y3BtLWRjdGNwLTAzLCBub3QNCj4gbWVudGlvbmVkIGluIHRoaXMgZHJhZnQgPw0KPiAN Cj4gRXZlbiBpZiBpdCBkb2VzIG5vdCBmYWxsIHdpdGhpbiB0aGUgNGxzIGV4cGVyaW1lbnRzIChu b3Qgc3VyZSBhYm91dCB0aGUNCj4gYW5zd2VyIHRvIHRoaXMpIHRoZW4gaXQgbWlnaHQgYmUgdXNl ZnVsIHRvIGFkZCBhIGZldyBsaW5lcyBleHBsYWluaW5nDQo+IHRoZSBzdGF0dXMgb2YgRENUQ1Ag aW4gdGhpcyByZXNwZWN0ID8NCj4gDQo+IFNvbWV0aGluZyBlbHNlIGVudGlyZWx5IHRoZW4gYXJl IG1lY2hhbmlzbXMgbGlrZSBEQ1FDTiwgbm90IHNwZWNpZmllZCBieQ0KPiBJRVRGLCBidXQgcmVs eWluZyBnZW5lcmFsbHkgb24gRUNOIG1hcmtpbmdzIGluIFVEUCB0cmFuc3BvcnQsDQo+IHRob3Vn aCBub3QgZm9sbG93aW5nIG5laXRoZXIgdGhlIGNsYXNzaWNhbCBub3IgdGhlIGw0cyBhcHByb2Fj aC4NCj4gU3VjaCBtZWNoYW5pc21zIGFzIGlzLCB3aGV0aGVyIHRoZXkgdXNlIEVDVCgwKSBvciBF Q1QoMSksIHJlbWFpbiB0byBiZQ0KPiB0cmVhdGVkIGFzIGFsaWFucyAob3IgcGxhaW5seSBhcyBu b3QgY29tcGxpYW50IHdpdGggc3RhbmRhcmRzKSBhdCB0aGlzIHRpbWUNCj4gaW4gc3RhZ2UuIENv cnJlY3QgPw0KPiANCj4gDQo+IEJSLCBLYXJlbg0K From nobody Wed Dec 7 06:46:21 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FA6129473 for ; Wed, 7 Dec 2016 06:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8IJUKGphc7U for ; Wed, 7 Dec 2016 06:46:18 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEE112947A for ; Wed, 7 Dec 2016 06:46:18 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cEdU7-0005Zq-Qz for tcpm@ietf.org; Wed, 07 Dec 2016 15:46:15 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cEdU7-0001Gj-Cj; Wed, 07 Dec 2016 15:46:15 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7812D0DE-EC15-4B19-8C03-6D5A052CA971@ifi.uio.no> Date: Wed, 7 Dec 2016 15:46:15 +0100 To: taps WG , tcpm IETF list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 4 sum rcpts/h 15 sum msgs/h 5 total rcpts 49703 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.643, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B9B3C4B5CE926AAEF5399371213B2A4C9E4C0206 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 11790 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [tcpm] Experimental TCP RFCs affecting the API? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 07 Dec 2016 14:46:20 -0000 Hi, As I'm working on an update of draft-ietf-taps-transports-usage to also = incorporate Experimental TCP RFCs, I wonder which of them had an impact = on the API - I mean any form of text describing how applications use the = protocol. Clearly, TFO is such a case (RFC 7413). Any others? Thanks in advance! Cheers, Michael From nobody Thu Dec 8 20:02:43 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 089D5129624; Thu, 8 Dec 2016 20:02:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148125616202.6971.8261886921811846243.idtracker@ietfa.amsl.com> Date: Thu, 08 Dec 2016 20:02:42 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 04:02:42 -0000 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 of the IETF. Title : Transmission Control Protocol Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-04.txt Pages : 94 Date : 2016-12-08 Abstract: This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793 and several other RFCs (TODO: list all actual RFCs when finished). RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 8 20:07:37 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A2D129611 for ; Thu, 8 Dec 2016 20:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QdxtfZch8_G for ; Thu, 8 Dec 2016 20:07:33 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E17F129582 for ; Thu, 8 Dec 2016 20:07:33 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id c47so5988916qtc.2 for ; Thu, 08 Dec 2016 20:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=InFKJfdDdqc2dxMykMni/lrKbEDTfmCTP02SaEt2c4U=; b=Xx+iW5S/gJ6xWP3bCYD+DbQ/Q069dLELHfmfvSbKl00pRFGZt/Z/sQoLBtTILk+Dv7 GGdCHCGp1TktCMrQPUuONPXmdrG5QSd4DJqS5lL9iWob+tn171u/kFGJbjY2M/jIQUz4 dQcvesPYRofCRBAUwpyoX8N+N6jlh9YjMrKGVt/H9J9H+hACG1hfQREhi7Mr2WhnJiJS svOTSdSVFHI59Txcq3encb0NGYy6QgGXqlcH+4lSb8da/Hb4rJhpu/aG4TIi1nhCO/aM P8+jKnR3BEWkauniTfcGj4Vnltwsc0ZUXSODI9g/Fo2Mj+Sdf8qh/zY44CdLYaGmX0I8 TY1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=InFKJfdDdqc2dxMykMni/lrKbEDTfmCTP02SaEt2c4U=; b=VdmKp+Sd8Gn9R2JSCJH0v2z8amoJKrf9jCNLJU+Z+0SQdLLuzFAalC8fRWyNyRtaQ5 Izyxba2v28e7TbHPj6GxJox4q6f9jxJu9qOJiWMKrIr5/paYQv8py4ObPIN/RjcU078R 5gle99ERiC+Dh5KLSR81TTAtYhu35bPICARyUS3x8iZsLWCeN+R9gRZWHaU64t4dZFwQ HhTXy5f9Q3DgPqWcm8OB4qxN0VBQqcctRfk1BPzcTh9V2Na32MlliCIoUQKt0j1GKQ+I mscih5vajRrHFa2aA39lyZZJ8kYvhI3Fn8RnBG2MuKyKoO0qNtIqTm9FIboZDFUoufsk FLng== X-Gm-Message-State: AKaTC034Qtw8G1EPJsLuAQ93v+o39KLfZZn18Ts4h6X8pNm39/N2OfoBJ2kBgvAAU4CSAA== X-Received: by 10.200.41.248 with SMTP id 53mr75860224qtt.3.1481256452625; Thu, 08 Dec 2016 20:07:32 -0800 (PST) Received: from [192.168.1.102] (user-12l31s2.cable.mindspring.com. [69.81.135.130]) by smtp.gmail.com with ESMTPSA id i190sm19014332qke.9.2016.12.08.20.07.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Dec 2016 20:07:32 -0800 (PST) To: tcpm@ietf.org References: <148125616202.6971.8261886921811846243.idtracker@ietfa.amsl.com> From: Wesley Eddy Message-ID: <04b70645-5a95-1bfe-db91-4261101f84f2@mti-systems.com> Date: Thu, 8 Dec 2016 23:07:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148125616202.6971.8261886921811846243.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 09 Dec 2016 04:07:35 -0000 The main progress in this revision is that I think all of the necessary RFC 1122 material is incorporated. There are a couple of items that the WG should provide feedback on, which I'll open separate threads for. On 12/8/2016 11:02 PM, internet-drafts@ietf.org wrote: > 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 of the IETF. > > Title : Transmission Control Protocol Specification > Author : Wesley M. Eddy > Filename : draft-ietf-tcpm-rfc793bis-04.txt > Pages : 94 > Date : 2016-12-08 > > Abstract: > This document specifies the Internet's Transmission Control Protocol > (TCP). TCP is an important transport layer protocol in the Internet > stack, and has continuously evolved over decades of use and growth of > the Internet. Over this time, a number of changes have been made to > TCP as it was specified in RFC 793, though these have only been > documented in a piecemeal fashion. This document collects and brings > those changes together with the protocol specification from RFC 793. > This document obsoletes RFC 793 and several other RFCs (TODO: list > all actual RFCs when finished). > > RFC EDITOR NOTE: If approved for publication as an RFC, this should > be marked additionally as "STD: 7" and replace RFC 793 in that role. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Dec 9 18:36:38 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06381295C9; Fri, 9 Dec 2016 18:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=gYgQfZon; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=UU/UlDIe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qtzz3h0cdLRk; Fri, 9 Dec 2016 18:36:32 -0800 (PST) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CF9128BA2; Fri, 9 Dec 2016 18:36:32 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=sIQWK4DOQn5+cKv8j58iCkjpBlXUmxid+lcQqy5VJq7DwFTCSEgE3+Dv 7CG3PtSAnr+quzyq1hSt5ggbfIIFW0yYFFJImP/ri+nMNLm0cY0+PQgoQ 92ZKFMcH1jAmiJYCZ4U9u4pUsG1DdTnOsnV0YihlDSW9IU0pJL5difieJ o=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1481337392; x=1512873392; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dd11OOoDZiRCnVGHQHT8CoUVieVrfTGIjuUtJzfnu5U=; b=gYgQfZone5rv1IukHabIWauxxZMCstlz0Cukfr+vUn1YPBEQmspKF1JS 2bLYqcgu1RVfluKEcx3PqTsnyfOl+H73dOyA/+sWWGwrRj3balGg3lffY QauC0YfK2ddYWQ4XNR45XsIFw0zRRQ9TlCtJK3QoGLTX8zScuKfkNCOex s=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Dec 2016 20:36:32 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Dec 2016 08:36:31 +0600 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uBA2aTm7004418 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 Dec 2016 21:36:30 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com uBA2aTm7004418 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1481337391; bh=TXHSqUgQ9VakDjlavdO3AULZ/Uo=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=UU/UlDIe3rbPqdTQnVoEoxucgYWZoG091aX06wMqRgv5HvcLCEeua2tS+quaTTbu3 K2ewdU9ojQnxiKB/UDoocvDjiXFcvD/2z8UdpFuNZWZi+XFsuuGUeWfQcnJVbpnI/7 tOGtceAyGoEuOoFXZm+r5CiwVlmwpG7ybHNJzb64= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com uBA2aTm7004418 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd56.lss.emc.com (RSA Interceptor); Fri, 9 Dec 2016 21:36:11 -0500 Received: from MXHUB306.corp.emc.com (MXHUB306.corp.emc.com [10.146.3.32]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uBA2a9J2021720 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 9 Dec 2016 21:36:11 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB306.corp.emc.com ([10.146.3.32]) with mapi id 14.03.0266.001; Fri, 9 Dec 2016 21:36:10 -0500 To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "tsvwg@ietf.org" , marcelo bagnulo braun , Bob Briscoe , "tcpm@ietf.org" Thread-Topic: [tsvwg] Review of draft-bagnulo-tsvwg-generalized-ecn-01 Thread-Index: AQHSUj0tiIbTpq4p30CWtzhFnVxA2KEAduuA Date: Sat, 10 Dec 2016 02:36:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tcpm] [tsvwg] Review of draft-bagnulo-tsvwg-generalized-ecn-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 10 Dec 2016 02:36:35 -0000 SGkgTWlyamENClsrdGNwbSBXR10NCg0KVGhlIGRhdGF0cmFja2VyIHJlY29yZHMgZHJhZnQtYmFn bnVsby10c3Z3Zy1nZW5lcmFsaXplZC1lY24gYXMgcmVwbGFjZWQNCmJ5IGRyYWZ0LWJhZ251bG8t dGNwbS1nZW5lcmFsaXplZC1lY24gLSB0aGUgbGF0dGVyIGRyYWZ0IGlzIGV4cGVjdGVkIHRvIG1v dmUNCnRoaXMgd29yayBmb3J3YXJkIGluIHRoZSB0Y3BtIFdHLg0KDQpUaGFua3MsIC0tRGF2aWQN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRz dndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaXJqYSBLw7xobGV3aW5kDQo+IFNl bnQ6IEZyaWRheSwgRGVjZW1iZXIgMDksIDIwMTYgMTE6NTYgQU0NCj4gVG86IHRzdndnQGlldGYu b3JnOyBtYXJjZWxvIGJhZ251bG8gYnJhdW47IEJvYiBCcmlzY29lDQo+IFN1YmplY3Q6IFt0c3Z3 Z10gUmV2aWV3IG9mIGRyYWZ0LWJhZ251bG8tdHN2d2ctZ2VuZXJhbGl6ZWQtZWNuLTAxDQo+IA0K PiBIaSBhbGwsDQo+IA0KPiBmaW5kIGJlbG93IHJldmlldyBjb21tZW50cyBmb3IgZHJhZnQtYmFn bnVsby10c3Z3Zy1nZW5lcmFsaXplZC1lY24tMDEgYXMgYW4NCj4gaW5kaXZpZHVhbCBjb250cmli dXRvciAoY2xhc3NpZmllZCBpbiBkaWZmZXJlbnQgY2F0ZWdvcmllcyk6DQo+IA0KPiBDb21tZW50 cyBvbiBBcmd1bWVudGF0aW9uOg0KPiBQbGVhc2Ugbm90ZSB0aGF0IEkgZG8gc3VwcG9ydCB0aGUg ZG9jdW1lbnQgYW5kIG1hcmtpbmcgb2YgY29udHJvbCBwYWNrZXRzDQo+IGdpdmVuIHRoZSBvdGhl cndpc2UgbmVnYXRpdmUgaW1wYWN0IG9uIHBlcmZvcm1hbmNlIGVzcGVjaWFsbHkgaWYgd2Ugd291 bGQgYWltDQo+IGZvciBhbiBhbGwtRUNOIEludGVybmV0IGluIGZ1dHVyZS4gVGhlc2UgYWRkaXRp b25hbCBhcmd1bWVudHMgYXJlIHByb3ZpZGVkIHRvDQo+IGJlIGFkZGVkIGZvciBkaXNjdXNzaW9u IGluIHRoZSBkb2MgZm9yIGNvbXBsZXRlbmVzcy4NCj4gDQo+IFNlY3Rpb24gMiAodGhlIHJlbGlh YmlsaXR5IGFyZ3VtZW50KQ0KPiAtLS0tLQ0KPiBFdmVuIHRob3VnaCB0aGlzIGlzIG5vdCBzcGVs bGVkIG91dCBsaWtlIHRoaXMgaW4gUkZDMzE2OCwgSSB3b3VsZCBsaWtlIHRvDQo+IGV4dGVuZCB0 aGUgYXJndW1lbnQgaGVyZSBhIGxpdHRsZToNCj4gDQo+IDEpIEknbSBva2F5IHRvIHNheSB0aGF0 IGlmIGxvc3MgaXMgbm90IGRldGVjdGVkIHJlbGlhYmx5IGZvciB0aGlzIGtpbmQgb2YNCj4gcGFj a2V0LCB5b3UgbWF5IGFzIHdlbGwgbm90IHJlcXVpcmUgdG8gZGV0ZWN0IENFIG1hcmtzLiBIb3dl dmVyLCByZWNlaXZpbmcgYQ0KPiBDRSBtYXJrLCBkZXRlY3RpbmcgaXQsIGFuZCBqdXN0IG5vIHJl YWN0aW5nIHRvIGl0LCBpcyBhIGRpZmZlcmVudCB0aGluZy4gSQ0KPiBjbGVhcmx5IHNlZSB0aGUg dHJhZGUtb2ZmIGhlcmUgZm9yIFRDUCBidXQgSSBkb24ndCB3YW50IHRoaXMgdG8gYmUgYQ0KPiBz dGF0ZW1lbnQgd2hlcmUgb3RoZXIgcHJvdG9jb2xzIHNheSBpdCdzIG9rYXkgdG8gbm90IHJlYWN0 IHRvIENFIGJlY2F1c2UgVENQDQo+IGlzIGRvaW5nIHRoaXMgYXMgd2VsbCBmb3IgQUNLcy4gTm90 ZSBzdXJlIHlldCBob3cgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGFuZA0KPiBJJ20gbm90IGNvbWZv cnRhYmxlIHdpdGggcmVjb21tZW5kaW5nIHRvIG1hcmsgY29udHJvbCBwYWNrZXRzIHdoaXRlb3V0 IGF0IHRoZQ0KPiBzYW1lIHRpbWUgZGVmaW5pbmcgc3RhbmRhcmQgbWVjaGFuaXNtcyBmb3IgVENQ IGhvdyB0byByZWFjdCB0byBpdC4NCj4gDQo+IDIpIElmIGEgcGFja2V0IGlzIGRyb3BwZWQsIGl0 J3MgZ29uZSBhbmQgY2Fubm90IGZ1cnRoZXIgY29uZ2VzdCB0aGUgbGluay4NCj4gVGhpcyBpcyB0 aGUgbWVjaGFuaXNtIG9mIHRoZSBuZXR3b3JrIHRvIHByb3RlY3QgaXRzZWxmLiBIb3dldmVyLCBp ZiB5b3UgbWFyaw0KPiBhIHBhY2tldCBhcyBFQ04gY2FwYWJsZSwgaXQga2VlcHMgc2l0dGluZyBp biB0aGUgcXVldWUgYW5kIGFub3RoZXIgbm9uLUVDVA0KPiBwYWNrZXQgbWlnaHQgYmUgZHJvcHBl ZCBpbnN0ZWFkLiBUaGlzIGlzIGEgd2VsbC1rbm93biBnZW5lcmFsIHByb2JsZW0gb2YgRUNOLA0K PiBob3dldmVyLCBpZiB0aGUgRUNULW1hcmtlZCBpcyB0aGVuIGFsc28gdW5yZXNwb25zaXZlIHRv IENFIG1hcmtpbmcsIHRoaXMNCj4gbWlnaHQgbWFrZSB0aGUgc2l0dWF0aW9uIHdvcnNlLg0KPiAN Cj4gU2VjdGlvbiAzIChUQ1AgU1lOcyk6IEFyZ3VtZW50IDMgKERvUyBhdHRhY2tzKQ0KPiAtLS0N Cj4gSGF2aW5nIEVDVCBtYXJrZWQgYXR0YWNrIHRyYWZmaWMgbWFrZXMgaXQgd29yc2UgYmVjYXVz ZSB0aGlzIG1pZ2h0IGxlYWRzIHRvIGENCj4gZXZlbiBoaWdoZXIgbG9zcyByYXRlIGZvciBub24t RUNUIHRyYWZmaWMgd2hpbGUgRUNUIHBhY2tldHMga2VlcCBzaXR0aW5nIGluDQo+IHRoZSBxdWV1 ZS4NCj4gDQo+IFNlY3Rpb24gNCAoUHVyZSBBQ0tzKTogc2Vjb25kIGFyZ3VtZW50DQo+IC0tLQ0K PiBUaGUgZGlmZmVyZW5jZSBpdCB0aGF0IGFuIENFIG1hcmtpbmcgb24gYSBBQ0sgY2FuIGJlIGRl dGVjdGVkIGJ5IHRoZSByZWNlaXZlcg0KPiAoZXZlbiB0aG91Z2ggaXQgbm90IGZ1bGx5IGNsZWFy IGhvdyB0byByZWFjdCB0byBpdCBvciBqdXN0IGlnbm9yZQ0KPiBpdC4uLmhvcGVmdWxseSBub3Qp IGJ1dCB5b3UgY2FuJ3QgZGV0ZWN0IEFDSyBsb3NzIGJlY2F1c2UgeW91IGRvbid0IGtub3cgaG93 DQo+IG1hbnkgQUNLcyBoYXZlIGJlZW4gc2VuZCBpbml0aWFsbHkuIEkgZG9uJ3QgdGhpbmsgdGhp cyBpcyBhbiBpc3N1ZSBidXQgeW91IHNheToNCj4gIklmIHRoZSBwdXJlIEFDSyBjYXJyeWluZyB0 aGUNCj4gICAgIEVDVCBhbmQgdGhlIENFIGJpdHMgc2V0IGlzIGxhdGVyIGRyb3BwZWQgYnkgdGhl IG5ldHdvcmssIGl0IHdpbGwgYmUNCj4gICAgIGVzc2VudGlhbGx5IGZhbGxpbmcgYmFjayB0byB0 aGUgdXNlIG9mIGRyb3AgYXMgY29uZ2VzdGlvbiBzaWduYWwuIg0KPiB3aGljaCBzZWVtcyB3cm9u Zy4NCj4gDQo+IEhvd2V2ZXIsIHRoaXMgaXMgb24gdGhlIG90aGVyIGhhZCBhIHBybyBhcmd1bWVu dCBiZWNhdXNlIHdoaWxlIGxvc3MgY2Fubm90IGJlDQo+IGRldGVjdGVkIGF0IGFsbCwgdGhlcmUg aXMgYXQgbGVhc3QgYSBjaGFuY2UgdG8gZGV0ZWN0IENFIG1hcmtlZCBBQ0tzLg0KPiANCj4gDQo+ IENvbW1lbnRzIG9uIHRoZSBtb3JlIGVkaXRvcmlhbCBzaWRlOg0KPiAxKSBPbmUgbW9yZSBhcmd1 bWVudCB0byBtYWtlIGluIHRoZSBpbnRybywgZXNwZWNpYWxseSBhcyB5b3UgbWVudGlvbiBsNHMs IGlzDQo+IHRoYXQgaW4gdGhpcyBjYXNlLCBoYXZpbmcgdGhlIHBhY2tldHMgbm90IG1hcmtlZCBh cyBFQ1QgY291bGQgZXZlbiBsZWFkIHRvDQo+IGRpZmZlcmVudGlhbCBuZXR3b3JrIHRyZWF0bWVu dCwgd2hpY2ggbWlnaHQgaW5mbHVlbmNlIHBlcmZvcm1hbmNlIGV2ZW4gbW9yZS4NCj4gMikgSSB3 b3VsZCByZWNvbW1lbmQgdG8gbW92ZSB0aGUgZGlzY3Vzc2lvbiBvbiBkYXRhIGNlbnRlcnMgaW4g c2VjdGlvbiAzIHRvIGENCj4gc2VwYXJhdGUgc2VjdGlvbiBhdCB0aGUgZW5kIG9mIHRoZSBkb2Mg YmVjYXVzZSB0aGF0J3MgdGhlIG9ubHkgdGltZSB5b3UgdGFsaw0KPiBhYm91dCBkYXRhIGNlbnRl cnMuDQo+IDMpIEluIHNlY3Rpb24gMyByZWdhcmRpbmcgW2Vjbi1wYW1dLCB5b3UgYXJlIGFzc3Vt aW5nIHRoYXQgdGhlIHBhY2tldHMgd2VyZQ0KPiBkcm9wcGVkIHRoZSB0aGUgZW5kcG9pbnQvcmVj ZWl2ZXIsIGhvd2V2ZXIsIHRoZXJlIGNvdWxkIGFsc28gYmUgbWlkZGxlYm94ZXMNCj4gZG9pbmcg dGhpcy4gSSBkb24ndCB0aGluayB3ZSBsb29rZWQgYXQgUlNUIGJ1dCB0aGF0IHdvdWxkIGJlIGlu dGVyZXN0aW5nLg0KPiAzKSBzZWN0aW9uIDMgIlRoZSByZXNwb25kZXIgbWF5IGRyb3AgdGhlIFNZ TiAoZWl0aGVyIHNpbGVudGx5IG9yIGJ5IHNlbmRpbmcgYQ0KPiBSU1QpIG9yIG1heSByZXBseSB3 aXRoIGEgbm9uIEVDVCBtYXJrZWQgU1lOL0FDSy4gIElmIGl0IGlzIHRoZSBsYXR0ZXIsDQo+ICAg ICB0aGVuIHRoaXMgaXMgYSBub24taXNzdWUiIC0+IEkgd291bGRuJ3QgY2FsbCBpdCBhIG5vbi1p c3N1ZSBiZWNhdXNlIGF0DQo+IGxlYXN0IHRoZSBjb25nZXN0aW9uIHNpZ25hbCBnb3QgbG9zdC4N Cj4gNCkgSSB0aGluayB5b3UgbmVlZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4NCj4gDQo+IE5p dDoNCj4gc2VjdGlvbiAzLCAxLiBzZW50ZW5jZTogcy9XZSBuZXh0IGRlc2NyaWJlIGhlIGFyZ3Vt ZW50cyBleGhpYml0ZWQvV2UgbmV4dA0KPiBkZXNjcmliZSB0aGUgYXJndW1lbnRzIGV4aGliaXRl ZC8NCj4gDQo+IEFuZCB0aGUgaW1wb3J0YW50IGJpdCBhdCB0aGUgZW5kOg0KPiANCj4gT25lIGhp Z2gtbGV2ZWwgY29tbWVudDoNCj4gVGhpcyBkb2N1bWVudCBpcyBhIGdvb2QgcmVhZCwgaG93ZXZl ciwgaXQgaXMgbm90IGNsZWFyIHdoYXQgYW4gaW1wbGVtZW50b3INCj4gc2hvdWxkIGFjdHVhbGx5 IGRvIGlmIGhlL3NoZSB3YW50IHRvIGVuYWJsZSBFQ04gb24gY29udHJvbCBwYWNrZXRzLiBJbnN0 ZWFkDQo+IG9mIG9ubHkgaGF2ZSBhbiBpbmZvcm1hdGlvbmFsIGRpc2N1c3Npb24sIEkgd291bGQg cmF0aGVyIHNlZSBhbiBleHBlcmltZW50DQo+IHdoZXJlIHlvdSBwcm9wb3NlZCBjb25jcmV0ZSB0 aGluZ3MvbWFjaGFuaW1zIHRoYXQgc2hvdWxkL211c3QgYmUgZG9uZQ0KPiB3aGVuDQo+IEVDTiBp cyB1c2VkIG9uIGNvbnRyb2wgcGFja2V0cy4NCj4gDQo+IEZ1cnRoZXIsIGF0IHRoZSBlbmQgb2Yg c2VjdGlvbiAzLCB5b3Ugbm90IG9ubHkgZGlzY3VzcyBwb3RlbnRpYWwNCj4gZmFsbGJhY2tzL3Nh ZmV0eSBndWFyZHMgb24gaG93IHRvIHVzZSBFQ04gb24gY29udHJvbCBwYWNrZXRzIGJ1dCB5b3Ug YWN0dWFsbHkNCj4gcHJvcG9zZSBjaGFuZ2VzIHRvIHRoZSBFQ04gcHJvdG9jb2wgYXMgc3BlY2lm aWVkIGluIFJGQzMxNjguIFRoaXMgcGFydCByZWFsbHkNCj4gZG9lc24ndCBzZWVtIHRvIGJlIGFw cHJvcHJpYXRlIGZvciBhbiBpbmZvcm1hdGlvbmFsIGRvYyBhbmQgYWxzbyB3b3VsZCBuZWVkDQo+ IGZ1cnRoZXIgZGlzY3Vzc2lvbiBhcyBhbiBleHBlcmltZW50LiBBcyB5b3UgaGF2ZSB0byByZWx5 IGZvciB0aGVzZSBtZWNoYW5pc20NCj4gb24gY2hhbmdlcyBvbiBib3RoIHRoZSBzZW5kZXIgYW5k IHJlY2VpdmVyIHNpZGUsIEkgd291bGQgc2ltcGx5IGp1c3QgdXNlDQo+IEFjY0VDTiBpbnN0ZWFk LiBUaGlzIHdvdWxkIG1lYW4gdGhlcmUgc2hvdWxkIG1heWJlIGJlIGEgcmVjb21tZW5kYXRpb24g dGhhdA0KPiBpZiB0aGUgaW5pdGlhdG9yIHdhbnRzIHRvIHNldCBFQ1Qgb24gY29udHJvbCBwYWNr ZXRzIGluY2wuIHRoZSBTWU4gaXQNCj4gc2hvdWxkL211c3QgYWxzbyB0cnkgdG8gbmVnb3RpYXRl IEFjY0VDTiBpbiB0aGUgaGFuZHNoYWtlICh3aGljaCBhbnl3YXkgYXMgYW4NCj4gaW1wbGljdCBm YWxsYmFjayB0byBjYWxzc2ljIEVDTiBpZiBBY2NFQ04gaXMgbm90IHN1cHBvcnRlZCBieSB0aGUg cmVjZWl2ZXIpLg0KPiANCj4gVGhhbmtzIGZvciB3cml0aW5nIHRoZSBkb2MuIEkgdGhpbmsgdGhp cyBpcyBhIHZlcnkgZ29vZCBzdGFydGluZyBwb2ludCENCj4gDQo+IE1pcmphDQoNCg== From nobody Sat Dec 10 01:39:33 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805B412007C; Sat, 10 Dec 2016 01:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afpzenX74kgJ; Sat, 10 Dec 2016 01:39:25 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240411295BE; Sat, 10 Dec 2016 01:39:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C74C6D9304; Sat, 10 Dec 2016 10:39:22 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WFy72RyH8mBy; Sat, 10 Dec 2016 10:39:22 +0100 (MET) Received: from [192.168.178.33] (p5DEC28B1.dip0.t-ipconnect.de [93.236.40.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 736C6D9303; Sat, 10 Dec 2016 10:39:22 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Sat, 10 Dec 2016 10:39:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Black, David" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "tcpm@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tcpm] [tsvwg] Review of draft-bagnulo-tsvwg-generalized-ecn-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 10 Dec 2016 09:39:27 -0000 Hi David, yes, I already realized that I reviewed the wrong doc. The right review = on the tcpm list will follow soon. I set the =E2=80=9Areplaces=E2=80=98 = relation yesterday after noticing.=20 @all: Please make sure you set this correctly if you upload a draft with = a new name! Mirja > Am 10.12.2016 um 03:36 schrieb Black, David : >=20 > Hi Mirja > [+tcpm WG] >=20 > The datatracker records draft-bagnulo-tsvwg-generalized-ecn as = replaced > by draft-bagnulo-tcpm-generalized-ecn - the latter draft is expected = to move > this work forward in the tcpm WG. >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Mirja = K=C3=BChlewind >> Sent: Friday, December 09, 2016 11:56 AM >> To: tsvwg@ietf.org; marcelo bagnulo braun; Bob Briscoe >> Subject: [tsvwg] Review of draft-bagnulo-tsvwg-generalized-ecn-01 >>=20 >> Hi all, >>=20 >> find below review comments for draft-bagnulo-tsvwg-generalized-ecn-01 = as an >> individual contributor (classified in different categories): >>=20 >> Comments on Argumentation: >> Please note that I do support the document and marking of control = packets >> given the otherwise negative impact on performance especially if we = would aim >> for an all-ECN Internet in future. These additional arguments are = provided to >> be added for discussion in the doc for completeness. >>=20 >> Section 2 (the reliability argument) >> ----- >> Even though this is not spelled out like this in RFC3168, I would = like to >> extend the argument here a little: >>=20 >> 1) I'm okay to say that if loss is not detected reliably for this = kind of >> packet, you may as well not require to detect CE marks. However, = receiving a >> CE mark, detecting it, and just no reacting to it, is a different = thing. I >> clearly see the trade-off here for TCP but I don't want this to be a >> statement where other protocols say it's okay to not react to CE = because TCP >> is doing this as well for ACKs. Note sure yet how to solve this = problem and >> I'm not comfortable with recommending to mark control packets = whiteout at the >> same time defining standard mechanisms for TCP how to react to it. >>=20 >> 2) If a packet is dropped, it's gone and cannot further congest the = link. >> This is the mechanism of the network to protect itself. However, if = you mark >> a packet as ECN capable, it keeps sitting in the queue and another = non-ECT >> packet might be dropped instead. This is a well-known general problem = of ECN, >> however, if the ECT-marked is then also unresponsive to CE marking, = this >> might make the situation worse. >>=20 >> Section 3 (TCP SYNs): Argument 3 (DoS attacks) >> --- >> Having ECT marked attack traffic makes it worse because this might = leads to a >> even higher loss rate for non-ECT traffic while ECT packets keep = sitting in >> the queue. >>=20 >> Section 4 (Pure ACKs): second argument >> --- >> The difference it that an CE marking on a ACK can be detected by the = receiver >> (even though it not fully clear how to react to it or just ignore >> it...hopefully not) but you can't detect ACK loss because you don't = know how >> many ACKs have been send initially. I don't think this is an issue = but you say: >> "If the pure ACK carrying the >> ECT and the CE bits set is later dropped by the network, it will = be >> essentially falling back to the use of drop as congestion signal." >> which seems wrong. >>=20 >> However, this is on the other had a pro argument because while loss = cannot be >> detected at all, there is at least a chance to detect CE marked ACKs. >>=20 >>=20 >> Comments on the more editorial side: >> 1) One more argument to make in the intro, especially as you mention = l4s, is >> that in this case, having the packets not marked as ECT could even = lead to >> differential network treatment, which might influence performance = even more. >> 2) I would recommend to move the discussion on data centers in = section 3 to a >> separate section at the end of the doc because that's the only time = you talk >> about data centers. >> 3) In section 3 regarding [ecn-pam], you are assuming that the = packets were >> dropped the the endpoint/receiver, however, there could also be = middleboxes >> doing this. I don't think we looked at RST but that would be = interesting. >> 3) section 3 "The responder may drop the SYN (either silently or by = sending a >> RST) or may reply with a non ECT marked SYN/ACK. If it is the = latter, >> then this is a non-issue" -> I wouldn't call it a non-issue = because at >> least the congestion signal got lost. >> 4) I think you need security considerations. >>=20 >> Nit: >> section 3, 1. sentence: s/We next describe he arguments exhibited/We = next >> describe the arguments exhibited/ >>=20 >> And the important bit at the end: >>=20 >> One high-level comment: >> This document is a good read, however, it is not clear what an = implementor >> should actually do if he/she want to enable ECN on control packets. = Instead >> of only have an informational discussion, I would rather see an = experiment >> where you proposed concrete things/machanims that should/must be done >> when >> ECN is used on control packets. >>=20 >> Further, at the end of section 3, you not only discuss potential >> fallbacks/safety guards on how to use ECN on control packets but you = actually >> propose changes to the ECN protocol as specified in RFC3168. This = part really >> doesn't seem to be appropriate for an informational doc and also = would need >> further discussion as an experiment. As you have to rely for these = mechanism >> on changes on both the sender and receiver side, I would simply just = use >> AccECN instead. This would mean there should maybe be a = recommendation that >> if the initiator wants to set ECT on control packets incl. the SYN it >> should/must also try to negotiate AccECN in the handshake (which = anyway as an >> implict fallback to calssic ECN if AccECN is not supported by the = receiver). >>=20 >> Thanks for writing the doc. I think this is a very good starting = point! >>=20 >> Mirja >=20 From nobody Mon Dec 12 12:04:13 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1AF1294C7 for ; Mon, 12 Dec 2016 12:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTX0xJ-LC_jr for ; Mon, 12 Dec 2016 12:04:10 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A53B12978B for ; Mon, 12 Dec 2016 12:04:10 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id h30so190178326iod.2 for ; Mon, 12 Dec 2016 12:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=pfEmKb7QkttJjFvmMdq+yZnGfWmi2U4TsJy64x2f114=; b=Z7HGe0eH/N9GwSQ6hPYHU5S31Ekg6KimrlIve6NjULHBzTIIz4v3CnPOwNo2YtQE6M qRrSRDJ1+aiU/z+IkJidPnLa6Ikh+Vmo0gdM58GnW4OCekjbPZ7zkLPuCp5x2/o7AW9C VO3fqc+uKDpe4wJmrQDzftD8RScj7LkPnR+DcDrh3Zt3auRCOXIobH/3Vv+A01NlyjHB Bl6KGUlSQEwNR4UHqAG3YAFbkffYrToIfx/06eejG57oODmScGYF0daT8K9im+g2PSXo 5qdgngvEGFvcVEV9fYmdDkXNz1XVqLTyykgNl6PsQh+jVhyNnLDx/XpTByOpxV8AWs30 XiBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=pfEmKb7QkttJjFvmMdq+yZnGfWmi2U4TsJy64x2f114=; b=Wvsl/q6FBT6dBXfGvlJfTiyFQ22izGmThGRdP6lfyDAbhDG2MF+FJP5VffbK6IW72q ki56XdgpiWJKzK/Ehz2Szt/bKfB7WjN31D5CMYyTHaV6cNHfJBhsMMHW/7YkAETW2MWD ik5sO3D5y1AgMtzllvKz9Vdvbxs8hciSe/LwE2fj4ZDUpETapZXWEJhxprm/Jnna4ow7 e7xKAEesoMVQfSTDwT1q9k/YVI2myV1+JMS+oQyeRhkisGCiYAqXPqzsRsbDv9aAwXEz IOmFmo1hFVhzrYQXeSw6E93jlKeMKJYHPDxePvIBzJ5+GPAmP1HhOrV0x80K0FKnNgaq 1+3Q== X-Gm-Message-State: AKaTC00H0HCyjw7q/9HvPt5KQO7z1YYlfylOvR2qkAZX+RZuPGjW9y5sFl6A1U5hYF7gFA== X-Received: by 10.107.134.83 with SMTP id i80mr26917956iod.151.1481573048390; Mon, 12 Dec 2016 12:04:08 -0800 (PST) Received: from [192.168.1.104] (cpe-76-188-215-129.neo.res.rr.com. [76.188.215.129]) by smtp.gmail.com with ESMTPSA id b81sm20015105iob.31.2016.12.12.12.04.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Dec 2016 12:04:07 -0800 (PST) To: tcpm@ietf.org From: Wesley Eddy Message-ID: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> Date: Mon, 12 Dec 2016 15:04:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] 793bis: requirement on RTO computation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 12 Dec 2016 20:04:12 -0000 This is a thread to check group consensus on how to discuss RTT estimation and RTO computation in RFC 793bis. RFC 793 originally had some material on this, described as "An Example Retransmission Timeout Procedure", but that is replaced by several later documents. - RFC 1122 adds mention of Karn's algorithm plus exponential backoff of the RTO, and more strongly adds requirements ("MUST") for these, rather than just being an "example". - RFC 2988 and then 6298 expanded on RTT and RTO computation, and 6298 currently updates 1122 in this regard. I think 6298 is "not too long" and has clear requirements. I think 793bis should simply reference 6298 as the requirement for computation of the RTO, rather than trying to actually discuss this as a self-contained topic in 793bis. I think that would be duplicative, unnecessary, and confusing. Do people agree with this? For reference, the current 793bis text is below. The first paragraph is direct from 793, the fourth from 1122, and the text in-between is attempting to say what I described above: 3.8.1. Retransmission Timeout Because of the variability of the networks that compose an internetwork system and the wide range of uses of TCP connections the retransmission timeout (RTO) must be dynamically determined. The RTO MUST be computed according to the algorithm in [7], including Karn's algorithm for taking RTT samples. RFC 793 contains an early example procedure for computing the RTO. This was then replaced by the algorithm described in RFC 1122, and subsequently updated in RFC 2988, and then again in RFC 6298. If a retransmitted packet is identical to the original packet (which implies not only that the data boundaries have not changed, but also that the window and acknowledgment fields of the header have not changed), then the same IP Identification field MAY be used (see Section 3.2.1.5 of RFC 1122). From nobody Mon Dec 12 12:14:34 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31A4129471 for ; Mon, 12 Dec 2016 12:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4rWOmmGEdHT for ; Mon, 12 Dec 2016 12:14:31 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D064912940F for ; Mon, 12 Dec 2016 12:14:30 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 20so92416587uak.0 for ; Mon, 12 Dec 2016 12:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lhqN5VbazMIng8Uh9YaZb6aqMbsyVH4WmByVrTubJ+M=; b=KUOB5BcrW9kGtHwx0AkJuhd/zGOOYjn/heXGYHiRxdBHe4TOCCefwslp+6kRxeeIIg lNwE3l/7ZLsiWwhJFUV+RcGm6RsZLa8o47nPAE6NJazAaM3B1ljYRMrOfzj50vYumZrl fkHsbodYLhsDuemb2dFa2JH1cj9X/JkKbQ936tjERJSUJkkFgTxiYzodg9S+q+V4Z5ZP Isx3v7R5T6HGR2Uy4UM7P7J/Cu9ZDGOE4C6SWMtSEg8/4IJDq4pNpssYOmm22B/Cwz81 v2hnVIrBDcwtD43uM3mTA8RKDlzWh2DO3tjWn6L99coqnS0+OPEZWZ74RnG6+HS8b86X MOOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lhqN5VbazMIng8Uh9YaZb6aqMbsyVH4WmByVrTubJ+M=; b=RGrkiYuObS/ib9YftL0UL6Un+NpIQsqoFNfS1gqivNd6kNb0P/nm8CsPrr9cQjmveb XJog0XgkjTo9MP89ApIH48brQnHaQnuFtbbXz4BBL0lccOuuGyPnPQBsvHtk7M9mh3Gj GCdYqO6Dvnc19s1b6+AJ8jdEmuC8JkAlg01RE/IrOXyGPp/o/L29yyVLVA/zfdNlpy4a 0Bfdf6GbAXlJPj14UsMp+6Au5mY0aRHS+FCRp/S6Q9KSgJQABbTzd1Ihb7ZcAtWETVuo tExdDVY+iTeNYj8YrscPpEsa/BG4PuCFSdN0F6wRrDcylmC4CemxolJrQFFndVQ76H1D fHnA== X-Gm-Message-State: AKaTC01erry7sSobp7W2n39Rn9JdXOWOsM0BwX04X7oJEPlyS3WtURCz1kgclocSQBOcleN7TrJMBXJ/Tm65MHDP X-Received: by 10.159.48.222 with SMTP id k30mr77177549uab.2.1481573669819; Mon, 12 Dec 2016 12:14:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Mon, 12 Dec 2016 12:14:29 -0800 (PST) In-Reply-To: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> References: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> From: Jana Iyengar Date: Mon, 12 Dec 2016 12:14:29 -0800 Message-ID: To: Wesley Eddy Content-Type: multipart/alternative; boundary=f403045dd8f04cac8605437bc04f Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] 793bis: requirement on RTO computation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 12 Dec 2016 20:14:33 -0000 --f403045dd8f04cac8605437bc04f Content-Type: text/plain; charset=UTF-8 On Mon, Dec 12, 2016 at 12:04 PM, Wesley Eddy wrote: > This is a thread to check group consensus on how to discuss RTT estimation > and RTO computation in RFC 793bis. > > RFC 793 originally had some material on this, described as "An Example > Retransmission Timeout Procedure", but that is replaced by several later > documents. > - RFC 1122 adds mention of Karn's algorithm plus exponential backoff of > the RTO, and more strongly adds requirements ("MUST") for these, rather > than just being an "example". > - RFC 2988 and then 6298 expanded on RTT and RTO computation, and 6298 > currently updates 1122 in this regard. > > I think 6298 is "not too long" and has clear requirements. I think 793bis > should simply reference 6298 as the requirement for computation of the RTO, > rather than trying to actually discuss this as a self-contained topic in > 793bis. I think that would be duplicative, unnecessary, and confusing. > > Do people agree with this? > +1. Nobody refers to 793 for RTT/RTO computation anyways. - jana > For reference, the current 793bis text is below. The first paragraph is > direct from 793, the fourth from 1122, and the text in-between is > attempting to say what I described above: > > 3.8.1. Retransmission Timeout > > Because of the variability of the networks that compose an > internetwork system and the wide range of uses of TCP connections the > retransmission timeout (RTO) must be dynamically determined. > > The RTO MUST be computed according to the algorithm in [7], including > Karn's algorithm for taking RTT samples. > > RFC 793 contains an early example procedure for computing the RTO. > This was then replaced by the algorithm described in RFC 1122, and > subsequently updated in RFC 2988, and then again in RFC 6298. > > If a retransmitted packet is identical to the original packet (which > implies not only that the data boundaries have not changed, but also > that the window and acknowledgment fields of the header have not > changed), then the same IP Identification field MAY be used (see > Section 3.2.1.5 of RFC 1122). > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --f403045dd8f04cac8605437bc04f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 12, 2016 at 12:04 PM, Wesley Eddy <wes@mti-systems.com> wrote:
This is a thread to = check group consensus on how to discuss RTT estimation and RTO computation = in RFC 793bis.

RFC 793 originally had some material on this, described as "An Example= Retransmission Timeout Procedure", but that is replaced by several la= ter documents.
- RFC 1122 adds mention of Karn's algorithm plus exponential backoff of= the RTO, and more strongly adds requirements ("MUST") for these,= rather than just being an "example".
-=C2=A0 RFC 2988 and then 6298 expanded on RTT and RTO computation, and 629= 8 currently updates 1122 in this regard.

I think 6298 is "not too long" and has clear requirements.=C2=A0 = I think 793bis should simply reference 6298 as the requirement for computat= ion of the RTO, rather than trying to actually discuss this as a self-conta= ined topic in 793bis.=C2=A0 I think that would be duplicative, unnecessary,= and confusing.

Do people agree with this?

+1. Nobody r= efers to 793 for RTT/RTO computation anyways.

- ja= na
=C2=A0
For reference, the current 793bis text is below.=C2=A0 The first paragraph = is direct from 793, the fourth from 1122, and the text in-between is attemp= ting to say what I described above:

3.8.1.=C2=A0 Retransmission Timeout

=C2=A0 =C2=A0Because of the variability of the networks that compose an
=C2=A0 =C2=A0internetwork system and the wide range of uses of TCP connecti= ons the
=C2=A0 =C2=A0retransmission timeout (RTO) must be dynamically determined.
=C2=A0 =C2=A0The RTO MUST be computed according to the algorithm in [7], in= cluding
=C2=A0 =C2=A0Karn's algorithm for taking RTT samples.

=C2=A0 =C2=A0RFC 793 contains an early example procedure for computing the = RTO.
=C2=A0 =C2=A0This was then replaced by the algorithm described in RFC 1122,= and
=C2=A0 =C2=A0subsequently updated in RFC 2988, and then again in RFC 6298.<= br>
=C2=A0 =C2=A0If a retransmitted packet is identical to the original packet = (which
=C2=A0 =C2=A0implies not only that the data boundaries have not changed, bu= t also
=C2=A0 =C2=A0that the window and acknowledgment fields of the header have n= ot
=C2=A0 =C2=A0changed), then the same IP Identification field MAY be used (s= ee
=C2=A0 =C2=A0Section 3.2.1.5 of RFC 1122).





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

--f403045dd8f04cac8605437bc04f-- From nobody Mon Dec 12 12:25:25 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CB2129491 for ; Mon, 12 Dec 2016 12:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MgB62GcCFU9 for ; Mon, 12 Dec 2016 12:25:21 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE53912948D for ; Mon, 12 Dec 2016 12:25:21 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id h30so191262479iod.2 for ; Mon, 12 Dec 2016 12:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=n9e8sGrQST2nK8Lx2P/Qf+Pe0cZBbMNKjMsV4Gmt3L8=; b=eDCiA53IH4cTd0eryd8vbme7uv0nyEC5gF2Nr48FMmq9gEvV4FLNsLjxobYmLXzOtW o1WT93fUc5wrfs8dgvHRl56SYuEs0nbNIexqyVZbejoSzuQYJhyNjflubzse2A227D6l MhhBdgP3Z6PeOkbA0VwbOTTWGL0eA51GEC8LSF5cSSSyBZeGxBrstsb2ESCft3mZHF6I z9bAXDVGJjncjVQ/T1jX/RpnsfEdC97n1jrJ5PfP38AEGNgwTTTp2IMGrp7uj9kt0nDY L/2j/msTS1UvuNDEZyxeNJp69m5cd4qdfeZLBokmLBmCPiaZW1qc+/S7LOwR0dvypLBP EVEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n9e8sGrQST2nK8Lx2P/Qf+Pe0cZBbMNKjMsV4Gmt3L8=; b=hQjoJ435PepCNfeTuKPY9O9gtDilc06jQ/Zt5MJIDo/Wnuomj9GbNAVEFd5mOSVRMA oLJCr60vxE6T9u0RGa0/mGCCxvUxlp6EBm9MIY8EBVnSKt0N+9Xw1Otkk3GLHT21FBu1 B77X7mx9k+7/FDLlRIO7Ap/RDfornVl5O/UyJ0r2ZmPyfBSHJ09miyi34fDyqjVSnTPU UblflL34AKbxHwuTjSvsQ7n7fgB7bbXzaeGWsNtgaITe8LafjSFg9OLXQk88aEXyCz9m bknWbAv4xCbz+7FpHn4E/JqFkMNbwMWv42Oni4JxcsOKfbMvcuVIT09y9hSUA2Qj0dNL b/uA== X-Gm-Message-State: AKaTC02NVfpavFKf2+jqbR2OfPN34tFVW07d9gO5tOzPnHU61EW8/GoSrpLCWfqm1HKupvO7I3GZ0qrMbTZ9yQga X-Received: by 10.36.178.81 with SMTP id h17mr11150282iti.98.1481574320813; Mon, 12 Dec 2016 12:25:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.150.67 with HTTP; Mon, 12 Dec 2016 12:24:39 -0800 (PST) In-Reply-To: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> References: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> From: Yuchung Cheng Date: Mon, 12 Dec 2016 12:24:39 -0800 Message-ID: To: Wesley Eddy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] 793bis: requirement on RTO computation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 12 Dec 2016 20:25:23 -0000 On Mon, Dec 12, 2016 at 12:04 PM, Wesley Eddy wrote: > > This is a thread to check group consensus on how to discuss RTT estimatio= n and RTO computation in RFC 793bis. > > RFC 793 originally had some material on this, described as "An Example Re= transmission Timeout Procedure", but that is replaced by several later docu= ments. > - RFC 1122 adds mention of Karn's algorithm plus exponential backoff of t= he RTO, and more strongly adds requirements ("MUST") for these, rather than= just being an "example". > - RFC 2988 and then 6298 expanded on RTT and RTO computation, and 6298 c= urrently updates 1122 in this regard. > > I think 6298 is "not too long" and has clear requirements. I think 793bi= s should simply reference 6298 as the requirement for computation of the RT= O, rather than trying to actually discuss this as a self-contained topic in= 793bis. I think that would be duplicative, unnecessary, and confusing. > > Do people agree with this? > > > For reference, the current 793bis text is below. The first paragraph is = direct from 793, the fourth from 1122, and the text in-between is attemptin= g to say what I described above: > > 3.8.1. Retransmission Timeout > > Because of the variability of the networks that compose an > internetwork system and the wide range of uses of TCP connections the > retransmission timeout (RTO) must be dynamically determined. > > The RTO MUST be computed according to the algorithm in [7], including > Karn's algorithm for taking RTT samples. > > RFC 793 contains an early example procedure for computing the RTO. > This was then replaced by the algorithm described in RFC 1122, and > subsequently updated in RFC 2988, and then again in RFC 6298. > > If a retransmitted packet is identical to the original packet (which > implies not only that the data boundaries have not changed, but also > that the window and acknowledgment fields of the header have not > changed), then the same IP Identification field MAY be used (see > Section 3.2.1.5 of RFC 1122). What will the new text looks like in the bis? > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Dec 12 12:35:28 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B392A1297C4 for ; Mon, 12 Dec 2016 12:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INfh6O_9v1SP for ; Mon, 12 Dec 2016 12:35:16 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27FE61297A7 for ; Mon, 12 Dec 2016 12:35:16 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id v84so100932367oie.3 for ; Mon, 12 Dec 2016 12:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+uU4z4JwwTOkmk1HWn3bi9ZLv7urUAT5x8fZPocmuPM=; b=YTs+cVgsfesd2PIm/Q4UlYn6AwR4v2mXZd3+BxdR/FjCnp8FK543Opw3Z1pkBA3OM8 t+mBTkgXq8kDU+WKzbMY8rb1hzB+ujZvCpO3nKNUvfoHf9aFsGv7TXCBgPA9uWTufjWL I8v5EvbxiXAyOuKqJbudtpPZtsSy0yKx3cyT5e8MSlygdbHkXRNrP3Ro/dQD1v7ZGYby 3cTw8YaWuIgOGDIn5ET/17TQ0Mt994BrlGqVQ3WSvdODZliMjhfYRwqHNZrDHnlkd0eg +d8uksrxOiwsi57yF9CpOzWqXbydRbbDunnbI9fM+e1NJcx5jwund5JmNirJmKmM2Hys idAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+uU4z4JwwTOkmk1HWn3bi9ZLv7urUAT5x8fZPocmuPM=; b=kWxD43gpCKeCadkbSrsDjniWSF6oQxn4qPU3VYG2dr5YI6zSv3+spax2sUEHpklS6l BsEhNHOnV5lSbvLkIeeDIyk5KDhPVjgZgZW2QJfd86SOl0YcwffyT4CCZKK01WQ6KOCO JakW8gWS57HbrsnabeAb15ZT3h/A9+EomTvP87e++e3qdrGRRqalzx8TAvkOuoKf1cIz 0UZkUI1iDAtXpcZpwjBvWUS6JyI+58nzjEABC1Jdz+4FuS4XV8Vss5Rw7mrJwUeRNn5h ThZtzIcQkKp/RMK6BLjTGGtLqc6v04p9WH5Pjbi32E5/JV7xyLBoqJy+BF6/cy06awq5 EmUw== X-Gm-Message-State: AKaTC02yOA4pSWb8sIzrjE6727R2fm7FJxMzk37r3gjofoLfus5NQOiI+LkmoS9ZKLwonwjVp5HYHb2O/aUN/Blj X-Received: by 10.157.2.36 with SMTP id 33mr55419202otb.180.1481574915447; Mon, 12 Dec 2016 12:35:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.240.213 with HTTP; Mon, 12 Dec 2016 12:34:45 -0800 (PST) In-Reply-To: References: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> From: Neal Cardwell Date: Mon, 12 Dec 2016 15:34:45 -0500 Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=94eb2c04432c8b8f7d05437c0ae8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 793bis: requirement on RTO computation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 12 Dec 2016 20:35:25 -0000 --94eb2c04432c8b8f7d05437c0ae8 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 12, 2016 at 3:14 PM, Jana Iyengar wrote: > > > On Mon, Dec 12, 2016 at 12:04 PM, Wesley Eddy wrote: > >> This is a thread to check group consensus on how to discuss RTT >> estimation and RTO computation in RFC 793bis. >> >> RFC 793 originally had some material on this, described as "An Example >> Retransmission Timeout Procedure", but that is replaced by several later >> documents. >> - RFC 1122 adds mention of Karn's algorithm plus exponential backoff of >> the RTO, and more strongly adds requirements ("MUST") for these, rather >> than just being an "example". >> - RFC 2988 and then 6298 expanded on RTT and RTO computation, and 6298 >> currently updates 1122 in this regard. >> >> I think 6298 is "not too long" and has clear requirements. I think >> 793bis should simply reference 6298 as the requirement for computation of >> the RTO, rather than trying to actually discuss this as a self-contained >> topic in 793bis. I think that would be duplicative, unnecessary, and >> confusing. >> >> Do people agree with this? >> > > +1. Nobody refers to 793 for RTT/RTO computation anyways. > +1 for just citing 6298, with text along the proposed lines. neal > > - jana > > >> For reference, the current 793bis text is below. The first paragraph is >> direct from 793, the fourth from 1122, and the text in-between is >> attempting to say what I described above: >> >> 3.8.1. Retransmission Timeout >> >> Because of the variability of the networks that compose an >> internetwork system and the wide range of uses of TCP connections the >> retransmission timeout (RTO) must be dynamically determined. >> >> The RTO MUST be computed according to the algorithm in [7], including >> Karn's algorithm for taking RTT samples. >> >> RFC 793 contains an early example procedure for computing the RTO. >> This was then replaced by the algorithm described in RFC 1122, and >> subsequently updated in RFC 2988, and then again in RFC 6298. >> >> If a retransmitted packet is identical to the original packet (which >> implies not only that the data boundaries have not changed, but also >> that the window and acknowledgment fields of the header have not >> changed), then the same IP Identification field MAY be used (see >> Section 3.2.1.5 of RFC 1122). >> >> >> >> >> >> _______________________________________________ >> 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 > > --94eb2c04432c8b8f7d05437c0ae8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 12, 2016 at 3:14 PM, Jana Iyengar <jri@google.com> wrote:


On Mon, D= ec 12, 2016 at 12:04 PM, Wesley Eddy <wes@mti-systems.com>= wrote:
This is a thread to check group c= onsensus on how to discuss RTT estimation and RTO computation in RFC 793bis= .

RFC 793 originally had some material on this, described as "An Example= Retransmission Timeout Procedure", but that is replaced by several la= ter documents.
- RFC 1122 adds mention of Karn's algorithm plus exponential backoff of= the RTO, and more strongly adds requirements ("MUST") for these,= rather than just being an "example".
-=C2=A0 RFC 2988 and then 6298 expanded on RTT and RTO computation, and 629= 8 currently updates 1122 in this regard.

I think 6298 is "not too long" and has clear requirements.=C2=A0 = I think 793bis should simply reference 6298 as the requirement for computat= ion of the RTO, rather than trying to actually discuss this as a self-conta= ined topic in 793bis.=C2=A0 I think that would be duplicative, unnecessary,= and confusing.

Do people agree with this?

+1. N= obody refers to 793 for RTT/RTO computation anyways.

+1 for just citing 6298, with text along = the proposed lines.

neal
=C2=A0

- jana
=C2=A0
For reference, the current 793bis text is below.=C2=A0 The first paragraph = is direct from 793, the fourth from 1122, and the text in-between is attemp= ting to say what I described above:

3.8.1.=C2=A0 Retransmission Timeout

=C2=A0 =C2=A0Because of the variability of the networks that compose an
=C2=A0 =C2=A0internetwork system and the wide range of uses of TCP connecti= ons the
=C2=A0 =C2=A0retransmission timeout (RTO) must be dynamically determined.
=C2=A0 =C2=A0The RTO MUST be computed according to the algorithm in [7], in= cluding
=C2=A0 =C2=A0Karn's algorithm for taking RTT samples.

=C2=A0 =C2=A0RFC 793 contains an early example procedure for computing the = RTO.
=C2=A0 =C2=A0This was then replaced by the algorithm described in RFC 1122,= and
=C2=A0 =C2=A0subsequently updated in RFC 2988, and then again in RFC 6298.<= br>
=C2=A0 =C2=A0If a retransmitted packet is identical to the original packet = (which
=C2=A0 =C2=A0implies not only that the data boundaries have not changed, bu= t also
=C2=A0 =C2=A0that the window and acknowledgment fields of the header have n= ot
=C2=A0 =C2=A0changed), then the same IP Identification field MAY be used (s= ee
=C2=A0 =C2=A0Section 3.2.1.5 of RFC 1122).





_______________________________________________
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


--94eb2c04432c8b8f7d05437c0ae8-- From nobody Mon Dec 12 12:42:13 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4F412947F for ; Mon, 12 Dec 2016 12:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm_J1zsWJzXd for ; Mon, 12 Dec 2016 12:42:08 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9D2126D73 for ; Mon, 12 Dec 2016 12:42:08 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 355DF990C4AE6; Mon, 12 Dec 2016 20:42:00 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uBCKg2UW027925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Dec 2016 20:42:03 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uBCKfTYZ013921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Dec 2016 20:42:01 GMT Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.116]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Mon, 12 Dec 2016 21:41:53 +0100 From: "Scharf, Michael (Nokia - DE)" To: Wesley Eddy , "tcpm@ietf.org" Thread-Topic: [tcpm] 793bis: requirement on RTO computation Thread-Index: AQHSVLLyZFn5dh35eUuQ9qAmVSrU5qEExZ1A Date: Mon, 12 Dec 2016 20:41:52 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48BF425D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> In-Reply-To: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] 793bis: requirement on RTO computation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 12 Dec 2016 20:42:10 -0000 Hi all, May I rephrase the question a bit: Should the reference to RFC 6298 be a MU= ST? For what it is worth, I can hardly think of any reason why we would want to= duplicate text RTO in 793bis, so IMHO the reference wording seems the key = question. Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Wesley Eddy > Sent: Monday, December 12, 2016 9:04 PM > To: tcpm@ietf.org > Subject: [tcpm] 793bis: requirement on RTO computation >=20 > This is a thread to check group consensus on how to discuss RTT > estimation and RTO computation in RFC 793bis. >=20 > RFC 793 originally had some material on this, described as "An Example > Retransmission Timeout Procedure", but that is replaced by several later > documents. > - RFC 1122 adds mention of Karn's algorithm plus exponential backoff of > the RTO, and more strongly adds requirements ("MUST") for these, rather > than just being an "example". > - RFC 2988 and then 6298 expanded on RTT and RTO computation, and 6298 > currently updates 1122 in this regard. >=20 > I think 6298 is "not too long" and has clear requirements. I think > 793bis should simply reference 6298 as the requirement for computation > of the RTO, rather than trying to actually discuss this as a > self-contained topic in 793bis. I think that would be duplicative, > unnecessary, and confusing. >=20 > Do people agree with this? >=20 >=20 > For reference, the current 793bis text is below. The first paragraph is > direct from 793, the fourth from 1122, and the text in-between is > attempting to say what I described above: >=20 > 3.8.1. Retransmission Timeout >=20 > Because of the variability of the networks that compose an > internetwork system and the wide range of uses of TCP connections the > retransmission timeout (RTO) must be dynamically determined. >=20 > The RTO MUST be computed according to the algorithm in [7], including > Karn's algorithm for taking RTT samples. >=20 > RFC 793 contains an early example procedure for computing the RTO. > This was then replaced by the algorithm described in RFC 1122, and > subsequently updated in RFC 2988, and then again in RFC 6298. >=20 > If a retransmitted packet is identical to the original packet (which > implies not only that the data boundaries have not changed, but also > that the window and acknowledgment fields of the header have not > changed), then the same IP Identification field MAY be used (see > Section 3.2.1.5 of RFC 1122). >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Dec 12 15:12:20 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9581F129F17 for ; Mon, 12 Dec 2016 15:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRvqsOQcDAIJ for ; Mon, 12 Dec 2016 15:12:16 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D28129E50 for ; Mon, 12 Dec 2016 15:08:57 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id d9so195201500ioe.0 for ; Mon, 12 Dec 2016 15:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RGgPpJosNzEqJwdcGwDOeMHuef9WPUyLLymp/zDYWzA=; b=lb6smHoKtFyXaOv6fJKeVdyeiJmvaMudq50ymILwVnl2mc352AC0vKeLV7Bx9b9CJs Tkjz5fj/wfs4mKbjSRjXoi4OgESsHPYdM7ti3nFYKi0Nr21PwlEQnmItROMPKV5F4/4B HXqxWlrhex9TBtmklFJjBz1ZgAiLfStAK4yucMNUE2Xrgik5y65wuYaL8Aa4Rc/sJ/eP TNHWp8bQQVo/RDxuKW2e08hPJ197OgLqCy2gn3BFQGkNCKpKCHQaRGNiFrT55P66dcVj unM9EiWX68CJCE8/MxOjrjzs3u8dxSSOYlsushmJvizPcAYbVKCzIjHZo04+WJGpv5RU nE2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RGgPpJosNzEqJwdcGwDOeMHuef9WPUyLLymp/zDYWzA=; b=XJLiRmmYNnFMgqBICOH0o+UAvF/GwK+iHMeLEISsF1swvOV5QIIzkSWxKNW1ZQ6WcJ inz2yk+7S+wznIvqtBnivAUfPkN7iKzjYdZiH17iJqMw1/Q08Zdh5LWbMWhgA8b0idFq pyiXQu6tl0fAsR+DOF3qkZjKZlEau6HvR9X2ooUlX+dPQF3Q8IWd/6jgxIaRe0gEOntH rUy6CLzNlom9At9zSYBhEqnTAzz5YcKch6NnHuoMdWTMuznYDC4kFlUcECyfeWIQnsNO gv9SrBm4db8Ne2YRLoMqWAItDUzM27oR28K/mMNrgw5GVGZmvUzuv/3WN/geJ1S9uv7+ QP8w== X-Gm-Message-State: AKaTC03qHN2+GBZf+eZDX2J+d7wer9RIzxgW+OjB8yeCaezF3G2AYxgZI8zz3fnqDqmrEmm5aN6e/4qrQk5Pl/HV X-Received: by 10.107.35.147 with SMTP id j141mr30854231ioj.41.1481584136557; Mon, 12 Dec 2016 15:08:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.150.67 with HTTP; Mon, 12 Dec 2016 15:08:15 -0800 (PST) In-Reply-To: <655C07320163294895BBADA28372AF5D48BF425D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> <655C07320163294895BBADA28372AF5D48BF425D@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Mon, 12 Dec 2016 15:08:15 -0800 Message-ID: To: "Scharf, Michael (Nokia - DE)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 793bis: requirement on RTO computation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 12 Dec 2016 23:12:19 -0000 On Mon, Dec 12, 2016 at 12:41 PM, Scharf, Michael (Nokia - DE) wrote: > Hi all, > > May I rephrase the question a bit: Should the reference to RFC 6298 be a MUST? > > For what it is worth, I can hardly think of any reason why we would want to duplicate text RTO in 793bis, so IMHO the reference wording seems the key question. > > Michael > > >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Wesley Eddy >> Sent: Monday, December 12, 2016 9:04 PM >> To: tcpm@ietf.org >> Subject: [tcpm] 793bis: requirement on RTO computation >> >> This is a thread to check group consensus on how to discuss RTT >> estimation and RTO computation in RFC 793bis. >> >> RFC 793 originally had some material on this, described as "An Example >> Retransmission Timeout Procedure", but that is replaced by several later >> documents. >> - RFC 1122 adds mention of Karn's algorithm plus exponential backoff of >> the RTO, and more strongly adds requirements ("MUST") for these, rather >> than just being an "example". >> - RFC 2988 and then 6298 expanded on RTT and RTO computation, and 6298 >> currently updates 1122 in this regard. >> >> I think 6298 is "not too long" and has clear requirements. I think >> 793bis should simply reference 6298 as the requirement for computation >> of the RTO, rather than trying to actually discuss this as a >> self-contained topic in 793bis. I think that would be duplicative, >> unnecessary, and confusing. >> >> Do people agree with this? +1 but some small suggestions below >> >> >> For reference, the current 793bis text is below. The first paragraph is >> direct from 793, the fourth from 1122, and the text in-between is >> attempting to say what I described above: >> >> 3.8.1. Retransmission Timeout >> >> Because of the variability of the networks that compose an >> internetwork system and the wide range of uses of TCP connections the >> retransmission timeout (RTO) must be dynamically determined. >> >> The RTO MUST be computed according to the algorithm in [7], including >> Karn's algorithm for taking RTT samples. why not just s/[7]/RFC6298 to save reader a round trip b/c he almost has to know what that is. >> >> RFC 793 contains an early example procedure for computing the RTO. >> This was then replaced by the algorithm described in RFC 1122, and >> subsequently updated in RFC 2988, and then again in RFC 6298. >> >> If a retransmitted packet is identical to the original packet (which >> implies not only that the data boundaries have not changed, but also >> that the window and acknowledgment fields of the header have not >> changed), then the same IP Identification field MAY be used (see >> Section 3.2.1.5 of RFC 1122). is this ipid text still useful. The text in RFC1122 seems to suggest the RFC authors didn't even believe that re-assembly benefit. >> >> >> >> >> >> _______________________________________________ >> 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 nobody Mon Dec 12 15:17:28 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E6D129E2D for ; Mon, 12 Dec 2016 15:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVgE-HLm2Fau for ; Mon, 12 Dec 2016 15:17:24 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078B4129E76 for ; Mon, 12 Dec 2016 15:17:14 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id 51so96542498uai.1 for ; Mon, 12 Dec 2016 15:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ySm7fZhhAziR1Ibww3TXhyzdwsoHGzAtxrzlOxI9MWU=; b=Gtqmhzym1dOK+my5S4Lx57L1Vo9fb3+PGaF9PDdb+t9dY8GnmHtLZEWCBrqRFE0Ktn xKjNS3s7vMd6sMm8dkNUrvY3XjvSyhqtd/5K0Fh6By+/tFwZ//7NwCC+a0hckGKwNlog SC6F9cD165NegLtXsllFX1O9f1Omyf+nD0MWXtPFWsBIfi8aCHhxsKHZzGqDBq59Ooxd NVvCY687BcAOFTtzJyTF+hfR6UMO5UkvAmSpLmJZ9g+evYjl6pN9WvjMfkaD5+mXwhLL ajW0Swh5KGH8mcomZR+vT9MfA7ZVo5yteBC3CGWAdIA/yh5s6bzVhyDBSG7P1zwiLCAH Zxdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ySm7fZhhAziR1Ibww3TXhyzdwsoHGzAtxrzlOxI9MWU=; b=cv0zeApNYhbZI6uBBSP77u/E3rMdwT4FBX6E3JGbCmVl8VOwuOV/QSeAiRfAqnC3r2 VWn+xnnVwHg8oM38Xe93GN37tICynKCpnH6LfUQiXF+3/j/zbXw1RLvtMnX7XUQIerDk WJyBUUMrzvpmDEZ/S115nY/UZ9nW+oDFlFq7cHVOk85F185TNB+Lr3aZQ+GhO6wuNtTc yTuYFXOBdw2FhkLzd9AYHzYo+svVmpwYhbas6praR7sHzMAfMIuxR+WHrbFlq2yzny9B 1ukw+ayUhfyVoq72dQAcfjMZC4UnkRN7aBppZBE94Jrg+V+CD4rtnlIOtQRhM0M118yp bPlA== X-Gm-Message-State: AKaTC03J+0MkP5iIJlZo+fWIMT9Xwf5WRYvL+1jp7Da+QLNx/5sLPqDCJ5ieDHXOruueWoYxSyTSckTnr6CQzZXM X-Received: by 10.176.80.154 with SMTP id c26mr76085210uaa.136.1481584632251; Mon, 12 Dec 2016 15:17:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Mon, 12 Dec 2016 15:17:11 -0800 (PST) In-Reply-To: <655C07320163294895BBADA28372AF5D48BF425D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> <655C07320163294895BBADA28372AF5D48BF425D@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Jana Iyengar Date: Mon, 12 Dec 2016 15:17:11 -0800 Message-ID: To: "Scharf, Michael (Nokia - DE)" Content-Type: multipart/alternative; boundary=94eb2c190cf0b6285705437e4df9 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] 793bis: requirement on RTO computation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 12 Dec 2016 23:17:26 -0000 --94eb2c190cf0b6285705437e4df9 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 12, 2016 at 12:41 PM, Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > Hi all, > > May I rephrase the question a bit: Should the reference to RFC 6298 be a > MUST? > Good question. MUST seems too strong for the reference to 6298, and there are no interoperability issues by doing something different. I wonder what folks think about saying "SHOULD implement 6298, and MUST adhere to guidelines in draft-ietf-tcpm-rto-consider". > For what it is worth, I can hardly think of any reason why we would want > to duplicate text RTO in 793bis, so IMHO the reference wording seems the > key question. > > Michael > > > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Wesley Eddy > > Sent: Monday, December 12, 2016 9:04 PM > > To: tcpm@ietf.org > > Subject: [tcpm] 793bis: requirement on RTO computation > > > > This is a thread to check group consensus on how to discuss RTT > > estimation and RTO computation in RFC 793bis. > > > > RFC 793 originally had some material on this, described as "An Example > > Retransmission Timeout Procedure", but that is replaced by several later > > documents. > > - RFC 1122 adds mention of Karn's algorithm plus exponential backoff of > > the RTO, and more strongly adds requirements ("MUST") for these, rather > > than just being an "example". > > - RFC 2988 and then 6298 expanded on RTT and RTO computation, and 6298 > > currently updates 1122 in this regard. > > > > I think 6298 is "not too long" and has clear requirements. I think > > 793bis should simply reference 6298 as the requirement for computation > > of the RTO, rather than trying to actually discuss this as a > > self-contained topic in 793bis. I think that would be duplicative, > > unnecessary, and confusing. > > > > Do people agree with this? > > > > > > For reference, the current 793bis text is below. The first paragraph is > > direct from 793, the fourth from 1122, and the text in-between is > > attempting to say what I described above: > > > > 3.8.1. Retransmission Timeout > > > > Because of the variability of the networks that compose an > > internetwork system and the wide range of uses of TCP connections the > > retransmission timeout (RTO) must be dynamically determined. > > > > The RTO MUST be computed according to the algorithm in [7], including > > Karn's algorithm for taking RTT samples. > > > > RFC 793 contains an early example procedure for computing the RTO. > > This was then replaced by the algorithm described in RFC 1122, and > > subsequently updated in RFC 2988, and then again in RFC 6298. > > > > If a retransmitted packet is identical to the original packet (which > > implies not only that the data boundaries have not changed, but also > > that the window and acknowledgment fields of the header have not > > changed), then the same IP Identification field MAY be used (see > > Section 3.2.1.5 of RFC 1122). > > > > > > > > > > > > _______________________________________________ > > 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 > --94eb2c190cf0b6285705437e4df9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 12, 2016 at 12:41 PM, Scharf, Michael (Nokia - DE) <michael= .scharf@nokia.com> wrote:
H= i all,

May I rephrase the question a bit: Should the reference to RFC 6298 be a MU= ST?

Good question. MUST seems too stron= g for the reference to 6298, and there are no interoperability issues by do= ing something different. I wonder what folks think about saying "SHOUL= D implement 6298, and MUST adhere to guidelines in draft-ietf-tcpm-rto-cons= ider".

=C2=A0
For what it is worth, I can hardly think of any reason why we would want to= duplicate text RTO in 793bis, so IMHO the reference wording seems the key = question.

Michael


> -----Original Message-----
> From: tcpm [mailto:tcpm-bounc= es@ietf.org] On Behalf Of Wesley Eddy
> Sent: Monday, December 12, 2016 9:04 PM
> To: tcpm@ietf.org
> Subject: [tcpm] 793bis: requirement on RTO computation
>
> This is a thread to check group consensus on how to discuss RTT
> estimation and RTO computation in RFC 793bis.
>
> RFC 793 originally had some material on this, described as "An Ex= ample
> Retransmission Timeout Procedure", but that is replaced by severa= l later
> documents.
> - RFC 1122 adds mention of Karn's algorithm plus exponential backo= ff of
> the RTO, and more strongly adds requirements ("MUST") for th= ese, rather
> than just being an "example".
> -=C2=A0 RFC 2988 and then 6298 expanded on RTT and RTO computation, an= d 6298
> currently updates 1122 in this regard.
>
> I think 6298 is "not too long" and has clear requirements.= =C2=A0 I think
> 793bis should simply reference 6298 as the requirement for computation=
> of the RTO, rather than trying to actually discuss this as a
> self-contained topic in 793bis.=C2=A0 I think that would be duplicativ= e,
> unnecessary, and confusing.
>
> Do people agree with this?
>
>
> For reference, the current 793bis text is below.=C2=A0 The first parag= raph is
> direct from 793, the fourth from 1122, and the text in-between is
> attempting to say what I described above:
>
> 3.8.1.=C2=A0 Retransmission Timeout
>
>=C2=A0 =C2=A0 =C2=A0Because of the variability of the networks that com= pose an
>=C2=A0 =C2=A0 =C2=A0internetwork system and the wide range of uses of T= CP connections the
>=C2=A0 =C2=A0 =C2=A0retransmission timeout (RTO) must be dynamically de= termined.
>
>=C2=A0 =C2=A0 =C2=A0The RTO MUST be computed according to the algorithm= in [7], including
>=C2=A0 =C2=A0 =C2=A0Karn's algorithm for taking RTT samples.
>
>=C2=A0 =C2=A0 =C2=A0RFC 793 contains an early example procedure for com= puting the RTO.
>=C2=A0 =C2=A0 =C2=A0This was then replaced by the algorithm described i= n RFC 1122, and
>=C2=A0 =C2=A0 =C2=A0subsequently updated in RFC 2988, and then again in= RFC 6298.
>
>=C2=A0 =C2=A0 =C2=A0If a retransmitted packet is identical to the origi= nal packet (which
>=C2=A0 =C2=A0 =C2=A0implies not only that the data boundaries have not = changed, but also
>=C2=A0 =C2=A0 =C2=A0that the window and acknowledgment fields of the he= ader have not
>=C2=A0 =C2=A0 =C2=A0changed), then the same IP Identification field MAY= be used (see
>=C2=A0 =C2=A0 =C2=A0Section 3.2.1.5 of RFC 1122).
>
>
>
>
>
> _______________________________________________
> 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

--94eb2c190cf0b6285705437e4df9-- From nobody Tue Dec 13 00:58:16 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259C61299F2 for ; Tue, 13 Dec 2016 00:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzYhrM-cgAmg for ; Tue, 13 Dec 2016 00:58:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BD21299EE for ; Tue, 13 Dec 2016 00:58:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCL85270; Tue, 13 Dec 2016 08:58:07 +0000 (GMT) Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 13 Dec 2016 08:58:06 +0000 Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.220]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0301.000; Tue, 13 Dec 2016 16:58:03 +0800 From: "zhangyali (D)" To: "tcpm@ietf.org" Thread-Topic: A question about Delayed ACK and RTO Thread-Index: AdJVHvxj56KQ83ErQFe6OJTIeyiZRg== Date: Tue, 13 Dec 2016 08:58:03 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.189.228] Content-Type: multipart/alternative; boundary="_000_A747A0713F56294D8FBE33E5C6B8F5815F545A98DGGEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.584FB822.015E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.220, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 54fa9cbe2bd28f35f4c7a5bf036d0b91 Archived-At: Subject: [tcpm] A question about Delayed ACK and RTO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 13 Dec 2016 08:58:15 -0000 --_000_A747A0713F56294D8FBE33E5C6B8F5815F545A98DGGEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Recent days, I am doing some simulation about TCP performance in NS3. I fou= nd a phenomenon is a default setting of TCP's delayed ACK is two packets or= 200ms. I am wondering if this setting is accord with some RFCs in IETF. B= ut After I referred to some RFCs, I just found some restrictions, such as, = the delay must be less than 0.5ms (RFC1122). I think the delayed ACK has a close relationship with RTO. Take an extreme = scenario, if the delay is longer than RTO, many packets will be retransmitt= ed, which will waste many network resources. So I want to know do we have some RFCs have given the exact value of both? = And if we permit any TCP stack to set them freely, what is the mechanism to= balance the mismatch between RTO and delayed ACK? Best Regards, Yali --_000_A747A0713F56294D8FBE33E5C6B8F5815F545A98DGGEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Recent days, I am doing some simulation about TCP pe= rformance in NS3. I found a phenomenon is a default setting of TCP’s = delayed ACK is two packets or 200ms. I am wondering if this setting is acco= rd with  some RFCs in IETF. But After I referred to some RFCs, I just found some restrictions, such as, the delay = must be less than 0.5ms (RFC1122).

 

I think the delayed ACK has a close relationship wit= h RTO. Take an extreme scenario, if the delay is longer than RTO, many pack= ets will be retransmitted, which will waste many network resources.

 

So I want to know do we have some RFCs have given th= e exact value of both? And if we permit any TCP stack to set them freely, w= hat is the mechanism to balance the mismatch between RTO and delayed ACK?

 

 

Best Regards,

Yali

--_000_A747A0713F56294D8FBE33E5C6B8F5815F545A98DGGEMA502MBSchi_-- From nobody Tue Dec 13 01:27:19 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC6E129506 for ; Tue, 13 Dec 2016 01:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoJVfYL4DN5v for ; Tue, 13 Dec 2016 01:27:13 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A12129582 for ; Tue, 13 Dec 2016 01:27:09 -0800 (PST) Received: from srichardlxp2 ([213.143.121.76]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M1n4s-1cVV191eHK-00tlwr; Tue, 13 Dec 2016 10:26:25 +0100 Message-ID: From: "Richard Scheffenegger" To: "Neal Cardwell" , "Yuchung Cheng" References: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> Date: Tue, 13 Dec 2016 10:06:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01D25528.A41F6760" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Provags-ID: V03:K0:+g6No+pgn2xUAdr7Qg3M5CGqByffRS/P+xMg2jgg257+Dl4yq1E WE0Q0ZFxgViBDF0dR2/rmwI+3lZvx+KPxYhMrXVvxx6FnosevL81c3GgwdmxapqWsOQKI9R eDN3ZfMS85gJFrSabvUT1ChK46C1S2EFZ/DLcHdB96i/MkWOs4NtX52DgR+Liir7/ATLwWe A922o2XnhMBMjdj4wu/bQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:GKo9MD4osXo=:G+xaAovIBGVRts/Qih56pI 9V6OujILZv6Ba4SUo3DkCaPFIdPuV9YJhetmHcAHMod1YigTtawRg8vDpXUbr8e8r4NNHSG07 CjYO47l8THsJjY7Z1YI1KFVjshuqqu22oPKwmrKV8owypZ+9DEzZkQxZ2AdDBIntX6poHwESS fdPJKgPPCj9suISy7wP3Fc6HTeDW1ySLrKVD8NghL6FegO1l7LzOerauX2FifjjcEVZ/1d+qN SS/aMkcFoyBMkvIsnQrG1Vp5PmVQlMC7gwMlzwsVs04Eqv8CRrl68GmiCd5qSwnj6rVfvqzyh e/wG+sWRWY1rhGsSmYoYcnaLfC3afLpWK8q1HBKir79Gp78uBiI0UqWxl3b0NrTTaZbnSA38Q R1ToXk83iol4vnOoW5ieych66keKk0CWCwol55X1LVrJUgFDGq15nvvW5HOoMclpvW47QKdn+ pRImmU0rQYZgO4qVM2mWB3HvLxditeMDOGyDV4ADytP6CyRJTgjir1dPlLLiUsPTlJCR1767P kOviWzuooIXJ+sr+Ay4Argbn79wzS+QA20jg42HcZOeZapMHzTh9229HDwlifaS74Q3sIcuQg XHY/JT2ioH9/QrRssHtruR/fDDmYRRK2aqOUj67OQHZaFMaylMMmbpVtWRMP5ZNzw9+ShSa1J KGASQGLnA2JnS3Z6V6g2D+L9940as+keHpSW+N0kmJtOw41DGgOtvb41JhURbMHz4hOrVZO5j w5s6OKKTSlyob3K2N4q8PO6zb3NaqHuSsywWBTnCFjo+XFSHq0hmrww8zcUNj3/sDjc4Osm7P hz9sCA9 Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] Ref to timestamp negotiation draft (expired) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 13 Dec 2016 09:27:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0033_01D25528.A41F6760 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Neal, did you have time to glance over the timestamp negotiation draft?=20 Here is a brief abstract of some of the properties that the proposed = negotiation scheme offers. However, at the time, there was too little = interest in this (and no other vendor to support development efforts) = thus it expired. a) no additional TCP Option space useage, particular in the initial SYN b) Up to 24 bits for arbitrary signalling - the draft uses 16 = (https://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiati= on-05) to signal the timestamp interval; the value is encoded = differently from a IEEE floating point representation to allow further = freedom to indicate relative precision of the injected timestamp (ie. = envision a NIC capable of hw clocking each segment in a TSO transfer, = vs. using a coarse grained software clock in a virtual host) c) generic mechanism to make (parts of) the timestamp useful for the = receiver, allowing the sender to weakly authenticate returned timestamps = (e.g. avoiding the cubic epoch exploit to game a sender by manipulating = timestamps) d) In that basic version, 8 bits would still be available to provide the = signals envisioned by your proposal for indicating Max ACK Delay - = perhaps using a shift value offset by a constant biad as for the = timestamp interval, more granualar signaling would be possible than in = your proposal. Drawback of the scheme: duing 3WHS, the sender needs to keep state of = the original TSval (which should be a non-issue for Linux stacks, and is = manageable for byte-oriented stacks). Also, a small probability of falsely activating the TS negotiation. = However, against servers on the internet, this probability is smaller = than expected as TSval still relates linearly to system uptime, in most = implementations; I've investigated this during writing intensively (not = what you could do, though) - see section 5.3=20 Re-reading, I see that my descriptive language is perhaps not clear = enough, the signals spoken about in the draft are always exchanged in a = TSecr field of a TS Option, with the TSecr of the SYN/ACK being the XOR = sum of the TSval from the SYN, plus the capabilites signal of the = receiver... Best regards, Richard Great. Thanks, Bob. We'll take a look at these... neal On Wed, Nov 16, 2016 at 9:59 AM, Bob Briscoe = wrote: > Neil, [re-sending from correct address, so it is acceptable to the = tcpm > list] > > As promised in the discussion just now about your timer negotiation = talk > in tcpm, here's the previous draft on a similar subject: > Additional negotiation in the TCP Timestamp Option field during the = TCP > handshake > = > > This was originally prompted by the research here (see section 3.1 for = the > timestamp discussion), which you might also be interested in: > Chirping for Congestion Control - Implementation Feasibility > > > > > Bob > > PS. I can recommend a good search engine to find stuff like this :) > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > ------=_NextPart_000_0033_01D25528.A41F6760 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Neal,
 
did you have time to glance over the = timestamp=20 negotiation draft?
 
Here is a brief abstract of some of the = properties=20 that the proposed negotiation scheme offers. However, at the time, there = was too=20 little interest in this (and no other vendor to support development = efforts)=20 thus it expired.
 
a) no additional TCP Option space = useage,=20 particular in the initial SYN
 
b) Up to 24 bits for arbitrary = signalling - the=20 draft uses 16 (https://tools.ietf.org/html/draft-scheffenegger-tcpm-timest= amp-negotiation-05)=20 to signal the timestamp interval; the value is encoded differently from = a IEEE=20 floating point representation to allow further freedom to indicate = relative=20 precision of the injected timestamp (ie. envision a NIC capable of hw = clocking=20 each segment in a TSO transfer, vs. using a coarse grained software = clock in a=20 virtual host)
 
c) generic mechanism to make (parts of) = the =20 timestamp useful for the receiver, allowing the sender to weakly = authenticate=20 returned timestamps (e.g. avoiding the cubic epoch exploit to game a = sender by=20 manipulating timestamps)
 
d) In that basic version, 8 bits would = still be=20 available to provide the signals envisioned by your proposal for = indicating Max=20 ACK Delay - perhaps using a shift value offset by a constant biad as for = the=20 timestamp interval, more granualar signaling would be possible than in = your=20 proposal.
 

Drawback of the scheme: duing 3WHS, the sender needs to keep = state of=20 the original TSval (which should be a non-issue for Linux stacks, and is = manageable for byte-oriented stacks).
 
Also, a small probability of falsely activating the TS negotiation. = However, against servers on the internet, this probability is smaller = than=20 expected as TSval still relates linearly to system uptime, in most=20 implementations; I've investigated this during writing intensively (not = what you=20 could do, though) - see section 5.3
 
Re-reading, I see that my descriptive language  is = perhaps not=20 clear enough, the signals spoken about in the draft are always exchanged = in a=20 TSecr field of a TS Option, with the TSecr of the SYN/ACK being the XOR = sum of=20 the TSval from the SYN, plus the capabilites signal of the = receiver...
 
Best regards,
  Richard
 
 
 
 
Great. Thanks, Bob. We'll take a look = at=20 these...
 
neal
 
On Wed, Nov 16, 2016 at 9:59 AM, Bob = Briscoe <ietf@bobbriscoe.net>=20 wrote:
 
> Neil, [re-sending from correct = address, so it=20 is acceptable to the tcpm
> list]
>
> As promised in = the=20 discussion just now about your timer negotiation talk
> in tcpm, = here's=20 the previous draft on a similar subject:
> Additional negotiation = in the=20 TCP Timestamp Option field during the TCP
> handshake
> = <https://tools.ietf.org/html/draft-scheffenegger-tcpm-timest= amp-negotiation-05>
>
>=20 This was originally prompted by the research here (see section 3.1 for=20 the
> timestamp discussion), which you might also be interested=20 in:
> Chirping for Congestion Control - Implementation = Feasibility
>=20 <http://www.bobbri= scoe.net/pubs.html#chirp_impl>
>
>
>
>=20 Bob
>
> PS. I can recommend a good search engine to find = stuff like=20 this :)
>
>
> --
>=20 ________________________________________________________________
> = Bob=20 Briscoe           =             &= nbsp;      =20 http://bobbriscoe.net/
>
>= ;
------=_NextPart_000_0033_01D25528.A41F6760-- From nobody Tue Dec 13 07:18:28 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C092412940A for ; Tue, 13 Dec 2016 07:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmdA69DMZ615 for ; Tue, 13 Dec 2016 07:18:23 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410FD129407 for ; Tue, 13 Dec 2016 07:18:23 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id w63so125820051oiw.0 for ; Tue, 13 Dec 2016 07:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9KWvLrHccwhKO2lX8hB5gJKa0xPfIyZDkWayqVBwD84=; b=XkimA3TyKS5VbWi+3jwrHYtwwg3lgCq6L8Mb3h1dY+fmG07ef+o4TKnbcXiBXqbi8Z Hdw3s0xYRX+N3UFDVxoZchn0+9WNxqrHcXHdtB0esmDAYCX4sHdscyweA/HovJKxUM6W JnhHkguvjX6WIO5AECwI6cMpMekndnl2js6T279DngCs2OXuw4BSuQpJZG/5QlkSKGIF IEt8vjlBDnX29UVmVEMOz5H1FJdjPLeJhWlxPqjF07WSU6ijcrFyiJJJrXsBVC9/hByu x3UKq9ZcPNrwCgEzZsv9mdDBE2RNaUCgC7UAyt4KFantBUsavdqoW/p9CerHYSz9bWZX Zbog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9KWvLrHccwhKO2lX8hB5gJKa0xPfIyZDkWayqVBwD84=; b=k1jr+xYenrLmg/wnViPfMJjeSfDYAzOPTbh2IpGxiPiR4yIxD8BFD5h3MEkFXEtD7L wKIdo72SJs23+rsOTowL9oHHEe01U3+QT80F6MAUciz4hwRcOZn9ZmdlTHlGmKcXN8Pf 6xbLXe9+xmqoY0tV15QZ14qAyLBcq+mEGOsNMXUyJG+Q4uwOBw0/fG3jhEoSqIo9lTqz m8qO0ucKzknpC4rDAQ3piAQ+ZXKD3FmZMDrbVzV1fBPAY5YajrdavRnYheQdtzdWqeYa LL+Us4M5erzdztdlI4gBi3mNGLdnwB42tULSvxByii4QYB8hxpKGuxZr+z/D7ElHKWse gWrQ== X-Gm-Message-State: AKaTC01rsRdfTEJAhc6W1uMWxmnpWDNmrSDdLPS50IIeYNuIeG98LoDnNWuTuY+vHvoB+1qxO4RVSvAU2zf7q6js X-Received: by 10.202.94.138 with SMTP id s132mr52931849oib.196.1481642302437; Tue, 13 Dec 2016 07:18:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.240.213 with HTTP; Tue, 13 Dec 2016 07:17:51 -0800 (PST) In-Reply-To: References: From: Neal Cardwell Date: Tue, 13 Dec 2016 10:17:51 -0500 Message-ID: To: "zhangyali (D)" Content-Type: multipart/alternative; boundary=001a113d2a781f720705438bbb8e Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] A question about Delayed ACK and RTO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 13 Dec 2016 15:18:26 -0000 --001a113d2a781f720705438bbb8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) wrote: > Hi all, > > > > Recent days, I am doing some simulation about TCP performance in NS3. I > found a phenomenon is a default setting of TCP=E2=80=99s delayed ACK is t= wo packets > or 200ms. I am wondering if this setting is accord with some RFCs in IET= F. > But After I referred to some RFCs, I just found some restrictions, such a= s, > the delay must be less than 0.5ms (RFC1122). > > I believe the 200ms figure is due to historical reasons. AFAIK it's due to the BSD delayed ACK behavior (see Stevens "TCP/IP Illustrated Volume 2", section 25.4 and figure 25.7, which describes the 200ms delayed ACK timer). Then this value was inherited by other widely-deployed OSes. > I think the delayed ACK has a close relationship with RTO. Take an extrem= e > scenario, if the delay is longer than RTO, many packets will be > retransmitted, which will waste many network resources. > Yes, exactly. In theory, the RTO tries to be adaptive enough to measure any RTT variations caused by delayed ACKs, and increase the RTO in response to this. However, it's quite easy for a bulk transfer to never have any delayed ACKs for most of its lifetime, during which the RTO gradually converges toward the raw RTT value. Then when there is suddenly a delayed ACK, there can be a spurious RTO. To avoid that, many TCP stacks (at least the major open source OSes) have a hard-coded 200ms "slop factor" or "fudge factor", to try to never let their estimate of RTT variation fall below that 200ms value, to avoid this effect. > So I want to know do we have some RFCs have given the exact value of both= ? > And if we permit any TCP stack to set them freely, what is the mechanism = to > balance the mismatch between RTO and delayed ACK? > I'm not aware of RFC specifications for exact values of both (delayed ACK and RTO). However, the historical precedent is very strong, and the 200ms delayed ACK value was very pronounced in Internet traces at least as recently as 2011, when I last looked at the effect. (Probably others have more recent data points for the prevalence of 200ms delayed ACKs.) At IETF 97 our team at Google presented some features we use for internal TCP traffic at Google, where the endpoints can negotiate the specific constant to use for the maximum delayed ACK from the receiver and the corresponding minimum RTT delay variation for budgeting in the RTO at the sender: https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-l= ow-latency-00.pdf As this slide deck notes, within Google we negotiate 5ms for delayed ACKs. cheers, neal --001a113d2a781f720705438bbb8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 13, 2016 at 3:58 AM, zhangyali (D) <zhangyali369@huawei.com<= /a>> wrote:

Hi all,

=C2=A0

Recent days, I am doing some simulation about TCP pe= rformance in NS3. I found a phenomenon is a default setting of TCP=E2=80=99= s delayed ACK is two packets or 200ms. I am wondering if this setting is ac= cord with =C2=A0some RFCs in IETF. But After I referred to some RFCs, I just found some restrictions, such as, the delay = must be less than 0.5ms (RFC1122).


<= div>I believe the 200ms figure is due to historical reasons. AFAIK it's= due to the BSD delayed ACK behavior (see Stevens "TCP/IP Illustrated = Volume 2", section 25.4 and figure 25.7, which describes the 200ms del= ayed ACK timer). Then this value was inherited by other widely-deployed OSe= s.



<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

=

So I want to know do we have some RFCs have given th= e exact value of both? And if we permit any TCP stack to set them freely, w= hat is the mechanism to balance the mismatch between RTO and delayed ACK?


I'm not aware of RFC spe= cifications for exact values of both (delayed ACK and RTO). However, the hi= storical precedent is very strong, and the 200ms delayed ACK value was very= pronounced in Internet traces at least as recently as 2011, when I last lo= oked at the effect. (Probably others have more recent data points for the p= revalence of 200ms delayed ACKs.)

At IETF 97 our t= eam at Google presented some features we use for internal TCP traffic at Go= ogle, where the endpoints can negotiate the specific constant to use for th= e maximum delayed ACK from the receiver and the corresponding minimum RTT d= elay variation for budgeting in the RTO at the sender:

=
As this slide deck notes, within Google we negotiate 5ms = for delayed ACKs.

cheers,=C2=A0
neal

--001a113d2a781f720705438bbb8e-- From nobody Tue Dec 13 11:22:55 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5B412946B for ; Tue, 13 Dec 2016 11:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I8kC7qLyvZz for ; Tue, 13 Dec 2016 11:22:52 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E722212941E for ; Tue, 13 Dec 2016 11:22:52 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id uBDJMkqZ026712; Tue, 13 Dec 2016 11:22:47 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AAE5269458EC; Tue, 13 Dec 2016 14:22:46 -0500 (EST) To: Neal Cardwell From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jailbreak X-URL-0: http://www.icir.org/mallman-files/Document3539.jpg X-URL-1: http://www.icir.org/mallman-files/Document96216.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 13 Dec 2016 14:22:46 -0500 Message-ID: <95734.1481656966@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] A question about Delayed ACK and RTO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 19:22:54 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I don't disagree with anything Neal said, but want to emphasize something.=20 > I think the delayed ACK has a close relationship with RTO. Take > an extreme scenario, if the delay is longer than RTO, many > packets will be retransmitted, which will waste many network > resources. >=20 > Yes, exactly. In theory, the RTO tries to be adaptive enough to > measure any RTT variations caused by delayed ACKs, and increase the > RTO in response to this. In other words, the delayed ACK timer and the RTO are not competing. The delayed ACK timer should be a subset of the RTO. That said, ... > However, it's quite easy for a bulk transfer to never have any > delayed ACKs for most of its lifetime, during which the RTO > gradually converges toward the raw RTT value. Then when there is > suddenly a delayed ACK, there can be a spurious RTO. ... this is certainly possible. And, especially so as folks have moved towards trying to make the RTO converge to the RTT (e.g., by not reseting the RTO on ACK reception or not using a minRTO or the like). The less variance the RTO accounts for the more a spike in delay (from various places) will fool the RTO. Many moons ago we showed there is a fundamental tradeoff between RTO timeliness and RTO accuracy. You can optimize for one of those, but it will come at the expense of the other. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlhQSoYACgkQWyrrWs4yIs4TKgCfcEVgx60nEnDg4KucS0Jcsjy4 4WsAnjximEzQHo6K4XjdpLBlMvsjvwRr =+bre -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Dec 14 01:49:00 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56921299EB for ; Wed, 14 Dec 2016 01:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLq2_-9IHops for ; Wed, 14 Dec 2016 01:48:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E501299E1 for ; Wed, 14 Dec 2016 01:48:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXB77640; Wed, 14 Dec 2016 09:48:50 +0000 (GMT) Received: from DGGEMA404-HUB.china.huawei.com (10.3.20.45) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 14 Dec 2016 09:48:28 +0000 Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.220]) by DGGEMA404-HUB.china.huawei.com ([10.3.20.45]) with mapi id 14.03.0301.000; Wed, 14 Dec 2016 17:48:21 +0800 From: "zhangyali (D)" To: Neal Cardwell Thread-Topic: [tcpm] A question about Delayed ACK and RTO Thread-Index: AdJVHvxj56KQ83ErQFe6OJTIeyiZRv//5A6A//5PGuA= Date: Wed, 14 Dec 2016 09:48:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.189.228] Content-Type: multipart/alternative; boundary="_000_A747A0713F56294D8FBE33E5C6B8F5815F545E28DGGEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58511583.03E2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.220, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 93e2bc82fbe8eafcbcb4f85e6454c61c Archived-At: Cc: "tcpm@ietf.org" Subject: [tcpm] =?utf-8?b?562U5aSNOiAgQSBxdWVzdGlvbiBhYm91dCBEZWxheWVkIEFD?= =?utf-8?q?K_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Dec 2016 09:49:00 -0000 --_000_A747A0713F56294D8FBE33E5C6B8F5815F545E28DGGEMA502MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmVhbCwNCg0KVGhhbmtzIGZvciB5b3VyIHByb3ZpZGluZyByZXF1ZXN0IGluZm9ybWF0aW9u Lg0KDQpBYm91dCB0aGUgZGVsYXkgb2YgZGVsYXllZCBBQ0ssIEkgZm91bmQgYW5vdGhlciBjbHVl IGluIGEgU0lHQ09NTSBwYXBlciBpbiAxOTg4LiBJbiB0aGUgcGFnZSAxNCwgYSBzZW50ZW5jZSBp cyDigJxUaGUgNC41S0JwcyBzZW5kZXJzIHdlcmUgdGFsa2luZyB0byA0LjNCU0QgcmVjZWl2ZXJz IHdoaWNoIHdvdWxkIGRlbGF5IGFuIGFjayB1bnRpbCAzNSUgb2YgdGhlIHdpbmRvdyB3YXMgZmls bGVkIG9yIDIwMCBtcyBoYWQgcGFzc2VkIChpLmUuLCBhbiBhY2sgd2FzIGRlbGF5ZWQgZm9yIDUt NyBwYWNrZXRzIG9uIGF2ZXJhZ2UpLuKAnSBUaGVyZSBpcyBubyByZWZlcmVuY2UgYWJvdXQgdGhl IDIwMCBtcywgc28gSSBndWVzcyB0aGlzIGlzIHRoZSBwYXJ0aWN1bGFyIGRlbGF5IGFwcGVhcnMg Zm9yIHRoZSBmaXJzdCB0aW1lLg0KSSB0cnkgdG8gY2FsY3VsYXRlIHRoZSB2YWx1ZSBiYXNlZCBv biBkZWxheWVkIHBhY2tldCBudW1iZXJzLCBwYWNrZXQgc2l6ZSBhbmQgc2VuZGluZyByYXRlLiBJ biB0aGlzIGNhc2UsIHRoZSBkZWxheWVkIHBhY2tldCBudW1iZXIgaXMgNywgdGhlIHBhY2tldCBz aXplIGlzIDU3NkJ5dGUgKHJlZmVyIHRvIFJGQzg3OSBpbiAxOTgzKSwgYW5kIHN1bmRlcmluZyBy YXRlIGlzIDQuNUJwcy4gVGhlIHZhbHVlIGlzIDg5NiBtcyEgTG9uZ2VyIHRoYW4gMjAwIG1zLg0K DQo+LiBIb3dldmVyLCBpdCdzIHF1aXRlIGVhc3kgZm9yIGEgYnVsayB0cmFuc2ZlciB0byBuZXZl ciBoYXZlIGFueSBkZWxheWVkIEFDS3MgZm9yIG1vc3Qgb2YgaXRzIGxpZmV0aW1lLCBkdXJpbmcg d2hpY2ggdGhlIFJUTyBncmFkdWFsbHkgY29udmVyZ2VzIHRvd2FyZCB0aGUgcmF3IFJUVCB2YWx1 ZS4gVGhlbiB3aGVuIHRoZXJlIGlzIHN1ZGRlbmx5IGEgZGVsYXllZCBBQ0ssIHRoZXJlIGNhbiBi ZSBhIHNwdXJpb3VzIFJUTy4NCkkgYW0gbm90IHZlcnkgc3VyZSBpZiBJIHNlZSB5b3VyIHBvaW50 LiBJIHRoaW5rIHRoZSBrZXkgcG9pbnQgaXMgdGhlIFJUVCB2YXJpYXRpb24gd2lsbCBiZSB3ZWFr ZW5lZCB3aGVuIHBhY2tldHMgYXJlIHNlbnQgaW4gYSBidXJzdCAodGhlIGNvbnNlcXVlbmNlIG9m IGRlbGF5ZWQgQUNLKS4gICBBbmQgdGhlIHNwdXJpb3VzICBjb3VsZCBvbmx5IGhhcHBlbiBmb3Ig dGhlIGxhc3QgZmV3IHBhY2tldHMgd2hvc2UgbnVtYmVyIGlzIHNtYWxsZXIgdGhhbiBkZWxheWVk IHBhY2tldHMsIHJpZ2h0Pw0KDQoNCkFib3V0IHlvdXIgcHJvcG9zYWwgYWJvdXQgbmVnb3RpYXRp b24gb2YgZGVsYXllZCBBQ0ssIGEgcG90ZW50aWFsIHByb2JsZW0gaXMgdGhhdCBSVE8gd2lsbCBi ZSBzdHJldGNoZWQgdGhhbiBiZWZvcmUgYmVjYXVzZSB5b3UgYWRkIGV4dHJhIGRlbGF5LiBBcyB5 b3UgaGF2ZSBzYWlkLCBtb3N0IG9mIHRoZSBwYWNrZXRzIHdpbGwgbm90IGV4Y2VlZCBSVE8gZXZl biBob3N0IGVuYWJsZSBkZWxheWVkIEFDSyBmb3IgbW9zdCBsYXJnZSBmbG93cywgYnV0IHRoZSBy ZXRyYW5zbWlzc2lvbiB3aWxsIGJlIGRlbGF5ZWQgKGkuZS4sIDVtcylhbHNvIG9uY2Ugb25lIHBh Y2tldCBpcyBsb3N0Lg0KDQpCZXN0LA0KWWFsaQ0K5Y+R5Lu25Lq6OiBOZWFsIENhcmR3ZWxsIFtt YWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTblubQxMuaciDEz 5pelIDIzOjE4DQrmlLbku7bkuro6IHpoYW5neWFsaSAoRCkgPHpoYW5neWFsaTM2OUBodWF3ZWku Y29tPg0K5oqE6YCBOiB0Y3BtQGlldGYub3JnDQrkuLvpopg6IFJlOiBbdGNwbV0gQSBxdWVzdGlv biBhYm91dCBEZWxheWVkIEFDSyBhbmQgUlRPDQoNCk9uIFR1ZSwgRGVjIDEzLCAyMDE2IGF0IDM6 NTggQU0sIHpoYW5neWFsaSAoRCkgPHpoYW5neWFsaTM2OUBodWF3ZWkuY29tPG1haWx0bzp6aGFu Z3lhbGkzNjlAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpSZWNlbnQgZGF5cywgSSBh bSBkb2luZyBzb21lIHNpbXVsYXRpb24gYWJvdXQgVENQIHBlcmZvcm1hbmNlIGluIE5TMy4gSSBm b3VuZCBhIHBoZW5vbWVub24gaXMgYSBkZWZhdWx0IHNldHRpbmcgb2YgVENQ4oCZcyBkZWxheWVk IEFDSyBpcyB0d28gcGFja2V0cyBvciAyMDBtcy4gSSBhbSB3b25kZXJpbmcgaWYgdGhpcyBzZXR0 aW5nIGlzIGFjY29yZCB3aXRoICBzb21lIFJGQ3MgaW4gSUVURi4gQnV0IEFmdGVyIEkgcmVmZXJy ZWQgdG8gc29tZSBSRkNzLCBJIGp1c3QgZm91bmQgc29tZSByZXN0cmljdGlvbnMsIHN1Y2ggYXMs IHRoZSBkZWxheSBtdXN0IGJlIGxlc3MgdGhhbiAwLjVtcyAoUkZDMTEyMikuDQoNCkkgYmVsaWV2 ZSB0aGUgMjAwbXMgZmlndXJlIGlzIGR1ZSB0byBoaXN0b3JpY2FsIHJlYXNvbnMuIEFGQUlLIGl0 J3MgZHVlIHRvIHRoZSBCU0QgZGVsYXllZCBBQ0sgYmVoYXZpb3IgKHNlZSBTdGV2ZW5zICJUQ1Av SVAgSWxsdXN0cmF0ZWQgVm9sdW1lIDIiLCBzZWN0aW9uIDI1LjQgYW5kIGZpZ3VyZSAyNS43LCB3 aGljaCBkZXNjcmliZXMgdGhlIDIwMG1zIGRlbGF5ZWQgQUNLIHRpbWVyKS4gVGhlbiB0aGlzIHZh bHVlIHdhcyBpbmhlcml0ZWQgYnkgb3RoZXIgd2lkZWx5LWRlcGxveWVkIE9TZXMuDQoNCg0KSSB0 aGluayB0aGUgZGVsYXllZCBBQ0sgaGFzIGEgY2xvc2UgcmVsYXRpb25zaGlwIHdpdGggUlRPLiBU YWtlIGFuIGV4dHJlbWUgc2NlbmFyaW8sIGlmIHRoZSBkZWxheSBpcyBsb25nZXIgdGhhbiBSVE8s IG1hbnkgcGFja2V0cyB3aWxsIGJlIHJldHJhbnNtaXR0ZWQsIHdoaWNoIHdpbGwgd2FzdGUgbWFu eSBuZXR3b3JrIHJlc291cmNlcy4NCg0KWWVzLCBleGFjdGx5LiBJbiB0aGVvcnksIHRoZSBSVE8g dHJpZXMgdG8gYmUgYWRhcHRpdmUgZW5vdWdoIHRvIG1lYXN1cmUgYW55IFJUVCB2YXJpYXRpb25z IGNhdXNlZCBieSBkZWxheWVkIEFDS3MsIGFuZCBpbmNyZWFzZSB0aGUgUlRPIGluIHJlc3BvbnNl IHRvIHRoaXMuIEhvd2V2ZXIsIGl0J3MgcXVpdGUgZWFzeSBmb3IgYSBidWxrIHRyYW5zZmVyIHRv IG5ldmVyIGhhdmUgYW55IGRlbGF5ZWQgQUNLcyBmb3IgbW9zdCBvZiBpdHMgbGlmZXRpbWUsIGR1 cmluZyB3aGljaCB0aGUgUlRPIGdyYWR1YWxseSBjb252ZXJnZXMgdG93YXJkIHRoZSByYXcgUlRU IHZhbHVlLiBUaGVuIHdoZW4gdGhlcmUgaXMgc3VkZGVubHkgYSBkZWxheWVkIEFDSywgdGhlcmUg Y2FuIGJlIGEgc3B1cmlvdXMgUlRPLg0KDQpUbyBhdm9pZCB0aGF0LCBtYW55IFRDUCBzdGFja3Mg KGF0IGxlYXN0IHRoZSBtYWpvciBvcGVuIHNvdXJjZSBPU2VzKSBoYXZlIGEgaGFyZC1jb2RlZCAy MDBtcyAic2xvcCBmYWN0b3IiIG9yICJmdWRnZSBmYWN0b3IiLCB0byB0cnkgdG8gbmV2ZXIgbGV0 IHRoZWlyIGVzdGltYXRlIG9mIFJUVCB2YXJpYXRpb24gZmFsbCBiZWxvdyB0aGF0IDIwMG1zIHZh bHVlLCB0byBhdm9pZCB0aGlzIGVmZmVjdC4NCg0KU28gSSB3YW50IHRvIGtub3cgZG8gd2UgaGF2 ZSBzb21lIFJGQ3MgaGF2ZSBnaXZlbiB0aGUgZXhhY3QgdmFsdWUgb2YgYm90aD8gQW5kIGlmIHdl IHBlcm1pdCBhbnkgVENQIHN0YWNrIHRvIHNldCB0aGVtIGZyZWVseSwgd2hhdCBpcyB0aGUgbWVj aGFuaXNtIHRvIGJhbGFuY2UgdGhlIG1pc21hdGNoIGJldHdlZW4gUlRPIGFuZCBkZWxheWVkIEFD Sz8NCg0KSSdtIG5vdCBhd2FyZSBvZiBSRkMgc3BlY2lmaWNhdGlvbnMgZm9yIGV4YWN0IHZhbHVl cyBvZiBib3RoIChkZWxheWVkIEFDSyBhbmQgUlRPKS4gSG93ZXZlciwgdGhlIGhpc3RvcmljYWwg cHJlY2VkZW50IGlzIHZlcnkgc3Ryb25nLCBhbmQgdGhlIDIwMG1zIGRlbGF5ZWQgQUNLIHZhbHVl IHdhcyB2ZXJ5IHByb25vdW5jZWQgaW4gSW50ZXJuZXQgdHJhY2VzIGF0IGxlYXN0IGFzIHJlY2Vu dGx5IGFzIDIwMTEsIHdoZW4gSSBsYXN0IGxvb2tlZCBhdCB0aGUgZWZmZWN0LiAoUHJvYmFibHkg b3RoZXJzIGhhdmUgbW9yZSByZWNlbnQgZGF0YSBwb2ludHMgZm9yIHRoZSBwcmV2YWxlbmNlIG9m IDIwMG1zIGRlbGF5ZWQgQUNLcy4pDQoNCkF0IElFVEYgOTcgb3VyIHRlYW0gYXQgR29vZ2xlIHBy ZXNlbnRlZCBzb21lIGZlYXR1cmVzIHdlIHVzZSBmb3IgaW50ZXJuYWwgVENQIHRyYWZmaWMgYXQg R29vZ2xlLCB3aGVyZSB0aGUgZW5kcG9pbnRzIGNhbiBuZWdvdGlhdGUgdGhlIHNwZWNpZmljIGNv bnN0YW50IHRvIHVzZSBmb3IgdGhlIG1heGltdW0gZGVsYXllZCBBQ0sgZnJvbSB0aGUgcmVjZWl2 ZXIgYW5kIHRoZSBjb3JyZXNwb25kaW5nIG1pbmltdW0gUlRUIGRlbGF5IHZhcmlhdGlvbiBmb3Ig YnVkZ2V0aW5nIGluIHRoZSBSVE8gYXQgdGhlIHNlbmRlcjoNCg0KICBodHRwczovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVzLTk3LXRjcG0tdGNwLW9wdGlvbnMtZm9y LWxvdy1sYXRlbmN5LTAwLnBkZg0KDQpBcyB0aGlzIHNsaWRlIGRlY2sgbm90ZXMsIHdpdGhpbiBH b29nbGUgd2UgbmVnb3RpYXRlIDVtcyBmb3IgZGVsYXllZCBBQ0tzLg0KDQpjaGVlcnMsDQpuZWFs DQoNCg== --_000_A747A0713F56294D8FBE33E5C6B8F5815F545E28DGGEMA502MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgTmVhbCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZv ciB5b3VyIHByb3ZpZGluZyByZXF1ZXN0IGluZm9ybWF0aW9uLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFib3V0IHRo ZSBkZWxheSBvZiBkZWxheWVkIEFDSywgSSBmb3VuZCBhbm90aGVyIGNsdWUgaW4gYSBTSUdDT01N IHBhcGVyIGluIDE5ODguIEluIHRoZSBwYWdlIDE0LCBhIHNlbnRlbmNlIGlzIOKAnFRoZSA0LjVL QnBzIHNlbmRlcnMgd2VyZSB0YWxraW5nIHRvIDQuM0JTRCByZWNlaXZlcnMgd2hpY2ggd291bGQN CiBkZWxheSBhbiBhY2sgdW50aWwgMzUlIG9mIHRoZSB3aW5kb3cgd2FzIGZpbGxlZCBvciAyMDAg bXMgaGFkIHBhc3NlZCAoaS5lLiwgYW4gYWNrIHdhcyBkZWxheWVkIGZvciA1LTcgcGFja2V0cyBv biBhdmVyYWdlKS7igJ0gVGhlcmUgaXMgbm8gcmVmZXJlbmNlIGFib3V0IHRoZSAyMDAgbXMsIHNv IEkgZ3Vlc3MgdGhpcyBpcyB0aGUgcGFydGljdWxhciBkZWxheSBhcHBlYXJzIGZvciB0aGUgZmly c3QgdGltZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SSB0cnkgdG8gY2FsY3VsYXRlIHRoZSB2YWx1ZSBiYXNlZCBvbiBkZWxheWVk IHBhY2tldCBudW1iZXJzLCBwYWNrZXQgc2l6ZSBhbmQgc2VuZGluZyByYXRlLiBJbiB0aGlzIGNh c2UsIHRoZSBkZWxheWVkIHBhY2tldCBudW1iZXIgaXMgNywgdGhlIHBhY2tldCBzaXplIGlzIDU3 NkJ5dGUgKHJlZmVyIHRvDQogUkZDODc5IGluIDE5ODMpLCBhbmQgc3VuZGVyaW5nIHJhdGUgaXMg NC41QnBzLiBUaGUgdmFsdWUgaXMgODk2IG1zISBMb25nZXIgdGhhbiAyMDAgbXMuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jmd0Ozwvc3Bhbj4uIEhvd2V2ZXIsIGl0J3MgcXVpdGUgZWFzeSBmb3IgYSBidWxrIHRyYW5z ZmVyIHRvIG5ldmVyIGhhdmUgYW55IGRlbGF5ZWQgQUNLcyBmb3IgbW9zdCBvZiBpdHMgbGlmZXRp bWUsIGR1cmluZyB3aGljaCB0aGUgUlRPIGdyYWR1YWxseSBjb252ZXJnZXMgdG93YXJkIHRoZSBy YXcgUlRUIHZhbHVlLg0KIFRoZW4gd2hlbiB0aGVyZSBpcyBzdWRkZW5seSBhIGRlbGF5ZWQgQUNL LCB0aGVyZSBjYW4gYmUgYSBzcHVyaW91cyBSVE8uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gbm90IHZlcnkgc3VyZSBpZiBJIHNlZSB5b3Vy IHBvaW50LiBJIHRoaW5rIHRoZSBrZXkgcG9pbnQgaXMgdGhlIFJUVCB2YXJpYXRpb24gd2lsbCBi ZSB3ZWFrZW5lZCB3aGVuIHBhY2tldHMgYXJlIHNlbnQgaW4gYSBidXJzdCAodGhlIGNvbnNlcXVl bmNlIG9mIGRlbGF5ZWQgQUNLKS4gJm5ic3A7Jm5ic3A7QW5kIHRoZQ0KIHNwdXJpb3VzICZuYnNw O2NvdWxkIG9ubHkgaGFwcGVuIGZvciB0aGUgbGFzdCBmZXcgcGFja2V0cyB3aG9zZSBudW1iZXIg aXMgc21hbGxlciB0aGFuIGRlbGF5ZWQgcGFja2V0cywgcmlnaHQ/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWJvdXQg eW91ciBwcm9wb3NhbCBhYm91dCBuZWdvdGlhdGlvbiBvZiBkZWxheWVkIEFDSywgYSBwb3RlbnRp YWwgcHJvYmxlbSBpcyB0aGF0IFJUTyB3aWxsIGJlIHN0cmV0Y2hlZCB0aGFuIGJlZm9yZSBiZWNh dXNlIHlvdSBhZGQgZXh0cmEgZGVsYXkuIEFzIHlvdSBoYXZlIHNhaWQsDQogbW9zdCBvZiB0aGUg cGFja2V0cyB3aWxsIG5vdCBleGNlZWQgUlRPIGV2ZW4gaG9zdCBlbmFibGUgZGVsYXllZCBBQ0sg Zm9yIG1vc3QgbGFyZ2UgZmxvd3MsIGJ1dCB0aGUgcmV0cmFuc21pc3Npb24gd2lsbCBiZSBkZWxh eWVkIChpLmUuLCA1bXMpYWxzbyBvbmNlIG9uZSBwYWNrZXQgaXMgbG9zdC4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ WWFsaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssc2Fucy1zZXJpZiI+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBOZWFs IENhcmR3ZWxsDQogW21haWx0bzpuY2FyZHdlbGxAZ29vZ2xlLmNvbV0gPGJyPg0KPGI+PHNwYW4g bGFuZz0iWkgtQ04iPuWPkemAgeaXtumXtDwvc3Bhbj46PC9iPiAyMDE2PHNwYW4gbGFuZz0iWkgt Q04iPuW5tDwvc3Bhbj4xMjxzcGFuIGxhbmc9IlpILUNOIj7mnIg8L3NwYW4+MTM8c3BhbiBsYW5n PSJaSC1DTiI+5pelPC9zcGFuPiAyMzoxODxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7mlLbk u7bkuro8L3NwYW4+OjwvYj4gemhhbmd5YWxpIChEKSAmbHQ7emhhbmd5YWxpMzY5QGh1YXdlaS5j b20mZ3Q7PGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaKhOmAgTwvc3Bhbj46PC9iPiB0Y3Bt QGlldGYub3JnPGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuS4u+mimDwvc3Bhbj46PC9iPiBS ZTogW3RjcG1dIEEgcXVlc3Rpb24gYWJvdXQgRGVsYXllZCBBQ0sgYW5kIFJUTzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgMTMs IDIwMTYgYXQgMzo1OCBBTSwgemhhbmd5YWxpIChEKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpoYW5n eWFsaTM2OUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+emhhbmd5YWxpMzY5QGh1YXdlaS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+UmVjZW50IGRheXMsIEkgYW0gZG9pbmcgc29tZSBzaW11bGF0aW9uIGFib3V0IFRDUCBw ZXJmb3JtYW5jZSBpbiBOUzMuIEkgZm91bmQgYSBwaGVub21lbm9uIGlzIGEgZGVmYXVsdCBzZXR0 aW5nIG9mIFRDUOKAmXMgZGVsYXllZCBBQ0sgaXMgdHdvIHBhY2tldHMgb3IgMjAwbXMuIEkgYW0g d29uZGVyaW5nIGlmIHRoaXMNCiBzZXR0aW5nIGlzIGFjY29yZCB3aXRoICZuYnNwO3NvbWUgUkZD cyBpbiBJRVRGLiBCdXQgQWZ0ZXIgSSByZWZlcnJlZCB0byBzb21lIFJGQ3MsIEkganVzdCBmb3Vu ZCBzb21lIHJlc3RyaWN0aW9ucywgc3VjaCBhcywgdGhlIGRlbGF5IG11c3QgYmUgbGVzcyB0aGFu IDAuNW1zIChSRkMxMTIyKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhlIDIwMG1z IGZpZ3VyZSBpcyBkdWUgdG8gaGlzdG9yaWNhbCByZWFzb25zLiBBRkFJSyBpdCdzIGR1ZSB0byB0 aGUgQlNEIGRlbGF5ZWQgQUNLIGJlaGF2aW9yIChzZWUgU3RldmVucyAmcXVvdDtUQ1AvSVAgSWxs dXN0cmF0ZWQgVm9sdW1lIDImcXVvdDssIHNlY3Rpb24gMjUuNCBhbmQgZmlndXJlIDI1LjcsIHdo aWNoIGRlc2NyaWJlcyB0aGUgMjAwbXMgZGVsYXllZCBBQ0sgdGltZXIpLiBUaGVuIHRoaXMgdmFs dWUNCiB3YXMgaW5oZXJpdGVkIGJ5IG90aGVyIHdpZGVseS1kZXBsb3llZCBPU2VzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5rIHRoZSBkZWxheWVkIEFDSyBoYXMgYSBjbG9zZSBy ZWxhdGlvbnNoaXAgd2l0aCBSVE8uIFRha2UgYW4gZXh0cmVtZSBzY2VuYXJpbywgaWYgdGhlIGRl bGF5IGlzIGxvbmdlciB0aGFuIFJUTywgbWFueSBwYWNrZXRzIHdpbGwgYmUgcmV0cmFuc21pdHRl ZCwgd2hpY2ggd2lsbCB3YXN0ZSBtYW55IG5ldHdvcmsNCiByZXNvdXJjZXMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WWVzLCBleGFjdGx5LiBJbiB0aGVvcnksIHRoZSBSVE8gdHJpZXMgdG8gYmUgYWRh cHRpdmUgZW5vdWdoIHRvIG1lYXN1cmUgYW55IFJUVCB2YXJpYXRpb25zIGNhdXNlZCBieSBkZWxh eWVkIEFDS3MsIGFuZCBpbmNyZWFzZSB0aGUgUlRPIGluIHJlc3BvbnNlIHRvIHRoaXMuIEhvd2V2 ZXIsIGl0J3MgcXVpdGUgZWFzeSBmb3IgYSBidWxrIHRyYW5zZmVyIHRvIG5ldmVyIGhhdmUgYW55 IGRlbGF5ZWQgQUNLcyBmb3INCiBtb3N0IG9mIGl0cyBsaWZldGltZSwgZHVyaW5nIHdoaWNoIHRo ZSBSVE8gZ3JhZHVhbGx5IGNvbnZlcmdlcyB0b3dhcmQgdGhlIHJhdyBSVFQgdmFsdWUuIFRoZW4g d2hlbiB0aGVyZSBpcyBzdWRkZW5seSBhIGRlbGF5ZWQgQUNLLCB0aGVyZSBjYW4gYmUgYSBzcHVy aW91cyBSVE8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRvIGF2b2lkIHRoYXQsIG1hbnkgVENQIHN0YWNrcyAoYXQgbGVhc3QgdGhlIG1ham9y IG9wZW4gc291cmNlIE9TZXMpIGhhdmUgYSBoYXJkLWNvZGVkIDIwMG1zICZxdW90O3Nsb3AgZmFj dG9yJnF1b3Q7IG9yICZxdW90O2Z1ZGdlIGZhY3RvciZxdW90OywgdG8gdHJ5IHRvIG5ldmVyIGxl dCB0aGVpciBlc3RpbWF0ZSBvZiBSVFQgdmFyaWF0aW9uIGZhbGwgYmVsb3cgdGhhdCAyMDBtcyB2 YWx1ZSwgdG8gYXZvaWQgdGhpcyBlZmZlY3QuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TbyBJ IHdhbnQgdG8ga25vdyBkbyB3ZSBoYXZlIHNvbWUgUkZDcyBoYXZlIGdpdmVuIHRoZSBleGFjdCB2 YWx1ZSBvZiBib3RoPyBBbmQgaWYgd2UgcGVybWl0IGFueSBUQ1Agc3RhY2sgdG8gc2V0IHRoZW0g ZnJlZWx5LCB3aGF0IGlzIHRoZSBtZWNoYW5pc20gdG8gYmFsYW5jZSB0aGUgbWlzbWF0Y2ggYmV0 d2Vlbg0KIFJUTyBhbmQgZGVsYXllZCBBQ0s/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBh d2FyZSBvZiBSRkMgc3BlY2lmaWNhdGlvbnMgZm9yIGV4YWN0IHZhbHVlcyBvZiBib3RoIChkZWxh eWVkIEFDSyBhbmQgUlRPKS4gSG93ZXZlciwgdGhlIGhpc3RvcmljYWwgcHJlY2VkZW50IGlzIHZl cnkgc3Ryb25nLCBhbmQgdGhlIDIwMG1zIGRlbGF5ZWQgQUNLIHZhbHVlIHdhcyB2ZXJ5IHByb25v dW5jZWQgaW4gSW50ZXJuZXQgdHJhY2VzIGF0IGxlYXN0IGFzIHJlY2VudGx5IGFzIDIwMTEsIHdo ZW4NCiBJIGxhc3QgbG9va2VkIGF0IHRoZSBlZmZlY3QuIChQcm9iYWJseSBvdGhlcnMgaGF2ZSBt b3JlIHJlY2VudCBkYXRhIHBvaW50cyBmb3IgdGhlIHByZXZhbGVuY2Ugb2YgMjAwbXMgZGVsYXll ZCBBQ0tzLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXQgSUVURiA5NyBvdXIgdGVhbSBhdCBHb29nbGUgcHJlc2VudGVkIHNvbWUgZmVhdHVy ZXMgd2UgdXNlIGZvciBpbnRlcm5hbCBUQ1AgdHJhZmZpYyBhdCBHb29nbGUsIHdoZXJlIHRoZSBl bmRwb2ludHMgY2FuIG5lZ290aWF0ZSB0aGUgc3BlY2lmaWMgY29uc3RhbnQgdG8gdXNlIGZvciB0 aGUgbWF4aW11bSBkZWxheWVkIEFDSyBmcm9tIHRoZSByZWNlaXZlciBhbmQgdGhlIGNvcnJlc3Bv bmRpbmcgbWluaW11bQ0KIFJUVCBkZWxheSB2YXJpYXRpb24gZm9yIGJ1ZGdldGluZyBpbiB0aGUg UlRPIGF0IHRoZSBzZW5kZXI6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVzLTk3LXRjcG0tdGNwLW9wdGlvbnMtZm9yLWxvdy1sYXRl bmN5LTAwLnBkZiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9zbGlkZXMv c2xpZGVzLTk3LXRjcG0tdGNwLW9wdGlvbnMtZm9yLWxvdy1sYXRlbmN5LTAwLnBkZjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgdGhp cyBzbGlkZSBkZWNrIG5vdGVzLCB3aXRoaW4gR29vZ2xlIHdlIG5lZ290aWF0ZSA1bXMgZm9yIGRl bGF5ZWQgQUNLcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Y2hlZXJzLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+bmVhbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A747A0713F56294D8FBE33E5C6B8F5815F545E28DGGEMA502MBSchi_-- From nobody Wed Dec 14 05:24:18 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF9A12965E for ; Wed, 14 Dec 2016 05:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0UHYo-43wB8 for ; Wed, 14 Dec 2016 05:24:13 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC96129662 for ; Wed, 14 Dec 2016 05:24:12 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id w63so19856538oiw.0 for ; Wed, 14 Dec 2016 05:24:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=celY/n7VQPOb7Hrz7XkkQQCPfFrZiTej0y5kN1ds7A0=; b=k6kQb6q1rX9Qe8KzM4DplA9W22T24r0OTMxa5b0HjesYFgZ3tsK2vdMnbhTRCc2W8e EL6UWjsgbkoCmtP4nNrVoP58Edo7AsPBiQflT4zKPRuL54KqcvaUbOczoOYBD4Kk/yvf PMSq9FnupbbJmOd7zmWx/HlBaiySsPh4KmRl4LJ+qKWOZQggC2Hg25HCN82h7C0A9HYC GomWsbdXP70U/wiA4WWsQGI1VgaPnMzlZ/h2jiPL4UhkM/UU2j8vAcyyaKf5imVWYQ2M CU15Di+AwBCyp54HCVLDfGePZNyY1uz9eEHlGpK/PyjmU1hL5PGw9tdnkfpksJ8ldH8e 0V/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=celY/n7VQPOb7Hrz7XkkQQCPfFrZiTej0y5kN1ds7A0=; b=RFI5WwvleWYisvReEPjyaLCG1VaT2q4bmx3BPtp1bBFZYTxfeuA+wgfIrwi4jOn1XR e5x2/1Lwszk1M/cLcNmHpJU13IVrjAfGU1N3UeEXgTLKrjuBEnvykt6uTqIZrYF8IEkp ndQwP2eHqM2iFZMO6QOr5voipWBXh6FhGHf7s2ytYiQeziFCxCHOKneZcMSrsp74MTcJ jUtGF1zKUM9jogS/SRYW47QU4RMRQuRyJHRbXRgxSTvf3xaGW2Ox5rOn8kq5RhjJhWue xjuhz28GZshlKBwmsWrM1wqC/5VVQbXXdzEwFHm2A1ZYgAMxuZFZL2nQ6tIX8CPMfy9A wmqA== X-Gm-Message-State: AKaTC0284PE76zue+94WDrn3uvtd76yLSQiaNfaxGN+ezb3AWo8EczZFaoxHVwBU878QwA1EmiADzB/ILv4FQgDc X-Received: by 10.157.20.142 with SMTP id d14mr54499322ote.74.1481721852040; Wed, 14 Dec 2016 05:24:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.240.213 with HTTP; Wed, 14 Dec 2016 05:23:41 -0800 (PST) In-Reply-To: References: From: Neal Cardwell Date: Wed, 14 Dec 2016 08:23:41 -0500 Message-ID: To: "zhangyali (D)" Content-Type: multipart/alternative; boundary=001a1135cefca612ca05439e4032 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiAgQSBxdWVzdGlvbiBhYm91dCBEZWxheWVkIEFD?= =?utf-8?q?K_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Dec 2016 13:24:17 -0000 --001a1135cefca612ca05439e4032 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) wrote: > Hi Neal, > > > > Thanks for your providing request information. > > > > About the delay of delayed ACK, I found another clue in a SIGCOMM paper i= n > 1988. In the page 14, a sentence is =E2=80=9CThe 4.5KBps senders were tal= king to > 4.3BSD receivers which would delay an ack until 35% of the window was > filled or 200 ms had passed (i.e., an ack was delayed for 5-7 packets on > average).=E2=80=9D There is no reference about the 200 ms, so I guess thi= s is the > particular delay appears for the first time. > > I try to calculate the value based on delayed packet numbers, packet size > and sending rate. In this case, the delayed packet number is 7, the packe= t > size is 576Byte (refer to RFC879 in 1983), and sundering rate is 4.5Bps. > The value is 896 ms! Longer than 200 ms. > > > > >. However, it's quite easy for a bulk transfer to never have any delayed > ACKs for most of its lifetime, during which the RTO gradually converges > toward the raw RTT value. Then when there is suddenly a delayed ACK, ther= e > can be a spurious RTO. > > I am not very sure if I see your point. I think the key point is the RTT > variation will be weakened when packets are sent in a burst (the > consequence of delayed ACK). And the spurious could only happen for th= e > last few packets whose number is smaller than delayed packets, right? > Yes, there should only be a delayed ACK at the end of an application chunk if there is an odd number of packets. But we would expect roughly half of application chunks to have an odd number of packets. Though the proportion is probably higher than that, since many application chunks are just one packet (e.g. an HTTP or RPC request or response). > About your proposal about negotiation of delayed ACK, a potential problem > is that RTO will be stretched than before because you add extra delay. As > you have said, most of the packets will not exceed RTO even host enable > delayed ACK for most large flows, but the retransmission will be delayed > (i.e., 5ms)also once one packet is lost. > The basic idea of the proposal is to tweak the RTO calculation and turn a previously existing, historically motivated 200ms fixed "slop factor" into a dynamically negotiated 5ms "slop factor". In our experience that is almost always a win. neal > > > Best, > > Yali > > *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* Neal Cardwell [mailto:ncardwell@google.c= om] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2016=E5=B9=B412=E6=9C=8813=E6=97= =A5 23:18 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* zhangyali (D) > *=E6=8A=84=E9=80=81:* tcpm@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: [tcpm] A question about Delayed ACK and RTO > > > > On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) > wrote: > > Hi all, > > > > Recent days, I am doing some simulation about TCP performance in NS3. I > found a phenomenon is a default setting of TCP=E2=80=99s delayed ACK is t= wo packets > or 200ms. I am wondering if this setting is accord with some RFCs in IET= F. > But After I referred to some RFCs, I just found some restrictions, such a= s, > the delay must be less than 0.5ms (RFC1122). > > > > I believe the 200ms figure is due to historical reasons. AFAIK it's due t= o > the BSD delayed ACK behavior (see Stevens "TCP/IP Illustrated Volume 2", > section 25.4 and figure 25.7, which describes the 200ms delayed ACK timer= ). > Then this value was inherited by other widely-deployed OSes. > > > > > > I think the delayed ACK has a close relationship with RTO. Take an extrem= e > scenario, if the delay is longer than RTO, many packets will be > retransmitted, which will waste many network resources. > > > > Yes, exactly. In theory, the RTO tries to be adaptive enough to measure > any RTT variations caused by delayed ACKs, and increase the RTO in respon= se > to this. However, it's quite easy for a bulk transfer to never have any > delayed ACKs for most of its lifetime, during which the RTO gradually > converges toward the raw RTT value. Then when there is suddenly a delayed > ACK, there can be a spurious RTO. > > > > To avoid that, many TCP stacks (at least the major open source OSes) have > a hard-coded 200ms "slop factor" or "fudge factor", to try to never let > their estimate of RTT variation fall below that 200ms value, to avoid thi= s > effect. > > > > So I want to know do we have some RFCs have given the exact value of both= ? > And if we permit any TCP stack to set them freely, what is the mechanism = to > balance the mismatch between RTO and delayed ACK? > > > > I'm not aware of RFC specifications for exact values of both (delayed ACK > and RTO). However, the historical precedent is very strong, and the 200ms > delayed ACK value was very pronounced in Internet traces at least as > recently as 2011, when I last looked at the effect. (Probably others have > more recent data points for the prevalence of 200ms delayed ACKs.) > > > > At IETF 97 our team at Google presented some features we use for internal > TCP traffic at Google, where the endpoints can negotiate the specific > constant to use for the maximum delayed ACK from the receiver and the > corresponding minimum RTT delay variation for budgeting in the RTO at the > sender: > > > > https://www.ietf.org/proceedings/97/slides/slides- > 97-tcpm-tcp-options-for-low-latency-00.pdf > > > > As this slide deck notes, within Google we negotiate 5ms for delayed ACKs= . > > > > cheers, > > neal > > > --001a1135cefca612ca05439e4032 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 14, 2016 at 4:48 AM, zhangyali (D) <zhangyali369@huawei.com<= /a>> wrote:

Hi Neal,

=C2=A0

Thanks for your providing request information.

=C2=A0

About the delay of delayed ACK, I found another clue i= n a SIGCOMM paper in 1988. In the page 14, a sentence is =E2=80=9CThe 4.5KB= ps senders were talking to 4.3BSD receivers which would delay an ack until 35% of the window was filled or 200 ms had passed (i.e.= , an ack was delayed for 5-7 packets on average).=E2=80=9D There is no refe= rence about the 200 ms, so I guess this is the particular delay appears for= the first time.

I try to calculate the value based on delayed packet n= umbers, packet size and sending rate. In this case, the delayed packet numb= er is 7, the packet size is 576Byte (refer to RFC879 in 1983), and sundering rate is 4.5Bps. The value is 896 ms! Longer= than 200 ms.

=C2=A0

>. However, it's quite easy for a bulk t= ransfer to never have any delayed ACKs for most of its lifetime, during whi= ch the RTO gradually converges toward the raw RTT value. Then when there is suddenly a delayed ACK, there can be a spurious RTO.=

I am not very sure if I see your point. I think= the key point is the RTT variation will be weakened when packets are sent = in a burst (the consequence of delayed ACK). =C2=A0=C2=A0And the spurious =C2=A0could only happen for the last few packets whose number is = smaller than delayed packets, right?



The basic idea of the proposal is to tweak the RTO calculation and turn a= previously existing, historically motivated 200ms fixed "slop factor&= quot; into a dynamically negotiated 5ms "slop factor". In our exp= erience that is almost always a win.

=C2=A0

=C2=A0

Best,

Yali

=E5=8F=91=E4= =BB=B6=E4=BA=BA: Neal Cardwell [mailto:ncardwel= l@google.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 20= 16=E5=B9=B412=E6=9C=8813=E6=97=A5 23:18
=E6=94=B6=E4=BB=B6=E4=BA=BA: zhangyali (= D) <zhangya= li369@huawei.com>
=E6=8A=84=E9=80=81: tcpm@ietf.org
=E4=B8=BB=E9=A2=98: Re: [tcpm] A questio= n about Delayed ACK and RTO

=C2=A0

On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) <<= a href=3D"mailto:zhangyali369@huawei.com" target=3D"_blank">zhangyali369@hu= awei.com> wrote:

Hi all,

=C2=A0

Recent days, I am doing some simulation about TCP pe= rformance in NS3. I found a phenomenon is a default setting of TCP=E2=80=99= s delayed ACK is two packets or 200ms. I am wondering if this setting is accord with =C2=A0some RFCs in IETF. But After I referred to so= me RFCs, I just found some restrictions, such as, the delay must be less th= an 0.5ms (RFC1122).

=C2=A0

I believe the 200ms figure is due to historical reas= ons. AFAIK it's due to the BSD delayed ACK behavior (see Stevens "= TCP/IP Illustrated Volume 2", section 25.4 and figure 25.7, which desc= ribes the 200ms delayed ACK timer). Then this value was inherited by other widely-deployed OSes.

=C2=A0

=C2=A0=C2=A0

I think the delayed ACK has a close relationship wit= h RTO. Take an extreme scenario, if the delay is longer than RTO, many pack= ets will be retransmitted, which will waste many network resources.

=C2=A0

Yes, exactly. In theory, the RTO tries to be adaptiv= e enough to measure any RTT variations caused by delayed ACKs, and increase= the RTO in response to this. However, it's quite easy for a bulk trans= fer to never have any delayed ACKs for most of its lifetime, during which the RTO gradually converges toward the = raw RTT value. Then when there is suddenly a delayed ACK, there can be a sp= urious RTO.

=C2=A0

To avoid that, many TCP stacks (at least the major o= pen source OSes) have a hard-coded 200ms "slop factor" or "f= udge factor", to try to never let their estimate of RTT variation fall= below that 200ms value, to avoid this effect.=C2=A0

=C2=A0

So I want to know do we have some RFCs have given th= e exact value of both? And if we permit any TCP stack to set them freely, w= hat is the mechanism to balance the mismatch between RTO and delayed ACK?

=C2=A0

I'm not aware of RFC specifications for exact va= lues of both (delayed ACK and RTO). However, the historical precedent is ve= ry strong, and the 200ms delayed ACK value was very pronounced in Internet = traces at least as recently as 2011, when I last looked at the effect. (Probably others have more recent data points= for the prevalence of 200ms delayed ACKs.)

=C2=A0

At IETF 97 our team at Google presented some feature= s we use for internal TCP traffic at Google, where the endpoints can negoti= ate the specific constant to use for the maximum delayed ACK from the recei= ver and the corresponding minimum RTT delay variation for budgeting in the RTO at the sender:<= /p>

=C2=A0

=C2=A0

As this slide deck notes, within Google we negotiate= 5ms for delayed ACKs.

=C2=A0

cheers,=C2=A0

neal

=C2=A0


--001a1135cefca612ca05439e4032-- From nobody Wed Dec 14 08:42:37 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BB112962F for ; Wed, 14 Dec 2016 08:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo3iwEep4T6f for ; Wed, 14 Dec 2016 08:42:34 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B61129418 for ; Wed, 14 Dec 2016 08:42:33 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id y198so26170693oia.1 for ; Wed, 14 Dec 2016 08:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=39kXskXmPtMrKes4esCqO9q1rHpZDgFaFSeRieAJZ2o=; b=j12mosDdCIe/eIGOWQ06IMbEGfs6RyH1Ao8LMqprPMOqvOIQ6X8vBPCiWHNZOF8QDO IggR8xSNr6SgvnAsmLlKdlH5DXF2ofDQZBr+66JmRJZGYF0bZd9v3kr73QxNxgFw1RaD SU17TvdJyhfvNjnGuaQN1YHiNd3A7poBYPjD4/4tVcG2nkcHfJ5dRqV9nMTPz0+1iiIj FK6sHnZvtkYmuiufxuk1p3I+5Z2Yf5fYvnHJs/OGt97W/s6HPu6yab+O63txRxs1C6Ef DNN82eU4TmsqwNu8afMUf6R7i/U8qwlULyAHiTFfcp7VRT7K2YSYsxY5Gar13PXYn+uI rUjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=39kXskXmPtMrKes4esCqO9q1rHpZDgFaFSeRieAJZ2o=; b=CbvkwTLUTf7twShw9H5KVcvq4JyPXbZgyWmIAfTunsmzb4yQN8HxYmSaIf5m3cn9yj lG36NUMXGQHPEby43CzowQeJWs4zst+Uxslg5rL3OZbWTpYOyX/Vx8ScBjezp+DKPBk4 82qfRM7hPJGAhPyn4aGwQIYEHzvToytuLBITXoqWUQ1bm00Lon3yOIxzxRgBp9nHkm1Q lVt2yo/6CBL89h17AKuSafhg6tP4L2+VZruV47ORF022zKcVWXOC8WAggkSmpIqrYqDV bSplYRIJ9MkKIIYAij3buTOWg8WUfwwUmvFGCTrsdN31GyAUs08wPrhP4Op6HrEA5QGz Dgog== X-Gm-Message-State: AKaTC01bKOcxNa4k70g9kxA9oTKTncH48+rD352aOIGlyH+LEYMKmlbbqX2d9gPvETaub/SUIYuPiEqrMfVEXVzg X-Received: by 10.157.2.36 with SMTP id 33mr61493879otb.180.1481733753118; Wed, 14 Dec 2016 08:42:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.240.213 with HTTP; Wed, 14 Dec 2016 08:42:02 -0800 (PST) In-Reply-To: References: <6b1695de-c94f-d4ef-6321-c74665432762@mti-systems.com> From: Neal Cardwell Date: Wed, 14 Dec 2016 11:42:02 -0500 Message-ID: To: Richard Scheffenegger Content-Type: multipart/alternative; boundary=94eb2c04432c01e59f0543a10665 Archived-At: Cc: "tcpm@ietf.org" , Eric Dumazet Subject: Re: [tcpm] Ref to timestamp negotiation draft (expired) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Dec 2016 16:42:36 -0000 --94eb2c04432c01e59f0543a10665 Content-Type: text/plain; charset=UTF-8 Hi Richard, Thanks for your note. Unfortunately, I've been busy with other projects recently (largely BBR) and haven't had time to read your draft on improving timestamps (draft-scheffenegger-tcpm-timestamp-negotiation-05). It looks like a very nice, thorough draft. So, rest assured that I will read it before our team embarks on any draft related to the timestamp code we are running within Google (which was written by Eric Dumazet, cc-ed). thanks, neal On Tue, Dec 13, 2016 at 4:06 AM, Richard Scheffenegger wrote: > Hi Neal, > > did you have time to glance over the timestamp negotiation draft? > > Here is a brief abstract of some of the properties that the proposed > negotiation scheme offers. However, at the time, there was too little > interest in this (and no other vendor to support development efforts) thus > it expired. > > a) no additional TCP Option space useage, particular in the initial SYN > > b) Up to 24 bits for arbitrary signalling - the draft uses 16 ( > https://tools.ietf.org/html/draft-scheffenegger-tcpm- > timestamp-negotiation-05) to signal the timestamp interval; the value is > encoded differently from a IEEE floating point representation to allow > further freedom to indicate relative precision of the injected timestamp > (ie. envision a NIC capable of hw clocking each segment in a TSO transfer, > vs. using a coarse grained software clock in a virtual host) > > c) generic mechanism to make (parts of) the timestamp useful for the > receiver, allowing the sender to weakly authenticate returned timestamps > (e.g. avoiding the cubic epoch exploit to game a sender by manipulating > timestamps) > > d) In that basic version, 8 bits would still be available to provide the > signals envisioned by your proposal for indicating Max ACK Delay - perhaps > using a shift value offset by a constant biad as for the timestamp > interval, more granualar signaling would be possible than in your proposal. > > > Drawback of the scheme: duing 3WHS, the sender needs to keep state of the > original TSval (which should be a non-issue for Linux stacks, and is > manageable for byte-oriented stacks). > > Also, a small probability of falsely activating the TS negotiation. > However, against servers on the internet, this probability is smaller than > expected as TSval still relates linearly to system uptime, in most > implementations; I've investigated this during writing intensively (not > what you could do, though) - see section 5.3 > > Re-reading, I see that my descriptive language is perhaps not clear > enough, the signals spoken about in the draft are always exchanged in a > TSecr field of a TS Option, with the TSecr of the SYN/ACK being the XOR sum > of the TSval from the SYN, plus the capabilites signal of the receiver... > > Best regards, > Richard > > > > > Great. Thanks, Bob. We'll take a look at these... > > neal > > On Wed, Nov 16, 2016 at 9:59 AM, Bob Briscoe wrote: > > > Neil, [re-sending from correct address, so it is acceptable to the tcpm > > list] > > > > As promised in the discussion just now about your timer negotiation talk > > in tcpm, here's the previous draft on a similar subject: > > Additional negotiation in the TCP Timestamp Option field during the TCP > > handshake > > timestamp-negotiation-05> > > > > This was originally prompted by the research here (see section 3.1 for > the > > timestamp discussion), which you might also be interested in: > > Chirping for Congestion Control - Implementation Feasibility > > > > > > > > > > Bob > > > > PS. I can recommend a good search engine to find stuff like this :) > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > > --94eb2c04432c01e59f0543a10665 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Richard,

Thanks for your note. Unfortunately, I= 've been busy with other projects recently (largely BBR) and haven'= t had time to read your draft on improving timestamps (draft-scheffenegger-= tcpm-timestamp-negotiation-05). It looks like a very nice, thorough draft. = So, rest assured that I will read it before our team embarks on any draft r= elated to the timestamp code we are running within Google (which was writte= n by Eric Dumazet, cc-ed).

thanks,
neal<= /div>


On Tue, Dec 13, 2016 at 4:06 AM, Richard Scheffenegger <rs.ietf@gm= x.at> wrote:
Hi Neal,
=C2=A0
did you have time to glance over the t= imestamp=20 negotiation draft?
=C2=A0
Here is a brief abstract of some of th= e properties=20 that the proposed negotiation scheme offers. However, at the time, there wa= s too=20 little interest in this (and no other vendor to support development efforts= )=20 thus it expired.
=C2=A0
a) no additional TCP Option space usea= ge,=20 particular in the initial SYN
=C2=A0
b) Up to 24 bits for arbitrary signall= ing - the=20 draft uses 16 (https://tools.ietf.org/html= /draft-scheffenegger-tcpm-timestamp-negotiation-05)=20 to signal the timestamp interval; the value is encoded differently from a I= EEE=20 floating point representation to allow further freedom to indicate relative= =20 precision of the injected timestamp (ie. envision a NIC capable of hw clock= ing=20 each segment in a TSO transfer, vs. using a coarse grained software clock i= n a=20 virtual host)
=C2=A0
c) generic mechanism to make (parts of= ) the=C2=A0=20 timestamp useful for the receiver, allowing the sender to weakly authentica= te=20 returned timestamps (e.g. avoiding the cubic epoch exploit to game a sender= by=20 manipulating timestamps)
=C2=A0
d) In that basic version, 8 bits would= still be=20 available to provide the signals envisioned by your proposal for indicating= Max=20 ACK Delay - perhaps using a shift value offset by a constant biad as for th= e=20 timestamp interval, more granualar signaling would be possible than in your= =20 proposal.
=C2=A0

Drawback of the scheme: duing 3WHS, the sender needs to keep state= of=20 the original TSval (which should be a non-issue for Linux stacks, and is=20 manageable for byte-oriented stacks).
=C2=A0
Also, a small probability of falsely activating the TS negotiation.=20 However, against servers on the internet, this probability is smaller than= =20 expected as TSval still relates linearly to system uptime, in most=20 implementations; I've investigated this during writing intensively (not= what you=20 could do, though) - see section 5.3
=C2=A0
Re-reading, I see that my descriptive language=C2=A0=C2=A0is perhaps n= ot=20 clear enough, the signals spoken about in the draft are always exchanged in= a=20 TSecr field of a TS Option, with the TSecr of the SYN/ACK being the XOR sum= of=20 the TSval from the SYN, plus the capabilites signal of the receiver...
=C2=A0
Best regards,
=C2=A0 Richard
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Great. Thanks, Bob. We'll take a l= ook at=20 these...
=C2=A0
neal
=C2=A0
On Wed, Nov 16, 2016 at 9:59 AM, Bob B= riscoe <ietf@bo= bbriscoe.net>=20 wrote:
=C2=A0
> Neil, [re-sending from correct ad= dress, so it=20 is acceptable to the tcpm
> list]
>
> As promised in the= =20 discussion just now about your timer negotiation talk
> in tcpm, here= 's=20 the previous draft on a similar subject:
> Additional negotiation in = the=20 TCP Timestamp Option field during the TCP
> handshake
> <https://tools.ietf.org/html/draft-scheff= enegger-tcpm-timestamp-negotiation-05>
>
>=20 This was originally prompted by the research here (see section 3.1 for=20 the
> timestamp discussion), which you might also be interested=20 in:
> Chirping for Congestion Control - Implementation Feasibility>=20 <http://www.bobbriscoe.net/pubs.html#chirp_impl>
>>
>
>=20 Bob
>
> PS. I can recommend a good search engine to find stuff = like=20 this :)
>
>
&= gt; --
>=20 ________________________________________________________________<= br>> Bob=20 Briscoe=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 http://bobbriscoe.net/=
>
>

--94eb2c04432c01e59f0543a10665-- From nobody Wed Dec 14 08:56:39 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226F3129B91 for ; Wed, 14 Dec 2016 08:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWytmIROfO2Q for ; Wed, 14 Dec 2016 08:56:35 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F8B12940E for ; Wed, 14 Dec 2016 08:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20857; q=dns/txt; s=iport; t=1481734594; x=1482944194; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3V54107+OW8hasan2zZrgKLOgOwef1j8KouPiLzK7aE=; b=IrWzV++NpQ+6BLgZHuD2Lnj6jl/E8FXRd1RPp0i1d53eXcxggsIi/iTV 9DkHXbY4A4pehjaRGRFLKSNhgoMaMy+HwdSdcEaxFG047B7Ywq0vpp/6a EF+Yk5t/Y3jezDfOJgKWb5idbxzZDmlzD5PGQITOgY9bqg5XdgKYpdXYr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBACOeFFY/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnM5CwEBAQEBH1oyVIMFikmmf4UjggkfAQyFdgIagV0/FAECAQE?= =?us-ascii?q?BAQEBAWIohGkCAgIBAQoCVwkEBxACAQYCDjEFAgIlCxQGCwIECgQFHohNDoxJn?= =?us-ascii?q?T4OgiaLDAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhj6BfYJehH6CRTaCMAWVAIV?= =?us-ascii?q?rAZEskEuOFIQOAR83PmQpDgEBgwU7HIFdcgGIMAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,347,1477958400"; d="scan'208,217";a="359014171" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2016 16:56:33 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uBEGuXW3027020 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Dec 2016 16:56:33 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 14 Dec 2016 10:56:32 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 14 Dec 2016 10:56:32 -0600 From: "Jakob Heitz (jheitz)" To: Neal Cardwell Thread-Topic: =?big5?B?W3RjcG1dILWqzmA6ICBBIHF1ZXN0aW9uIGFib3V0IERlbGF5ZWQgQUNLIGFuZCBS?= =?big5?Q?TO?= Thread-Index: AQHSVe9ZihVtZ/k7EEi0Ho/ODIoIM6EH00iA///W5BY= Date: Wed, 14 Dec 2016 16:56:32 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_F9D5899E435E417AB5D0561183AFFC92ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?big5?b?tarOYDogIEEgcXVlc3Rpb24gYWJvdXQgRGVsYXllZCBBQ0sg?= =?big5?b?YW5kIFJUTw==?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Dec 2016 16:56:37 -0000 --_000_F9D5899E435E417AB5D0561183AFFC92ciscocom_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 SGlzdG9yaWNhbGx5LCB0aGUgbWluaW11bSBSVE8gaXMgMSBzZWNvbmQgYW5kIGFjdHVhbCBSVFQg aXMgdmVyeSByYXJlbHkgbW9yZSB0aGFuIDEgc2Vjb25kLCBzbyBhbGwgdGhpcyBSVFQgY2FsY3Vs YXRpb24gaGFyZGx5IGV2ZXIgbWF0dGVycyBhbnl3YXkuDQoNClRoYW5rcywNCkpha29iLg0KDQoN Ck9uIERlYyAxNCwgMjAxNiwgYXQgNToyNCBBTSwgTmVhbCBDYXJkd2VsbCA8bmNhcmR3ZWxsQGdv b2dsZS5jb208bWFpbHRvOm5jYXJkd2VsbEBnb29nbGUuY29tPj4gd3JvdGU6DQoNCk9uIFdlZCwg RGVjIDE0LCAyMDE2IGF0IDQ6NDggQU0sIHpoYW5neWFsaSAoRCkgPHpoYW5neWFsaTM2OUBodWF3 ZWkuY29tPG1haWx0bzp6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgTmVhbCwN Cg0KVGhhbmtzIGZvciB5b3VyIHByb3ZpZGluZyByZXF1ZXN0IGluZm9ybWF0aW9uLg0KDQpBYm91 dCB0aGUgZGVsYXkgb2YgZGVsYXllZCBBQ0ssIEkgZm91bmQgYW5vdGhlciBjbHVlIGluIGEgU0lH Q09NTSBwYXBlciBpbiAxOTg4LiBJbiB0aGUgcGFnZSAxNCwgYSBzZW50ZW5jZSBpcyChp1RoZSA0 LjVLQnBzIHNlbmRlcnMgd2VyZSB0YWxraW5nIHRvIDQuM0JTRCByZWNlaXZlcnMgd2hpY2ggd291 bGQgZGVsYXkgYW4gYWNrIHVudGlsIDM1JSBvZiB0aGUgd2luZG93IHdhcyBmaWxsZWQgb3IgMjAw IG1zIGhhZCBwYXNzZWQgKGkuZS4sIGFuIGFjayB3YXMgZGVsYXllZCBmb3IgNS03IHBhY2tldHMg b24gYXZlcmFnZSkuoaggVGhlcmUgaXMgbm8gcmVmZXJlbmNlIGFib3V0IHRoZSAyMDAgbXMsIHNv IEkgZ3Vlc3MgdGhpcyBpcyB0aGUgcGFydGljdWxhciBkZWxheSBhcHBlYXJzIGZvciB0aGUgZmly c3QgdGltZS4NCkkgdHJ5IHRvIGNhbGN1bGF0ZSB0aGUgdmFsdWUgYmFzZWQgb24gZGVsYXllZCBw YWNrZXQgbnVtYmVycywgcGFja2V0IHNpemUgYW5kIHNlbmRpbmcgcmF0ZS4gSW4gdGhpcyBjYXNl LCB0aGUgZGVsYXllZCBwYWNrZXQgbnVtYmVyIGlzIDcsIHRoZSBwYWNrZXQgc2l6ZSBpcyA1NzZC eXRlIChyZWZlciB0byBSRkM4NzkgaW4gMTk4MyksIGFuZCBzdW5kZXJpbmcgcmF0ZSBpcyA0LjVC cHMuIFRoZSB2YWx1ZSBpcyA4OTYgbXMhIExvbmdlciB0aGFuIDIwMCBtcy4NCg0KPi4gSG93ZXZl ciwgaXQncyBxdWl0ZSBlYXN5IGZvciBhIGJ1bGsgdHJhbnNmZXIgdG8gbmV2ZXIgaGF2ZSBhbnkg ZGVsYXllZCBBQ0tzIGZvciBtb3N0IG9mIGl0cyBsaWZldGltZSwgZHVyaW5nIHdoaWNoIHRoZSBS VE8gZ3JhZHVhbGx5IGNvbnZlcmdlcyB0b3dhcmQgdGhlIHJhdyBSVFQgdmFsdWUuIFRoZW4gd2hl biB0aGVyZSBpcyBzdWRkZW5seSBhIGRlbGF5ZWQgQUNLLCB0aGVyZSBjYW4gYmUgYSBzcHVyaW91 cyBSVE8uDQpJIGFtIG5vdCB2ZXJ5IHN1cmUgaWYgSSBzZWUgeW91ciBwb2ludC4gSSB0aGluayB0 aGUga2V5IHBvaW50IGlzIHRoZSBSVFQgdmFyaWF0aW9uIHdpbGwgYmUgd2Vha2VuZWQgd2hlbiBw YWNrZXRzIGFyZSBzZW50IGluIGEgYnVyc3QgKHRoZSBjb25zZXF1ZW5jZSBvZiBkZWxheWVkIEFD SykuICAgQW5kIHRoZSBzcHVyaW91cyAgY291bGQgb25seSBoYXBwZW4gZm9yIHRoZSBsYXN0IGZl dyBwYWNrZXRzIHdob3NlIG51bWJlciBpcyBzbWFsbGVyIHRoYW4gZGVsYXllZCBwYWNrZXRzLCBy aWdodD8NCg0KWWVzLCB0aGVyZSBzaG91bGQgb25seSBiZSBhIGRlbGF5ZWQgQUNLIGF0IHRoZSBl bmQgb2YgYW4gYXBwbGljYXRpb24gY2h1bmsgaWYgdGhlcmUgaXMgYW4gb2RkIG51bWJlciBvZiBw YWNrZXRzLiBCdXQgd2Ugd291bGQgZXhwZWN0IHJvdWdobHkgaGFsZiBvZiBhcHBsaWNhdGlvbiBj aHVua3MgdG8gaGF2ZSBhbiBvZGQgbnVtYmVyIG9mIHBhY2tldHMuIFRob3VnaCB0aGUgcHJvcG9y dGlvbiBpcyBwcm9iYWJseSBoaWdoZXIgdGhhbiB0aGF0LCBzaW5jZSBtYW55IGFwcGxpY2F0aW9u IGNodW5rcyBhcmUganVzdCBvbmUgcGFja2V0IChlLmcuIGFuIEhUVFAgb3IgUlBDIHJlcXVlc3Qg b3IgcmVzcG9uc2UpLg0KDQoNCkFib3V0IHlvdXIgcHJvcG9zYWwgYWJvdXQgbmVnb3RpYXRpb24g b2YgZGVsYXllZCBBQ0ssIGEgcG90ZW50aWFsIHByb2JsZW0gaXMgdGhhdCBSVE8gd2lsbCBiZSBz dHJldGNoZWQgdGhhbiBiZWZvcmUgYmVjYXVzZSB5b3UgYWRkIGV4dHJhIGRlbGF5LiBBcyB5b3Ug aGF2ZSBzYWlkLCBtb3N0IG9mIHRoZSBwYWNrZXRzIHdpbGwgbm90IGV4Y2VlZCBSVE8gZXZlbiBo b3N0IGVuYWJsZSBkZWxheWVkIEFDSyBmb3IgbW9zdCBsYXJnZSBmbG93cywgYnV0IHRoZSByZXRy YW5zbWlzc2lvbiB3aWxsIGJlIGRlbGF5ZWQgKGkuZS4sIDVtcylhbHNvIG9uY2Ugb25lIHBhY2tl dCBpcyBsb3N0Lg0KDQpUaGUgYmFzaWMgaWRlYSBvZiB0aGUgcHJvcG9zYWwgaXMgdG8gdHdlYWsg dGhlIFJUTyBjYWxjdWxhdGlvbiBhbmQgdHVybiBhIHByZXZpb3VzbHkgZXhpc3RpbmcsIGhpc3Rv cmljYWxseSBtb3RpdmF0ZWQgMjAwbXMgZml4ZWQgInNsb3AgZmFjdG9yIiBpbnRvIGEgZHluYW1p Y2FsbHkgbmVnb3RpYXRlZCA1bXMgInNsb3AgZmFjdG9yIi4gSW4gb3VyIGV4cGVyaWVuY2UgdGhh dCBpcyBhbG1vc3QgYWx3YXlzIGEgd2luLg0KDQpuZWFsDQoNCg0KQmVzdCwNCllhbGkNCj+l86RI OiBOZWFsIENhcmR3ZWxsIFttYWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb208bWFpbHRvOm5jYXJk d2VsbEBnb29nbGUuY29tPl0NCj+wZT8/OiAyMDE2pn4xMqTrMTOk6SAyMzoxOA0Kpqyl86RIOiB6 aGFuZ3lhbGkgKEQpIDx6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbTxtYWlsdG86emhhbmd5YWxpMzY5 QGh1YXdlaS5jb20+Pg0Kp9uwZTogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4N CqVEPzogUmU6IFt0Y3BtXSBBIHF1ZXN0aW9uIGFib3V0IERlbGF5ZWQgQUNLIGFuZCBSVE8NCg0K T24gVHVlLCBEZWMgMTMsIDIwMTYgYXQgMzo1OCBBTSwgemhhbmd5YWxpIChEKSA8emhhbmd5YWxp MzY5QGh1YXdlaS5jb208bWFpbHRvOnpoYW5neWFsaTM2OUBodWF3ZWkuY29tPj4gd3JvdGU6DQpI aSBhbGwsDQoNClJlY2VudCBkYXlzLCBJIGFtIGRvaW5nIHNvbWUgc2ltdWxhdGlvbiBhYm91dCBU Q1AgcGVyZm9ybWFuY2UgaW4gTlMzLiBJIGZvdW5kIGEgcGhlbm9tZW5vbiBpcyBhIGRlZmF1bHQg c2V0dGluZyBvZiBUQ1ChpnMgZGVsYXllZCBBQ0sgaXMgdHdvIHBhY2tldHMgb3IgMjAwbXMuIEkg YW0gd29uZGVyaW5nIGlmIHRoaXMgc2V0dGluZyBpcyBhY2NvcmQgd2l0aCAgc29tZSBSRkNzIGlu IElFVEYuIEJ1dCBBZnRlciBJIHJlZmVycmVkIHRvIHNvbWUgUkZDcywgSSBqdXN0IGZvdW5kIHNv bWUgcmVzdHJpY3Rpb25zLCBzdWNoIGFzLCB0aGUgZGVsYXkgbXVzdCBiZSBsZXNzIHRoYW4gMC41 bXMgKFJGQzExMjIpLg0KDQpJIGJlbGlldmUgdGhlIDIwMG1zIGZpZ3VyZSBpcyBkdWUgdG8gaGlz dG9yaWNhbCByZWFzb25zLiBBRkFJSyBpdCdzIGR1ZSB0byB0aGUgQlNEIGRlbGF5ZWQgQUNLIGJl aGF2aW9yIChzZWUgU3RldmVucyAiVENQL0lQIElsbHVzdHJhdGVkIFZvbHVtZSAyIiwgc2VjdGlv biAyNS40IGFuZCBmaWd1cmUgMjUuNywgd2hpY2ggZGVzY3JpYmVzIHRoZSAyMDBtcyBkZWxheWVk IEFDSyB0aW1lcikuIFRoZW4gdGhpcyB2YWx1ZSB3YXMgaW5oZXJpdGVkIGJ5IG90aGVyIHdpZGVs eS1kZXBsb3llZCBPU2VzLg0KDQoNCkkgdGhpbmsgdGhlIGRlbGF5ZWQgQUNLIGhhcyBhIGNsb3Nl IHJlbGF0aW9uc2hpcCB3aXRoIFJUTy4gVGFrZSBhbiBleHRyZW1lIHNjZW5hcmlvLCBpZiB0aGUg ZGVsYXkgaXMgbG9uZ2VyIHRoYW4gUlRPLCBtYW55IHBhY2tldHMgd2lsbCBiZSByZXRyYW5zbWl0 dGVkLCB3aGljaCB3aWxsIHdhc3RlIG1hbnkgbmV0d29yayByZXNvdXJjZXMuDQoNClllcywgZXhh Y3RseS4gSW4gdGhlb3J5LCB0aGUgUlRPIHRyaWVzIHRvIGJlIGFkYXB0aXZlIGVub3VnaCB0byBt ZWFzdXJlIGFueSBSVFQgdmFyaWF0aW9ucyBjYXVzZWQgYnkgZGVsYXllZCBBQ0tzLCBhbmQgaW5j cmVhc2UgdGhlIFJUTyBpbiByZXNwb25zZSB0byB0aGlzLiBIb3dldmVyLCBpdCdzIHF1aXRlIGVh c3kgZm9yIGEgYnVsayB0cmFuc2ZlciB0byBuZXZlciBoYXZlIGFueSBkZWxheWVkIEFDS3MgZm9y IG1vc3Qgb2YgaXRzIGxpZmV0aW1lLCBkdXJpbmcgd2hpY2ggdGhlIFJUTyBncmFkdWFsbHkgY29u dmVyZ2VzIHRvd2FyZCB0aGUgcmF3IFJUVCB2YWx1ZS4gVGhlbiB3aGVuIHRoZXJlIGlzIHN1ZGRl bmx5IGEgZGVsYXllZCBBQ0ssIHRoZXJlIGNhbiBiZSBhIHNwdXJpb3VzIFJUTy4NCg0KVG8gYXZv aWQgdGhhdCwgbWFueSBUQ1Agc3RhY2tzIChhdCBsZWFzdCB0aGUgbWFqb3Igb3BlbiBzb3VyY2Ug T1NlcykgaGF2ZSBhIGhhcmQtY29kZWQgMjAwbXMgInNsb3AgZmFjdG9yIiBvciAiZnVkZ2UgZmFj dG9yIiwgdG8gdHJ5IHRvIG5ldmVyIGxldCB0aGVpciBlc3RpbWF0ZSBvZiBSVFQgdmFyaWF0aW9u IGZhbGwgYmVsb3cgdGhhdCAyMDBtcyB2YWx1ZSwgdG8gYXZvaWQgdGhpcyBlZmZlY3QuDQoNClNv IEkgd2FudCB0byBrbm93IGRvIHdlIGhhdmUgc29tZSBSRkNzIGhhdmUgZ2l2ZW4gdGhlIGV4YWN0 IHZhbHVlIG9mIGJvdGg/IEFuZCBpZiB3ZSBwZXJtaXQgYW55IFRDUCBzdGFjayB0byBzZXQgdGhl bSBmcmVlbHksIHdoYXQgaXMgdGhlIG1lY2hhbmlzbSB0byBiYWxhbmNlIHRoZSBtaXNtYXRjaCBi ZXR3ZWVuIFJUTyBhbmQgZGVsYXllZCBBQ0s/DQoNCkknbSBub3QgYXdhcmUgb2YgUkZDIHNwZWNp ZmljYXRpb25zIGZvciBleGFjdCB2YWx1ZXMgb2YgYm90aCAoZGVsYXllZCBBQ0sgYW5kIFJUTyku IEhvd2V2ZXIsIHRoZSBoaXN0b3JpY2FsIHByZWNlZGVudCBpcyB2ZXJ5IHN0cm9uZywgYW5kIHRo ZSAyMDBtcyBkZWxheWVkIEFDSyB2YWx1ZSB3YXMgdmVyeSBwcm9ub3VuY2VkIGluIEludGVybmV0 IHRyYWNlcyBhdCBsZWFzdCBhcyByZWNlbnRseSBhcyAyMDExLCB3aGVuIEkgbGFzdCBsb29rZWQg YXQgdGhlIGVmZmVjdC4gKFByb2JhYmx5IG90aGVycyBoYXZlIG1vcmUgcmVjZW50IGRhdGEgcG9p bnRzIGZvciB0aGUgcHJldmFsZW5jZSBvZiAyMDBtcyBkZWxheWVkIEFDS3MuKQ0KDQpBdCBJRVRG IDk3IG91ciB0ZWFtIGF0IEdvb2dsZSBwcmVzZW50ZWQgc29tZSBmZWF0dXJlcyB3ZSB1c2UgZm9y IGludGVybmFsIFRDUCB0cmFmZmljIGF0IEdvb2dsZSwgd2hlcmUgdGhlIGVuZHBvaW50cyBjYW4g bmVnb3RpYXRlIHRoZSBzcGVjaWZpYyBjb25zdGFudCB0byB1c2UgZm9yIHRoZSBtYXhpbXVtIGRl bGF5ZWQgQUNLIGZyb20gdGhlIHJlY2VpdmVyIGFuZCB0aGUgY29ycmVzcG9uZGluZyBtaW5pbXVt IFJUVCBkZWxheSB2YXJpYXRpb24gZm9yIGJ1ZGdldGluZyBpbiB0aGUgUlRPIGF0IHRoZSBzZW5k ZXI6DQoNCiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRl cy05Ny10Y3BtLXRjcC1vcHRpb25zLWZvci1sb3ctbGF0ZW5jeS0wMC5wZGYNCg0KQXMgdGhpcyBz bGlkZSBkZWNrIG5vdGVzLCB3aXRoaW4gR29vZ2xlIHdlIG5lZ290aWF0ZSA1bXMgZm9yIGRlbGF5 ZWQgQUNLcy4NCg0KY2hlZXJzLA0KbmVhbA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQp0Y3BtIG1haWxpbmcgbGlzdA0KdGNwbUBpZXRmLm9yZzxt YWlsdG86dGNwbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGNwbQ0K --_000_F9D5899E435E417AB5D0561183AFFC92ciscocom_ Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Historically, the minimum RTO is 1 second and actual RTT is very rarel= y more than 1 second, so all this RTT calculation hardly ever matters anywa= y.

Thanks,
Jakob.


On Dec 14, 2016, at 5:24 AM, Neal Cardwell <ncardwell@google.com> wrote:

On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) <= span dir=3D"ltr"> <zhangyali3= 69@huawei.com> wrote:

Hi Neal,

 

Thanks for your providing request information.

 

About the delay of delayed ACK, I found another clue i= n a SIGCOMM paper in 1988. In the page 14, a sentence is =A1=A7The 4.5KBps = senders were talking to 4.3BSD receivers which would delay an ack until 35% of the window was filled or 200 ms had passed (i.e.= , an ack was delayed for 5-7 packets on average).=A1=A8 There is no referen= ce about the 200 ms, so I guess this is the particular delay appears for th= e first time.

I try to calculate the value based on delayed packet n= umbers, packet size and sending rate. In this case, the delayed packet numb= er is 7, the packet size is 576Byte (refer to RFC879 in 1983), and sundering rate is 4.5Bps. The value is 896 ms! Longer= than 200 ms.

 

>. However, it's quite easy for a bulk trans= fer to never have any delayed ACKs for most of its lifetime, during which t= he RTO gradually converges toward the raw RTT value. Then when there is suddenly a delayed ACK, there can be a spurious RTO.=

I am not very sure if I see your point. I think the ke= y point is the RTT variation will be weakened when packets are sent in a bu= rst (the consequence of delayed ACK).   And the spurious  could only happen for the last few packets whose number is = smaller than delayed packets, right?


Yes, there should only be a delayed ACK at the end of an application c= hunk if there is an odd number of packets. But we would expect roughly half= of application chunks to have an odd number of packets. Though the proport= ion is probably higher than that, since many application chunks are just one packet (e.g. an HTTP or RPC req= uest or response).

  

About your proposal about negotiation= of delayed ACK, a potential problem is that RTO will be stretched than bef= ore because you add extra delay. As you have said, most of the packets will not exceed RTO even host enable delayed ACK for m= ost large flows, but the retransmission will be delayed (i.e., 5ms)also onc= e one packet is lost.


The basic idea of the proposal is to tweak the RTO calculation and tur= n a previously existing, historically motivated 200ms fixed "slop fact= or" into a dynamically negotiated 5ms "slop factor". In our = experience that is almost always a win.

neal
 

 

Best,

Yali

发=A5= =F3=A4H:ncardwell@google.com]
发=B0e时间: 2016=A6~12=A4=EB13=A4=E9 23:18
=A6=AC=A5=F3=A4H: zhangyali (D) <zhangyali369@huawe= i.com>
=A7=DB=B0e: tcpm@ietf.org
=A5D题: Re: [tcpm] A question abou= t Delayed ACK and RTO

 

On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) <<= a href=3D"mailto:zhangyali369@huawei.com" target=3D"_blank">zhangyali369@hu= awei.com> wrote:

Hi all,

 

Recent days, I am doing some simulation about TCP pe= rformance in NS3. I found a phenomenon is a default setting of TCP=A1=A6s d= elayed ACK is two packets or 200ms. I am wondering if this setting is accor= d with  some RFCs in IETF. But After I referred to some RFCs, I just found some restrictions, such as, the delay = must be less than 0.5ms (RFC1122).

 

I believe the 200ms figure is due to historical reas= ons. AFAIK it's due to the BSD delayed ACK behavior (see Stevens "TCP/= IP Illustrated Volume 2", section 25.4 and figure 25.7, which describe= s the 200ms delayed ACK timer). Then this value was inherited by other widely-deployed OSes.

 

  

I think the delayed ACK has a close relationship wit= h RTO. Take an extreme scenario, if the delay is longer than RTO, many pack= ets will be retransmitted, which will waste many network resources.<= u>

 

Yes, exactly. In theory, the RTO tries to be adaptiv= e enough to measure any RTT variations caused by delayed ACKs, and increase= the RTO in response to this. However, it's quite easy for a bulk transfer = to never have any delayed ACKs for most of its lifetime, during which the RTO gradually converges toward the = raw RTT value. Then when there is suddenly a delayed ACK, there can be a sp= urious RTO.

 

To avoid that, many TCP stacks (at least the major o= pen source OSes) have a hard-coded 200ms "slop factor" or "f= udge factor", to try to never let their estimate of RTT variation fall= below that 200ms value, to avoid this effect. 

 

So I want to know do we have some RFCs have given th= e exact value of both? And if we permit any TCP stack to set them freely, w= hat is the mechanism to balance the mismatch between RTO and delayed ACK?

 

I'm not aware of RFC specifications for exact values= of both (delayed ACK and RTO). However, the historical precedent is very s= trong, and the 200ms delayed ACK value was very pronounced in Internet trac= es at least as recently as 2011, when I last looked at the effect. (Probably others have more recent data points= for the prevalence of 200ms delayed ACKs.)

 

At IETF 97 our team at Google presented some feature= s we use for internal TCP traffic at Google, where the endpoints can negoti= ate the specific constant to use for the maximum delayed ACK from the recei= ver and the corresponding minimum RTT delay variation for budgeting in the RTO at the sender:<= /p>

 

 

As this slide deck notes, within Google we negotiate= 5ms for delayed ACKs.

 

cheers, 

neal

 


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ie= tf.org/mailman/listinfo/tcpm
--_000_F9D5899E435E417AB5D0561183AFFC92ciscocom_-- From nobody Wed Dec 14 09:04:44 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CC51296DB for ; Wed, 14 Dec 2016 09:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVoZ0A8pw5It for ; Wed, 14 Dec 2016 09:04:40 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EC4129B57 for ; Wed, 14 Dec 2016 09:04:38 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id b126so26893064oia.2 for ; Wed, 14 Dec 2016 09:04:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+5uNSqqv6E2hXZJ1CT3g9krwALJW9v0UYF+TAqXkK98=; b=BK6h1kdl1Eqpz8WbhyLXkGPCp60kzP2coeBbjrUxI7olrSeX1+JsZBouVpO3Aahp6Z 8PUyOIoUkau83HUtT1FbaxkeuMRDyN1Ku09OopfFU2Fauk2MNiCp0ze3Ag+1q4pe/loL PQXl1jzae4Umbld3+tz8wm4DXlisEk91qMZx6qgXjpIq/x1RhhjHcTBxQLoSCGZBQx8Y VmY3MCqmqtm27PRKc6Wg5nolGGY0HXpAoX6pafq8YoBZ8v7HHOts3HD1Lu72blAHQeKW gWjP8IkDFP9OqyZeudHIKt3bNmwW1Do24v56IYoZ9b8AhETXwxpH1TK8mJfyXm71+LKc 95Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+5uNSqqv6E2hXZJ1CT3g9krwALJW9v0UYF+TAqXkK98=; b=B2QbzhHNQ2F+Df1MX6ThOLwLeqS23mXEbkV9/fNZ3usnKGahlPH+sLeFgtzIDINaKr t2BWEREnYJFV5gzgrxu/5ur6/2p3oSw0ilh5UimtEpSKtaC41E4lE/7bWT+UGBxeJr71 0mHEduysa5f9MOPthwms7qIuXqQoU5b1QpVxoPw/8GSxZsQEIOVpz77JQuDjJkN+xz5F uCo6TWwVJeIHgfdXUvoQzjypJIZdikGJDa67Igb+tvEmYqyE8ldNixFKt2EdEYA52L8x MgVp7dPHjvknAlltLHsJm3vqTWV7YdTvWCDrXfpayJrUK+np7NZaMr7Ykk+rEpXbkGj7 HuUA== X-Gm-Message-State: AKaTC01kBi+vjDVICaquNge3yP6S5jVISMHA4QELIG4gouTdLT+iX6H2q7zXpFYiDHHv5hPrCM/LetgJ1i7dQRW4 X-Received: by 10.202.195.18 with SMTP id t18mr57817755oif.110.1481735077395; Wed, 14 Dec 2016 09:04:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.240.213 with HTTP; Wed, 14 Dec 2016 09:04:06 -0800 (PST) In-Reply-To: References: From: Neal Cardwell Date: Wed, 14 Dec 2016 12:04:06 -0500 Message-ID: To: "Jakob Heitz (jheitz)" Content-Type: multipart/alternative; boundary=001a1134fbcef152090543a15431 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiBBIHF1ZXN0aW9uIGFib3V0IERlbGF5ZWQgQUNL?= =?utf-8?q?_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Dec 2016 17:04:43 -0000 --001a1134fbcef152090543a15431 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 14, 2016 at 11:56 AM, Jakob Heitz (jheitz) wrote: > Historically, the minimum RTO is 1 second and actual RTT is very rarely > more than 1 second, so all this RTT calculation hardly ever matters anywa= y. > That may be true historically, but for many years major TCP implementations (including Linux and FreeBSD) have used a minimum RTO closer to 200ms. And in datacenter environments even 200ms can be infeasibly high. neal > > Thanks, > Jakob. > > > On Dec 14, 2016, at 5:24 AM, Neal Cardwell wrote: > > On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) > wrote: > >> Hi Neal, >> >> >> >> Thanks for your providing request information. >> >> >> >> About the delay of delayed ACK, I found another clue in a SIGCOMM paper >> in 1988. In the page 14, a sentence is =E2=80=9CThe 4.5KBps senders were= talking to >> 4.3BSD receivers which would delay an ack until 35% of the window was >> filled or 200 ms had passed (i.e., an ack was delayed for 5-7 packets on >> average).=E2=80=9D There is no reference about the 200 ms, so I guess th= is is the >> particular delay appears for the first time. >> >> I try to calculate the value based on delayed packet numbers, packet siz= e >> and sending rate. In this case, the delayed packet number is 7, the pack= et >> size is 576Byte (refer to RFC879 in 1983), and sundering rate is 4.5Bps. >> The value is 896 ms! Longer than 200 ms. >> >> >> >> >. However, it's quite easy for a bulk transfer to never have any >> delayed ACKs for most of its lifetime, during which the RTO gradually >> converges toward the raw RTT value. Then when there is suddenly a delaye= d >> ACK, there can be a spurious RTO. >> >> I am not very sure if I see your point. I think the key point is the RTT >> variation will be weakened when packets are sent in a burst (the >> consequence of delayed ACK). And the spurious could only happen for t= he >> last few packets whose number is smaller than delayed packets, right? >> > > Yes, there should only be a delayed ACK at the end of an application chun= k > if there is an odd number of packets. But we would expect roughly half of > application chunks to have an odd number of packets. Though the proportio= n > is probably higher than that, since many application chunks are just one > packet (e.g. an HTTP or RPC request or response). > > > >> About your proposal about negotiation of delayed ACK, a potential proble= m >> is that RTO will be stretched than before because you add extra delay. A= s >> you have said, most of the packets will not exceed RTO even host enable >> delayed ACK for most large flows, but the retransmission will be delayed >> (i.e., 5ms)also once one packet is lost. >> > > The basic idea of the proposal is to tweak the RTO calculation and turn a > previously existing, historically motivated 200ms fixed "slop factor" int= o > a dynamically negotiated 5ms "slop factor". In our experience that is > almost always a win. > > neal > > >> >> >> Best, >> >> Yali >> >> *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* Neal Cardwell [mailto:ncardwell@google.= com] >> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2016=E5=B9=B412=E6=9C=8813=E6=97= =A5 23:18 >> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* zhangyali (D) >> *=E6=8A=84=E9=80=81:* tcpm@ietf.org >> *=E4=B8=BB=E9=A2=98:* Re: [tcpm] A question about Delayed ACK and RTO >> >> >> >> On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) >> wrote: >> >> Hi all, >> >> >> >> Recent days, I am doing some simulation about TCP performance in NS3. I >> found a phenomenon is a default setting of TCP=E2=80=99s delayed ACK is = two packets >> or 200ms. I am wondering if this setting is accord with some RFCs in IE= TF. >> But After I referred to some RFCs, I just found some restrictions, such = as, >> the delay must be less than 0.5ms (RFC1122). >> >> >> >> I believe the 200ms figure is due to historical reasons. AFAIK it's due >> to the BSD delayed ACK behavior (see Stevens "TCP/IP Illustrated Volume = 2", >> section 25.4 and figure 25.7, which describes the 200ms delayed ACK time= r). >> Then this value was inherited by other widely-deployed OSes. >> >> >> >> >> >> I think the delayed ACK has a close relationship with RTO. Take an >> extreme scenario, if the delay is longer than RTO, many packets will be >> retransmitted, which will waste many network resources. >> >> >> >> Yes, exactly. In theory, the RTO tries to be adaptive enough to measure >> any RTT variations caused by delayed ACKs, and increase the RTO in respo= nse >> to this. However, it's quite easy for a bulk transfer to never have any >> delayed ACKs for most of its lifetime, during which the RTO gradually >> converges toward the raw RTT value. Then when there is suddenly a delaye= d >> ACK, there can be a spurious RTO. >> >> >> >> To avoid that, many TCP stacks (at least the major open source OSes) hav= e >> a hard-coded 200ms "slop factor" or "fudge factor", to try to never let >> their estimate of RTT variation fall below that 200ms value, to avoid th= is >> effect. >> >> >> >> So I want to know do we have some RFCs have given the exact value of >> both? And if we permit any TCP stack to set them freely, what is the >> mechanism to balance the mismatch between RTO and delayed ACK? >> >> >> >> I'm not aware of RFC specifications for exact values of both (delayed AC= K >> and RTO). However, the historical precedent is very strong, and the 200m= s >> delayed ACK value was very pronounced in Internet traces at least as >> recently as 2011, when I last looked at the effect. (Probably others hav= e >> more recent data points for the prevalence of 200ms delayed ACKs.) >> >> >> >> At IETF 97 our team at Google presented some features we use for interna= l >> TCP traffic at Google, where the endpoints can negotiate the specific >> constant to use for the maximum delayed ACK from the receiver and the >> corresponding minimum RTT delay variation for budgeting in the RTO at th= e >> sender: >> >> >> >> https://www.ietf.org/proceedings/97/slides/slides-97-tcpm- >> tcp-options-for-low-latency-00.pdf >> >> >> >> As this slide deck notes, within Google we negotiate 5ms for delayed ACK= s. >> >> >> >> cheers, >> >> neal >> >> >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --001a1134fbcef152090543a15431 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 14, 2016 at 11:56 AM, Jakob Heitz (jheitz) <jheitz@cisco.com>= ; wrote:
Historically, the minimum RTO is 1 second and actual RTT is very rarel= y more than 1 second, so all this RTT calculation hardly ever matters anywa= y.

That may be true historically= , but for many years major TCP implementations (including Linux and FreeBSD= ) have used a minimum RTO closer to 200ms. And in datacenter environments e= ven 200ms can be infeasibly high.

neal
=C2=A0<= /div>

Thanks,
Jakob.


On Dec 14, 2016, at 5:24 AM, Neal Cardwell <ncardwell@google.com> wrote:

On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) <= span dir=3D"ltr"> <zhangyali3= 69@huawei.com> wrote:

Hi Neal,

=C2=A0

Thanks for your providing request information.

=C2=A0

About the delay of delayed ACK, I found another clue in a S= IGCOMM paper in 1988. In the page 14, a sentence is =E2=80=9CThe 4.5KBps se= nders were talking to 4.3BSD receivers which would delay an ack until 35% of the window was filled or 200 ms had passed (i.e.= , an ack was delayed for 5-7 packets on average).=E2=80=9D There is no refe= rence about the 200 ms, so I guess this is the particular delay appears for= the first time.

I try to calculate the value based on delayed packet number= s, packet size and sending rate. In this case, the delayed packet number is= 7, the packet size is 576Byte (refer to RFC879 in 1983), and sundering rate is 4.5Bps. The value is 896 ms! Longer= than 200 ms.

=C2=A0

>. However, it's quite easy for a bulk transf= er to never have any delayed ACKs for most of its lifetime, during which th= e RTO gradually converges toward the raw RTT value. Then when there is suddenly a delayed ACK, there can be a spurious RTO.=

I am not very sure if I see your point. I think the key poi= nt is the RTT variation will be weakened when packets are sent in a burst (= the consequence of delayed ACK). =C2=A0=C2=A0And the spurious =C2=A0could only happen for the last few packets whose number is = smaller than delayed packets, right?


Yes, there should only be a delayed ACK at the end of an application c= hunk if there is an odd number of packets. But we would expect roughly half= of application chunks to have an odd number of packets. Though the proport= ion is probably higher than that, since many application chunks are just one packet (e.g. an HTTP or RPC req= uest or response).

=C2=A0=C2=A0

About your proposal about negotiation of del= ayed ACK, a potential problem is that RTO will be stretched than before bec= ause you add extra delay. As you have said, most of the packets will not exceed RTO even host enable delayed ACK for m= ost large flows, but the retransmission will be delayed (i.e., 5ms)also onc= e one packet is lost.


The basic idea of the proposal is to tweak the RTO calculation and tur= n a previously existing, historically motivated 200ms fixed "slop fact= or" into a dynamically negotiated 5ms "slop factor". In our = experience that is almost always a win.

neal
=C2=A0

=C2=A0

Best,

Yali

=E5=8F=91=E4=BB=B6= =E4=BA=BA: Neal Cardwell [mailto:ncardwell@google.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 20= 16=E5=B9=B412=E6=9C=8813=E6=97=A5 23:18
=E6=94=B6=E4=BB=B6=E4=BA=BA: zhangyali (= D) <zhangya= li369@huawei.com>
=E6=8A=84=E9=80=81: tcpm@ietf.org
=E4=B8=BB=E9=A2=98: Re: [tcpm] A questio= n about Delayed ACK and RTO

=C2=A0

On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) <<= a href=3D"mailto:zhangyali369@huawei.com" target=3D"_blank">zhangyali369@hu= awei.com> wrote:

Hi all,

=C2=A0

Recent days, I am doing some simulation about TCP pe= rformance in NS3. I found a phenomenon is a default setting of TCP=E2=80=99= s delayed ACK is two packets or 200ms. I am wondering if this setting is ac= cord with =C2=A0some RFCs in IETF. But After I referred to some RFCs, I just found some restrictions, such as, the delay = must be less than 0.5ms (RFC1122).

=C2=A0

I believe the 200ms figure is due to historical reas= ons. AFAIK it's due to the BSD delayed ACK behavior (see Stevens "= TCP/IP Illustrated Volume 2", section 25.4 and figure 25.7, which desc= ribes the 200ms delayed ACK timer). Then this value was inherited by other widely-deployed OSes.

=C2=A0

=C2=A0=C2=A0

I think the delayed ACK has a close relationship wit= h RTO. Take an extreme scenario, if the delay is longer than RTO, many pack= ets will be retransmitted, which will waste many network resources.<= u>

=C2=A0

Yes, exactly. In theory, the RTO tries to be adaptiv= e enough to measure any RTT variations caused by delayed ACKs, and increase= the RTO in response to this. However, it's quite easy for a bulk trans= fer to never have any delayed ACKs for most of its lifetime, during which the RTO gradually converges toward the = raw RTT value. Then when there is suddenly a delayed ACK, there can be a sp= urious RTO.

=C2=A0

To avoid that, many TCP stacks (at least the major o= pen source OSes) have a hard-coded 200ms "slop factor" or "f= udge factor", to try to never let their estimate of RTT variation fall= below that 200ms value, to avoid this effect.=C2=A0

=C2=A0

So I want to know do we have some RFCs have given th= e exact value of both? And if we permit any TCP stack to set them freely, w= hat is the mechanism to balance the mismatch between RTO and delayed ACK?

=C2=A0

I'm not aware of RFC specifications for exact va= lues of both (delayed ACK and RTO). However, the historical precedent is ve= ry strong, and the 200ms delayed ACK value was very pronounced in Internet = traces at least as recently as 2011, when I last looked at the effect. (Probably others have more recent data points= for the prevalence of 200ms delayed ACKs.)

=C2=A0

At IETF 97 our team at Google presented some feature= s we use for internal TCP traffic at Google, where the endpoints can negoti= ate the specific constant to use for the maximum delayed ACK from the recei= ver and the corresponding minimum RTT delay variation for budgeting in the RTO at the sender:<= /p>

=C2=A0

=C2=A0

As this slide deck notes, within Google we negotiate= 5ms for delayed ACKs.

=C2=A0

cheers,=C2=A0

neal

=C2=A0


_______________________________________________
tcpm mailing list
tcpm@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/tcpm

--001a1134fbcef152090543a15431-- From nobody Wed Dec 14 09:21:40 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A153129BAC for ; Wed, 14 Dec 2016 09:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.417 X-Spam-Level: X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLY12Sap5Kte for ; Wed, 14 Dec 2016 09:21:35 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026BE129B95 for ; Wed, 14 Dec 2016 09:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23463; q=dns/txt; s=iport; t=1481736093; x=1482945693; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l+0x9xhQ+bK//JsWwT7TgDdZOVOF+Q2mHNPVBtNdeKg=; b=WMX3oU14h4t2HNjOPy/xhMikTz8k6SdrvdeLc8VG2FDV0PJo8JZ+d9NV OTsHm0vZbMrmQt1JTVQiQ9CutHH53eYRty94gNJEtMnk0UIbbWQNQuuml yg+p5k4y9AiYWcJ+IkDbUsgi1EVUUVOrph2CE5RitnR0QExx3fGrU4IFc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAwCmflFY/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnM5CwEBAQEBH1oyVI1OrCKCCR8BDIV2AhqBXT8UAQIBAQEBAQE?= =?us-ascii?q?BYiiEaQICAgEBDFcJBAcQAgEGAg4xBQICJQsUBgsCBAoEBR6ITQ6MUJ1ECIImi?= =?us-ascii?q?w8BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYY+gX2CXoRfH4JKMYIwBZUAhWsBkSy?= =?us-ascii?q?QS44UhA4BHzc+ZCkOAQGDBTscgV1yAYgwAQEB?= X-IronPort-AV: E=Sophos;i="5.33,347,1477958400"; d="scan'208,217";a="360748704" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2016 17:21:32 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uBEHLWuD020943 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Dec 2016 17:21:32 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 14 Dec 2016 11:21:32 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 14 Dec 2016 11:21:32 -0600 From: "Jakob Heitz (jheitz)" To: Neal Cardwell Thread-Topic: =?gb2312?B?W3RjcG1dILTwuLQ6IEEgcXVlc3Rpb24gYWJvdXQgRGVsYXllZCBBQ0sgYW5k?= =?gb2312?Q?_RTO?= Thread-Index: AQHSVixyarKi+1Y3zEWcMy0t1yecaaEHsK1i Date: Wed, 14 Dec 2016 17:21:32 +0000 Message-ID: <3C746F85-73B9-428F-AD18-82E6BB99BE52@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_3C746F8573B9428FAD1882E6BB99BE52ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?gb2312?b?tPC4tDogQSBxdWVzdGlvbiBhYm91dCBEZWxheWVkIEFD?= =?gb2312?b?SyBhbmQgUlRP?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Dec 2016 17:21:38 -0000 --_000_3C746F8573B9428FAD1882E6BB99BE52ciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhlIHByb2JsZW0gaW4gYSB2aXJ0dWFsaXplZCBlbnZpcm9ubWVudCBpcyB0aGF0IFJUVCBpcyBo aWdobHkgdmFyaWFibGUuIE1vc3RseSBzdWIgbWlsbGlzZWNvbmQgd2l0aCBvY2Nhc2lvbmFsIHNw aWtlcyBhdCBzZXZlcmFsIDEwMCBtcy4gQW5kIG5vdCBqdXN0IGJlY2F1c2Ugb2YgZGVsYXllZCBh Y2ssIGJ1dCBkdWUgdG8gZWZmZWN0cyBvZiBWTSBzY2hlZHVsaW5nIGFuZCBsb2FkLg0KDQpUaGFu a3MsDQpKYWtvYi4NCg0KDQpPbiBEZWMgMTQsIDIwMTYsIGF0IDk6MDYgQU0sIE5lYWwgQ2FyZHdl bGwgPG5jYXJkd2VsbEBnb29nbGUuY29tPG1haWx0bzpuY2FyZHdlbGxAZ29vZ2xlLmNvbT4+IHdy b3RlOg0KDQpPbiBXZWQsIERlYyAxNCwgMjAxNiBhdCAxMTo1NiBBTSwgSmFrb2IgSGVpdHogKGpo ZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+PiB3cm90ZToN Ckhpc3RvcmljYWxseSwgdGhlIG1pbmltdW0gUlRPIGlzIDEgc2Vjb25kIGFuZCBhY3R1YWwgUlRU IGlzIHZlcnkgcmFyZWx5IG1vcmUgdGhhbiAxIHNlY29uZCwgc28gYWxsIHRoaXMgUlRUIGNhbGN1 bGF0aW9uIGhhcmRseSBldmVyIG1hdHRlcnMgYW55d2F5Lg0KDQpUaGF0IG1heSBiZSB0cnVlIGhp c3RvcmljYWxseSwgYnV0IGZvciBtYW55IHllYXJzIG1ham9yIFRDUCBpbXBsZW1lbnRhdGlvbnMg KGluY2x1ZGluZyBMaW51eCBhbmQgRnJlZUJTRCkgaGF2ZSB1c2VkIGEgbWluaW11bSBSVE8gY2xv c2VyIHRvIDIwMG1zLiBBbmQgaW4gZGF0YWNlbnRlciBlbnZpcm9ubWVudHMgZXZlbiAyMDBtcyBj YW4gYmUgaW5mZWFzaWJseSBoaWdoLg0KDQpuZWFsDQoNCg0KVGhhbmtzLA0KSmFrb2IuDQoNCg0K T24gRGVjIDE0LCAyMDE2LCBhdCA1OjI0IEFNLCBOZWFsIENhcmR3ZWxsIDxuY2FyZHdlbGxAZ29v Z2xlLmNvbTxtYWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KT24gV2VkLCBE ZWMgMTQsIDIwMTYgYXQgNDo0OCBBTSwgemhhbmd5YWxpIChEKSA8emhhbmd5YWxpMzY5QGh1YXdl aS5jb208bWFpbHRvOnpoYW5neWFsaTM2OUBodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBOZWFsLA0K DQpUaGFua3MgZm9yIHlvdXIgcHJvdmlkaW5nIHJlcXVlc3QgaW5mb3JtYXRpb24uDQoNCkFib3V0 IHRoZSBkZWxheSBvZiBkZWxheWVkIEFDSywgSSBmb3VuZCBhbm90aGVyIGNsdWUgaW4gYSBTSUdD T01NIHBhcGVyIGluIDE5ODguIEluIHRoZSBwYWdlIDE0LCBhIHNlbnRlbmNlIGlzIKGwVGhlIDQu NUtCcHMgc2VuZGVycyB3ZXJlIHRhbGtpbmcgdG8gNC4zQlNEIHJlY2VpdmVycyB3aGljaCB3b3Vs ZCBkZWxheSBhbiBhY2sgdW50aWwgMzUlIG9mIHRoZSB3aW5kb3cgd2FzIGZpbGxlZCBvciAyMDAg bXMgaGFkIHBhc3NlZCAoaS5lLiwgYW4gYWNrIHdhcyBkZWxheWVkIGZvciA1LTcgcGFja2V0cyBv biBhdmVyYWdlKS6hsSBUaGVyZSBpcyBubyByZWZlcmVuY2UgYWJvdXQgdGhlIDIwMCBtcywgc28g SSBndWVzcyB0aGlzIGlzIHRoZSBwYXJ0aWN1bGFyIGRlbGF5IGFwcGVhcnMgZm9yIHRoZSBmaXJz dCB0aW1lLg0KSSB0cnkgdG8gY2FsY3VsYXRlIHRoZSB2YWx1ZSBiYXNlZCBvbiBkZWxheWVkIHBh Y2tldCBudW1iZXJzLCBwYWNrZXQgc2l6ZSBhbmQgc2VuZGluZyByYXRlLiBJbiB0aGlzIGNhc2Us IHRoZSBkZWxheWVkIHBhY2tldCBudW1iZXIgaXMgNywgdGhlIHBhY2tldCBzaXplIGlzIDU3NkJ5 dGUgKHJlZmVyIHRvIFJGQzg3OSBpbiAxOTgzKSwgYW5kIHN1bmRlcmluZyByYXRlIGlzIDQuNUJw cy4gVGhlIHZhbHVlIGlzIDg5NiBtcyEgTG9uZ2VyIHRoYW4gMjAwIG1zLg0KDQo+LiBIb3dldmVy LCBpdCdzIHF1aXRlIGVhc3kgZm9yIGEgYnVsayB0cmFuc2ZlciB0byBuZXZlciBoYXZlIGFueSBk ZWxheWVkIEFDS3MgZm9yIG1vc3Qgb2YgaXRzIGxpZmV0aW1lLCBkdXJpbmcgd2hpY2ggdGhlIFJU TyBncmFkdWFsbHkgY29udmVyZ2VzIHRvd2FyZCB0aGUgcmF3IFJUVCB2YWx1ZS4gVGhlbiB3aGVu IHRoZXJlIGlzIHN1ZGRlbmx5IGEgZGVsYXllZCBBQ0ssIHRoZXJlIGNhbiBiZSBhIHNwdXJpb3Vz IFJUTy4NCkkgYW0gbm90IHZlcnkgc3VyZSBpZiBJIHNlZSB5b3VyIHBvaW50LiBJIHRoaW5rIHRo ZSBrZXkgcG9pbnQgaXMgdGhlIFJUVCB2YXJpYXRpb24gd2lsbCBiZSB3ZWFrZW5lZCB3aGVuIHBh Y2tldHMgYXJlIHNlbnQgaW4gYSBidXJzdCAodGhlIGNvbnNlcXVlbmNlIG9mIGRlbGF5ZWQgQUNL KS4gICBBbmQgdGhlIHNwdXJpb3VzICBjb3VsZCBvbmx5IGhhcHBlbiBmb3IgdGhlIGxhc3QgZmV3 IHBhY2tldHMgd2hvc2UgbnVtYmVyIGlzIHNtYWxsZXIgdGhhbiBkZWxheWVkIHBhY2tldHMsIHJp Z2h0Pw0KDQpZZXMsIHRoZXJlIHNob3VsZCBvbmx5IGJlIGEgZGVsYXllZCBBQ0sgYXQgdGhlIGVu ZCBvZiBhbiBhcHBsaWNhdGlvbiBjaHVuayBpZiB0aGVyZSBpcyBhbiBvZGQgbnVtYmVyIG9mIHBh Y2tldHMuIEJ1dCB3ZSB3b3VsZCBleHBlY3Qgcm91Z2hseSBoYWxmIG9mIGFwcGxpY2F0aW9uIGNo dW5rcyB0byBoYXZlIGFuIG9kZCBudW1iZXIgb2YgcGFja2V0cy4gVGhvdWdoIHRoZSBwcm9wb3J0 aW9uIGlzIHByb2JhYmx5IGhpZ2hlciB0aGFuIHRoYXQsIHNpbmNlIG1hbnkgYXBwbGljYXRpb24g Y2h1bmtzIGFyZSBqdXN0IG9uZSBwYWNrZXQgKGUuZy4gYW4gSFRUUCBvciBSUEMgcmVxdWVzdCBv ciByZXNwb25zZSkuDQoNCg0KQWJvdXQgeW91ciBwcm9wb3NhbCBhYm91dCBuZWdvdGlhdGlvbiBv ZiBkZWxheWVkIEFDSywgYSBwb3RlbnRpYWwgcHJvYmxlbSBpcyB0aGF0IFJUTyB3aWxsIGJlIHN0 cmV0Y2hlZCB0aGFuIGJlZm9yZSBiZWNhdXNlIHlvdSBhZGQgZXh0cmEgZGVsYXkuIEFzIHlvdSBo YXZlIHNhaWQsIG1vc3Qgb2YgdGhlIHBhY2tldHMgd2lsbCBub3QgZXhjZWVkIFJUTyBldmVuIGhv c3QgZW5hYmxlIGRlbGF5ZWQgQUNLIGZvciBtb3N0IGxhcmdlIGZsb3dzLCBidXQgdGhlIHJldHJh bnNtaXNzaW9uIHdpbGwgYmUgZGVsYXllZCAoaS5lLiwgNW1zKWFsc28gb25jZSBvbmUgcGFja2V0 IGlzIGxvc3QuDQoNClRoZSBiYXNpYyBpZGVhIG9mIHRoZSBwcm9wb3NhbCBpcyB0byB0d2VhayB0 aGUgUlRPIGNhbGN1bGF0aW9uIGFuZCB0dXJuIGEgcHJldmlvdXNseSBleGlzdGluZywgaGlzdG9y aWNhbGx5IG1vdGl2YXRlZCAyMDBtcyBmaXhlZCAic2xvcCBmYWN0b3IiIGludG8gYSBkeW5hbWlj YWxseSBuZWdvdGlhdGVkIDVtcyAic2xvcCBmYWN0b3IiLiBJbiBvdXIgZXhwZXJpZW5jZSB0aGF0 IGlzIGFsbW9zdCBhbHdheXMgYSB3aW4uDQoNCm5lYWwNCg0KDQpCZXN0LA0KWWFsaQ0Kt6K8/sjL OiBOZWFsIENhcmR3ZWxsIFttYWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb208bWFpbHRvOm5jYXJk d2VsbEBnb29nbGUuY29tPl0NCreiy83KsbzkOiAyMDE2xOoxMtTCMTPI1SAyMzoxOA0KytW8/sjL OiB6aGFuZ3lhbGkgKEQpIDx6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbTxtYWlsdG86emhhbmd5YWxp MzY5QGh1YXdlaS5jb20+Pg0Ks63LzTogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9y Zz4NCtb3zOI6IFJlOiBbdGNwbV0gQSBxdWVzdGlvbiBhYm91dCBEZWxheWVkIEFDSyBhbmQgUlRP DQoNCk9uIFR1ZSwgRGVjIDEzLCAyMDE2IGF0IDM6NTggQU0sIHpoYW5neWFsaSAoRCkgPHpoYW5n eWFsaTM2OUBodWF3ZWkuY29tPG1haWx0bzp6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbT4+IHdyb3Rl Og0KSGkgYWxsLA0KDQpSZWNlbnQgZGF5cywgSSBhbSBkb2luZyBzb21lIHNpbXVsYXRpb24gYWJv dXQgVENQIHBlcmZvcm1hbmNlIGluIE5TMy4gSSBmb3VuZCBhIHBoZW5vbWVub24gaXMgYSBkZWZh dWx0IHNldHRpbmcgb2YgVENQoa9zIGRlbGF5ZWQgQUNLIGlzIHR3byBwYWNrZXRzIG9yIDIwMG1z LiBJIGFtIHdvbmRlcmluZyBpZiB0aGlzIHNldHRpbmcgaXMgYWNjb3JkIHdpdGggIHNvbWUgUkZD cyBpbiBJRVRGLiBCdXQgQWZ0ZXIgSSByZWZlcnJlZCB0byBzb21lIFJGQ3MsIEkganVzdCBmb3Vu ZCBzb21lIHJlc3RyaWN0aW9ucywgc3VjaCBhcywgdGhlIGRlbGF5IG11c3QgYmUgbGVzcyB0aGFu IDAuNW1zIChSRkMxMTIyKS4NCg0KSSBiZWxpZXZlIHRoZSAyMDBtcyBmaWd1cmUgaXMgZHVlIHRv IGhpc3RvcmljYWwgcmVhc29ucy4gQUZBSUsgaXQncyBkdWUgdG8gdGhlIEJTRCBkZWxheWVkIEFD SyBiZWhhdmlvciAoc2VlIFN0ZXZlbnMgIlRDUC9JUCBJbGx1c3RyYXRlZCBWb2x1bWUgMiIsIHNl Y3Rpb24gMjUuNCBhbmQgZmlndXJlIDI1LjcsIHdoaWNoIGRlc2NyaWJlcyB0aGUgMjAwbXMgZGVs YXllZCBBQ0sgdGltZXIpLiBUaGVuIHRoaXMgdmFsdWUgd2FzIGluaGVyaXRlZCBieSBvdGhlciB3 aWRlbHktZGVwbG95ZWQgT1Nlcy4NCg0KDQpJIHRoaW5rIHRoZSBkZWxheWVkIEFDSyBoYXMgYSBj bG9zZSByZWxhdGlvbnNoaXAgd2l0aCBSVE8uIFRha2UgYW4gZXh0cmVtZSBzY2VuYXJpbywgaWYg dGhlIGRlbGF5IGlzIGxvbmdlciB0aGFuIFJUTywgbWFueSBwYWNrZXRzIHdpbGwgYmUgcmV0cmFu c21pdHRlZCwgd2hpY2ggd2lsbCB3YXN0ZSBtYW55IG5ldHdvcmsgcmVzb3VyY2VzLg0KDQpZZXMs IGV4YWN0bHkuIEluIHRoZW9yeSwgdGhlIFJUTyB0cmllcyB0byBiZSBhZGFwdGl2ZSBlbm91Z2gg dG8gbWVhc3VyZSBhbnkgUlRUIHZhcmlhdGlvbnMgY2F1c2VkIGJ5IGRlbGF5ZWQgQUNLcywgYW5k IGluY3JlYXNlIHRoZSBSVE8gaW4gcmVzcG9uc2UgdG8gdGhpcy4gSG93ZXZlciwgaXQncyBxdWl0 ZSBlYXN5IGZvciBhIGJ1bGsgdHJhbnNmZXIgdG8gbmV2ZXIgaGF2ZSBhbnkgZGVsYXllZCBBQ0tz IGZvciBtb3N0IG9mIGl0cyBsaWZldGltZSwgZHVyaW5nIHdoaWNoIHRoZSBSVE8gZ3JhZHVhbGx5 IGNvbnZlcmdlcyB0b3dhcmQgdGhlIHJhdyBSVFQgdmFsdWUuIFRoZW4gd2hlbiB0aGVyZSBpcyBz dWRkZW5seSBhIGRlbGF5ZWQgQUNLLCB0aGVyZSBjYW4gYmUgYSBzcHVyaW91cyBSVE8uDQoNClRv IGF2b2lkIHRoYXQsIG1hbnkgVENQIHN0YWNrcyAoYXQgbGVhc3QgdGhlIG1ham9yIG9wZW4gc291 cmNlIE9TZXMpIGhhdmUgYSBoYXJkLWNvZGVkIDIwMG1zICJzbG9wIGZhY3RvciIgb3IgImZ1ZGdl IGZhY3RvciIsIHRvIHRyeSB0byBuZXZlciBsZXQgdGhlaXIgZXN0aW1hdGUgb2YgUlRUIHZhcmlh dGlvbiBmYWxsIGJlbG93IHRoYXQgMjAwbXMgdmFsdWUsIHRvIGF2b2lkIHRoaXMgZWZmZWN0Lg0K DQpTbyBJIHdhbnQgdG8ga25vdyBkbyB3ZSBoYXZlIHNvbWUgUkZDcyBoYXZlIGdpdmVuIHRoZSBl eGFjdCB2YWx1ZSBvZiBib3RoPyBBbmQgaWYgd2UgcGVybWl0IGFueSBUQ1Agc3RhY2sgdG8gc2V0 IHRoZW0gZnJlZWx5LCB3aGF0IGlzIHRoZSBtZWNoYW5pc20gdG8gYmFsYW5jZSB0aGUgbWlzbWF0 Y2ggYmV0d2VlbiBSVE8gYW5kIGRlbGF5ZWQgQUNLPw0KDQpJJ20gbm90IGF3YXJlIG9mIFJGQyBz cGVjaWZpY2F0aW9ucyBmb3IgZXhhY3QgdmFsdWVzIG9mIGJvdGggKGRlbGF5ZWQgQUNLIGFuZCBS VE8pLiBIb3dldmVyLCB0aGUgaGlzdG9yaWNhbCBwcmVjZWRlbnQgaXMgdmVyeSBzdHJvbmcsIGFu ZCB0aGUgMjAwbXMgZGVsYXllZCBBQ0sgdmFsdWUgd2FzIHZlcnkgcHJvbm91bmNlZCBpbiBJbnRl cm5ldCB0cmFjZXMgYXQgbGVhc3QgYXMgcmVjZW50bHkgYXMgMjAxMSwgd2hlbiBJIGxhc3QgbG9v a2VkIGF0IHRoZSBlZmZlY3QuIChQcm9iYWJseSBvdGhlcnMgaGF2ZSBtb3JlIHJlY2VudCBkYXRh IHBvaW50cyBmb3IgdGhlIHByZXZhbGVuY2Ugb2YgMjAwbXMgZGVsYXllZCBBQ0tzLikNCg0KQXQg SUVURiA5NyBvdXIgdGVhbSBhdCBHb29nbGUgcHJlc2VudGVkIHNvbWUgZmVhdHVyZXMgd2UgdXNl IGZvciBpbnRlcm5hbCBUQ1AgdHJhZmZpYyBhdCBHb29nbGUsIHdoZXJlIHRoZSBlbmRwb2ludHMg Y2FuIG5lZ290aWF0ZSB0aGUgc3BlY2lmaWMgY29uc3RhbnQgdG8gdXNlIGZvciB0aGUgbWF4aW11 bSBkZWxheWVkIEFDSyBmcm9tIHRoZSByZWNlaXZlciBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgbWlu aW11bSBSVFQgZGVsYXkgdmFyaWF0aW9uIGZvciBidWRnZXRpbmcgaW4gdGhlIFJUTyBhdCB0aGUg c2VuZGVyOg0KDQogIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L3NsaWRlcy9z bGlkZXMtOTctdGNwbS10Y3Atb3B0aW9ucy1mb3ItbG93LWxhdGVuY3ktMDAucGRmDQoNCkFzIHRo aXMgc2xpZGUgZGVjayBub3Rlcywgd2l0aGluIEdvb2dsZSB3ZSBuZWdvdGlhdGUgNW1zIGZvciBk ZWxheWVkIEFDS3MuDQoNCmNoZWVycywNCm5lYWwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1AaWV0Zi5v cmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RjcG0NCg0K --_000_3C746F8573B9428FAD1882E6BB99BE52ciscocom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
The problem in a virtualized environment is that RTT is highly variabl= e. Mostly sub millisecond with occasional spikes at several 100 ms. And not= just because of delayed ack, but due to effects of VM scheduling and load.=

Thanks,
Jakob.


On Dec 14, 2016, at 9:06 AM, Neal Cardwell <ncardwell@google.com> wrote:

On Wed, Dec 14, 2016 at 11:56 AM, Jakob Heitz (j= heitz) <jheitz@cisco.com<= /a>> wrote:
Historically, the minimum RTO is 1 second and actual RTT is very rarel= y more than 1 second, so all this RTT calculation hardly ever matters anywa= y.

That may be true historically, but for many years major TCP implementations= (including Linux and FreeBSD) have used a minimum RTO closer to 200ms. And= in datacenter environments even 200ms can be infeasibly high.

neal
 

Thanks,
Jakob.

On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) <= span dir=3D"ltr"> <zhangyali3= 69@huawei.com> wrote:

Hi Neal,

 

Thanks for your providing request information.

 

About the delay of delayed ACK, I found another clue in a S= IGCOMM paper in 1988. In the page 14, a sentence is =A1=B0The 4.5KBps sende= rs were talking to 4.3BSD receivers which would delay an ack until 35% of the window was filled or 200 ms had passed= (i.e., an ack was delayed for 5-7 packets on average).=A1=B1 There is no r= eference about the 200 ms, so I guess this is the particular delay appears = for the first time.

I try to calculate the value based on delayed packet number= s, packet size and sending rate. In this case, the delayed packet number is= 7, the packet size is 576Byte (refer to RFC879 in 1983), and sundering rate is 4.5Bps. The value is 896 ms! Lon= ger than 200 ms.

 

>. However, it's quite easy for a bulk transfer t= o never have any delayed ACKs for most of its lifetime, during which the RT= O gradually converges toward the raw RTT value. Then when there is suddenly a delayed ACK, there can be a spurious = RTO.

I am not very sure if I see your point. I think the key poi= nt is the RTT variation will be weakened when packets are sent in a burst (= the consequence of delayed ACK).   And the spurious  could only happen for the last few packets whose number= is smaller than delayed packets, right?


Yes, there should only be a delayed ACK at the end of an application c= hunk if there is an odd number of packets. But we would expect roughly half= of application chunks to have an odd number of packets. Though the proport= ion is probably higher than that, since many application chunks are just one packet (e.g. an HTTP or RPC req= uest or response).

  

About your proposal about negotiation of del= ayed ACK, a potential problem is that RTO will be stretched than before bec= ause you add extra delay. As you have said, most of the packets will not exceed RTO even host enable delayed ACK= for most large flows, but the retransmission will be delayed (i.e., 5ms)al= so once one packet is lost.


The basic idea of the proposal is to tweak the RTO calculation and tur= n a previously existing, historically motivated 200ms fixed "slop fact= or" into a dynamically negotiated 5ms "slop factor". In our = experience that is almost always a win.

neal
 

 

Best,

Yali

=B7=A2=BC=FE=C8=CB<= b>: Neal Cardwell [mailto:ncardwell@google.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA12=D4=C213=C8=D5 23:18
=CA=D5=BC=FE=C8=CB: zhangyali (D) <zhangyali369@hua= wei.com>
=B3=AD=CB=CD: tcpm@ietf.org
=D6=F7=CC=E2: Re: [tcpm] A question abou= t Delayed ACK and RTO

 

On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) <<= a href=3D"mailto:zhangyali369@huawei.com" target=3D"_blank">zhangyali369@hu= awei.com> wrote:

Hi all,

 

Recent days, I am doing some simulation about TCP pe= rformance in NS3. I found a phenomenon is a default setting of TCP=A1=AFs d= elayed ACK is two packets or 200ms. I am wondering if this setting is accor= d with  some RFCs in IETF. But After I referred to some RFCs, I just found some restrictions, such as, the delay = must be less than 0.5ms (RFC1122).

 

I believe the 200ms figure is due to historical reas= ons. AFAIK it's due to the BSD delayed ACK behavior (see Stevens "TCP/= IP Illustrated Volume 2", section 25.4 and figure 25.7, which describe= s the 200ms delayed ACK timer). Then this value was inherited by other widely-deployed OSes.

 

  

I think the delayed ACK has a close relationship wit= h RTO. Take an extreme scenario, if the delay is longer than RTO, many pack= ets will be retransmitted, which will waste many network resources.<= u>

 

Yes, exactly. In theory, the RTO tries to be adaptiv= e enough to measure any RTT variations caused by delayed ACKs, and increase= the RTO in response to this. However, it's quite easy for a bulk transfer = to never have any delayed ACKs for most of its lifetime, during which the RTO gradually converges toward the = raw RTT value. Then when there is suddenly a delayed ACK, there can be a sp= urious RTO.

 

To avoid that, many TCP stacks (at least the major o= pen source OSes) have a hard-coded 200ms "slop factor" or "f= udge factor", to try to never let their estimate of RTT variation fall= below that 200ms value, to avoid this effect. 

 

So I want to know do we have some RFCs have given th= e exact value of both? And if we permit any TCP stack to set them freely, w= hat is the mechanism to balance the mismatch between RTO and delayed ACK?

 

I'm not aware of RFC specifications for exact values= of both (delayed ACK and RTO). However, the historical precedent is very s= trong, and the 200ms delayed ACK value was very pronounced in Internet trac= es at least as recently as 2011, when I last looked at the effect. (Probably others have more recent data points= for the prevalence of 200ms delayed ACKs.)

 

At IETF 97 our team at Google presented some feature= s we use for internal TCP traffic at Google, where the endpoints can negoti= ate the specific constant to use for the maximum delayed ACK from the recei= ver and the corresponding minimum RTT delay variation for budgeting in the RTO at the sender:<= /p>

 

 

As this slide deck notes, within Google we negotiate= 5ms for delayed ACKs.

 

cheers, 

neal

 


_______________________________________________
tcpm mailing list
tcpm@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/tcpm

--_000_3C746F8573B9428FAD1882E6BB99BE52ciscocom_-- From nobody Wed Dec 14 11:13:50 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB0B129EB1 for ; Wed, 14 Dec 2016 11:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXTZ5M77mjXQ for ; Wed, 14 Dec 2016 11:13:46 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71EDC12711D for ; Wed, 14 Dec 2016 11:13:46 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id y198so30274602oia.1 for ; Wed, 14 Dec 2016 11:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iXGUA+Xw11lK3FmwK2wIIc988zrQ4PMaUyXQGg6HPzk=; b=FUbYGpY/zzCylJNAqFQOOEsgqhnf3CW4qhSf88IUkaZgdq8ktQY0ZTUBHLvhE6lU9M y6PCQ9A4wirHnOtu/i+l7qlwtgQKv5xwUgpQ3jx/kHA7KmMMs/2Vg/llLEriqzIKSWQI B8wlLG5judiyu/A93/0/5FUcYaK4cfV0JAjOlBqWrECAWu8lbliUGDKqyDSepHMRyUs6 5V8Fy3WuG5hhgHwF7znDfX9E/dzl8V9+0W8HqIPRQNXuNHMnCJyfWuGhQbalUSht1p94 lJeNLlCQFwind4lh/fgi0NdGdhcfycg6Ij+kzxhFMq0839p0ozKFkViujpC8dbZCW7Ue S0TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iXGUA+Xw11lK3FmwK2wIIc988zrQ4PMaUyXQGg6HPzk=; b=trbErPXDbXypTqyzhcy6Z3rjEM1amFNWf1CMC/7WXJr0YxkG5EZxpOoA5hW6FCw5Fq eql99eGINZiscoLqjyQIV9bUDatQ945LjdSXwehUPJjyiKfTWfxcI21APUU7Eb9PXIdU JSfBXWw6bXUdheBQNLDQlmPlNVyIgilQi6wiCVoex+KEtZe/rgCbOq1Fj6/6iVjZBpph Nao9ha6zijMGIOnv1ULdxQ4aEDIqhdk8MphLH4nYbeetbV775j3CI7NaYjLLXKIlyf4C GS4ECPRLF6eMfKUrbRLb3imh7wxZSrp6s1PD6pXpUdQKdzfw6/PmQDlzaKT7Gf+Yg3P5 VPRg== X-Gm-Message-State: AKaTC032vX0lPnDeYHzLDUWiNMkZ5AoiG0C73RgmWqBJgjQerNOvUP7xDLaVrUFTIo6wwb2zF9ZFNNuD/BRfy0s+ X-Received: by 10.202.108.76 with SMTP id h73mr57410216oic.29.1481742825659; Wed, 14 Dec 2016 11:13:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.240.213 with HTTP; Wed, 14 Dec 2016 11:13:15 -0800 (PST) In-Reply-To: <3C746F85-73B9-428F-AD18-82E6BB99BE52@cisco.com> References: <3C746F85-73B9-428F-AD18-82E6BB99BE52@cisco.com> From: Neal Cardwell Date: Wed, 14 Dec 2016 14:13:15 -0500 Message-ID: To: "Jakob Heitz (jheitz)" Content-Type: multipart/alternative; boundary=001a1142d920c627cc0543a3220c Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiBBIHF1ZXN0aW9uIGFib3V0IERlbGF5ZWQgQUNL?= =?utf-8?q?_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Dec 2016 19:13:49 -0000 --001a1142d920c627cc0543a3220c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 14, 2016 at 12:21 PM, Jakob Heitz (jheitz) wrote: > The problem in a virtualized environment is that RTT is highly variable. > Mostly sub millisecond with occasional spikes at several 100 ms. And not > just because of delayed ack, but due to effects of VM scheduling and load= . > True enough. But the RTO mechanism need not try to drive the spurious RTO rate down to zero. There is some trade-off between faster loss recovery and an increase in spurious retransmits, and some associated cost-benefit analysis. These days IMHO the cost of a spurious timer-based loss repair attempt is relatively low, now that we have TLP and a number of nice undo mechanisms (FRTO, Eifel, DSACKs). By contrast, in datacenter apps w/ sub-millisecond RTTs, there are prohibitive costs for delaying every timer-driven loss repair for 200ms. cheers, neal > > Thanks, > Jakob. > > > On Dec 14, 2016, at 9:06 AM, Neal Cardwell wrote: > > On Wed, Dec 14, 2016 at 11:56 AM, Jakob Heitz (jheitz) > wrote: > >> Historically, the minimum RTO is 1 second and actual RTT is very rarely >> more than 1 second, so all this RTT calculation hardly ever matters anyw= ay. >> > > That may be true historically, but for many years major TCP > implementations (including Linux and FreeBSD) have used a minimum RTO > closer to 200ms. And in datacenter environments even 200ms can be > infeasibly high. > > neal > > >> >> Thanks, >> Jakob. >> >> >> On Dec 14, 2016, at 5:24 AM, Neal Cardwell wrote: >> >> On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) >> wrote: >> >>> Hi Neal, >>> >>> >>> >>> Thanks for your providing request information. >>> >>> >>> >>> About the delay of delayed ACK, I found another clue in a SIGCOMM paper >>> in 1988. In the page 14, a sentence is =E2=80=9CThe 4.5KBps senders wer= e talking to >>> 4.3BSD receivers which would delay an ack until 35% of the window was >>> filled or 200 ms had passed (i.e., an ack was delayed for 5-7 packets o= n >>> average).=E2=80=9D There is no reference about the 200 ms, so I guess t= his is the >>> particular delay appears for the first time. >>> >>> I try to calculate the value based on delayed packet numbers, packet >>> size and sending rate. In this case, the delayed packet number is 7, th= e >>> packet size is 576Byte (refer to RFC879 in 1983), and sundering rate is >>> 4.5Bps. The value is 896 ms! Longer than 200 ms. >>> >>> >>> >>> >. However, it's quite easy for a bulk transfer to never have any >>> delayed ACKs for most of its lifetime, during which the RTO gradually >>> converges toward the raw RTT value. Then when there is suddenly a delay= ed >>> ACK, there can be a spurious RTO. >>> >>> I am not very sure if I see your point. I think the key point is the RT= T >>> variation will be weakened when packets are sent in a burst (the >>> consequence of delayed ACK). And the spurious could only happen for = the >>> last few packets whose number is smaller than delayed packets, right? >>> >> >> Yes, there should only be a delayed ACK at the end of an application >> chunk if there is an odd number of packets. But we would expect roughly >> half of application chunks to have an odd number of packets. Though the >> proportion is probably higher than that, since many application chunks a= re >> just one packet (e.g. an HTTP or RPC request or response). >> >> >> >>> About your proposal about negotiation of delayed ACK, a potential >>> problem is that RTO will be stretched than before because you add extra >>> delay. As you have said, most of the packets will not exceed RTO even h= ost >>> enable delayed ACK for most large flows, but the retransmission will be >>> delayed (i.e., 5ms)also once one packet is lost. >>> >> >> The basic idea of the proposal is to tweak the RTO calculation and turn = a >> previously existing, historically motivated 200ms fixed "slop factor" in= to >> a dynamically negotiated 5ms "slop factor". In our experience that is >> almost always a win. >> >> neal >> >> >>> >>> >>> Best, >>> >>> Yali >>> >>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* Neal Cardwell [mailto:ncardwell@google= .com] >>> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2016=E5=B9=B412=E6=9C=8813=E6= =97=A5 23:18 >>> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* zhangyali (D) >>> *=E6=8A=84=E9=80=81:* tcpm@ietf.org >>> *=E4=B8=BB=E9=A2=98:* Re: [tcpm] A question about Delayed ACK and RTO >>> >>> >>> >>> On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) >>> wrote: >>> >>> Hi all, >>> >>> >>> >>> Recent days, I am doing some simulation about TCP performance in NS3. I >>> found a phenomenon is a default setting of TCP=E2=80=99s delayed ACK is= two packets >>> or 200ms. I am wondering if this setting is accord with some RFCs in I= ETF. >>> But After I referred to some RFCs, I just found some restrictions, such= as, >>> the delay must be less than 0.5ms (RFC1122). >>> >>> >>> >>> I believe the 200ms figure is due to historical reasons. AFAIK it's due >>> to the BSD delayed ACK behavior (see Stevens "TCP/IP Illustrated Volume= 2", >>> section 25.4 and figure 25.7, which describes the 200ms delayed ACK tim= er). >>> Then this value was inherited by other widely-deployed OSes. >>> >>> >>> >>> >>> >>> I think the delayed ACK has a close relationship with RTO. Take an >>> extreme scenario, if the delay is longer than RTO, many packets will be >>> retransmitted, which will waste many network resources. >>> >>> >>> >>> Yes, exactly. In theory, the RTO tries to be adaptive enough to measure >>> any RTT variations caused by delayed ACKs, and increase the RTO in resp= onse >>> to this. However, it's quite easy for a bulk transfer to never have any >>> delayed ACKs for most of its lifetime, during which the RTO gradually >>> converges toward the raw RTT value. Then when there is suddenly a delay= ed >>> ACK, there can be a spurious RTO. >>> >>> >>> >>> To avoid that, many TCP stacks (at least the major open source OSes) >>> have a hard-coded 200ms "slop factor" or "fudge factor", to try to neve= r >>> let their estimate of RTT variation fall below that 200ms value, to avo= id >>> this effect. >>> >>> >>> >>> So I want to know do we have some RFCs have given the exact value of >>> both? And if we permit any TCP stack to set them freely, what is the >>> mechanism to balance the mismatch between RTO and delayed ACK? >>> >>> >>> >>> I'm not aware of RFC specifications for exact values of both (delayed >>> ACK and RTO). However, the historical precedent is very strong, and the >>> 200ms delayed ACK value was very pronounced in Internet traces at least= as >>> recently as 2011, when I last looked at the effect. (Probably others ha= ve >>> more recent data points for the prevalence of 200ms delayed ACKs.) >>> >>> >>> >>> At IETF 97 our team at Google presented some features we use for >>> internal TCP traffic at Google, where the endpoints can negotiate the >>> specific constant to use for the maximum delayed ACK from the receiver = and >>> the corresponding minimum RTT delay variation for budgeting in the RTO = at >>> the sender: >>> >>> >>> >>> https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tc >>> p-options-for-low-latency-00.pdf >>> >>> >>> >>> As this slide deck notes, within Google we negotiate 5ms for delayed >>> ACKs. >>> >>> >>> >>> cheers, >>> >>> neal >>> >>> >>> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> > --001a1142d920c627cc0543a3220c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 14, 2016 at 12:21 PM, Jakob Heitz (jheitz) <jheitz@cisco.com>= ; wrote:
The problem in a virtualized environment is that RTT is highly variabl= e. Mostly sub millisecond with occasional spikes at several 100 ms. And not= just because of delayed ack, but due to effects of VM scheduling and load.=

True enough. But the RTO m= echanism need not try to drive the spurious RTO rate down to zero. There is= some trade-off between faster loss recovery and an increase in spurious re= transmits, and some associated cost-benefit analysis. These days IMHO the c= ost of a spurious timer-based loss repair attempt is relatively low, now th= at we have TLP and a number of nice undo mechanisms (FRTO, Eifel, DSACKs). = By contrast, in datacenter apps w/ sub-millisecond RTTs, there are prohibit= ive costs for delaying every timer-driven loss repair for 200ms.
=
cheers,
neal

=C2=A0
=

Thanks,
Jakob.


On Dec 14, 2016, at 9:06 AM, Neal Cardwell <ncardwell@google.com> wrote:

On Wed, Dec 14, 2016 at 11:56 AM, Jakob Heitz (j= heitz) <jheitz@cisco.com<= /a>> wrote:
Historically, the minimum RTO is 1 second and actual RTT is very rarel= y more than 1 second, so all this RTT calculation hardly ever matters anywa= y.

That may be true historically, but for many years major TCP implementations= (including Linux and FreeBSD) have used a minimum RTO closer to 200ms. And= in datacenter environments even 200ms can be infeasibly high.

neal
=C2=A0

Thanks,
Jakob.

On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) <= span dir=3D"ltr"> <zhangyali3= 69@huawei.com> wrote:

Hi Neal,

=C2=A0

Thanks for your providing request information.

=C2=A0

About the delay of delayed ACK, I found another clue in a S= IGCOMM paper in 1988. In the page 14, a sentence is =E2=80=9CThe 4.5KBps se= nders were talking to 4.3BSD receivers which would delay an ack until 35% of the window was filled or 200 ms had passed= (i.e., an ack was delayed for 5-7 packets on average).=E2=80=9D There is n= o reference about the 200 ms, so I guess this is the particular delay appea= rs for the first time.

I try to calculate the value based on delayed packet number= s, packet size and sending rate. In this case, the delayed packet number is= 7, the packet size is 576Byte (refer to RFC879 in 1983), and sundering rate is 4.5Bps. The value is 896 ms! Lon= ger than 200 ms.

=C2=A0

>. However, it's quite easy for a bulk transf= er to never have any delayed ACKs for most of its lifetime, during which th= e RTO gradually converges toward the raw RTT value. Then when there is suddenly a delayed ACK, there can be a spurious = RTO.

I am not very sure if I see your point. I think the key poi= nt is the RTT variation will be weakened when packets are sent in a burst (= the consequence of delayed ACK). =C2=A0=C2=A0And the spurious =C2=A0could only happen for the last few packets whose number= is smaller than delayed packets, right?


Yes, there should only be a delayed ACK at the end of an application c= hunk if there is an odd number of packets. But we would expect roughly half= of application chunks to have an odd number of packets. Though the proport= ion is probably higher than that, since many application chunks are just one packet (e.g. an HTTP or RPC req= uest or response).

=C2=A0=C2=A0

About your proposal about negotiation of del= ayed ACK, a potential problem is that RTO will be stretched than before bec= ause you add extra delay. As you have said, most of the packets will not exceed RTO even host enable delayed ACK= for most large flows, but the retransmission will be delayed (i.e., 5ms)al= so once one packet is lost.


The basic idea of the proposal is to tweak the RTO calculation and tur= n a previously existing, historically motivated 200ms fixed "slop fact= or" into a dynamically negotiated 5ms "slop factor". In our = experience that is almost always a win.

neal
=C2=A0

=C2=A0

Best,

Yali

=E5=8F=91=E4=BB=B6= =E4=BA=BA: Neal C= ardwell [mailto:n= cardwell@google.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 20= 16=E5=B9=B412=E6=9C=8813=E6=97=A5 23:18
=E6=94=B6=E4=BB=B6=E4=BA=BA: zhangyali (= D) <zhangya= li369@huawei.com>
=E6=8A=84=E9=80=81: tcpm@ietf.org
=E4=B8=BB=E9=A2=98: Re: [tcpm] A questio= n about Delayed ACK and RTO

=C2=A0

On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) <<= a href=3D"mailto:zhangyali369@huawei.com" target=3D"_blank">zhangyali369@hu= awei.com> wrote:

Hi all,

=C2=A0

Recent days, I am doing some simulation about TCP pe= rformance in NS3. I found a phenomenon is a default setting of TCP=E2=80=99= s delayed ACK is two packets or 200ms. I am wondering if this setting is ac= cord with =C2=A0some RFCs in IETF. But After I referred to some RFCs, I just found some restrictions, such as, the delay = must be less than 0.5ms (RFC1122).

=C2=A0

I believe the 200ms figure is due to historical reas= ons. AFAIK it's due to the BSD delayed ACK behavior (see Stevens "= TCP/IP Illustrated Volume 2", section 25.4 and figure 25.7, which desc= ribes the 200ms delayed ACK timer). Then this value was inherited by other widely-deployed OSes.

=C2=A0

=C2=A0=C2=A0

I think the delayed ACK has a close relationship wit= h RTO. Take an extreme scenario, if the delay is longer than RTO, many pack= ets will be retransmitted, which will waste many network resources.<= u>

=C2=A0

Yes, exactly. In theory, the RTO tries to be adaptiv= e enough to measure any RTT variations caused by delayed ACKs, and increase= the RTO in response to this. However, it's quite easy for a bulk trans= fer to never have any delayed ACKs for most of its lifetime, during which the RTO gradually converges toward the = raw RTT value. Then when there is suddenly a delayed ACK, there can be a sp= urious RTO.

=C2=A0

To avoid that, many TCP stacks (at least the major o= pen source OSes) have a hard-coded 200ms "slop factor" or "f= udge factor", to try to never let their estimate of RTT variation fall= below that 200ms value, to avoid this effect.=C2=A0

=C2=A0

So I want to know do we have some RFCs have given th= e exact value of both? And if we permit any TCP stack to set them freely, w= hat is the mechanism to balance the mismatch between RTO and delayed ACK?

=C2=A0

I'm not aware of RFC specifications for exact va= lues of both (delayed ACK and RTO). However, the historical precedent is ve= ry strong, and the 200ms delayed ACK value was very pronounced in Internet = traces at least as recently as 2011, when I last looked at the effect. (Probably others have more recent data points= for the prevalence of 200ms delayed ACKs.)

=C2=A0

At IETF 97 our team at Google presented some feature= s we use for internal TCP traffic at Google, where the endpoints can negoti= ate the specific constant to use for the maximum delayed ACK from the recei= ver and the corresponding minimum RTT delay variation for budgeting in the RTO at the sender:<= /p>

=C2=A0

=C2=A0

As this slide deck notes, within Google we negotiate= 5ms for delayed ACKs.

=C2=A0

cheers,=C2=A0

neal

=C2=A0


_______________________________________________
tcpm mailing list
tcpm@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/tcpm


--001a1142d920c627cc0543a3220c-- From nobody Wed Dec 14 11:20:35 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5628A129EC2 for ; Wed, 14 Dec 2016 11:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.795 X-Spam-Level: X-Spam-Status: No, score=-9.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmm28v3ysfCU for ; Wed, 14 Dec 2016 11:20:33 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D6C129EC1 for ; Wed, 14 Dec 2016 11:20:32 -0800 (PST) Received: from [128.9.184.244] ([128.9.184.244]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBEJK1dB010535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Dec 2016 11:20:04 -0800 (PST) To: Neal Cardwell , "Jakob Heitz (jheitz)" References: From: Joe Touch Message-ID: <37069250-13c5-7692-f137-0f441d57a90c@isi.edu> Date: Wed, 14 Dec 2016 11:20:01 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------210A99D607FAAD82E01B539E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiBBIHF1ZXN0aW9uIGFib3V0IERlbGF5ZWQgQUNL?= =?utf-8?q?_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Dec 2016 19:20:34 -0000 This is a multi-part message in MIME format. --------------210A99D607FAAD82E01B539E Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit We should not be optimizing TCP for specific environments; that's for operators to override. Joe On 12/14/2016 9:04 AM, Neal Cardwell wrote: > On Wed, Dec 14, 2016 at 11:56 AM, Jakob Heitz (jheitz) > > wrote: > > Historically, the minimum RTO is 1 second and actual RTT is very > rarely more than 1 second, so all this RTT calculation hardly ever > matters anyway. > > > That may be true historically, but for many years major TCP > implementations (including Linux and FreeBSD) have used a minimum RTO > closer to 200ms. And in datacenter environments even 200ms can be > infeasibly high. > > neal > --------------210A99D607FAAD82E01B539E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

We should not be optimizing TCP for specific environments; that's for operators to override.

Joe


On 12/14/2016 9:04 AM, Neal Cardwell wrote:
On Wed, Dec 14, 2016 at 11:56 AM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
Historically, the minimum RTO is 1 second and actual RTT is very rarely more than 1 second, so all this RTT calculation hardly ever matters anyway.

That may be true historically, but for many years major TCP implementations (including Linux and FreeBSD) have used a minimum RTO closer to 200ms. And in datacenter environments even 200ms can be infeasibly high.

neal
 

--------------210A99D607FAAD82E01B539E-- From nobody Wed Dec 14 17:45:30 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72462129F5A for ; Wed, 14 Dec 2016 17:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJB6RABYgmlP for ; Wed, 14 Dec 2016 17:45:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBE7129F42 for ; Wed, 14 Dec 2016 17:45:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCP09281; Thu, 15 Dec 2016 01:45:22 +0000 (GMT) Received: from DGGEMA406-HUB.china.huawei.com (10.3.20.47) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 15 Dec 2016 01:45:15 +0000 Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.220]) by DGGEMA406-HUB.china.huawei.com ([10.3.20.47]) with mapi id 14.03.0301.000; Thu, 15 Dec 2016 09:45:10 +0800 From: "zhangyali (D)" To: Neal Cardwell Thread-Topic: =?utf-8?B?562U5aSNOiBbdGNwbV0gQSBxdWVzdGlvbiBhYm91dCBEZWxheWVkIEFDSyBh?= =?utf-8?Q?nd_RTO?= Thread-Index: AdJVHvxj56KQ83ErQFe6OJTIeyiZRv//5A6A//5PGuCAAyNVgP/+rY4g Date: Thu, 15 Dec 2016 01:45:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.189.228] Content-Type: multipart/alternative; boundary="_000_A747A0713F56294D8FBE33E5C6B8F5815F546099DGGEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5851F5B3.01A4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.220, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fc172a1710963bfdb47de5d318acf5e0 Archived-At: Cc: "tcpm@ietf.org" Subject: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBBIHF1ZXN0aW9uIGFib3V0IERl?= =?utf-8?q?layed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Dec 2016 01:45:29 -0000 --_000_A747A0713F56294D8FBE33E5C6B8F5815F546099DGGEMA502MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBZZXMsIHRoZXJlIHNob3VsZCBvbmx5IGJlIGEgZGVsYXllZCBBQ0sgYXQgdGhlIGVuZCBvZiBh biBhcHBsaWNhdGlvbiBjaHVuayBpZiB0aGVyZSBpcyBhbiBvZGQgbnVtYmVyIG9mIHBhY2tldHMu IEJ1dCB3ZSB3b3VsZCBleHBlY3Qgcm91Z2hseSBoYWxmIG9mIGFwcGxpY2F0aW9uIGNodW5rcyB0 byBoYXZlIGFuIG9kZCBudW1iZXIgb2YgcGFja2V0cy4gVGhvdWdoIHRoZSBwcm9wb3J0aW9uIGlz IHByb2JhYmx5IGhpZ2hlciB0aGFuIHRoYXQsIHNpbmNlIG1hbnkgYXBwbGljYXRpb24gY2h1bmtz IGFyZSBqdXN0IG9uZSBwYWNrZXQgKGUuZy4gYW4gSFRUUCBvciBSUEMgcmVxdWVzdCBvciByZXNw b25zZSkuDQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCBvZGQgbnVtYmVyIG9mIHBhY2tldHMgbWF5 IG9jY3VyIHNwdXJpb3VzIFJUTyBtb3JlIGVhc2lseSwgYnV0IEkgdGhpbmsgZm9yIHRoZSBmbG93 cyBvd25pbmcganVzdCBvbmUgcGFja2V0IHNob3VsZCBub3QgYmUgYWZmZWN0ZWQgYnkgZGVsYXll ZCBBQ0suIEFGQUlLLCBzbG93LXN0YXJ0IHN0YWdlIHdpbGwgYmVnaW4gd2l0aCBvbmUgcGFja2V0 LCBhbmQgc2VuZGVyIHdpbGwgc2VuZCB0d28gcGFja2V0cyBhZnRlciBpdCByZWNlaXZlcyBhbiBB Q0suIElmIHRoZSBmaXJzdCBwYWNrZXQgaXMgb2JzdHJ1Y3RlZCBieSB0aGUgZGVsYXllZCBBQ0ss IHRoZSDigJhjbG9jayBhbGdvcml0aG3igJkgd2lsbCBiZSBicm9rZW4gZG93bi4gU28gcmVjZWl2 ZXIgc2hvdWxkIGp1ZGdlIGlmIHRoaXMgcGFja2V0IGlzIHRoZSBmaXJzdCBvbmUgaW4gdGhlIHNs b3ctc3RhcnQgc3RhZ2UsIGlmIHllcywgc2VuZCB0aGUgYWNrIGltbWVkaWF0ZWx5IG9uY2UgcmVj ZWl2aW5nIHRoZSBwYWNrZXQuDQoNCllhbGkNCg0K5Y+R5Lu25Lq6OiBOZWFsIENhcmR3ZWxsIFtt YWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTblubQxMuaciDE0 5pelIDIxOjI0DQrmlLbku7bkuro6IHpoYW5neWFsaSAoRCkgPHpoYW5neWFsaTM2OUBodWF3ZWku Y29tPg0K5oqE6YCBOiB0Y3BtQGlldGYub3JnDQrkuLvpopg6IFJlOiDnrZTlpI06IFt0Y3BtXSBB IHF1ZXN0aW9uIGFib3V0IERlbGF5ZWQgQUNLIGFuZCBSVE8NCg0KT24gV2VkLCBEZWMgMTQsIDIw MTYgYXQgNDo0OCBBTSwgemhhbmd5YWxpIChEKSA8emhhbmd5YWxpMzY5QGh1YXdlaS5jb208bWFp bHRvOnpoYW5neWFsaTM2OUBodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBOZWFsLA0KDQpUaGFua3Mg Zm9yIHlvdXIgcHJvdmlkaW5nIHJlcXVlc3QgaW5mb3JtYXRpb24uDQoNCkFib3V0IHRoZSBkZWxh eSBvZiBkZWxheWVkIEFDSywgSSBmb3VuZCBhbm90aGVyIGNsdWUgaW4gYSBTSUdDT01NIHBhcGVy IGluIDE5ODguIEluIHRoZSBwYWdlIDE0LCBhIHNlbnRlbmNlIGlzIOKAnFRoZSA0LjVLQnBzIHNl bmRlcnMgd2VyZSB0YWxraW5nIHRvIDQuM0JTRCByZWNlaXZlcnMgd2hpY2ggd291bGQgZGVsYXkg YW4gYWNrIHVudGlsIDM1JSBvZiB0aGUgd2luZG93IHdhcyBmaWxsZWQgb3IgMjAwIG1zIGhhZCBw YXNzZWQgKGkuZS4sIGFuIGFjayB3YXMgZGVsYXllZCBmb3IgNS03IHBhY2tldHMgb24gYXZlcmFn ZSku4oCdIFRoZXJlIGlzIG5vIHJlZmVyZW5jZSBhYm91dCB0aGUgMjAwIG1zLCBzbyBJIGd1ZXNz IHRoaXMgaXMgdGhlIHBhcnRpY3VsYXIgZGVsYXkgYXBwZWFycyBmb3IgdGhlIGZpcnN0IHRpbWUu DQpJIHRyeSB0byBjYWxjdWxhdGUgdGhlIHZhbHVlIGJhc2VkIG9uIGRlbGF5ZWQgcGFja2V0IG51 bWJlcnMsIHBhY2tldCBzaXplIGFuZCBzZW5kaW5nIHJhdGUuIEluIHRoaXMgY2FzZSwgdGhlIGRl bGF5ZWQgcGFja2V0IG51bWJlciBpcyA3LCB0aGUgcGFja2V0IHNpemUgaXMgNTc2Qnl0ZSAocmVm ZXIgdG8gUkZDODc5IGluIDE5ODMpLCBhbmQgc3VuZGVyaW5nIHJhdGUgaXMgNC41QnBzLiBUaGUg dmFsdWUgaXMgODk2IG1zISBMb25nZXIgdGhhbiAyMDAgbXMuDQoNCj4uIEhvd2V2ZXIsIGl0J3Mg cXVpdGUgZWFzeSBmb3IgYSBidWxrIHRyYW5zZmVyIHRvIG5ldmVyIGhhdmUgYW55IGRlbGF5ZWQg QUNLcyBmb3IgbW9zdCBvZiBpdHMgbGlmZXRpbWUsIGR1cmluZyB3aGljaCB0aGUgUlRPIGdyYWR1 YWxseSBjb252ZXJnZXMgdG93YXJkIHRoZSByYXcgUlRUIHZhbHVlLiBUaGVuIHdoZW4gdGhlcmUg aXMgc3VkZGVubHkgYSBkZWxheWVkIEFDSywgdGhlcmUgY2FuIGJlIGEgc3B1cmlvdXMgUlRPLg0K SSBhbSBub3QgdmVyeSBzdXJlIGlmIEkgc2VlIHlvdXIgcG9pbnQuIEkgdGhpbmsgdGhlIGtleSBw b2ludCBpcyB0aGUgUlRUIHZhcmlhdGlvbiB3aWxsIGJlIHdlYWtlbmVkIHdoZW4gcGFja2V0cyBh cmUgc2VudCBpbiBhIGJ1cnN0ICh0aGUgY29uc2VxdWVuY2Ugb2YgZGVsYXllZCBBQ0spLiAgIEFu ZCB0aGUgc3B1cmlvdXMgIGNvdWxkIG9ubHkgaGFwcGVuIGZvciB0aGUgbGFzdCBmZXcgcGFja2V0 cyB3aG9zZSBudW1iZXIgaXMgc21hbGxlciB0aGFuIGRlbGF5ZWQgcGFja2V0cywgcmlnaHQ/DQoN ClllcywgdGhlcmUgc2hvdWxkIG9ubHkgYmUgYSBkZWxheWVkIEFDSyBhdCB0aGUgZW5kIG9mIGFu IGFwcGxpY2F0aW9uIGNodW5rIGlmIHRoZXJlIGlzIGFuIG9kZCBudW1iZXIgb2YgcGFja2V0cy4g QnV0IHdlIHdvdWxkIGV4cGVjdCByb3VnaGx5IGhhbGYgb2YgYXBwbGljYXRpb24gY2h1bmtzIHRv IGhhdmUgYW4gb2RkIG51bWJlciBvZiBwYWNrZXRzLiBUaG91Z2ggdGhlIHByb3BvcnRpb24gaXMg cHJvYmFibHkgaGlnaGVyIHRoYW4gdGhhdCwgc2luY2UgbWFueSBhcHBsaWNhdGlvbiBjaHVua3Mg YXJlIGp1c3Qgb25lIHBhY2tldCAoZS5nLiBhbiBIVFRQIG9yIFJQQyByZXF1ZXN0IG9yIHJlc3Bv bnNlKS4NCg0KDQpBYm91dCB5b3VyIHByb3Bvc2FsIGFib3V0IG5lZ290aWF0aW9uIG9mIGRlbGF5 ZWQgQUNLLCBhIHBvdGVudGlhbCBwcm9ibGVtIGlzIHRoYXQgUlRPIHdpbGwgYmUgc3RyZXRjaGVk IHRoYW4gYmVmb3JlIGJlY2F1c2UgeW91IGFkZCBleHRyYSBkZWxheS4gQXMgeW91IGhhdmUgc2Fp ZCwgbW9zdCBvZiB0aGUgcGFja2V0cyB3aWxsIG5vdCBleGNlZWQgUlRPIGV2ZW4gaG9zdCBlbmFi bGUgZGVsYXllZCBBQ0sgZm9yIG1vc3QgbGFyZ2UgZmxvd3MsIGJ1dCB0aGUgcmV0cmFuc21pc3Np b24gd2lsbCBiZSBkZWxheWVkIChpLmUuLCA1bXMpYWxzbyBvbmNlIG9uZSBwYWNrZXQgaXMgbG9z dC4NCg0KVGhlIGJhc2ljIGlkZWEgb2YgdGhlIHByb3Bvc2FsIGlzIHRvIHR3ZWFrIHRoZSBSVE8g Y2FsY3VsYXRpb24gYW5kIHR1cm4gYSBwcmV2aW91c2x5IGV4aXN0aW5nLCBoaXN0b3JpY2FsbHkg bW90aXZhdGVkIDIwMG1zIGZpeGVkICJzbG9wIGZhY3RvciIgaW50byBhIGR5bmFtaWNhbGx5IG5l Z290aWF0ZWQgNW1zICJzbG9wIGZhY3RvciIuIEluIG91ciBleHBlcmllbmNlIHRoYXQgaXMgYWxt b3N0IGFsd2F5cyBhIHdpbi4NCg0KbmVhbA0KDQoNCkJlc3QsDQpZYWxpDQrlj5Hku7bkuro6IE5l YWwgQ2FyZHdlbGwgW21haWx0bzpuY2FyZHdlbGxAZ29vZ2xlLmNvbTxtYWlsdG86bmNhcmR3ZWxs QGdvb2dsZS5jb20+XQ0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0MTLmnIgxM+aXpSAyMzoxOA0K5pS2 5Lu25Lq6OiB6aGFuZ3lhbGkgKEQpIDx6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbTxtYWlsdG86emhh bmd5YWxpMzY5QGh1YXdlaS5jb20+Pg0K5oqE6YCBOiB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3Bt QGlldGYub3JnPg0K5Li76aKYOiBSZTogW3RjcG1dIEEgcXVlc3Rpb24gYWJvdXQgRGVsYXllZCBB Q0sgYW5kIFJUTw0KDQpPbiBUdWUsIERlYyAxMywgMjAxNiBhdCAzOjU4IEFNLCB6aGFuZ3lhbGkg KEQpIDx6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbTxtYWlsdG86emhhbmd5YWxpMzY5QGh1YXdlaS5j b20+PiB3cm90ZToNCkhpIGFsbCwNCg0KUmVjZW50IGRheXMsIEkgYW0gZG9pbmcgc29tZSBzaW11 bGF0aW9uIGFib3V0IFRDUCBwZXJmb3JtYW5jZSBpbiBOUzMuIEkgZm91bmQgYSBwaGVub21lbm9u IGlzIGEgZGVmYXVsdCBzZXR0aW5nIG9mIFRDUOKAmXMgZGVsYXllZCBBQ0sgaXMgdHdvIHBhY2tl dHMgb3IgMjAwbXMuIEkgYW0gd29uZGVyaW5nIGlmIHRoaXMgc2V0dGluZyBpcyBhY2NvcmQgd2l0 aCAgc29tZSBSRkNzIGluIElFVEYuIEJ1dCBBZnRlciBJIHJlZmVycmVkIHRvIHNvbWUgUkZDcywg SSBqdXN0IGZvdW5kIHNvbWUgcmVzdHJpY3Rpb25zLCBzdWNoIGFzLCB0aGUgZGVsYXkgbXVzdCBi ZSBsZXNzIHRoYW4gMC41bXMgKFJGQzExMjIpLg0KDQpJIGJlbGlldmUgdGhlIDIwMG1zIGZpZ3Vy ZSBpcyBkdWUgdG8gaGlzdG9yaWNhbCByZWFzb25zLiBBRkFJSyBpdCdzIGR1ZSB0byB0aGUgQlNE IGRlbGF5ZWQgQUNLIGJlaGF2aW9yIChzZWUgU3RldmVucyAiVENQL0lQIElsbHVzdHJhdGVkIFZv bHVtZSAyIiwgc2VjdGlvbiAyNS40IGFuZCBmaWd1cmUgMjUuNywgd2hpY2ggZGVzY3JpYmVzIHRo ZSAyMDBtcyBkZWxheWVkIEFDSyB0aW1lcikuIFRoZW4gdGhpcyB2YWx1ZSB3YXMgaW5oZXJpdGVk IGJ5IG90aGVyIHdpZGVseS1kZXBsb3llZCBPU2VzLg0KDQoNCkkgdGhpbmsgdGhlIGRlbGF5ZWQg QUNLIGhhcyBhIGNsb3NlIHJlbGF0aW9uc2hpcCB3aXRoIFJUTy4gVGFrZSBhbiBleHRyZW1lIHNj ZW5hcmlvLCBpZiB0aGUgZGVsYXkgaXMgbG9uZ2VyIHRoYW4gUlRPLCBtYW55IHBhY2tldHMgd2ls bCBiZSByZXRyYW5zbWl0dGVkLCB3aGljaCB3aWxsIHdhc3RlIG1hbnkgbmV0d29yayByZXNvdXJj ZXMuDQoNClllcywgZXhhY3RseS4gSW4gdGhlb3J5LCB0aGUgUlRPIHRyaWVzIHRvIGJlIGFkYXB0 aXZlIGVub3VnaCB0byBtZWFzdXJlIGFueSBSVFQgdmFyaWF0aW9ucyBjYXVzZWQgYnkgZGVsYXll ZCBBQ0tzLCBhbmQgaW5jcmVhc2UgdGhlIFJUTyBpbiByZXNwb25zZSB0byB0aGlzLiBIb3dldmVy LCBpdCdzIHF1aXRlIGVhc3kgZm9yIGEgYnVsayB0cmFuc2ZlciB0byBuZXZlciBoYXZlIGFueSBk ZWxheWVkIEFDS3MgZm9yIG1vc3Qgb2YgaXRzIGxpZmV0aW1lLCBkdXJpbmcgd2hpY2ggdGhlIFJU TyBncmFkdWFsbHkgY29udmVyZ2VzIHRvd2FyZCB0aGUgcmF3IFJUVCB2YWx1ZS4gVGhlbiB3aGVu IHRoZXJlIGlzIHN1ZGRlbmx5IGEgZGVsYXllZCBBQ0ssIHRoZXJlIGNhbiBiZSBhIHNwdXJpb3Vz IFJUTy4NCg0KVG8gYXZvaWQgdGhhdCwgbWFueSBUQ1Agc3RhY2tzIChhdCBsZWFzdCB0aGUgbWFq b3Igb3BlbiBzb3VyY2UgT1NlcykgaGF2ZSBhIGhhcmQtY29kZWQgMjAwbXMgInNsb3AgZmFjdG9y IiBvciAiZnVkZ2UgZmFjdG9yIiwgdG8gdHJ5IHRvIG5ldmVyIGxldCB0aGVpciBlc3RpbWF0ZSBv ZiBSVFQgdmFyaWF0aW9uIGZhbGwgYmVsb3cgdGhhdCAyMDBtcyB2YWx1ZSwgdG8gYXZvaWQgdGhp cyBlZmZlY3QuDQoNClNvIEkgd2FudCB0byBrbm93IGRvIHdlIGhhdmUgc29tZSBSRkNzIGhhdmUg Z2l2ZW4gdGhlIGV4YWN0IHZhbHVlIG9mIGJvdGg/IEFuZCBpZiB3ZSBwZXJtaXQgYW55IFRDUCBz dGFjayB0byBzZXQgdGhlbSBmcmVlbHksIHdoYXQgaXMgdGhlIG1lY2hhbmlzbSB0byBiYWxhbmNl IHRoZSBtaXNtYXRjaCBiZXR3ZWVuIFJUTyBhbmQgZGVsYXllZCBBQ0s/DQoNCkknbSBub3QgYXdh cmUgb2YgUkZDIHNwZWNpZmljYXRpb25zIGZvciBleGFjdCB2YWx1ZXMgb2YgYm90aCAoZGVsYXll ZCBBQ0sgYW5kIFJUTykuIEhvd2V2ZXIsIHRoZSBoaXN0b3JpY2FsIHByZWNlZGVudCBpcyB2ZXJ5 IHN0cm9uZywgYW5kIHRoZSAyMDBtcyBkZWxheWVkIEFDSyB2YWx1ZSB3YXMgdmVyeSBwcm9ub3Vu Y2VkIGluIEludGVybmV0IHRyYWNlcyBhdCBsZWFzdCBhcyByZWNlbnRseSBhcyAyMDExLCB3aGVu IEkgbGFzdCBsb29rZWQgYXQgdGhlIGVmZmVjdC4gKFByb2JhYmx5IG90aGVycyBoYXZlIG1vcmUg cmVjZW50IGRhdGEgcG9pbnRzIGZvciB0aGUgcHJldmFsZW5jZSBvZiAyMDBtcyBkZWxheWVkIEFD S3MuKQ0KDQpBdCBJRVRGIDk3IG91ciB0ZWFtIGF0IEdvb2dsZSBwcmVzZW50ZWQgc29tZSBmZWF0 dXJlcyB3ZSB1c2UgZm9yIGludGVybmFsIFRDUCB0cmFmZmljIGF0IEdvb2dsZSwgd2hlcmUgdGhl IGVuZHBvaW50cyBjYW4gbmVnb3RpYXRlIHRoZSBzcGVjaWZpYyBjb25zdGFudCB0byB1c2UgZm9y IHRoZSBtYXhpbXVtIGRlbGF5ZWQgQUNLIGZyb20gdGhlIHJlY2VpdmVyIGFuZCB0aGUgY29ycmVz cG9uZGluZyBtaW5pbXVtIFJUVCBkZWxheSB2YXJpYXRpb24gZm9yIGJ1ZGdldGluZyBpbiB0aGUg UlRPIGF0IHRoZSBzZW5kZXI6DQoNCiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv OTcvc2xpZGVzL3NsaWRlcy05Ny10Y3BtLXRjcC1vcHRpb25zLWZvci1sb3ctbGF0ZW5jeS0wMC5w ZGYNCg0KQXMgdGhpcyBzbGlkZSBkZWNrIG5vdGVzLCB3aXRoaW4gR29vZ2xlIHdlIG5lZ290aWF0 ZSA1bXMgZm9yIGRlbGF5ZWQgQUNLcy4NCg0KY2hlZXJzLA0KbmVhbA0KDQoNCg== --_000_A747A0713F56294D8FBE33E5C6B8F5815F546099DGGEMA502MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7DQo8L3NwYW4+WWVzLCB0 aGVyZSBzaG91bGQgb25seSBiZSBhIGRlbGF5ZWQgQUNLIGF0IHRoZSBlbmQgb2YgYW4gYXBwbGlj YXRpb24gY2h1bmsgaWYgdGhlcmUgaXMgYW4gb2RkIG51bWJlciBvZiBwYWNrZXRzLiBCdXQgd2Ug d291bGQgZXhwZWN0IHJvdWdobHkgaGFsZiBvZiBhcHBsaWNhdGlvbiBjaHVua3MgdG8gaGF2ZSBh biBvZGQgbnVtYmVyIG9mIHBhY2tldHMuIFRob3VnaCB0aGUgcHJvcG9ydGlvbiBpcyBwcm9iYWJs eSBoaWdoZXIgdGhhbiB0aGF0LA0KIHNpbmNlIG1hbnkgYXBwbGljYXRpb24gY2h1bmtzIGFyZSBq dXN0IG9uZSBwYWNrZXQgKGUuZy4gYW4gSFRUUCBvciBSUEMgcmVxdWVzdCBvciByZXNwb25zZSku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCB5b3UgdGhh dCBvZGQgbnVtYmVyIG9mIHBhY2tldHMgbWF5IG9jY3VyIHNwdXJpb3VzIFJUTyBtb3JlIGVhc2ls eSwgYnV0IEkgdGhpbmsgZm9yIHRoZSBmbG93cyBvd25pbmcganVzdCBvbmUgcGFja2V0IHNob3Vs ZCBub3QgYmUgYWZmZWN0ZWQgYnkgZGVsYXllZA0KIEFDSy4gQUZBSUssIHNsb3ctc3RhcnQgc3Rh Z2Ugd2lsbCBiZWdpbiB3aXRoIG9uZSBwYWNrZXQsIGFuZCBzZW5kZXIgd2lsbCBzZW5kIHR3byBw YWNrZXRzIGFmdGVyIGl0IHJlY2VpdmVzIGFuIEFDSy4gSWYgdGhlIGZpcnN0IHBhY2tldCBpcyBv YnN0cnVjdGVkIGJ5IHRoZSBkZWxheWVkIEFDSywgdGhlIOKAmGNsb2NrIGFsZ29yaXRobeKAmSB3 aWxsIGJlIGJyb2tlbiBkb3duLiBTbyByZWNlaXZlciBzaG91bGQganVkZ2UgaWYgdGhpcyBwYWNr ZXQgaXMNCiB0aGUgZmlyc3Qgb25lIGluIHRoZSBzbG93LXN0YXJ0IHN0YWdlLCBpZiB5ZXMsIHNl bmQgdGhlIGFjayBpbW1lZGlhdGVseSBvbmNlIHJlY2VpdmluZyB0aGUgcGFja2V0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WWFsaTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPuWPkeS7tuS6ujwvc3Bhbj48L2I+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWYiPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4g TmVhbCBDYXJkd2VsbA0KIFttYWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb21dIDxicj4NCjxiPjxz cGFuIGxhbmc9IlpILUNOIj7lj5HpgIHml7bpl7Q8L3NwYW4+OjwvYj4gMjAxNjxzcGFuIGxhbmc9 IlpILUNOIj7lubQ8L3NwYW4+MTI8c3BhbiBsYW5nPSJaSC1DTiI+5pyIPC9zcGFuPjE0PHNwYW4g bGFuZz0iWkgtQ04iPuaXpTwvc3Bhbj4gMjE6MjQ8YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1DTiI+ 5pS25Lu25Lq6PC9zcGFuPjo8L2I+IHpoYW5neWFsaSAoRCkgJmx0O3poYW5neWFsaTM2OUBodWF3 ZWkuY29tJmd0Ozxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7mioTpgIE8L3NwYW4+OjwvYj4g dGNwbUBpZXRmLm9yZzxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7kuLvpopg8L3NwYW4+Ojwv Yj4gUmU6IDxzcGFuIGxhbmc9IlpILUNOIj7nrZTlpI08L3NwYW4+OiBbdGNwbV0gQSBxdWVzdGlv biBhYm91dCBEZWxheWVkIEFDSyBhbmQgUlRPPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIERlYyAxNCwgMjAxNiBhdCA0OjQ4IEFNLCB6 aGFuZ3lhbGkgKEQpICZsdDs8YSBocmVmPSJtYWlsdG86emhhbmd5YWxpMzY5QGh1YXdlaS5jb20i IHRhcmdldD0iX2JsYW5rIj56aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIE5lYWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlv dXIgcHJvdmlkaW5nIHJlcXVlc3QgaW5mb3JtYXRpb24uDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFib3V0IHRo ZSBkZWxheSBvZiBkZWxheWVkIEFDSywgSSBmb3VuZCBhbm90aGVyIGNsdWUgaW4gYSBTSUdDT01N IHBhcGVyIGluIDE5ODguIEluIHRoZSBwYWdlIDE0LCBhIHNlbnRlbmNlIGlzIOKAnFRoZQ0KIDQu NUtCcHMgc2VuZGVycyB3ZXJlIHRhbGtpbmcgdG8gNC4zQlNEIHJlY2VpdmVycyB3aGljaCB3b3Vs ZCBkZWxheSBhbiBhY2sgdW50aWwgMzUlIG9mIHRoZSB3aW5kb3cgd2FzIGZpbGxlZCBvciAyMDAg bXMgaGFkIHBhc3NlZCAoaS5lLiwgYW4gYWNrIHdhcyBkZWxheWVkIGZvciA1LTcgcGFja2V0cyBv biBhdmVyYWdlKS7igJ0gVGhlcmUgaXMgbm8gcmVmZXJlbmNlIGFib3V0IHRoZSAyMDAgbXMsIHNv IEkgZ3Vlc3MgdGhpcyBpcyB0aGUgcGFydGljdWxhcg0KIGRlbGF5IGFwcGVhcnMgZm9yIHRoZSBm aXJzdCB0aW1lLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SSB0cnkgdG8gY2FsY3VsYXRlIHRoZSB2YWx1ZSBiYXNlZCBvbiBkZWxh eWVkIHBhY2tldCBudW1iZXJzLCBwYWNrZXQgc2l6ZSBhbmQgc2VuZGluZyByYXRlLiBJbiB0aGlz IGNhc2UsIHRoZSBkZWxheWVkDQogcGFja2V0IG51bWJlciBpcyA3LCB0aGUgcGFja2V0IHNpemUg aXMgNTc2Qnl0ZSAocmVmZXIgdG8gUkZDODc5IGluIDE5ODMpLCBhbmQgc3VuZGVyaW5nIHJhdGUg aXMgNC41QnBzLiBUaGUgdmFsdWUgaXMgODk2IG1zISBMb25nZXIgdGhhbiAyMDAgbXMuDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZndDs8L3NwYW4+LiBIb3dldmVyLCBpdCdzIHF1aXRlIGVhc3kgZm9yIGEgYnVs ayB0cmFuc2ZlciB0byBuZXZlciBoYXZlIGFueSBkZWxheWVkIEFDS3MgZm9yIG1vc3Qgb2YgaXRz IGxpZmV0aW1lLCBkdXJpbmcNCiB3aGljaCB0aGUgUlRPIGdyYWR1YWxseSBjb252ZXJnZXMgdG93 YXJkIHRoZSByYXcgUlRUIHZhbHVlLiBUaGVuIHdoZW4gdGhlcmUgaXMgc3VkZGVubHkgYSBkZWxh eWVkIEFDSywgdGhlcmUgY2FuIGJlIGEgc3B1cmlvdXMgUlRPLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gbm90IHZlcnkgc3VyZSBpZiBJ IHNlZSB5b3VyIHBvaW50LiBJIHRoaW5rIHRoZSBrZXkgcG9pbnQgaXMgdGhlIFJUVCB2YXJpYXRp b24gd2lsbCBiZSB3ZWFrZW5lZCB3aGVuIHBhY2tldHMgYXJlDQogc2VudCBpbiBhIGJ1cnN0ICh0 aGUgY29uc2VxdWVuY2Ugb2YgZGVsYXllZCBBQ0spLiAmbmJzcDsmbmJzcDtBbmQgdGhlIHNwdXJp b3VzICZuYnNwO2NvdWxkIG9ubHkgaGFwcGVuIGZvciB0aGUgbGFzdCBmZXcgcGFja2V0cyB3aG9z ZSBudW1iZXIgaXMgc21hbGxlciB0aGFuIGRlbGF5ZWQgcGFja2V0cywgcmlnaHQ/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhlcmUgc2hvdWxkIG9ubHkgYmUgYSBkZWxheWVkIEFD SyBhdCB0aGUgZW5kIG9mIGFuIGFwcGxpY2F0aW9uIGNodW5rIGlmIHRoZXJlIGlzIGFuIG9kZCBu dW1iZXIgb2YgcGFja2V0cy4gQnV0IHdlIHdvdWxkIGV4cGVjdCByb3VnaGx5IGhhbGYgb2YgYXBw bGljYXRpb24gY2h1bmtzIHRvIGhhdmUgYW4gb2RkIG51bWJlciBvZiBwYWNrZXRzLiBUaG91Z2gg dGhlIHByb3BvcnRpb24gaXMgcHJvYmFibHkNCiBoaWdoZXIgdGhhbiB0aGF0LCBzaW5jZSBtYW55 IGFwcGxpY2F0aW9uIGNodW5rcyBhcmUganVzdCBvbmUgcGFja2V0IChlLmcuIGFuIEhUVFAgb3Ig UlBDIHJlcXVlc3Qgb3IgcmVzcG9uc2UpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5BYm91dCB5b3VyIHByb3Bvc2FsIGFib3V0IG5lZ290aWF0aW9uIG9mIGRlbGF5ZWQg QUNLLCBhIHBvdGVudGlhbCBwcm9ibGVtIGlzIHRoYXQgUlRPIHdpbGwgYmUgc3RyZXRjaGVkDQog dGhhbiBiZWZvcmUgYmVjYXVzZSB5b3UgYWRkIGV4dHJhIGRlbGF5LiBBcyB5b3UgaGF2ZSBzYWlk LCBtb3N0IG9mIHRoZSBwYWNrZXRzIHdpbGwgbm90IGV4Y2VlZCBSVE8gZXZlbiBob3N0IGVuYWJs ZSBkZWxheWVkIEFDSyBmb3IgbW9zdCBsYXJnZSBmbG93cywgYnV0IHRoZSByZXRyYW5zbWlzc2lv biB3aWxsIGJlIGRlbGF5ZWQgKGkuZS4sIDVtcylhbHNvIG9uY2Ugb25lIHBhY2tldCBpcyBsb3N0 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYmFzaWMgaWRlYSBvZiB0aGUgcHJvcG9z YWwgaXMgdG8gdHdlYWsgdGhlIFJUTyBjYWxjdWxhdGlvbiBhbmQgdHVybiBhIHByZXZpb3VzbHkg ZXhpc3RpbmcsIGhpc3RvcmljYWxseSBtb3RpdmF0ZWQgMjAwbXMgZml4ZWQgJnF1b3Q7c2xvcCBm YWN0b3ImcXVvdDsgaW50byBhIGR5bmFtaWNhbGx5IG5lZ290aWF0ZWQgNW1zICZxdW90O3Nsb3Ag ZmFjdG9yJnF1b3Q7LiBJbiBvdXIgZXhwZXJpZW5jZSB0aGF0IGlzIGFsbW9zdCBhbHdheXMgYSB3 aW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pm5lYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPllhbGk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxh bmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrlrovkvZMiPuWP keS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+DQogTmVhbCBDYXJkd2VsbCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuY2FyZHdlbGxA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5jYXJkd2VsbEBnb29nbGUuY29tPC9hPl0NCjxi cj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk65a6L5L2TIj7lj5HpgIHml7bpl7Q8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiAyMDE2PC9zcGFuPjxzcGFuIGxhbmc9IlpI LUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrlrovkvZMiPuW5tDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj4xMjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ MTM8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OuWui+S9kyI+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KIDIzOjE4PGJyPg0KPC9z cGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTrlrovkvZMiPuaUtuS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Ojwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+IHpoYW5neWFsaSAoRCkgJmx0OzxhIGhyZWY9Im1haWx0bzp6 aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnpoYW5neWFsaTM2OUBodWF3 ZWkuY29tPC9hPiZndDs8YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5oqE6YCBPC9zcGFuPjwvYj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCjxhIGhyZWY9Im1haWx0 bzp0Y3BtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQo8 L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OuWui+S9kyI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj46PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj4gUmU6IFt0Y3BtXSBBIHF1ZXN0aW9uIGFib3V0IERlbGF5ZWQN CiBBQ0sgYW5kIFJUTzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBEZWMgMTMsIDIwMTYgYXQgMzo1OCBB TSwgemhhbmd5YWxpIChEKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpoYW5neWFsaTM2OUBodWF3ZWku Y29tIiB0YXJnZXQ9Il9ibGFuayI+emhhbmd5YWxpMzY5QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIGFsbCw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlY2VudCBkYXlzLCBJIGFtIGRvaW5nIHNvbWUg c2ltdWxhdGlvbiBhYm91dCBUQ1AgcGVyZm9ybWFuY2UgaW4gTlMzLiBJIGZvdW5kIGEgcGhlbm9t ZW5vbiBpcyBhIGRlZmF1bHQgc2V0dGluZyBvZiBUQ1DigJlzIGRlbGF5ZWQgQUNLIGlzIHR3byBw YWNrZXRzIG9yIDIwMG1zLiBJIGFtIHdvbmRlcmluZyBpZiB0aGlzDQogc2V0dGluZyBpcyBhY2Nv cmQgd2l0aCAmbmJzcDtzb21lIFJGQ3MgaW4gSUVURi4gQnV0IEFmdGVyIEkgcmVmZXJyZWQgdG8g c29tZSBSRkNzLCBJIGp1c3QgZm91bmQgc29tZSByZXN0cmljdGlvbnMsIHN1Y2ggYXMsIHRoZSBk ZWxheSBtdXN0IGJlIGxlc3MgdGhhbiAwLjVtcyAoUkZDMTEyMikuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkkgYmVsaWV2ZSB0aGUgMjAwbXMgZmlndXJlIGlzIGR1ZSB0byBoaXN0b3JpY2FsIHJl YXNvbnMuIEFGQUlLIGl0J3MgZHVlIHRvIHRoZSBCU0QgZGVsYXllZCBBQ0sgYmVoYXZpb3IgKHNl ZSBTdGV2ZW5zICZxdW90O1RDUC9JUCBJbGx1c3RyYXRlZCBWb2x1bWUgMiZxdW90Oywgc2VjdGlv biAyNS40IGFuZCBmaWd1cmUgMjUuNywNCiB3aGljaCBkZXNjcmliZXMgdGhlIDIwMG1zIGRlbGF5 ZWQgQUNLIHRpbWVyKS4gVGhlbiB0aGlzIHZhbHVlIHdhcyBpbmhlcml0ZWQgYnkgb3RoZXIgd2lk ZWx5LWRlcGxveWVkIE9TZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGUgZGVsYXllZCBBQ0sgaGFz IGEgY2xvc2UgcmVsYXRpb25zaGlwIHdpdGggUlRPLiBUYWtlIGFuIGV4dHJlbWUgc2NlbmFyaW8s IGlmIHRoZSBkZWxheSBpcyBsb25nZXIgdGhhbiBSVE8sIG1hbnkgcGFja2V0cyB3aWxsIGJlIHJl dHJhbnNtaXR0ZWQsIHdoaWNoIHdpbGwgd2FzdGUgbWFueSBuZXR3b3JrDQogcmVzb3VyY2VzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMsIGV4YWN0bHkuIEluIHRoZW9yeSwgdGhlIFJUTyB0 cmllcyB0byBiZSBhZGFwdGl2ZSBlbm91Z2ggdG8gbWVhc3VyZSBhbnkgUlRUIHZhcmlhdGlvbnMg Y2F1c2VkIGJ5IGRlbGF5ZWQgQUNLcywgYW5kIGluY3JlYXNlIHRoZSBSVE8gaW4gcmVzcG9uc2Ug dG8gdGhpcy4gSG93ZXZlciwgaXQncyBxdWl0ZQ0KIGVhc3kgZm9yIGEgYnVsayB0cmFuc2ZlciB0 byBuZXZlciBoYXZlIGFueSBkZWxheWVkIEFDS3MgZm9yIG1vc3Qgb2YgaXRzIGxpZmV0aW1lLCBk dXJpbmcgd2hpY2ggdGhlIFJUTyBncmFkdWFsbHkgY29udmVyZ2VzIHRvd2FyZCB0aGUgcmF3IFJU VCB2YWx1ZS4gVGhlbiB3aGVuIHRoZXJlIGlzIHN1ZGRlbmx5IGEgZGVsYXllZCBBQ0ssIHRoZXJl IGNhbiBiZSBhIHNwdXJpb3VzIFJUTy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIGF2b2lkIHRoYXQsIG1hbnkgVENQIHN0YWNrcyAo YXQgbGVhc3QgdGhlIG1ham9yIG9wZW4gc291cmNlIE9TZXMpIGhhdmUgYSBoYXJkLWNvZGVkIDIw MG1zICZxdW90O3Nsb3AgZmFjdG9yJnF1b3Q7IG9yICZxdW90O2Z1ZGdlIGZhY3RvciZxdW90Oywg dG8gdHJ5IHRvIG5ldmVyIGxldCB0aGVpciBlc3RpbWF0ZSBvZiBSVFQgdmFyaWF0aW9uDQogZmFs bCBiZWxvdyB0aGF0IDIwMG1zIHZhbHVlLCB0byBhdm9pZCB0aGlzIGVmZmVjdC4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNv IEkgd2FudCB0byBrbm93IGRvIHdlIGhhdmUgc29tZSBSRkNzIGhhdmUgZ2l2ZW4gdGhlIGV4YWN0 IHZhbHVlIG9mIGJvdGg/IEFuZCBpZiB3ZSBwZXJtaXQgYW55IFRDUCBzdGFjayB0byBzZXQgdGhl bSBmcmVlbHksIHdoYXQgaXMgdGhlIG1lY2hhbmlzbSB0byBiYWxhbmNlIHRoZSBtaXNtYXRjaCBi ZXR3ZWVuDQogUlRPIGFuZCBkZWxheWVkIEFDSz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdt IG5vdCBhd2FyZSBvZiBSRkMgc3BlY2lmaWNhdGlvbnMgZm9yIGV4YWN0IHZhbHVlcyBvZiBib3Ro IChkZWxheWVkIEFDSyBhbmQgUlRPKS4gSG93ZXZlciwgdGhlIGhpc3RvcmljYWwgcHJlY2VkZW50 IGlzIHZlcnkgc3Ryb25nLCBhbmQgdGhlIDIwMG1zIGRlbGF5ZWQgQUNLIHZhbHVlIHdhcyB2ZXJ5 IHByb25vdW5jZWQNCiBpbiBJbnRlcm5ldCB0cmFjZXMgYXQgbGVhc3QgYXMgcmVjZW50bHkgYXMg MjAxMSwgd2hlbiBJIGxhc3QgbG9va2VkIGF0IHRoZSBlZmZlY3QuIChQcm9iYWJseSBvdGhlcnMg aGF2ZSBtb3JlIHJlY2VudCBkYXRhIHBvaW50cyBmb3IgdGhlIHByZXZhbGVuY2Ugb2YgMjAwbXMg ZGVsYXllZCBBQ0tzLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkF0IElFVEYgOTcgb3VyIHRlYW0gYXQgR29vZ2xlIHByZXNlbnRlZCBz b21lIGZlYXR1cmVzIHdlIHVzZSBmb3IgaW50ZXJuYWwgVENQIHRyYWZmaWMgYXQgR29vZ2xlLCB3 aGVyZSB0aGUgZW5kcG9pbnRzIGNhbiBuZWdvdGlhdGUgdGhlIHNwZWNpZmljIGNvbnN0YW50IHRv IHVzZSBmb3IgdGhlIG1heGltdW0gZGVsYXllZA0KIEFDSyBmcm9tIHRoZSByZWNlaXZlciBhbmQg dGhlIGNvcnJlc3BvbmRpbmcgbWluaW11bSBSVFQgZGVsYXkgdmFyaWF0aW9uIGZvciBidWRnZXRp bmcgaW4gdGhlIFJUTyBhdCB0aGUgc2VuZGVyOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVzLTk3LXRjcG0tdGNwLW9wdGlv bnMtZm9yLWxvdy1sYXRlbmN5LTAwLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05Ny10Y3BtLXRjcC1vcHRpb25z LWZvci1sb3ctbGF0ZW5jeS0wMC5wZGY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyB0aGlzIHNsaWRlIGRlY2sgbm90ZXMsIHdp dGhpbiBHb29nbGUgd2UgbmVnb3RpYXRlIDVtcyBmb3IgZGVsYXllZCBBQ0tzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Y2hlZXJzLCZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5uZWFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A747A0713F56294D8FBE33E5C6B8F5815F546099DGGEMA502MBSchi_-- From nobody Wed Dec 14 18:02:31 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0249E129FB0 for ; Wed, 14 Dec 2016 18:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.106 X-Spam-Level: X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_XlUxLM8L0s for ; Wed, 14 Dec 2016 18:02:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6002A129531 for ; Wed, 14 Dec 2016 18:02:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCP10691; Thu, 15 Dec 2016 02:02:24 +0000 (GMT) Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 15 Dec 2016 02:02:23 +0000 Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.220]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0301.000; Thu, 15 Dec 2016 10:02:13 +0800 From: "zhangyali (D)" To: Joe Touch , Neal Cardwell , "Jakob Heitz (jheitz)" Thread-Topic: =?gb2312?B?W3RjcG1dILTwuLQ6IEEgcXVlc3Rpb24gYWJvdXQgRGVsYXllZCBBQ0sgYW5k?= =?gb2312?Q?_RTO?= Thread-Index: AQHSViwtlIKhgt0wv06RrJTZqFjRVaEHS6yAgADyWFA= Date: Thu, 15 Dec 2016 02:02:13 +0000 Message-ID: References: <37069250-13c5-7692-f137-0f441d57a90c@isi.edu> In-Reply-To: <37069250-13c5-7692-f137-0f441d57a90c@isi.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.189.228] Content-Type: multipart/alternative; boundary="_000_A747A0713F56294D8FBE33E5C6B8F5815F5460C4DGGEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5851F9B1.0027, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.220, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d363b1bc5827e1986390321e92d320ce Archived-At: Cc: "tcpm@ietf.org" Subject: [tcpm] =?gb2312?b?tPC4tDogILTwuLQ6IEEgcXVlc3Rpb24gYWJvdXQgRGVs?= =?gb2312?b?YXllZCBBQ0sgYW5kIFJUTw==?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Dec 2016 02:02:31 -0000 --_000_A747A0713F56294D8FBE33E5C6B8F5815F5460C4DGGEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSm9lLA0KDQpJIHJlYWxseSBhZ3JlZSB3aXRoIHlvdSBhYm91dCBUQ1AgbWVjaGFuaXNtIHNo b3VsZCBnZW5lcmFsIGZvciBhbGwgYXJlYXMsIGluY2x1ZGluZyB3YW4gYW5kIGRhdGEgY2VudGVy Lg0KDQpCdXQgZXZlcnkgc2NlbmFyaW9zIGhhdmUgdGhlaXIgb3duIGNoYXJhY3RlcmlzdGljcy4g RGF0YSBjZW50ZXIgaGFzIHNvbWUgZGlzdGluY3RpdmUgZmVhdHVyZXMsIHN1Y2ggYXMsIHVsdHJh bG93IFJUVCwgYmVjYXVzZSBvZiBjZW50cmFsaXplZCBsb2NhdGlvbiwgbGVzcyBob3BzLCBhbmQg c28gb24uIFRoZXNlIGZlYXR1cmVzIGRldGVybWluZXMgZGlmZmVyZW50IHJlcXVpcmVtZW50IGZv ciBUQ1AgZGVmYXVsdCBjb25maWd1cmF0aW9uLCBjb21wYXJlZCB3aXRoIHdhbiBzY2VuYXJpby4g SXQgaXMgYSBzb2x1dGlvbiBieSBoYXZpbmcgdGhlIGFpZHMgb2Ygb3BlcmF0b3IsIGJ1dCBtYXli ZSB3ZSBjb3VsZCBoYXZlIGEgbW9yZSBhdXRvbWF0aWMgYW5kIGdlbmVyYWwgbWVjaGFuaXNtIHRv IHNvbHZlIGRpc2NyZXBhbmN5LiBKdXN0IGEgc2ltcGxlIGlkZWEuIDopDQoNCkJlc3QgUmVnYXJk cywNCllhbGkNCg0Kt6K8/sjLOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSC0 +rHtIEpvZSBUb3VjaA0Kt6LLzcqxvOQ6IDIwMTbE6jEy1MIxNcjVIDM6MjANCsrVvP7IyzogTmVh bCBDYXJkd2VsbCA8bmNhcmR3ZWxsQGdvb2dsZS5jb20+OyBKYWtvYiBIZWl0eiAoamhlaXR6KSA8 amhlaXR6QGNpc2NvLmNvbT4NCrOty806IHRjcG1AaWV0Zi5vcmcNCtb3zOI6IFJlOiBbdGNwbV0g tPC4tDogQSBxdWVzdGlvbiBhYm91dCBEZWxheWVkIEFDSyBhbmQgUlRPDQoNCg0KV2Ugc2hvdWxk IG5vdCBiZSBvcHRpbWl6aW5nIFRDUCBmb3Igc3BlY2lmaWMgZW52aXJvbm1lbnRzOyB0aGF0J3Mg Zm9yIG9wZXJhdG9ycyB0byBvdmVycmlkZS4NCg0KSm9lDQoNCk9uIDEyLzE0LzIwMTYgOTowNCBB TSwgTmVhbCBDYXJkd2VsbCB3cm90ZToNCk9uIFdlZCwgRGVjIDE0LCAyMDE2IGF0IDExOjU2IEFN LCBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbTxtYWlsdG86amhlaXR6QGNp c2NvLmNvbT4+IHdyb3RlOg0KSGlzdG9yaWNhbGx5LCB0aGUgbWluaW11bSBSVE8gaXMgMSBzZWNv bmQgYW5kIGFjdHVhbCBSVFQgaXMgdmVyeSByYXJlbHkgbW9yZSB0aGFuIDEgc2Vjb25kLCBzbyBh bGwgdGhpcyBSVFQgY2FsY3VsYXRpb24gaGFyZGx5IGV2ZXIgbWF0dGVycyBhbnl3YXkuDQoNClRo YXQgbWF5IGJlIHRydWUgaGlzdG9yaWNhbGx5LCBidXQgZm9yIG1hbnkgeWVhcnMgbWFqb3IgVENQ IGltcGxlbWVudGF0aW9ucyAoaW5jbHVkaW5nIExpbnV4IGFuZCBGcmVlQlNEKSBoYXZlIHVzZWQg YSBtaW5pbXVtIFJUTyBjbG9zZXIgdG8gMjAwbXMuIEFuZCBpbiBkYXRhY2VudGVyIGVudmlyb25t ZW50cyBldmVuIDIwMG1zIGNhbiBiZSBpbmZlYXNpYmx5IGhpZ2guDQoNCm5lYWwNCg0KDQo= --_000_A747A0713F56294D8FBE33E5C6B8F5815F5460C4DGGEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Joe,

 

I really agree with you about TCP mec= hanism should general for all areas, including wan and data center.

 

But every scenarios have their own ch= aracteristics. Data center has some distinctive features, such as, ultralow= RTT, because of centralized location, less hops, and so on. These features determines different requirement for TCP default= configuration, compared with wan scenario. It is a solution by having the = aids of operator, but maybe we could have a more automatic and general mech= anism to solve discrepancy. Just a simple idea. J

 

Best Regards,

Yali

 

=B7=A2=BC=FE=C8=CB: tcpm [mailto:tcpm-bounces@ietf.org] =B4=FA=B1=ED <= /span>Joe Touch
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA12=D4=C215=C8=D5 3:20
=CA=D5=BC=FE=C8=CB: Neal Cardwell <nc= ardwell@google.com>; Jakob Heitz (jheitz) <jheitz@cisco.com>
=B3=AD=CB=CD: tcpm@ietf.org
=D6=F7=CC=E2: Re: [tcpm] =B4=F0=B8=B4: A question about Delayed ACK and RTO<= /span>

 

We should not be optimizing TCP for specific environments; that's for op= erators to override.

Joe

 

On 12/14/2016 9:04 AM, Neal Cardwell wrote:

On Wed, Dec 14, 2016 at 11:56 AM, Jakob Heitz (jheit= z) <jheitz@cisco.c= om> wrote:

Historically, the minimum RTO is 1 second and actual= RTT is very rarely more than 1 second, so all this RTT calculation hardly = ever matters anyway.

 

That may be true historically, but for many years ma= jor TCP implementations (including Linux and FreeBSD) have used a minimum R= TO closer to 200ms. And in datacenter environments even 200ms can be infeas= ibly high.

 

neal

 

 

--_000_A747A0713F56294D8FBE33E5C6B8F5815F5460C4DGGEMA502MBSchi_-- From nobody Wed Dec 14 19:09:12 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D32129494 for ; Wed, 14 Dec 2016 19:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enGwudy44Dpf for ; Wed, 14 Dec 2016 19:09:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC3B129421 for ; Wed, 14 Dec 2016 19:09:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCP17949; Thu, 15 Dec 2016 03:09:01 +0000 (GMT) Received: from DGGEMA406-HUB.china.huawei.com (10.3.20.47) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 15 Dec 2016 03:09:00 +0000 Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.220]) by DGGEMA406-HUB.china.huawei.com ([10.3.20.47]) with mapi id 14.03.0301.000; Thu, 15 Dec 2016 11:08:52 +0800 From: "zhangyali (D)" To: "zhangyali (D)" , Neal Cardwell Thread-Topic: =?utf-8?B?W3RjcG1dIOetlOWkjTog562U5aSNOiAgQSBxdWVzdGlvbiBhYm91dCBEZWxh?= =?utf-8?Q?yed_ACK_and_RTO?= Thread-Index: AQHSVnTx722W/E75/UawK40cX9bcW6EIUiHA Date: Thu, 15 Dec 2016 03:08:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.189.228] Content-Type: multipart/alternative; boundary="_000_A747A0713F56294D8FBE33E5C6B8F5815F5460FFDGGEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.5852094E.0181, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.220, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7339b0a94b961a8f3c8dfd8e356aa6c5 Archived-At: Cc: "tcpm@ietf.org" Subject: [tcpm] =?utf-8?b?562U5aSNOiAg562U5aSNOiDnrZTlpI06ICBBIHF1ZXN0aW9u?= =?utf-8?q?_about_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Dec 2016 03:09:10 -0000 --_000_A747A0713F56294D8FBE33E5C6B8F5815F5460FFDGGEMA502MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGFsbG93IG1lIHRvIGFkZCBvbmUgbW9yZSBwb2ludC4gSWYgdGhlIHByb2JhYmlsaXR5 IG9mIG9kZCBudW1iZXIgb2YgcGFja2V0cyBvY2N1cnJpbmcgIHNwdXJpb3VzIFJUTyBpcyBzbyBv dXRzdGFuZGluZywgd2h5IG5vYm9keSB0cnkgdG8gc29sdmUgdGhpcyBwcm9ibGVtPw0KDQrlj5Hk u7bkuro6IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCB6aGFuZ3lh bGkgKEQpDQrlj5HpgIHml7bpl7Q6IDIwMTblubQxMuaciDE15pelIDk6NDUNCuaUtuS7tuS6ujog TmVhbCBDYXJkd2VsbCA8bmNhcmR3ZWxsQGdvb2dsZS5jb20+DQrmioTpgIE6IHRjcG1AaWV0Zi5v cmcNCuS4u+mimDogW3RjcG1dIOetlOWkjTog562U5aSNOiBBIHF1ZXN0aW9uIGFib3V0IERlbGF5 ZWQgQUNLIGFuZCBSVE8NCg0KPiBZZXMsIHRoZXJlIHNob3VsZCBvbmx5IGJlIGEgZGVsYXllZCBB Q0sgYXQgdGhlIGVuZCBvZiBhbiBhcHBsaWNhdGlvbiBjaHVuayBpZiB0aGVyZSBpcyBhbiBvZGQg bnVtYmVyIG9mIHBhY2tldHMuIEJ1dCB3ZSB3b3VsZCBleHBlY3Qgcm91Z2hseSBoYWxmIG9mIGFw cGxpY2F0aW9uIGNodW5rcyB0byBoYXZlIGFuIG9kZCBudW1iZXIgb2YgcGFja2V0cy4gVGhvdWdo IHRoZSBwcm9wb3J0aW9uIGlzIHByb2JhYmx5IGhpZ2hlciB0aGFuIHRoYXQsIHNpbmNlIG1hbnkg YXBwbGljYXRpb24gY2h1bmtzIGFyZSBqdXN0IG9uZSBwYWNrZXQgKGUuZy4gYW4gSFRUUCBvciBS UEMgcmVxdWVzdCBvciByZXNwb25zZSkuDQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCBvZGQgbnVt YmVyIG9mIHBhY2tldHMgbWF5IG9jY3VyIHNwdXJpb3VzIFJUTyBtb3JlIGVhc2lseSwgYnV0IEkg dGhpbmsgZm9yIHRoZSBmbG93cyBvd25pbmcganVzdCBvbmUgcGFja2V0IHNob3VsZCBub3QgYmUg YWZmZWN0ZWQgYnkgZGVsYXllZCBBQ0suIEFGQUlLLCBzbG93LXN0YXJ0IHN0YWdlIHdpbGwgYmVn aW4gd2l0aCBvbmUgcGFja2V0LCBhbmQgc2VuZGVyIHdpbGwgc2VuZCB0d28gcGFja2V0cyBhZnRl ciBpdCByZWNlaXZlcyBhbiBBQ0suIElmIHRoZSBmaXJzdCBwYWNrZXQgaXMgb2JzdHJ1Y3RlZCBi eSB0aGUgZGVsYXllZCBBQ0ssIHRoZSDigJhjbG9jayBhbGdvcml0aG3igJkgd2lsbCBiZSBicm9r ZW4gZG93bi4gU28gcmVjZWl2ZXIgc2hvdWxkIGp1ZGdlIGlmIHRoaXMgcGFja2V0IGlzIHRoZSBm aXJzdCBvbmUgaW4gdGhlIHNsb3ctc3RhcnQgc3RhZ2UsIGlmIHllcywgc2VuZCB0aGUgYWNrIGlt bWVkaWF0ZWx5IG9uY2UgcmVjZWl2aW5nIHRoZSBwYWNrZXQuDQoNCllhbGkNCg0K5Y+R5Lu25Lq6 OiBOZWFsIENhcmR3ZWxsIFttYWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb21dDQrlj5HpgIHml7bp l7Q6IDIwMTblubQxMuaciDE05pelIDIxOjI0DQrmlLbku7bkuro6IHpoYW5neWFsaSAoRCkgPHpo YW5neWFsaTM2OUBodWF3ZWkuY29tPG1haWx0bzp6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbT4+DQrm ioTpgIE6IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQrkuLvpopg6IFJlOiDn rZTlpI06IFt0Y3BtXSBBIHF1ZXN0aW9uIGFib3V0IERlbGF5ZWQgQUNLIGFuZCBSVE8NCg0KT24g V2VkLCBEZWMgMTQsIDIwMTYgYXQgNDo0OCBBTSwgemhhbmd5YWxpIChEKSA8emhhbmd5YWxpMzY5 QGh1YXdlaS5jb208bWFpbHRvOnpoYW5neWFsaTM2OUBodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBO ZWFsLA0KDQpUaGFua3MgZm9yIHlvdXIgcHJvdmlkaW5nIHJlcXVlc3QgaW5mb3JtYXRpb24uDQoN CkFib3V0IHRoZSBkZWxheSBvZiBkZWxheWVkIEFDSywgSSBmb3VuZCBhbm90aGVyIGNsdWUgaW4g YSBTSUdDT01NIHBhcGVyIGluIDE5ODguIEluIHRoZSBwYWdlIDE0LCBhIHNlbnRlbmNlIGlzIOKA nFRoZSA0LjVLQnBzIHNlbmRlcnMgd2VyZSB0YWxraW5nIHRvIDQuM0JTRCByZWNlaXZlcnMgd2hp Y2ggd291bGQgZGVsYXkgYW4gYWNrIHVudGlsIDM1JSBvZiB0aGUgd2luZG93IHdhcyBmaWxsZWQg b3IgMjAwIG1zIGhhZCBwYXNzZWQgKGkuZS4sIGFuIGFjayB3YXMgZGVsYXllZCBmb3IgNS03IHBh Y2tldHMgb24gYXZlcmFnZSku4oCdIFRoZXJlIGlzIG5vIHJlZmVyZW5jZSBhYm91dCB0aGUgMjAw IG1zLCBzbyBJIGd1ZXNzIHRoaXMgaXMgdGhlIHBhcnRpY3VsYXIgZGVsYXkgYXBwZWFycyBmb3Ig dGhlIGZpcnN0IHRpbWUuDQpJIHRyeSB0byBjYWxjdWxhdGUgdGhlIHZhbHVlIGJhc2VkIG9uIGRl bGF5ZWQgcGFja2V0IG51bWJlcnMsIHBhY2tldCBzaXplIGFuZCBzZW5kaW5nIHJhdGUuIEluIHRo aXMgY2FzZSwgdGhlIGRlbGF5ZWQgcGFja2V0IG51bWJlciBpcyA3LCB0aGUgcGFja2V0IHNpemUg aXMgNTc2Qnl0ZSAocmVmZXIgdG8gUkZDODc5IGluIDE5ODMpLCBhbmQgc3VuZGVyaW5nIHJhdGUg aXMgNC41QnBzLiBUaGUgdmFsdWUgaXMgODk2IG1zISBMb25nZXIgdGhhbiAyMDAgbXMuDQoNCj4u IEhvd2V2ZXIsIGl0J3MgcXVpdGUgZWFzeSBmb3IgYSBidWxrIHRyYW5zZmVyIHRvIG5ldmVyIGhh dmUgYW55IGRlbGF5ZWQgQUNLcyBmb3IgbW9zdCBvZiBpdHMgbGlmZXRpbWUsIGR1cmluZyB3aGlj aCB0aGUgUlRPIGdyYWR1YWxseSBjb252ZXJnZXMgdG93YXJkIHRoZSByYXcgUlRUIHZhbHVlLiBU aGVuIHdoZW4gdGhlcmUgaXMgc3VkZGVubHkgYSBkZWxheWVkIEFDSywgdGhlcmUgY2FuIGJlIGEg c3B1cmlvdXMgUlRPLg0KSSBhbSBub3QgdmVyeSBzdXJlIGlmIEkgc2VlIHlvdXIgcG9pbnQuIEkg dGhpbmsgdGhlIGtleSBwb2ludCBpcyB0aGUgUlRUIHZhcmlhdGlvbiB3aWxsIGJlIHdlYWtlbmVk IHdoZW4gcGFja2V0cyBhcmUgc2VudCBpbiBhIGJ1cnN0ICh0aGUgY29uc2VxdWVuY2Ugb2YgZGVs YXllZCBBQ0spLiAgIEFuZCB0aGUgc3B1cmlvdXMgIGNvdWxkIG9ubHkgaGFwcGVuIGZvciB0aGUg bGFzdCBmZXcgcGFja2V0cyB3aG9zZSBudW1iZXIgaXMgc21hbGxlciB0aGFuIGRlbGF5ZWQgcGFj a2V0cywgcmlnaHQ/DQoNClllcywgdGhlcmUgc2hvdWxkIG9ubHkgYmUgYSBkZWxheWVkIEFDSyBh dCB0aGUgZW5kIG9mIGFuIGFwcGxpY2F0aW9uIGNodW5rIGlmIHRoZXJlIGlzIGFuIG9kZCBudW1i ZXIgb2YgcGFja2V0cy4gQnV0IHdlIHdvdWxkIGV4cGVjdCByb3VnaGx5IGhhbGYgb2YgYXBwbGlj YXRpb24gY2h1bmtzIHRvIGhhdmUgYW4gb2RkIG51bWJlciBvZiBwYWNrZXRzLiBUaG91Z2ggdGhl IHByb3BvcnRpb24gaXMgcHJvYmFibHkgaGlnaGVyIHRoYW4gdGhhdCwgc2luY2UgbWFueSBhcHBs aWNhdGlvbiBjaHVua3MgYXJlIGp1c3Qgb25lIHBhY2tldCAoZS5nLiBhbiBIVFRQIG9yIFJQQyBy ZXF1ZXN0IG9yIHJlc3BvbnNlKS4NCg0KDQpBYm91dCB5b3VyIHByb3Bvc2FsIGFib3V0IG5lZ290 aWF0aW9uIG9mIGRlbGF5ZWQgQUNLLCBhIHBvdGVudGlhbCBwcm9ibGVtIGlzIHRoYXQgUlRPIHdp bGwgYmUgc3RyZXRjaGVkIHRoYW4gYmVmb3JlIGJlY2F1c2UgeW91IGFkZCBleHRyYSBkZWxheS4g QXMgeW91IGhhdmUgc2FpZCwgbW9zdCBvZiB0aGUgcGFja2V0cyB3aWxsIG5vdCBleGNlZWQgUlRP IGV2ZW4gaG9zdCBlbmFibGUgZGVsYXllZCBBQ0sgZm9yIG1vc3QgbGFyZ2UgZmxvd3MsIGJ1dCB0 aGUgcmV0cmFuc21pc3Npb24gd2lsbCBiZSBkZWxheWVkIChpLmUuLCA1bXMpYWxzbyBvbmNlIG9u ZSBwYWNrZXQgaXMgbG9zdC4NCg0KVGhlIGJhc2ljIGlkZWEgb2YgdGhlIHByb3Bvc2FsIGlzIHRv IHR3ZWFrIHRoZSBSVE8gY2FsY3VsYXRpb24gYW5kIHR1cm4gYSBwcmV2aW91c2x5IGV4aXN0aW5n LCBoaXN0b3JpY2FsbHkgbW90aXZhdGVkIDIwMG1zIGZpeGVkICJzbG9wIGZhY3RvciIgaW50byBh IGR5bmFtaWNhbGx5IG5lZ290aWF0ZWQgNW1zICJzbG9wIGZhY3RvciIuIEluIG91ciBleHBlcmll bmNlIHRoYXQgaXMgYWxtb3N0IGFsd2F5cyBhIHdpbi4NCg0KbmVhbA0KDQoNCkJlc3QsDQpZYWxp DQrlj5Hku7bkuro6IE5lYWwgQ2FyZHdlbGwgW21haWx0bzpuY2FyZHdlbGxAZ29vZ2xlLmNvbTxt YWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb20+XQ0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0MTLmnIgx M+aXpSAyMzoxOA0K5pS25Lu25Lq6OiB6aGFuZ3lhbGkgKEQpIDx6aGFuZ3lhbGkzNjlAaHVhd2Vp LmNvbTxtYWlsdG86emhhbmd5YWxpMzY5QGh1YXdlaS5jb20+Pg0K5oqE6YCBOiB0Y3BtQGlldGYu b3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0K5Li76aKYOiBSZTogW3RjcG1dIEEgcXVlc3Rpb24g YWJvdXQgRGVsYXllZCBBQ0sgYW5kIFJUTw0KDQpPbiBUdWUsIERlYyAxMywgMjAxNiBhdCAzOjU4 IEFNLCB6aGFuZ3lhbGkgKEQpIDx6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbTxtYWlsdG86emhhbmd5 YWxpMzY5QGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIGFsbCwNCg0KUmVjZW50IGRheXMsIEkgYW0g ZG9pbmcgc29tZSBzaW11bGF0aW9uIGFib3V0IFRDUCBwZXJmb3JtYW5jZSBpbiBOUzMuIEkgZm91 bmQgYSBwaGVub21lbm9uIGlzIGEgZGVmYXVsdCBzZXR0aW5nIG9mIFRDUOKAmXMgZGVsYXllZCBB Q0sgaXMgdHdvIHBhY2tldHMgb3IgMjAwbXMuIEkgYW0gd29uZGVyaW5nIGlmIHRoaXMgc2V0dGlu ZyBpcyBhY2NvcmQgd2l0aCAgc29tZSBSRkNzIGluIElFVEYuIEJ1dCBBZnRlciBJIHJlZmVycmVk IHRvIHNvbWUgUkZDcywgSSBqdXN0IGZvdW5kIHNvbWUgcmVzdHJpY3Rpb25zLCBzdWNoIGFzLCB0 aGUgZGVsYXkgbXVzdCBiZSBsZXNzIHRoYW4gMC41bXMgKFJGQzExMjIpLg0KDQpJIGJlbGlldmUg dGhlIDIwMG1zIGZpZ3VyZSBpcyBkdWUgdG8gaGlzdG9yaWNhbCByZWFzb25zLiBBRkFJSyBpdCdz IGR1ZSB0byB0aGUgQlNEIGRlbGF5ZWQgQUNLIGJlaGF2aW9yIChzZWUgU3RldmVucyAiVENQL0lQ IElsbHVzdHJhdGVkIFZvbHVtZSAyIiwgc2VjdGlvbiAyNS40IGFuZCBmaWd1cmUgMjUuNywgd2hp Y2ggZGVzY3JpYmVzIHRoZSAyMDBtcyBkZWxheWVkIEFDSyB0aW1lcikuIFRoZW4gdGhpcyB2YWx1 ZSB3YXMgaW5oZXJpdGVkIGJ5IG90aGVyIHdpZGVseS1kZXBsb3llZCBPU2VzLg0KDQoNCkkgdGhp bmsgdGhlIGRlbGF5ZWQgQUNLIGhhcyBhIGNsb3NlIHJlbGF0aW9uc2hpcCB3aXRoIFJUTy4gVGFr ZSBhbiBleHRyZW1lIHNjZW5hcmlvLCBpZiB0aGUgZGVsYXkgaXMgbG9uZ2VyIHRoYW4gUlRPLCBt YW55IHBhY2tldHMgd2lsbCBiZSByZXRyYW5zbWl0dGVkLCB3aGljaCB3aWxsIHdhc3RlIG1hbnkg bmV0d29yayByZXNvdXJjZXMuDQoNClllcywgZXhhY3RseS4gSW4gdGhlb3J5LCB0aGUgUlRPIHRy aWVzIHRvIGJlIGFkYXB0aXZlIGVub3VnaCB0byBtZWFzdXJlIGFueSBSVFQgdmFyaWF0aW9ucyBj YXVzZWQgYnkgZGVsYXllZCBBQ0tzLCBhbmQgaW5jcmVhc2UgdGhlIFJUTyBpbiByZXNwb25zZSB0 byB0aGlzLiBIb3dldmVyLCBpdCdzIHF1aXRlIGVhc3kgZm9yIGEgYnVsayB0cmFuc2ZlciB0byBu ZXZlciBoYXZlIGFueSBkZWxheWVkIEFDS3MgZm9yIG1vc3Qgb2YgaXRzIGxpZmV0aW1lLCBkdXJp bmcgd2hpY2ggdGhlIFJUTyBncmFkdWFsbHkgY29udmVyZ2VzIHRvd2FyZCB0aGUgcmF3IFJUVCB2 YWx1ZS4gVGhlbiB3aGVuIHRoZXJlIGlzIHN1ZGRlbmx5IGEgZGVsYXllZCBBQ0ssIHRoZXJlIGNh biBiZSBhIHNwdXJpb3VzIFJUTy4NCg0KVG8gYXZvaWQgdGhhdCwgbWFueSBUQ1Agc3RhY2tzIChh dCBsZWFzdCB0aGUgbWFqb3Igb3BlbiBzb3VyY2UgT1NlcykgaGF2ZSBhIGhhcmQtY29kZWQgMjAw bXMgInNsb3AgZmFjdG9yIiBvciAiZnVkZ2UgZmFjdG9yIiwgdG8gdHJ5IHRvIG5ldmVyIGxldCB0 aGVpciBlc3RpbWF0ZSBvZiBSVFQgdmFyaWF0aW9uIGZhbGwgYmVsb3cgdGhhdCAyMDBtcyB2YWx1 ZSwgdG8gYXZvaWQgdGhpcyBlZmZlY3QuDQoNClNvIEkgd2FudCB0byBrbm93IGRvIHdlIGhhdmUg c29tZSBSRkNzIGhhdmUgZ2l2ZW4gdGhlIGV4YWN0IHZhbHVlIG9mIGJvdGg/IEFuZCBpZiB3ZSBw ZXJtaXQgYW55IFRDUCBzdGFjayB0byBzZXQgdGhlbSBmcmVlbHksIHdoYXQgaXMgdGhlIG1lY2hh bmlzbSB0byBiYWxhbmNlIHRoZSBtaXNtYXRjaCBiZXR3ZWVuIFJUTyBhbmQgZGVsYXllZCBBQ0s/ DQoNCkknbSBub3QgYXdhcmUgb2YgUkZDIHNwZWNpZmljYXRpb25zIGZvciBleGFjdCB2YWx1ZXMg b2YgYm90aCAoZGVsYXllZCBBQ0sgYW5kIFJUTykuIEhvd2V2ZXIsIHRoZSBoaXN0b3JpY2FsIHBy ZWNlZGVudCBpcyB2ZXJ5IHN0cm9uZywgYW5kIHRoZSAyMDBtcyBkZWxheWVkIEFDSyB2YWx1ZSB3 YXMgdmVyeSBwcm9ub3VuY2VkIGluIEludGVybmV0IHRyYWNlcyBhdCBsZWFzdCBhcyByZWNlbnRs eSBhcyAyMDExLCB3aGVuIEkgbGFzdCBsb29rZWQgYXQgdGhlIGVmZmVjdC4gKFByb2JhYmx5IG90 aGVycyBoYXZlIG1vcmUgcmVjZW50IGRhdGEgcG9pbnRzIGZvciB0aGUgcHJldmFsZW5jZSBvZiAy MDBtcyBkZWxheWVkIEFDS3MuKQ0KDQpBdCBJRVRGIDk3IG91ciB0ZWFtIGF0IEdvb2dsZSBwcmVz ZW50ZWQgc29tZSBmZWF0dXJlcyB3ZSB1c2UgZm9yIGludGVybmFsIFRDUCB0cmFmZmljIGF0IEdv b2dsZSwgd2hlcmUgdGhlIGVuZHBvaW50cyBjYW4gbmVnb3RpYXRlIHRoZSBzcGVjaWZpYyBjb25z dGFudCB0byB1c2UgZm9yIHRoZSBtYXhpbXVtIGRlbGF5ZWQgQUNLIGZyb20gdGhlIHJlY2VpdmVy IGFuZCB0aGUgY29ycmVzcG9uZGluZyBtaW5pbXVtIFJUVCBkZWxheSB2YXJpYXRpb24gZm9yIGJ1 ZGdldGluZyBpbiB0aGUgUlRPIGF0IHRoZSBzZW5kZXI6DQoNCiAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05Ny10Y3BtLXRjcC1vcHRpb25zLWZvci1s b3ctbGF0ZW5jeS0wMC5wZGYNCg0KQXMgdGhpcyBzbGlkZSBkZWNrIG5vdGVzLCB3aXRoaW4gR29v Z2xlIHdlIG5lZ290aWF0ZSA1bXMgZm9yIGRlbGF5ZWQgQUNLcy4NCg0KY2hlZXJzLA0KbmVhbA0K DQoNCg== --_000_A747A0713F56294D8FBE33E5C6B8F5815F5460FFDGGEMA502MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGFsbG93 IG1lIHRvIGFkZCBvbmUgbW9yZSBwb2ludC4gSWYgdGhlIHByb2JhYmlsaXR5IG9mIG9kZCBudW1i ZXIgb2YgcGFja2V0cyBvY2N1cnJpbmcgJm5ic3A7c3B1cmlvdXMgUlRPIGlzIHNvIG91dHN0YW5k aW5nLCB3aHkgbm9ib2R5IHRyeSB0byBzb2x2ZSB0aGlzIHByb2JsZW0/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LHNhbnMtc2VyaWYiPuWPkeS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYi Pjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gdGNwbSBbbWFpbHRvOnRjcG0tYm91 bmNlc0BpZXRmLm9yZ10NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7ku6PooaggPC9zcGFuPjwvYj56 aGFuZ3lhbGkgKEQpPGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuWPkemAgeaXtumXtDwvc3Bh bj46PC9iPiAyMDE2PHNwYW4gbGFuZz0iWkgtQ04iPuW5tDwvc3Bhbj4xMjxzcGFuIGxhbmc9IlpI LUNOIj7mnIg8L3NwYW4+MTU8c3BhbiBsYW5nPSJaSC1DTiI+5pelPC9zcGFuPiA5OjQ1PGJyPg0K PGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaUtuS7tuS6ujwvc3Bhbj46PC9iPiBOZWFsIENhcmR3ZWxs ICZsdDtuY2FyZHdlbGxAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1DTiI+ 5oqE6YCBPC9zcGFuPjo8L2I+IHRjcG1AaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1D TiI+5Li76aKYPC9zcGFuPjo8L2I+IFt0Y3BtXSA8c3BhbiBsYW5nPSJaSC1DTiI+562U5aSNPC9z cGFuPjogPHNwYW4gbGFuZz0iWkgtQ04iPg0K562U5aSNPC9zcGFuPjogQSBxdWVzdGlvbiBhYm91 dCBEZWxheWVkIEFDSyBhbmQgUlRPPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsNCjwvc3Bhbj5Z ZXMsIHRoZXJlIHNob3VsZCBvbmx5IGJlIGEgZGVsYXllZCBBQ0sgYXQgdGhlIGVuZCBvZiBhbiBh cHBsaWNhdGlvbiBjaHVuayBpZiB0aGVyZSBpcyBhbiBvZGQgbnVtYmVyIG9mIHBhY2tldHMuIEJ1 dCB3ZSB3b3VsZCBleHBlY3Qgcm91Z2hseSBoYWxmIG9mIGFwcGxpY2F0aW9uIGNodW5rcyB0byBo YXZlIGFuIG9kZCBudW1iZXIgb2YgcGFja2V0cy4gVGhvdWdoIHRoZSBwcm9wb3J0aW9uIGlzIHBy b2JhYmx5IGhpZ2hlciB0aGFuIHRoYXQsDQogc2luY2UgbWFueSBhcHBsaWNhdGlvbiBjaHVua3Mg YXJlIGp1c3Qgb25lIHBhY2tldCAoZS5nLiBhbiBIVFRQIG9yIFJQQyByZXF1ZXN0IG9yIHJlc3Bv bnNlKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIHlv dSB0aGF0IG9kZCBudW1iZXIgb2YgcGFja2V0cyBtYXkgb2NjdXIgc3B1cmlvdXMgUlRPIG1vcmUg ZWFzaWx5LCBidXQgSSB0aGluayBmb3IgdGhlIGZsb3dzIG93bmluZyBqdXN0IG9uZSBwYWNrZXQg c2hvdWxkIG5vdCBiZSBhZmZlY3RlZCBieSBkZWxheWVkDQogQUNLLiBBRkFJSywgc2xvdy1zdGFy dCBzdGFnZSB3aWxsIGJlZ2luIHdpdGggb25lIHBhY2tldCwgYW5kIHNlbmRlciB3aWxsIHNlbmQg dHdvIHBhY2tldHMgYWZ0ZXIgaXQgcmVjZWl2ZXMgYW4gQUNLLiBJZiB0aGUgZmlyc3QgcGFja2V0 IGlzIG9ic3RydWN0ZWQgYnkgdGhlIGRlbGF5ZWQgQUNLLCB0aGUg4oCYY2xvY2sgYWxnb3JpdGht 4oCZIHdpbGwgYmUgYnJva2VuIGRvd24uIFNvIHJlY2VpdmVyIHNob3VsZCBqdWRnZSBpZiB0aGlz IHBhY2tldCBpcw0KIHRoZSBmaXJzdCBvbmUgaW4gdGhlIHNsb3ctc3RhcnQgc3RhZ2UsIGlmIHll cywgc2VuZCB0aGUgYWNrIGltbWVkaWF0ZWx5IG9uY2UgcmVjZWl2aW5nIHRoZSBwYWNrZXQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZYWxpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R5Lu25Lq6PC9zcGFuPjwv Yj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWYiPiBOZWFsIENhcmR3ZWxsDQogWzxhIGhyZWY9Im1haWx0bzpuY2FyZHdlbGxAZ29vZ2xlLmNv bSI+bWFpbHRvOm5jYXJkd2VsbEBnb29nbGUuY29tPC9hPl0gPGJyPg0KPGI+PHNwYW4gbGFuZz0i WkgtQ04iPuWPkemAgeaXtumXtDwvc3Bhbj46PC9iPiAyMDE2PHNwYW4gbGFuZz0iWkgtQ04iPuW5 tDwvc3Bhbj4xMjxzcGFuIGxhbmc9IlpILUNOIj7mnIg8L3NwYW4+MTQ8c3BhbiBsYW5nPSJaSC1D TiI+5pelPC9zcGFuPiAyMToyNDxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7mlLbku7bkuro8 L3NwYW4+OjwvYj4gemhhbmd5YWxpIChEKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpoYW5neWFsaTM2 OUBodWF3ZWkuY29tIj56aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+PHNw YW4gbGFuZz0iWkgtQ04iPuaKhOmAgTwvc3Bhbj46PC9iPiA8YSBocmVmPSJtYWlsdG86dGNwbUBp ZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj48c3BhbiBsYW5nPSJaSC1DTiI+5Li7 6aKYPC9zcGFuPjo8L2I+IFJlOiA8c3BhbiBsYW5nPSJaSC1DTiI+562U5aSNPC9zcGFuPjogW3Rj cG1dIEEgcXVlc3Rpb24gYWJvdXQgRGVsYXllZCBBQ0sgYW5kIFJUTzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBEZWMgMTQsIDIwMTYg YXQgNDo0OCBBTSwgemhhbmd5YWxpIChEKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpoYW5neWFsaTM2 OUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+emhhbmd5YWxpMzY5QGh1YXdlaS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SGkgTmVhbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciBwcm92 aWRpbmcgcmVxdWVzdCBpbmZvcm1hdGlvbi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWJvdXQgdGhlIGRlbGF5 IG9mIGRlbGF5ZWQgQUNLLCBJIGZvdW5kIGFub3RoZXIgY2x1ZSBpbiBhIFNJR0NPTU0gcGFwZXIg aW4gMTk4OC4gSW4gdGhlIHBhZ2UgMTQsIGEgc2VudGVuY2UgaXMg4oCcVGhlDQogNC41S0JwcyBz ZW5kZXJzIHdlcmUgdGFsa2luZyB0byA0LjNCU0QgcmVjZWl2ZXJzIHdoaWNoIHdvdWxkIGRlbGF5 IGFuIGFjayB1bnRpbCAzNSUgb2YgdGhlIHdpbmRvdyB3YXMgZmlsbGVkIG9yIDIwMCBtcyBoYWQg cGFzc2VkIChpLmUuLCBhbiBhY2sgd2FzIGRlbGF5ZWQgZm9yIDUtNyBwYWNrZXRzIG9uIGF2ZXJh Z2UpLuKAnSBUaGVyZSBpcyBubyByZWZlcmVuY2UgYWJvdXQgdGhlIDIwMCBtcywgc28gSSBndWVz cyB0aGlzIGlzIHRoZSBwYXJ0aWN1bGFyDQogZGVsYXkgYXBwZWFycyBmb3IgdGhlIGZpcnN0IHRp bWUuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIHRyeSB0byBjYWxjdWxhdGUgdGhlIHZhbHVlIGJhc2VkIG9uIGRlbGF5ZWQgcGFj a2V0IG51bWJlcnMsIHBhY2tldCBzaXplIGFuZCBzZW5kaW5nIHJhdGUuIEluIHRoaXMgY2FzZSwg dGhlIGRlbGF5ZWQNCiBwYWNrZXQgbnVtYmVyIGlzIDcsIHRoZSBwYWNrZXQgc2l6ZSBpcyA1NzZC eXRlIChyZWZlciB0byBSRkM4NzkgaW4gMTk4MyksIGFuZCBzdW5kZXJpbmcgcmF0ZSBpcyA0LjVC cHMuIFRoZSB2YWx1ZSBpcyA4OTYgbXMhIExvbmdlciB0aGFuIDIwMCBtcy4NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jmd0Ozwvc3Bhbj4uIEhvd2V2ZXIsIGl0J3MgcXVpdGUgZWFzeSBmb3IgYSBidWxrIHRyYW5z ZmVyIHRvIG5ldmVyIGhhdmUgYW55IGRlbGF5ZWQgQUNLcyBmb3IgbW9zdCBvZiBpdHMgbGlmZXRp bWUsIGR1cmluZw0KIHdoaWNoIHRoZSBSVE8gZ3JhZHVhbGx5IGNvbnZlcmdlcyB0b3dhcmQgdGhl IHJhdyBSVFQgdmFsdWUuIFRoZW4gd2hlbiB0aGVyZSBpcyBzdWRkZW5seSBhIGRlbGF5ZWQgQUNL LCB0aGVyZSBjYW4gYmUgYSBzcHVyaW91cyBSVE8uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbSBub3QgdmVyeSBzdXJlIGlmIEkgc2VlIHlv dXIgcG9pbnQuIEkgdGhpbmsgdGhlIGtleSBwb2ludCBpcyB0aGUgUlRUIHZhcmlhdGlvbiB3aWxs IGJlIHdlYWtlbmVkIHdoZW4gcGFja2V0cyBhcmUNCiBzZW50IGluIGEgYnVyc3QgKHRoZSBjb25z ZXF1ZW5jZSBvZiBkZWxheWVkIEFDSykuICZuYnNwOyZuYnNwO0FuZCB0aGUgc3B1cmlvdXMgJm5i c3A7Y291bGQgb25seSBoYXBwZW4gZm9yIHRoZSBsYXN0IGZldyBwYWNrZXRzIHdob3NlIG51bWJl ciBpcyBzbWFsbGVyIHRoYW4gZGVsYXllZCBwYWNrZXRzLCByaWdodD88L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WWVzLCB0aGVyZSBzaG91bGQgb25seSBiZSBhIGRlbGF5ZWQgQUNLIGF0IHRo ZSBlbmQgb2YgYW4gYXBwbGljYXRpb24gY2h1bmsgaWYgdGhlcmUgaXMgYW4gb2RkIG51bWJlciBv ZiBwYWNrZXRzLiBCdXQgd2Ugd291bGQgZXhwZWN0IHJvdWdobHkgaGFsZiBvZiBhcHBsaWNhdGlv biBjaHVua3MgdG8gaGF2ZSBhbiBvZGQgbnVtYmVyIG9mIHBhY2tldHMuIFRob3VnaCB0aGUgcHJv cG9ydGlvbiBpcyBwcm9iYWJseQ0KIGhpZ2hlciB0aGFuIHRoYXQsIHNpbmNlIG1hbnkgYXBwbGlj YXRpb24gY2h1bmtzIGFyZSBqdXN0IG9uZSBwYWNrZXQgKGUuZy4gYW4gSFRUUCBvciBSUEMgcmVx dWVzdCBvciByZXNwb25zZSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BYm91dCB5b3VyIHByb3Bvc2Fs IGFib3V0IG5lZ290aWF0aW9uIG9mIGRlbGF5ZWQgQUNLLCBhIHBvdGVudGlhbCBwcm9ibGVtIGlz IHRoYXQgUlRPIHdpbGwgYmUgc3RyZXRjaGVkDQogdGhhbiBiZWZvcmUgYmVjYXVzZSB5b3UgYWRk IGV4dHJhIGRlbGF5LiBBcyB5b3UgaGF2ZSBzYWlkLCBtb3N0IG9mIHRoZSBwYWNrZXRzIHdpbGwg bm90IGV4Y2VlZCBSVE8gZXZlbiBob3N0IGVuYWJsZSBkZWxheWVkIEFDSyBmb3IgbW9zdCBsYXJn ZSBmbG93cywgYnV0IHRoZSByZXRyYW5zbWlzc2lvbiB3aWxsIGJlIGRlbGF5ZWQgKGkuZS4sIDVt cylhbHNvIG9uY2Ugb25lIHBhY2tldCBpcyBsb3N0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgYmFzaWMgaWRlYSBvZiB0aGUgcHJvcG9zYWwgaXMgdG8gdHdlYWsgdGhlIFJUTyBjYWxj dWxhdGlvbiBhbmQgdHVybiBhIHByZXZpb3VzbHkgZXhpc3RpbmcsIGhpc3RvcmljYWxseSBtb3Rp dmF0ZWQgMjAwbXMgZml4ZWQgJnF1b3Q7c2xvcCBmYWN0b3ImcXVvdDsgaW50byBhIGR5bmFtaWNh bGx5IG5lZ290aWF0ZWQgNW1zICZxdW90O3Nsb3AgZmFjdG9yJnF1b3Q7LiBJbiBvdXIgZXhwZXJp ZW5jZSB0aGF0IGlzIGFsbW9zdCBhbHdheXMgYSB3aW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm5lYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5ZYWxpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 5a6L5L2TIj7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPg0KIE5lYWwgQ2FyZHdlbGwgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 bmNhcmR3ZWxsQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uY2FyZHdlbGxAZ29vZ2xlLmNv bTwvYT5dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R6YCB5pe26Ze0PC9zcGFuPjwvYj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4gMjAxNjwvc3Bhbj48c3Bh biBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65a6L5L2T Ij7lubQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+MTI8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5pyIPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPjEzPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTrlrovkvZMiPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4NCiAyMzox ODxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7mlLbku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiB6aGFuZ3lhbGkgKEQpICZsdDs8YSBocmVm PSJtYWlsdG86emhhbmd5YWxpMzY5QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj56aGFuZ3lh bGkzNjlAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNO IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrlrovkvZMiPuaKhOmAgTwvc3Bh bj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+DQo8YSBo cmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0Zi5vcmc8 L2E+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTrlrovkvZMiPuS4u+mimDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+IFJlOiBbdGNwbV0gQSBxdWVzdGlvbiBhYm91 dCBEZWxheWVkDQogQUNLIGFuZCBSVE88L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRGVjIDEzLCAyMDE2 IGF0IDM6NTggQU0sIHpoYW5neWFsaSAoRCkgJmx0OzxhIGhyZWY9Im1haWx0bzp6aGFuZ3lhbGkz NjlAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnpoYW5neWFsaTM2OUBodWF3ZWkuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5IaSBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWNlbnQgZGF5cywgSSBhbSBk b2luZyBzb21lIHNpbXVsYXRpb24gYWJvdXQgVENQIHBlcmZvcm1hbmNlIGluIE5TMy4gSSBmb3Vu ZCBhIHBoZW5vbWVub24gaXMgYSBkZWZhdWx0IHNldHRpbmcgb2YgVENQ4oCZcyBkZWxheWVkIEFD SyBpcyB0d28gcGFja2V0cyBvciAyMDBtcy4gSSBhbSB3b25kZXJpbmcgaWYgdGhpcw0KIHNldHRp bmcgaXMgYWNjb3JkIHdpdGggJm5ic3A7c29tZSBSRkNzIGluIElFVEYuIEJ1dCBBZnRlciBJIHJl ZmVycmVkIHRvIHNvbWUgUkZDcywgSSBqdXN0IGZvdW5kIHNvbWUgcmVzdHJpY3Rpb25zLCBzdWNo IGFzLCB0aGUgZGVsYXkgbXVzdCBiZSBsZXNzIHRoYW4gMC41bXMgKFJGQzExMjIpLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JIGJlbGlldmUgdGhlIDIwMG1zIGZpZ3VyZSBpcyBkdWUgdG8gaGlz dG9yaWNhbCByZWFzb25zLiBBRkFJSyBpdCdzIGR1ZSB0byB0aGUgQlNEIGRlbGF5ZWQgQUNLIGJl aGF2aW9yIChzZWUgU3RldmVucyAmcXVvdDtUQ1AvSVAgSWxsdXN0cmF0ZWQgVm9sdW1lIDImcXVv dDssIHNlY3Rpb24gMjUuNCBhbmQgZmlndXJlIDI1LjcsDQogd2hpY2ggZGVzY3JpYmVzIHRoZSAy MDBtcyBkZWxheWVkIEFDSyB0aW1lcikuIFRoZW4gdGhpcyB2YWx1ZSB3YXMgaW5oZXJpdGVkIGJ5 IG90aGVyIHdpZGVseS1kZXBsb3llZCBPU2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgdGhlIGRlbGF5 ZWQgQUNLIGhhcyBhIGNsb3NlIHJlbGF0aW9uc2hpcCB3aXRoIFJUTy4gVGFrZSBhbiBleHRyZW1l IHNjZW5hcmlvLCBpZiB0aGUgZGVsYXkgaXMgbG9uZ2VyIHRoYW4gUlRPLCBtYW55IHBhY2tldHMg d2lsbCBiZSByZXRyYW5zbWl0dGVkLCB3aGljaCB3aWxsIHdhc3RlIG1hbnkgbmV0d29yaw0KIHJl c291cmNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVzLCBleGFjdGx5LiBJbiB0aGVvcnks IHRoZSBSVE8gdHJpZXMgdG8gYmUgYWRhcHRpdmUgZW5vdWdoIHRvIG1lYXN1cmUgYW55IFJUVCB2 YXJpYXRpb25zIGNhdXNlZCBieSBkZWxheWVkIEFDS3MsIGFuZCBpbmNyZWFzZSB0aGUgUlRPIGlu IHJlc3BvbnNlIHRvIHRoaXMuIEhvd2V2ZXIsIGl0J3MgcXVpdGUNCiBlYXN5IGZvciBhIGJ1bGsg dHJhbnNmZXIgdG8gbmV2ZXIgaGF2ZSBhbnkgZGVsYXllZCBBQ0tzIGZvciBtb3N0IG9mIGl0cyBs aWZldGltZSwgZHVyaW5nIHdoaWNoIHRoZSBSVE8gZ3JhZHVhbGx5IGNvbnZlcmdlcyB0b3dhcmQg dGhlIHJhdyBSVFQgdmFsdWUuIFRoZW4gd2hlbiB0aGVyZSBpcyBzdWRkZW5seSBhIGRlbGF5ZWQg QUNLLCB0aGVyZSBjYW4gYmUgYSBzcHVyaW91cyBSVE8uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UbyBhdm9pZCB0aGF0LCBtYW55IFRD UCBzdGFja3MgKGF0IGxlYXN0IHRoZSBtYWpvciBvcGVuIHNvdXJjZSBPU2VzKSBoYXZlIGEgaGFy ZC1jb2RlZCAyMDBtcyAmcXVvdDtzbG9wIGZhY3RvciZxdW90OyBvciAmcXVvdDtmdWRnZSBmYWN0 b3ImcXVvdDssIHRvIHRyeSB0byBuZXZlciBsZXQgdGhlaXIgZXN0aW1hdGUgb2YgUlRUIHZhcmlh dGlvbg0KIGZhbGwgYmVsb3cgdGhhdCAyMDBtcyB2YWx1ZSwgdG8gYXZvaWQgdGhpcyBlZmZlY3Qu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5TbyBJIHdhbnQgdG8ga25vdyBkbyB3ZSBoYXZlIHNvbWUgUkZDcyBoYXZlIGdpdmVu IHRoZSBleGFjdCB2YWx1ZSBvZiBib3RoPyBBbmQgaWYgd2UgcGVybWl0IGFueSBUQ1Agc3RhY2sg dG8gc2V0IHRoZW0gZnJlZWx5LCB3aGF0IGlzIHRoZSBtZWNoYW5pc20gdG8gYmFsYW5jZSB0aGUg bWlzbWF0Y2ggYmV0d2Vlbg0KIFJUTyBhbmQgZGVsYXllZCBBQ0s/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkknbSBub3QgYXdhcmUgb2YgUkZDIHNwZWNpZmljYXRpb25zIGZvciBleGFjdCB2YWx1 ZXMgb2YgYm90aCAoZGVsYXllZCBBQ0sgYW5kIFJUTykuIEhvd2V2ZXIsIHRoZSBoaXN0b3JpY2Fs IHByZWNlZGVudCBpcyB2ZXJ5IHN0cm9uZywgYW5kIHRoZSAyMDBtcyBkZWxheWVkIEFDSyB2YWx1 ZSB3YXMgdmVyeSBwcm9ub3VuY2VkDQogaW4gSW50ZXJuZXQgdHJhY2VzIGF0IGxlYXN0IGFzIHJl Y2VudGx5IGFzIDIwMTEsIHdoZW4gSSBsYXN0IGxvb2tlZCBhdCB0aGUgZWZmZWN0LiAoUHJvYmFi bHkgb3RoZXJzIGhhdmUgbW9yZSByZWNlbnQgZGF0YSBwb2ludHMgZm9yIHRoZSBwcmV2YWxlbmNl IG9mIDIwMG1zIGRlbGF5ZWQgQUNLcy4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BdCBJRVRGIDk3IG91ciB0ZWFtIGF0IEdvb2dsZSBw cmVzZW50ZWQgc29tZSBmZWF0dXJlcyB3ZSB1c2UgZm9yIGludGVybmFsIFRDUCB0cmFmZmljIGF0 IEdvb2dsZSwgd2hlcmUgdGhlIGVuZHBvaW50cyBjYW4gbmVnb3RpYXRlIHRoZSBzcGVjaWZpYyBj b25zdGFudCB0byB1c2UgZm9yIHRoZSBtYXhpbXVtIGRlbGF5ZWQNCiBBQ0sgZnJvbSB0aGUgcmVj ZWl2ZXIgYW5kIHRoZSBjb3JyZXNwb25kaW5nIG1pbmltdW0gUlRUIGRlbGF5IHZhcmlhdGlvbiBm b3IgYnVkZ2V0aW5nIGluIHRoZSBSVE8gYXQgdGhlIHNlbmRlcjo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOw0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTcvc2xpZGVzL3NsaWRlcy05Ny10Y3Bt LXRjcC1vcHRpb25zLWZvci1sb3ctbGF0ZW5jeS0wMC5wZGYiIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L3NsaWRlcy9zbGlkZXMtOTctdGNwbS10 Y3Atb3B0aW9ucy1mb3ItbG93LWxhdGVuY3ktMDAucGRmPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgdGhpcyBzbGlkZSBkZWNr IG5vdGVzLCB3aXRoaW4gR29vZ2xlIHdlIG5lZ290aWF0ZSA1bXMgZm9yIGRlbGF5ZWQgQUNLcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PmNoZWVycywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+bmVhbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A747A0713F56294D8FBE33E5C6B8F5815F5460FFDGGEMA502MBSchi_-- From nobody Wed Dec 14 19:21:33 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12601294A4 for ; Wed, 14 Dec 2016 19:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9Cxv8maghYC for ; Wed, 14 Dec 2016 19:21:30 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCD9129EAF for ; Wed, 14 Dec 2016 19:21:14 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id p9so58980062vkd.3 for ; Wed, 14 Dec 2016 19:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=F7LNTSr8DQ3qtbTARS7GCij0ghH4+GusPZnoJ78Xbpk=; b=FRz85nQwW6v1q17oiE4LeukRA7THBC0tFvOeTDYL4v7eTJ4oaDRVPipQxRrCCIFTa8 XO5wz7dtci/B1Q5I/28v3n2EmNSruqmeliR23g+QzbdpDrRDmDez6F0sElHyLRo8+OS9 p11uGkAyBl/ih/ZAhn/hmytC2SgtZ0LELwngqOrxM0ZaPLUqqU3ZamU/JTLNPcIZfGOA q0qQpb8ftw71C03IX3jD8xf8N/JKDpHuH7dWsJBxkAhauSNSD6fL3H30hi6yVPw2NFtE 7ZXLx/2z+KSUmNzjB1p1l0gyLxZupnZ32F1zNUORiAtK0MvGQKGwBPsa8C/zkJeJ4okH D3Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F7LNTSr8DQ3qtbTARS7GCij0ghH4+GusPZnoJ78Xbpk=; b=bUoJXHGGxXx7qdZJG9uPvdO/BNfo0Rw5k7cn/5ru8iFCMvepVTwW4otN/d+kdJ03Rf QEGVu4zcPXTvS1w9RjqgmZUAvne2ffI5r9dnnP+awoJ8k/t5dAP7oIxWIuChtSgNSKI1 TPEA08zceLoVdw6nkJ19znl7ZdkbIYmrMW1jTUmKFpVEYXxMxrpeDkMrl/NMPeP6m7wu XgEw06fkx3wx7fkftFNNmVayktKlf+ZCMpYPI990J87xKyCQohF59c79hQFL1HgGkowF jJIZDzmiaBSZNmgegbIrVMwn7nfbUxnUFA5VqcSheAWnh3wIVsNFe6lSKwHhFTwe4oCP YMdQ== X-Gm-Message-State: AKaTC00fH0YDTCBdE3lHxizMClyxMFN8GyZfsQap2/U6nMgjO6vDZl4eCyJJaB1Czfev8S+vBv7L9e82wKUj0Q== X-Received: by 10.31.128.132 with SMTP id b126mr72055vkd.52.1481772073754; Wed, 14 Dec 2016 19:21:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.5.198 with HTTP; Wed, 14 Dec 2016 19:21:13 -0800 (PST) In-Reply-To: References: From: Sepherosa Ziehau Date: Thu, 15 Dec 2016 11:21:13 +0800 Message-ID: To: "zhangyali (D)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh?= =?utf-8?q?bout_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Dec 2016 03:21:33 -0000 I believe delack timeout has been 100ms on FreeBSD since 1999, while RTO min is >=3D 200ms by default on FreeBSD. On Thu, Dec 15, 2016 at 11:08 AM, zhangyali (D) w= rote: > Please allow me to add one more point. If the probability of odd number o= f > packets occurring spurious RTO is so outstanding, why nobody try to solv= e > this problem? > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: tcpm [mailto:tcpm-bounces@ietf.org] =E4=BB= =A3=E8=A1=A8 zhangyali (D) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B412=E6=9C=8815=E6=97=A5= 9:45 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Neal Cardwell > =E6=8A=84=E9=80=81: tcpm@ietf.org > =E4=B8=BB=E9=A2=98: [tcpm] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: A ques= tion about Delayed ACK and RTO > > > >> Yes, there should only be a delayed ACK at the end of an application chu= nk >> if there is an odd number of packets. But we would expect roughly half o= f >> application chunks to have an odd number of packets. Though the proporti= on >> is probably higher than that, since many application chunks are just one >> packet (e.g. an HTTP or RPC request or response). > > > > I agree with you that odd number of packets may occur spurious RTO more > easily, but I think for the flows owning just one packet should not be > affected by delayed ACK. AFAIK, slow-start stage will begin with one pack= et, > and sender will send two packets after it receives an ACK. If the first > packet is obstructed by the delayed ACK, the =E2=80=98clock algorithm=E2= =80=99 will be > broken down. So receiver should judge if this packet is the first one in = the > slow-start stage, if yes, send the ack immediately once receiving the > packet. > > > > Yali > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Neal Cardwell [mailto:ncardwell@google.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B412=E6=9C=8814=E6=97=A5= 21:24 > =E6=94=B6=E4=BB=B6=E4=BA=BA: zhangyali (D) > =E6=8A=84=E9=80=81: tcpm@ietf.org > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [tcpm] A question about Delay= ed ACK and RTO > > > > On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) > wrote: > > Hi Neal, > > > > Thanks for your providing request information. > > > > About the delay of delayed ACK, I found another clue in a SIGCOMM paper i= n > 1988. In the page 14, a sentence is =E2=80=9CThe 4.5KBps senders were tal= king to > 4.3BSD receivers which would delay an ack until 35% of the window was fil= led > or 200 ms had passed (i.e., an ack was delayed for 5-7 packets on average= ).=E2=80=9D > There is no reference about the 200 ms, so I guess this is the particular > delay appears for the first time. > > I try to calculate the value based on delayed packet numbers, packet size > and sending rate. In this case, the delayed packet number is 7, the packe= t > size is 576Byte (refer to RFC879 in 1983), and sundering rate is 4.5Bps. = The > value is 896 ms! Longer than 200 ms. > > > >>. However, it's quite easy for a bulk transfer to never have any delayed >> ACKs for most of its lifetime, during which the RTO gradually converges >> toward the raw RTT value. Then when there is suddenly a delayed ACK, the= re >> can be a spurious RTO. > > I am not very sure if I see your point. I think the key point is the RTT > variation will be weakened when packets are sent in a burst (the conseque= nce > of delayed ACK). And the spurious could only happen for the last few > packets whose number is smaller than delayed packets, right? > > > > Yes, there should only be a delayed ACK at the end of an application chun= k > if there is an odd number of packets. But we would expect roughly half of > application chunks to have an odd number of packets. Though the proportio= n > is probably higher than that, since many application chunks are just one > packet (e.g. an HTTP or RPC request or response). > > > > > > About your proposal about negotiation of delayed ACK, a potential problem= is > that RTO will be stretched than before because you add extra delay. As yo= u > have said, most of the packets will not exceed RTO even host enable delay= ed > ACK for most large flows, but the retransmission will be delayed (i.e., > 5ms)also once one packet is lost. > > > > The basic idea of the proposal is to tweak the RTO calculation and turn a > previously existing, historically motivated 200ms fixed "slop factor" int= o a > dynamically negotiated 5ms "slop factor". In our experience that is almos= t > always a win. > > > > neal > > > > > > Best, > > Yali > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Neal Cardwell [mailto:ncardwell@google.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B412=E6=9C=8813=E6=97=A5= 23:18 > =E6=94=B6=E4=BB=B6=E4=BA=BA: zhangyali (D) > =E6=8A=84=E9=80=81: tcpm@ietf.org > =E4=B8=BB=E9=A2=98: Re: [tcpm] A question about Delayed ACK and RTO > > > > On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) > wrote: > > Hi all, > > > > Recent days, I am doing some simulation about TCP performance in NS3. I > found a phenomenon is a default setting of TCP=E2=80=99s delayed ACK is t= wo packets > or 200ms. I am wondering if this setting is accord with some RFCs in IET= F. > But After I referred to some RFCs, I just found some restrictions, such a= s, > the delay must be less than 0.5ms (RFC1122). > > > > I believe the 200ms figure is due to historical reasons. AFAIK it's due t= o > the BSD delayed ACK behavior (see Stevens "TCP/IP Illustrated Volume 2", > section 25.4 and figure 25.7, which describes the 200ms delayed ACK timer= ). > Then this value was inherited by other widely-deployed OSes. > > > > > > I think the delayed ACK has a close relationship with RTO. Take an extrem= e > scenario, if the delay is longer than RTO, many packets will be > retransmitted, which will waste many network resources. > > > > Yes, exactly. In theory, the RTO tries to be adaptive enough to measure a= ny > RTT variations caused by delayed ACKs, and increase the RTO in response t= o > this. However, it's quite easy for a bulk transfer to never have any dela= yed > ACKs for most of its lifetime, during which the RTO gradually converges > toward the raw RTT value. Then when there is suddenly a delayed ACK, ther= e > can be a spurious RTO. > > > > To avoid that, many TCP stacks (at least the major open source OSes) have= a > hard-coded 200ms "slop factor" or "fudge factor", to try to never let the= ir > estimate of RTT variation fall below that 200ms value, to avoid this effe= ct. > > > > So I want to know do we have some RFCs have given the exact value of both= ? > And if we permit any TCP stack to set them freely, what is the mechanism = to > balance the mismatch between RTO and delayed ACK? > > > > I'm not aware of RFC specifications for exact values of both (delayed ACK > and RTO). However, the historical precedent is very strong, and the 200ms > delayed ACK value was very pronounced in Internet traces at least as > recently as 2011, when I last looked at the effect. (Probably others have > more recent data points for the prevalence of 200ms delayed ACKs.) > > > > At IETF 97 our team at Google presented some features we use for internal > TCP traffic at Google, where the endpoints can negotiate the specific > constant to use for the maximum delayed ACK from the receiver and the > corresponding minimum RTT delay variation for budgeting in the RTO at the > sender: > > > > > https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for= -low-latency-00.pdf > > > > As this slide deck notes, within Google we negotiate 5ms for delayed ACKs= . > > > > cheers, > > neal > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --=20 Tomorrow Will Never Die From nobody Thu Dec 15 00:24:32 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B569129577 for ; Thu, 15 Dec 2016 00:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.297 X-Spam-Level: X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN1AQQG9GAmG for ; Thu, 15 Dec 2016 00:24:28 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9525D129462 for ; Thu, 15 Dec 2016 00:24:28 -0800 (PST) Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com [209.85.217.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 24E542791E6 for ; Thu, 15 Dec 2016 17:24:26 +0900 (JST) Received: by mail-ua0-f182.google.com with SMTP id b35so120810uaa.3 for ; Thu, 15 Dec 2016 00:24:26 -0800 (PST) X-Gm-Message-State: AKaTC01jaR7kx8EWC1qTeVbZgWsFiDO9IsNrybdQ8Jq88RsuSAKiV6XpZD5mbju8GEkO3kmHt9F1WVk4t72bGA== X-Received: by 10.176.0.168 with SMTP id 37mr101045uaj.16.1481790264530; Thu, 15 Dec 2016 00:24:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.3.169 with HTTP; Thu, 15 Dec 2016 00:24:24 -0800 (PST) In-Reply-To: References: From: Yoshifumi Nishida Date: Thu, 15 Dec 2016 00:24:24 -0800 X-Gmail-Original-Message-ID: Message-ID: To: "zhangyali (D)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh?= =?utf-8?q?bout_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Dec 2016 08:24:31 -0000 A question would be when TCP sent odd number of packets, how it can know whether another packets will come from upper layer very soon or not. Also, I'm not very sure yet if the probability is so obvious. I can agree that RTO can get close to raw rtt value under bulk transfer. But, I am guessing not so many apps change the behavior from bulk transfer to spontaneous small burst transfer. -- Yoshi On Wed, Dec 14, 2016 at 7:08 PM, zhangyali (D) wr= ote: > Please allow me to add one more point. If the probability of odd number o= f > packets occurring spurious RTO is so outstanding, why nobody try to solv= e > this problem? > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: tcpm [mailto:tcpm-bounces@ietf.org] =E4=BB= =A3=E8=A1=A8 zhangyali (D) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B412=E6=9C=8815=E6=97=A5= 9:45 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Neal Cardwell > =E6=8A=84=E9=80=81: tcpm@ietf.org > =E4=B8=BB=E9=A2=98: [tcpm] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: A ques= tion about Delayed ACK and RTO > > > >> Yes, there should only be a delayed ACK at the end of an application chu= nk >> if there is an odd number of packets. But we would expect roughly half o= f >> application chunks to have an odd number of packets. Though the proporti= on >> is probably higher than that, since many application chunks are just one >> packet (e.g. an HTTP or RPC request or response). > > > > I agree with you that odd number of packets may occur spurious RTO more > easily, but I think for the flows owning just one packet should not be > affected by delayed ACK. AFAIK, slow-start stage will begin with one pack= et, > and sender will send two packets after it receives an ACK. If the first > packet is obstructed by the delayed ACK, the =E2=80=98clock algorithm=E2= =80=99 will be > broken down. So receiver should judge if this packet is the first one in = the > slow-start stage, if yes, send the ack immediately once receiving the > packet. > > > > Yali > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Neal Cardwell [mailto:ncardwell@google.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B412=E6=9C=8814=E6=97=A5= 21:24 > =E6=94=B6=E4=BB=B6=E4=BA=BA: zhangyali (D) > =E6=8A=84=E9=80=81: tcpm@ietf.org > =E4=B8=BB=E9=A2=98: Re: =E7=AD=94=E5=A4=8D: [tcpm] A question about Delay= ed ACK and RTO > > > > On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) > wrote: > > Hi Neal, > > > > Thanks for your providing request information. > > > > About the delay of delayed ACK, I found another clue in a SIGCOMM paper i= n > 1988. In the page 14, a sentence is =E2=80=9CThe 4.5KBps senders were tal= king to > 4.3BSD receivers which would delay an ack until 35% of the window was fil= led > or 200 ms had passed (i.e., an ack was delayed for 5-7 packets on average= ).=E2=80=9D > There is no reference about the 200 ms, so I guess this is the particular > delay appears for the first time. > > I try to calculate the value based on delayed packet numbers, packet size > and sending rate. In this case, the delayed packet number is 7, the packe= t > size is 576Byte (refer to RFC879 in 1983), and sundering rate is 4.5Bps. = The > value is 896 ms! Longer than 200 ms. > > > >>. However, it's quite easy for a bulk transfer to never have any delayed >> ACKs for most of its lifetime, during which the RTO gradually converges >> toward the raw RTT value. Then when there is suddenly a delayed ACK, the= re >> can be a spurious RTO. > > I am not very sure if I see your point. I think the key point is the RTT > variation will be weakened when packets are sent in a burst (the conseque= nce > of delayed ACK). And the spurious could only happen for the last few > packets whose number is smaller than delayed packets, right? > > > > Yes, there should only be a delayed ACK at the end of an application chun= k > if there is an odd number of packets. But we would expect roughly half of > application chunks to have an odd number of packets. Though the proportio= n > is probably higher than that, since many application chunks are just one > packet (e.g. an HTTP or RPC request or response). > > > > > > About your proposal about negotiation of delayed ACK, a potential problem= is > that RTO will be stretched than before because you add extra delay. As yo= u > have said, most of the packets will not exceed RTO even host enable delay= ed > ACK for most large flows, but the retransmission will be delayed (i.e., > 5ms)also once one packet is lost. > > > > The basic idea of the proposal is to tweak the RTO calculation and turn a > previously existing, historically motivated 200ms fixed "slop factor" int= o a > dynamically negotiated 5ms "slop factor". In our experience that is almos= t > always a win. > > > > neal > > > > > > Best, > > Yali > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Neal Cardwell [mailto:ncardwell@google.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B412=E6=9C=8813=E6=97=A5= 23:18 > =E6=94=B6=E4=BB=B6=E4=BA=BA: zhangyali (D) > =E6=8A=84=E9=80=81: tcpm@ietf.org > =E4=B8=BB=E9=A2=98: Re: [tcpm] A question about Delayed ACK and RTO > > > > On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) > wrote: > > Hi all, > > > > Recent days, I am doing some simulation about TCP performance in NS3. I > found a phenomenon is a default setting of TCP=E2=80=99s delayed ACK is t= wo packets > or 200ms. I am wondering if this setting is accord with some RFCs in IET= F. > But After I referred to some RFCs, I just found some restrictions, such a= s, > the delay must be less than 0.5ms (RFC1122). > > > > I believe the 200ms figure is due to historical reasons. AFAIK it's due t= o > the BSD delayed ACK behavior (see Stevens "TCP/IP Illustrated Volume 2", > section 25.4 and figure 25.7, which describes the 200ms delayed ACK timer= ). > Then this value was inherited by other widely-deployed OSes. > > > > > > I think the delayed ACK has a close relationship with RTO. Take an extrem= e > scenario, if the delay is longer than RTO, many packets will be > retransmitted, which will waste many network resources. > > > > Yes, exactly. In theory, the RTO tries to be adaptive enough to measure a= ny > RTT variations caused by delayed ACKs, and increase the RTO in response t= o > this. However, it's quite easy for a bulk transfer to never have any dela= yed > ACKs for most of its lifetime, during which the RTO gradually converges > toward the raw RTT value. Then when there is suddenly a delayed ACK, ther= e > can be a spurious RTO. > > > > To avoid that, many TCP stacks (at least the major open source OSes) have= a > hard-coded 200ms "slop factor" or "fudge factor", to try to never let the= ir > estimate of RTT variation fall below that 200ms value, to avoid this effe= ct. > > > > So I want to know do we have some RFCs have given the exact value of both= ? > And if we permit any TCP stack to set them freely, what is the mechanism = to > balance the mismatch between RTO and delayed ACK? > > > > I'm not aware of RFC specifications for exact values of both (delayed ACK > and RTO). However, the historical precedent is very strong, and the 200ms > delayed ACK value was very pronounced in Internet traces at least as > recently as 2011, when I last looked at the effect. (Probably others have > more recent data points for the prevalence of 200ms delayed ACKs.) > > > > At IETF 97 our team at Google presented some features we use for internal > TCP traffic at Google, where the endpoints can negotiate the specific > constant to use for the maximum delayed ACK from the receiver and the > corresponding minimum RTT delay variation for budgeting in the RTO at the > sender: > > > > > https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for= -low-latency-00.pdf > > > > As this slide deck notes, within Google we negotiate 5ms for delayed ACKs= . > > > > cheers, > > neal > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Thu Dec 15 02:21:11 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1EF129521 for ; Thu, 15 Dec 2016 02:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ6EiACVKxPW for ; Thu, 15 Dec 2016 02:21:06 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 063C212943F for ; Thu, 15 Dec 2016 02:21:06 -0800 (PST) Received: from dhcp-207-163.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:b1ed:238e:d12c:7706]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 50ED91B0020B; Thu, 15 Dec 2016 12:19:10 +0000 (GMT) References: To: Yoshifumi Nishida , "zhangyali (D)" From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> Date: Thu, 15 Dec 2016 10:20:56 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh?= =?utf-8?q?bout_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 10:21:10 -0000 Just adding a few more comments here, because there has been much talk about how desirable it is for the RTO to converge to the RTT, and I think we need to be clear. The TCP RTO has two distinct functions: (1) the RTO is of course the method of last resort for the recovery of a lost segment (the final segment of a burst, following persistent loss, etc). (2) Second the RTO is method to detect a path failure - where something has changed significantly. As such, triggering a conservative (1 or 3 seconds) RTO implies that state about the path needs to be reset (RTT, perhaps invoking PMTUD, congestion state variables, etc, possibly in the future falling back from using ECN, etc) For the first function, there are many ways to detect lost segments (Dupacks, probe packets, recovery timers, etc). All of these act faster than a conservatively set timeout. They also do not need to erase collected path state, they can simply re-transmit the lost segments. An RTO close to the RTT will be disastrous for some paths. This is one of the reasons why people have deployed PEPs to support radio technology - we should not be encouraging this. An RTO set close to the RTT can produce complex interactions when the path characteristics change (which does happen with propagation impairments and radio resource management, on wireless, microwave satellite and other paths, and also with middleboxes that attempt to control capacity/volume usage). This type of path is not going away, talk of wireless links with top speeds of Gbps for 5G will likely be accompanied by very large variation in path characteristics - at the other extreme people in large parts of the world are still with kbps technology. If the timer only recovers packets, it would simply result in retransmission, if it triggers other probing that would be unfortunate. I think the IETF needs to ensure our specs work for all people. What I am saying is that the second function does not need a timeout period near the RTT. Robust protocols have been designed to have a conservative RTO timer that is set to much more than a RTT, designed to detect an unresponsive endpoint or path problem. The IETF has argued - and to my knowledge still argues that Min_RTO should be one second, which I think reflects this position. If the loss recovery is efficient, this will trigger only infrequently (e.g., persistent loss of one packet). I think this is the correct way to design TCP. It motivates that we should actually strive for a one second (or so) RTO. Gorry On 15/12/2016 08:24, Yoshifumi Nishida wrote: > A question would be when TCP sent odd number of packets, how it can > know whether another packets will come from upper layer very soon or > not. Also, I'm not very sure yet if the probability is so obvious. I > can agree that RTO can get close to raw rtt value under bulk transfer. > But, I am guessing not so many apps change the behavior from bulk > transfer to spontaneous small burst transfer. > -- > Yoshi > > > On Wed, Dec 14, 2016 at 7:08 PM, zhangyali (D) wrote: >> Please allow me to add one more point. If the probability of odd number of >> packets occurring spurious RTO is so outstanding, why nobody try to solve >> this problem? >> >> >> >> 发件人: tcpm [mailto:tcpm-bounces@ietf.org] 代表 zhangyali (D) >> 发é€ć—¶é—´: 2016ĺą´12ćś15ć—Ą 9:45 >> 收件人: Neal Cardwell >> 抄é€: tcpm@ietf.org >> 主é˘: [tcpm] 答复: 答复: A question about Delayed ACK and RTO >> >> >> >>> Yes, there should only be a delayed ACK at the end of an application chunk >>> if there is an odd number of packets. But we would expect roughly half of >>> application chunks to have an odd number of packets. Though the proportion >>> is probably higher than that, since many application chunks are just one >>> packet (e.g. an HTTP or RPC request or response). >> >> >> >> I agree with you that odd number of packets may occur spurious RTO more >> easily, but I think for the flows owning just one packet should not be >> affected by delayed ACK. AFAIK, slow-start stage will begin with one packet, >> and sender will send two packets after it receives an ACK. If the first >> packet is obstructed by the delayed ACK, the â€clock algorithm’ will be >> broken down. So receiver should judge if this packet is the first one in the >> slow-start stage, if yes, send the ack immediately once receiving the >> packet. >> >> >> >> Yali >> >> >> >> 发件人: Neal Cardwell [mailto:ncardwell@google.com] >> 发é€ć—¶é—´: 2016ĺą´12ćś14ć—Ą 21:24 >> 收件人: zhangyali (D) >> 抄é€: tcpm@ietf.org >> 主é˘: Re: 答复: [tcpm] A question about Delayed ACK and RTO >> >> >> >> On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) >> wrote: >> >> Hi Neal, >> >> >> >> Thanks for your providing request information. >> >> >> >> About the delay of delayed ACK, I found another clue in a SIGCOMM paper in >> 1988. In the page 14, a sentence is “The 4.5KBps senders were talking to >> 4.3BSD receivers which would delay an ack until 35% of the window was filled >> or 200 ms had passed (i.e., an ack was delayed for 5-7 packets on average).” >> There is no reference about the 200 ms, so I guess this is the particular >> delay appears for the first time. >> >> I try to calculate the value based on delayed packet numbers, packet size >> and sending rate. In this case, the delayed packet number is 7, the packet >> size is 576Byte (refer to RFC879 in 1983), and sundering rate is 4.5Bps. The >> value is 896 ms! Longer than 200 ms. >> >> >> >>> . However, it's quite easy for a bulk transfer to never have any delayed >>> ACKs for most of its lifetime, during which the RTO gradually converges >>> toward the raw RTT value. Then when there is suddenly a delayed ACK, there >>> can be a spurious RTO. >> >> I am not very sure if I see your point. I think the key point is the RTT >> variation will be weakened when packets are sent in a burst (the consequence >> of delayed ACK). And the spurious could only happen for the last few >> packets whose number is smaller than delayed packets, right? >> >> >> >> Yes, there should only be a delayed ACK at the end of an application chunk >> if there is an odd number of packets. But we would expect roughly half of >> application chunks to have an odd number of packets. Though the proportion >> is probably higher than that, since many application chunks are just one >> packet (e.g. an HTTP or RPC request or response). >> >> >> >> >> >> About your proposal about negotiation of delayed ACK, a potential problem is >> that RTO will be stretched than before because you add extra delay. As you >> have said, most of the packets will not exceed RTO even host enable delayed >> ACK for most large flows, but the retransmission will be delayed (i.e., >> 5ms)also once one packet is lost. >> >> >> >> The basic idea of the proposal is to tweak the RTO calculation and turn a >> previously existing, historically motivated 200ms fixed "slop factor" into a >> dynamically negotiated 5ms "slop factor". In our experience that is almost >> always a win. >> >> >> >> neal >> >> >> >> >> >> Best, >> >> Yali >> >> 发件人: Neal Cardwell [mailto:ncardwell@google.com] >> 发é€ć—¶é—´: 2016ĺą´12ćś13ć—Ą 23:18 >> 收件人: zhangyali (D) >> 抄é€: tcpm@ietf.org >> 主é˘: Re: [tcpm] A question about Delayed ACK and RTO >> >> >> >> On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) >> wrote: >> >> Hi all, >> >> >> >> Recent days, I am doing some simulation about TCP performance in NS3. I >> found a phenomenon is a default setting of TCP’s delayed ACK is two packets >> or 200ms. I am wondering if this setting is accord with some RFCs in IETF. >> But After I referred to some RFCs, I just found some restrictions, such as, >> the delay must be less than 0.5ms (RFC1122). >> >> >> >> I believe the 200ms figure is due to historical reasons. AFAIK it's due to >> the BSD delayed ACK behavior (see Stevens "TCP/IP Illustrated Volume 2", >> section 25.4 and figure 25.7, which describes the 200ms delayed ACK timer). >> Then this value was inherited by other widely-deployed OSes. >> >> >> >> >> >> I think the delayed ACK has a close relationship with RTO. Take an extreme >> scenario, if the delay is longer than RTO, many packets will be >> retransmitted, which will waste many network resources. >> >> >> >> Yes, exactly. In theory, the RTO tries to be adaptive enough to measure any >> RTT variations caused by delayed ACKs, and increase the RTO in response to >> this. However, it's quite easy for a bulk transfer to never have any delayed >> ACKs for most of its lifetime, during which the RTO gradually converges >> toward the raw RTT value. Then when there is suddenly a delayed ACK, there >> can be a spurious RTO. >> >> >> >> To avoid that, many TCP stacks (at least the major open source OSes) have a >> hard-coded 200ms "slop factor" or "fudge factor", to try to never let their >> estimate of RTT variation fall below that 200ms value, to avoid this effect. >> >> >> >> So I want to know do we have some RFCs have given the exact value of both? >> And if we permit any TCP stack to set them freely, what is the mechanism to >> balance the mismatch between RTO and delayed ACK? >> >> >> >> I'm not aware of RFC specifications for exact values of both (delayed ACK >> and RTO). However, the historical precedent is very strong, and the 200ms >> delayed ACK value was very pronounced in Internet traces at least as >> recently as 2011, when I last looked at the effect. (Probably others have >> more recent data points for the prevalence of 200ms delayed ACKs.) >> >> >> >> At IETF 97 our team at Google presented some features we use for internal >> TCP traffic at Google, where the endpoints can negotiate the specific >> constant to use for the maximum delayed ACK from the receiver and the >> corresponding minimum RTT delay variation for budgeting in the RTO at the >> sender: >> >> >> >> >> https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdf >> >> >> >> As this slide deck notes, within Google we negotiate 5ms for delayed ACKs. >> >> >> >> cheers, >> >> neal >> >> >> >> >> >> >> _______________________________________________ >> 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 nobody Thu Dec 15 03:25:26 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DC3129A13 for ; Thu, 15 Dec 2016 03:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=palermo.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aErIsxr8teWh for ; Thu, 15 Dec 2016 03:25:21 -0800 (PST) Received: from maxwell.palermo.edu (maxwell.palermo.edu [200.69.213.7]) by ietfa.amsl.com (Postfix) with ESMTP id 12E7C129A10 for ; Thu, 15 Dec 2016 03:25:20 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.8.4 maxwell.palermo.edu uBFBOK4w010331 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=palermo.edu; s=default; t=1481801060; bh=41Pv50QOQTEm+PmvYjQyWXJPeH8liUyBydOnw88Rib8=; h=To:References:From:Date:In-Reply-To:Subject; b=NXT26segL4fJfl+EPQhuSH1B5rofjkxGquUwZgfknWNGG1rFsBJiCcOr5k6XoYTtc oKKd/XQyWJP6vg20WobUS7KnAbGpXQSDCzWiP/Fwa5qKfPmBjaMkkqJxw9NjovKtVh aXJtCTOHJZhj6zFs+HtZJUKKKZ79BqeIvOXoiBw8= Received: from maxwell.palermo.edu (localhost [127.0.0.1]) by maxwell.palermo.edu (8.14.4/8.14.4) with ESMTP id uBFBOK4w010331 for ; Thu, 15 Dec 2016 08:24:20 -0300 Received: from [192.168.2.154] ( [200.49.156.100]) by maxwell.palermo.edu with ESMTP id VOH3T03W.1292349.0 To: tcpm@ietf.org References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> From: Alejandro Popovsky Message-ID: Date: Thu, 15 Dec 2016 08:25:19 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Authorization-Id: who=apopov X-Host: 200.49.156.100 Archived-At: Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh?= =?utf-8?q?bout_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Dec 2016 11:25:25 -0000 Tcp would benefit much from and 'end of app write call' signal or may be 'end of sender buffer data' signal. TLP, adaptive RTO at the end of bursts, end of burst reordering, and may be some other mechanisms were introduced to help with this issue. May be the addition of an option for this signal may help, or may be the reinterpretation of the push flag. This would need the modification of both senders and receivers, so the effect of not having a modified receiver getting the flag should be contemplated. Alejandro. On 15/12/2016 7:20 a. m., Gorry Fairhurst wrote: > > Just adding a few more comments here, because there has been much talk > about how desirable it is for the RTO to converge to the RTT, and I > think we need to be clear. > > The TCP RTO has two distinct functions: > > (1) the RTO is of course the method of last resort for the recovery > of a lost segment (the final segment of a burst, following persistent > loss, etc). > > (2) Second the RTO is method to detect a path failure - where > something has changed significantly. As such, triggering a > conservative (1 or 3 seconds) RTO implies that state about the path > needs to be reset (RTT, perhaps invoking PMTUD, congestion state > variables, etc, possibly in the future falling back from using ECN, etc) > > For the first function, there are many ways to detect lost segments > (Dupacks, probe packets, recovery timers, etc). All of these act > faster than a conservatively set timeout. They also do not need to > erase collected path state, they can simply re-transmit the lost > segments. > > An RTO close to the RTT will be disastrous for some paths. This is one > of the reasons why people have deployed PEPs to support radio > technology - we should not be encouraging this. An RTO set close to > the RTT can produce complex interactions when the path characteristics > change (which does happen with propagation impairments and radio > resource management, on wireless, microwave satellite and other paths, > and also with middleboxes that attempt to control capacity/volume > usage). This type of path is not going away, talk of wireless links > with top speeds of Gbps for 5G will likely be accompanied by very > large variation in path characteristics - at the other extreme people > in large parts of the world are still with kbps technology. If the > timer only recovers packets, it would simply result in retransmission, > if it triggers other probing that would be unfortunate. I think the > IETF needs to ensure our specs work for all people. > > What I am saying is that the second function does not need a timeout > period near the RTT. Robust protocols have been designed to have a > conservative RTO timer that is set to much more than a RTT, designed > to detect an unresponsive endpoint or path problem. The IETF has > argued - and to my knowledge still argues that Min_RTO should be one > second, which I think reflects this position. If the loss recovery is > efficient, this will trigger only infrequently (e.g., persistent loss > of one packet). I think this is the correct way to design TCP. It > motivates that we should actually strive for a one second (or so) RTO. > > Gorry > > > On 15/12/2016 08:24, Yoshifumi Nishida wrote: >> A question would be when TCP sent odd number of packets, how it can >> know whether another packets will come from upper layer very soon or >> not. Also, I'm not very sure yet if the probability is so obvious. I >> can agree that RTO can get close to raw rtt value under bulk transfer. >> But, I am guessing not so many apps change the behavior from bulk >> transfer to spontaneous small burst transfer. >> -- >> Yoshi >> >> >> On Wed, Dec 14, 2016 at 7:08 PM, zhangyali (D) >> wrote: >>> Please allow me to add one more point. If the probability of odd >>> number of >>> packets occurring spurious RTO is so outstanding, why nobody try to >>> solve >>> this problem? >>> >>> >>> >>> 发件人: tcpm [mailto:tcpm-bounces@ietf.org] 代表 zhangyali (D) >>> 发é€ć—¶é—´: 2016ĺą´12ćś15ć—Ą 9:45 >>> 收件人: Neal Cardwell >>> 抄é€: tcpm@ietf.org >>> 主é˘: [tcpm] 答复: 答复: A question about Delayed ACK and RTO >>> >>> >>> >>>> Yes, there should only be a delayed ACK at the end of an >>>> application chunk >>>> if there is an odd number of packets. But we would expect roughly >>>> half of >>>> application chunks to have an odd number of packets. Though the >>>> proportion >>>> is probably higher than that, since many application chunks are >>>> just one >>>> packet (e.g. an HTTP or RPC request or response). >>> >>> >>> >>> I agree with you that odd number of packets may occur spurious RTO more >>> easily, but I think for the flows owning just one packet should not be >>> affected by delayed ACK. AFAIK, slow-start stage will begin with one >>> packet, >>> and sender will send two packets after it receives an ACK. If the first >>> packet is obstructed by the delayed ACK, the â€clock algorithm’ will be >>> broken down. So receiver should judge if this packet is the first >>> one in the >>> slow-start stage, if yes, send the ack immediately once receiving the >>> packet. >>> >>> >>> >>> Yali >>> >>> >>> >>> 发件人: Neal Cardwell [mailto:ncardwell@google.com] >>> 发é€ć—¶é—´: 2016ĺą´12ćś14ć—Ą 21:24 >>> 收件人: zhangyali (D) >>> 抄é€: tcpm@ietf.org >>> 主é˘: Re: 答复: [tcpm] A question about Delayed ACK and RTO >>> >>> >>> >>> On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) >>> >>> wrote: >>> >>> Hi Neal, >>> >>> >>> >>> Thanks for your providing request information. >>> >>> >>> >>> About the delay of delayed ACK, I found another clue in a SIGCOMM >>> paper in >>> 1988. In the page 14, a sentence is “The 4.5KBps senders were >>> talking to >>> 4.3BSD receivers which would delay an ack until 35% of the window >>> was filled >>> or 200 ms had passed (i.e., an ack was delayed for 5-7 packets on >>> average).” >>> There is no reference about the 200 ms, so I guess this is the >>> particular >>> delay appears for the first time. >>> >>> I try to calculate the value based on delayed packet numbers, packet >>> size >>> and sending rate. In this case, the delayed packet number is 7, the >>> packet >>> size is 576Byte (refer to RFC879 in 1983), and sundering rate is >>> 4.5Bps. The >>> value is 896 ms! Longer than 200 ms. >>> >>> >>> >>>> . However, it's quite easy for a bulk transfer to never have any >>>> delayed >>>> ACKs for most of its lifetime, during which the RTO gradually >>>> converges >>>> toward the raw RTT value. Then when there is suddenly a delayed >>>> ACK, there >>>> can be a spurious RTO. >>> >>> I am not very sure if I see your point. I think the key point is the >>> RTT >>> variation will be weakened when packets are sent in a burst (the >>> consequence >>> of delayed ACK). And the spurious could only happen for the last few >>> packets whose number is smaller than delayed packets, right? >>> >>> >>> >>> Yes, there should only be a delayed ACK at the end of an application >>> chunk >>> if there is an odd number of packets. But we would expect roughly >>> half of >>> application chunks to have an odd number of packets. Though the >>> proportion >>> is probably higher than that, since many application chunks are just >>> one >>> packet (e.g. an HTTP or RPC request or response). >>> >>> >>> >>> >>> >>> About your proposal about negotiation of delayed ACK, a potential >>> problem is >>> that RTO will be stretched than before because you add extra delay. >>> As you >>> have said, most of the packets will not exceed RTO even host enable >>> delayed >>> ACK for most large flows, but the retransmission will be delayed (i.e., >>> 5ms)also once one packet is lost. >>> >>> >>> >>> The basic idea of the proposal is to tweak the RTO calculation and >>> turn a >>> previously existing, historically motivated 200ms fixed "slop >>> factor" into a >>> dynamically negotiated 5ms "slop factor". In our experience that is >>> almost >>> always a win. >>> >>> >>> >>> neal >>> >>> >>> >>> >>> >>> Best, >>> >>> Yali >>> >>> 发件人: Neal Cardwell [mailto:ncardwell@google.com] >>> 发é€ć—¶é—´: 2016ĺą´12ćś13ć—Ą 23:18 >>> 收件人: zhangyali (D) >>> 抄é€: tcpm@ietf.org >>> 主é˘: Re: [tcpm] A question about Delayed ACK and RTO >>> >>> >>> >>> On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) >>> >>> wrote: >>> >>> Hi all, >>> >>> >>> >>> Recent days, I am doing some simulation about TCP performance in NS3. I >>> found a phenomenon is a default setting of TCP’s delayed ACK is two >>> packets >>> or 200ms. I am wondering if this setting is accord with some RFCs >>> in IETF. >>> But After I referred to some RFCs, I just found some restrictions, >>> such as, >>> the delay must be less than 0.5ms (RFC1122). >>> >>> >>> >>> I believe the 200ms figure is due to historical reasons. AFAIK it's >>> due to >>> the BSD delayed ACK behavior (see Stevens "TCP/IP Illustrated Volume >>> 2", >>> section 25.4 and figure 25.7, which describes the 200ms delayed ACK >>> timer). >>> Then this value was inherited by other widely-deployed OSes. >>> >>> >>> >>> >>> >>> I think the delayed ACK has a close relationship with RTO. Take an >>> extreme >>> scenario, if the delay is longer than RTO, many packets will be >>> retransmitted, which will waste many network resources. >>> >>> >>> >>> Yes, exactly. In theory, the RTO tries to be adaptive enough to >>> measure any >>> RTT variations caused by delayed ACKs, and increase the RTO in >>> response to >>> this. However, it's quite easy for a bulk transfer to never have any >>> delayed >>> ACKs for most of its lifetime, during which the RTO gradually converges >>> toward the raw RTT value. Then when there is suddenly a delayed ACK, >>> there >>> can be a spurious RTO. >>> >>> >>> >>> To avoid that, many TCP stacks (at least the major open source OSes) >>> have a >>> hard-coded 200ms "slop factor" or "fudge factor", to try to never >>> let their >>> estimate of RTT variation fall below that 200ms value, to avoid this >>> effect. >>> >>> >>> >>> So I want to know do we have some RFCs have given the exact value of >>> both? >>> And if we permit any TCP stack to set them freely, what is the >>> mechanism to >>> balance the mismatch between RTO and delayed ACK? >>> >>> >>> >>> I'm not aware of RFC specifications for exact values of both >>> (delayed ACK >>> and RTO). However, the historical precedent is very strong, and the >>> 200ms >>> delayed ACK value was very pronounced in Internet traces at least as >>> recently as 2011, when I last looked at the effect. (Probably others >>> have >>> more recent data points for the prevalence of 200ms delayed ACKs.) >>> >>> >>> >>> At IETF 97 our team at Google presented some features we use for >>> internal >>> TCP traffic at Google, where the endpoints can negotiate the specific >>> constant to use for the maximum delayed ACK from the receiver and the >>> corresponding minimum RTT delay variation for budgeting in the RTO >>> at the >>> sender: >>> >>> >>> >>> >>> https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdf >>> >>> >>> >>> >>> As this slide deck notes, within Google we negotiate 5ms for delayed >>> ACKs. >>> >>> >>> >>> cheers, >>> >>> neal >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Dec 15 06:53:03 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B59212969D for ; Thu, 15 Dec 2016 06:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmvyRx7rwH01 for ; Thu, 15 Dec 2016 06:53:00 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8900812945E for ; Thu, 15 Dec 2016 06:52:58 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id uBFEqN7T017446; Thu, 15 Dec 2016 06:52:24 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 482AB698C136; Thu, 15 Dec 2016 09:52:23 -0500 (EST) To: gorry@erg.abdn.ac.uk From: Mark Allman In-Reply-To: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: I'm No Angel X-URL-0: http://www.icir.org/mallman-files/Document79668.doc X-URL-1: http://www.icir.org/mallman-files/Document40639.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 15 Dec 2016 09:52:23 -0500 Message-ID: <29664.1481813543@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh?= =?utf-8?q?bout_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 14:53:02 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I agree with Gorry's take on variable path characteristics and all.=20 > The TCP RTO has two distinct functions: >=20 > (1) the RTO is of course the method of last resort for the recovery > of a lost segment (the final segment of a burst, following > persistent loss, etc). >=20 > (2) Second the RTO is method to detect a path failure - where > something has changed significantly. I think this is an accident. And, the way we should handle it is to not conflate such disparate functions into one mechanism. The RTO is a ***retransmission*** timeout. It's original function was to decide when to trigger resending data that has not been ACKed because after this time period chances are the packet was lost (i.e., case (1)). Independently we do need to understand path failure. And, part of detecting path failure may well be detecting that packets are not being delivered. However, this is a different issue than figuring out when to resend a segment. The fact that we use the RTO for this function boils down to laziness in re-using something that was laying around instead of doing it right. By trying to shoehorn both functions into one mechanism we are ***guaranteeing*** that the mechanism will be lousy (for at least one of the tasks and probably both!). This thread perfectly illustrates this... If we were to use the RTO for both functions then it would be impossible to reconcile Gorry's notion that path failure happens on long timescales and so RTOs on the order of a second are needed with Neal's world where he wants to trigger retransmissions three orders of magnitude sooner. Path failure may *leverage* loss detection, but it needn't be the exact same such that it *hampers* loss detection. IMHO. :-) allman =2D- http://www.icir.org/mallman/ @mallman_icsi --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlhSriQACgkQWyrrWs4yIs4mKwCfRTes0ywj4ep8JgdT+CcfvNr+ twEAnAxXPZlslis9RmQ+vtCm4dRARXxg =lrR3 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Thu Dec 15 07:30:10 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED2C1294BC for ; Thu, 15 Dec 2016 07:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGe2Y3mGqi_F for ; Thu, 15 Dec 2016 07:30:07 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F191296F5 for ; Thu, 15 Dec 2016 07:30:01 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBFFTeVM018926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 15 Dec 2016 07:29:45 -0800 (PST) To: Alejandro Popovsky , tcpm@ietf.org References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> From: Joe Touch Message-ID: <45f0034f-70a2-2aa3-d87b-c7288a51ad77@isi.edu> Date: Thu, 15 Dec 2016 07:29:39 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh?= =?utf-8?q?bout_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Dec 2016 15:30:08 -0000 On 12/15/2016 3:25 AM, Alejandro Popovsky wrote: > Tcp would benefit much from and 'end of app write call' signal or may > be 'end of sender buffer data' signal. In the current TCP API, there is absolutely no correlation between app SEND calls and any notion TCP might have of boundaries - TCP presents a bytestream service only. There would be many consequences to changing that API, but it might be useful to note that this was once considered. Just two days ago, Bob Braden and I were discussing TCP v3 (before the current one - as documented in IEN 21), which did have this sort of signal, but it was carried into the packet as begin/end (of "letter") flags. Note that his behavior is a consequence of the interaction between delayed ACKs and a lack of application data, and happens any time the app layer "starves" TCP. It was well studied in the 90's in its interaction with persistent web connections. It isn't really related to RTO per se. Joe From nobody Thu Dec 15 10:54:13 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C14129525 for ; Thu, 15 Dec 2016 10:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Md6M9kLcsLO7 for ; Thu, 15 Dec 2016 10:54:10 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33CFE129450 for ; Thu, 15 Dec 2016 10:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3376; q=dns/txt; s=iport; t=1481828050; x=1483037650; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=YJyBdO6/GUJPhA3PPBl2z/pdOyBc7bpCz78afo5+QaQ=; b=acH01VX0XvZdAuplHKR3ofzIw7aQhKOSdIBvujiIodDQbhhAjmijH9WF bCAigWI6dr7M1gRWI8yXFDdWFmUT8HG+zG3F4zj07HDthrFY3u15Hg8VV kD1jJVsqsaHbXUt1CfnmSEXxslB1YdLniM3+esv0VJsv6GX5JwdeY7CxK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DTAQBi5lJY/4YNJK1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM3AQEBAQEfWoEGBwGNRpZYlQqCCR8LhXgCGoFuPxQBAgEBAQE?= =?us-ascii?q?BAQFiKIRoAQEBAgIBAQwEIjECBxcEAgEGAhEEAQEBBCMFAgIlCxQGAwgCBAESC?= =?us-ascii?q?BqISQ6LUY9VAY1wCIImiwgBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEHhS+EWYR?= =?us-ascii?q?XgmmCYQEEmmwBhlCKWZBUjhSEDgEfN4EiKYNUHIEiO3IBhi4HgSkBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,353,1477958400"; d="scan'208";a="187415915" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Dec 2016 18:54:09 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uBFIs9NM029129 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Dec 2016 18:54:09 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 15 Dec 2016 12:54:08 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 15 Dec 2016 12:54:08 -0600 From: "Jakob Heitz (jheitz)" To: Joe Touch , Alejandro Popovsky , "tcpm@ietf.org" Thread-Topic: =?gb2312?B?W3RjcG1dILTwuLQ6ILTwuLQ6ILTwuLQ6IEEgcXVlc3Rpb24gYWJvdXQgRGVs?= =?gb2312?Q?ayed_ACK_and_RTO?= Thread-Index: AQHSVqysk8jt8lCMAkyjbESZ056iY6EJMRMAgAAR/YCAAEREgP//ymbA Date: Thu, 15 Dec 2016 18:54:08 +0000 Message-ID: <59e16ab85bb64c66b39e9d92f9b95a7a@XCH-ALN-014.cisco.com> References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> <45f0034f-70a2-2aa3-d87b-c7288a51ad77@isi.edu> In-Reply-To: <45f0034f-70a2-2aa3-d87b-c7288a51ad77@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.24] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] =?gb2312?b?tPC4tDogtPC4tDogtPC4tDogQSBxdWVzdGlvbiBhYm91?= =?gb2312?b?dCBEZWxheWVkIEFDSyBhbmQgUlRP?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Dec 2016 18:54:12 -0000 VGhpcyBzbyBjYWxsZWQgImFwcCBzdGFydmluZyB0aGUgVENQIiBkb2VzIGhhcHBlbiBhbmQgaXQg aGFwcGVucw0Kb2Z0ZW4gZW5vdWdoIHRvIGJlIGFuIGlzc3VlLiBUaGUgb25seSByZWNvdmVyeSBm cm9tIGEgbG9zcyBhdA0KdGhhdCB0aW1lIGlzIHRoZSByZXRyYW5zbWlzc2lvbiB0aW1lci4NCg0K VGhlIHJldHJhbnNtaXNzaW9uIHRpbWVyIGlzIGEgY29tcHJvbWlzZS4gSWYgaXQgaXMgc2V0IHRv byBsb3csIHRoZW4NCnNwdXJpb3VzIHJldHJhbnNtaXNzaW9ucyBvY2N1ciwgYnV0IGlmIGl0IGlz IHNldCB0b28gaGlnaCwgdGhlbiBpdA0KdGFrZXMgdG9vIGxvbmcgdG8gcmV0cmFuc21pdCB3aGVu IGl0IGlzIHJlYWxseSBuZWVkZWQuDQoNClRoZSByaWdodCBiYWxhbmNlIGlzIGFjaGlldmVkIHdo ZW4gYW4gYWNjZXB0YWJseSBzbWFsbCBudW1iZXIgb2YNCnNwdXJpb3VzIHJldHJhbnNtaXNzaW9u cyBvY2N1ciAobm90IHplcm8pLg0KDQpBYm91dCAzIHllYXJzIGFnbywgSSB3cm90ZSBhIFRDUCBz dGFjayBpbiB1c2VyIHNwYWNlIGFuZCBpdCBmYWNlZA0KaGlnaGx5IGJ1cnN0eSBjb25kaXRpb25z LiBJIGltcGxlbWVudGVkIGEgZGlmZmVyZW50IFJUTyBtZWNoYW5pc20NCndoaWNoIHdvcmtlZCB3 ZWxsLiBJIHByZXNlbnRlZCBpdCBoZXJlOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaGVpdHpoZS10Y3BtLXZtLXJ0by0wMA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTEvc2xpZGVzL3NsaWRlcy05MS10Y3BtLTEucGRmDQoNCk1vcmUgZXhwZXJpZW5jZSB3 aXRoIGl0IHJldmVhbGVkIGFuIGlzc3VlLg0KSXQgd291bGQgaHVtIGFsb25nIHZlcnkgbmljZWx5 IGF0IDEwdVMgYW5kIHRoZW4gaGl0IGEgc3Bpa2UNCm9mIDEgc2Vjb25kLCBjYXVzaW5nIHRoZSBz ZXNzaW9uIHRvIGRyb3AgZHVlIHRvIHNlc3Npb24gdGltZW91dC4NCkEgbWluaW11bSBvZiAxbVMg cHJldmVudHMgdGhlIHByb2JsZW0uDQoNCg0KVGhhbmtzLA0KSmFrb2IuDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lIFRvdWNoDQo+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJl ciAxNSwgMjAxNiA3OjMwIEFNDQo+IFRvOiBBbGVqYW5kcm8gUG9wb3Zza3kgPGFwb3BvdkBwYWxl cm1vLmVkdT47IHRjcG1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0Y3BtXSC08Li0OiC08Li0 OiC08Li0OiBBIHF1ZXN0aW9uIGFib3V0IERlbGF5ZWQgQUNLIGFuZCBSVE8NCj4gDQo+IA0KPiAN Cj4gT24gMTIvMTUvMjAxNiAzOjI1IEFNLCBBbGVqYW5kcm8gUG9wb3Zza3kgd3JvdGU6DQo+ID4g VGNwIHdvdWxkIGJlbmVmaXQgbXVjaCBmcm9tIGFuZCAnZW5kIG9mIGFwcCB3cml0ZSBjYWxsJyBz aWduYWwgb3IgbWF5DQo+ID4gYmUgJ2VuZCBvZiBzZW5kZXIgYnVmZmVyIGRhdGEnIHNpZ25hbC4N Cj4gDQo+ICBJbiB0aGUgY3VycmVudCBUQ1AgQVBJLCB0aGVyZSBpcyBhYnNvbHV0ZWx5IG5vIGNv cnJlbGF0aW9uIGJldHdlZW4gYXBwDQo+IFNFTkQgY2FsbHMgYW5kIGFueSBub3Rpb24gVENQIG1p Z2h0IGhhdmUgb2YgYm91bmRhcmllcyAtIFRDUCBwcmVzZW50cyBhDQo+IGJ5dGVzdHJlYW0gc2Vy dmljZSBvbmx5LiBUaGVyZSB3b3VsZCBiZSBtYW55IGNvbnNlcXVlbmNlcyB0byBjaGFuZ2luZw0K PiB0aGF0IEFQSSwgYnV0IGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBub3RlIHRoYXQgdGhpcyB3YXMg b25jZSBjb25zaWRlcmVkLg0KPiBKdXN0IHR3byBkYXlzIGFnbywgQm9iIEJyYWRlbiBhbmQgSSB3 ZXJlIGRpc2N1c3NpbmcgVENQIHYzIChiZWZvcmUgdGhlDQo+IGN1cnJlbnQgb25lICAtIGFzIGRv Y3VtZW50ZWQgaW4gSUVOICAyMSksIHdoaWNoIGRpZCBoYXZlIHRoaXMgc29ydCBvZg0KPiBzaWdu YWwsIGJ1dCBpdCB3YXMgY2FycmllZCBpbnRvIHRoZSBwYWNrZXQgYXMgYmVnaW4vZW5kIChvZiAi bGV0dGVyIikgZmxhZ3MuDQo+IA0KPiBOb3RlIHRoYXQgaGlzIGJlaGF2aW9yIGlzIGEgY29uc2Vx dWVuY2Ugb2YgdGhlIGludGVyYWN0aW9uIGJldHdlZW4NCj4gZGVsYXllZCBBQ0tzIGFuZCBhIGxh Y2sgb2YgYXBwbGljYXRpb24gZGF0YSwgYW5kIGhhcHBlbnMgYW55IHRpbWUgdGhlDQo+IGFwcCBs YXllciAic3RhcnZlcyIgVENQLiBJdCB3YXMgd2VsbCBzdHVkaWVkIGluIHRoZSA5MCdzIGluIGl0 cw0KPiBpbnRlcmFjdGlvbiB3aXRoIHBlcnNpc3RlbnQgd2ViIGNvbm5lY3Rpb25zLiBJdCBpc24n dCByZWFsbHkgcmVsYXRlZCB0bw0KPiBSVE8gcGVyIHNlLg0KPiANCj4gSm9lDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0Y3BtIG1haWxp bmcgbGlzdA0KPiB0Y3BtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGNwbQ0K From nobody Thu Dec 15 15:17:25 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D0F129F1C for ; Thu, 15 Dec 2016 15:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=palermo.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWBvdAqjV0ll for ; Thu, 15 Dec 2016 15:17:22 -0800 (PST) Received: from maxwell.palermo.edu (maxwell.palermo.edu [200.69.213.7]) by ietfa.amsl.com (Postfix) with ESMTP id 99C85129F61 for ; Thu, 15 Dec 2016 15:13:11 -0800 (PST) X-Authorization-Id: how= who= DKIM-Filter: OpenDKIM Filter v2.8.4 maxwell.palermo.edu uBFNC9Fq005805 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=palermo.edu; s=default; t=1481843530; bh=df7BpHbTNF1ef2VWFEEnlXNZihZ+83MdEx+s1YOf2CM=; h=To:References:From:Date:In-Reply-To:Subject; b=EUxICJeYZc+B3OIsAcL3LHql3Z0POXm7trlWX4hf1NH9Fdnqlo3Oo0wi/AsgPgcqL RhP2AQIAI9SofEWJnTtO2Oau0JXfHvuYGUoBCFfRHlIxN7xPGtAQVMSE8YJHjeV9zv T3/TakpGArO7we1qAH0tL+lkWuTys4MeCp1qcdK0= Received: from maxwell.palermo.edu (localhost [127.0.0.1]) by maxwell.palermo.edu (8.14.4/8.14.4) with ESMTP id uBFNC9Fq005805; Thu, 15 Dec 2016 20:12:09 -0300 Received: from [10.10.30.100] ( [10.10.30.100]) by maxwell.palermo.edu with ESMTP id VOH3T03W.1363173.0 To: Joe Touch , tcpm@ietf.org References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> <45f0034f-70a2-2aa3-d87b-c7288a51ad77@isi.edu> From: Alejandro Popovsky Message-ID: <48aa99d0-113e-edda-94f7-48d81bea59fd@palermo.edu> Date: Thu, 15 Dec 2016 20:13:08 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <45f0034f-70a2-2aa3-d87b-c7288a51ad77@isi.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Host: 10.10.30.100 Archived-At: Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh?= =?utf-8?q?bout_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Dec 2016 23:17:24 -0000 On the second option (no more data to send) there would be no need to change the API. The tcp sender tcp would generate the signal automatically with the last segment. And the receiver could just use the info to adjust the delay ack timer for that segment. And in order for the extra ack not to produce an extra cwnd growth the sender should follow the recommendation of rfc5681, page 6. Alejandro. On 15/12/2016 12:29 p. m., Joe Touch wrote: > > On 12/15/2016 3:25 AM, Alejandro Popovsky wrote: >> Tcp would benefit much from and 'end of app write call' signal or may >> be 'end of sender buffer data' signal. > In the current TCP API, there is absolutely no correlation between app > SEND calls and any notion TCP might have of boundaries - TCP presents a > bytestream service only. There would be many consequences to changing > that API, but it might be useful to note that this was once considered. > Just two days ago, Bob Braden and I were discussing TCP v3 (before the > current one - as documented in IEN 21), which did have this sort of > signal, but it was carried into the packet as begin/end (of "letter") flags. > > Note that his behavior is a consequence of the interaction between > delayed ACKs and a lack of application data, and happens any time the > app layer "starves" TCP. It was well studied in the 90's in its > interaction with persistent web connections. It isn't really related to > RTO per se. > > Joe > From nobody Thu Dec 15 16:24:36 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A7D129AC3 for ; Thu, 15 Dec 2016 16:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84O47qMVP7eO for ; Thu, 15 Dec 2016 16:24:33 -0800 (PST) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id AF73E129BB7 for ; Thu, 15 Dec 2016 16:24:33 -0800 (PST) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 3AB161770C; Thu, 15 Dec 2016 16:24:33 -0800 (PST) Date: Thu, 15 Dec 2016 16:24:33 -0800 From: hiren panchasara To: Mark Allman Message-ID: <20161216002433.GH82166@strugglingcoder.info> References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> <29664.1481813543@lawyers.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NzX0AQGjRQPusK/O" Content-Disposition: inline In-Reply-To: <29664.1481813543@lawyers.icir.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] ??: ??: ??: A question about Delayed ACK and RTO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 00:24:35 -0000 --NzX0AQGjRQPusK/O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/15/16 at 09:52P, Mark Allman wrote: >=20 > I agree with Gorry's take on variable path characteristics and all.=20 >=20 > > The TCP RTO has two distinct functions: > >=20 > > (1) the RTO is of course the method of last resort for the recovery > > of a lost segment (the final segment of a burst, following > > persistent loss, etc). > >=20 > > (2) Second the RTO is method to detect a path failure - where > > something has changed significantly. >=20 > I think this is an accident. And, the way we should handle it is to > not conflate such disparate functions into one mechanism. >=20 > The RTO is a ***retransmission*** timeout. It's original function > was to decide when to trigger resending data that has not been ACKed > because after this time period chances are the packet was lost > (i.e., case (1)). >=20 > Independently we do need to understand path failure. And, part of > detecting path failure may well be detecting that packets are not > being delivered. However, this is a different issue than figuring > out when to resend a segment. The fact that we use the RTO for this > function boils down to laziness in re-using something that was > laying around instead of doing it right. >=20 > By trying to shoehorn both functions into one mechanism we are > ***guaranteeing*** that the mechanism will be lousy (for at least > one of the tasks and probably both!). This thread perfectly > illustrates this... If we were to use the RTO for both functions > then it would be impossible to reconcile Gorry's notion that path > failure happens on long timescales and so RTOs on the order of a > second are needed with Neal's world where he wants to trigger > retransmissions three orders of magnitude sooner. Path failure may > *leverage* loss detection, but it needn't be the exact same such > that it *hampers* loss detection. Interesting. How can these 2 be differentiated? Has that been discussed/researched in IETF or elsewhere? OR can tcp borrow such a scheme from somewhere else? Cheers, Hiren --NzX0AQGjRQPusK/O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJYUzQ+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lwtAH/0UGFyRuX+qgA3gI4/JyxZma P0sXJi5VCvLMLJGsRGysguQR6rsoXAnouJh/8Cqow/GdmI1X2lDBVwWGb9S/vEHD N5f+UtaNCCI0tHJJyVEIh3pXK14Dekp3X5yZs+gQh2xW6cx/xFg6kOi2DWQZbq2I 6GFV7dVUTa1/CHw+NbCdnI9bKdVD4WTlZG8hip0rBpOAFa1YzNG4kuG47G5/Trh4 hFXixBEuMz/EJaWvZJx8Ks2N2OPm4RJCR2BZmSXDkiPgXXns8Cj43hx/9MmhwdBC 8Fyc8qG3XROsBWes3tWSyZrohVMH+kL93Xx9dmhRTkhhYYVdTtG8hSeLWym78qs= =csKj -----END PGP SIGNATURE----- --NzX0AQGjRQPusK/O-- From nobody Thu Dec 15 16:48:54 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD01A129BF1 for ; Thu, 15 Dec 2016 16:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0frGniRjb9H for ; Thu, 15 Dec 2016 16:48:51 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B3A129BF0 for ; Thu, 15 Dec 2016 16:48:51 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id uBG0m9NG025218; Thu, 15 Dec 2016 16:48:09 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AEF9369B9775; Thu, 15 Dec 2016 19:48:09 -0500 (EST) To: hiren panchasara From: Mark Allman In-Reply-To: <20161216002433.GH82166@strugglingcoder.info> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: I'm No Angel X-URL-0: http://www.icir.org/mallman-files/Document7721.docx X-URL-1: http://www.icir.org/mallman-files/Document41709.xls X-URL-2: http://www.icir.org/mallman-files/Document15610.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 15 Dec 2016 19:48:09 -0500 Message-ID: <99636.1481849289@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] ??: ??: ??: A question about Delayed ACK and RTO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 00:48:53 -0000 --=-------459435943823349593450 Content-Type: text/plain > How can these 2 be differentiated? Easy. Retransmissions are triggered by the scheme outlined in RFC 6298. Path failure is defined as not getting any packets through in 10sec. There. Differentiated. I am not suggesting that is smart. Or, the best way. But, making these two things triggered by their own criteria that is tuned to the each specific task is trivial. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlhTOccACgkQWyrrWs4yIs7d1wCfRyBmQEIXXdrjBXsiFQkXLmN9 oi0AnjhlEu2bMl5wTJ3KSjo3t4Ur1DZF =L8mz -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Thu Dec 15 17:13:43 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCACE129C08 for ; Thu, 15 Dec 2016 17:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.012 X-Spam-Level: X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZTqppVop9Dq for ; Thu, 15 Dec 2016 17:13:39 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0122.outbound.protection.outlook.com [104.47.37.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C381129BA7 for ; Thu, 15 Dec 2016 17:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V1mfrGAjQOe2f7NpfxsDgk/oCHcyLxzXBirjNoCnV3I=; b=P5hN7Vz/xq9ylvpJaSa3c3KaXaFUaVE/GxpAMisxf48nXC8qrvq65iWvQXMNzvfX7A1M94vU26ySXRft/8DopniJGtmbCVO14Z43LiGD7mGfGEdI7+1t+nxgbAuctXHKeTNR/cz96qe5APAWxG/G2AiaMBxP+6clZIk0QeE/+Eo= Received: from BN1PR03MB008.namprd03.prod.outlook.com (10.255.224.38) by BN1PR03MB005.namprd03.prod.outlook.com (10.255.224.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Fri, 16 Dec 2016 01:13:37 +0000 Received: from BN1PR03MB008.namprd03.prod.outlook.com ([169.254.16.17]) by BN1PR03MB008.namprd03.prod.outlook.com ([169.254.16.17]) with mapi id 15.01.0761.015; Fri, 16 Dec 2016 01:13:36 +0000 From: Praveen Balasubramanian To: Alejandro Popovsky , Joe Touch , "tcpm@ietf.org" Thread-Topic: =?big5?B?W3RjcG1dILWqzmA6ILWqzmA6ILWqzmA6IEEgcXVlc3Rpb24gYWJvdXQgRGVsYXll?= =?big5?Q?d_ACK_and_RTO?= Thread-Index: AQHSVqyuBMG/SVY0gE2sKu38YsaiuaEIzH4AgAAR/YCAAEREgIAAgX8AgAAeiVA= Date: Fri, 16 Dec 2016 01:13:36 +0000 Message-ID: References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> <45f0034f-70a2-2aa3-d87b-c7288a51ad77@isi.edu> <48aa99d0-113e-edda-94f7-48d81bea59fd@palermo.edu> In-Reply-To: <48aa99d0-113e-edda-94f7-48d81bea59fd@palermo.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:2::668] x-ms-office365-filtering-correlation-id: 08f8b9cf-9562-46c1-25a4-08d42550c342 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN1PR03MB005; x-microsoft-exchange-diagnostics: 1; BN1PR03MB005; 7:oi5AUrYZQctJwrhYSTwElsAvihR8T/Q5OmtAQVgprYyPbHfcoW54tdyuW3tO2I1/hO+5Dp55qoMpwX96E959/HD2LtxGCbP7pyXsS4qhVQ9ZUAtY1YpIT7MX04Kr7qs/zMLh9jXqsvSNYXd2k2UIcqoduGZ+g7T7VEYZiGWIy/cwPStkMrOX63LHCzmVK4vFuVdCBcbAA2M4CGngqlHVPxUPXzs9PFgqC3bC2jzrPLwFhEvIJaFMYeQoerBXVJlIcuY3hc6xCoDr2oPAFpH45shIoqRfHXqIpJL4vMHXx2y6Uo/z0lE8VklC5TYicRQHv90+s3gg5A/gW0lOgipLUFOSXQPic0oJdqe/7xucc/768BovCANhP0IsCNCUY4sfxjDBPQrpFr8qEBDlJGofpssJ/lj+X0gCI5Xr7qsqDaYqJu/rNFvzIo3MMRS79QIwxzAOxUz+N/riTxZ5GXnM6QpIHe0YQQrc00hD8d75xmw= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(6047074); SRVR:BN1PR03MB005; BCL:0; PCL:0; RULEID:; SRVR:BN1PR03MB005; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39410400002)(39450400003)(39840400002)(199003)(13464003)(377454003)(24454002)(189002)(5005710100001)(7696004)(5001770100001)(97736004)(9686002)(76176999)(50986999)(5660300001)(10290500002)(54356999)(3660700001)(189998001)(101416001)(76576001)(68736007)(107886002)(7736002)(6506006)(93886004)(74316002)(10090500001)(8990500004)(2950100002)(6436002)(33656002)(305945005)(229853002)(25786008)(2906002)(3280700002)(105586002)(86362001)(2900100001)(224303003)(99286002)(2501003)(2171001)(92566002)(106116001)(86612001)(38730400001)(8936002)(106356001)(6116002)(102836003)(81156014)(81166006)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB005; H:BN1PR03MB008.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2016 01:13:36.8216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB005 Archived-At: Subject: Re: [tcpm] =?big5?b?tarOYDogtarOYDogtarOYDogQSBxdWVzdGlvbiBhYm91dCBE?= =?big5?b?ZWxheWVkIEFDSyBhbmQgUlRP?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 01:13:42 -0000 RldJVyB0aGUgd2luZG93cyBUQ1AgaW1wbGVtZW50YXRpb24gcHJlc2VydmVzIHRoZSBub3Rpb24g b2YgYXBwbGljYXRpb24gc2VuZCgpIG1lc3NhZ2UgYm91bmRhcnkgYnkgc2V0dGluZyB0aGUgUFNI IGJpdCBvbmx5IG9uIHRoZSBsYXN0IHNlZ21lbnQgZ2VuZXJhdGVkIGZyb20gdGhlIHBvc3RlZCBi dWZmZXIuIFVuZm9ydHVuYXRlbHkgb3RoZXIgc3RhY2tzIHNlZW0gdG8gc2V0IFBTSCBvbiBhbGwg c2VnbWVudHMgbWFraW5nIGFueSByZWNlaXZlciBvcHRpbWl6YXRpb24gb2YgaW1tZWRpYXRlIEFD SyBvbiBQU0ggaW1wb3NzaWJsZSwgYmVjYXVzZSB0aGF0IHdvdWxkIGVmZmVjdGl2ZWx5IHR1cm4g b2ZmIGRlbGF5ZWQgQUNLcy4gVGhhdCBzYWlkLCB3aXRoIEFDSyBzdHJldGNoaW5nLCBMUk8gZXRj LiBiZWluZyB2ZXJ5IGNvbW1vbiBtYXliZSBpdCBpcyB0aW1lIGZvciBUQ1AgaW1wbGVtZW50YXRp b25zIHRvIHR1cm4gb2ZmIGRlbGF5ZWQgQUNLcyBhY3Jvc3MgdGhlIGJvYXJkIGV4Y2VwdCBmb3Ig cmVxdWVzdC1yZXNwb25zZSBhcHBsaWNhdGlvbnMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQWxlamFuZHJvIFBvcG92c2t5DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMTUsIDIwMTYg MzoxMyBQTQ0KVG86IEpvZSBUb3VjaCA8dG91Y2hAaXNpLmVkdT47IHRjcG1AaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbdGNwbV0gtarOYDogtarOYDogtarOYDogQSBxdWVzdGlvbiBhYm91dCBEZWxh eWVkIEFDSyBhbmQgUlRPDQoNCk9uIHRoZSBzZWNvbmQgb3B0aW9uIChubyBtb3JlIGRhdGEgdG8g c2VuZCkgdGhlcmUgd291bGQgYmUgbm8gbmVlZCB0byBjaGFuZ2UgdGhlIEFQSS4gVGhlIHRjcCBz ZW5kZXIgdGNwIHdvdWxkIGdlbmVyYXRlIHRoZSBzaWduYWwgYXV0b21hdGljYWxseSB3aXRoIHRo ZSBsYXN0IHNlZ21lbnQuIEFuZCB0aGUgcmVjZWl2ZXIgY291bGQganVzdCB1c2UgdGhlIGluZm8g dG8gYWRqdXN0IHRoZSBkZWxheSBhY2sgdGltZXIgZm9yIHRoYXQgc2VnbWVudC4NCg0KQW5kIGlu IG9yZGVyIGZvciB0aGUgZXh0cmEgYWNrIG5vdCB0byBwcm9kdWNlIGFuIGV4dHJhIGN3bmQgZ3Jv d3RoIHRoZSBzZW5kZXIgc2hvdWxkIGZvbGxvdyB0aGUgcmVjb21tZW5kYXRpb24gb2YgcmZjNTY4 MSwgcGFnZSA2Lg0KDQpBbGVqYW5kcm8uDQoNCk9uIDE1LzEyLzIwMTYgMTI6MjkgcC4gbS4sIEpv ZSBUb3VjaCB3cm90ZToNCj4NCj4gT24gMTIvMTUvMjAxNiAzOjI1IEFNLCBBbGVqYW5kcm8gUG9w b3Zza3kgd3JvdGU6DQo+PiBUY3Agd291bGQgYmVuZWZpdCBtdWNoIGZyb20gYW5kICdlbmQgb2Yg YXBwIHdyaXRlIGNhbGwnIHNpZ25hbCBvciBtYXkgDQo+PiBiZSAnZW5kIG9mIHNlbmRlciBidWZm ZXIgZGF0YScgc2lnbmFsLg0KPiAgIEluIHRoZSBjdXJyZW50IFRDUCBBUEksIHRoZXJlIGlzIGFi c29sdXRlbHkgbm8gY29ycmVsYXRpb24gYmV0d2VlbiANCj4gYXBwIFNFTkQgY2FsbHMgYW5kIGFu eSBub3Rpb24gVENQIG1pZ2h0IGhhdmUgb2YgYm91bmRhcmllcyAtIFRDUCANCj4gcHJlc2VudHMg YSBieXRlc3RyZWFtIHNlcnZpY2Ugb25seS4gVGhlcmUgd291bGQgYmUgbWFueSBjb25zZXF1ZW5j ZXMgDQo+IHRvIGNoYW5naW5nIHRoYXQgQVBJLCBidXQgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIG5v dGUgdGhhdCB0aGlzIHdhcyBvbmNlIGNvbnNpZGVyZWQuDQo+IEp1c3QgdHdvIGRheXMgYWdvLCBC b2IgQnJhZGVuIGFuZCBJIHdlcmUgZGlzY3Vzc2luZyBUQ1AgdjMgKGJlZm9yZSB0aGUgDQo+IGN1 cnJlbnQgb25lICAtIGFzIGRvY3VtZW50ZWQgaW4gSUVOICAyMSksIHdoaWNoIGRpZCBoYXZlIHRo aXMgc29ydCBvZiANCj4gc2lnbmFsLCBidXQgaXQgd2FzIGNhcnJpZWQgaW50byB0aGUgcGFja2V0 IGFzIGJlZ2luL2VuZCAob2YgImxldHRlciIpIGZsYWdzLg0KPg0KPiBOb3RlIHRoYXQgaGlzIGJl aGF2aW9yIGlzIGEgY29uc2VxdWVuY2Ugb2YgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gDQo+IGRl bGF5ZWQgQUNLcyBhbmQgYSBsYWNrIG9mIGFwcGxpY2F0aW9uIGRhdGEsIGFuZCBoYXBwZW5zIGFu eSB0aW1lIHRoZSANCj4gYXBwIGxheWVyICJzdGFydmVzIiBUQ1AuIEl0IHdhcyB3ZWxsIHN0dWRp ZWQgaW4gdGhlIDkwJ3MgaW4gaXRzIA0KPiBpbnRlcmFjdGlvbiB3aXRoIHBlcnNpc3RlbnQgd2Vi IGNvbm5lY3Rpb25zLiBJdCBpc24ndCByZWFsbHkgcmVsYXRlZCANCj4gdG8gUlRPIHBlciBzZS4N Cj4NCj4gSm9lDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp0Y3BtIG1haWxpbmcgbGlzdA0KdGNwbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo= From nobody Thu Dec 15 17:21:13 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59225129ACB for ; Thu, 15 Dec 2016 17:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aia0U_OgrXeH for ; Thu, 15 Dec 2016 17:21:10 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0103.outbound.protection.outlook.com [104.47.32.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9B3129513 for ; Thu, 15 Dec 2016 17:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lVYYIRd0yqYLKt/febjtuOLlsWA9EDujgm4VOq3r9pI=; b=lYXf/oTnQ+SHQW4erMkhEOUp4nMzRRoOQo41yx067tvYcPzae39LSzyC/IKBOBNFdD6XcV0RS7f/RSDMyU1T3ZOpMrldJrTmNs5P16xpBStf4hjkvynJke8KkAyVbWJAwhriPcTSJtG1f6pKcQBwi/mEOCt0sgaVDZ+eJYW3DjU= Received: from BN1PR03MB008.namprd03.prod.outlook.com (10.255.224.38) by BN1PR03MB008.namprd03.prod.outlook.com (10.255.224.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Fri, 16 Dec 2016 01:21:06 +0000 Received: from BN1PR03MB008.namprd03.prod.outlook.com ([169.254.16.17]) by BN1PR03MB008.namprd03.prod.outlook.com ([169.254.16.17]) with mapi id 15.01.0761.015; Fri, 16 Dec 2016 01:21:06 +0000 From: Praveen Balasubramanian To: "zhangyali (D)" , Joe Touch , "Neal Cardwell" , "Jakob Heitz (jheitz)" Thread-Topic: =?utf-8?B?W3RjcG1dIOetlOWkjTogIOetlOWkjTogQSBxdWVzdGlvbiBhYm91dCBEZWxh?= =?utf-8?Q?yed_ACK_and_RTO?= Thread-Index: AQHSVndPRXfkBxIR+0uexKisuekRA6EJx+KA Date: Fri, 16 Dec 2016 01:21:06 +0000 Message-ID: References: <37069250-13c5-7692-f137-0f441d57a90c@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:2::668] x-ms-office365-filtering-correlation-id: 977336c5-007e-422c-7064-08d42551cf6b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN1PR03MB008; x-microsoft-exchange-diagnostics: 1; BN1PR03MB008; 7:dz4+lW1BEsuE736SJCQMBiqkwiA1maOcXciTW4bderck8sgteSdnHnAaZyKLauR+LGSyPyrYv/ity+XAAxWHYg8ukK8ED/h5Cq9fcNB0FTD6ZvJPA97J6WIXRjn/dgm7Hk69DtQ4P7RIs/NG1uOMJ7kob1VUfJnhB5cMfCyxI2Zwun6f6A2jljMcWX10h8CZkP8hqbJ1xw64GC7xvMlHfVhQxH7Txg6QDAxi/oXH+qzb4DXAFTIGhOVtUnpZXcRwQYBE4ZspW7gbrKaUXfmNPHdabf6C/9y32LzZIKsnlUQpG+2mW5FOPBhdOUR0+wdrbBHdSPauu6XGmr8H2N0Q/otIQ0/mDnVkqbjGGQ4jSyBTK2Lwii7mWgKwS/lEk9wOU/sfVMZ0NlQKNCk4bRjzOQHNtEljZtP86DXobz4GFOAuMuW56Tv62EvIYK2TrBAbmYJ2pRa1eozb356iHfj22wyTGFR7VfHZgJ5xZd/pLLQ= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6042181)(6072148)(6047074); SRVR:BN1PR03MB008; BCL:0; PCL:0; RULEID:; SRVR:BN1PR03MB008; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(24454002)(33656002)(76576001)(86612001)(5660300001)(224303003)(10090500001)(6436002)(3280700002)(2900100001)(229853002)(8990500004)(86362001)(6506006)(6116002)(97736004)(4326007)(122556002)(7736002)(74316002)(38730400001)(92566002)(2906002)(3660700001)(102836003)(9686002)(50986999)(189998001)(7696004)(81156014)(106356001)(8936002)(5001770100001)(81166006)(105586002)(99286002)(2171001)(54356999)(93886004)(101416001)(5005710100001)(790700001)(2950100002)(76176999)(10290500002)(106116001)(25786008)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB008; H:BN1PR03MB008.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN1PR03MB0080450F8ED7E868BC5466AB69C0BN1PR03MB008namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2016 01:21:06.6016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB008 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiAg562U5aSNOiBBIHF1ZXN0aW9uIGFib3V0IERl?= =?utf-8?q?layed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 01:21:12 -0000 --_000_BN1PR03MB0080450F8ED7E868BC5466AB69C0BN1PR03MB008namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hpbGUgb3BlcmF0b3JzIGNvdWxkIHR3ZWFrIHRoZSBzZXR0aW5ncywgaGF2aW5nIFRDUCBwZXJm b3JtIHdlbGwgb3V0IG9mIGJveCBpbiBsb3cgbGF0ZW5jeSBlbnZpcm9ubWVudHMgaXMgdmVyeSB1 c2VmdWwuIEZvciBsb3cgbGF0ZW5jeSBjb25uZWN0aW9ucyBXaW5kb3dzIFNlcnZlciBoYXMgc2hp cHBlZCB3aXRoIGEgMjAgbXNlYyBtaW4gUlRPIGFuZCAxMCBtc2VjIGRlbGF5ZWQgQUNLIHRpbWVv dXQgZm9yIHNldmVyYWwgeWVhcnMgbm93LiBCdXQgdGhpcyBtZXRob2QgcmVsaWVzIG9uIGEgaGV1 cmlzdGljIHRvIHVzZSB0aGUgU1lOIGhhbmRzaGFrZSBSVFQgdG8gZGV0ZWN0IGxvdyBsYXRlbmN5 IGNvbm5lY3Rpb25zIGFuZCBwaWNrIHRoZSBtb3JlIGFnZ3Jlc3NpdmUgdGltZW91dHMgd2hpY2gg aXMgbGVzcyB0aGFuIGlkZWFsLiBBbiBleHBsaWNpdCBuZWdvdGlhdGlvbiBvZiB0aGUgdGltZW91 dCB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bCBiZWNhdXNlIGl0IHJlbW92ZXMgYW55IGNoYW5jZXMgb2Yg bWlzbWF0Y2ggYW5kIGhlbHBzIGRpZmZlcmVudCBPUyBUQ1Agc3RhY2tzIGludGVyb3AuDQoNCkZy b206IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB6aGFu Z3lhbGkgKEQpDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE0LCAyMDE2IDY6MDIgUE0NClRv OiBKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU+OyBOZWFsIENhcmR3ZWxsIDxuY2FyZHdlbGxAZ29v Z2xlLmNvbT47IEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPg0KQ2M6IHRj cG1AaWV0Zi5vcmcNClN1YmplY3Q6IFt0Y3BtXSDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh Ym91dCBEZWxheWVkIEFDSyBhbmQgUlRPDQoNCkhpIEpvZSwNCg0KSSByZWFsbHkgYWdyZWUgd2l0 aCB5b3UgYWJvdXQgVENQIG1lY2hhbmlzbSBzaG91bGQgZ2VuZXJhbCBmb3IgYWxsIGFyZWFzLCBp bmNsdWRpbmcgd2FuIGFuZCBkYXRhIGNlbnRlci4NCg0KQnV0IGV2ZXJ5IHNjZW5hcmlvcyBoYXZl IHRoZWlyIG93biBjaGFyYWN0ZXJpc3RpY3MuIERhdGEgY2VudGVyIGhhcyBzb21lIGRpc3RpbmN0 aXZlIGZlYXR1cmVzLCBzdWNoIGFzLCB1bHRyYWxvdyBSVFQsIGJlY2F1c2Ugb2YgY2VudHJhbGl6 ZWQgbG9jYXRpb24sIGxlc3MgaG9wcywgYW5kIHNvIG9uLiBUaGVzZSBmZWF0dXJlcyBkZXRlcm1p bmVzIGRpZmZlcmVudCByZXF1aXJlbWVudCBmb3IgVENQIGRlZmF1bHQgY29uZmlndXJhdGlvbiwg Y29tcGFyZWQgd2l0aCB3YW4gc2NlbmFyaW8uIEl0IGlzIGEgc29sdXRpb24gYnkgaGF2aW5nIHRo ZSBhaWRzIG9mIG9wZXJhdG9yLCBidXQgbWF5YmUgd2UgY291bGQgaGF2ZSBhIG1vcmUgYXV0b21h dGljIGFuZCBnZW5lcmFsIG1lY2hhbmlzbSB0byBzb2x2ZSBkaXNjcmVwYW5jeS4gSnVzdCBhIHNp bXBsZSBpZGVhLiDimLoNCg0KQmVzdCBSZWdhcmRzLA0KWWFsaQ0KDQrlj5Hku7bkuro6IHRjcG0g W21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBKb2UgVG91Y2gNCuWPkemAgeaX tumXtDogMjAxNuW5tDEy5pyIMTXml6UgMzoyMA0K5pS25Lu25Lq6OiBOZWFsIENhcmR3ZWxsIDxu Y2FyZHdlbGxAZ29vZ2xlLmNvbTxtYWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb20+PjsgSmFrb2Ig SGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+ Pg0K5oqE6YCBOiB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0K5Li76aKYOiBS ZTogW3RjcG1dIOetlOWkjTogQSBxdWVzdGlvbiBhYm91dCBEZWxheWVkIEFDSyBhbmQgUlRPDQoN Cg0KV2Ugc2hvdWxkIG5vdCBiZSBvcHRpbWl6aW5nIFRDUCBmb3Igc3BlY2lmaWMgZW52aXJvbm1l bnRzOyB0aGF0J3MgZm9yIG9wZXJhdG9ycyB0byBvdmVycmlkZS4NCg0KSm9lDQoNCk9uIDEyLzE0 LzIwMTYgOTowNCBBTSwgTmVhbCBDYXJkd2VsbCB3cm90ZToNCk9uIFdlZCwgRGVjIDE0LCAyMDE2 IGF0IDExOjU2IEFNLCBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbTxtYWls dG86amhlaXR6QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGlzdG9yaWNhbGx5LCB0aGUgbWluaW11bSBS VE8gaXMgMSBzZWNvbmQgYW5kIGFjdHVhbCBSVFQgaXMgdmVyeSByYXJlbHkgbW9yZSB0aGFuIDEg c2Vjb25kLCBzbyBhbGwgdGhpcyBSVFQgY2FsY3VsYXRpb24gaGFyZGx5IGV2ZXIgbWF0dGVycyBh bnl3YXkuDQoNClRoYXQgbWF5IGJlIHRydWUgaGlzdG9yaWNhbGx5LCBidXQgZm9yIG1hbnkgeWVh cnMgbWFqb3IgVENQIGltcGxlbWVudGF0aW9ucyAoaW5jbHVkaW5nIExpbnV4IGFuZCBGcmVlQlNE KSBoYXZlIHVzZWQgYSBtaW5pbXVtIFJUTyBjbG9zZXIgdG8gMjAwbXMuIEFuZCBpbiBkYXRhY2Vu dGVyIGVudmlyb25tZW50cyBldmVuIDIwMG1zIGNhbiBiZSBpbmZlYXNpYmx5IGhpZ2guDQoNCm5l YWwNCg0KDQo= --_000_BN1PR03MB0080450F8ED7E868BC5466AB69C0BN1PR03MB008namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1pY3Jvc29m dCBZYUhlaSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBNaWNyb3NvZnQgWWFIZWkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIg MiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5v c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2lt U3VuOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjsNCgljb2xvcjpibGFjazsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv d3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldoaWxlIG9wZXJhdG9ycyBjb3VsZCB0 d2VhayB0aGUgc2V0dGluZ3MsIGhhdmluZyBUQ1AgcGVyZm9ybSB3ZWxsIG91dCBvZiBib3ggaW4g bG93IGxhdGVuY3kgZW52aXJvbm1lbnRzIGlzIHZlcnkgdXNlZnVsLiBGb3IgbG93DQogbGF0ZW5j eSBjb25uZWN0aW9ucyBXaW5kb3dzIFNlcnZlciBoYXMgc2hpcHBlZCB3aXRoIGEgMjAgbXNlYyBt aW4gUlRPIGFuZCAxMCBtc2VjIGRlbGF5ZWQgQUNLIHRpbWVvdXQgZm9yIHNldmVyYWwgeWVhcnMg bm93LiBCdXQgdGhpcyBtZXRob2QgcmVsaWVzIG9uIGEgaGV1cmlzdGljIHRvIHVzZSB0aGUgU1lO IGhhbmRzaGFrZSBSVFQgdG8gZGV0ZWN0IGxvdyBsYXRlbmN5IGNvbm5lY3Rpb25zIGFuZCBwaWNr IHRoZSBtb3JlIGFnZ3Jlc3NpdmUgdGltZW91dHMNCiB3aGljaCBpcyBsZXNzIHRoYW4gaWRlYWwu IEFuIGV4cGxpY2l0IG5lZ290aWF0aW9uIG9mIHRoZSB0aW1lb3V0IHdvdWxkIGJlIHZlcnkgdXNl ZnVsIGJlY2F1c2UgaXQgcmVtb3ZlcyBhbnkgY2hhbmNlcyBvZiBtaXNtYXRjaCBhbmQgaGVscHMg ZGlmZmVyZW50IE9TIFRDUCBzdGFja3MgaW50ZXJvcC4gJm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiB0Y3BtIFtt YWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj56aGFuZ3lh bGkgKEQpPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRGVjZW1iZXIgMTQsIDIwMTYgNjow MiBQTTxicj4NCjxiPlRvOjwvYj4gSm9lIFRvdWNoICZsdDt0b3VjaEBpc2kuZWR1Jmd0OzsgTmVh bCBDYXJkd2VsbCAmbHQ7bmNhcmR3ZWxsQGdvb2dsZS5jb20mZ3Q7OyBKYWtvYiBIZWl0eiAoamhl aXR6KSAmbHQ7amhlaXR6QGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRjcG1AaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3RjcG1dIDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+562U5aSNPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij46DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgt Q04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPuetlOWkjTwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+OiBBIHF1ZXN0aW9uIGFib3V0IERl bGF5ZWQgQUNLIGFuZCBSVE88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgSm9lLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSByZWFsbHkgYWdyZWUgd2l0aCB5b3Ug YWJvdXQgVENQIG1lY2hhbmlzbSBzaG91bGQgZ2VuZXJhbCBmb3IgYWxsIGFyZWFzLCBpbmNsdWRp bmcgd2FuIGFuZCBkYXRhIGNlbnRlci4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+QnV0IGV2ZXJ5IHNjZW5hcmlvcyBoYXZlIHRoZWlyIG93biBjaGFyYWN0ZXJp c3RpY3MuIERhdGEgY2VudGVyIGhhcyBzb21lIGRpc3RpbmN0aXZlIGZlYXR1cmVzLCBzdWNoIGFz LCB1bHRyYWxvdyBSVFQsIGJlY2F1c2Ugb2YgY2VudHJhbGl6ZWQgbG9jYXRpb24sIGxlc3MgaG9w cywNCiBhbmQgc28gb24uIFRoZXNlIGZlYXR1cmVzIGRldGVybWluZXMgZGlmZmVyZW50IHJlcXVp cmVtZW50IGZvciBUQ1AgZGVmYXVsdCBjb25maWd1cmF0aW9uLCBjb21wYXJlZCB3aXRoIHdhbiBz Y2VuYXJpby4gSXQgaXMgYSBzb2x1dGlvbiBieSBoYXZpbmcgdGhlIGFpZHMgb2Ygb3BlcmF0b3Is IGJ1dCBtYXliZSB3ZSBjb3VsZCBoYXZlIGEgbW9yZSBhdXRvbWF0aWMgYW5kIGdlbmVyYWwgbWVj aGFuaXNtIHRvIHNvbHZlIGRpc2NyZXBhbmN5LiBKdXN0DQogYSBzaW1wbGUgaWRlYS4gPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xv cjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+WWFsaQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij4NCiB0Y3BtIFs8YSBocmVmPSJtYWlsdG86dGNwbS1ib3VuY2VzQGlldGYu b3JnIj5tYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+DQo8c3BhbiBsYW5nPSJa SC1DTiI+5Luj6KGoIDwvc3Bhbj48L2I+Sm9lIFRvdWNoPGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgt Q04iPuWPkemAgeaXtumXtDwvc3Bhbj46PC9iPiAyMDE2PHNwYW4gbGFuZz0iWkgtQ04iPuW5tDwv c3Bhbj4xMjxzcGFuIGxhbmc9IlpILUNOIj7mnIg8L3NwYW4+MTU8c3BhbiBsYW5nPSJaSC1DTiI+ 5pelPC9zcGFuPiAzOjIwPGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaUtuS7tuS6ujwvc3Bh bj46PC9iPiBOZWFsIENhcmR3ZWxsICZsdDs8YSBocmVmPSJtYWlsdG86bmNhcmR3ZWxsQGdvb2ds ZS5jb20iPm5jYXJkd2VsbEBnb29nbGUuY29tPC9hPiZndDs7IEpha29iIEhlaXR6IChqaGVpdHop ICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+amhlaXR6QGNpc2NvLmNvbTwv YT4mZ3Q7PGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaKhOmAgTwvc3Bhbj46PC9iPiA8YSBo cmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj48c3Bh biBsYW5nPSJaSC1DTiI+5Li76aKYPC9zcGFuPjo8L2I+IFJlOiBbdGNwbV0gPHNwYW4gbGFuZz0i WkgtQ04iPuetlOWkjTwvc3Bhbj46IEEgcXVlc3Rpb24gYWJvdXQgRGVsYXllZCBBQ0sgYW5kIFJU TzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPldlIHNob3VsZCBub3QgYmUgb3B0aW1pemlu ZyBUQ1AgZm9yIHNwZWNpZmljIGVudmlyb25tZW50czsgdGhhdCdzIGZvciBvcGVyYXRvcnMgdG8g b3ZlcnJpZGUuPG86cD48L286cD48L3A+DQo8cD5Kb2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIDEyLzE0LzIwMTYgOTowNCBBTSwgTmVhbCBDYXJkd2VsbCB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIERlYyAxNCwg MjAxNiBhdCAxMTo1NiBBTSwgSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0OzxhIGhyZWY9Im1haWx0 bzpqaGVpdHpAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+amhlaXR6QGNpc2NvLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp c3RvcmljYWxseSwgdGhlIG1pbmltdW0gUlRPIGlzIDEgc2Vjb25kIGFuZCBhY3R1YWwgUlRUIGlz IHZlcnkgcmFyZWx5IG1vcmUgdGhhbiAxIHNlY29uZCwgc28gYWxsIHRoaXMgUlRUIGNhbGN1bGF0 aW9uIGhhcmRseSBldmVyIG1hdHRlcnMgYW55d2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBtYXkgYmUg dHJ1ZSBoaXN0b3JpY2FsbHksIGJ1dCBmb3IgbWFueSB5ZWFycyBtYWpvciBUQ1AgaW1wbGVtZW50 YXRpb25zIChpbmNsdWRpbmcgTGludXggYW5kIEZyZWVCU0QpIGhhdmUgdXNlZCBhIG1pbmltdW0g UlRPIGNsb3NlciB0byAyMDBtcy4gQW5kIGluIGRhdGFjZW50ZXIgZW52aXJvbm1lbnRzIGV2ZW4g MjAwbXMgY2FuIGJlIGluZmVhc2libHkgaGlnaC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+bmVhbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN1PR03MB0080450F8ED7E868BC5466AB69C0BN1PR03MB008namprd_-- From nobody Thu Dec 15 17:51:27 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6EC129C34 for ; Thu, 15 Dec 2016 17:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv3eFTyXhKgU for ; Thu, 15 Dec 2016 17:51:25 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344B6126FDC for ; Thu, 15 Dec 2016 17:51:25 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBG1p0pM023781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 15 Dec 2016 17:51:01 -0800 (PST) To: Alejandro Popovsky , tcpm@ietf.org References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> <45f0034f-70a2-2aa3-d87b-c7288a51ad77@isi.edu> <48aa99d0-113e-edda-94f7-48d81bea59fd@palermo.edu> From: Joe Touch Message-ID: <24b9423a-f34c-14f1-d142-3b3de3e56fb4@isi.edu> Date: Thu, 15 Dec 2016 17:50:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <48aa99d0-113e-edda-94f7-48d81bea59fd@palermo.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh?= =?utf-8?q?bout_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 01:51:26 -0000 On 12/15/2016 3:13 PM, Alejandro Popovsky wrote: > On the second option (no more data to send) there would be no need to > change the API. The tcp sender tcp would generate the signal > automatically > with the last segment. And the receiver could just use the info to > adjust the delay > ack timer for that segment. The two problems: - the sending app can't signal "last segment" of a data chunk to TCP. All it can say is "close", after which it can't send data anymore. - the sending-side TCP can't signal "last segment" to the receiver either. The only flag there is FIN, which similarly inhibits later data on the connection in that direction. Joe > > And in order for the extra ack not to produce an extra cwnd growth > the sender should follow the recommendation of rfc5681, page 6. > > Alejandro. > > On 15/12/2016 12:29 p. m., Joe Touch wrote: >> >> On 12/15/2016 3:25 AM, Alejandro Popovsky wrote: >>> Tcp would benefit much from and 'end of app write call' signal or may >>> be 'end of sender buffer data' signal. >> In the current TCP API, there is absolutely no correlation between app >> SEND calls and any notion TCP might have of boundaries - TCP presents a >> bytestream service only. There would be many consequences to changing >> that API, but it might be useful to note that this was once considered. >> Just two days ago, Bob Braden and I were discussing TCP v3 (before the >> current one - as documented in IEN 21), which did have this sort of >> signal, but it was carried into the packet as begin/end (of "letter") >> flags. >> >> Note that his behavior is a consequence of the interaction between >> delayed ACKs and a lack of application data, and happens any time the >> app layer "starves" TCP. It was well studied in the 90's in its >> interaction with persistent web connections. It isn't really related to >> RTO per se. >> >> Joe >> From nobody Thu Dec 15 18:00:26 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA32129C49 for ; Thu, 15 Dec 2016 18:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-NtYtWenln5 for ; Thu, 15 Dec 2016 18:00:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8D7129C50 for ; Thu, 15 Dec 2016 18:00:22 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBG1xcSb024667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 15 Dec 2016 17:59:39 -0800 (PST) To: Praveen Balasubramanian , Alejandro Popovsky , "tcpm@ietf.org" References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> <45f0034f-70a2-2aa3-d87b-c7288a51ad77@isi.edu> <48aa99d0-113e-edda-94f7-48d81bea59fd@palermo.edu> From: Joe Touch Message-ID: Date: Thu, 15 Dec 2016 17:59:36 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh?= =?utf-8?q?bout_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 02:00:24 -0000 On 12/15/2016 5:13 PM, Praveen Balasubramanian wrote: > FWIW the windows TCP implementation preserves the notion of application send() message boundary by setting the PSH bit only on the last segment generated from the posted buffer. TCP isn't required to allow the app to decide when to set the PSH bit (it's a MAY in the SEND call). It can coalesce multiple PSH bits to send a larger segment. However, it's also explicitly not a record boundary. PUSH is really just to avoid deadlock between the app and TCP on the send side. > Unfortunately other stacks seem to set PSH on all segments making any receiver optimization of immediate ACK on PSH impossible, because that would effectively turn off delayed ACKs. That said, with ACK stretching, LRO etc. being very common maybe it is time for TCP implementations to turn off delayed ACKs across the board except for request-response applications. There are many ways this could be fixed but they all require going outside the current spec. Joe > > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Alejandro Popovsky > Sent: Thursday, December 15, 2016 3:13 PM > To: Joe Touch ; tcpm@ietf.org > Subject: Re: [tcpm] µŞÎ`: µŞÎ`: µŞÎ`: A question about Delayed ACK and RTO > > On the second option (no more data to send) there would be no need to change the API. The tcp sender tcp would generate the signal automatically with the last segment. And the receiver could just use the info to adjust the delay ack timer for that segment. > > And in order for the extra ack not to produce an extra cwnd growth the sender should follow the recommendation of rfc5681, page 6. > > Alejandro. > > On 15/12/2016 12:29 p. m., Joe Touch wrote: >> On 12/15/2016 3:25 AM, Alejandro Popovsky wrote: >>> Tcp would benefit much from and 'end of app write call' signal or may >>> be 'end of sender buffer data' signal. >> In the current TCP API, there is absolutely no correlation between >> app SEND calls and any notion TCP might have of boundaries - TCP >> presents a bytestream service only. There would be many consequences >> to changing that API, but it might be useful to note that this was once considered. >> Just two days ago, Bob Braden and I were discussing TCP v3 (before the >> current one - as documented in IEN 21), which did have this sort of >> signal, but it was carried into the packet as begin/end (of "letter") flags. >> >> Note that his behavior is a consequence of the interaction between >> delayed ACKs and a lack of application data, and happens any time the >> app layer "starves" TCP. It was well studied in the 90's in its >> interaction with persistent web connections. It isn't really related >> to RTO per se. >> >> Joe >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Dec 15 18:02:30 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0652A1295EF for ; Thu, 15 Dec 2016 18:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.785 X-Spam-Level: X-Spam-Status: No, score=-9.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3IiM5WxJzih for ; Thu, 15 Dec 2016 18:02:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BBC1294AB for ; Thu, 15 Dec 2016 18:02:27 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBG21i6P025290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 15 Dec 2016 18:01:45 -0800 (PST) To: Praveen Balasubramanian , "zhangyali (D)" , Neal Cardwell , "Jakob Heitz (jheitz)" References: <37069250-13c5-7692-f137-0f441d57a90c@isi.edu> From: Joe Touch Message-ID: <66111946-ad29-47b9-7ae5-17823d1cbb0e@isi.edu> Date: Thu, 15 Dec 2016 18:01:42 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FF75F1AE46E2AF1516690B52" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IEEgcXVlc3Rpb24gYWJvdXQgRGVs?= =?utf-8?q?ayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 02:02:29 -0000 This is a multi-part message in MIME format. --------------FF75F1AE46E2AF1516690B52 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 12/15/2016 5:21 PM, Praveen Balasubramanian wrote: > > While operators could tweak the settings, having TCP perform well out > of box in low latency environments is very useful. > IMO, the only rule "out of the box" is that TCP ought to *work*. Every other rule ends up compromising "works" for "works well", which is a mistake IMO. It just makes the whole Internet brittle in the future, WHEN (not if) your assumptions change. Joe --------------FF75F1AE46E2AF1516690B52 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 12/15/2016 5:21 PM, Praveen Balasubramanian wrote:

While operators could tweak the settings, having TCP perform well out of box in low latency environments is very useful.


IMO, the only rule "out of the box" is that TCP ought to *work*.

Every other rule ends up compromising "works" for "works well", which is a mistake IMO. It just makes the whole Internet brittle in the future, WHEN (not if) your assumptions change.

Joe
--------------FF75F1AE46E2AF1516690B52-- From nobody Thu Dec 15 18:07:57 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9D9129C4E for ; Thu, 15 Dec 2016 18:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBimBc8GOPUL for ; Thu, 15 Dec 2016 18:07:55 -0800 (PST) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id E4EB4129C56 for ; Thu, 15 Dec 2016 18:07:54 -0800 (PST) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 7887E177F6; Thu, 15 Dec 2016 18:07:54 -0800 (PST) Date: Thu, 15 Dec 2016 18:07:54 -0800 From: hiren panchasara To: Mark Allman Message-ID: <20161216020754.GJ82166@strugglingcoder.info> References: <20161216002433.GH82166@strugglingcoder.info> <99636.1481849289@lawyers.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SBT+cnFS/G3NVgv4" Content-Disposition: inline In-Reply-To: <99636.1481849289@lawyers.icir.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] ??: ??: ??: A question about Delayed ACK and RTO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 02:07:56 -0000 --SBT+cnFS/G3NVgv4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/15/16 at 07:48P, Mark Allman wrote: >=20 > > How can these 2 be differentiated? >=20 > Easy. >=20 > Retransmissions are triggered by the scheme outlined in RFC 6298. >=20 > Path failure is defined as not getting any packets through in 10sec. >=20 > There. Differentiated. >=20 > I am not suggesting that is smart. Or, the best way. But, making > these two things triggered by their own criteria that is tuned to > the each specific task is trivial. Thank you. I think I am getting the point you are trying to make and I agree that we need to separate them but I thought coming up wiht that '10sec' was the trickiest part. May be I am missing something or over-thinking this. :-) RTO, at least, gets derived from something realistic. I guess 'path failure' needs to come up with something like that? Cheers, Hiren PS: PMTUD implementation (at least in FreeBSD) comes to mind when I think about detecting anomaly beyond just 'packets are getting lost'. But thats again based on RTO in FreeBSD. Though I think we are talking about more fatal failures here. --SBT+cnFS/G3NVgv4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJYU0x2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lPdkH/RbwoFeKeahgx9ZY1oOw4bvk /Bln0WwyqsQoAyd1pn65WXQUSdGi0ATbXPPBXbnPclWn+M23RkXDaKZQ42LqKd5k v5FnpZLMg23k49Ix66xb62aX3aTcuf92MlQhk4q0pYCGhqvqzU851xSqSacW/kg4 7gpFzDuEFPIKl+x5pbWKOK1ZgqZBPHUwheoKJ6n4meJNpEfUwr2SLWUKLvdbtS1t mfpAKkiuVkPcwLh6My2uoHX6ejDLzc5pSMMoDmxDAAYEJgArrnM2DrBZ5m0eUMIC sHfN/TqTZLuDuFecqEv5E9lD0wo7mf3bd+eRRymb50Jkdl48AyNTBepkHWr1H5c= =paOf -----END PGP SIGNATURE----- --SBT+cnFS/G3NVgv4-- From nobody Thu Dec 15 23:02:24 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC751294E7 for ; Thu, 15 Dec 2016 23:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.106 X-Spam-Level: X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIJR1dMGXRD0 for ; Thu, 15 Dec 2016 23:02:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09139128DF6 for ; Thu, 15 Dec 2016 23:02:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCR26205; Fri, 16 Dec 2016 07:02:16 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 16 Dec 2016 07:02:13 +0000 Received: from DGGEMA406-HUB.china.huawei.com (10.3.20.47) by nkgeml411-hub.china.huawei.com (10.98.56.70) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 16 Dec 2016 15:02:11 +0800 Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.220]) by DGGEMA406-HUB.china.huawei.com ([10.3.20.47]) with mapi id 14.03.0301.000; Fri, 16 Dec 2016 15:02:06 +0800 From: "zhangyali (D)" To: Praveen Balasubramanian , Joe Touch , Neal Cardwell , "Jakob Heitz (jheitz)" Thread-Topic: =?utf-8?B?W3RjcG1dIOetlOWkjTogIOetlOWkjTogQSBxdWVzdGlvbiBhYm91dCBEZWxh?= =?utf-8?Q?yed_ACK_and_RTO?= Thread-Index: AQHSVzqzxdebrqonqECBBfboAwn9hqEKIbUA Date: Fri, 16 Dec 2016 07:02:05 +0000 Message-ID: References: <37069250-13c5-7692-f137-0f441d57a90c@isi.edu> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.189.228] Content-Type: multipart/alternative; boundary="_000_A747A0713F56294D8FBE33E5C6B8F5815F546384DGGEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.58539179.002E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.220, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 016109d4cbe2ba0f6756673ba05a8f62 Archived-At: Cc: "tcpm@ietf.org" Subject: [tcpm] =?utf-8?b?562U5aSNOiAg562U5aSNOiAg562U5aSNOiBBIHF1ZXN0aW9u?= =?utf-8?q?_about_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 07:02:23 -0000 --_000_A747A0713F56294D8FBE33E5C6B8F5815F546384DGGEMA502MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28sIHRoZSBwcm9iYWJpbGl0eSBvZiBkZWxheWluZyBzZWdtZW50IGNhdXNlZCBieSBkZWxheWVk IEFDSyBpcyBvYnZpb3VzLCByaWdodD8gSSBkaWQgZm91bmQgdGhlIHBoZW5vbWVub24gdGhhdCBz b21lIHNtYWxsIGZsb3dz4oCZIEZDVCBpcyB2ZXJ5IGxhcmdlLCB0aGF0IEkgdGhpbmsgc2VuZGVy 4oCZcyB0aW1lb3V0IGlzIHRyaWdnZXJlZCBieSByZWNlaXZlcuKAmXMgZGVsYXllZCBBQ0suDQoN CkkgdGhpbmsgaXQgcmVhbGx5IG1ha2Ugc2Vuc2UgdG8gc2V0IGxvbmdlciBSVE8gdmFsdWUgdGhh biBkZWxheWVkIEFDSywgd2hpY2ggd2lsbCByZWR1Y2Ugc3B1cmlvdXMgdGltZW91dCBjYXVzZWQg YnkgZGVsYXllZCBBQ0suIEJ1dCBhbm90aGVyIHF1ZXN0aW9uIG5lZWRzIHRvIGJlIGNvbnNpZGVy ZWQgaXMgdGhhdCBob3cgc2VuZGVyIGtub3cgaG93IGxvbmcgd2lsbCBiZSBkZWxheWVkIGluIHRo ZSByZWNlaXZlciBpZiByZWNlaXZlciBjb3VsZCBzZXQgaXQgZnJlZWx5LiBGb3IgZXhhbXBsZSwg dGhlIGRlZmF1bHQgZGVsYXllZCBBQ0sgYW5kIFJUTyBhcmUgYm90aCAyMDBtcyBpbiBzb21lIExp bnV4IE9TLCBzbyB0aGUgc3B1cmlvdXMgdGltZW91dCBpbiB0aGUgc2VuZGVyIGhhcHBlbiBtb3Jl IGZyZXF1ZW50bHkgd2hlbiBvbmUgc2VnbWVudCBpcyBkZWxheWVkIGluIHRoZSByZWNlaXZlciBh bmQgc2VuZGVyIGhhdmUgbm8gc2VnbWVudCB0byBiZSBzZW5kLg0KDQpTbyBJIHRoaW5rIHdlIHNo b3VsZCBoYXZlIG9uZSBtZXRob2QgdG8gZ2l2ZSBhIHN0YW5kYXJkIHZhbHVlIG9yIHRvIGNvb3Jk aW5hdGUgdGhlc2UgdHdvIHBhcmFtZXRlcnMgYXV0b21hdGljYWxseS4NCg0KWWFsaQ0KDQrlj5Hk u7bkuro6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIFttYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNv bV0NCuWPkemAgeaXtumXtDogMjAxNuW5tDEy5pyIMTbml6UgOToyMQ0K5pS25Lu25Lq6OiB6aGFu Z3lhbGkgKEQpIDx6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbT47IEpvZSBUb3VjaCA8dG91Y2hAaXNp LmVkdT47IE5lYWwgQ2FyZHdlbGwgPG5jYXJkd2VsbEBnb29nbGUuY29tPjsgSmFrb2IgSGVpdHog KGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb20+DQrmioTpgIE6IHRjcG1AaWV0Zi5vcmcNCuS4u+mi mDogUkU6IFt0Y3BtXSDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBhYm91dCBEZWxheWVkIEFD SyBhbmQgUlRPDQoNCldoaWxlIG9wZXJhdG9ycyBjb3VsZCB0d2VhayB0aGUgc2V0dGluZ3MsIGhh dmluZyBUQ1AgcGVyZm9ybSB3ZWxsIG91dCBvZiBib3ggaW4gbG93IGxhdGVuY3kgZW52aXJvbm1l bnRzIGlzIHZlcnkgdXNlZnVsLiBGb3IgbG93IGxhdGVuY3kgY29ubmVjdGlvbnMgV2luZG93cyBT ZXJ2ZXIgaGFzIHNoaXBwZWQgd2l0aCBhIDIwIG1zZWMgbWluIFJUTyBhbmQgMTAgbXNlYyBkZWxh eWVkIEFDSyB0aW1lb3V0IGZvciBzZXZlcmFsIHllYXJzIG5vdy4gQnV0IHRoaXMgbWV0aG9kIHJl bGllcyBvbiBhIGhldXJpc3RpYyB0byB1c2UgdGhlIFNZTiBoYW5kc2hha2UgUlRUIHRvIGRldGVj dCBsb3cgbGF0ZW5jeSBjb25uZWN0aW9ucyBhbmQgcGljayB0aGUgbW9yZSBhZ2dyZXNzaXZlIHRp bWVvdXRzIHdoaWNoIGlzIGxlc3MgdGhhbiBpZGVhbC4gQW4gZXhwbGljaXQgbmVnb3RpYXRpb24g b2YgdGhlIHRpbWVvdXQgd291bGQgYmUgdmVyeSB1c2VmdWwgYmVjYXVzZSBpdCByZW1vdmVzIGFu eSBjaGFuY2VzIG9mIG1pc21hdGNoIGFuZCBoZWxwcyBkaWZmZXJlbnQgT1MgVENQIHN0YWNrcyBp bnRlcm9wLg0KDQpGcm9tOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2Ygemhhbmd5YWxpIChEKQ0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxNCwgMjAx NiA2OjAyIFBNDQpUbzogSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1PG1haWx0bzp0b3VjaEBpc2ku ZWR1Pj47IE5lYWwgQ2FyZHdlbGwgPG5jYXJkd2VsbEBnb29nbGUuY29tPG1haWx0bzpuY2FyZHdl bGxAZ29vZ2xlLmNvbT4+OyBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbTxt YWlsdG86amhlaXR6QGNpc2NvLmNvbT4+DQpDYzogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBp ZXRmLm9yZz4NClN1YmplY3Q6IFt0Y3BtXSDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBhYm91 dCBEZWxheWVkIEFDSyBhbmQgUlRPDQoNCkhpIEpvZSwNCg0KSSByZWFsbHkgYWdyZWUgd2l0aCB5 b3UgYWJvdXQgVENQIG1lY2hhbmlzbSBzaG91bGQgZ2VuZXJhbCBmb3IgYWxsIGFyZWFzLCBpbmNs dWRpbmcgd2FuIGFuZCBkYXRhIGNlbnRlci4NCg0KQnV0IGV2ZXJ5IHNjZW5hcmlvcyBoYXZlIHRo ZWlyIG93biBjaGFyYWN0ZXJpc3RpY3MuIERhdGEgY2VudGVyIGhhcyBzb21lIGRpc3RpbmN0aXZl IGZlYXR1cmVzLCBzdWNoIGFzLCB1bHRyYWxvdyBSVFQsIGJlY2F1c2Ugb2YgY2VudHJhbGl6ZWQg bG9jYXRpb24sIGxlc3MgaG9wcywgYW5kIHNvIG9uLiBUaGVzZSBmZWF0dXJlcyBkZXRlcm1pbmVz IGRpZmZlcmVudCByZXF1aXJlbWVudCBmb3IgVENQIGRlZmF1bHQgY29uZmlndXJhdGlvbiwgY29t cGFyZWQgd2l0aCB3YW4gc2NlbmFyaW8uIEl0IGlzIGEgc29sdXRpb24gYnkgaGF2aW5nIHRoZSBh aWRzIG9mIG9wZXJhdG9yLCBidXQgbWF5YmUgd2UgY291bGQgaGF2ZSBhIG1vcmUgYXV0b21hdGlj IGFuZCBnZW5lcmFsIG1lY2hhbmlzbSB0byBzb2x2ZSBkaXNjcmVwYW5jeS4gSnVzdCBhIHNpbXBs ZSBpZGVhLiDimLoNCg0KQmVzdCBSZWdhcmRzLA0KWWFsaQ0KDQrlj5Hku7bkuro6IHRjcG0gW21h aWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBKb2UgVG91Y2gNCuWPkemAgeaXtumX tDogMjAxNuW5tDEy5pyIMTXml6UgMzoyMA0K5pS25Lu25Lq6OiBOZWFsIENhcmR3ZWxsIDxuY2Fy ZHdlbGxAZ29vZ2xlLmNvbTxtYWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb20+PjsgSmFrb2IgSGVp dHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+Pg0K 5oqE6YCBOiB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0K5Li76aKYOiBSZTog W3RjcG1dIOetlOWkjTogQSBxdWVzdGlvbiBhYm91dCBEZWxheWVkIEFDSyBhbmQgUlRPDQoNCg0K V2Ugc2hvdWxkIG5vdCBiZSBvcHRpbWl6aW5nIFRDUCBmb3Igc3BlY2lmaWMgZW52aXJvbm1lbnRz OyB0aGF0J3MgZm9yIG9wZXJhdG9ycyB0byBvdmVycmlkZS4NCg0KSm9lDQoNCk9uIDEyLzE0LzIw MTYgOTowNCBBTSwgTmVhbCBDYXJkd2VsbCB3cm90ZToNCk9uIFdlZCwgRGVjIDE0LCAyMDE2IGF0 IDExOjU2IEFNLCBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbTxtYWlsdG86 amhlaXR6QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGlzdG9yaWNhbGx5LCB0aGUgbWluaW11bSBSVE8g aXMgMSBzZWNvbmQgYW5kIGFjdHVhbCBSVFQgaXMgdmVyeSByYXJlbHkgbW9yZSB0aGFuIDEgc2Vj b25kLCBzbyBhbGwgdGhpcyBSVFQgY2FsY3VsYXRpb24gaGFyZGx5IGV2ZXIgbWF0dGVycyBhbnl3 YXkuDQoNClRoYXQgbWF5IGJlIHRydWUgaGlzdG9yaWNhbGx5LCBidXQgZm9yIG1hbnkgeWVhcnMg bWFqb3IgVENQIGltcGxlbWVudGF0aW9ucyAoaW5jbHVkaW5nIExpbnV4IGFuZCBGcmVlQlNEKSBo YXZlIHVzZWQgYSBtaW5pbXVtIFJUTyBjbG9zZXIgdG8gMjAwbXMuIEFuZCBpbiBkYXRhY2VudGVy IGVudmlyb25tZW50cyBldmVuIDIwMG1zIGNhbiBiZSBpbmZlYXNpYmx5IGhpZ2guDQoNCm5lYWwN Cg0KDQo= --_000_A747A0713F56294D8FBE33E5C6B8F5815F546384DGGEMA502MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buROw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5b6u6L2v6ZuF6buRIjsNCglwYW5v c2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWu i+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5TbywgdGhlIHByb2JhYmlsaXR5IG9mIGRlbGF5aW5nIHNlZ21lbnQgY2F1c2VkIGJ5 IGRlbGF5ZWQgQUNLIGlzIG9idmlvdXMsIHJpZ2h0PyBJIGRpZCBmb3VuZCB0aGUgcGhlbm9tZW5v biB0aGF0IHNvbWUgc21hbGwgZmxvd3PigJkgRkNUIGlzIHZlcnkgbGFyZ2UsIHRoYXQgSSB0aGlu aw0KIHNlbmRlcuKAmXMgdGltZW91dCBpcyB0cmlnZ2VyZWQgYnkgcmVjZWl2ZXLigJlzIGRlbGF5 ZWQgQUNLLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aGlu ayBpdCByZWFsbHkgbWFrZSBzZW5zZSB0byBzZXQgbG9uZ2VyIFJUTyB2YWx1ZSB0aGFuIGRlbGF5 ZWQgQUNLLCB3aGljaCB3aWxsIHJlZHVjZSBzcHVyaW91cyB0aW1lb3V0IGNhdXNlZCBieSBkZWxh eWVkIEFDSy4gQnV0IGFub3RoZXIgcXVlc3Rpb24gbmVlZHMgdG8NCiBiZSBjb25zaWRlcmVkIGlz IHRoYXQgaG93IHNlbmRlciBrbm93IGhvdyBsb25nIHdpbGwgYmUgZGVsYXllZCBpbiB0aGUgcmVj ZWl2ZXIgaWYgcmVjZWl2ZXIgY291bGQgc2V0IGl0IGZyZWVseS4gRm9yIGV4YW1wbGUsIHRoZSBk ZWZhdWx0IGRlbGF5ZWQgQUNLIGFuZCBSVE8gYXJlIGJvdGggMjAwbXMgaW4gc29tZSBMaW51eCBP Uywgc28gdGhlIHNwdXJpb3VzIHRpbWVvdXQgaW4gdGhlIHNlbmRlciBoYXBwZW4gbW9yZSBmcmVx dWVudGx5IHdoZW4NCiBvbmUgc2VnbWVudCBpcyBkZWxheWVkIGluIHRoZSByZWNlaXZlciBhbmQg c2VuZGVyIGhhdmUgbm8gc2VnbWVudCB0byBiZSBzZW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+U28gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBvbmUgbWV0aG9k IHRvIGdpdmUgYSBzdGFuZGFyZCB2YWx1ZSBvciB0byBjb29yZGluYXRlIHRoZXNlIHR3byBwYXJh bWV0ZXJzIGF1dG9tYXRpY2FsbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5ZYWxpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ 5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4N CiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiBbbWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb21dIDxi cj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7lj5HpgIHml7bpl7Q8L3NwYW4+OjwvYj4gMjAxNjxz cGFuIGxhbmc9IlpILUNOIj7lubQ8L3NwYW4+MTI8c3BhbiBsYW5nPSJaSC1DTiI+5pyIPC9zcGFu PjE2PHNwYW4gbGFuZz0iWkgtQ04iPuaXpTwvc3Bhbj4gOToyMTxicj4NCjxiPjxzcGFuIGxhbmc9 IlpILUNOIj7mlLbku7bkuro8L3NwYW4+OjwvYj4gemhhbmd5YWxpIChEKSAmbHQ7emhhbmd5YWxp MzY5QGh1YXdlaS5jb20mZ3Q7OyBKb2UgVG91Y2ggJmx0O3RvdWNoQGlzaS5lZHUmZ3Q7OyBOZWFs IENhcmR3ZWxsICZsdDtuY2FyZHdlbGxAZ29vZ2xlLmNvbSZndDs7IEpha29iIEhlaXR6IChqaGVp dHopICZsdDtqaGVpdHpAY2lzY28uY29tJmd0Ozxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7m ioTpgIE8L3NwYW4+OjwvYj4gdGNwbUBpZXRmLm9yZzxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNO Ij7kuLvpopg8L3NwYW4+OjwvYj4gUkU6IFt0Y3BtXSA8c3BhbiBsYW5nPSJaSC1DTiI+562U5aSN PC9zcGFuPjogPHNwYW4gbGFuZz0iWkgtQ04iPg0K562U5aSNPC9zcGFuPjogQSBxdWVzdGlvbiBh Ym91dCBEZWxheWVkIEFDSyBhbmQgUlRPPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPldoaWxlIG9wZXJhdG9ycyBjb3VsZCB0d2VhayB0aGUgc2V0dGlu Z3MsIGhhdmluZyBUQ1AgcGVyZm9ybSB3ZWxsIG91dCBvZiBib3ggaW4gbG93IGxhdGVuY3kgZW52 aXJvbm1lbnRzIGlzIHZlcnkgdXNlZnVsLiBGb3IgbG93DQogbGF0ZW5jeSBjb25uZWN0aW9ucyBX aW5kb3dzIFNlcnZlciBoYXMgc2hpcHBlZCB3aXRoIGEgMjAgbXNlYyBtaW4gUlRPIGFuZCAxMCBt c2VjIGRlbGF5ZWQgQUNLIHRpbWVvdXQgZm9yIHNldmVyYWwgeWVhcnMgbm93LiBCdXQgdGhpcyBt ZXRob2QgcmVsaWVzIG9uIGEgaGV1cmlzdGljIHRvIHVzZSB0aGUgU1lOIGhhbmRzaGFrZSBSVFQg dG8gZGV0ZWN0IGxvdyBsYXRlbmN5IGNvbm5lY3Rpb25zIGFuZCBwaWNrIHRoZSBtb3JlIGFnZ3Jl c3NpdmUgdGltZW91dHMNCiB3aGljaCBpcyBsZXNzIHRoYW4gaWRlYWwuIEFuIGV4cGxpY2l0IG5l Z290aWF0aW9uIG9mIHRoZSB0aW1lb3V0IHdvdWxkIGJlIHZlcnkgdXNlZnVsIGJlY2F1c2UgaXQg cmVtb3ZlcyBhbnkgY2hhbmNlcyBvZiBtaXNtYXRjaCBhbmQgaGVscHMgZGlmZmVyZW50IE9TIFRD UCBzdGFja3MgaW50ZXJvcC4gJm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gdGNwbSBbPGEgaHJlZj0ibWFpbHRvOnRjcG0tYm91bmNl c0BpZXRmLm9yZyI+bWFpbHRvOnRjcG0tYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPnpoYW5neWFsaSAoRCk8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBEZWNl bWJlciAxNCwgMjAxNiA2OjAyIFBNPGJyPg0KPGI+VG86PC9iPiBKb2UgVG91Y2ggJmx0OzxhIGhy ZWY9Im1haWx0bzp0b3VjaEBpc2kuZWR1Ij50b3VjaEBpc2kuZWR1PC9hPiZndDs7IE5lYWwgQ2Fy ZHdlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpuY2FyZHdlbGxAZ29vZ2xlLmNvbSI+bmNhcmR3ZWxs QGdvb2dsZS5jb208L2E+Jmd0OzsgSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0OzxhIGhyZWY9Im1h aWx0bzpqaGVpdHpAY2lzY28uY29tIj5qaGVpdHpAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5D Yzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50Y3BtQGlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbdGNwbV0gPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij7nrZTlpI08L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjoNCjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+562U5aSNPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij46IEEgcXVlc3Rpb24gYWJvdXQgRGVsYXll ZCBBQ0sgYW5kIFJUTzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBKb2UsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHJlYWxseSBhZ3JlZSB3aXRoIHlvdSBhYm91 dCBUQ1AgbWVjaGFuaXNtIHNob3VsZCBnZW5lcmFsIGZvciBhbGwgYXJlYXMsIGluY2x1ZGluZyB3 YW4gYW5kIGRhdGEgY2VudGVyLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5CdXQgZXZlcnkgc2NlbmFyaW9zIGhhdmUgdGhlaXIgb3duIGNoYXJhY3RlcmlzdGlj cy4gRGF0YSBjZW50ZXIgaGFzIHNvbWUgZGlzdGluY3RpdmUgZmVhdHVyZXMsIHN1Y2ggYXMsIHVs dHJhbG93IFJUVCwgYmVjYXVzZSBvZiBjZW50cmFsaXplZCBsb2NhdGlvbiwgbGVzcyBob3BzLA0K IGFuZCBzbyBvbi4gVGhlc2UgZmVhdHVyZXMgZGV0ZXJtaW5lcyBkaWZmZXJlbnQgcmVxdWlyZW1l bnQgZm9yIFRDUCBkZWZhdWx0IGNvbmZpZ3VyYXRpb24sIGNvbXBhcmVkIHdpdGggd2FuIHNjZW5h cmlvLiBJdCBpcyBhIHNvbHV0aW9uIGJ5IGhhdmluZyB0aGUgYWlkcyBvZiBvcGVyYXRvciwgYnV0 IG1heWJlIHdlIGNvdWxkIGhhdmUgYSBtb3JlIGF1dG9tYXRpYyBhbmQgZ2VuZXJhbCBtZWNoYW5p c20gdG8gc29sdmUgZGlzY3JlcGFuY3kuIEp1c3QNCiBhIHNpbXBsZSBpZGVhLiA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPko8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlc3Qg UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WWFsaQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij4NCiB0Y3BtIFs8YSBocmVmPSJtYWlsdG86dGNwbS1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+DQo8c3BhbiBs YW5nPSJaSC1DTiI+5Luj6KGoIDwvc3Bhbj48L2I+Sm9lIFRvdWNoPGJyPg0KPGI+PHNwYW4gbGFu Zz0iWkgtQ04iPuWPkemAgeaXtumXtDwvc3Bhbj46PC9iPiAyMDE2PHNwYW4gbGFuZz0iWkgtQ04i PuW5tDwvc3Bhbj4xMjxzcGFuIGxhbmc9IlpILUNOIj7mnIg8L3NwYW4+MTU8c3BhbiBsYW5nPSJa SC1DTiI+5pelPC9zcGFuPiAzOjIwPGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaUtuS7tuS6 ujwvc3Bhbj46PC9iPiBOZWFsIENhcmR3ZWxsICZsdDs8YSBocmVmPSJtYWlsdG86bmNhcmR3ZWxs QGdvb2dsZS5jb20iPm5jYXJkd2VsbEBnb29nbGUuY29tPC9hPiZndDs7IEpha29iIEhlaXR6IChq aGVpdHopICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+amhlaXR6QGNpc2Nv LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuaKhOmAgTwvc3Bhbj46PC9i PiA8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQo8 Yj48c3BhbiBsYW5nPSJaSC1DTiI+5Li76aKYPC9zcGFuPjo8L2I+IFJlOiBbdGNwbV0gPHNwYW4g bGFuZz0iWkgtQ04iPuetlOWkjTwvc3Bhbj46IEEgcXVlc3Rpb24gYWJvdXQgRGVsYXllZCBBQ0sg YW5kIFJUTzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPldlIHNob3VsZCBub3QgYmUgb3B0 aW1pemluZyBUQ1AgZm9yIHNwZWNpZmljIGVudmlyb25tZW50czsgdGhhdCdzIGZvciBvcGVyYXRv cnMgdG8gb3ZlcnJpZGUuPG86cD48L286cD48L3A+DQo8cD5Kb2U8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDEyLzE0LzIwMTYgOTowNCBBTSwgTmVhbCBDYXJkd2VsbCB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIERl YyAxNCwgMjAxNiBhdCAxMTo1NiBBTSwgSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0OzxhIGhyZWY9 Im1haWx0bzpqaGVpdHpAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+amhlaXR6QGNpc2NvLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhpc3RvcmljYWxseSwgdGhlIG1pbmltdW0gUlRPIGlzIDEgc2Vjb25kIGFuZCBhY3R1YWwg UlRUIGlzIHZlcnkgcmFyZWx5IG1vcmUgdGhhbiAxIHNlY29uZCwgc28gYWxsIHRoaXMgUlRUIGNh bGN1bGF0aW9uIGhhcmRseSBldmVyIG1hdHRlcnMgYW55d2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBt YXkgYmUgdHJ1ZSBoaXN0b3JpY2FsbHksIGJ1dCBmb3IgbWFueSB5ZWFycyBtYWpvciBUQ1AgaW1w bGVtZW50YXRpb25zIChpbmNsdWRpbmcgTGludXggYW5kIEZyZWVCU0QpIGhhdmUgdXNlZCBhIG1p bmltdW0gUlRPIGNsb3NlciB0byAyMDBtcy4gQW5kIGluIGRhdGFjZW50ZXIgZW52aXJvbm1lbnRz IGV2ZW4gMjAwbXMgY2FuIGJlIGluZmVhc2libHkgaGlnaC4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bmVhbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A747A0713F56294D8FBE33E5C6B8F5815F546384DGGEMA502MBSchi_-- From nobody Thu Dec 15 23:29:12 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25E9129AA9 for ; Thu, 15 Dec 2016 23:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.117 X-Spam-Level: X-Spam-Status: No, score=-7.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVsL2VPDTbxg for ; Thu, 15 Dec 2016 23:29:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F97129C44 for ; Thu, 15 Dec 2016 23:29:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCR29593; Fri, 16 Dec 2016 07:29:04 +0000 (GMT) Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 16 Dec 2016 07:29:03 +0000 Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.220]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0301.000; Fri, 16 Dec 2016 15:28:57 +0800 From: "zhangyali (D)" To: Alejandro Popovsky , Joe Touch , "tcpm@ietf.org" Thread-Topic: =?gb2312?B?W3RjcG1dILTwuLQ6ILTwuLQ6ILTwuLQ6IEEgcXVlc3Rpb24gYWJvdXQgRGVs?= =?gb2312?Q?ayed_ACK_and_RTO?= Thread-Index: AQHSVqypJ3KpAUvddE2SRtM0MhZVAKEIRmIAgAAR/YCAAEREgIAAgX8AgAEOJ1A= Date: Fri, 16 Dec 2016 07:28:57 +0000 Message-ID: References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> <45f0034f-70a2-2aa3-d87b-c7288a51ad77@isi.edu> <48aa99d0-113e-edda-94f7-48d81bea59fd@palermo.edu> In-Reply-To: <48aa99d0-113e-edda-94f7-48d81bea59fd@palermo.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.189.228] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.585397C0.03BE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.220, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e879ff10b7c783f571ed579b61138ab2 Archived-At: Subject: [tcpm] =?gb2312?b?tPC4tDogILTwuLQ6ILTwuLQ6ILTwuLQ6IEEgcXVlc3Rp?= =?gb2312?b?b24gYWJvdXQgRGVsYXllZCBBQ0sgYW5kIFJUTw==?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 07:29:12 -0000 WWVzLCBJIHRoaW5rIGl0J3MgYSBnb29kIGNob2ljZSB0byBkaWZmZXJlbnRpYXRlIHRoZSBsYXN0 IHNlZ21lbnQuIEJ1dCBtYXliZSBpdCdzIG5vdCBlYXN5IHRvIGNvbmZpcm0gaWYgaXQgaXMgdGhl IGxhc3Qgc2VnbWVudCwgZXZlbiB0aGVyZSBpcyBqdXN0IG9uZSBzZWdtZW50IGluIGJ1ZmZlciwg c2luY2UgaXQgaXMgZGV0ZXJtaW5lZCBieSB0aGUgdXBwZXIgYXBwbGljYXRpb24uIA0KDQpBbm90 aGVyIHF1ZXN0aW9uIGlzIHRoYXQgZm9yIHRoZSBmbG93IHNlbmRpbmcgb25lIHNlZ21lbnQgcGVy IGEgbG9uZyB0aW1lLCB3aWxsIGl0IHN1ZmZlciBmcm9tIGRlbGF5ZWQgQUNLPw0KDQpZYWxpDQoN Ci0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGll dGYub3JnXSC0+rHtIEFsZWphbmRybyBQb3BvdnNreQ0Kt6LLzcqxvOQ6IDIwMTbE6jEy1MIxNsjV IDc6MTMNCsrVvP7IyzogSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1PjsgdGNwbUBpZXRmLm9yZw0K 1vfM4jogUmU6IFt0Y3BtXSC08Li0OiC08Li0OiC08Li0OiBBIHF1ZXN0aW9uIGFib3V0IERlbGF5 ZWQgQUNLIGFuZCBSVE8NCg0KT24gdGhlIHNlY29uZCBvcHRpb24gKG5vIG1vcmUgZGF0YSB0byBz ZW5kKSB0aGVyZSB3b3VsZCBiZSBubyBuZWVkIHRvIGNoYW5nZSB0aGUgQVBJLiBUaGUgdGNwIHNl bmRlciB0Y3Agd291bGQgZ2VuZXJhdGUgdGhlIHNpZ25hbCBhdXRvbWF0aWNhbGx5IHdpdGggdGhl IGxhc3Qgc2VnbWVudC4gQW5kIHRoZSByZWNlaXZlciBjb3VsZCBqdXN0IHVzZSB0aGUgaW5mbyB0 byBhZGp1c3QgdGhlIGRlbGF5IGFjayB0aW1lciBmb3IgdGhhdCBzZWdtZW50Lg0KDQpBbmQgaW4g b3JkZXIgZm9yIHRoZSBleHRyYSBhY2sgbm90IHRvIHByb2R1Y2UgYW4gZXh0cmEgY3duZCBncm93 dGggdGhlIHNlbmRlciBzaG91bGQgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbiBvZiByZmM1Njgx LCBwYWdlIDYuDQoNCkFsZWphbmRyby4NCg0KT24gMTUvMTIvMjAxNiAxMjoyOSBwLiBtLiwgSm9l IFRvdWNoIHdyb3RlOg0KPg0KPiBPbiAxMi8xNS8yMDE2IDM6MjUgQU0sIEFsZWphbmRybyBQb3Bv dnNreSB3cm90ZToNCj4+IFRjcCB3b3VsZCBiZW5lZml0IG11Y2ggZnJvbSBhbmQgJ2VuZCBvZiBh cHAgd3JpdGUgY2FsbCcgc2lnbmFsIG9yIG1heSANCj4+IGJlICdlbmQgb2Ygc2VuZGVyIGJ1ZmZl ciBkYXRhJyBzaWduYWwuDQo+ICAgSW4gdGhlIGN1cnJlbnQgVENQIEFQSSwgdGhlcmUgaXMgYWJz b2x1dGVseSBubyBjb3JyZWxhdGlvbiBiZXR3ZWVuIA0KPiBhcHAgU0VORCBjYWxscyBhbmQgYW55 IG5vdGlvbiBUQ1AgbWlnaHQgaGF2ZSBvZiBib3VuZGFyaWVzIC0gVENQIA0KPiBwcmVzZW50cyBh IGJ5dGVzdHJlYW0gc2VydmljZSBvbmx5LiBUaGVyZSB3b3VsZCBiZSBtYW55IGNvbnNlcXVlbmNl cyANCj4gdG8gY2hhbmdpbmcgdGhhdCBBUEksIGJ1dCBpdCBtaWdodCBiZSB1c2VmdWwgdG8gbm90 ZSB0aGF0IHRoaXMgd2FzIG9uY2UgY29uc2lkZXJlZC4NCj4gSnVzdCB0d28gZGF5cyBhZ28sIEJv YiBCcmFkZW4gYW5kIEkgd2VyZSBkaXNjdXNzaW5nIFRDUCB2MyAoYmVmb3JlIHRoZSANCj4gY3Vy cmVudCBvbmUgIC0gYXMgZG9jdW1lbnRlZCBpbiBJRU4gIDIxKSwgd2hpY2ggZGlkIGhhdmUgdGhp cyBzb3J0IG9mIA0KPiBzaWduYWwsIGJ1dCBpdCB3YXMgY2FycmllZCBpbnRvIHRoZSBwYWNrZXQg YXMgYmVnaW4vZW5kIChvZiAibGV0dGVyIikgZmxhZ3MuDQo+DQo+IE5vdGUgdGhhdCBoaXMgYmVo YXZpb3IgaXMgYSBjb25zZXF1ZW5jZSBvZiB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiANCj4gZGVs YXllZCBBQ0tzIGFuZCBhIGxhY2sgb2YgYXBwbGljYXRpb24gZGF0YSwgYW5kIGhhcHBlbnMgYW55 IHRpbWUgdGhlIA0KPiBhcHAgbGF5ZXIgInN0YXJ2ZXMiIFRDUC4gSXQgd2FzIHdlbGwgc3R1ZGll ZCBpbiB0aGUgOTAncyBpbiBpdHMgDQo+IGludGVyYWN0aW9uIHdpdGggcGVyc2lzdGVudCB3ZWIg Y29ubmVjdGlvbnMuIEl0IGlzbid0IHJlYWxseSByZWxhdGVkIA0KPiB0byBSVE8gcGVyIHNlLg0K Pg0KPiBKb2UNCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg== From nobody Thu Dec 15 23:47:19 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0576E129861 for ; Thu, 15 Dec 2016 23:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.117 X-Spam-Level: X-Spam-Status: No, score=-7.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2aJjfm7aNsb for ; Thu, 15 Dec 2016 23:47:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC12129449 for ; Thu, 15 Dec 2016 23:47:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCR32258; Fri, 16 Dec 2016 07:47:10 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 16 Dec 2016 07:47:08 +0000 Received: from DGGEMA404-HUB.china.huawei.com (10.3.20.45) by nkgeml412-hub.china.huawei.com (10.98.56.73) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 16 Dec 2016 15:47:06 +0800 Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.220]) by DGGEMA404-HUB.china.huawei.com ([10.3.20.45]) with mapi id 14.03.0301.000; Fri, 16 Dec 2016 15:47:00 +0800 From: "zhangyali (D)" To: "gorry@erg.abdn.ac.uk" , Yoshifumi Nishida Thread-Topic: =?utf-8?B?W3RjcG1dIOetlOWkjTog562U5aSNOiDnrZTlpI06IEEgcXVlc3Rpb24gYWJv?= =?utf-8?Q?ut_Delayed_ACK_and_RTO?= Thread-Index: AQHSVqypJ3KpAUvddE2SRtM0MhZVAKEIRmIAgAHojMA= Date: Fri, 16 Dec 2016 07:47:00 +0000 Message-ID: References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> In-Reply-To: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.189.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58539BFE.03E2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.220, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2a34cbab053e054bdcc219d3dbe78842 Archived-At: Cc: "tcpm@ietf.org" Subject: [tcpm] =?utf-8?b?562U5aSNOiAg562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBx?= =?utf-8?q?uestion_about_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 07:47:18 -0000 SSBpZGVudGlmeSB3aXRoIHlvdXIgZGlzdGluY3Rpb24gZnVuY3Rpb24gb2YgUlRPLiBJIHJlYWxs eSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBkaWZmZXJlbnRpYXRlIHRoZSBlZmZlY3QgY2F1c2VkIGJ5 IG5ldHdvcmsgY29uZ2VzdGlvbiBvciBwYXRoIGZhaWx1cmUsIGFuZCB0YWtlIGRpZmZlcmVudCBh Y3Rpb25zLCBzdWNoIGFzLCBtb3JlIGFnZ3Jlc3NpdmUgYWN0aW9uIHRvIHRoZSBzZWNvbmQgY2Fz ZXMuIEJ1dCBub3csIHdlIGp1c3QgaGF2ZSBSVE8gYXMgdGhlIGxhc3QgbWV0aG9kIHRvIHJldHJh bnNtaXNzaW9uIHRoZSBzZWdtZW50IHRoYXQgaXMgbG9zdCBvciBqdXN0IGJlIGRlbGF5ZWQgaWYg d2UgZG8gbm90IGhhdmUgZXh0cmEgc2VnbWVudHMgb3Igd2luZG93IHRvIHRyaWdnZXIgZHVwYWNr LiBTbyBhbm90aGVyIHJldGFuc21pc3Npb24gZGV0ZWN0aW9uIG1ldGhvZCBmYXN0ZXIgdGhhbiB0 aW1lb3V0IGFuZCBtb3JlIGVmZmVjdGl2ZSBzaG91bGQgYmUgdGhpbmtlZCBhYm91dC4NCg0KWWFs aQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IEdvcnJ5IEZhaXJodXJzdCBb bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrXSANCuWPkemAgeaXtumXtDogMjAxNuW5tDEy5pyI MTXml6UgMTg6MjENCuaUtuS7tuS6ujogWW9zaGlmdW1pIE5pc2hpZGEgPG5pc2hpZGFAc2ZjLndp ZGUuYWQuanA+OyB6aGFuZ3lhbGkgKEQpIDx6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbT4NCuaKhOmA gTogdGNwbUBpZXRmLm9yZw0K5Li76aKYOiBSZTogW3RjcG1dIOetlOWkjTog562U5aSNOiDnrZTl pI06IEEgcXVlc3Rpb24gYWJvdXQgRGVsYXllZCBBQ0sgYW5kIFJUTw0KDQoNCkp1c3QgYWRkaW5n IGEgZmV3IG1vcmUgY29tbWVudHMgaGVyZSwgYmVjYXVzZSB0aGVyZSBoYXMgYmVlbiBtdWNoIHRh bGsgYWJvdXQgaG93IGRlc2lyYWJsZSBpdCBpcyBmb3IgdGhlIFJUTyB0byBjb252ZXJnZSB0byB0 aGUgUlRULCBhbmQgSSB0aGluayB3ZSBuZWVkIHRvIGJlIGNsZWFyLg0KDQpUaGUgVENQIFJUTyBo YXMgdHdvIGRpc3RpbmN0IGZ1bmN0aW9uczoNCg0KKDEpICB0aGUgUlRPIGlzIG9mIGNvdXJzZSB0 aGUgbWV0aG9kIG9mIGxhc3QgcmVzb3J0IGZvciB0aGUgcmVjb3Zlcnkgb2YgYSBsb3N0IHNlZ21l bnQgKHRoZSBmaW5hbCBzZWdtZW50IG9mIGEgYnVyc3QsIGZvbGxvd2luZyBwZXJzaXN0ZW50IGxv c3MsIGV0YykuDQoNCigyKSBTZWNvbmQgdGhlIFJUTyBpcyAgbWV0aG9kIHRvIGRldGVjdCBhIHBh dGggZmFpbHVyZSAtIHdoZXJlIHNvbWV0aGluZyBoYXMgY2hhbmdlZCBzaWduaWZpY2FudGx5LiBB cyBzdWNoLCB0cmlnZ2VyaW5nIGEgY29uc2VydmF0aXZlICgxIG9yIDMNCnNlY29uZHMpIFJUTyBp bXBsaWVzIHRoYXQgc3RhdGUgYWJvdXQgdGhlIHBhdGggbmVlZHMgdG8gYmUgcmVzZXQgKFJUVCwg cGVyaGFwcyBpbnZva2luZyBQTVRVRCwgY29uZ2VzdGlvbiBzdGF0ZSB2YXJpYWJsZXMsIGV0Yywg cG9zc2libHkgaW4gdGhlIGZ1dHVyZSBmYWxsaW5nIGJhY2sgZnJvbSB1c2luZyBFQ04sIGV0YykN Cg0KRm9yIHRoZSBmaXJzdCBmdW5jdGlvbiwgdGhlcmUgYXJlIG1hbnkgd2F5cyB0byBkZXRlY3Qg bG9zdCBzZWdtZW50cyAoRHVwYWNrcywgcHJvYmUgcGFja2V0cywgcmVjb3ZlcnkgdGltZXJzLCBl dGMpLiBBbGwgb2YgdGhlc2UgYWN0IGZhc3RlciB0aGFuIGEgY29uc2VydmF0aXZlbHkgc2V0IHRp bWVvdXQuIFRoZXkgYWxzbyBkbyBub3QgbmVlZCB0byBlcmFzZSBjb2xsZWN0ZWQgcGF0aCBzdGF0 ZSwgdGhleSBjYW4gc2ltcGx5IHJlLXRyYW5zbWl0IHRoZSBsb3N0IHNlZ21lbnRzLg0KDQpBbiBS VE8gY2xvc2UgdG8gdGhlIFJUVCB3aWxsIGJlIGRpc2FzdHJvdXMgZm9yIHNvbWUgcGF0aHMuIFRo aXMgaXMgb25lIG9mIHRoZSByZWFzb25zIHdoeSBwZW9wbGUgaGF2ZSBkZXBsb3llZCBQRVBzIHRv IHN1cHBvcnQgcmFkaW8gdGVjaG5vbG9neQ0KLSB3ZSBzaG91bGQgbm90IGJlIGVuY291cmFnaW5n IHRoaXMuIEFuIFJUTyBzZXQgY2xvc2UgdG8gdGhlIFJUVCBjYW4gcHJvZHVjZSBjb21wbGV4IGlu dGVyYWN0aW9ucyB3aGVuIHRoZSBwYXRoIGNoYXJhY3RlcmlzdGljcyBjaGFuZ2UgKHdoaWNoIGRv ZXMgaGFwcGVuIHdpdGggcHJvcGFnYXRpb24gaW1wYWlybWVudHMgYW5kIHJhZGlvIHJlc291cmNl IG1hbmFnZW1lbnQsIG9uIHdpcmVsZXNzLCBtaWNyb3dhdmUgc2F0ZWxsaXRlIGFuZCBvdGhlciBw YXRocywgYW5kIGFsc28gd2l0aCBtaWRkbGVib3hlcyB0aGF0IGF0dGVtcHQgdG8gY29udHJvbCBj YXBhY2l0eS92b2x1bWUgdXNhZ2UpLiBUaGlzIHR5cGUgb2YgcGF0aCBpcyBub3QgZ29pbmcgYXdh eSwgdGFsayBvZiB3aXJlbGVzcyBsaW5rcyB3aXRoIHRvcCBzcGVlZHMgb2YgR2JwcyBmb3IgNUcg d2lsbCBsaWtlbHkgYmUgYWNjb21wYW5pZWQgYnkgdmVyeSBsYXJnZSB2YXJpYXRpb24gaW4gcGF0 aCBjaGFyYWN0ZXJpc3RpY3MgLSBhdCB0aGUgb3RoZXIgZXh0cmVtZSBwZW9wbGUgaW4gbGFyZ2Ug cGFydHMgb2YgdGhlIHdvcmxkIGFyZSBzdGlsbCB3aXRoIGticHMgdGVjaG5vbG9neS4gSWYgdGhl IHRpbWVyIG9ubHkgcmVjb3ZlcnMgcGFja2V0cywgaXQgd291bGQgc2ltcGx5IHJlc3VsdCBpbiBy ZXRyYW5zbWlzc2lvbiwgaWYgaXQgdHJpZ2dlcnMgb3RoZXIgcHJvYmluZyB0aGF0IHdvdWxkIGJl IHVuZm9ydHVuYXRlLiBJIHRoaW5rIHRoZSBJRVRGIG5lZWRzIHRvIGVuc3VyZSBvdXIgc3BlY3Mg d29yayBmb3IgYWxsIHBlb3BsZS4NCg0KV2hhdCBJIGFtIHNheWluZyBpcyB0aGF0IHRoZSBzZWNv bmQgZnVuY3Rpb24gZG9lcyBub3QgbmVlZCBhIHRpbWVvdXQgcGVyaW9kIG5lYXIgdGhlIFJUVC4g Um9idXN0IHByb3RvY29scyBoYXZlIGJlZW4gZGVzaWduZWQgdG8gaGF2ZSBhIGNvbnNlcnZhdGl2 ZSBSVE8gdGltZXIgdGhhdCBpcyBzZXQgdG8gbXVjaCBtb3JlIHRoYW4gYSBSVFQsIGRlc2lnbmVk IHRvIGRldGVjdCBhbiB1bnJlc3BvbnNpdmUgZW5kcG9pbnQgb3IgcGF0aCBwcm9ibGVtLiBUaGUg SUVURiBoYXMgYXJndWVkIC0gYW5kIHRvIG15IGtub3dsZWRnZSBzdGlsbCBhcmd1ZXMgdGhhdCBN aW5fUlRPIHNob3VsZCBiZSBvbmUgc2Vjb25kLCB3aGljaCBJIHRoaW5rIHJlZmxlY3RzIHRoaXMg cG9zaXRpb24uIElmIHRoZSBsb3NzIHJlY292ZXJ5IGlzIGVmZmljaWVudCwgdGhpcyB3aWxsIHRy aWdnZXIgb25seSBpbmZyZXF1ZW50bHkgKGUuZy4sIHBlcnNpc3RlbnQgbG9zcyBvZiBvbmUgcGFj a2V0KS4gSSB0aGluayB0aGlzIGlzIHRoZSBjb3JyZWN0IHdheSB0byBkZXNpZ24gVENQLiBJdCBt b3RpdmF0ZXMgdGhhdCB3ZSBzaG91bGQgYWN0dWFsbHkgc3RyaXZlIGZvciBhIG9uZSBzZWNvbmQg KG9yIHNvKSBSVE8uDQoNCkdvcnJ5DQoNCg0KT24gMTUvMTIvMjAxNiAwODoyNCwgWW9zaGlmdW1p IE5pc2hpZGEgd3JvdGU6DQo+IEEgcXVlc3Rpb24gd291bGQgYmUgd2hlbiBUQ1Agc2VudCBvZGQg bnVtYmVyIG9mIHBhY2tldHMsIGhvdyBpdCBjYW4gDQo+IGtub3cgd2hldGhlciBhbm90aGVyIHBh Y2tldHMgd2lsbCBjb21lIGZyb20gdXBwZXIgbGF5ZXIgdmVyeSBzb29uIG9yIA0KPiBub3QuIEFs c28sIEknbSBub3QgdmVyeSBzdXJlIHlldCBpZiB0aGUgcHJvYmFiaWxpdHkgaXMgc28gb2J2aW91 cy4gSSANCj4gY2FuIGFncmVlIHRoYXQgUlRPIGNhbiBnZXQgY2xvc2UgdG8gcmF3IHJ0dCB2YWx1 ZSB1bmRlciBidWxrIHRyYW5zZmVyLg0KPiBCdXQsIEkgYW0gZ3Vlc3Npbmcgbm90IHNvIG1hbnkg YXBwcyBjaGFuZ2UgdGhlIGJlaGF2aW9yIGZyb20gYnVsayANCj4gdHJhbnNmZXIgdG8gc3BvbnRh bmVvdXMgc21hbGwgYnVyc3QgdHJhbnNmZXIuDQo+IC0tDQo+IFlvc2hpDQo+DQo+DQo+IE9uIFdl ZCwgRGVjIDE0LCAyMDE2IGF0IDc6MDggUE0sIHpoYW5neWFsaSAoRCkgPHpoYW5neWFsaTM2OUBo dWF3ZWkuY29tPiB3cm90ZToNCj4+IFBsZWFzZSBhbGxvdyBtZSB0byBhZGQgb25lIG1vcmUgcG9p bnQuIElmIHRoZSBwcm9iYWJpbGl0eSBvZiBvZGQgDQo+PiBudW1iZXIgb2YgcGFja2V0cyBvY2N1 cnJpbmcgIHNwdXJpb3VzIFJUTyBpcyBzbyBvdXRzdGFuZGluZywgd2h5IA0KPj4gbm9ib2R5IHRy eSB0byBzb2x2ZSB0aGlzIHByb2JsZW0/DQo+Pg0KPj4NCj4+DQo+PiDlj5Hku7bkuro6IHRjcG0g W21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCB6aGFuZ3lhbGkgKEQpDQo+PiDl j5HpgIHml7bpl7Q6IDIwMTblubQxMuaciDE15pelIDk6NDUNCj4+IOaUtuS7tuS6ujogTmVhbCBD YXJkd2VsbCA8bmNhcmR3ZWxsQGdvb2dsZS5jb20+DQo+PiDmioTpgIE6IHRjcG1AaWV0Zi5vcmcN Cj4+IOS4u+mimDogW3RjcG1dIOetlOWkjTog562U5aSNOiBBIHF1ZXN0aW9uIGFib3V0IERlbGF5 ZWQgQUNLIGFuZCBSVE8NCj4+DQo+Pg0KPj4NCj4+PiBZZXMsIHRoZXJlIHNob3VsZCBvbmx5IGJl IGEgZGVsYXllZCBBQ0sgYXQgdGhlIGVuZCBvZiBhbiBhcHBsaWNhdGlvbiANCj4+PiBjaHVuayBp ZiB0aGVyZSBpcyBhbiBvZGQgbnVtYmVyIG9mIHBhY2tldHMuIEJ1dCB3ZSB3b3VsZCBleHBlY3Qg DQo+Pj4gcm91Z2hseSBoYWxmIG9mIGFwcGxpY2F0aW9uIGNodW5rcyB0byBoYXZlIGFuIG9kZCBu dW1iZXIgb2YgcGFja2V0cy4gDQo+Pj4gVGhvdWdoIHRoZSBwcm9wb3J0aW9uIGlzIHByb2JhYmx5 IGhpZ2hlciB0aGFuIHRoYXQsIHNpbmNlIG1hbnkgDQo+Pj4gYXBwbGljYXRpb24gY2h1bmtzIGFy ZSBqdXN0IG9uZSBwYWNrZXQgKGUuZy4gYW4gSFRUUCBvciBSUEMgcmVxdWVzdCBvciByZXNwb25z ZSkuDQo+Pg0KPj4NCj4+DQo+PiBJIGFncmVlIHdpdGggeW91IHRoYXQgb2RkIG51bWJlciBvZiBw YWNrZXRzIG1heSBvY2N1ciBzcHVyaW91cyBSVE8gDQo+PiBtb3JlIGVhc2lseSwgYnV0IEkgdGhp bmsgZm9yIHRoZSBmbG93cyBvd25pbmcganVzdCBvbmUgcGFja2V0IHNob3VsZCANCj4+IG5vdCBi ZSBhZmZlY3RlZCBieSBkZWxheWVkIEFDSy4gQUZBSUssIHNsb3ctc3RhcnQgc3RhZ2Ugd2lsbCBi ZWdpbiANCj4+IHdpdGggb25lIHBhY2tldCwgYW5kIHNlbmRlciB3aWxsIHNlbmQgdHdvIHBhY2tl dHMgYWZ0ZXIgaXQgcmVjZWl2ZXMgDQo+PiBhbiBBQ0suIElmIHRoZSBmaXJzdCBwYWNrZXQgaXMg b2JzdHJ1Y3RlZCBieSB0aGUgZGVsYXllZCBBQ0ssIHRoZSANCj4+IOKAmGNsb2NrIGFsZ29yaXRo beKAmSB3aWxsIGJlIGJyb2tlbiBkb3duLiBTbyByZWNlaXZlciBzaG91bGQganVkZ2UgaWYgDQo+ PiB0aGlzIHBhY2tldCBpcyB0aGUgZmlyc3Qgb25lIGluIHRoZSBzbG93LXN0YXJ0IHN0YWdlLCBp ZiB5ZXMsIHNlbmQgDQo+PiB0aGUgYWNrIGltbWVkaWF0ZWx5IG9uY2UgcmVjZWl2aW5nIHRoZSBw YWNrZXQuDQo+Pg0KPj4NCj4+DQo+PiBZYWxpDQo+Pg0KPj4NCj4+DQo+PiDlj5Hku7bkuro6IE5l YWwgQ2FyZHdlbGwgW21haWx0bzpuY2FyZHdlbGxAZ29vZ2xlLmNvbV0NCj4+IOWPkemAgeaXtumX tDogMjAxNuW5tDEy5pyIMTTml6UgMjE6MjQNCj4+IOaUtuS7tuS6ujogemhhbmd5YWxpIChEKSA8 emhhbmd5YWxpMzY5QGh1YXdlaS5jb20+DQo+PiDmioTpgIE6IHRjcG1AaWV0Zi5vcmcNCj4+IOS4 u+mimDogUmU6IOetlOWkjTogW3RjcG1dIEEgcXVlc3Rpb24gYWJvdXQgRGVsYXllZCBBQ0sgYW5k IFJUTw0KPj4NCj4+DQo+Pg0KPj4gT24gV2VkLCBEZWMgMTQsIDIwMTYgYXQgNDo0OCBBTSwgemhh bmd5YWxpIChEKSANCj4+IDx6aGFuZ3lhbGkzNjlAaHVhd2VpLmNvbT4NCj4+IHdyb3RlOg0KPj4N Cj4+IEhpIE5lYWwsDQo+Pg0KPj4NCj4+DQo+PiBUaGFua3MgZm9yIHlvdXIgcHJvdmlkaW5nIHJl cXVlc3QgaW5mb3JtYXRpb24uDQo+Pg0KPj4NCj4+DQo+PiBBYm91dCB0aGUgZGVsYXkgb2YgZGVs YXllZCBBQ0ssIEkgZm91bmQgYW5vdGhlciBjbHVlIGluIGEgU0lHQ09NTSANCj4+IHBhcGVyIGlu IDE5ODguIEluIHRoZSBwYWdlIDE0LCBhIHNlbnRlbmNlIGlzIOKAnFRoZSA0LjVLQnBzIHNlbmRl cnMgDQo+PiB3ZXJlIHRhbGtpbmcgdG8gNC4zQlNEIHJlY2VpdmVycyB3aGljaCB3b3VsZCBkZWxh eSBhbiBhY2sgdW50aWwgMzUlIA0KPj4gb2YgdGhlIHdpbmRvdyB3YXMgZmlsbGVkIG9yIDIwMCBt cyBoYWQgcGFzc2VkIChpLmUuLCBhbiBhY2sgd2FzIGRlbGF5ZWQgZm9yIDUtNyBwYWNrZXRzIG9u IGF2ZXJhZ2UpLuKAnQ0KPj4gVGhlcmUgaXMgbm8gcmVmZXJlbmNlIGFib3V0IHRoZSAyMDAgbXMs IHNvIEkgZ3Vlc3MgdGhpcyBpcyB0aGUgDQo+PiBwYXJ0aWN1bGFyIGRlbGF5IGFwcGVhcnMgZm9y IHRoZSBmaXJzdCB0aW1lLg0KPj4NCj4+IEkgdHJ5IHRvIGNhbGN1bGF0ZSB0aGUgdmFsdWUgYmFz ZWQgb24gZGVsYXllZCBwYWNrZXQgbnVtYmVycywgcGFja2V0IA0KPj4gc2l6ZSBhbmQgc2VuZGlu ZyByYXRlLiBJbiB0aGlzIGNhc2UsIHRoZSBkZWxheWVkIHBhY2tldCBudW1iZXIgaXMgNywgDQo+ PiB0aGUgcGFja2V0IHNpemUgaXMgNTc2Qnl0ZSAocmVmZXIgdG8gUkZDODc5IGluIDE5ODMpLCBh bmQgc3VuZGVyaW5nIA0KPj4gcmF0ZSBpcyA0LjVCcHMuIFRoZSB2YWx1ZSBpcyA4OTYgbXMhIExv bmdlciB0aGFuIDIwMCBtcy4NCj4+DQo+Pg0KPj4NCj4+PiAuIEhvd2V2ZXIsIGl0J3MgcXVpdGUg ZWFzeSBmb3IgYSBidWxrIHRyYW5zZmVyIHRvIG5ldmVyIGhhdmUgYW55IA0KPj4+IGRlbGF5ZWQg QUNLcyBmb3IgbW9zdCBvZiBpdHMgbGlmZXRpbWUsIGR1cmluZyB3aGljaCB0aGUgUlRPIA0KPj4+ IGdyYWR1YWxseSBjb252ZXJnZXMgdG93YXJkIHRoZSByYXcgUlRUIHZhbHVlLiBUaGVuIHdoZW4g dGhlcmUgaXMgDQo+Pj4gc3VkZGVubHkgYSBkZWxheWVkIEFDSywgdGhlcmUgY2FuIGJlIGEgc3B1 cmlvdXMgUlRPLg0KPj4NCj4+IEkgYW0gbm90IHZlcnkgc3VyZSBpZiBJIHNlZSB5b3VyIHBvaW50 LiBJIHRoaW5rIHRoZSBrZXkgcG9pbnQgaXMgdGhlIA0KPj4gUlRUIHZhcmlhdGlvbiB3aWxsIGJl IHdlYWtlbmVkIHdoZW4gcGFja2V0cyBhcmUgc2VudCBpbiBhIGJ1cnN0ICh0aGUgY29uc2VxdWVu Y2UNCj4+IG9mIGRlbGF5ZWQgQUNLKS4gICBBbmQgdGhlIHNwdXJpb3VzICBjb3VsZCBvbmx5IGhh cHBlbiBmb3IgdGhlIGxhc3QgZmV3DQo+PiBwYWNrZXRzIHdob3NlIG51bWJlciBpcyBzbWFsbGVy IHRoYW4gZGVsYXllZCBwYWNrZXRzLCByaWdodD8NCj4+DQo+Pg0KPj4NCj4+IFllcywgdGhlcmUg c2hvdWxkIG9ubHkgYmUgYSBkZWxheWVkIEFDSyBhdCB0aGUgZW5kIG9mIGFuIGFwcGxpY2F0aW9u IA0KPj4gY2h1bmsgaWYgdGhlcmUgaXMgYW4gb2RkIG51bWJlciBvZiBwYWNrZXRzLiBCdXQgd2Ug d291bGQgZXhwZWN0IA0KPj4gcm91Z2hseSBoYWxmIG9mIGFwcGxpY2F0aW9uIGNodW5rcyB0byBo YXZlIGFuIG9kZCBudW1iZXIgb2YgcGFja2V0cy4gDQo+PiBUaG91Z2ggdGhlIHByb3BvcnRpb24g aXMgcHJvYmFibHkgaGlnaGVyIHRoYW4gdGhhdCwgc2luY2UgbWFueSANCj4+IGFwcGxpY2F0aW9u IGNodW5rcyBhcmUganVzdCBvbmUgcGFja2V0IChlLmcuIGFuIEhUVFAgb3IgUlBDIHJlcXVlc3Qg b3IgcmVzcG9uc2UpLg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBBYm91dCB5b3VyIHByb3Bvc2Fs IGFib3V0IG5lZ290aWF0aW9uIG9mIGRlbGF5ZWQgQUNLLCBhIHBvdGVudGlhbCANCj4+IHByb2Js ZW0gaXMgdGhhdCBSVE8gd2lsbCBiZSBzdHJldGNoZWQgdGhhbiBiZWZvcmUgYmVjYXVzZSB5b3Ug YWRkIA0KPj4gZXh0cmEgZGVsYXkuIEFzIHlvdSBoYXZlIHNhaWQsIG1vc3Qgb2YgdGhlIHBhY2tl dHMgd2lsbCBub3QgZXhjZWVkIA0KPj4gUlRPIGV2ZW4gaG9zdCBlbmFibGUgZGVsYXllZCBBQ0sg Zm9yIG1vc3QgbGFyZ2UgZmxvd3MsIGJ1dCB0aGUgDQo+PiByZXRyYW5zbWlzc2lvbiB3aWxsIGJl IGRlbGF5ZWQgKGkuZS4sIDVtcylhbHNvIG9uY2Ugb25lIHBhY2tldCBpcyBsb3N0Lg0KPj4NCj4+ DQo+Pg0KPj4gVGhlIGJhc2ljIGlkZWEgb2YgdGhlIHByb3Bvc2FsIGlzIHRvIHR3ZWFrIHRoZSBS VE8gY2FsY3VsYXRpb24gYW5kIA0KPj4gdHVybiBhIHByZXZpb3VzbHkgZXhpc3RpbmcsIGhpc3Rv cmljYWxseSBtb3RpdmF0ZWQgMjAwbXMgZml4ZWQgInNsb3AgDQo+PiBmYWN0b3IiIGludG8gYSBk eW5hbWljYWxseSBuZWdvdGlhdGVkIDVtcyAic2xvcCBmYWN0b3IiLiBJbiBvdXIgDQo+PiBleHBl cmllbmNlIHRoYXQgaXMgYWxtb3N0IGFsd2F5cyBhIHdpbi4NCj4+DQo+Pg0KPj4NCj4+IG5lYWwN Cj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gQmVzdCwNCj4+DQo+PiBZYWxpDQo+Pg0KPj4g5Y+R5Lu2 5Lq6OiBOZWFsIENhcmR3ZWxsIFttYWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb21dDQo+PiDlj5Hp gIHml7bpl7Q6IDIwMTblubQxMuaciDEz5pelIDIzOjE4DQo+PiDmlLbku7bkuro6IHpoYW5neWFs aSAoRCkgPHpoYW5neWFsaTM2OUBodWF3ZWkuY29tPg0KPj4g5oqE6YCBOiB0Y3BtQGlldGYub3Jn DQo+PiDkuLvpopg6IFJlOiBbdGNwbV0gQSBxdWVzdGlvbiBhYm91dCBEZWxheWVkIEFDSyBhbmQg UlRPDQo+Pg0KPj4NCj4+DQo+PiBPbiBUdWUsIERlYyAxMywgMjAxNiBhdCAzOjU4IEFNLCB6aGFu Z3lhbGkgKEQpIA0KPj4gPHpoYW5neWFsaTM2OUBodWF3ZWkuY29tPg0KPj4gd3JvdGU6DQo+Pg0K Pj4gSGkgYWxsLA0KPj4NCj4+DQo+Pg0KPj4gUmVjZW50IGRheXMsIEkgYW0gZG9pbmcgc29tZSBz aW11bGF0aW9uIGFib3V0IFRDUCBwZXJmb3JtYW5jZSBpbiBOUzMuIA0KPj4gSSBmb3VuZCBhIHBo ZW5vbWVub24gaXMgYSBkZWZhdWx0IHNldHRpbmcgb2YgVENQ4oCZcyBkZWxheWVkIEFDSyBpcyB0 d28gDQo+PiBwYWNrZXRzIG9yIDIwMG1zLiBJIGFtIHdvbmRlcmluZyBpZiB0aGlzIHNldHRpbmcg aXMgYWNjb3JkIHdpdGggIHNvbWUgUkZDcyBpbiBJRVRGLg0KPj4gQnV0IEFmdGVyIEkgcmVmZXJy ZWQgdG8gc29tZSBSRkNzLCBJIGp1c3QgZm91bmQgc29tZSByZXN0cmljdGlvbnMsIA0KPj4gc3Vj aCBhcywgdGhlIGRlbGF5IG11c3QgYmUgbGVzcyB0aGFuIDAuNW1zIChSRkMxMTIyKS4NCj4+DQo+ Pg0KPj4NCj4+IEkgYmVsaWV2ZSB0aGUgMjAwbXMgZmlndXJlIGlzIGR1ZSB0byBoaXN0b3JpY2Fs IHJlYXNvbnMuIEFGQUlLIGl0J3MgDQo+PiBkdWUgdG8gdGhlIEJTRCBkZWxheWVkIEFDSyBiZWhh dmlvciAoc2VlIFN0ZXZlbnMgIlRDUC9JUCBJbGx1c3RyYXRlZCANCj4+IFZvbHVtZSAyIiwgc2Vj dGlvbiAyNS40IGFuZCBmaWd1cmUgMjUuNywgd2hpY2ggZGVzY3JpYmVzIHRoZSAyMDBtcyBkZWxh eWVkIEFDSyB0aW1lcikuDQo+PiBUaGVuIHRoaXMgdmFsdWUgd2FzIGluaGVyaXRlZCBieSBvdGhl ciB3aWRlbHktZGVwbG95ZWQgT1Nlcy4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gSSB0aGluayB0 aGUgZGVsYXllZCBBQ0sgaGFzIGEgY2xvc2UgcmVsYXRpb25zaGlwIHdpdGggUlRPLiBUYWtlIGFu IA0KPj4gZXh0cmVtZSBzY2VuYXJpbywgaWYgdGhlIGRlbGF5IGlzIGxvbmdlciB0aGFuIFJUTywg bWFueSBwYWNrZXRzIHdpbGwgDQo+PiBiZSByZXRyYW5zbWl0dGVkLCB3aGljaCB3aWxsIHdhc3Rl IG1hbnkgbmV0d29yayByZXNvdXJjZXMuDQo+Pg0KPj4NCj4+DQo+PiBZZXMsIGV4YWN0bHkuIElu IHRoZW9yeSwgdGhlIFJUTyB0cmllcyB0byBiZSBhZGFwdGl2ZSBlbm91Z2ggdG8gDQo+PiBtZWFz dXJlIGFueSBSVFQgdmFyaWF0aW9ucyBjYXVzZWQgYnkgZGVsYXllZCBBQ0tzLCBhbmQgaW5jcmVh c2UgdGhlIA0KPj4gUlRPIGluIHJlc3BvbnNlIHRvIHRoaXMuIEhvd2V2ZXIsIGl0J3MgcXVpdGUg ZWFzeSBmb3IgYSBidWxrIHRyYW5zZmVyIA0KPj4gdG8gbmV2ZXIgaGF2ZSBhbnkgZGVsYXllZCBB Q0tzIGZvciBtb3N0IG9mIGl0cyBsaWZldGltZSwgZHVyaW5nIHdoaWNoIA0KPj4gdGhlIFJUTyBn cmFkdWFsbHkgY29udmVyZ2VzIHRvd2FyZCB0aGUgcmF3IFJUVCB2YWx1ZS4gVGhlbiB3aGVuIHRo ZXJlIA0KPj4gaXMgc3VkZGVubHkgYSBkZWxheWVkIEFDSywgdGhlcmUgY2FuIGJlIGEgc3B1cmlv dXMgUlRPLg0KPj4NCj4+DQo+Pg0KPj4gVG8gYXZvaWQgdGhhdCwgbWFueSBUQ1Agc3RhY2tzIChh dCBsZWFzdCB0aGUgbWFqb3Igb3BlbiBzb3VyY2UgT1NlcykgDQo+PiBoYXZlIGEgaGFyZC1jb2Rl ZCAyMDBtcyAic2xvcCBmYWN0b3IiIG9yICJmdWRnZSBmYWN0b3IiLCB0byB0cnkgdG8gDQo+PiBu ZXZlciBsZXQgdGhlaXIgZXN0aW1hdGUgb2YgUlRUIHZhcmlhdGlvbiBmYWxsIGJlbG93IHRoYXQg MjAwbXMgdmFsdWUsIHRvIGF2b2lkIHRoaXMgZWZmZWN0Lg0KPj4NCj4+DQo+Pg0KPj4gU28gSSB3 YW50IHRvIGtub3cgZG8gd2UgaGF2ZSBzb21lIFJGQ3MgaGF2ZSBnaXZlbiB0aGUgZXhhY3QgdmFs dWUgb2YgYm90aD8NCj4+IEFuZCBpZiB3ZSBwZXJtaXQgYW55IFRDUCBzdGFjayB0byBzZXQgdGhl bSBmcmVlbHksIHdoYXQgaXMgdGhlIA0KPj4gbWVjaGFuaXNtIHRvIGJhbGFuY2UgdGhlIG1pc21h dGNoIGJldHdlZW4gUlRPIGFuZCBkZWxheWVkIEFDSz8NCj4+DQo+Pg0KPj4NCj4+IEknbSBub3Qg YXdhcmUgb2YgUkZDIHNwZWNpZmljYXRpb25zIGZvciBleGFjdCB2YWx1ZXMgb2YgYm90aCAoZGVs YXllZCANCj4+IEFDSyBhbmQgUlRPKS4gSG93ZXZlciwgdGhlIGhpc3RvcmljYWwgcHJlY2VkZW50 IGlzIHZlcnkgc3Ryb25nLCBhbmQgDQo+PiB0aGUgMjAwbXMgZGVsYXllZCBBQ0sgdmFsdWUgd2Fz IHZlcnkgcHJvbm91bmNlZCBpbiBJbnRlcm5ldCB0cmFjZXMgYXQgDQo+PiBsZWFzdCBhcyByZWNl bnRseSBhcyAyMDExLCB3aGVuIEkgbGFzdCBsb29rZWQgYXQgdGhlIGVmZmVjdC4gDQo+PiAoUHJv YmFibHkgb3RoZXJzIGhhdmUgbW9yZSByZWNlbnQgZGF0YSBwb2ludHMgZm9yIHRoZSBwcmV2YWxl bmNlIG9mIA0KPj4gMjAwbXMgZGVsYXllZCBBQ0tzLikNCj4+DQo+Pg0KPj4NCj4+IEF0IElFVEYg OTcgb3VyIHRlYW0gYXQgR29vZ2xlIHByZXNlbnRlZCBzb21lIGZlYXR1cmVzIHdlIHVzZSBmb3Ig DQo+PiBpbnRlcm5hbCBUQ1AgdHJhZmZpYyBhdCBHb29nbGUsIHdoZXJlIHRoZSBlbmRwb2ludHMg Y2FuIG5lZ290aWF0ZSB0aGUgDQo+PiBzcGVjaWZpYyBjb25zdGFudCB0byB1c2UgZm9yIHRoZSBt YXhpbXVtIGRlbGF5ZWQgQUNLIGZyb20gdGhlIA0KPj4gcmVjZWl2ZXIgYW5kIHRoZSBjb3JyZXNw b25kaW5nIG1pbmltdW0gUlRUIGRlbGF5IHZhcmlhdGlvbiBmb3IgDQo+PiBidWRnZXRpbmcgaW4g dGhlIFJUTyBhdCB0aGUNCj4+IHNlbmRlcjoNCj4+DQo+Pg0KPj4NCj4+DQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9zbGlkZXMvc2xpZGVzLTk3LXRjcG0tdGNwLW9wdGlv bnMNCj4+IC1mb3ItbG93LWxhdGVuY3ktMDAucGRmDQo+Pg0KPj4NCj4+DQo+PiBBcyB0aGlzIHNs aWRlIGRlY2sgbm90ZXMsIHdpdGhpbiBHb29nbGUgd2UgbmVnb3RpYXRlIDVtcyBmb3IgZGVsYXll ZCBBQ0tzLg0KPj4NCj4+DQo+Pg0KPj4gY2hlZXJzLA0KPj4NCj4+IG5lYWwNCj4+DQo+Pg0KPj4N Cj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiB0Y3BtIG1haWxpbmcgbGlzdA0KPj4gdGNwbUBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo+Pg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0Y3BtIG1haWxpbmcgbGlz dA0KPiB0Y3BtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGNwbQ0KPg0KDQo= From nobody Fri Dec 16 00:16:55 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17B91294F0 for ; Fri, 16 Dec 2016 00:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0VXyB_10U0j for ; Fri, 16 Dec 2016 00:16:50 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 556DB1294DF for ; Fri, 16 Dec 2016 00:16:49 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 0FF581B00219; Fri, 16 Dec 2016 10:14:21 +0000 (GMT) Message-ID: <5853A2C9.4050001@erg.abdn.ac.uk> Date: Fri, 16 Dec 2016 08:16:09 +0000 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "zhangyali (D)" References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiAg562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBx?= =?utf-8?q?uestion_about_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 08:16:54 -0000 On 16/12/2016 07:47, zhangyali (D) wrote: > I identify with your distinction function of RTO. I really agree that we should differentiate the effect caused by network congestion or path failure, and take different actions, such as, more aggressive action to the second cases. But now, we just have RTO as the last method to retransmission the segment that is lost or just be delayed if we do not have extra segments or window to trigger dupack. So another retansmission detection method faster than timeout and more effective should be thinked about. > > Yali On this I also agree - Tail Loss has become a problem for latency-sensitive shorter traffic bursts, amd we need widely deployed mechanisms to deal with this. There have been proposals in TCPM to add mechanisms that would help and this seems worth looking at. Gorry > -----邮件原件----- > 发件人: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > 发é€ć—¶é—´: 2016ĺą´12ćś15ć—Ą 18:21 > 收件人: Yoshifumi Nishida; zhangyali (D) > 抄é€: tcpm@ietf.org > 主é˘: Re: [tcpm] 答复: 答复: 答复: A question about Delayed ACK and RTO > > > Just adding a few more comments here, because there has been much talk about how desirable it is for the RTO to converge to the RTT, and I think we need to be clear. > > The TCP RTO has two distinct functions: > > (1) the RTO is of course the method of last resort for the recovery of a lost segment (the final segment of a burst, following persistent loss, etc). > > (2) Second the RTO is method to detect a path failure - where something has changed significantly. As such, triggering a conservative (1 or 3 > seconds) RTO implies that state about the path needs to be reset (RTT, perhaps invoking PMTUD, congestion state variables, etc, possibly in the future falling back from using ECN, etc) > > For the first function, there are many ways to detect lost segments (Dupacks, probe packets, recovery timers, etc). All of these act faster than a conservatively set timeout. They also do not need to erase collected path state, they can simply re-transmit the lost segments. > > An RTO close to the RTT will be disastrous for some paths. This is one of the reasons why people have deployed PEPs to support radio technology > - we should not be encouraging this. An RTO set close to the RTT can produce complex interactions when the path characteristics change (which does happen with propagation impairments and radio resource management, on wireless, microwave satellite and other paths, and also with middleboxes that attempt to control capacity/volume usage). This type of path is not going away, talk of wireless links with top speeds of Gbps for 5G will likely be accompanied by very large variation in path characteristics - at the other extreme people in large parts of the world are still with kbps technology. If the timer only recovers packets, it would simply result in retransmission, if it triggers other probing that would be unfortunate. I think the IETF needs to ensure our specs work for all people. > > What I am saying is that the second function does not need a timeout period near the RTT. Robust protocols have been designed to have a conservative RTO timer that is set to much more than a RTT, designed to detect an unresponsive endpoint or path problem. The IETF has argued - and to my knowledge still argues that Min_RTO should be one second, which I think reflects this position. If the loss recovery is efficient, this will trigger only infrequently (e.g., persistent loss of one packet). I think this is the correct way to design TCP. It motivates that we should actually strive for a one second (or so) RTO. > > Gorry > > > On 15/12/2016 08:24, Yoshifumi Nishida wrote: >> A question would be when TCP sent odd number of packets, how it can >> know whether another packets will come from upper layer very soon or >> not. Also, I'm not very sure yet if the probability is so obvious. I >> can agree that RTO can get close to raw rtt value under bulk transfer. >> But, I am guessing not so many apps change the behavior from bulk >> transfer to spontaneous small burst transfer. >> -- >> Yoshi >> >> >> On Wed, Dec 14, 2016 at 7:08 PM, zhangyali (D) wrote: >>> Please allow me to add one more point. If the probability of odd >>> number of packets occurring spurious RTO is so outstanding, why >>> nobody try to solve this problem? >>> >>> >>> >>> 发件人: tcpm [mailto:tcpm-bounces@ietf.org] 代表 zhangyali (D) >>> 发é€ć—¶é—´: 2016ĺą´12ćś15ć—Ą 9:45 >>> 收件人: Neal Cardwell >>> 抄é€: tcpm@ietf.org >>> 主é˘: [tcpm] 答复: 答复: A question about Delayed ACK and RTO >>> >>> >>> >>>> Yes, there should only be a delayed ACK at the end of an application >>>> chunk if there is an odd number of packets. But we would expect >>>> roughly half of application chunks to have an odd number of packets. >>>> Though the proportion is probably higher than that, since many >>>> application chunks are just one packet (e.g. an HTTP or RPC request or response). >>> >>> >>> I agree with you that odd number of packets may occur spurious RTO >>> more easily, but I think for the flows owning just one packet should >>> not be affected by delayed ACK. AFAIK, slow-start stage will begin >>> with one packet, and sender will send two packets after it receives >>> an ACK. If the first packet is obstructed by the delayed ACK, the >>> â€clock algorithm’ will be broken down. So receiver should judge if >>> this packet is the first one in the slow-start stage, if yes, send >>> the ack immediately once receiving the packet. >>> >>> >>> >>> Yali >>> >>> >>> >>> 发件人: Neal Cardwell [mailto:ncardwell@google.com] >>> 发é€ć—¶é—´: 2016ĺą´12ćś14ć—Ą 21:24 >>> 收件人: zhangyali (D) >>> 抄é€: tcpm@ietf.org >>> 主é˘: Re: 答复: [tcpm] A question about Delayed ACK and RTO >>> >>> >>> >>> On Wed, Dec 14, 2016 at 4:48 AM, zhangyali (D) >>> >>> wrote: >>> >>> Hi Neal, >>> >>> >>> >>> Thanks for your providing request information. >>> >>> >>> >>> About the delay of delayed ACK, I found another clue in a SIGCOMM >>> paper in 1988. In the page 14, a sentence is “The 4.5KBps senders >>> were talking to 4.3BSD receivers which would delay an ack until 35% >>> of the window was filled or 200 ms had passed (i.e., an ack was delayed for 5-7 packets on average).” >>> There is no reference about the 200 ms, so I guess this is the >>> particular delay appears for the first time. >>> >>> I try to calculate the value based on delayed packet numbers, packet >>> size and sending rate. In this case, the delayed packet number is 7, >>> the packet size is 576Byte (refer to RFC879 in 1983), and sundering >>> rate is 4.5Bps. The value is 896 ms! Longer than 200 ms. >>> >>> >>> >>>> . However, it's quite easy for a bulk transfer to never have any >>>> delayed ACKs for most of its lifetime, during which the RTO >>>> gradually converges toward the raw RTT value. Then when there is >>>> suddenly a delayed ACK, there can be a spurious RTO. >>> I am not very sure if I see your point. I think the key point is the >>> RTT variation will be weakened when packets are sent in a burst (the consequence >>> of delayed ACK). And the spurious could only happen for the last few >>> packets whose number is smaller than delayed packets, right? >>> >>> >>> >>> Yes, there should only be a delayed ACK at the end of an application >>> chunk if there is an odd number of packets. But we would expect >>> roughly half of application chunks to have an odd number of packets. >>> Though the proportion is probably higher than that, since many >>> application chunks are just one packet (e.g. an HTTP or RPC request or response). >>> >>> >>> >>> >>> >>> About your proposal about negotiation of delayed ACK, a potential >>> problem is that RTO will be stretched than before because you add >>> extra delay. As you have said, most of the packets will not exceed >>> RTO even host enable delayed ACK for most large flows, but the >>> retransmission will be delayed (i.e., 5ms)also once one packet is lost. >>> >>> >>> >>> The basic idea of the proposal is to tweak the RTO calculation and >>> turn a previously existing, historically motivated 200ms fixed "slop >>> factor" into a dynamically negotiated 5ms "slop factor". In our >>> experience that is almost always a win. >>> >>> >>> >>> neal >>> >>> >>> >>> >>> >>> Best, >>> >>> Yali >>> >>> 发件人: Neal Cardwell [mailto:ncardwell@google.com] >>> 发é€ć—¶é—´: 2016ĺą´12ćś13ć—Ą 23:18 >>> 收件人: zhangyali (D) >>> 抄é€: tcpm@ietf.org >>> 主é˘: Re: [tcpm] A question about Delayed ACK and RTO >>> >>> >>> >>> On Tue, Dec 13, 2016 at 3:58 AM, zhangyali (D) >>> >>> wrote: >>> >>> Hi all, >>> >>> >>> >>> Recent days, I am doing some simulation about TCP performance in NS3. >>> I found a phenomenon is a default setting of TCP’s delayed ACK is two >>> packets or 200ms. I am wondering if this setting is accord with some RFCs in IETF. >>> But After I referred to some RFCs, I just found some restrictions, >>> such as, the delay must be less than 0.5ms (RFC1122). >>> >>> >>> >>> I believe the 200ms figure is due to historical reasons. AFAIK it's >>> due to the BSD delayed ACK behavior (see Stevens "TCP/IP Illustrated >>> Volume 2", section 25.4 and figure 25.7, which describes the 200ms delayed ACK timer). >>> Then this value was inherited by other widely-deployed OSes. >>> >>> >>> >>> >>> >>> I think the delayed ACK has a close relationship with RTO. Take an >>> extreme scenario, if the delay is longer than RTO, many packets will >>> be retransmitted, which will waste many network resources. >>> >>> >>> >>> Yes, exactly. In theory, the RTO tries to be adaptive enough to >>> measure any RTT variations caused by delayed ACKs, and increase the >>> RTO in response to this. However, it's quite easy for a bulk transfer >>> to never have any delayed ACKs for most of its lifetime, during which >>> the RTO gradually converges toward the raw RTT value. Then when there >>> is suddenly a delayed ACK, there can be a spurious RTO. >>> >>> >>> >>> To avoid that, many TCP stacks (at least the major open source OSes) >>> have a hard-coded 200ms "slop factor" or "fudge factor", to try to >>> never let their estimate of RTT variation fall below that 200ms value, to avoid this effect. >>> >>> >>> >>> So I want to know do we have some RFCs have given the exact value of both? >>> And if we permit any TCP stack to set them freely, what is the >>> mechanism to balance the mismatch between RTO and delayed ACK? >>> >>> >>> >>> I'm not aware of RFC specifications for exact values of both (delayed >>> ACK and RTO). However, the historical precedent is very strong, and >>> the 200ms delayed ACK value was very pronounced in Internet traces at >>> least as recently as 2011, when I last looked at the effect. >>> (Probably others have more recent data points for the prevalence of >>> 200ms delayed ACKs.) >>> >>> >>> >>> At IETF 97 our team at Google presented some features we use for >>> internal TCP traffic at Google, where the endpoints can negotiate the >>> specific constant to use for the maximum delayed ACK from the >>> receiver and the corresponding minimum RTT delay variation for >>> budgeting in the RTO at the >>> sender: >>> >>> >>> >>> >>> https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options >>> -for-low-latency-00.pdf >>> >>> >>> >>> As this slide deck notes, within Google we negotiate 5ms for delayed ACKs. >>> >>> >>> >>> cheers, >>> >>> neal >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 nobody Fri Dec 16 04:53:01 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E13129D0E for ; Fri, 16 Dec 2016 04:53:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148189278022.8392.11514072396223415735.idtracker@ietfa.amsl.com> Date: Fri, 16 Dec 2016 04:53:00 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 12:53:00 -0000 Changed milestone "Submit document on a time-based fast loss detection algorithm for TCP to the IESG for publication as an Experimental RFC", added draft-ietf-tcpm-rack to milestone. URL: https://datatracker.ietf.org/wg/tcpm/charter/ From nobody Fri Dec 16 06:06:56 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF12129D21 for ; Fri, 16 Dec 2016 06:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK-UCuEBnwdl for ; Fri, 16 Dec 2016 06:06:51 -0800 (PST) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401B2129A6F for ; Fri, 16 Dec 2016 06:06:43 -0800 (PST) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id uBGDCAV6019449; Fri, 16 Dec 2016 07:12:11 -0600 (CST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: David Borman In-Reply-To: Date: Fri, 16 Dec 2016 08:06:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <47FF18FE-34E6-479D-8B89-430390D15EC3@weston.borman.com> References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> <45f0034f-70a2-2aa3-d87b-c7288a51ad77@isi.edu> <48aa99d0-113e-edda-94f7-48d81bea59fd@palermo.edu> To: Joe Touch X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh?= =?utf-8?q?bout_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 14:06:53 -0000 > On Dec 15, 2016, at 7:59 PM, Joe Touch wrote: >=20 >=20 >=20 > On 12/15/2016 5:13 PM, Praveen Balasubramanian wrote: >> FWIW the windows TCP implementation preserves the notion of = application send() message boundary by setting the PSH bit only on the = last segment generated from the posted buffer. Other TCP implementations have done the same thing for decades. > TCP isn't required to allow the app to decide when to set the PSH bit > (it's a MAY in the SEND call). It can coalesce multiple PSH bits to = send > a larger segment. >=20 > However, it's also explicitly not a record boundary. PUSH is really = just > to avoid deadlock between the app and TCP on the send side. The PUSH bit is a way for the sending TCP to signal the receiving TCP = that no more data is coming, and so if the receiving TCP is buffering = data and has not yet made it available to the receiving application, it = should now make all that data available to be read. These days this = doesn=E2=80=99t matter as much, because TCP stacks make all received = data immediately available to the receiving application. But senders = should continue to set the PUSH bit. -David Borman >> Unfortunately other stacks seem to set PSH on all segments making any = receiver optimization of immediate ACK on PSH impossible, because that = would effectively turn off delayed ACKs. That said, with ACK stretching, = LRO etc. being very common maybe it is time for TCP implementations to = turn off delayed ACKs across the board except for request-response = applications. >=20 > There are many ways this could be fixed but they all require going > outside the current spec. >=20 > Joe >=20 >>=20 >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Alejandro = Popovsky >> Sent: Thursday, December 15, 2016 3:13 PM >> To: Joe Touch ; tcpm@ietf.org >> Subject: Re: [tcpm] =E7=AD=94=E5=A4=8D: =E7=AD=94=E5=A4=8D: =E7=AD=94=E5= =A4=8D: A question about Delayed ACK and RTO >>=20 >> On the second option (no more data to send) there would be no need to = change the API. The tcp sender tcp would generate the signal = automatically with the last segment. And the receiver could just use the = info to adjust the delay ack timer for that segment. >>=20 >> And in order for the extra ack not to produce an extra cwnd growth = the sender should follow the recommendation of rfc5681, page 6. >>=20 >> Alejandro. >>=20 >> On 15/12/2016 12:29 p. m., Joe Touch wrote: >>> On 12/15/2016 3:25 AM, Alejandro Popovsky wrote: >>>> Tcp would benefit much from and 'end of app write call' signal or = may=20 >>>> be 'end of sender buffer data' signal. >>> In the current TCP API, there is absolutely no correlation between=20= >>> app SEND calls and any notion TCP might have of boundaries - TCP=20 >>> presents a bytestream service only. There would be many consequences=20= >>> to changing that API, but it might be useful to note that this was = once considered. >>> Just two days ago, Bob Braden and I were discussing TCP v3 (before = the=20 >>> current one - as documented in IEN 21), which did have this sort = of=20 >>> signal, but it was carried into the packet as begin/end (of = "letter") flags. >>>=20 >>> Note that his behavior is a consequence of the interaction between=20= >>> delayed ACKs and a lack of application data, and happens any time = the=20 >>> app layer "starves" TCP. It was well studied in the 90's in its=20 >>> interaction with persistent web connections. It isn't really related=20= >>> to RTO per se. >>>=20 >>> Joe >>>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From dciliske@netburner.com Thu Dec 15 13:52:58 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B3512946E for ; Thu, 15 Dec 2016 13:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netburner-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS0RS6n0OiTB for ; Thu, 15 Dec 2016 13:52:56 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B55129482 for ; Thu, 15 Dec 2016 13:52:56 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id d2so10572236pfd.0 for ; Thu, 15 Dec 2016 13:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netburner-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=9gux+D73FrE8gW5OfaVlJUd6i52rfcw9T2K44Yj/Cjc=; b=PkJjqMTM6/EJoE6cntS0mYjWDzMwtkKOZgM4amqPrSwyBWORe8cjqCMrhOqfwTW37W ELAjCq0aM0Q5J85ov6Na6CF79yKoiiz0fzILfaZ47/9dUM4f+CfLnxLjWCiue0CExcmW iYpzM7qfyQYwdClCzDbEulw4XLU2NudLf0jB5IxsyhsHFnR2tO6YnQd+mHsCn5L66FAh Oi/EZ0IwXR+wtzswlkOaFIeuc6QWZnsu8jYJKqjOvWWnItc9AJqNlU5pCxYkxuY5XUBb 2dD6sC5ojiHJ3CGJYwUUxpilHBCpnFA0tpvHSiRF7W8QHUb+LVvxP5fBMt9e6GM4NkZm pGzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=9gux+D73FrE8gW5OfaVlJUd6i52rfcw9T2K44Yj/Cjc=; b=cvgu7XroBOUV1VDBrxHGegGAHWMWOTtBnrLHK8vzszv0pjUneUa9VjcLbCWp2wSTEa n8QMRMIUacZlphMmlcDQVN6NMqCpgZZv6Nwzs0Tzl43YfMRPvt6Ap/kJARE/eGgJgz0y DQcCET5BCwexh/RUvx59V7vhUiyqC2BG2UpimB+m3ozhXs9C2Js6zBHoOy3VsJurfdku /ioYVK47DmbZfg5tYX/rjuJJLyhlO7MF1pAjTg1vryqNx+60+W/ZobqZGFuvWADyxZgh pQIfOIOoxEHuIy4eJ8YL7UaCnKfXY6Mccp6+mtWhmc4dvAS2d0VKHhUI9mYLVFMwpcq/ KXCg== X-Gm-Message-State: AKaTC01tK0m1qbxkAH9XPcRgkKhMZN+nDXk9jYxqh/gZAbzCI/uW7IMQf8DUdlFkvSJAzPzS X-Received: by 10.98.138.72 with SMTP id y69mr4513155pfd.52.1481838775924; Thu, 15 Dec 2016 13:52:55 -0800 (PST) Received: from [10.2.0.69] (c-76-28-228-11.hsd1.wa.comcast.net. [76.28.228.11]) by smtp.gmail.com with ESMTPSA id y200sm6696963pfb.16.2016.12.15.13.52.55 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Dec 2016 13:52:55 -0800 (PST) From: Dan Ciliske Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 15 Dec 2016 13:52:54 -0800 To: tcpm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Fri, 16 Dec 2016 08:02:12 -0800 Subject: [tcpm] Fast retransmit of Zero Window Probes with 1 byte X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 15 Dec 2016 21:59:05 -0000 I appear to have run into either an edge case or ambiguity between RFC = 793 and 5681 SHOULDs and MUSTs where the sending TCP stack chooses to = implement Zero Window Probing by sending 1 byte packets. Error scenario = is as follows: No. Time Source Destination Info 1 0.000000 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D1 Ack=3D1 = Win=3D4644 Len=3D1460 2 0.000853 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D1461 Ack=3D1 = Win=3D4644 Len=3D1460 3 0.000855 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D2921 Ack=3D1 = Win=3D4644 Len=3D1460 4 0.000855 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D4381 Ack=3D1 = Win=3D4644 Len=3D264 5 0.000856 10.1.1.56 10.1.1.62 [ACK] Seq=3D1 Ack=3D1461 = Win=3D3184 Len=3D0 6 0.000856 10.1.1.56 10.1.1.62 [ACK] Seq=3D1 Ack=3D2921 = Win=3D1724 Len=3D0 7 0.002107 10.1.1.56 10.1.1.62 [ACK] Seq=3D1 Ack=3D4381 = Win=3D264 Len=3D0 8 0.002107 10.1.1.56 10.1.1.62 [TCP ZeroWindow] [ACK] Seq=3D1 = Ack=3D4645 Win=3D0 Len=3D0 9 4.966264 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, = ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 10 4.966265 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] [TCP = ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 11 5.465671 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, = ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 12 5.466429 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] [TCP = ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 13 6.465684 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, = ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 14 6.466442 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] [TCP = ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 15 6.466443 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, = ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 16 6.466443 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] [TCP = ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 ... 1-4. Sender Sends final data that fills RWND. 5-8. Receiver Sends ACK for SND.UNA. Receiver fails to respond in a = timely manner with an increased window size. 9. Sender Sends Zero Window Probe with 1 byte, increasing SND.UNA by = one. 10. Receiver responds with ACK for SND.UNA-1 and RWND of 0. This is the = first Duplicate ACK. 11. After delaying, Sender Resends the ZWP. 12. Receiver Responds with ACK for SND.UNA-1 and RWND of 0. This is the = second Duplicate ACK. 13. After delaying, Sender Resends the ZWD. 14. Receiver Responds with ACK for SND.UNA-1 and a RWND of 0. This is = the third Duplicate ACK. 15. In response to three duplicate ACKs, the Sender now enters Fast = Retransmission for the dropped packet, aka the ZWP. 15+. The Sender will respond to all ACKs from the Receiver with a = retransmission of the Zero Window Probe due to Fast Retransmission. 16+. The Receiver will respond to all Probes with ACK for SND.UNA-1 and = a RWND of 0, until it=E2=80=99s user application reads the data. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 On a fast network (i.e. LAN), and a slow receiver (i.e. an embedded = device), this becomes a Denial of Service as the receiver ends up = spending all its resources ACKing the Probes instead of reading from the = socket. Suggested change, in RFC 5681: Section 3.2, paragraph 2 says: The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (as = defined in section 2, without any intervening ACKs which move SND.UNA) as an indication that a segment has been lost. After receiving 3 = duplicate ACKs, TCP performs a retransmission of what appears to be the = missing segment, without waiting for the retransmission timer to expire. It should say: The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (as = defined in section 2, without any intervening ACKs which move SND.UNA) as an indication that a segment has been lost. After receiving 3 = duplicate ACKs, TCP performs a retransmission of what appears to be the = missing segment, without waiting for the retransmission timer to expire.=20 However, if all transmitted data from the sender has been = acknowledged, the duplicate ACKs are in response to a Zero Window Probe, AND the advertised window is still zero, then the TCP sender MUST NOT = consider these to be duplicate ACKs in relation to the fast retransmit = algorithm. -Dan= From nobody Fri Dec 16 08:48:18 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0884D129A56 for ; Fri, 16 Dec 2016 08:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbo2p68gnO4m for ; Fri, 16 Dec 2016 08:48:14 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE4B1298D5 for ; Fri, 16 Dec 2016 08:48:14 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBGGlkJW009889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 16 Dec 2016 08:47:47 -0800 (PST) To: David Borman References: <0a234a82-5333-e3f7-cfa9-812d93144c54@erg.abdn.ac.uk> <45f0034f-70a2-2aa3-d87b-c7288a51ad77@isi.edu> <48aa99d0-113e-edda-94f7-48d81bea59fd@palermo.edu> <47FF18FE-34E6-479D-8B89-430390D15EC3@weston.borman.com> From: Joe Touch Message-ID: <8e25a683-3f41-556b-70fe-1ddb292c98c8@isi.edu> Date: Fri, 16 Dec 2016 08:47:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <47FF18FE-34E6-479D-8B89-430390D15EC3@weston.borman.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogQSBxdWVzdGlvbiBh?= =?utf-8?q?bout_Delayed_ACK_and_RTO?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 16:48:16 -0000 On 12/16/2016 6:06 AM, David Borman wrote: >> On Dec 15, 2016, at 7:59 PM, Joe Touch wrote: >> >> >> >> On 12/15/2016 5:13 PM, Praveen Balasubramanian wrote: >>> FWIW the windows TCP implementation preserves the notion of application send() message boundary by setting the PSH bit only on the last segment generated from the posted buffer. > Other TCP implementations have done the same thing for decades. RFC793 states that the PSH bit is independent of segment boundaries. Both it and RFC1122 indicate that the send() call MAY support setting that flag and give provisions for what to do when that flag is not supported. However, we can't simply assume that this means "last segment generated". It means only "last segment in this group" as part of an interactive transfer. There could be another group following it immediately. > >> TCP isn't required to allow the app to decide when to set the PSH bit >> (it's a MAY in the SEND call). It can coalesce multiple PSH bits to send >> a larger segment. >> >> However, it's also explicitly not a record boundary. PUSH is really just >> to avoid deadlock between the app and TCP on the send side. > The PUSH bit is a way for the sending TCP to signal the receiving TCP that no more data is coming, as part of this "group" only. There's no rule that a PSH means that the sending app has paused at all. > and so if the receiving TCP is buffering data and has not yet made it available to the receiving application, it should now make all that data available to be read. RIght - push this through as a group. This is about when to avoid delays to the receiving app. It's not useful as a signal to override delayed ACKs because it doesn't require the sender to pause. > These days this doesn’t matter as much, because TCP stacks make all received data immediately available to the receiving application. But senders should continue to set the PUSH bit. The conditions under which they need to do this are spec'd in RFC1122. Applications can't assume access via the send() call, so they shouldn't design their apps with this assumption. Joe From nobody Fri Dec 16 09:48:22 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FD7129B60 for ; Fri, 16 Dec 2016 09:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yg8OfIdJh75n for ; Fri, 16 Dec 2016 09:48:18 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C970F129B08 for ; Fri, 16 Dec 2016 09:48:17 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id b126so85286805oia.2 for ; Fri, 16 Dec 2016 09:48:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1JvfQoSqqkqD4QPfs6S+A2/gNdzT8VAdnEYD12tfPCM=; b=ggKK13s1/q3iyOjniRvUaIoZgWbNlpEVODxffMYI9X0k9WGbEsTL8t/MgWLcdLgV8b G4rVSaLyq/MI2WZ+lQlL5Hw/WVZp50WdobjIEvQSt336tpcB3slVpe6ADI4WEfnetm4l jzHfrFfwPTzemoFslVfbJmBnTCrgGkubqXCjVdEnqUsv0eLbwTyvXZG2WqIWHbPiyvcp qxpbERQsMCBZexMGJ2BYtXOYs9+tirI2Oip6K+85GjDFfG+qtaM/hpicVLXOKTwVhLcd 6OraPJvfsgwXceYh22IKzshy0DoJm+i8zZlt59tVD9gmqwlqtyrzS3a5nYeaP00aOl2p JGMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1JvfQoSqqkqD4QPfs6S+A2/gNdzT8VAdnEYD12tfPCM=; b=ioPetH6UgEyi5PlhgVX9giG7QVa30ygBBvy3LxaTu1HS5eqV3hFOA52CTQJ1HCiUak sbZxdelm50OxMODgXq7hqYy1k4yHMkTwMhR+ZLdhd1Pj4W51oU4H4Djv7YNZPGheEI+t ip1Wvz/hb0ZSzNGbQDFgk6aGzTYk6mGY4CdHwMN7da83Y9eFcNKzpxz85av8xGlmyaHa odcwTJYxuZOMlKafmq1W2Csses2j6wrlHmASKCv7tK7d8C9m8jXoW6CiSeFVmicppE8V CgdkFbb8dQDXgI3sM2DdWLeS96eCLqE/CskqCMzad1YBll+pfSW1mUgw6vkrsPqTrtTy Amag== X-Gm-Message-State: AIkVDXKzAKZJpzCmYl24wKnpCva0jgiOiBbUPa4GWkR/jywv9SEPe7nnuH9MeRoNgPxHJQdiN+xlNOB1mt/CTKaV X-Received: by 10.202.236.130 with SMTP id k124mr2382044oih.83.1481910497007; Fri, 16 Dec 2016 09:48:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.240.213 with HTTP; Fri, 16 Dec 2016 09:47:46 -0800 (PST) In-Reply-To: References: From: Neal Cardwell Date: Fri, 16 Dec 2016 12:47:46 -0500 Message-ID: To: Dan Ciliske Content-Type: multipart/alternative; boundary=001a1137c88ec3ab5d0543ca2cf5 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fast retransmit of Zero Window Probes with 1 byte X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 17:48:20 -0000 --001a1137c88ec3ab5d0543ca2cf5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good point. The RFC does seem unclear on that. The BSD code (tcp_input.c or Figure 29.3 in Stevens volume 2) is pretty clear about simply not treating a window probe as "outstanding data": * If we have outstanding data (other than * a window probe), ... So one option would be to go with that approach, and clarify in the definition of a dupack that a window probe does not count as outstanding data: So the existing RFC 5681 text: DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a "duplicate" in the following algorithms when (a) the receiver of the ACK has outstanding data, could be: DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a "duplicate" in the following algorithms when (a) the receiver of the ACK has outstanding data (other than a window probe), Do you mind sharing which TCP implementation was running on the sender in the scenario you describe? I haven't been able to reproduce that behavior on Linux, and BSD doesn't seem like it would be susceptible. Just curious. neal On Thu, Dec 15, 2016 at 4:52 PM, Dan Ciliske wrote= : > I appear to have run into either an edge case or ambiguity between RFC 79= 3 > and 5681 SHOULDs and MUSTs where the sending TCP stack chooses to impleme= nt > Zero Window Probing by sending 1 byte packets. Error scenario is as follo= ws: > > No. Time Source Destination Info > 1 0.000000 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D1 Ack=3D1 Win= =3D4644 > Len=3D1460 > 2 0.000853 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D1461 Ack=3D1 > Win=3D4644 Len=3D1460 > 3 0.000855 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D2921 Ack=3D1 > Win=3D4644 Len=3D1460 > 4 0.000855 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D4381 Ack=3D1 > Win=3D4644 Len=3D264 > 5 0.000856 10.1.1.56 10.1.1.62 [ACK] Seq=3D1 Ack=3D1461 Win=3D= 3184 > Len=3D0 > 6 0.000856 10.1.1.56 10.1.1.62 [ACK] Seq=3D1 Ack=3D2921 Win=3D= 1724 > Len=3D0 > 7 0.002107 10.1.1.56 10.1.1.62 [ACK] Seq=3D1 Ack=3D4381 Win=3D= 264 > Len=3D0 > 8 0.002107 10.1.1.56 10.1.1.62 [TCP ZeroWindow] [ACK] Seq=3D1 > Ack=3D4645 Win=3D0 Len=3D0 > > 9 4.966264 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, ACK= ] > Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 > 10 4.966265 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] [TCP > ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 > > 11 5.465671 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, ACK= ] > Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 > 12 5.466429 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] [TCP > ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 > > 13 6.465684 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, ACK= ] > Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 > 14 6.466442 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] [TCP > ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 > 15 6.466443 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, ACK= ] > Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 > 16 6.466443 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] [TCP > ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 > ... > > 1-4. Sender Sends final data that fills RWND. > 5-8. Receiver Sends ACK for SND.UNA. Receiver fails to respond in a timel= y > manner with an increased window size. > 9. Sender Sends Zero Window Probe with 1 byte, increasing SND.UNA by one. > 10. Receiver responds with ACK for SND.UNA-1 and RWND of 0. This is the > first Duplicate ACK. > 11. After delaying, Sender Resends the ZWP. > 12. Receiver Responds with ACK for SND.UNA-1 and RWND of 0. This is the > second Duplicate ACK. > 13. After delaying, Sender Resends the ZWD. > 14. Receiver Responds with ACK for SND.UNA-1 and a RWND of 0. This is the > third Duplicate ACK. > 15. In response to three duplicate ACKs, the Sender now enters Fast > Retransmission for the dropped packet, aka the ZWP. > > 15+. The Sender will respond to all ACKs from the Receiver with a > retransmission of the Zero Window Probe due to Fast Retransmission. > 16+. The Receiver will respond to all Probes with ACK for SND.UNA-1 and a > RWND of 0, until it=E2=80=99s user application reads the data. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > On a fast network (i.e. LAN), and a slow receiver (i.e. an embedded > device), this becomes a Denial of Service as the receiver ends up spendin= g > all its resources ACKing the Probes instead of reading from the socket. > > Suggested change, in RFC 5681: > Section 3.2, paragraph 2 says: > The TCP sender SHOULD use the "fast retransmit" algorithm to detect > and repair loss, based on incoming duplicate ACKs. The fast > retransmit algorithm uses the arrival of 3 duplicate ACKs (as defined > in section 2, without any intervening ACKs which move SND.UNA) as an > indication that a segment has been lost. After receiving 3 duplicate > ACKs, TCP performs a retransmission of what appears to be the missing > segment, without waiting for the retransmission timer to expire. > > It should say: > The TCP sender SHOULD use the "fast retransmit" algorithm to detect > and repair loss, based on incoming duplicate ACKs. The fast > retransmit algorithm uses the arrival of 3 duplicate ACKs (as defined > in section 2, without any intervening ACKs which move SND.UNA) as an > indication that a segment has been lost. After receiving 3 duplicate > ACKs, TCP performs a retransmission of what appears to be the missing > segment, without waiting for the retransmission timer to expire. > However, if all transmitted data from the sender has been acknowledge= d, > the duplicate ACKs are in response to a Zero Window Probe, AND the > advertised window is still zero, then the TCP sender MUST NOT conside= r > these to be duplicate ACKs in relation to the fast retransmit > algorithm. > > > -Dan > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a1137c88ec3ab5d0543ca2cf5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good point. The RFC does seem unclear on that.
<= div>
The BSD code (tcp_input.c or Figure 29.3 in Stevens volu= me 2) is pretty clear about simply not treating a window probe as "out= standing data":

=C2=A0 * If we have outstandi= ng data (other than
=C2=A0 * a window probe), ...

<= /div>
So one option would be to go with that approach, and clarify in t= he definition of a dupack that a window probe does not count as outstanding= data:

So the existing RFC 5681 text:
=C2=A0 =C2=A0DUPLICATE ACKNOWLEDGMENT: An acknowledgment = is considered a
=C2=A0 =C2=A0 =C2=A0 "duplicate" in the= following algorithms when (a) the receiver of
=C2=A0 =C2=A0 =C2= =A0 the ACK has outstanding data,

could be:<= /div>

=C2=A0 =C2=A0DUPLICATE ACKNOWLEDGMENT: An ack= nowledgment is considered a
=C2=A0 =C2=A0 =C2=A0 "duplicate&= quot; in the following algorithms when (a) the receiver of
=C2=A0= =C2=A0 =C2=A0 the ACK has outstanding data (other than a window probe),

Do you mind sharing which TCP implementation w= as running on the sender in the scenario you describe? I haven't been a= ble to reproduce that behavior on Linux, and BSD doesn't seem like it w= ould be susceptible. Just curious.

neal
=

O= n Thu, Dec 15, 2016 at 4:52 PM, Dan Ciliske <dciliske@netburner.com= > wrote:
I appear to have r= un into either an edge case or ambiguity between RFC 793 and 5681 SHOULDs a= nd MUSTs where the sending TCP stack chooses to implement Zero Window Probi= ng by sending 1 byte packets. Error scenario is as follows:

No. Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 Source=C2=A0 =C2=A0 =C2=A0 Destination= =C2=A0 =C2=A0Info
=C2=A0 1 0.000000=C2=A0 =C2=A0 10.1.1.62=C2=A0 =C2=A010.1.1.56=C2=A0 =C2=A0= =C2=A0[PSH, ACK] Seq=3D1 Ack=3D1 Win=3D4644 Len=3D1460
=C2=A0 2 0.000853=C2=A0 =C2=A0 10.1.1.62=C2=A0 =C2=A010.1.1.56=C2=A0 =C2=A0= =C2=A0[PSH, ACK] Seq=3D1461 Ack=3D1 Win=3D4644 Len=3D1460
=C2=A0 3 0.000855=C2=A0 =C2=A0 10.1.1.62=C2=A0 =C2=A010.1.1.56=C2=A0 =C2=A0= =C2=A0[PSH, ACK] Seq=3D2921 Ack=3D1 Win=3D4644 Len=3D1460
=C2=A0 4 0.000855=C2=A0 =C2=A0 10.1.1.62=C2=A0 =C2=A010.1.1.56=C2=A0 =C2=A0= =C2=A0[PSH, ACK] Seq=3D4381 Ack=3D1 Win=3D4644 Len=3D264
=C2=A0 5 0.000856=C2=A0 =C2=A0 10.1.1.56=C2=A0 =C2=A010.1.1.62=C2=A0 =C2=A0= =C2=A0[ACK] Seq=3D1 Ack=3D1461 Win=3D3184 Len=3D0
=C2=A0 6 0.000856=C2=A0 =C2=A0 10.1.1.56=C2=A0 =C2=A010.1.1.62=C2=A0 =C2=A0= =C2=A0[ACK] Seq=3D1 Ack=3D2921 Win=3D1724 Len=3D0
=C2=A0 7 0.002107=C2=A0 =C2=A0 10.1.1.56=C2=A0 =C2=A010.1.1.62=C2=A0 =C2=A0= =C2=A0[ACK] Seq=3D1 Ack=3D4381 Win=3D264 Len=3D0
=C2=A0 8 0.002107=C2=A0 =C2=A0 10.1.1.56=C2=A0 =C2=A010.1.1.62=C2=A0 =C2=A0= =C2=A0[TCP ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0

=C2=A0 9 4.966264=C2=A0 =C2=A0 10.1.1.62=C2=A0 =C2=A010.1.1.56=C2=A0 =C2=A0= =C2=A0[TCP ZeroWindowProbe] [PSH, ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len= =3D1
=C2=A010 4.966265=C2=A0 =C2=A0 10.1.1.56=C2=A0 =C2=A010.1.1.62=C2=A0 =C2=A0= =C2=A0[TCP ZeroWindowProbeAck] [TCP ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 W= in=3D0 Len=3D0

=C2=A011 5.465671=C2=A0 =C2=A0 10.1.1.62=C2=A0 =C2=A010.1.1.56=C2=A0 =C2=A0= =C2=A0[TCP ZeroWindowProbe] [PSH, ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len= =3D1
=C2=A012 5.466429=C2=A0 =C2=A0 10.1.1.56=C2=A0 =C2=A010.1.1.62=C2=A0 =C2=A0= =C2=A0[TCP ZeroWindowProbeAck] [TCP ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 W= in=3D0 Len=3D0

=C2=A013 6.465684=C2=A0 =C2=A0 10.1.1.62=C2=A0 =C2=A010.1.1.56=C2=A0 =C2=A0= =C2=A0[TCP ZeroWindowProbe] [PSH, ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len= =3D1
=C2=A014 6.466442=C2=A0 =C2=A0 10.1.1.56=C2=A0 =C2=A010.1.1.62=C2=A0 =C2=A0= =C2=A0[TCP ZeroWindowProbeAck] [TCP ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 W= in=3D0 Len=3D0
=C2=A015 6.466443=C2=A0 =C2=A0 10.1.1.62=C2=A0 =C2=A010.1.1.56=C2=A0 =C2=A0= =C2=A0[TCP ZeroWindowProbe] [PSH, ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len= =3D1
=C2=A016 6.466443=C2=A0 =C2=A0 10.1.1.56=C2=A0 =C2=A010.1.1.62=C2=A0 =C2=A0= =C2=A0[TCP ZeroWindowProbeAck] [TCP ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 W= in=3D0 Len=3D0
=C2=A0 =C2=A0 =C2=A0...

1-4. Sender Sends final data that fills RWND.
5-8. Receiver Sends ACK for SND.UNA. Receiver fails to respond in a timely = manner with an increased window size.
9. Sender Sends Zero Window Probe with 1 byte, increasing SND.UNA by one. 10. Receiver responds with ACK for SND.UNA-1 and RWND of 0. This is the fir= st Duplicate ACK.
11. After delaying, Sender Resends the ZWP.
12. Receiver Responds with ACK for SND.UNA-1 and RWND of 0. This is the sec= ond Duplicate ACK.
13. After delaying, Sender Resends the ZWD.
14. Receiver Responds with ACK for SND.UNA-1 and a RWND of 0. This is the t= hird Duplicate ACK.
15. In response to three duplicate ACKs, the Sender now enters Fast Retrans= mission for the dropped packet, aka the ZWP.

15+. The Sender will respond to all ACKs from the Receiver with a retransmi= ssion of the Zero Window Probe due to Fast Retransmission.
16+. The Receiver will respond to all Probes with ACK for SND.UNA-1 and a R= WND of 0, until it=E2=80=99s user application reads the data.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

On a fast network (i.e. LAN), and a slow receiver (i.e. an embedded device)= , this becomes a Denial of Service as the receiver ends up spending all its= resources ACKing the Probes instead of reading from the socket.

Suggested change, in RFC 5681:
Section 3.2, paragraph 2 says:
=C2=A0 =C2=A0 The TCP sender SHOULD use the "fast retransmit" alg= orithm to detect
=C2=A0 =C2=A0 and repair loss, based on incoming duplicate ACKs.=C2=A0 The = fast
=C2=A0 =C2=A0 retransmit algorithm uses the arrival of 3 duplicate ACKs (as= defined
=C2=A0 =C2=A0 in section 2, without any intervening ACKs which move SND.UNA= ) as an
=C2=A0 =C2=A0 indication that a segment has been lost.=C2=A0 After receivin= g 3 duplicate
=C2=A0 =C2=A0 ACKs, TCP performs a retransmission of what appears to be the= missing
=C2=A0 =C2=A0 segment, without waiting for the retransmission timer to expi= re.

It should say:
=C2=A0 =C2=A0 The TCP sender SHOULD use the "fast retransmit" alg= orithm to detect
=C2=A0 =C2=A0 and repair loss, based on incoming duplicate ACKs.=C2=A0 The = fast
=C2=A0 =C2=A0 retransmit algorithm uses the arrival of 3 duplicate ACKs (as= defined
=C2=A0 =C2=A0 in section 2, without any intervening ACKs which move SND.UNA= ) as an
=C2=A0 =C2=A0 indication that a segment has been lost.=C2=A0 After receivin= g 3 duplicate
=C2=A0 =C2=A0 ACKs, TCP performs a retransmission of what appears to be the= missing
=C2=A0 =C2=A0 segment, without waiting for the retransmission timer to expi= re.
=C2=A0 =C2=A0 However, if all transmitted data from the sender has been ack= nowledged,
=C2=A0 =C2=A0 the duplicate ACKs are in response to a Zero Window Probe, AN= D the
=C2=A0 =C2=A0 advertised window is still zero, then the TCP sender MUST NOT= consider
=C2=A0 =C2=A0 these to be duplicate ACKs in relation to the fast retransmit= algorithm.


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

--001a1137c88ec3ab5d0543ca2cf5-- From nobody Fri Dec 16 15:10:27 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B2712948D for ; Fri, 16 Dec 2016 15:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUV-qXxgzNTX for ; Fri, 16 Dec 2016 15:10:24 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2210B12948B for ; Fri, 16 Dec 2016 15:10:23 -0800 (PST) Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com [209.85.217.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B9D6F2785DF for ; Sat, 17 Dec 2016 08:10:21 +0900 (JST) Received: by mail-ua0-f178.google.com with SMTP id 3so36953723uaz.3 for ; Fri, 16 Dec 2016 15:10:21 -0800 (PST) X-Gm-Message-State: AKaTC022LZlARj9ke5d65LBF86IDlFCucXbN1P5VY4dTv+AaMLuJdI5CGwYntCiNLYn4ealTLg/EDjifsSYRcQ== X-Received: by 10.176.82.48 with SMTP id i45mr3816640uaa.126.1481929817272; Fri, 16 Dec 2016 15:10:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.3.169 with HTTP; Fri, 16 Dec 2016 15:10:16 -0800 (PST) From: Yoshifumi Nishida Date: Fri, 16 Dec 2016 15:10:16 -0800 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c18f7ee573c190543ceac33 Archived-At: Subject: [tcpm] Adopting call for draft-khademi-tcpm-alternativebackoff-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 23:10:26 -0000 --94eb2c18f7ee573c190543ceac33 Content-Type: text/plain; charset=UTF-8 Hello, As we have discussed during Seoul meeting, the chairs decided to start running a call for adoption of draft-khademi-tcpm-alternativebackoff-ecn. We would like to confirm that the TCPM community agrees to: * adopt draft-khademi-tcpm-alternativebackoff-ecn as a TCPM working group item to publish it as an experimental RFC. * add a corresponding milestone to the TCPM charter. Aug 2017 Submit document on alternative backoff with ECN algorithm to the IESG for publication as an Experimental RFC As the end of the year is approaching, we decided to run a longer call than usual. Please let us know by * Friday January 6 2017 *, whether you support or object adoption of the document. Thanks, -- tcpm co-chairs --94eb2c18f7ee573c190543ceac33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

As we have discussed during Seoul meeting, t= he chairs decided to start running a call for adoption of draft-khademi-tcp= m-alternativebackoff-ecn.=C2=A0

We would like to confirm that the T= CPM community agrees to:

=C2=A0 * adopt draft-khademi-tcpm-alternati= vebackoff-ecn as a TCPM working group item to publish it as an experimental= RFC.
=C2=A0 * add a corresponding milestone to the TCPM charter.
=C2=A0 =C2=A0 =C2=A0Aug 2017 =C2=A0Submit document on alternative backoff = with ECN algorithm to the IESG for publication as an Experimental RFC

As the end of the year is approaching, we decided to run a longer cal= l than usual. Please let us know by * Friday January 6 =C2=A02017 *, whethe= r you support or object adoption of the document.=C2=A0

Thanks,
= --
tcpm co-chairs
--94eb2c18f7ee573c190543ceac33-- From nobody Sat Dec 17 10:26:07 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE2A1204D9 for ; Fri, 16 Dec 2016 10:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netburner-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbERfg-sTM8n for ; Fri, 16 Dec 2016 10:44:19 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B921296B8 for ; Fri, 16 Dec 2016 10:44:19 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id f188so34786630pgc.3 for ; Fri, 16 Dec 2016 10:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netburner-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=nbwzoQnk25CHMqafNVcAKj4mvS/0UcYJ2WkT/Jr1Scc=; b=d7NwE/6Vu7Y83fQ/hIa5Ss1TZMPTCOeeabvP11D3McsiFiURmos2gZjywii298eLwp rbfTy0GI9eUpiemPOWMBUPtxQTOz4zvSLnMq580QNzjA3ACXCtPt+OlsKJj/+NTEkOUt xyfIHuThzfZAjTrjFknWLZCXgFxjMSBG9Bu+VjaS3275QxcsvtSKDskaLWzNjSAJ3PGK byrF/FeFssMUV67CtakudrzPM25V5eo8xTmDUCE2nICrfS3fYmtRWszP15fZhO1ilMd/ UwJK/83hKaCpGZY/AFhZdMUcZDZb2S5hMS6loxWte2gaxNZZ02JJvfE2vVfOyiCjmvF1 Pi2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nbwzoQnk25CHMqafNVcAKj4mvS/0UcYJ2WkT/Jr1Scc=; b=s5OQsxv/pCb0lY87aMZ+jJrq8bSdMr4yA0m6TywyjcLlhKQwcD+HRvBuvXxmX9+tnr mXW+4dq9JFOUrBjN04XqN1cjnfXp9gQTa971bWgVJIAj42Py6CRmGPCT6UUikqzq557C M08+QXd5N37QHLZMhI+pd5sjhyjntKO40swwNh+ddF1S9i64pI49+1vc7InuxM6LQXby ixF6eXX6AtCm0ZkkMt3PQ54+Aag25HugMlUBn9E7XVSgYTZcugSFENaTdAxbVgiS5Spp Nwwzy8Ap0JVDb430yh8Z2Z9O0jifk++Y/pBl+CAz6PLKuZslUyDFgen7BLkCx4/1xMsw MSew== X-Gm-Message-State: AKaTC03kN61DGbf2ijVvuwIzF3vPSazIComyHEuIas4w8zP4Rp+Or5yWH3wv8+/nVoIQBjwx X-Received: by 10.99.117.11 with SMTP id q11mr8025361pgc.50.1481913858740; Fri, 16 Dec 2016 10:44:18 -0800 (PST) Received: from ?IPv6:2601:601:8f00:71db:6132:8839:6584:63fe? ([2601:601:8f00:71db:6132:8839:6584:63fe]) by smtp.gmail.com with ESMTPSA id w5sm13555060pfl.31.2016.12.16.10.44.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Dec 2016 10:44:18 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_71553A00-E789-4DCC-B488-E1D9CF5E7751" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Dan Ciliske In-Reply-To: Date: Fri, 16 Dec 2016 10:44:17 -0800 Message-Id: References: To: Neal Cardwell X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Sat, 17 Dec 2016 10:26:06 -0800 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fast retransmit of Zero Window Probes with 1 byte X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Dec 2016 18:44:22 -0000 --Apple-Mail=_71553A00-E789-4DCC-B488-E1D9CF5E7751 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hmm=E2=80=A6 looks like I may need to dredge up my copy. As to the = stack: it=E2=80=99s our own custom embedded TCP/IP stack running on a = derivative of uC/OS II. The code triggering this was written nearly 18 = years ago=E2=80=A6 I have no idea why it=E2=80=99s just now showed up. Also, your wording change seems to be more concise and clear. -Dan > On Dec 16, 2016, at 9:47 AM, Neal Cardwell = wrote: >=20 > Good point. The RFC does seem unclear on that. >=20 > The BSD code (tcp_input.c or Figure 29.3 in Stevens volume 2) is = pretty clear about simply not treating a window probe as "outstanding = data": >=20 > * If we have outstanding data (other than > * a window probe), ... >=20 > So one option would be to go with that approach, and clarify in the = definition of a dupack that a window probe does not count as outstanding = data: >=20 > So the existing RFC 5681 text: >=20 > DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a > "duplicate" in the following algorithms when (a) the receiver of > the ACK has outstanding data, >=20 > could be: >=20 > DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a > "duplicate" in the following algorithms when (a) the receiver of > the ACK has outstanding data (other than a window probe), >=20 > Do you mind sharing which TCP implementation was running on the sender = in the scenario you describe? I haven't been able to reproduce that = behavior on Linux, and BSD doesn't seem like it would be susceptible. = Just curious. >=20 > neal >=20 >=20 > On Thu, Dec 15, 2016 at 4:52 PM, Dan Ciliske > wrote: > I appear to have run into either an edge case or ambiguity between RFC = 793 and 5681 SHOULDs and MUSTs where the sending TCP stack chooses to = implement Zero Window Probing by sending 1 byte packets. Error scenario = is as follows: >=20 > No. Time Source Destination Info > 1 0.000000 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D1 Ack=3D1 = Win=3D4644 Len=3D1460 > 2 0.000853 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D1461 Ack=3D1 = Win=3D4644 Len=3D1460 > 3 0.000855 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D2921 Ack=3D1 = Win=3D4644 Len=3D1460 > 4 0.000855 10.1.1.62 10.1.1.56 [PSH, ACK] Seq=3D4381 Ack=3D1 = Win=3D4644 Len=3D264 > 5 0.000856 10.1.1.56 10.1.1.62 [ACK] Seq=3D1 Ack=3D1461 = Win=3D3184 Len=3D0 > 6 0.000856 10.1.1.56 10.1.1.62 [ACK] Seq=3D1 Ack=3D2921 = Win=3D1724 Len=3D0 > 7 0.002107 10.1.1.56 10.1.1.62 [ACK] Seq=3D1 Ack=3D4381 = Win=3D264 Len=3D0 > 8 0.002107 10.1.1.56 10.1.1.62 [TCP ZeroWindow] [ACK] Seq=3D1= Ack=3D4645 Win=3D0 Len=3D0 >=20 > 9 4.966264 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, = ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 > 10 4.966265 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] = [TCP ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 >=20 > 11 5.465671 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, = ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 > 12 5.466429 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] = [TCP ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 >=20 > 13 6.465684 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, = ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 > 14 6.466442 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] = [TCP ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 > 15 6.466443 10.1.1.62 10.1.1.56 [TCP ZeroWindowProbe] [PSH, = ACK] Seq=3D4645 Ack=3D1 Win=3D4644 Len=3D1 > 16 6.466443 10.1.1.56 10.1.1.62 [TCP ZeroWindowProbeAck] = [TCP ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0 > ... >=20 > 1-4. Sender Sends final data that fills RWND. > 5-8. Receiver Sends ACK for SND.UNA. Receiver fails to respond in a = timely manner with an increased window size. > 9. Sender Sends Zero Window Probe with 1 byte, increasing SND.UNA by = one. > 10. Receiver responds with ACK for SND.UNA-1 and RWND of 0. This is = the first Duplicate ACK. > 11. After delaying, Sender Resends the ZWP. > 12. Receiver Responds with ACK for SND.UNA-1 and RWND of 0. This is = the second Duplicate ACK. > 13. After delaying, Sender Resends the ZWD. > 14. Receiver Responds with ACK for SND.UNA-1 and a RWND of 0. This is = the third Duplicate ACK. > 15. In response to three duplicate ACKs, the Sender now enters Fast = Retransmission for the dropped packet, aka the ZWP. >=20 > 15+. The Sender will respond to all ACKs from the Receiver with a = retransmission of the Zero Window Probe due to Fast Retransmission. > 16+. The Receiver will respond to all Probes with ACK for SND.UNA-1 = and a RWND of 0, until it=E2=80=99s user application reads the data. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >=20 > On a fast network (i.e. LAN), and a slow receiver (i.e. an embedded = device), this becomes a Denial of Service as the receiver ends up = spending all its resources ACKing the Probes instead of reading from the = socket. >=20 > Suggested change, in RFC 5681: > Section 3.2, paragraph 2 says: > The TCP sender SHOULD use the "fast retransmit" algorithm to = detect > and repair loss, based on incoming duplicate ACKs. The fast > retransmit algorithm uses the arrival of 3 duplicate ACKs (as = defined > in section 2, without any intervening ACKs which move SND.UNA) as = an > indication that a segment has been lost. After receiving 3 = duplicate > ACKs, TCP performs a retransmission of what appears to be the = missing > segment, without waiting for the retransmission timer to expire. >=20 > It should say: > The TCP sender SHOULD use the "fast retransmit" algorithm to = detect > and repair loss, based on incoming duplicate ACKs. The fast > retransmit algorithm uses the arrival of 3 duplicate ACKs (as = defined > in section 2, without any intervening ACKs which move SND.UNA) as = an > indication that a segment has been lost. After receiving 3 = duplicate > ACKs, TCP performs a retransmission of what appears to be the = missing > segment, without waiting for the retransmission timer to expire. > However, if all transmitted data from the sender has been = acknowledged, > the duplicate ACKs are in response to a Zero Window Probe, AND the > advertised window is still zero, then the TCP sender MUST NOT = consider > these to be duplicate ACKs in relation to the fast retransmit = algorithm. >=20 >=20 > -Dan > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = >=20 --Apple-Mail=_71553A00-E789-4DCC-B488-E1D9CF5E7751 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hmm=E2=80=A6 looks like I may need to dredge up my copy. As = to the stack: it=E2=80=99s our own custom embedded TCP/IP stack running = on a derivative of uC/OS II. The code triggering this was written nearly = 18 years ago=E2=80=A6 I have no idea why it=E2=80=99s just now showed = up.

Also, your = wording change seems to be more concise and clear.

-Dan

On Dec 16, 2016, at 9:47 AM, = Neal Cardwell <ncardwell@google.com> wrote:

Good point. The RFC does seem unclear on = that.

The BSD = code (tcp_input.c or Figure 29.3 in Stevens volume 2) is pretty clear = about simply not treating a window probe as "outstanding = data":

  = * If we have outstanding data (other than
  * = a window probe), ...

So one option would be to go with that approach, and clarify = in the definition of a dupack that a window probe does not count as = outstanding data:

So the existing RFC 5681 text:

   DUPLICATE = ACKNOWLEDGMENT: An acknowledgment is considered a
      "duplicate" in the following algorithms = when (a) the receiver of
      the = ACK has outstanding data,

could be:

   DUPLICATE = ACKNOWLEDGMENT: An acknowledgment is considered a
      "duplicate" in the following algorithms = when (a) the receiver of
      the = ACK has outstanding data (other than a window probe),

Do you mind sharing = which TCP implementation was running on the sender in the scenario you = describe? I haven't been able to reproduce that behavior on Linux, and = BSD doesn't seem like it would be susceptible. Just curious.

neal


On Thu, Dec 15, 2016 at 4:52 PM, = Dan Ciliske <dciliske@netburner.com> wrote:
I appear to have run = into either an edge case or ambiguity between RFC 793 and 5681 SHOULDs = and MUSTs where the sending TCP stack chooses to implement Zero Window = Probing by sending 1 byte packets. Error scenario is as follows:

No. Time        Source      = Destination   Info
  1 0.000000    10.1.1.62   10.1.1.56  =    [PSH, ACK] Seq=3D1 Ack=3D1 Win=3D4644 Len=3D1460
  2 0.000853    10.1.1.62   10.1.1.56  =    [PSH, ACK] Seq=3D1461 Ack=3D1 Win=3D4644 Len=3D1460
  3 0.000855    10.1.1.62   10.1.1.56  =    [PSH, ACK] Seq=3D2921 Ack=3D1 Win=3D4644 Len=3D1460
  4 0.000855    10.1.1.62   10.1.1.56  =    [PSH, ACK] Seq=3D4381 Ack=3D1 Win=3D4644 Len=3D264
  5 0.000856    10.1.1.56   10.1.1.62  =    [ACK] Seq=3D1 Ack=3D1461 Win=3D3184 Len=3D0
  6 0.000856    10.1.1.56   10.1.1.62  =    [ACK] Seq=3D1 Ack=3D2921 Win=3D1724 Len=3D0
  7 0.002107    10.1.1.56   10.1.1.62  =    [ACK] Seq=3D1 Ack=3D4381 Win=3D264 Len=3D0
  8 0.002107    10.1.1.56   10.1.1.62  =    [TCP ZeroWindow] [ACK] Seq=3D1 Ack=3D4645 Win=3D0 Len=3D0

  9 4.966264    10.1.1.62   10.1.1.56  =    [TCP ZeroWindowProbe] [PSH, ACK] Seq=3D4645 Ack=3D1 = Win=3D4644 Len=3D1
 10 4.966265    10.1.1.56   10.1.1.62  =    [TCP ZeroWindowProbeAck] [TCP ZeroWindow] [ACK] Seq=3D1 = Ack=3D4645 Win=3D0 Len=3D0

 11 5.465671    10.1.1.62   10.1.1.56  =    [TCP ZeroWindowProbe] [PSH, ACK] Seq=3D4645 Ack=3D1 = Win=3D4644 Len=3D1
 12 5.466429    10.1.1.56   10.1.1.62  =    [TCP ZeroWindowProbeAck] [TCP ZeroWindow] [ACK] Seq=3D1 = Ack=3D4645 Win=3D0 Len=3D0

 13 6.465684    10.1.1.62   10.1.1.56  =    [TCP ZeroWindowProbe] [PSH, ACK] Seq=3D4645 Ack=3D1 = Win=3D4644 Len=3D1
 14 6.466442    10.1.1.56   10.1.1.62  =    [TCP ZeroWindowProbeAck] [TCP ZeroWindow] [ACK] Seq=3D1 = Ack=3D4645 Win=3D0 Len=3D0
 15 6.466443    10.1.1.62   10.1.1.56  =    [TCP ZeroWindowProbe] [PSH, ACK] Seq=3D4645 Ack=3D1 = Win=3D4644 Len=3D1
 16 6.466443    10.1.1.56   10.1.1.62  =    [TCP ZeroWindowProbeAck] [TCP ZeroWindow] [ACK] Seq=3D1 = Ack=3D4645 Win=3D0 Len=3D0
     ...

1-4. Sender Sends final data that fills RWND.
5-8. Receiver Sends ACK for SND.UNA. Receiver fails to respond in a = timely manner with an increased window size.
9. Sender Sends Zero Window Probe with 1 byte, increasing SND.UNA by = one.
10. Receiver responds with ACK for SND.UNA-1 and RWND of 0. This is the = first Duplicate ACK.
11. After delaying, Sender Resends the ZWP.
12. Receiver Responds with ACK for SND.UNA-1 and RWND of 0. This is the = second Duplicate ACK.
13. After delaying, Sender Resends the ZWD.
14. Receiver Responds with ACK for SND.UNA-1 and a RWND of 0. This is = the third Duplicate ACK.
15. In response to three duplicate ACKs, the Sender now enters Fast = Retransmission for the dropped packet, aka the ZWP.

15+. The Sender will respond to all ACKs from the Receiver with a = retransmission of the Zero Window Probe due to Fast Retransmission.
16+. The Receiver will respond to all Probes with ACK for SND.UNA-1 and = a RWND of 0, until it=E2=80=99s user application reads the data.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

On a fast network (i.e. LAN), and a slow receiver (i.e. an embedded = device), this becomes a Denial of Service as the receiver ends up = spending all its resources ACKing the Probes instead of reading from the = socket.

Suggested change, in RFC 5681:
Section 3.2, paragraph 2 says:
    The TCP sender SHOULD use the "fast retransmit" algorithm = to detect
    and repair loss, based on incoming duplicate ACKs.  = The fast
    retransmit algorithm uses the arrival of 3 duplicate ACKs = (as defined
    in section 2, without any intervening ACKs which move = SND.UNA) as an
    indication that a segment has been lost.  After = receiving 3 duplicate
    ACKs, TCP performs a retransmission of what appears to be = the missing
    segment, without waiting for the retransmission timer to = expire.

It should say:
    The TCP sender SHOULD use the "fast retransmit" algorithm = to detect
    and repair loss, based on incoming duplicate ACKs.  = The fast
    retransmit algorithm uses the arrival of 3 duplicate ACKs = (as defined
    in section 2, without any intervening ACKs which move = SND.UNA) as an
    indication that a segment has been lost.  After = receiving 3 duplicate
    ACKs, TCP performs a retransmission of what appears to be = the missing
    segment, without waiting for the retransmission timer to = expire.
    However, if all transmitted data from the sender has been = acknowledged,
    the duplicate ACKs are in response to a Zero Window Probe, = AND the
    advertised window is still zero, then the TCP sender MUST = NOT consider
    these to be duplicate ACKs in relation to the fast = retransmit algorithm.


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


= --Apple-Mail=_71553A00-E789-4DCC-B488-E1D9CF5E7751-- From nobody Wed Dec 21 08:08:31 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54079129713 for ; Wed, 21 Dec 2016 08:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUxuJ4JV8UWj for ; Wed, 21 Dec 2016 08:08:28 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CE1129715 for ; Wed, 21 Dec 2016 08:08:27 -0800 (PST) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.example.com) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87_RC125) id 1cJjRH-00006Q-4M for tcpm@ietf.org (return-path ); Wed, 21 Dec 2016 16:08:23 +0000 To: tcpm@ietf.org References: <147792042334.32506.9174702720038902578.idtracker@ietfa.amsl.com> From: Jeremy Harris Message-ID: <880491cb-7032-4c29-e182-6b16e66fc8df@wizmail.org> Date: Wed, 21 Dec 2016 16:08:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.example.com) with esmtpsa Archived-At: Subject: Re: [tcpm] Fwd: New Version Notification for draft-harris-estab-wscale-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Dec 2016 16:08:30 -0000 On 01/11/16 15:55, Jeremy Harris wrote: > I have submitted a draft extending the use of the TCP Wscale option. [Apologies for the threading break; I didn't receive Yoshifumi's mail directly] Yoshifumi Nishida wrote: > 1: This might be beneficial for middle points that want to do some > network analysis. However, I don't see benefits for sender and > receiver. So, unless there are strong relationships between network > analysis app and sender/receiver, sender/receiver won't have good > motivation to implement and activate this feature. However, such > relationship might not always exist. Indeed. The intent is to make it low-enough cost that it will be at least commonly available, preferably commonly enabled as a default. > 2: For the same reason, it seems to be difficult for senders to decide > whether activate this feature or not. If it is not enabled by default on a system, it should be possible for operators to enable it when needed for a packet-capture debug step. I'll add some words pointing this out. > Also, it's difficult to decide the interval for sending this option > as it totally depends on network analysis apps. > It seems that the draft presumes to use one fixed value for > interval, but I'm not sure if we can find a proper value as I guess > the requirements can be varied for some reasons. It's not intended that the option is required in the flow for proper operation of anything, including any network analysis applications. It is solely intended as a convenience datum which may be discovered either manually or by an analysis application. The draft does not require any specific interval, and I see no reason for a fixed interval either. A fixed number of packets is simple to code, but that should not be part of the specification. > 3: The requirements in Section 2.3 won't be needed as it's already > stated in Section 2.2 in RFC7323. > So, I think this proposal will require sender-only modification. > (which is better than updating both sides) I'll change the wording, to clarify that RFC 7323 still controls this aspect. > 4: I think you'll need to refer RFC7323 instead of 1323 as 1323 is obsoleted. Yes. -- Cheers, Jeremy From nobody Fri Dec 23 01:32:08 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19503124281; Fri, 23 Dec 2016 01:32:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148248552707.16717.11302559767769281990.idtracker@ietfa.amsl.com> Date: Fri, 23 Dec 2016 01:32:07 -0800 Archived-At: Cc: tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org Subject: [tcpm] tcpm - New Meeting Session Request for IETF 98 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 09:32:07 -0000 A new meeting session request has just been submitted by Michael Scharf, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig maprg rtcweb rmcat teas Third Priority: ippm Special Requests: A plus BoF/WG would also be a first priority conflict ---------------------------------------------------------