From nobody Tue Oct 3 08:20:57 2017 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 681C9134D4D for ; Tue, 3 Oct 2017 08:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 ITyPPx4DAicT for ; Tue, 3 Oct 2017 08:20:48 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id 06633134672 for ; Tue, 3 Oct 2017 08:15:17 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 068FC17105 for ; Tue, 3 Oct 2017 08:15:21 -0700 (PDT) Date: Tue, 3 Oct 2017 08:15:20 -0700 From: hiren panchasara To: tcpm@ietf.org Message-ID: <20171003151520.GC46744@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2JFBq9zoW8cOFH7v" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [tcpm] CUBIC hystart entering CA X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 03 Oct 2017 15:20:49 -0000 --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Looking for some help in understanding how to set cwnd when hystart moves connection into CA mode. Draft says: In the case when CUBIC runs the hybrid slow start [HR08], it may exit the first slow start without incurring any packet loss and thus W_max is undefined. In this special case, CUBIC switches to congestion avoidance and increases its congestion window size using Eq. 1 where K is set to 0 and W_max is set to the window size when CUBIC just exits the slow start. Now, t = time since last congestion event. Which is essentially total time the connection is alive as it hasn't seen any loss yet. i.e. can be large. W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1) What I am observing is, this equation yields quite large window and I believe at this point cwnd is set to that value as we follow cubic cwnd growth as opposed to tcp-friendly region. This basically makes cwnd pretty large and moves connection into loss much quicker defeating the purpose of hystart. Is this a correct analysis or am I missing something obvious? Cheers, Hiren --2JFBq9zoW8cOFH7v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJZ06mCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lnv4H/0KuDIIOBZoH6hRKc3G0tDrp NN5ze4zKD1n0FiS96uAYWj1t3jV9VY+SxwKJ6eSq1JAIYNz0vobl4Y94RVSIlAzl 5RebUbnQV2/UymKcOvAUpVYfyBti6iaPr+gTWcoUkmlxM0HOSXD/2CBhDCCm4PMQ hVrqzxTQmym5N1Zh6djBu+cOndmSH75cch8ZpxN9Ylhezx43RFLu+MhAZdWv1poG ab0QvVaDITwj3eZ7heKfbSxfnsqpGTcRdE9EQzCaFsmSa0Vq5nd1FZw+Gc+6+EKn iizWOgNSm8RJnoEQ4Ent+PPueJJP/ATbEWyc4y0EZiVJjtrwM41pStY6XCEH1NY= =JVyY -----END PGP SIGNATURE----- --2JFBq9zoW8cOFH7v-- From nobody Tue Oct 3 08:56:56 2017 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 89E04134E97 for ; Tue, 3 Oct 2017 08:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=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 nAgoWrVG9aI2 for ; Tue, 3 Oct 2017 08:56:50 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0015.outbound.protection.outlook.com [216.32.180.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6559D13468E for ; Tue, 3 Oct 2017 08:56:50 -0700 (PDT) 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=zg6sjiHdbccMMishfTfFMPdPyho333Sx8D43Vh7vq1M=; b=Yt9mG2efOCb9s1wnTtWH6Zyqp/o0eZOsuLQiExuCnfjsTT6pw/K5gmeign7GuLi3fFcbTObZseofbplw8tpFLsqnG+HVqSFX0PNGO2mtHWo6yu/m7AO22+FopkR4pmaWFVq6xPSTtH7XrI77ohRmN8pn8pxjG0RyzhCEjy0vwu8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [192.168.0.21] (97.98.140.59) by DM5PR08MB2761.namprd08.prod.outlook.com (10.175.219.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 3 Oct 2017 15:56:48 +0000 To: hiren panchasara , tcpm@ietf.org References: <20171003151520.GC46744@strugglingcoder.info> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <4a4ec453-2875-9273-9fa8-d2ad0c7e7128@unl.edu> Date: Tue, 3 Oct 2017 10:56:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171003151520.GC46744@strugglingcoder.info> Content-Type: multipart/alternative; boundary="------------E4C73BBC5123A9CE554A2177" Content-Language: en-US X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: BN6PR1101CA0024.namprd11.prod.outlook.com (10.174.237.34) To DM5PR08MB2761.namprd08.prod.outlook.com (10.175.219.7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 293081d3-cfe6-46fa-394e-08d50a775b2c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR08MB2761; X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2761; 3:djbJqH6o+mxFOXFm8kM8mAxZyRfjxA7rtkNNXL1MQgRjXwmrroRg+caLjcAmqd8Wrb99XBZyq6+NGrvJc+xqVNWVweaUcZ4/QK68D3U0GfdyZLDv/BAlGTS2GbQxPLHvDjz8w5mqei4S9dIqUSdmdjYxRfvfOnp7rqpsiY4RWG4F4FvCu2oL5xWOPkrFZ+Lb/2Coo+M/hpDjbMgktZdWoy0LoJufHTFScJ183Dg6UidfDwLOmLn1uxIQqH8H05HB; 25:sf8tIzo+iUEDR9Qhp7FqpkiUsX79qzQh5bJQq7QoqCx7G6eAXP+1xRUhda7QBUNiyg1XxVzRE/KBCSfnFtDGMX/uLXN61GLVy6FRdwig2sZj0DvrWTyfM5xOueqlIfIQzhePzIQ5SNN/MBSZrzpTpxJPkGeF9X0/YtkGJdGoWPL9zHfzA1HzIIbIeKUYtHyEQhP1YRClQo6qz23dzjUsXMQI1bDF2KS02lMqm+2cen2o9goTcJB1fIKAnwy+MW7N4044pzs+s5ik/YsDFx9ixdJWL5whcMul1OOjM2uOgPjvUnvxIPmvimuW9jB6OdsJACwQ1EF3aOUr+bbvQVl+6w==; 31:6NcAzViC2YEUisrpz1uhIrBQcOGX6WtOiSdrQof01AKTw0h90DUxxhyPbI0s0jE6rLc7gAz2nf7gwctD4n4K0zmSkUyl66vTvIo9WDHUD4Fku35KVaH67JsKKQt0soE1ORm7p8Cu/O1zMiGPDFuFu7XC3s3QrpMlfAYaXVTdt4ag5D/vXBN3/c6VKeUuHSnF6lptj2Mi1sS4iIjglcp7yRwR5iJvevSdXVjAqz9DEJE= X-MS-TrafficTypeDiagnostic: DM5PR08MB2761: X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2761; 20:bZYmkk0wXGRjE4bvS4baR/c9J4oYk04cRnesJh3sblVa4mDmjzxu0mPUChB42FDlVPw3NIDxM4+8oLP3RbbyBCXFSEUKpuBJkfdNUHbUby3ejz7I5V6aGv8Bvi8OH2IB8IpdOjXyC9ObqsQF7s/DlkdOjseu5wxngjOpJDG44GIffIJb+KZX4MhRy20qdvn+Nr1g6/HY0V19CxGyoayVuU0Tipvs5Joru/GFITNHbYaXwDWuz9kmwmbWV8Hl1VQFcthM8bCYGcehzxOg/N048GbUbHvxkTvW+yYjkIP4Qpxq+Azt/u2uMnIrza2gqmoB9I8fL4OEMxKJHkfCpEk7K9JvcHzjvGz+oCq55QJsgosd2/YxiQwxKogNku1BuQeXfrxTA8ra9B6w74/yif0PQZs/5j7fHyKD1dHoZQHQyvsn+xsvTwJgmcSp5SX4/1uUwhEGadTteAa8wqkTbB6n7kQ5X/RThCRx+6JYI2xAqBOY7SSUxvpn4FKjHixUw//4; 4:xX5GRL2EtWpNo8+m7S169PrA1pN54rnQYgZQWv/tj1hQP7vhB89iFkRSIMyViFc+J426VwIcn6yRuwovlch0pyt7yJPjBYk5hWlawZZvo2B6YdVaLr0eU5VPIK3ntYZvMYKQ1iZ+NPJDvXm4YrOMer9+WBLHbe8G9unHeUtgjfZMuj4Kom1m8AC3T8fhSdpStKK/4fLvK5W9vvTarTcmtLQIUd7zrUWFZCFmXuUK8Q1rIpkzpT6fPTqBuLArSdQN X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR08MB2761; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR08MB2761; X-Forefront-PRVS: 044968D9E1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(346002)(377454003)(24454002)(199003)(189002)(68736007)(25786009)(36756003)(2950100002)(86362001)(606006)(8936002)(478600001)(31696002)(90366009)(81166006)(81156014)(117156002)(77096006)(3260700006)(8676002)(6486002)(189998001)(53546010)(54356999)(16526017)(50986999)(16586007)(270700001)(65826007)(83506001)(76176999)(316002)(64126003)(786003)(5660300001)(84326002)(58126008)(37036004)(101416001)(105586002)(16576012)(33646002)(106356001)(229853002)(7736002)(31686004)(6116002)(66066001)(413944005)(966005)(65806001)(65956001)(3846002)(88552002)(6666003)(2906002)(6246003)(236005)(97736004)(54896002)(53936002)(6306002)(75432002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR08MB2761; H:[192.168.0.21]; 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: =?us-ascii?Q?1; DM5PR08MB2761; 23:M5w1bDLwfech6ObJTpYPtVUAlOSA+OgGTUrFOd5iR?= =?us-ascii?Q?YU3tMG22dzn/o3hsX7JwdTj/I4OzaYsvX46GYGCt2Ox2GLDnlvj4TSGHp6nU?= =?us-ascii?Q?54vEho94Jn0fip4A7DDeNPWsotNE5yjbCSBW0bOCCJ5mg/VXekw83QtEdf4S?= =?us-ascii?Q?1zbrwpcK3Ryl3A9OHTbJ1XxRkuM3005Bezc/02cE+Sze8aITKWRN/EhKcdfF?= =?us-ascii?Q?5l9SIAH88x2nf5p1DFrEmFrX+bBwIEXLVqaOdRf4rzBBJtqDW6AU1DIMt5Hm?= =?us-ascii?Q?RV7LZQhn0VQTlTz1jVBWuRRYTnEpdijpLt+CRJ9wtFFYVXOD5W1dYLRzMxHk?= =?us-ascii?Q?rHhVufGmIG54GnjPioALdYvbiPkPUVb1LqLcOhs34X09gCPIOf7tmeerK1W2?= =?us-ascii?Q?NuwMhtDFSYlKl07TwDshLEQJvF9XlGP7UB336YH6qN6Ht+uIoE072imaf8vw?= =?us-ascii?Q?pHKGQG0drZR9o60a+ZKYWpa4Zde3XN6nfm6JyM4KjmAVKCKTeJqwIvDILvGy?= =?us-ascii?Q?f75YmY6Kcb79BFIw99MpcyNNcTrAnvuQRZHJzi/eJKCG+Y/TA9l1JfkX7TQI?= =?us-ascii?Q?8DM5jfFFmxExDnvBBXT9XK6SXgWimD2oKlJMs6nPOhmHF9RFiA5BYCmT8yps?= =?us-ascii?Q?LyEo1aQYhQJeD7cszvlJNl1ouNoe86vBJ8kib5PEwaoy/UbItJzf8BbchdW/?= =?us-ascii?Q?Ms/eXnSDLhPqLho6QQL69/KfjYDdby8IHZjv/SabceED9j5kzeQ7uUC5HT0h?= =?us-ascii?Q?hsUmD5Zhc8D7B59tCy0thlqMdmI2XZ20BE62OTe4CeZ/hPB6lvLm+eq+N4j4?= =?us-ascii?Q?OpLGmc8JhlpIpINNaJ9H8mi6ssN+zTbznCnVrCucxPqmsTJgrprTchn0ksmV?= =?us-ascii?Q?HDEolaDZS1DiPgWUENRkiXs1c4TBSCr9RDSLC88IxoEEtS1F/sg9X0i9KW9h?= =?us-ascii?Q?rpUk0unhPEFNRVhJIn7vGbGmZGPC8Z0/1tU+NiIKoTta9BOewIZCuw9HSO8n?= =?us-ascii?Q?YfQZ6mpNTB6bS6I8QjbXkLDg7g0ByVLECBJzF36dvNmMByR/6Z0kaFmYOW1s?= =?us-ascii?Q?gYw8Ga6dRTtHMpUXmUzt77DnBTmWg++1Vh6xSns13nAolgGULmOd55G6GXH5?= =?us-ascii?Q?HRbFbQGn1DkDdX+Q/EiKXla+RSiBiAAVTearJP3v6dsLTsyAOPC6acqpNnbJ?= =?us-ascii?Q?jDCIThGRUPlhlAG7CPF1gnOpISZpQ4umE9rv/JElxSVNidFmJY+Ui94La+9U?= =?us-ascii?Q?/Mel5ql17xv/Hz5Re2DwID6MIM9zcrSQlO+hfZikumpcyarUE6ej7/DdFYVd?= =?us-ascii?Q?kzlFN9vaF6bTHkZM/H5r0pS8PZxpxdiPPNsBFXaxI9AqjGrITZRIkutqjHiI?= =?us-ascii?Q?JbaxS4cnYD2Vgwt+e0D6QNVVXjdrvItttOtAL2ndI6c9NQ2oNp6ocDBsi0ok?= =?us-ascii?Q?RGUBOCVxdpS5gJsWGDheQBD0N8BJMdrCTtlwVbPty/q2/y3OBVbrv2Wy/Tn3?= =?us-ascii?Q?P1ZEAhr3Td1sc0n/Nf7vx5+7T7DgEqFhaK74yOzRAhMVr8L+SBYo6ER?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2761; 6:q6lqmJ9HS8Ljc0WcHylYS91ZaNYMs0s/nzOtiYF3VxSI25LUz8Ms4punxsZXqPlBGKHIBbkcEdkc993lZGEoEdT3qmmd90D2waR5Blmpw0/jJR1BFywL4c6sXheYxGuu7174Y7fAERywFsSSmIzQxF6cZyzV6pL7j4d3hvyK7m1zXxum/b6bqDId8pnY0ZiVZAey3aDWlaWCRVy1AfkiMDlz1g1mePspVJ8R9U0MrkkuAwvv5XFGXMJnS6BhU0QFx8/JAnIYi4deqDhUGZbEVFVnD331lavdbF0Ib44BS5j3vClCXdYof0M7HF5hNL6F1VdJTrVS5AdDKfxgptrmHw==; 5:7sDqtg8uAj/IYt6FYEOG34c1hfNTyKlRdD6+KfqAtFRirlcJloSb5kM6PfGJWM6xc3+G+UdzM48Zj6q8BAki3p9My4XCU2u/AwW/qOiYAY/yE/JhUMOKLeQVE6GGFIdWAya2qBoUooGnCCKqhugPXQ==; 24:u22Dr87LApn6iorU1ljfx3EOuGYA4fWm5PgJ5t9Lf0mM1S7JUiZkjkbE8xvGczXsN3JONgkeT8ukTAqbH7YA5eI8hyiZUZSbTk/eJcr/3sY=; 7:wHDVWdeIoax2H+2HWbaCHbmfCz/8Gt455ucaoHWVQWntpVKv28Hi8FDHFXX+P/8q2YYIx8itWv92J4w3GN0szFMBOqm5+bIcLDXHcDkkzH2bvPBX0lvT6aY1Jp+saRQP4WYdEhUxFUMhbpXVJfz4JDOylpMS1K3gDKZ6gj2/1I63iPx4FBjMZmDMDATE3Gq0gtgu+OIl4pJFGA56APmvnP1PG0kRwZBb4g19rHA3+Wo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2017 15:56:48.4335 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: fddb01ad-4983-436e-ab35-1af043b818c9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2761 Archived-At: Subject: Re: [tcpm] CUBIC hystart entering CA X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 03 Oct 2017 15:56:53 -0000 This is a multi-part message in MIME format. --------------E4C73BBC5123A9CE554A2177 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear Hiren, In this case, t is the time interval since the time it exits the slow start instead of the beginning of the connection. We will revise the draft to clearly explain it. Thanks Lisong On 10/3/2017 10:15 AM, hiren panchasara wrote: > Looking for some help in understanding how to set cwnd when hystart > moves connection into CA mode. > > Draft says: > In the case when CUBIC runs the hybrid slow start [HR08], it may exit > the first slow start without incurring any packet loss and thus W_max > is undefined. In this special case, CUBIC switches to congestion > avoidance and increases its congestion window size using Eq. 1 where > K is set to 0 and W_max is set to the window size when CUBIC just > exits the slow start. > > Now, t = time since last congestion event. Which is essentially total > time the connection is alive as it hasn't seen any loss yet. i.e. can be > large. > > W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1) > > What I am observing is, this equation yields quite large window and > I believe at this point cwnd is set to that value as we follow cubic > cwnd growth as opposed to tcp-friendly region. > > This basically makes cwnd pretty large and moves connection into loss > much quicker defeating the purpose of hystart. > > Is this a correct analysis or am I missing something obvious? > > Cheers, > Hiren > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------E4C73BBC5123A9CE554A2177 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Dear Hiren,

In this case, t is the time interval since the time it exits the slow start instead of the beginning of the connection.

We will revise the draft to clearly explain it.

Thanks

Lisong


On 10/3/2017 10:15 AM, hiren panchasara wrote:
Looking for some help in understanding how to set cwnd when hystart
moves connection into CA mode.

Draft says:
   In the case when CUBIC runs the hybrid slow start [HR08], it may exit
   the first slow start without incurring any packet loss and thus W_max
   is undefined.  In this special case, CUBIC switches to congestion
   avoidance and increases its congestion window size using Eq. 1 where
   K is set to 0 and W_max is set to the window size when CUBIC just
   exits the slow start.

Now, t = time since last congestion event. Which is essentially total
time the connection is alive as it hasn't seen any loss yet. i.e. can be
large.

W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1)

What I am observing is, this equation yields quite large window and
I believe at this point cwnd is set to that value as we follow cubic
cwnd growth as opposed to tcp-friendly region.

This basically makes cwnd pretty large and moves connection into loss
much quicker defeating the purpose of hystart.

Is this a correct analysis or am I missing something obvious?

Cheers,
Hiren



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

--------------E4C73BBC5123A9CE554A2177-- From nobody Tue Oct 3 09:11:28 2017 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 7E620134EF5 for ; Tue, 3 Oct 2017 09:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 7huKCM-hpUhP for ; Tue, 3 Oct 2017 09:11:26 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id F1739134EF1 for ; Tue, 3 Oct 2017 09:11:25 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 18AF5171B1; Tue, 3 Oct 2017 09:11:29 -0700 (PDT) Date: Tue, 3 Oct 2017 09:11:29 -0700 From: hiren panchasara To: Lisong Xu Cc: tcpm@ietf.org Message-ID: <20171003161129.GD46744@strugglingcoder.info> References: <20171003151520.GC46744@strugglingcoder.info> <4a4ec453-2875-9273-9fa8-d2ad0c7e7128@unl.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1sNVjLsmu1MXqwQ/" Content-Disposition: inline In-Reply-To: <4a4ec453-2875-9273-9fa8-d2ad0c7e7128@unl.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [tcpm] CUBIC hystart entering CA X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 03 Oct 2017 16:11:27 -0000 --1sNVjLsmu1MXqwQ/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/03/17 at 10:56P, Lisong Xu wrote: > Dear Hiren, >=20 > In this case, t is the time interval since the time it exits the slow=20 > start instead of the beginning of the connection. A ha! That makes sense. >=20 > We will revise the draft to clearly explain it. Thanks a lot! While here, I was wondering if following can be clarified a little more in the draft: "While most alternative algorithms to Standard TCP uses a convex increase function where during congestion avoidance the window increment is always increasing, CUBIC uses both the concave and convex profiles of a cubic function for window increase." I guess what's being suggested here is that CUBIC doesn't increment window with the same *amount* of bytes like most standard TCP? Anyways, its probably obvious so will leave that up to you. Thanks a lot for a quick response though. :-) Cheers, Hiren >=20 > Thanks >=20 > Lisong >=20 >=20 > On 10/3/2017 10:15 AM, hiren panchasara wrote: > > Looking for some help in understanding how to set cwnd when hystart > > moves connection into CA mode. > > > > Draft says: > > In the case when CUBIC runs the hybrid slow start [HR08], it may ex= it > > the first slow start without incurring any packet loss and thus W_m= ax > > is undefined. In this special case, CUBIC switches to congestion > > avoidance and increases its congestion window size using Eq. 1 where > > K is set to 0 and W_max is set to the window size when CUBIC just > > exits the slow start. > > > > Now, t =3D time since last congestion event. Which is essentially total > > time the connection is alive as it hasn't seen any loss yet. i.e. can be > > large. > > > > W_cubic(t) =3D C*(t-K)^3 + W_max (Eq. 1) > > > > What I am observing is, this equation yields quite large window and > > I believe at this point cwnd is set to that value as we follow cubic > > cwnd growth as opposed to tcp-friendly region. > > > > This basically makes cwnd pretty large and moves connection into loss > > much quicker defeating the purpose of hystart. > > > > Is this a correct analysis or am I missing something obvious? > > > > Cheers, > > Hiren > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 --1sNVjLsmu1MXqwQ/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJZ07asXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lpfcH/i+WD6QHGwQmaWfSV+tb4ALh PvXr2lbuMQrJZHiK1kWt9fdIHkYCbzw/TFRa5spGDPiCg+kaLkGh3tD1d84QosBp LUSCOOavN01OGNopIHzZ+6o/UUA7BUlkHW0PAI/d+ONsoF4ANlRh3SpM1q0sPdiD y6REeeGZ2U85ABjwTOm1pPMCOaNzIidspSg6OFyEK+AoB5rwtiytw73FHAWUpbNO k9xVpI0cUSpqw2WgHBo9tfEvOXr3YkuCvYsfC1/Q7cuwZpJ1n8UXrlzAz7C7QFRR wm1GDpq5XMzCUyMgSAemWWFJi8R2sb5S2I+K5lb/VeNDdKMqzvFzYOVPW3Dvpns= =SLcN -----END PGP SIGNATURE----- --1sNVjLsmu1MXqwQ/-- From nobody Tue Oct 3 18:39:34 2017 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 E0CFF1331F6 for ; Tue, 3 Oct 2017 18:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=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 zbyMz-ig1H61 for ; Tue, 3 Oct 2017 18:39:30 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0117.outbound.protection.outlook.com [207.46.163.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9812513308D for ; Tue, 3 Oct 2017 18:39:30 -0700 (PDT) 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=wWfNmg+c4IlgwXEW5jKv+hfr2d7KvQ5Zwq84bF/EiKE=; b=AoN06g8oX8+FG38ZakkfSjqxq+mdxo/S52iPtMle+P4fwqxiTTI8Ghe18BjXfglzKd2xTxw1qmeiYf9oNoPQn1M8gmPqkQ9bJmNEcgN8jiCIwXpojeXmB8bn/athCpLLvXBncLa8cbd1Oft7q5OBD1bhOzIQvei2d3+Aq6Vq4ao= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [192.168.0.21] (97.98.140.59) by DM5PR08MB2761.namprd08.prod.outlook.com (10.175.219.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 4 Oct 2017 01:39:28 +0000 To: hiren panchasara Cc: tcpm@ietf.org References: <20171003151520.GC46744@strugglingcoder.info> <4a4ec453-2875-9273-9fa8-d2ad0c7e7128@unl.edu> <20171003161129.GD46744@strugglingcoder.info> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: <0fca69ba-6572-ccbc-4110-a107c7d9c8f4@unl.edu> Date: Tue, 3 Oct 2017 20:38:55 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171003161129.GD46744@strugglingcoder.info> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: CO1PR15CA0063.namprd15.prod.outlook.com (10.175.176.31) To DM5PR08MB2761.namprd08.prod.outlook.com (10.175.219.7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2858b92e-4802-4f46-4b0c-08d50ac8c135 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR08MB2761; X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2761; 3:WkHXFo0DSRIoo0tcxv/c9vcsG2hKEBnctDkp4tGiDyYZR1xQ04BGUp/LL6dxHeplu2SGO4MNk4SOh/AvT5FZk7kFDJ8+fQpEnFEfSBGY878pAyX4w9H5nEPLHB2jhXFpN6487tLgDtAcgNEi5VXSzK2KvBRYEbIGQy99ZsoDo/Y6EfRNY9sOr7fAeZBSz3jgVD+meS9Kldu2AiFmNQl1ZVE+plHHA2aTXCGWyYH9jcCdgyZHoNSXP1tCIyO0LO/b; 25:aXj0OUtsoWB9QCQEXvVGV8uJLmoPKwHO1FqbmvMCtdg700GJyLImnX8moTu4Ez9Lf9RKrdht/pBSQ6WtMC2Id4dSJsX86jV0BHXlT4+mUHiTMB9PXugPOCA7PNgwOcO+OU0R60Eo97S4tLbItG/sM9rDXQt0IybQJbcgKEfa6QfPPvl/KUDOQXDkbsOTUUydD0X+N3kd+zU0LQmGSZ1oRdUUAMHzkdirtbwB/fh1vVJZAWJAEkqrLEQbMRJlwSEYXKbSEDPZUl98PqfRbshhdqJSyiJ88dr4viFaw+bdAKFt4ZkhVJhttTedcTM6zlYwsYBOPkZ2G17lwN6qT0FlOg==; 31:DrdTRbXRCSbJTpFqnVJ7BhKWFJTEiCE7vJKGkL4/js7afgtWRmipVKPZCzsj6rGV67C8dbWg4z1NLKSbcqchU4EplL1UbVZAp+xoUlDsuDVyD4zApRRdWq1h3IB0BK2llu5EMhDuGdPyRkrsb1uzsO3gYQ5TmR0EA8moR1/105xqrwdpRMM0uDku58mKMp68x+5N0SaQc6Wy+0mMEFY2mPj7hsbXGR91IgIaAEz+BMQ= X-MS-TrafficTypeDiagnostic: DM5PR08MB2761: X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2761; 20:HDPMdMACsW0TTSayM+hjC5bT4NgjacRI/slV8ljRSM/c4/N6ueCfGzSXpkOupn4bWwfGi3u2uVtD95ER8JQ0SSURZKzl/xngerGjkJf3TI29q78QqwW/HnLKE0poeuvgs2rynueZEQ0UEx7WuP+GHAihq8wrTcX7gBmsWXdPl0Mc4u+lvUveq4y6WeFqFq3We0OcJV/jOQLziNqHHyEKeCkT2lQxF/ZxwB5N93i5Xves9KPwqN8h4P1W4g4Tfe9UwudenwfGO54WG3DuopyVvvuNhYkJxz+bhu2foOzvZEFnxC4MMT0l6Di2ZKeCCz3DHgRU3GADKAlbqeEyY5rrwtqejEkwbcbJbfrsG1G31CBKC8wPASemSDDR1+rXL5nHfrsqaMSL8DlUMKcqzyq5P4Yv0grv9e3arwoV10hQAOsun8diAtkcoehgxpWSp5Tv5RvMfadTWibOgJVBgKHp7S2m2734RWUubbjso281/qqSe6b/ICxkmogrtBsxp79V; 4:HVhPBwpHwDn0b9QTtuHidqGijFA9s+S1l+mMi/kni2NpSCbw9yKm6eM6OlPP4Ok+CXg+lTK77u3EigvvUIhdw7qe6PPwfu1awxtMiD7PzTosDkXFERNihgV2Wggte21VmQI32b3TpXesFrKT6SIG0+CnDPUujv+UjC8V2w+97jVAeWo6kIOWcf1jaI+L7ZHypN1phTpxh7q0IXBRdIKqn46duJVffikakNIh3YA/+RA1QAm/3Wgig/xelrOMizPl X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR08MB2761; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR08MB2761; X-Forefront-PRVS: 0450A714CB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(376002)(346002)(189002)(199003)(24454002)(377454003)(6116002)(6246003)(66066001)(7736002)(3846002)(47776003)(65956001)(6666003)(31686004)(88552002)(966005)(65806001)(413944005)(229853002)(106356001)(33646002)(4326008)(50466002)(2906002)(23746002)(6306002)(305945005)(53936002)(97736004)(75432002)(189998001)(53546010)(31696002)(81166006)(90366009)(117156002)(3260700006)(77096006)(81156014)(8676002)(6486002)(68736007)(6916009)(25786009)(478600001)(8936002)(86362001)(2950100002)(36756003)(101416001)(230700001)(54356999)(105586002)(16576012)(58126008)(65826007)(5660300001)(50986999)(64126003)(83506001)(316002)(76176999)(16526018)(786003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR08MB2761; H:[192.168.0.21]; 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: =?Windows-1252?Q?1; DM5PR08MB2761; 23:HvdNb+uj0Yd1PcAYYiA0YTdC3x9QDkuxybnx/?= =?Windows-1252?Q?Hs/m9fi6c7K6IUKcG0hyb18B6FL2iWa8zKOUoVyeyp7yM7CRLWD2tnoa?= =?Windows-1252?Q?bm/LrHO1z7iRh3MewRHhNKc5O/XcT1KTvTvXizD7c2H3zRky84u+/aRa?= =?Windows-1252?Q?enBkraNmDAclUCTD9KhGjlWAVEi+DrzTBEPxXuxIcUX8Q+zvvjQ1gh5u?= =?Windows-1252?Q?n9rmqIQGItB3cKy+ZGQ337GMfKb4JWtaK5AXm+XfOpt88hTq+vo1MzHc?= =?Windows-1252?Q?V5vKKR2s+CM7x1RRDfdqfZxMK0QZXeSyRMxyOChf3Uec+9xlomVmcQZh?= =?Windows-1252?Q?MWgF7Il7+8kLHXJAx2lz1EDGRcLOhD3PTeVf8OQ/M+0IF+y6NY73plh6?= =?Windows-1252?Q?vYAmMEnViIiXjLiIesnm9WplW7ksdK+abd99i1VqBhEM3XE+WWLC/gPo?= =?Windows-1252?Q?hqDEJrqjfa122SSwzxagGrUlv7nFGIdd4x1bKbcqXOeXwD4XFWtYTR7k?= =?Windows-1252?Q?Cxn/ZfANV/a9Wm5fUSrrwQZN3oil8JMbfkcmVE2aL5/7OnFT3FJ3pzQZ?= =?Windows-1252?Q?y7DDToQmZrxqc//X15Yh7zD/lL4gfY0NW+insfMFjE4VLKkXhYaLD8/x?= =?Windows-1252?Q?wM8kU108t0FadOoKxVBZ+6huTKpzQ04WODebWSssn9FWCMK+9am4CrFq?= =?Windows-1252?Q?i7LQvyfWdY+7jUktOCMjtVq6rCuZ5L8+emvnuttv37pVBgKLNmXIeEfc?= =?Windows-1252?Q?VxpH0dUEhJBBaG8KNpzdcL/64BR0jmLWoSqjj8DeDVhgDHs+CcQWVaBm?= =?Windows-1252?Q?B/TbrvQi3IEtqT35wxOMy27sgljAyXWVEro2BTQ3odSdUz1USrI+nHwT?= =?Windows-1252?Q?xloqTh8YknUSs9z0ofcdQZydvIcN07ftxIOdtjbWDWUYlUm38uWcNYjo?= =?Windows-1252?Q?/m9Gt2xX/Dv3QEwnIZ+wTUo5KAeN6Tya1UZwf50o3X5MJhX7h1/jcY0z?= =?Windows-1252?Q?Mxur+KVh28TIrlc4UqKfZyW1elLeD5tr5NCav4aY2L2dhHt7BDuxkniW?= =?Windows-1252?Q?uP3ESa5MB1U/R/FiE5zOlG+4K769k+/3NdKEvUQj8F4Mwx+ard2Q/522?= =?Windows-1252?Q?nXjpWCK0pZildUZmp9pbPTEZ3P/I78BJI4qfesob3Sgn7w7NjsYABjVQ?= =?Windows-1252?Q?kRv2mFJQb3KpXzhXmOC4pxbD5i4fqMIJ+Mh1AE3cXRRUR1rC04mya5rF?= =?Windows-1252?Q?8Cgp9EB3d58MJs9tsCWgqewjcMNksTqGU/d94sZWUaiIXuitPv8qvfK3?= =?Windows-1252?Q?9/QRcUUZdHNkaKkA17is18Vn5Dv0F4/nPziAm7AbxX+iV3q+KJct9Uyg?= =?Windows-1252?Q?lGOBbla+q96mqU4QhZ13wdyyEQgRRnYWIEGAmUno2GoaOOkcZyIbqUJK?= =?Windows-1252?Q?9d+Qx2akyJpXlSJdIqaRYFeQtOdbmID1Ib1LCZaE+Wzab2G9sFAXugnk?= =?Windows-1252?Q?Sw1iaqYErbFktm6ahA13I20EXLdwQKBiTmZSWPApWeGQTNpGLNC42i3D?= =?Windows-1252?Q?l1nuSTAa303K8SMzMQ/PFKZBPy1eQrmuW8LohFQ+y3QoY2sRKwx3eyUn?= =?Windows-1252?Q?GyB9yWKzWaC75rIa/2DfTCkj+WidLUCbIfWnXdSaic1?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR08MB2761; 6:RW6PoG3fbGm5DnE9d9cTsjMybubAcPeFr149kGLxvpRMrN3ablZHXtLJhttyxqV2MC021bx6br8VrmP/IQuxMScYcwRVUofoH5oMbTt+SeifNl3v0KFVrOTRnqkhwf+eVGP7vnopGc+bSgk2tWTsY3DImX9gSEbNKt73+XF0i82CiPuKS/qcqeM80IsWT3PnEk0xryeA2uL0MLn4q+AhmkVw3zH++/Xgjl6NZCnuqqcbNiAqcUmtNi8cNPoYKEhq1l1RhDrdgnur39QCGLNpOiTRuKwnDOdtONsgjUsx+2NUl/wi5bUaPE3oF3Cu8OG6Q2tyhxdy+i7RnIbHK0MVMQ==; 5:aMvAK+0Kg29qQoJFSFQwLcTnoN2SYgT1x5rEkhXrQp3J1UrA75s9fIWsSVWQYmkaXuAJr0iwExJLaPY1Dz426Z1ai8uoqg3XJFA1DYqQd6Sbj1LIDJoV8SgjD3mbtnzQvebGeJ3cMmhWPQq8JfB3Ew==; 24:bClFQbTn29gh1FFpKbpuaP6AZ8nWgrZX7NEWlg/NFSjSav86R5cg2D55L+DLtvGTRl7byQHZoP/AiB9fEYtCeNtRg2grWfbDbsiD/AlFh9E=; 7:DzHpolFBn2EXpBfSmrLdgoD5dPM7Qq0caleFHcyIstY9krRREQn4zCyXlYUJBcI+QnQVuYgp/ErLKwNcgcLG9UAwzoh9boIYKeMXlkU9mRk+2zTg8m5UEoG0iUkq4OwQitUfnjWnwNwxkkH0zXNC2k8LIc4HZ5ON39F+XVoxYLTZQjFEJtjB9AwvSJxrGaq/p8TEhL2jE5Cir7LwlrFAUxc3w/baPMZpNPVI+/TlNYo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2017 01:39:28.7619 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: fddb01ad-4983-436e-ab35-1af043b818c9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2761 Archived-At: Subject: Re: [tcpm] CUBIC hystart entering CA X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 04 Oct 2017 01:39:33 -0000 Dear Hiren, I believe your understanding is right that the traditional TCP Reno(AIMD) increases its cwnd one segment per RTT, whereas CUBIC increases its cwnd using a cubic function instead of a linear function (thus different amount of bytes). Thanks Lisong On 10/3/2017 11:11 AM, hiren panchasara wrote: > While here, I was wondering if following can be clarified a little more > in the draft: > > "While most alternative algorithms to Standard TCP uses a convex > increase function where during congestion avoidance the window > increment is always increasing, CUBIC uses both the concave and > convex profiles of a cubic function for window increase." > > I guess what's being suggested here is that CUBIC doesn't increment > window with the same *amount* of bytes like most standard TCP? > > Anyways, its probably obvious so will leave that up to you. Thanks a lot > for a quick response though. :-) > > Cheers, > Hiren > >> Thanks >> >> Lisong >> >> >> On 10/3/2017 10:15 AM, hiren panchasara wrote: >>> Looking for some help in understanding how to set cwnd when hystart >>> moves connection into CA mode. >>> >>> Draft says: >>> In the case when CUBIC runs the hybrid slow start [HR08], it may exit >>> the first slow start without incurring any packet loss and thus W_max >>> is undefined. In this special case, CUBIC switches to congestion >>> avoidance and increases its congestion window size using Eq. 1 where >>> K is set to 0 and W_max is set to the window size when CUBIC just >>> exits the slow start. >>> >>> Now, t = time since last congestion event. Which is essentially total >>> time the connection is alive as it hasn't seen any loss yet. i.e. can be >>> large. >>> >>> W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1) >>> >>> What I am observing is, this equation yields quite large window and >>> I believe at this point cwnd is set to that value as we follow cubic >>> cwnd growth as opposed to tcp-friendly region. >>> >>> This basically makes cwnd pretty large and moves connection into loss >>> much quicker defeating the purpose of hystart. >>> >>> Is this a correct analysis or am I missing something obvious? >>> >>> Cheers, >>> Hiren >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Oct 9 03:34:09 2017 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 0F1531344B6 for ; Mon, 9 Oct 2017 03:34:08 -0700 (PDT) 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=it-uc3m-es.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 lnY0ElD2S9D3 for ; Mon, 9 Oct 2017 03:34:05 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 3208D1344AA for ; Mon, 9 Oct 2017 03:34:05 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t69so21159866wmt.2 for ; Mon, 09 Oct 2017 03:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=msEOmGPaVlW1oKnlmLQxM5qk0u4d4MzGTFbSjelit38=; b=RgrcshsNpFJG2IbisK9zD8JVv2JfAvJfRXSqHKh3DWiyoEjeVNuda0/z+KbTAFpze7 rBr++dbu6Yf+7z2nWmAFAVbBZsb7DMqXzi58fSTbcf4Vb/wDUWs7DCN9t9Kf5z/DZmha 6fH5J8Md0gd0ZGkpUuU3YMJ0pRjKgLLoSu1QCEU49s1GX4qdlS8Ouo31li7uKUhMDLE+ tLXOG2+X5Q5g9abs8niugYOnpgSeMS4x7Xqg1uSVjoZy725UFVGjIy9uNwYxrSSls+Kb XiqhmUpDs9kkzdZl5vdARmumqjIQK/YI0BjG9xQu8qOQtpnKi/nPS9UhetxxTQLGfYVW SpKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=msEOmGPaVlW1oKnlmLQxM5qk0u4d4MzGTFbSjelit38=; b=ah6O96jg7eIUrHRms0aGyJ08dVmEdZLB5AdhZaf5ha/011oNZB4/0NNgvTwCBqRMjh N6Q/1BrxjWaOizQtkIs9ePXgkpPL4D5ILNvxhCMsgH1AOuqnXqCaMlJyzmMwbW9XjmxW y/hFC7AsOZXzK9J5NXYJXr/V1iSnwtE5B/8zmjiFrUYCu+n5ZsLU12EQxbt/z6urrMqW ITvoY37QHwEdSkBHE7o7GpRzbjSuGxG72fgH5fkhM24RHbZxwROJMQ++Sl+0RZL4hF01 U9llPAp5mTMQ8hdcBzqP4/gqEamaVKonpSJiZb6xbMaGpcGPJ8nUYKPH2c4GdMJ5SjsT dKFQ== X-Gm-Message-State: AMCzsaWt6hnVstk8wUvZuf0j0r75LWhdlWSQi4t3baFSytsuwuyRkaSU SwVl870f5azS7P/F71pkXa/IgA== X-Google-Smtp-Source: AOwi7QAwEOeER2C1r/dRXASAbCOQw/M05PGD3i7mLX29f/UAhJbl/qItW3qcEXHSkrpw1DpFe0jT1g== X-Received: by 10.28.56.198 with SMTP id f189mr8972017wma.16.1507545243591; Mon, 09 Oct 2017 03:34:03 -0700 (PDT) Received: from Macintosh-6.local ([2001:720:410:1010:d4cb:b7e5:e1f6:10ce]) by smtp.gmail.com with ESMTPSA id t43sm16546479wrc.74.2017.10.09.03.34.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 03:34:03 -0700 (PDT) To: tcpm IETF list , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Jana Iyengar , Anna Brunstrom From: marcelo bagnulo braun Message-ID: <839cc83c-f060-f812-c8e7-a2530798d6ee@it.uc3m.es> Date: Mon, 9 Oct 2017 12:34:02 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] ECN++: Whether to allow ECT/CE marking of pure ACKs and what response to recommend to feedback reporting that a pure ACK was CE marked. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Oct 2017 10:34:08 -0000 Hi, Regarding, draft-ietf-tcpm-generalized-ecn, we still have the open issue regarding whether to allow ECT/CE marking in pure acks and what response to reccomend if a pure ack encountered congestion. After considering the discussion in the last meeting and in the ml, we propose the following text in the draft: --------------------- For the experiments proposed here, the TCP implementation will set ECT on pure ACKs. It can ignore the requirement in section 6.1.4 of RFC 3168 to set not-ECT on a pure ACK. A host that sets ECT on pure ACKs SHOULD respond to the congestion signal resulting from pure ACKs being marked with the CE codepoint. The specific response will need to be defined as an update to each congestion control specification. Possible responses to congestion feedback include regulating the pure ACK rate (see AckCC [RFC5690]) or reducing the congestion window (CWND). However, if the congestion response implemented reduces the CWND upon the report of CE marking of Pure ACKs, then the congestion control algorithm must also increase the CWND upon delivery of pure ACKs without a CE mark, to avoid a bias in the congestion control algorithm. (We can also include some of the description of how to do this based on the text below for RFC3168 and AccECN in an appendix.) --------------------- Some background about this proposal: First of all, it's worth reminding that without ECN++, TCP currently is not required to detect loss of pure ACKs and is not required to react to them. The current draft states that it is allowed to ECT/CE mark the pure ACKs and that: " A host that sets ECT on pure ACKs MUST reduce its congestion window in response to any congestion feedback, in order to regulate any data segments it might be sending amongst the pure ACKs. It MAY also implement AckCC [RFC5690] to regulate the pure ACK rate, but this is not required. " The feedback we received in the Prague meeting was: - It is valuable to allow ECT/CE marking of pure ACK to avoid high drop rate when there is congestion. There is a strong case for ECN-capable pure ACKs as they are critical for connection performance. - The sender of the pure acks must respond (somehow) to the congestion signal resulting from getting CE marks in pure ACKs. Recommending not to respond to a received congestion signal seem like a bad recommendation to make in general and setting a bad precedent. There are two possible responses: reduce CWND (somehow) and/or ACK congestion control (ACK CC) (as defined in RFC5690). - The feedback regarding ACK CC is that it is too complex and with too many corner cases to mandate its implementation, so we should not mandate it. - Regarding reducing the CWND, there were several arguments against doing this. A very compelling argument is that since we do not increase the CWND when pure ACKs are successfully delivered, if we reduce the CWND when they are CE marked, then we have a strong bias towards reducing the CWND. In particular, in the case the one endpoint is only sending pure ACKs, the likely result is that the CWND will be 1 after a while. It is possible to address this issue by allowing the increase of CWND in case there are no CE marks in the pure ACKs. A possible approach for this would be the following: - if ECN++ is being used with RFC3168 ECN, then we simply do what is done with data packets, i.e. if during a RTT no ECE is received, the sender increases its CWND and if the sender receives one or more ECE marks, then it reduces its CWND. The only difference is that we include pure ACKs as well. - if ECN++ is used with AccECN, the situation is slightly more complex because the sender of the pure ACKs needs to keep track of the pure ACKs that got CE marked and those that didnt. But the sender of the pure ACKs knows how many pure ACKs it has sent. The other endpoint includes pure ACKs in the packet count of CE marked packets that is reported using AccECN, then the sender of the pure ACKs can figure out how many pure ACKs have been CE marked and how many were not. It then can feed this information to the congestion control algorithm. (The limitation of this approach is that lost pure ACKs are accounted as delivered pure ACKs without any CE marks, meaning that in the case of severe congestion, when pure ACKs are being dropped, the congestion control algorithm will include those lost pure ACK packets as delivered and increase the CWND the corresponding share. Since pure ACKs are small packets, it is not clear how much of a problem is this. Similarly (but worse), with 3168 feedback, even if detecting CE on pure ACKs, if pure ACKs are lost and there's no CE on a pure ACK within an RTT, cwnd will continue to increase. However, in both cases, it is still better with ECN++, because without ECN++ there was no response to either dropped or CE-marked pure ACKs.) It might be useful for the congestion response to be proportionate to an estimate of the bytes marked rather than packets marked, by adding an assumed header size on the wire to the size of every segment (otherwise pure ACKs would have zero size and not require any response). This would be up to the implementation. Note that the response to the congestion signal is outside the scope of draft-ietf-generalized-ecn, because it depends on the specific CC, e.g. Reno, Cubic, Compound, etc) That being said, we should include some guidance of what type of response is sensible, particularly for the standards track CC [RFC5681]. thoughts? Bob & Marcelo From nobody Mon Oct 9 04:58:04 2017 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 DD7F21321A4 for ; Mon, 9 Oct 2017 04:58:01 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 0LKFv3ckobcH for ; Mon, 9 Oct 2017 04:57:59 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C4B133020 for ; Mon, 9 Oct 2017 04:57:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3y9dzT5s94zMlpJ; Mon, 9 Oct 2017 13:57:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqlVY5e28RRt; Mon, 9 Oct 2017 13:57:56 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (pD9E11169.dip0.t-ipconnect.de [217.225.17.105]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 9 Oct 2017 13:57:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <839cc83c-f060-f812-c8e7-a2530798d6ee@it.uc3m.es> Date: Mon, 9 Oct 2017 13:57:55 +0200 Cc: tcpm IETF list , Jana Iyengar , Anna Brunstrom Content-Transfer-Encoding: quoted-printable Message-Id: <22CB67D2-B6BE-4AF2-8FBD-68C9F3F91F11@tik.ee.ethz.ch> References: <839cc83c-f060-f812-c8e7-a2530798d6ee@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tcpm] ECN++: Whether to allow ECT/CE marking of pure ACKs and what response to recommend to feedback reporting that a pure ACK was CE marked. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 09 Oct 2017 11:58:02 -0000 Hi Marcelo, sorry for top-posting but I=E2=80=99m actually not sure where exactly to = reply below because I think the situation is less complicated than you = described it below. First of all I think pure ACKs should not be ECT marked if AccECN is not = supported. Losing an ACK is less bad than losing a data packet but you = should not mark packets as ECT if there is no way to provide feedback to = the sender if congestion was experienced.=20 Then if you have AccECN it is actually not that much important if a pure = ACK or a data packet was marked. If there is a congestion marking that = means the link is congested and you should react to it. Now the question = is what=E2=80=99s the right reaction, and there multiple cases here: 1) You send pure ACKs interleaved with data packets that means your = congestion window might be large and any indicate of congestion should = trigger a congestion control reaction accordingly. 2) You only send pure ACKs; in this case your congestion window should = reduce to min_win sooner or later anyway; if there is congestion this = might happen a bit quicker but if there is congestion and you already = know about this, you should also not just resume sending with your = previous rate. Then if you are at min_cwnd you cannot reduce it any = further, therefore you MAY consider using AckCC in this case, or more = generally speaking apply some algorithm increase your delayed ack = factor. I really don=E2=80=99t think that increasing the congestion window based = on ACK is even a possible option. You don=E2=80=99t get ACKs for ACKs so = you never know if an ACK was successfully received. That means you = don=E2=80=99t even have any information that would allow you to react = on. Mirja =20 > Am 09.10.2017 um 12:34 schrieb marcelo bagnulo braun = : >=20 > Hi, >=20 > Regarding, draft-ietf-tcpm-generalized-ecn, we still have the open = issue regarding whether to allow ECT/CE marking in pure acks and what = response to reccomend if a pure ack encountered congestion. >=20 > After considering the discussion in the last meeting and in the ml, we = propose the following text in the draft: >=20 > --------------------- >=20 > For the experiments proposed here, the TCP implementation will set > ECT on pure ACKs. It can ignore the requirement in section 6.1.4 of > RFC 3168 to set not-ECT on a pure ACK. >=20 > A host that sets ECT on pure ACKs SHOULD respond to the congestion = signal resulting from pure ACKs being marked with the CE codepoint. The = specific response will need to be defined as an update to each = congestion control specification. Possible responses to congestion = feedback include regulating the pure ACK rate (see AckCC [RFC5690]) or = reducing the congestion window (CWND). >=20 > However, if the congestion response implemented reduces the CWND upon = the report of CE marking of Pure ACKs, then the congestion control = algorithm must also increase the CWND upon delivery of pure ACKs without = a CE mark, to avoid a bias in the congestion control algorithm. >=20 > (We can also include some of the description of how to do this based = on the text below for RFC3168 and AccECN in an appendix.) >=20 > --------------------- >=20 > Some background about this proposal: >=20 > First of all, it's worth reminding that without ECN++, TCP currently = is not required to detect loss of pure ACKs and is not required to react = to them. > The current draft states that it is allowed to ECT/CE mark the pure = ACKs and that: > " A host that sets ECT on pure ACKs MUST reduce its congestion = window > in response to any congestion feedback, in order to regulate any = data > segments it might be sending amongst the pure ACKs. It MAY also > implement AckCC [RFC5690] to regulate the pure ACK rate, but this is > not required. " >=20 > The feedback we received in the Prague meeting was: >=20 > - It is valuable to allow ECT/CE marking of pure ACK to avoid high = drop rate when there is congestion. There is a strong case for = ECN-capable pure ACKs as they are critical for connection performance. >=20 > - The sender of the pure acks must respond (somehow) to the congestion = signal resulting from getting CE marks in pure ACKs. Recommending not to = respond to a received congestion signal seem like a bad recommendation = to make in general and setting a bad precedent. >=20 > There are two possible responses: reduce CWND (somehow) and/or ACK = congestion control (ACK CC) (as defined in RFC5690). >=20 > - The feedback regarding ACK CC is that it is too complex and with too = many corner cases to mandate its implementation, so we should not = mandate it. >=20 > - Regarding reducing the CWND, there were several arguments against = doing this. A very compelling argument is that since we do not increase = the CWND when pure ACKs are successfully delivered, if we reduce the = CWND when they are CE marked, then we have a strong bias towards = reducing the CWND. In particular, in the case the one endpoint is only = sending pure ACKs, the likely result is that the CWND will be 1 after a = while. >=20 > It is possible to address this issue by allowing the increase of CWND = in case there are no CE marks in the pure ACKs. >=20 > A possible approach for this would be the following: >=20 > - if ECN++ is being used with RFC3168 ECN, then we simply do what is = done with data packets, i.e. if during a RTT no ECE is received, the = sender increases its CWND and if the sender receives one or more ECE = marks, then it reduces its CWND. The only difference is that we include = pure ACKs as well. >=20 > - if ECN++ is used with AccECN, the situation is slightly more complex = because the sender of the pure ACKs needs to keep track of the pure ACKs = that got CE marked and those that didnt. But the sender of the pure ACKs = knows how many pure ACKs it has sent. The other endpoint includes pure = ACKs in the packet count of CE marked packets that is reported using = AccECN, then the sender of the pure ACKs can figure out how many pure = ACKs have been CE marked and how many were not. It then can feed this = information to the congestion control algorithm. >=20 > (The limitation of this approach is that lost pure ACKs are accounted = as delivered pure ACKs without any CE marks, meaning that in the case of = severe congestion, when pure ACKs are being dropped, the congestion = control algorithm will include those lost pure ACK packets as delivered = and increase the CWND the corresponding share. Since pure ACKs are small = packets, it is not clear how much of a problem is this. Similarly (but = worse), with 3168 feedback, even if detecting CE on pure ACKs, if pure = ACKs are lost and there's no CE on a pure ACK within an RTT, cwnd will = continue to increase. However, in both cases, it is still better with = ECN++, because without ECN++ there was no response to either dropped or = CE-marked pure ACKs.) >=20 > It might be useful for the congestion response to be proportionate to = an estimate of the bytes marked rather than packets marked, by adding an = assumed header size on the wire to the size of every segment (otherwise = pure ACKs would have zero size and not require any response). This would = be up to the implementation. >=20 >=20 > Note that the response to the congestion signal is outside the scope = of draft-ietf-generalized-ecn, because it depends on the specific CC, = e.g. Reno, Cubic, Compound, etc) >=20 > That being said, we should include some guidance of what type of = response is sensible, particularly for the standards track CC [RFC5681]. >=20 > thoughts? >=20 > Bob & Marcelo >=20 From nobody Tue Oct 10 01:26:45 2017 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 36DCE1342DA for ; Tue, 10 Oct 2017 01:26:44 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.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 qXNBqlcTqIaf for ; Tue, 10 Oct 2017 01:26:40 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 8EEB7134A7D for ; Tue, 10 Oct 2017 01:25:46 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id m72so14733258wmc.0 for ; Tue, 10 Oct 2017 01:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=SFW/E32ZWPUK/W/Q71q1MmHZGasVAotiAelOPYyJYxg=; b=jYE2zc5eL45C0wACW1SMU07+FnYcRQIQp5Bg3r1lMDKgJNjsCHUCJun5OBSeJlqmjM tSBo+gd7PrvzuZStK4v4q4D7m8N65sHD3brooK+cyhWyjR4pNXlFIC9ABcXlv5H39OmZ ld62EmPoC0KndlLAChu/AFKmC9cWqmDIwyKvSovTVERXKwjKWTBOeD3P41maNIvgk4AF gByjYflE/l8dY2TLunJZ6S40UeNIwXJnVM/vyzhKPos509F8ttzNPL1aEmdd2bqSCyek 6xGhcqMxZyTwpvf7vzW4ylNIXWeHPx2K05Av4aofBlH9CfdtaNdWQUsb7s8zCNR37TiR quEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SFW/E32ZWPUK/W/Q71q1MmHZGasVAotiAelOPYyJYxg=; b=RtDLKbREmsNE2/JFERgKBF49SBK9O02az9ZHH60MtuRjfTK5FUcGPPUHnQPyWg7745 Mgoi0aF51zOf4PkWKfRCE49DL6QZdkPHzmLV/mbwK+jC7kSTIfe5WIXd/1wsQE+QJ+kQ MzgJIJTizKqSN5Y9fySSLj7/GObXDE6TZhESKAfB1iuVvZbRbMpGZqhMWS+UD+CAIna1 xFp3P+CZuF8tifSyGGOYoZ7lisfh+oPKAcMkWIPo1LIdJsl2RA6FKxtw2lBtINWY+LbY oL2prL2IYL7nTfTIcNpC/GUqXj7b6vhOrkZ1H1f2M25BfDOzt3iB3/jCZ1BZDyiBqNUc jhcQ== X-Gm-Message-State: AMCzsaWcPX3w0QwFkQxqf7m3K4bx8O/QOmlEq2iN0JU5dAJR0T/47hiY dMN1fVHEDv+KoYjWkMzcDhsGDgU5 X-Google-Smtp-Source: AOwi7QCpMZ1S1RfDYwi5gWpRU2zUlenTPW2jI/3YbW7Z/QCcAFPmCFcH+yujMoTSWvcWaDRGf7eHcQ== X-Received: by 10.28.54.22 with SMTP id d22mr9554197wma.120.1507623944881; Tue, 10 Oct 2017 01:25:44 -0700 (PDT) Received: from Macintosh-6.local ([2001:720:410:1010:bc28:5587:82ea:a67c]) by smtp.gmail.com with ESMTPSA id m19sm5645111wma.24.2017.10.10.01.25.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Oct 2017 01:25:44 -0700 (PDT) To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <839cc83c-f060-f812-c8e7-a2530798d6ee@it.uc3m.es> <22CB67D2-B6BE-4AF2-8FBD-68C9F3F91F11@tik.ee.ethz.ch> Cc: tcpm IETF list , Jana Iyengar , Anna Brunstrom From: marcelo bagnulo braun Message-ID: <76f10b55-0538-0832-3b58-5226ee39959e@it.uc3m.es> Date: Tue, 10 Oct 2017 10:25:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <22CB67D2-B6BE-4AF2-8FBD-68C9F3F91F11@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] ECN++: Whether to allow ECT/CE marking of pure ACKs and what response to recommend to feedback reporting that a pure ACK was CE marked. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Oct 2017 08:26:44 -0000 Hi Mirja, Thanks for your reply. I understand that what you are proposing is that we only allow ECT marking of pure ACKs when AccECN is negotiated and that upon the reception of a signal informing that a pure ACK was CE marked, the sender must reduce its CWND as with any other packet, is that so? some further questions below.... El 09/10/17 a las 13:57, Mirja Kühlewind escribió: > Hi Marcelo, > > sorry for top-posting but I’m actually not sure where exactly to reply below because I think the situation is less complicated than you described it below. > > First of all I think pure ACKs should not be ECT marked if AccECN is not supported. Losing an ACK is less bad than losing a data packet but you should not mark packets as ECT if there is no way to provide feedback to the sender if congestion was experienced. I am not sure i understand why you say that when AccECN is not supported, there is not mean to provide feedback to the sender. Wouldnt the receiver simply set the ECE flag in packets going in the other direction upon the reception of a pure ACK with the CE mark? > Then if you have AccECN it is actually not that much important if a pure ACK or a data packet was marked. Actually, people make the argument that there is a difference between data packets and pure ACKs. The concern people expressed it that reducing the CWND based on CE marks on pure ACK introduces a bias, since the sender reduces the CWND when Pure ACKs experience congestion but the sender does not increase the CWND when the pure ACK does not experience congestion. This is a fundamental concern, i believe and it is irrespective whether there is data traffic along with pure ACKs, i think. In AccECN, the bias can be less, i think, because since the pure ACK has not data, the amount of bits that experienced congestion is small, so the bias is small. This is the reason why i think it is more acceptable to have this behaviour with AccECN than with no AccECN. So, my understanding is that the options are - not ECN marking of pure ACKs, which results in higher loss probability - marking pure ACKs but not responding to congestion, bad precedent - marking pure ACKs and responding to congestion, bias towards decreasing the CWND - marking pure ACKs, responding to congestion and adding some way to increase the CWND, complicated and inaccurate. So, from my side, I think your proposal of only supporting ECN marking of pure ACK when AccECN is supported seems a good trade-off, while not perfect, may be a good way forward > If there is a congestion marking that means the link is congested and you should react to it. Now the question is what’s the right reaction, and there multiple cases here: > > 1) You send pure ACKs interleaved with data packets that means your congestion window might be large and any indicate of congestion should trigger a congestion control reaction accordingly. > > 2) You only send pure ACKs; in this case your congestion window should reduce to min_win sooner or later anyway; if there is congestion this might happen a bit quicker but if there is congestion and you already know about this, you should also not just resume sending with your previous rate. Then if you are at min_cwnd you cannot reduce it any further, therefore you MAY consider using AckCC in this case, or more generally speaking apply some algorithm increase your delayed ack factor. See above, the concern here is the biased introduced towards reducing the CWND. > I really don’t think that increasing the congestion window based on ACK is even a possible option. You don’t get ACKs for ACKs so you never know if an ACK was successfully received. That means you don’t even have any information that would allow you to react on. You do get some idea of what ACKs got through, but i agree that given the cumulative nature of ACKs, some acks can get lost undetected. I agree this is not perfect, but not of the options are. That being said, I also think that this option introduces complexity with little benefit, so if all solutions are imperfect, we should at least choose one that is at least simple. Regards, marcelo > Mirja > > >> Am 09.10.2017 um 12:34 schrieb marcelo bagnulo braun : >> >> Hi, >> >> Regarding, draft-ietf-tcpm-generalized-ecn, we still have the open issue regarding whether to allow ECT/CE marking in pure acks and what response to reccomend if a pure ack encountered congestion. >> >> After considering the discussion in the last meeting and in the ml, we propose the following text in the draft: >> >> --------------------- >> >> For the experiments proposed here, the TCP implementation will set >> ECT on pure ACKs. It can ignore the requirement in section 6.1.4 of >> RFC 3168 to set not-ECT on a pure ACK. >> >> A host that sets ECT on pure ACKs SHOULD respond to the congestion signal resulting from pure ACKs being marked with the CE codepoint. The specific response will need to be defined as an update to each congestion control specification. Possible responses to congestion feedback include regulating the pure ACK rate (see AckCC [RFC5690]) or reducing the congestion window (CWND). >> >> However, if the congestion response implemented reduces the CWND upon the report of CE marking of Pure ACKs, then the congestion control algorithm must also increase the CWND upon delivery of pure ACKs without a CE mark, to avoid a bias in the congestion control algorithm. >> >> (We can also include some of the description of how to do this based on the text below for RFC3168 and AccECN in an appendix.) >> >> --------------------- >> >> Some background about this proposal: >> >> First of all, it's worth reminding that without ECN++, TCP currently is not required to detect loss of pure ACKs and is not required to react to them. >> The current draft states that it is allowed to ECT/CE mark the pure ACKs and that: >> " A host that sets ECT on pure ACKs MUST reduce its congestion window >> in response to any congestion feedback, in order to regulate any data >> segments it might be sending amongst the pure ACKs. It MAY also >> implement AckCC [RFC5690] to regulate the pure ACK rate, but this is >> not required. " >> >> The feedback we received in the Prague meeting was: >> >> - It is valuable to allow ECT/CE marking of pure ACK to avoid high drop rate when there is congestion. There is a strong case for ECN-capable pure ACKs as they are critical for connection performance. >> >> - The sender of the pure acks must respond (somehow) to the congestion signal resulting from getting CE marks in pure ACKs. Recommending not to respond to a received congestion signal seem like a bad recommendation to make in general and setting a bad precedent. >> >> There are two possible responses: reduce CWND (somehow) and/or ACK congestion control (ACK CC) (as defined in RFC5690). >> >> - The feedback regarding ACK CC is that it is too complex and with too many corner cases to mandate its implementation, so we should not mandate it. >> >> - Regarding reducing the CWND, there were several arguments against doing this. A very compelling argument is that since we do not increase the CWND when pure ACKs are successfully delivered, if we reduce the CWND when they are CE marked, then we have a strong bias towards reducing the CWND. In particular, in the case the one endpoint is only sending pure ACKs, the likely result is that the CWND will be 1 after a while. >> >> It is possible to address this issue by allowing the increase of CWND in case there are no CE marks in the pure ACKs. >> >> A possible approach for this would be the following: >> >> - if ECN++ is being used with RFC3168 ECN, then we simply do what is done with data packets, i.e. if during a RTT no ECE is received, the sender increases its CWND and if the sender receives one or more ECE marks, then it reduces its CWND. The only difference is that we include pure ACKs as well. >> >> - if ECN++ is used with AccECN, the situation is slightly more complex because the sender of the pure ACKs needs to keep track of the pure ACKs that got CE marked and those that didnt. But the sender of the pure ACKs knows how many pure ACKs it has sent. The other endpoint includes pure ACKs in the packet count of CE marked packets that is reported using AccECN, then the sender of the pure ACKs can figure out how many pure ACKs have been CE marked and how many were not. It then can feed this information to the congestion control algorithm. >> >> (The limitation of this approach is that lost pure ACKs are accounted as delivered pure ACKs without any CE marks, meaning that in the case of severe congestion, when pure ACKs are being dropped, the congestion control algorithm will include those lost pure ACK packets as delivered and increase the CWND the corresponding share. Since pure ACKs are small packets, it is not clear how much of a problem is this. Similarly (but worse), with 3168 feedback, even if detecting CE on pure ACKs, if pure ACKs are lost and there's no CE on a pure ACK within an RTT, cwnd will continue to increase. However, in both cases, it is still better with ECN++, because without ECN++ there was no response to either dropped or CE-marked pure ACKs.) >> >> It might be useful for the congestion response to be proportionate to an estimate of the bytes marked rather than packets marked, by adding an assumed header size on the wire to the size of every segment (otherwise pure ACKs would have zero size and not require any response). This would be up to the implementation. >> >> >> Note that the response to the congestion signal is outside the scope of draft-ietf-generalized-ecn, because it depends on the specific CC, e.g. Reno, Cubic, Compound, etc) >> >> That being said, we should include some guidance of what type of response is sensible, particularly for the standards track CC [RFC5681]. >> >> thoughts? >> >> Bob & Marcelo >> > From nobody Tue Oct 10 04:42:13 2017 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 7B79B1344EB for ; Tue, 10 Oct 2017 04:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 CMzfezXXUWXn for ; Tue, 10 Oct 2017 04:42:09 -0700 (PDT) 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 27EB6134D02 for ; Tue, 10 Oct 2017 04:40:53 -0700 (PDT) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89.118) id 1e1su3-0007Tl-2p for tcpm@ietf.org (return-path ); Tue, 10 Oct 2017 11:40:51 +0000 To: tcpm@ietf.org References: <839cc83c-f060-f812-c8e7-a2530798d6ee@it.uc3m.es> <22CB67D2-B6BE-4AF2-8FBD-68C9F3F91F11@tik.ee.ethz.ch> <76f10b55-0538-0832-3b58-5226ee39959e@it.uc3m.es> From: Jeremy Harris Message-ID: <7acd40bc-856a-c461-8164-8c344e62b3e6@wizmail.org> Date: Tue, 10 Oct 2017 12:40:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <76f10b55-0538-0832-3b58-5226ee39959e@it.uc3m.es> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [tcpm] ECN++: Whether to allow ECT/CE marking of pure ACKs and what response to recommend to feedback reporting that a pure ACK was CE marked. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 10 Oct 2017 11:42:11 -0000 On 10/10/17 09:25, marcelo bagnulo braun wrote: > So, my understanding is that the options are > - not ECN marking of pure ACKs, which results in higher loss probability > - marking pure ACKs but not responding to congestion, bad precedent > - marking pure ACKs and responding to congestion, bias towards > decreasing the CWND > - marking pure ACKs, responding to congestion and adding some way to > increase the CWND, complicated and inaccurate. - marking pure ACKs and responding to congestion via CWND (bias towards decreasing the CWND) plus ACKcc -- Jeremy From nobody Tue Oct 10 21:30:51 2017 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 91FCA133044; Tue, 10 Oct 2017 21:30:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-tcpm-cubic@ietf.org, Yoshifumi Nishida , tcpm-chairs@ietf.org, nishida@sfc.wide.ad.jp, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150769624359.24807.7453328458969104483.idtracker@ietfa.amsl.com> Date: Tue, 10 Oct 2017 21:30:43 -0700 Archived-At: Subject: [tcpm] Spencer Dawkins' Yes on draft-ietf-tcpm-cubic-06: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 04:30:44 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-tcpm-cubic-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm really glad to see this specification entering IESG Evaluation. I have a few comments, but most are editorial or (at most) about improving clarity. In this text, In a smaller BDP network where Standard TCP flows are working well, the absolute amount of the window decrease at a loss event is always smaller because of the multiplicative decrease. I got lost on "always smaller" than what - than Standard TCP? Or CUBIC? Or something else? Nit: Is "weithed" "weighted", or is it something else? In 4.7. Timeout In case of timeout, CUBIC follows the standard TCP to reduce cwnd, but sets ssthresh using beta_cubic (same as in Section 4.5). should "standard TCP" be "Standard TCP"? I wasn't watching for other occurrences of "standard TCP", but I noticed a bunch of them. In this text, CUBIC MUST employ a slow start algorithm, when the cwnd is no more than ssthresh. Among the slow start algorithms, CUBIC MAY choose the standard TCP slow start [RFC5681] in general networks, or the limited slow start [RFC3742] or hybrid slow start [HR08] for high-bandwidth and long-distance networks. is there any guidance you can give implementers about when to choose specific slow start algorithms? In 5.10. Incremental Deployment CUBIC requires only the change of TCP senders, and does not require any assistant of routers. I'm not parsing the sentence. Is it saying CUBIC requires only changes to TCP senders, and does not require any changes to routers. ? Either way, it might be worth pointing out here that no changes to TCP receivers are required, either. From nobody Wed Oct 11 08:37:12 2017 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 7FAB612ECEC; Wed, 11 Oct 2017 08:37:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-tcpm-cubic@ietf.org, Yoshifumi Nishida , tcpm-chairs@ietf.org, nishida@sfc.wide.ad.jp, tcpm@ietf.org, bill.wu@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150773622551.24759.48027156263820666.idtracker@ietfa.amsl.com> Date: Wed, 11 Oct 2017 08:37:05 -0700 Archived-At: Subject: [tcpm] Benoit Claise's No Objection on draft-ietf-tcpm-cubic-06: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 15:37:06 -0000 Benoit Claise has entered the following ballot position for draft-ietf-tcpm-cubic-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some minor issues from Qin Wu's OPS DIR review needs to be taken care of (as agreed by Mirja) From nobody Wed Oct 11 11:27:43 2017 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 49701126B6D; Wed, 11 Oct 2017 11:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=KWzr9O1L; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UQxBC+/P 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 XFaBQIKY2nZF; Wed, 11 Oct 2017 11:27:39 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E729126B6E; Wed, 11 Oct 2017 11:27:39 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DF9D320BE9; Wed, 11 Oct 2017 14:27:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 11 Oct 2017 14:27:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=axOnjNvCd2b3++nUY2or+g/vFUsGX lmhFND8IRI4KOw=; b=KWzr9O1L4w8FWzI/abb64g0wfO4E8an10I9pFJ2bL5HTt bswRAcGbd2ipS2uKpEM/LUGPQrDE/URrUkh06zrfANlX5V/FeVdoADh9dqumf2xp EptHQG2ox8YE7PRNVQX0dOyaUvB3c78qgG53nXlSFQy3XP0BhVHkeHFizSwezF6n zc3L82BslEtPKZGpo6Mo6jIN72EixLYq0TPMTILNGqGDn/7H+lk77XlHexlH/40p 8aw4ipUqLK6lZPv+HVdLDUYnjuzYp1+57blaIpyPh7ihLgEesLarbKta2Pi5EPKr YbsO42/sOqZPN9SfYjbbwD4KRrjVZ/9RLJQvBlIlQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=axOnjN vCd2b3++nUY2or+g/vFUsGXlmhFND8IRI4KOw=; b=UQxBC+/PjEQDDzWKVRds73 Cugk+vwPPm7nEgEZBSjevmlDS9PFCMDjcQSurpANLdT3+skK3S4oFPvV4x7MwtQZ uT8nAHRYyxcfPsbkSTwpS+HECk9icVJuWhZ8IDdvLgeOD4KcAW3qOWmANwEDjIN3 NQhSmay2uXzJ7RIMYc9cO3kwPQaqraUFqva3TFQ3FgUfBfzWlaI1tI+4gjr3zCmY Iqb3/qQfr0tqKoVEO0K5igrhckCJqwHcKFi73/glAmshEqeNP2nJy08CKANhoZsL KRAyi/ljwxUplhRdljVGLUGmwTTnJz/glatQu6G4R5oS7S21G8rYo6J4XPXzy14w == X-ME-Sender: Received: from sjc-alcoop-88112.cisco.com (unknown [128.107.241.182]) by mail.messagingengine.com (Postfix) with ESMTPA id D58D324735; Wed, 11 Oct 2017 14:27:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <150610688453.16831.3652838434219802004@ietfa.amsl.com> Date: Wed, 11 Oct 2017 14:27:35 -0400 Cc: gen-art , tcpm@ietf.org, draft-ietf-tcpm-cubic.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <4970470C-6CF0-42B7-8085-63A28BED81FF@cooperw.in> References: <150610688453.16831.3652838434219802004@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [tcpm] [Gen-art] Genart last call review of draft-ietf-tcpm-cubic-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Oct 2017 18:27:41 -0000 Joel, thank you for your review. I have entered a No Objection ballot. Alissa > On Sep 22, 2017, at 3:01 PM, Joel Halpern wrote: > > Reviewer: Joel Halpern > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-tcpm-cubic-06 > Reviewer: Joel Halpern > Review Date: 2017-09-22 > IETF LC End Date: 2017-10-02 > IESG Telechat date: 2017-10-12 > > Summary: This Document is ready for publication as an Informational RFC. > > Major issues: N/A > > Minor issues: N/A > > Nits/editorial comments: N/A > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Oct 11 14:50:10 2017 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 398461326ED for ; Wed, 11 Oct 2017 14:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 ddIbcQPSnOPC for ; Wed, 11 Oct 2017 14:50:08 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id 38EA61320D9 for ; Wed, 11 Oct 2017 14:50:08 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 5B1E217F8B for ; Wed, 11 Oct 2017 14:50:11 -0700 (PDT) Date: Wed, 11 Oct 2017 14:50:11 -0700 From: hiren panchasara To: tcpm@ietf.org Message-ID: <20171011215011.GH19289@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YrlhzR9YrZtruaFS" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Oct 2017 21:50:09 -0000 --YrlhzR9YrZtruaFS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Looking at TLP draft and RACK draft, Open state: the sender has so far received in-sequence ACKs with no SACK blocks, and no other indications (such as retransmission timeout) that a loss may have occurred. So, loss probes are not scheduled after the first SACK block seen on the connection? Shouldn't they be scheduled as long as the connection is not in recovery? Or am I missing something? Any clarification would be great. Cheers, Hiren --YrlhzR9YrZtruaFS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJZ3pIQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lXJsH/RLTnTBbeqOD0KpIrY6dvMPU VJpxA95e6FMIrTmWBNZjfmbM5XU7gA2aDvjBZGklLIXli+YqzvRCuLdvvdjL7jcM TV9tkYlvktV+B55Ov1fcO+tGKstl0UErjuz7RhJ4atQ/Vd00RWZknl1DBPT3oDDi IPGlmSi5dRGGYmZEYLru9ZAo5/fqYe/hPfmG9BR1dTH0DR9GVSqlFfMFQE6BfBrc ol3nGSd22GyHjgZnkAb6cqKNdu589Ip+VHDWRZltK7WpstRmiaSyua2vHRc0fFa1 zhnU6riaVBaF3qYpJQD5FtjREZLlLQphMlDqsgEfRTlKapkG5+yL3stNDsT0fpk= =sPKq -----END PGP SIGNATURE----- --YrlhzR9YrZtruaFS-- From nobody Wed Oct 11 15:41:03 2017 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 3AE041320D9 for ; Wed, 11 Oct 2017 15:41:00 -0700 (PDT) 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=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 vcDGsOoZmoPI for ; Wed, 11 Oct 2017 15:40:58 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 97782133061 for ; Wed, 11 Oct 2017 15:40:58 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id i124so8770328wmf.3 for ; Wed, 11 Oct 2017 15:40:58 -0700 (PDT) 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=4FPwVsdxrjxvlpVQ+GlXmCO7j+9OKgSZ69wV5VgdSVc=; b=HhhMrj58zW7Nj2z7asHnX+e9Kuv2XjwRj5tnCae9GlVmCRkY0CHhSoS1x7kvh3xqm6 vxB6CzhLaqvL4RBFtSxoUdeB5ixopcH8JJGF3wvS3ASl8OFAqhf8QryGaoQHqH5FRaTJ ecI+jPMH1KLTAWzPaBoLtQDHtXzySWWof09lfEkIiFEVjVag3OtCzieV3G7sETCQ/77E Qp/A4DAfa0dH5nf1Rd/dzC+oV9eaSuFmAVrm+mNfHEBDbPvrs92Pu0FAdA14WDuyLuru 6FkyiWnlpZq0uqfgrdGPfWAOApOvGActc6ABXe4dBhoLAWT3xLhlHTbvJ9OyoJ57G+p6 xP4g== 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=4FPwVsdxrjxvlpVQ+GlXmCO7j+9OKgSZ69wV5VgdSVc=; b=bnjWF2CcdJ0IR0w71n8atBq3jwNlPCYmVpYmrVe4orsNDdjfCbc8bmJaEu8J5DtBuT bOX8fHlAg6q2+j0CepP1PBlKntIZ4xKhAsGRGPazfraOHZA/ad9DbeJfcyV3EC/EE25i vh1STm3Git5jyxEZxbeYXRXw9FvsVZEnjhLIEUFWRxjpN8EONnANB5f+KO06lQTLfRtL QeeRSnmY8P6+4Z1/SuvVTOW/SIkpky1MIMSjGK/e1sakZwEDvbGxgy8HSxdHDhKmkx9t G0u2GA9laz+mbEaYTJdmKl3S9Dh1MRiNgYSabUPg1xs5mxnMDUgwAKMh05I/399QEuqw Eayw== X-Gm-Message-State: AMCzsaWugGVUz/BN5Kl/j3WKpJ/sTDkeel7frYy05Mz4PVwph6vUpXyl WbGRtNQiIFzhAa9xt/rRPzxVrvJLKAkcwPeVHYXqyl9dBWc= X-Google-Smtp-Source: AOwi7QD0vYFZvk1vnAFMHdolvSzMpQCqevnYPm3yhmlmiwmu1ZfLigcNs3bq56z9F3c0nffIhWSzEtNNtH502W8QJAY= X-Received: by 10.223.177.139 with SMTP id q11mr426009wra.77.1507761656984; Wed, 11 Oct 2017 15:40:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.146.137 with HTTP; Wed, 11 Oct 2017 15:40:36 -0700 (PDT) In-Reply-To: <20171011215011.GH19289@strugglingcoder.info> References: <20171011215011.GH19289@strugglingcoder.info> From: Neal Cardwell Date: Wed, 11 Oct 2017 22:40:36 +0000 Message-ID: To: hiren panchasara Cc: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Oct 2017 22:41:00 -0000 On Wed, Oct 11, 2017 at 9:50 PM, hiren panchasara wrote: > > Looking at TLP draft and RACK draft, > > Open state: the sender has so far received in-sequence ACKs with no > SACK blocks, and no other indications (such as retransmission > timeout) that a loss may have occurred. > > So, loss probes are not scheduled after the first SACK block seen on the > connection? Right. > Shouldn't they be scheduled as long as the connection is > not in recovery? Or am I missing something? If there is a SACK block seen, then the sender should be scheduling a RACK timer, which would fire faster than the TLP timer anyway. Basically, if there is a SACK block then you have info about how long it should have taken for the previous packets to arrive. A TLP is a probe, intended for when there is no feedback at all arriving at the sender. cheers, neal From nobody Wed Oct 11 16:24:32 2017 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 E270613301B for ; Wed, 11 Oct 2017 16:24:30 -0700 (PDT) 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] 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 SwDv3Ph8Z3I2 for ; Wed, 11 Oct 2017 16:24:29 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id B738D132025 for ; Wed, 11 Oct 2017 16:24:29 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id C9FF0170CB; Wed, 11 Oct 2017 16:24:32 -0700 (PDT) Date: Wed, 11 Oct 2017 16:24:32 -0700 From: hiren panchasara To: Neal Cardwell Cc: "tcpm@ietf.org" Message-ID: <20171011232432.GJ19289@strugglingcoder.info> References: <20171011215011.GH19289@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d6iqOn7HZPWKXx18" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Oct 2017 23:24:31 -0000 --d6iqOn7HZPWKXx18 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/11/17 at 10:40P, Neal Cardwell wrote: > On Wed, Oct 11, 2017 at 9:50 PM, hiren panchasara > wrote: > > > > Looking at TLP draft and RACK draft, > > > > Open state: the sender has so far received in-sequence ACKs with no > > SACK blocks, and no other indications (such as retransmission > > timeout) that a loss may have occurred. > > > > So, loss probes are not scheduled after the first SACK block seen on the > > connection? >=20 > Right. >=20 > > Shouldn't they be scheduled as long as the connection is > > not in recovery? Or am I missing something? >=20 > If there is a SACK block seen, then the sender should be scheduling a > RACK timer, which would fire faster than the TLP timer anyway. >=20 > Basically, if there is a SACK block then you have info about how long > it should have taken for the previous packets to arrive. A TLP is a > probe, intended for when there is no feedback at all arriving at the > sender. So, I think the idea is that a SACK block is all RACK needs to start marking previous packets as lost. I am still confused by how these 2 conditions are different wrt TLP: 1) slow-start before receiving any SACK=20 2) Congestion avoidance after a loss-recovery episode is finished and connection is humming along Now if acks stop arriving, we send loss probe in case of 1) but not in case of 2). How would RACK detect those "tail" packets lost in that situation for 2)? Probably I am missing something here. :-) Thanks for taking time and responding. Cheers, Hiren --d6iqOn7HZPWKXx18 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJZ3qgtXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lwdcH/RAdPQZhqPA9YEeOEg21xzHf X8xRGVtaDa0sm4srjxi69eZ4tshE8eqrVCZdnqj+Ephstw1v5OOB/nBYH9iDQR8Q pF1A8UQ5Hcwb5ZsBv2ZpwWDJ/8lRZgw4IS6iDpS3Q4N9iB4HdkUr5IZ2h2qhXoIm wnUHy8zLozadloUd9XzA6Obcl6sHATJGsWm3JFVtKoSXER69HCerwBrLCICAB1Zs BipMlEkjXiiiOJHdkjhODza/GM970nywCmHygW25IVPQBekhBlejGPJd69XIDB3T h/Fc+NhBSG6sUrQMjRxzoRqc5AIq2g0nNIKvLC6ZgABIUXkvcHKYVZhcTgzAgyo= =Rzqe -----END PGP SIGNATURE----- --d6iqOn7HZPWKXx18-- From nobody Wed Oct 11 16:38:33 2017 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 3C2CB132939 for ; Wed, 11 Oct 2017 16:38:32 -0700 (PDT) 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=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 NpM-GpUIeLHU for ; Wed, 11 Oct 2017 16:38:30 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 84BF4133072 for ; Wed, 11 Oct 2017 16:38:30 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id d10so3834568lfg.11 for ; Wed, 11 Oct 2017 16:38:30 -0700 (PDT) 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=0p4WKRTuGYqjQ7ac+E08TsHC1r1FcLTlKSzbK6RfOxA=; b=S/iU3be7sqPM8DWVTxz+X1LO9pVu2yB7hIe+XdY0xzAirYYTYy7gWUnfgVUPQxUEd0 5fD07X18O04p1acqCe7n4FjRo5xHMUmnsePHGLSfWXP/hITvxvXCyOdyzKW18+nA3sTV +OodHN5/z8espA7TVVhzpCjaFSAEvSOtRD6K+apzF1k0HdXiSEedMxBg0aGbthimVyUM WcWrsiurldsNqvAVMrSCLKmVh46uML0TQJr/0HDDE8PvUXe59oTNC7g0Ojqp+qcquQNN qHprJlylJPRsQ+kOIryn270ljjtVtbvb9nrAT1+fRTzgQjWKNTIr29JRhKpD0wnQ3jKd 4h2g== 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=0p4WKRTuGYqjQ7ac+E08TsHC1r1FcLTlKSzbK6RfOxA=; b=q5C7uP8DZm0KEAoVBI9Cd6O7ygjQH2NbLsY1NN5cVO/hr015oVX3WagGXcGzYV0MsT B71z6teGmqIJtZaoqKiHktl8rc55srRIbUVyniLbNCRSygQaWG9gj+4k3B6g5H1YST1E 81Re0IpBIsTmojaFzrUpFMnH2q9LgKA8qfUX3DVB5JC67bNKuNvuZa+3DUloSztAirb6 o1NrmpW41kTk9wAiwPR0P0D/6FozykkajKg1q2B7z29uCTL6dp2xiPiRgl2+nSV/cOSW IXfbrNHRiVa11KkZoPJZ7x+UOq+O86W6SmoU9IbvWn2RXBvhEYQ7ttu6sH3jcLcm0sJ8 9y3Q== X-Gm-Message-State: AMCzsaVPMxmNUAVrJPPXuDUTg1dudEHBfQ9mS28wECFdVYxRouBQ51l+ WlZv09B7kCgO1+0KjxFU2vQqtLVUZ/yVPwoe1FJjG1W5kaY= X-Google-Smtp-Source: ABhQp+T9M+kF7P5Ji2yKyi9c2YDP3xqMmxo4Ug3lS2cKt3kBOJ31dLfUVvdKgBzehH7+6+DL7ICOWS5RfJmEqg1p6kY= X-Received: by 10.28.127.206 with SMTP id a197mr327061wmd.12.1507765108480; Wed, 11 Oct 2017 16:38:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.146.137 with HTTP; Wed, 11 Oct 2017 16:38:07 -0700 (PDT) In-Reply-To: <20171011232432.GJ19289@strugglingcoder.info> References: <20171011215011.GH19289@strugglingcoder.info> <20171011232432.GJ19289@strugglingcoder.info> From: Neal Cardwell Date: Wed, 11 Oct 2017 23:38:07 +0000 Message-ID: To: hiren panchasara Cc: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Oct 2017 23:38:32 -0000 On Wed, Oct 11, 2017 at 11:24 PM, hiren panchasara wrote: > On 10/11/17 at 10:40P, Neal Cardwell wrote: >> On Wed, Oct 11, 2017 at 9:50 PM, hiren panchasara >> wrote: >> > >> > Looking at TLP draft and RACK draft, >> > >> > Open state: the sender has so far received in-sequence ACKs with no >> > SACK blocks, and no other indications (such as retransmission >> > timeout) that a loss may have occurred. >> > >> > So, loss probes are not scheduled after the first SACK block seen on the >> > connection? >> >> Right. >> >> > Shouldn't they be scheduled as long as the connection is >> > not in recovery? Or am I missing something? >> >> If there is a SACK block seen, then the sender should be scheduling a >> RACK timer, which would fire faster than the TLP timer anyway. >> >> Basically, if there is a SACK block then you have info about how long >> it should have taken for the previous packets to arrive. A TLP is a >> probe, intended for when there is no feedback at all arriving at the >> sender. > > So, I think the idea is that a SACK block is all RACK needs to start > marking previous packets as lost. Yes. > I am still confused by how these 2 conditions are different wrt TLP: > 1) slow-start before receiving any SACK > 2) Congestion avoidance after a loss-recovery episode is finished and > connection is humming along These are not different with respect to TLP. Those are 2 different states in the congestion control algorithm state machine. But TLP does not care about the congestion control algorithm state machine. TLP only cares about the loss recovery state machine. We used the term "Open state" in the draft to refer to the state in a loss recovery state machine when there are no SACKed sequence ranges in the SACK scoreboard, and we are not in the middle of fast recovery or timeout recovery (the terminology is borrowed from the Linux TCP loss recovery state machine's TCP_CA_Open state). > Now if acks stop arriving, we send loss probe in case of 1) but not in > case of 2). Nope, both (1) and (2) are in the "Open state" in the loss recovery state machine, so we would send a TLP in either case. I think the sentence in the draft is ambiguous. It seems you interpreted "so far" to mean "so far in the lifetime of the connection", when the draft is trying to convey "so far in the current loss recovery epoch" (or something like that). :-) We will try to clarify that in the next rev of the draft. thanks, neal From nobody Wed Oct 11 16:44:18 2017 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 B6971134218 for ; Wed, 11 Oct 2017 16:44:17 -0700 (PDT) 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=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 UsfI6faqBDKC for ; Wed, 11 Oct 2017 16:44:16 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 2C7D8132939 for ; Wed, 11 Oct 2017 16:44:16 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id k40so3847834lfi.4 for ; Wed, 11 Oct 2017 16:44:16 -0700 (PDT) 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=UBGGRrV52MYQDEt28EUINxAbe/7ZXKF0fRbCIl77vpA=; b=IA/HGS/Hn5IrcYb17WezTHqqTUVXBSRKAyFOPgpZFlwRd48oX8afNt/sWxNymP+1Sl EWc8W839367J0ZprdRBtYxMue3jHhps68A8hqaAWqytV15a/a3QgQyQqrWy7t/cf8WwD QlN+zKtqdOw9WQdBtougllSQEX2WU8A2fWPtBhdRoAjJcxcZk/q21NMgcQcEGzvt4ez/ Ssoa4OtqMTN3Qvatxk8F7P3XH4ajS8LmZ401lT0f9wyw5AGbKcKovjl0vK767QYeo006 noJVCDSDBUG8IkNSFZzWxKngaZjx4Cx+WKKY9SEhK/wTEF8IKJnOOPi5dauu78L7a4Sa MbCw== 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=UBGGRrV52MYQDEt28EUINxAbe/7ZXKF0fRbCIl77vpA=; b=qCx+GUm5RfAqbofPgjnsab3mmCHMlL8o7BWuehN0VRHLHquRZ7b5f8+2Pn8jo5ub15 dfUJMM2jTj/ZGkybUJYCJdS946nLRqHODQGcma9xEkqFAQd67GV6lplMsKOeREV9S1Fm Txpr0WtY3ApQyTmDyH+oWqzrGtt5manCXqecdJB0ECW5oDtSILAijkxpF6TwTvwx/tei Kc8sISZNvuXCVyJaG82HlFK8IsXAQPrcF3utOtg0Y5yxKr4aCujzymev5ZIjcOYH6gkq xOLsYKJVvZLArpdu4Ca3k2EJ0SfLt0oliZKXgeG8jVTi8nEjAoyZCfEZJFc8NFY8H8Pi nyGw== X-Gm-Message-State: AMCzsaXCeaEjLBZkNQJUIy9T6ocoS6+M9vkYW7C+mkM+g5u3yGx+IBMg fJ7t0Ms3RN6ZmMnVHUwBG8mGx0E1lCqjmX9AA7QBqA== X-Google-Smtp-Source: AOwi7QCNYIvdge/KrcTaLW7cxVudnEWd66HwiR+DY5mRZhXVSFEzMPjXbBmOHm4dPzFeDmSUh8+LJ8R1KH2TYzY4EkQ= X-Received: by 10.223.195.131 with SMTP id p3mr484099wrf.89.1507765454326; Wed, 11 Oct 2017 16:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.146.137 with HTTP; Wed, 11 Oct 2017 16:43:53 -0700 (PDT) In-Reply-To: References: <20171011215011.GH19289@strugglingcoder.info> <20171011232432.GJ19289@strugglingcoder.info> From: Neal Cardwell Date: Wed, 11 Oct 2017 23:43:53 +0000 Message-ID: To: hiren panchasara Cc: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Oct 2017 23:44:18 -0000 On Wed, Oct 11, 2017 at 11:38 PM, Neal Cardwell wrote: > We will try to clarify that in the next rev of the draft. How's this: Open state: the sender's loss recovery state machine is in its normal, default state: there are no SACKed sequence ranges in the SACK scoreboard, and neither fast recovery, timeout-based recovery, nor ECN-based cwnd reduction are underway. neal From nobody Wed Oct 11 16:49:48 2017 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 5B6A3132403 for ; Wed, 11 Oct 2017 16:49:47 -0700 (PDT) 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] 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 f7PMQC86lnqd for ; Wed, 11 Oct 2017 16:49:46 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id 15572132025 for ; Wed, 11 Oct 2017 16:49:46 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 4D05D1711D; Wed, 11 Oct 2017 16:49:49 -0700 (PDT) Date: Wed, 11 Oct 2017 16:49:49 -0700 From: hiren panchasara To: Neal Cardwell Cc: "tcpm@ietf.org" Message-ID: <20171011234949.GK19289@strugglingcoder.info> References: <20171011215011.GH19289@strugglingcoder.info> <20171011232432.GJ19289@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sU4rRG038CsJurvk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Oct 2017 23:49:47 -0000 --sU4rRG038CsJurvk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/11/17 at 11:38P, Neal Cardwell wrote: > On Wed, Oct 11, 2017 at 11:24 PM, hiren panchasara > wrote: > > On 10/11/17 at 10:40P, Neal Cardwell wrote: > >> On Wed, Oct 11, 2017 at 9:50 PM, hiren panchasara > >> wrote: > >> > > >> > Looking at TLP draft and RACK draft, > >> > > >> > Open state: the sender has so far received in-sequence ACKs with = no > >> > SACK blocks, and no other indications (such as retransmission > >> > timeout) that a loss may have occurred. > >> > > >> > So, loss probes are not scheduled after the first SACK block seen on= the > >> > connection? > >> > >> Right. > >> > >> > Shouldn't they be scheduled as long as the connection is > >> > not in recovery? Or am I missing something? > >> > >> If there is a SACK block seen, then the sender should be scheduling a > >> RACK timer, which would fire faster than the TLP timer anyway. > >> > >> Basically, if there is a SACK block then you have info about how long > >> it should have taken for the previous packets to arrive. A TLP is a > >> probe, intended for when there is no feedback at all arriving at the > >> sender. > > > > So, I think the idea is that a SACK block is all RACK needs to start > > marking previous packets as lost. >=20 > Yes. >=20 > > I am still confused by how these 2 conditions are different wrt TLP: > > 1) slow-start before receiving any SACK > > 2) Congestion avoidance after a loss-recovery episode is finished and > > connection is humming along >=20 > These are not different with respect to TLP. Those are 2 different > states in the congestion control algorithm state machine. But TLP does > not care about the congestion control algorithm state machine. TLP > only cares about the loss recovery state machine. We used the term > "Open state" in the draft to refer to the state in a loss recovery > state machine when there are no SACKed sequence ranges in the SACK > scoreboard, and we are not in the middle of fast recovery or timeout > recovery (the terminology is borrowed from the Linux TCP loss recovery > state machine's TCP_CA_Open state). >=20 > > Now if acks stop arriving, we send loss probe in case of 1) but not in > > case of 2). >=20 > Nope, both (1) and (2) are in the "Open state" in the loss recovery > state machine, so we would send a TLP in either case. >=20 > I think the sentence in the draft is ambiguous. It seems you > interpreted "so far" to mean "so far in the lifetime of the > connection", when the draft is trying to convey "so far in the current > loss recovery epoch" (or something like that). :-) Awesome! Thanks a ton for clearing my doubts. >=20 > We will try to clarify that in the next rev of the draft. I guess RACK draft is going to be the source of truth for TLP or the TLP draft is going to be maintained? Cheers, Hiren --sU4rRG038CsJurvk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJZ3q4aXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/loA0H/A4y05o/k0IwgopLok8tW3Gf 1ymHjLTowesXw/jueVkI8ey0Y1nK4BrAhnzae6rv3fh5YDbjxg5/PryBUMI6TO0e Nx20RhgA15vdTVLIZv8/T95cq3Ah/iFBEYm7qAEE/EWM/JByUzDWmM3SzYAG3Xt5 WCUnUzLPuPwFnj3AJJafj9rvpv/P0pLROh3R5qdnKXJmq0Jdk8c+nvBM6KmlQcu9 azbt8NMipFevadoLzixmk0+FDAARcjRthF24Ju0n+AcLXFIJHRI3rGGDjXw0nVGH x/nzFayiU0YARcanLUPQ1KL4jurGTQ73THcCewOuNpntwt9HgIUUdnq3yqS/VgE= =rcen -----END PGP SIGNATURE----- --sU4rRG038CsJurvk-- From nobody Wed Oct 11 16:51:10 2017 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 BBE801342DF for ; Wed, 11 Oct 2017 16:51:08 -0700 (PDT) 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] 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 j4QXjRUK6Lmh for ; Wed, 11 Oct 2017 16:51:07 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id AC7611342E5 for ; Wed, 11 Oct 2017 16:50:56 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id E438417125; Wed, 11 Oct 2017 16:50:59 -0700 (PDT) Date: Wed, 11 Oct 2017 16:50:59 -0700 From: hiren panchasara To: Neal Cardwell Cc: "tcpm@ietf.org" Message-ID: <20171011235059.GL19289@strugglingcoder.info> References: <20171011215011.GH19289@strugglingcoder.info> <20171011232432.GJ19289@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Z1OTrj3C7qypP14j" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Oct 2017 23:51:09 -0000 --Z1OTrj3C7qypP14j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/11/17 at 11:43P, Neal Cardwell wrote: > On Wed, Oct 11, 2017 at 11:38 PM, Neal Cardwell wr= ote: > > We will try to clarify that in the next rev of the draft. >=20 > How's this: >=20 > Open state: the sender's loss recovery state machine is in > its normal, default state: there are no SACKed sequence > ranges in the SACK scoreboard, and neither fast recovery, > timeout-based recovery, nor ECN-based cwnd reduction > are underway. Sounds good! Thank you. Cheers, Hiren --Z1OTrj3C7qypP14j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJZ3q5jXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lUWkIAIQo1VH0AAk/Vp3707KHPTiz AuxBkahrA9lr102eyy71CAM7nEbfqIskcGTXMmWVhggz0bGt46839H1A1J+37HQj 4xqRUmfXu33BfzVKanMnolP0kVoBv+dS1X12UKemLosESMsJyJkfYZEqDpKWPlrW DBegRGuw6FCArMk3TQ4otfHxj8b5Lzw9N7LpGxDHPdclyWXUD3Mm4wkh9WX4lkmc sv31a/jenvQerbD5NDLQRY+ZKXgNZC4E/xe08NmTwCZoqgrkWWFB5NJgyQMSyPRw vsFOelPAjHWbxttlqVrGnSLnjTEgdlGXwRwqw/N7OfIKcYVW5SYhqls/v4Ds7Cg= =+9nx -----END PGP SIGNATURE----- --Z1OTrj3C7qypP14j-- From nobody Wed Oct 11 16:53:44 2017 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 057C2134218 for ; Wed, 11 Oct 2017 16:53:42 -0700 (PDT) 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=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 wnDtlbIzg6fj for ; Wed, 11 Oct 2017 16:53:40 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 73195132025 for ; Wed, 11 Oct 2017 16:53:40 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id a69so3904340lfe.5 for ; Wed, 11 Oct 2017 16:53:40 -0700 (PDT) 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=HV8f83mn7PtQY3ladHIZzGqM2QdDZbKrk8DjGyVV1Gk=; b=nz5TWzTbAejgxwImuqdBU0gTYA/TYmu/bzxWET98PqKmuBI3WpLoBTMQC2hsAkaqkq YiB4gwReTP7sssSKYgLzuUVwtatyPBlb5w4BoUPzK9AXrkERkod7RMsVMvDDyFrE0XmB KlsUjkfB55nFkucpI6brSRxohypxuwy3sV4IeEPCcPbnt1q86aIKgJ2tkKIBsjiJLN+g 95K+6YquaH/iE4YB+LH08W5tnGjQIi3P0x4PhZWZY1W+7mQZThr41K9xZ0xb9dW1OrgP uOlR0vLfyspGDYAOx1bG23hJH7orlfJxGBJfFrI41sAJNyCwD6NXNh4bCHkxkdo1hY5+ 2mJg== 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=HV8f83mn7PtQY3ladHIZzGqM2QdDZbKrk8DjGyVV1Gk=; b=fSaZIsxAOrArc+Klv3KsRDkvOddidx4tQzKpcJwKFgq5PCRBPucMjyw44fthNdQtnD 4yvQxrR7XFMQyzETGTOUJmeq9HPnXvwnT/cmAYHV58gyPeSq3+C9ndwIlvt0khgvDN5P CLlinf3kxWws5Lj+De2PIcw3oKCL4g7DawlLjTljXey4eYCVGXaplqx93JzvwXIJVm43 2YEcK1ynuB27eoifhxNumkN0fo760Nk8/eIsYdgJirHGgCYmVtilYGrBiFcHPKJE94SJ Wjd2+PXzCWIeyBa69RjG8cs1f+KjM/cgDwCVgyFz6AdQYeact6PiABbmPtprQcqEmg9S aeYw== X-Gm-Message-State: AMCzsaXNQMXoqcCTMDTAluJtESnBpDoy+Ir4tN0/CMS4b2DYpdQaoOnL EahqLMaKVVQNwrAQ9rNJ3gsxmr3NuY7/OzXP9UALpg== X-Google-Smtp-Source: AOwi7QDPH2I8rtTjmuCcnBpipGKAbwogS6ot7mD6LeYRfNnyFKw/houaorUdVyPXqrIDFRkWjKMo93DVoxJ/UMsn8uc= X-Received: by 10.28.126.208 with SMTP id z199mr316922wmc.91.1507766018460; Wed, 11 Oct 2017 16:53:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.146.137 with HTTP; Wed, 11 Oct 2017 16:53:17 -0700 (PDT) In-Reply-To: <20171011234949.GK19289@strugglingcoder.info> References: <20171011215011.GH19289@strugglingcoder.info> <20171011232432.GJ19289@strugglingcoder.info> <20171011234949.GK19289@strugglingcoder.info> From: Neal Cardwell Date: Wed, 11 Oct 2017 23:53:17 +0000 Message-ID: To: hiren panchasara Cc: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Oct 2017 23:53:42 -0000 On Wed, Oct 11, 2017 at 11:49 PM, hiren panchasara wrote: >> We will try to clarify that in the next rev of the draft. > > I guess RACK draft is going to be the source of truth for TLP or the TLP > draft is going to be maintained? Yes, the RACK draft will continue to be the official latest source for the TLP mechanism. neal From nobody Wed Oct 11 19:54:11 2017 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 CD8B9124F57; Wed, 11 Oct 2017 19:54:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-tcpm-cubic@ietf.org, Yoshifumi Nishida , tcpm-chairs@ietf.org, nishida@sfc.wide.ad.jp, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150777684383.16893.7292254005966552138.idtracker@ietfa.amsl.com> Date: Wed, 11 Oct 2017 19:54:03 -0700 Archived-At: Subject: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-cubic-06: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 02:54:04 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tcpm-cubic-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a confused by the fact that this draft claims to specify CUBIC, but also cites another document for CUBIC. Which is the authoritative definition? If the answer is "that other document", then some words to clarify that would be helpful. I gather CUBIC is not an acronym? If correct, why spell it in all-caps? From nobody Wed Oct 11 22:43:36 2017 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 6D8B1132D8A for ; Wed, 11 Oct 2017 22:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 vX8-ckiNhwpB for ; Wed, 11 Oct 2017 22:43:33 -0700 (PDT) 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 3302C124B17 for ; Wed, 11 Oct 2017 22:43:33 -0700 (PDT) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1e2WHL-0006dO-2V for tcpm@ietf.org; Thu, 12 Oct 2017 07:43:31 +0200 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.9]) by mail-mx06.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1e2WHK-0006Fj-Bd; Thu, 12 Oct 2017 07:43:31 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: Date: Thu, 12 Oct 2017 07:43:44 +0200 Cc: hiren panchasara , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3787DA21-AC16-4DBE-96ED-A7D7A99A1A29@ifi.uio.no> References: <20171011215011.GH19289@strugglingcoder.info> <20171011232432.GJ19289@strugglingcoder.info> <20171011234949.GK19289@strugglingcoder.info> To: Neal Cardwell X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.9]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.000, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 217AD01BB06C48AF2B77246C5A5A4BF2CB3C6B0A Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Oct 2017 05:43:35 -0000 Hi, This was an interesting dialogue to follow, thanks! > On Oct 12, 2017, at 1:53 AM, Neal Cardwell = wrote: >=20 > On Wed, Oct 11, 2017 at 11:49 PM, hiren panchasara > wrote: >=20 >>> We will try to clarify that in the next rev of the draft. >>=20 >> I guess RACK draft is going to be the source of truth for TLP or the = TLP >> draft is going to be maintained? >=20 > Yes, the RACK draft will continue to be the official latest source for > the TLP mechanism. Good to know! While we=E2=80=99re at it - I have a question about RACK and TLP too: Say, we have a cwnd of 100 segments and hit heavy congestion: all = packets are lost. ssthresh becomes 50, or 70 in case of Cubic. A TLP timer would fire, and = let=E2=80=99s say that this one single packet would make it. Because an = ACK arrives, the sender would stay in FR, and from the resulting SACK = info, RACK would know that this was much later than all the previous = packets, and hence would immediately send out a burst (maybe paced, but = that=E2=80=99s another story) of 50 or 70 packets, right? Have I understood this correctly? If so, isn=E2=80=99t this a pretty = aggressive behavior? I mean, we have one RTT of losing everything, a = probe timer later we get one packet through, and then we have so many = packets again, straight away after this long pause=E2=80=A6 this may or = may not be the right thing to do. As you know I like the RACK idea, but = if it can turn out to be as aggressive as that, I would appreciate = evaluation results showing that this doesn=E2=80=99t become a problem = (and if it does become a problem, some limitations could be put in = place). I don=E2=80=99t think we=E2=80=99ve seen this type of evaluation = so far. Cheers, Michael From nobody Wed Oct 11 23:33:59 2017 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 463C41320D9 for ; Wed, 11 Oct 2017 23:33:58 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 LejteV33ObNF for ; Wed, 11 Oct 2017 23:33:56 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 7DE93126CB6 for ; Wed, 11 Oct 2017 23:33:56 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id i124so10240408wmf.3 for ; Wed, 11 Oct 2017 23:33:56 -0700 (PDT) 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:content-transfer-encoding; bh=W/OQhj3wuA0U9qz7E8iGCPN8xKwRi0rlIYaQzfVKmhQ=; b=vS/zasLDjRVmrPcWLJ6/a6su4WEOd3bwMu6r0hmWDgLB4TFITQuKJauPhBbvSoj9Bf 0tKBlRnfWolT2CdF+aoDMZjaQnsKB7mPxynuVVI2K6PRA2gwUhI+Jqk1cIra68YWf+yr 11w0PFLhBnGrFGZMMMo+wAHN+U/I/8co1prl4xMaEXGF1zzr/31ASwNHEAFCxWlnRa9A uS3Nmegi7P3SVQzsEgw4gyuP9XDvH8j/UHqSIAbulZ1t5o16kJjrzRCnnXNcnZ7+Kfbv GIrSSWCExHqYa2VvEC4ShN+j1EV5KfswH7R/Sn01/Ej5ELUv4cuQuop7lMDYt6agOkzy 3LdA== 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=W/OQhj3wuA0U9qz7E8iGCPN8xKwRi0rlIYaQzfVKmhQ=; b=Qlov3tmjnuhMpb6zu+kJG+T1erOfR5CL/wPYroaMMT0bqVHfG/btpISL2YQCogt65i ICDX73bCsVOiBQIOvxuEn/zm00Re2iyF3GpNqhOZ6p+BzlikeCyIxvEGq4Ut9XOOadq7 3b+fZwqa0JhQ+YODyJ/HCHl0mQaj41UlNOiXjy3ak0RtIyI0cAoWHhrbEOy1r5rxTVoz X1RGQPGprOPqLziCRZq4dyMY1Ovg3HGqzoh1vVKnkY78YX9WoimpM4csc+naWeNtKswg lP57VMdEKaDtDA823RdfGWpM7LQTKsIdtPnHwT3TBl493S6dJrnDJW4RtSAe1fZU2x4M HpNw== X-Gm-Message-State: AMCzsaVZ7wkVIHrmuYkHRFtD/MmTuDSJn3UOttUIT2BIQQ1n07bEqepB 6gL+0wcF3in7XdwDwENyRDDc+EIvSAqYlo28oaIO2w== X-Google-Smtp-Source: AOwi7QBNS4cfFOPtpqsD8PfAIl2LKWeG5DL0E/NkPAfoO+rVFwnVVjiIZOQebAY21UDs91Io9QXZqsS8NSxykpQ3iLA= X-Received: by 10.223.151.51 with SMTP id r48mr1045340wrb.164.1507790034677; Wed, 11 Oct 2017 23:33:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.146.137 with HTTP; Wed, 11 Oct 2017 23:33:33 -0700 (PDT) In-Reply-To: <3787DA21-AC16-4DBE-96ED-A7D7A99A1A29@ifi.uio.no> References: <20171011215011.GH19289@strugglingcoder.info> <20171011232432.GJ19289@strugglingcoder.info> <20171011234949.GK19289@strugglingcoder.info> <3787DA21-AC16-4DBE-96ED-A7D7A99A1A29@ifi.uio.no> From: Neal Cardwell Date: Thu, 12 Oct 2017 06:33:33 +0000 Message-ID: To: Michael Welzl Cc: hiren panchasara , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Oct 2017 06:33:58 -0000 On Thu, Oct 12, 2017 at 5:43 AM, Michael Welzl wrote: > > While we=E2=80=99re at it - I have a question about RACK and TLP too: > > Say, we have a cwnd of 100 segments and hit heavy congestion: all packets= are lost. > ssthresh becomes 50, or 70 in case of Cubic. A TLP timer would fire, and = let=E2=80=99s say that this one single packet would make it. Because an ACK= arrives, the sender would stay in FR, and from the resulting SACK info, RA= CK would know that this was much later than all the previous packets, and h= ence would immediately send out a burst (maybe paced, but that=E2=80=99s an= other story) of 50 or 70 packets, right? > > Have I understood this correctly? If so, isn=E2=80=99t this a pretty aggr= essive behavior? I mean, we have one RTT of losing everything, a probe tim= er later we get one packet through, and then we have so many packets again,= straight away after this long pause=E2=80=A6 this may or may not be the ri= ght thing to do. As you know I like the RACK idea, but if it can turn out t= o be as aggressive as that, I would appreciate evaluation results showing t= hat this doesn=E2=80=99t become a problem (and if it does become a problem,= some limitations could be put in place). I don=E2=80=99t think we=E2=80=99= ve seen this type of evaluation so far. Good question. We cover that kind of question (with an example very close to yours) in section 7.5, "Interaction with congestion control", in: https://tools.ietf.org/html/draft-ietf-tcpm-rack-02 At a high level, we feel that what the sender does when it gets a small number of packets SACKed that indicate a large number of packet lost is a congestion control decision, which we feel should be considered to be decoupled (as much as possible) from the loss detection logic in RACK. That said, as we mention in the draft, we recommend combining RACK with PRR [RFC6937]. After receiving the SACK for the TLP probe packet, at which point RACK marks the whole rest of the flight lost, PRR would not send a burst, but rather would slow-start, starting from 1 packet (1, 2, 4, 8....). neal From nobody Wed Oct 11 23:55:26 2017 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 08DF5132D41 for ; Wed, 11 Oct 2017 23:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 OJ3l0HM__U2E for ; Wed, 11 Oct 2017 23:55:22 -0700 (PDT) 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 9CA771243F6 for ; Wed, 11 Oct 2017 23:55:22 -0700 (PDT) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1e2XOr-0005UK-0p for tcpm@ietf.org; Thu, 12 Oct 2017 08:55:21 +0200 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.9]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1e2XOp-0001LG-L4; Thu, 12 Oct 2017 08:55:20 +0200 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E14636D0-8F8E-4669-9189-79728E6D4385" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 12 Oct 2017 08:55:35 +0200 In-Reply-To: Cc: "tcpm@ietf.org" To: Neal Cardwell References: <20171011215011.GH19289@strugglingcoder.info> <20171011232432.GJ19289@strugglingcoder.info> <20171011234949.GK19289@strugglingcoder.info> <3787DA21-AC16-4DBE-96ED-A7D7A99A1A29@ifi.uio.no> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.9]; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.125, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E6B6B1BB443D85579B602A752996A7ED12E56104 Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Oct 2017 06:55:25 -0000 --Apple-Mail=_E14636D0-8F8E-4669-9189-79728E6D4385 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Oct 12, 2017, at 8:33 AM, Neal Cardwell = wrote: >=20 > On Thu, Oct 12, 2017 at 5:43 AM, Michael Welzl = wrote: >>=20 >> While we=E2=80=99re at it - I have a question about RACK and TLP too: >>=20 >> Say, we have a cwnd of 100 segments and hit heavy congestion: all = packets are lost. >> ssthresh becomes 50, or 70 in case of Cubic. A TLP timer would fire, = and let=E2=80=99s say that this one single packet would make it. Because = an ACK arrives, the sender would stay in FR, and from the resulting SACK = info, RACK would know that this was much later than all the previous = packets, and hence would immediately send out a burst (maybe paced, but = that=E2=80=99s another story) of 50 or 70 packets, right? >>=20 >> Have I understood this correctly? If so, isn=E2=80=99t this a pretty = aggressive behavior? I mean, we have one RTT of losing everything, a = probe timer later we get one packet through, and then we have so many = packets again, straight away after this long pause=E2=80=A6 this may or = may not be the right thing to do. As you know I like the RACK idea, but = if it can turn out to be as aggressive as that, I would appreciate = evaluation results showing that this doesn=E2=80=99t become a problem = (and if it does become a problem, some limitations could be put in = place). I don=E2=80=99t think we=E2=80=99ve seen this type of evaluation = so far. >=20 > Good question. We cover that kind of question (with an example very > close to yours) in section 7.5, "Interaction with congestion control", > in: > https://tools.ietf.org/html/draft-ietf-tcpm-rack-02 = Ah, right - sorry for missing this (I had read this section once, but = forgot about it). > At a high level, we feel that what the sender does when it gets a > small number of packets SACKed that indicate a large number of packet > lost is a congestion control decision, which we feel should be > considered to be decoupled (as much as possible) from the loss > detection logic in RACK. That makes sense to me - although I think we do need a concrete default = recommendation on what to do (in the absence of any better solutions, = e.g. pacing or whatever, ..). > That said, as we mention in the draft, we recommend combining RACK > with PRR [RFC6937]. After receiving the SACK for the TLP probe packet, > at which point RACK marks the whole rest of the flight lost, PRR would > not send a burst, but rather would slow-start, starting from 1 packet > (1, 2, 4, 8....). Yes, this is nicely explained in section 7.5, and it seems to me to be a = reasonable thing to do. The recommendation to use PRR is kinda there, but IMO a bit too weak: *** A packet marked lost by RACK SHOULD NOT be retransmitted until congestion control deems this appropriate (e.g. using [RFC6937]). *** What about, e.g.: *** A packet marked lost by RACK SHOULD NOT be retransmitted until congestion control deems this appropriate. Specifically, Proportional Rate Reduction [RFC6937] SHOULD be enabled when using RACK. *** Cheers, Michael --Apple-Mail=_E14636D0-8F8E-4669-9189-79728E6D4385 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On = Oct 12, 2017, at 8:33 AM, Neal Cardwell <ncardwell@google.com> wrote:

On = Thu, Oct 12, 2017 at 5:43 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:

While we=E2=80=99re at it - I have a question about RACK and = TLP too:

Say, we have a cwnd of 100 = segments and hit heavy congestion: all packets are lost.
ssthresh becomes 50, or 70 in case of Cubic. A TLP timer = would fire, and let=E2=80=99s say that this one single packet would make = it. Because an ACK arrives, the sender would stay in FR, and from the = resulting SACK info, RACK would know that this was much later than all = the previous packets, and hence would immediately send out a burst = (maybe paced, but that=E2=80=99s another story) of 50 or 70 packets, = right?

Have I understood this correctly? If = so, isn=E2=80=99t this a pretty aggressive behavior?  I mean, we = have one RTT of losing everything, a probe timer later we get one packet = through, and then we have so many packets again, straight away after = this long pause=E2=80=A6 this may or may not be the right thing to do. = As you know I like the RACK idea, but if it can turn out to be as = aggressive as that, I would appreciate evaluation results showing that = this doesn=E2=80=99t become a problem (and if it does become a problem, = some limitations could be put in place). I don=E2=80=99t think we=E2=80=99= ve seen this type of evaluation so far.

Good question. We cover that kind of question (with an = example very
close to yours) in section 7.5, "Interaction = with congestion control",
in:
 https://tools.ietf.org/html/draft-ietf-tcpm-rack-02

Ah, right = - sorry for missing this  (I had read this section once, but forgot = about it).


At a high = level, we feel that what the sender does when it gets a
small number of packets SACKed that indicate a large number = of packet
lost is a congestion control decision, which we = feel should be
considered to be decoupled (as much as = possible) from the loss
detection logic in RACK.

That makes = sense to me - although I think we do need a concrete default = recommendation on what to do (in the absence of any better solutions, = e.g. pacing or whatever, ..).


That said, as we mention in the draft, we recommend combining = RACK
with PRR [RFC6937]. After receiving the SACK for the = TLP probe packet,
at which point RACK marks the whole rest = of the flight lost, PRR would
not send a burst, but rather = would slow-start, starting from 1 packet
(1, 2, 4, = 8....).

Yes, this is nicely explained in section 7.5, = and it seems to me to be a reasonable thing to do.

The recommendation to use PRR is kinda there, but = IMO a bit too weak:
***
A packet = marked lost by RACK SHOULD NOT be
  =  retransmitted until congestion control deems this appropriate = (e.g.
   using = [RFC6937]).
***

What = about, e.g.:
***
A packet = marked lost by RACK SHOULD NOT be
  =  retransmitted until congestion control deems this = appropriate.
Specifically, Proportional Rate = Reduction [RFC6937] SHOULD be
enabled when using = RACK.
***

Cheers,
Michael

= --Apple-Mail=_E14636D0-8F8E-4669-9189-79728E6D4385-- From nobody Thu Oct 12 00:21:19 2017 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 DB71B1320D9 for ; Thu, 12 Oct 2017 00:21:18 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 h6UZBiBGURlF for ; Thu, 12 Oct 2017 00:21:17 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 4BF6C126B71 for ; Thu, 12 Oct 2017 00:21:17 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id q132so10552644wmd.2 for ; Thu, 12 Oct 2017 00:21:17 -0700 (PDT) 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=Y/9c4qlhYNh0cHBKApa+1O6kOImGLVG8yzE9PIpLFMc=; b=GcDPb5GNpPPHUQpeqFRcSwiOUL8eCz6ovJRpdyDv1qZ2kDUmkKfEG6/zuXHN7Qd8ci X8Ec6tszLy3JTZUw3I66A2h0f9XRkuWQrrZ2LATV4vUgYJe/bJN1eSlAN0z82FVEo/Jk DJQ2IoZrURCpYVjd+TsZukh8NmhVpbPP0vzv5s6B1ODFLU7yOKcTUTKbdlxEH7PeTTvE hOD0twf8zNh2BEQmlZYo1jpSZ2ktNppGgHxrsEADooJeT1LLgJ78g+5sdHJH+MAMczT2 pdxyk+VDi5OsMyLwXh/xdKQQTilMybPHj09gsJEkgms9mArQ8efQyKUZalH9bNK+oDK0 5xEg== 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=Y/9c4qlhYNh0cHBKApa+1O6kOImGLVG8yzE9PIpLFMc=; b=VPvldvT6UKxbpneEkIu3hsWrW29o/rfzUkHNNfAgOIQUElq6E0TiG9PBO/MufivjSN HrvUhAKKtZwHV5c1tZL1nUkpSz06tAHcxog0O3Fha7qkUm6InLwxNJBc4Eqt3xl9Wl9R UHDW1Db9sOqAH9QBJBAKprZckq5MwbQIRFqqbHm7r09kFf006yB2Hdvpz8x3MppI3xBx CX50gNhPcTgg/Y32ZSd41KnTm8hpGyBG4KcSV0wuEGqmhmZ9yw72Yt7OIv8kzYdnPBep jG6rU8K/khoN1ykCkxfvIasBXMTOthcWg3GpYO8EW1MFu8Ws5eiN3+lbV7qyAqhzis05 6H2Q== X-Gm-Message-State: AMCzsaWayZZYYe9bfVNmbc5XiY/B7IutIWsQ2DBQZoNxYe+5geONcPf0 74gpWpc2WQbOJpj9vmxajdV3rMsxMsA0MSMYSBYaig== X-Google-Smtp-Source: AOwi7QBXlXrLLWqsWwItS71m9wqGb/Yq58JoCsFTKukOxaAyH6Ykb+z9jB1N3hfZYwc70a92D0uHDpU9go6M4D0WoYg= X-Received: by 10.223.196.199 with SMTP id o7mr1119925wrf.119.1507792875649; Thu, 12 Oct 2017 00:21:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.146.137 with HTTP; Thu, 12 Oct 2017 00:20:54 -0700 (PDT) In-Reply-To: References: <20171011215011.GH19289@strugglingcoder.info> <20171011232432.GJ19289@strugglingcoder.info> <20171011234949.GK19289@strugglingcoder.info> <3787DA21-AC16-4DBE-96ED-A7D7A99A1A29@ifi.uio.no> From: Neal Cardwell Date: Thu, 12 Oct 2017 07:20:54 +0000 Message-ID: To: Michael Welzl Cc: "tcpm@ietf.org" , Yuchung Cheng , Nandita Dukkipati Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Oct 2017 07:21:19 -0000 On Thu, Oct 12, 2017 at 6:55 AM, Michael Welzl wrote: > Yes, this is nicely explained in section 7.5, and it seems to me to be a > reasonable thing to do. > > The recommendation to use PRR is kinda there, but IMO a bit too weak: > *** > A packet marked lost by RACK SHOULD NOT be > retransmitted until congestion control deems this appropriate (e.g. > using [RFC6937]). > *** > > What about, e.g.: > *** > A packet marked lost by RACK SHOULD NOT be > retransmitted until congestion control deems this appropriate. > Specifically, Proportional Rate Reduction [RFC6937] SHOULD be > enabled when using RACK. > *** Thanks, Michael. That sounds good to me. CC-ing my co-authors to get their sense. BTW, this has been the behavior of TLP-initiated recovery in Linux TCP since our team added it in March of 2013. (Back then Linux TCP was using TLP + FACK + PRR; now it's with TLP + RACK + PRR.) neal From nobody Thu Oct 12 08:18:15 2017 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 B84F31332CA for ; Thu, 12 Oct 2017 08:18:14 -0700 (PDT) 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] 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 fgdzAunmnDrU for ; Thu, 12 Oct 2017 08:18:13 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id D147E133039 for ; Thu, 12 Oct 2017 08:18:13 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id E8DCA17787; Thu, 12 Oct 2017 08:18:16 -0700 (PDT) Date: Thu, 12 Oct 2017 08:18:16 -0700 From: hiren panchasara To: Michael Welzl Cc: Neal Cardwell , "tcpm@ietf.org" Message-ID: <20171012151816.GM19289@strugglingcoder.info> References: <20171011215011.GH19289@strugglingcoder.info> <20171011232432.GJ19289@strugglingcoder.info> <20171011234949.GK19289@strugglingcoder.info> <3787DA21-AC16-4DBE-96ED-A7D7A99A1A29@ifi.uio.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ICrdrp3pM9DyZLTK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [tcpm] TLP pto scheduling X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 12 Oct 2017 15:18:15 -0000 --ICrdrp3pM9DyZLTK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/12/17 at 08:55P, Michael Welzl wrote: > Hi, > [snip] > Yes, this is nicely explained in section 7.5, and it seems to me to be a = reasonable thing to do. >=20 > The recommendation to use PRR is kinda there, but IMO a bit too weak: > *** > A packet marked lost by RACK SHOULD NOT be > retransmitted until congestion control deems this appropriate (e.g. > using [RFC6937]). > *** >=20 > What about, e.g.: > *** > A packet marked lost by RACK SHOULD NOT be > retransmitted until congestion control deems this appropriate. > Specifically, Proportional Rate Reduction [RFC6937] SHOULD be > enabled when using RACK. > *** Yes please. I ran into the exact same problem when Neal/Yuchung pointed me to PRR and implementing that fixed the issue of bursting out retransmissions too fast during recovery. Even without pacing it does a very nice job so yeah, it should be marked as 'necessary' with rack. Cheers, Hiren --ICrdrp3pM9DyZLTK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJZ34e1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lxOwH/2WGn5y8h1EDSeFwdLKyGNjL OKrMvYPVOD0/YFM8PjFDZSNajjp2Az63LqLCG+o6+FYSamNxfn8wZqv/hlndQHag IAHnD7+zyr4R+z3IaQb1ApKk1NPJo1SrasmRCWbXtaAaEyxVpAanqM5kqZw0NjcV /6LeXGZTSfXs/OtcokdhWHWn06dWTSjxGfAZYTijcWNj2JQ+5dfiK2I74iTz9IEw lwJfHxjN4UWrsPzemwnWb4NlolnmhjiUqg0pUojM/mb5agIhWiYQrhHM5NWqGEOi wfPHMwmNYBZVLiC4EgIo8GqaaD6vjIVQed5XdZa1MSCUJGDYdd2OfMoJpP9/mjU= =GTKL -----END PGP SIGNATURE----- --ICrdrp3pM9DyZLTK-- From nobody Fri Oct 13 03:44:09 2017 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 E543713239C for ; Fri, 13 Oct 2017 03:44:07 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 LurkNR_o4y0S for ; Fri, 13 Oct 2017 03:44:05 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3F01321A1 for ; Fri, 13 Oct 2017 03:44:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3yD48M48Qfz15LG8; Fri, 13 Oct 2017 12:44:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbpQyMHPChc5; Fri, 13 Oct 2017 12:44:01 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 13 Oct 2017 12:44:01 +0200 (CEST) To: marcelo bagnulo braun Cc: tcpm IETF list , Jana Iyengar , Anna Brunstrom References: <839cc83c-f060-f812-c8e7-a2530798d6ee@it.uc3m.es> <22CB67D2-B6BE-4AF2-8FBD-68C9F3F91F11@tik.ee.ethz.ch> <76f10b55-0538-0832-3b58-5226ee39959e@it.uc3m.es> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <62e06c68-3b97-ce39-558f-20189775b00c@tik.ee.ethz.ch> Date: Fri, 13 Oct 2017 12:44:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <76f10b55-0538-0832-3b58-5226ee39959e@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] ECN++: Whether to allow ECT/CE marking of pure ACKs and what response to recommend to feedback reporting that a pure ACK was CE marked. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Oct 2017 10:44:08 -0000 Hi Marcelo, see inline. On 10.10.2017 10:25, marcelo bagnulo braun wrote: > Hi Mirja, > > Thanks for your reply. > > I understand that what you are proposing is that we only allow ECT > marking of pure ACKs when AccECN is negotiated and that upon the > reception of a signal informing that a pure ACK was CE marked, the > sender must reduce its CWND as with any other packet, is that so? > > some further questions below.... > > El 09/10/17 a las 13:57, Mirja Kühlewind escribió: >> Hi Marcelo, >> >> sorry for top-posting but I’m actually not sure where exactly to reply below because I think the situation is less complicated than you described it below. >> >> First of all I think pure ACKs should not be ECT marked if AccECN is not supported. Losing an ACK is less bad than losing a data packet but you should not mark packets as ECT if there is no way to provide feedback to the sender if congestion was experienced. > > I am not sure i understand why you say that when AccECN is not > supported, there is not mean to provide feedback to the sender. Wouldnt > the receiver simply set the ECE flag in packets going in the other > direction upon the reception of a pure ACK with the CE mark? Actually this is a good question and not well-specified in RFC3168. So my guess it that this is a no for most implementations but more research is needed. > >> Then if you have AccECN it is actually not that much important if a pure ACK or a data packet was marked. > > > Actually, people make the argument that there is a difference between > data packets and pure ACKs. > > The concern people expressed it that reducing the CWND based on CE marks > on pure ACK introduces a bias, since the sender reduces the CWND when > Pure ACKs experience congestion but the sender does not increase the > CWND when the pure ACK does not experience congestion. This is a > fundamental concern, i believe and it is irrespective whether there is > data traffic along with pure ACKs, i think. There is huge difference here because if you only send pure ACKs your congestion would decrease to min-cwnd sooner or later anyway and you should not increase that just because you send ACKs continuously. In this scenario, increasing the congestion window without actually using it, is a bad idea. However, usually you don't get any feedback that tells you that an ACK was received or not, so I don't even understand how you would want to increase the cwnd for ACKs...? Anyway we seem to agree below on using ECN for pure ACKs only with AccECN, right? Mirja > In AccECN, the bias can be less, i think, because since the pure ACK has > not data, the amount of bits that experienced congestion is small, so > the bias is small. This is the reason why i think it is more acceptable > to have this behaviour with AccECN than with no AccECN. > > So, my understanding is that the options are > - not ECN marking of pure ACKs, which results in higher loss probability > - marking pure ACKs but not responding to congestion, bad precedent > - marking pure ACKs and responding to congestion, bias towards > decreasing the CWND > - marking pure ACKs, responding to congestion and adding some way to > increase the CWND, complicated and inaccurate. > > So, from my side, I think your proposal of only supporting ECN marking > of pure ACK when AccECN is supported seems a good trade-off, while not > perfect, may be a good way forward > >> If there is a congestion marking that means the link is congested and you should react to it. Now the question is what’s the right reaction, and there multiple cases here: >> >> 1) You send pure ACKs interleaved with data packets that means your congestion window might be large and any indicate of congestion should trigger a congestion control reaction accordingly. >> >> 2) You only send pure ACKs; in this case your congestion window should reduce to min_win sooner or later anyway; if there is congestion this might happen a bit quicker but if there is congestion and you already know about this, you should also not just resume sending with your previous rate. Then if you are at min_cwnd you cannot reduce it any further, therefore you MAY consider using AckCC in this case, or more generally speaking apply some algorithm increase your delayed ack factor. > > See above, the concern here is the biased introduced towards reducing > the CWND. > >> I really don’t think that increasing the congestion window based on ACK is even a possible option. You don’t get ACKs for ACKs so you never know if an ACK was successfully received. That means you don’t even have any information that would allow you to react on. > > You do get some idea of what ACKs got through, but i agree that given > the cumulative nature of ACKs, some acks can get lost undetected. > I agree this is not perfect, but not of the options are. > That being said, I also think that this option introduces complexity > with little benefit, so if all solutions are imperfect, we should at > least choose one that is at least simple. > > Regards, marcelo > >> Mirja >> >> >>> Am 09.10.2017 um 12:34 schrieb marcelo bagnulo braun : >>> >>> Hi, >>> >>> Regarding, draft-ietf-tcpm-generalized-ecn, we still have the open issue regarding whether to allow ECT/CE marking in pure acks and what response to reccomend if a pure ack encountered congestion. >>> >>> After considering the discussion in the last meeting and in the ml, we propose the following text in the draft: >>> >>> --------------------- >>> >>> For the experiments proposed here, the TCP implementation will set >>> ECT on pure ACKs. It can ignore the requirement in section 6.1.4 of >>> RFC 3168 to set not-ECT on a pure ACK. >>> >>> A host that sets ECT on pure ACKs SHOULD respond to the congestion signal resulting from pure ACKs being marked with the CE codepoint. The specific response will need to be defined as an update to each congestion control specification. Possible responses to congestion feedback include regulating the pure ACK rate (see AckCC [RFC5690]) or reducing the congestion window (CWND). >>> >>> However, if the congestion response implemented reduces the CWND upon the report of CE marking of Pure ACKs, then the congestion control algorithm must also increase the CWND upon delivery of pure ACKs without a CE mark, to avoid a bias in the congestion control algorithm. >>> >>> (We can also include some of the description of how to do this based on the text below for RFC3168 and AccECN in an appendix.) >>> >>> --------------------- >>> >>> Some background about this proposal: >>> >>> First of all, it's worth reminding that without ECN++, TCP currently is not required to detect loss of pure ACKs and is not required to react to them. >>> The current draft states that it is allowed to ECT/CE mark the pure ACKs and that: >>> " A host that sets ECT on pure ACKs MUST reduce its congestion window >>> in response to any congestion feedback, in order to regulate any data >>> segments it might be sending amongst the pure ACKs. It MAY also >>> implement AckCC [RFC5690] to regulate the pure ACK rate, but this is >>> not required. " >>> >>> The feedback we received in the Prague meeting was: >>> >>> - It is valuable to allow ECT/CE marking of pure ACK to avoid high drop rate when there is congestion. There is a strong case for ECN-capable pure ACKs as they are critical for connection performance. >>> >>> - The sender of the pure acks must respond (somehow) to the congestion signal resulting from getting CE marks in pure ACKs. Recommending not to respond to a received congestion signal seem like a bad recommendation to make in general and setting a bad precedent. >>> >>> There are two possible responses: reduce CWND (somehow) and/or ACK congestion control (ACK CC) (as defined in RFC5690). >>> >>> - The feedback regarding ACK CC is that it is too complex and with too many corner cases to mandate its implementation, so we should not mandate it. >>> >>> - Regarding reducing the CWND, there were several arguments against doing this. A very compelling argument is that since we do not increase the CWND when pure ACKs are successfully delivered, if we reduce the CWND when they are CE marked, then we have a strong bias towards reducing the CWND. In particular, in the case the one endpoint is only sending pure ACKs, the likely result is that the CWND will be 1 after a while. >>> >>> It is possible to address this issue by allowing the increase of CWND in case there are no CE marks in the pure ACKs. >>> >>> A possible approach for this would be the following: >>> >>> - if ECN++ is being used with RFC3168 ECN, then we simply do what is done with data packets, i.e. if during a RTT no ECE is received, the sender increases its CWND and if the sender receives one or more ECE marks, then it reduces its CWND. The only difference is that we include pure ACKs as well. >>> >>> - if ECN++ is used with AccECN, the situation is slightly more complex because the sender of the pure ACKs needs to keep track of the pure ACKs that got CE marked and those that didnt. But the sender of the pure ACKs knows how many pure ACKs it has sent. The other endpoint includes pure ACKs in the packet count of CE marked packets that is reported using AccECN, then the sender of the pure ACKs can figure out how many pure ACKs have been CE marked and how many were not. It then can feed this information to the congestion control algorithm. >>> >>> (The limitation of this approach is that lost pure ACKs are accounted as delivered pure ACKs without any CE marks, meaning that in the case of severe congestion, when pure ACKs are being dropped, the congestion control algorithm will include those lost pure ACK packets as delivered and increase the CWND the corresponding share. Since pure ACKs are small packets, it is not clear how much of a problem is this. Similarly (but worse), with 3168 feedback, even if detecting CE on pure ACKs, if pure ACKs are lost and there's no CE on a pure ACK within an RTT, cwnd will continue to increase. However, in both cases, it is still better with ECN++, because without ECN++ there was no response to either dropped or CE-marked pure ACKs.) >>> >>> It might be useful for the congestion response to be proportionate to an estimate of the bytes marked rather than packets marked, by adding an assumed header size on the wire to the size of every segment (otherwise pure ACKs would have zero size and not require any response). This would be up to the implementation. >>> >>> >>> Note that the response to the congestion signal is outside the scope of draft-ietf-generalized-ecn, because it depends on the specific CC, e.g. Reno, Cubic, Compound, etc) >>> >>> That being said, we should include some guidance of what type of response is sensible, particularly for the standards track CC [RFC5681]. >>> >>> thoughts? >>> >>> Bob & Marcelo >>> >> > From nobody Fri Oct 13 04:42:23 2017 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 A65B61326FE for ; Fri, 13 Oct 2017 04:42:21 -0700 (PDT) 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=it-uc3m-es.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 VYtx0YuyeB4N for ; Fri, 13 Oct 2017 04:42:18 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 38CC412EC30 for ; Fri, 13 Oct 2017 04:42:18 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id l68so21015392wmd.5 for ; Fri, 13 Oct 2017 04:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dAi1xAiFDNb3/sY8Ruj/ybRK9Ny63WqnHwoWRCFaA30=; b=uSog+sFFCSdLbXMedZSQOqJXVFKbijSjZL+eyUxXKSdcLjotq4c8ADvxRJhrzkAPG9 yhg7j0QFH4SAdgzD38ZU6NrvcZI1Y8duvf/+Y7otzMoFW023w90/QxescTJyv6thIJgD nu+xc6PNEPXl3m3/OUVHWvqKppqN6lC/uP/L0wTQd3iGd3RFQI6tkp8ISSYGBSMdp7ZD X3xOJmXb08kVgtjDBMbCzqFPp5WKwPi2cgdbnHd1UPSCtLg1qZkQkTDxu2Fm+/3Ruq5l 8I3M7eGNptRgCMtjOhi7+ACiJKqBOa+r/rzhFIzQgCCRhJyHwR3tGeRr6CiV7Obyo2Cx GBWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dAi1xAiFDNb3/sY8Ruj/ybRK9Ny63WqnHwoWRCFaA30=; b=Jzk+NbhWwwUc6Q44GOIeaBMZQpmjixoCp/6+KcPpeyCVpiBI0++rIR/Kg+7p5tJDyr DO2lHocfwILv6+7/gTj5fN6GqZou1jMTtPOjbILvwPJqARgN76OjzcPpajfeup14F/x/ 1Jap3X4jsZMWr+xOWzzzNXVIEZ8IzX+t5bokbCI84B+tQM5YFL2einxY1kgf+wTt4Uhn JEbRJQ3/ih2cxNutvkTudv1tbTHtleQVc41XTt+biFqALU11EmSQVpGMC2d4oGVHHzuj sOMVLwlwakSttJiP/hLKzWWxa9boZesVSi1/Dli8SComk0g4RSyGiNeY+ieQQD7mSwob zTZg== X-Gm-Message-State: AMCzsaUcxmk7HCAyok8rHedb2nsIh4iCtV344AdeIveBEfDGy+KyjvTK Gy3MwfHmDKkiI98JEGTbVC1CRA== X-Google-Smtp-Source: ABhQp+Qkgh3RlAHdz1Mp9HQAFuTDwi/SEnS3qWR+Zjdf/Zsa3mzNpwNY3jLH08kDrsiBF1zlAz8lJw== X-Received: by 10.28.45.5 with SMTP id t5mr1179350wmt.108.1507894936464; Fri, 13 Oct 2017 04:42:16 -0700 (PDT) Received: from Macintosh-6.local ([2001:720:410:1010:1472:3c39:d26b:5130]) by smtp.gmail.com with ESMTPSA id l73sm1055298wmd.47.2017.10.13.04.42.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2017 04:42:15 -0700 (PDT) To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <839cc83c-f060-f812-c8e7-a2530798d6ee@it.uc3m.es> <22CB67D2-B6BE-4AF2-8FBD-68C9F3F91F11@tik.ee.ethz.ch> <76f10b55-0538-0832-3b58-5226ee39959e@it.uc3m.es> <62e06c68-3b97-ce39-558f-20189775b00c@tik.ee.ethz.ch> Cc: tcpm IETF list , Jana Iyengar , Anna Brunstrom From: marcelo bagnulo braun Message-ID: Date: Fri, 13 Oct 2017 13:42:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <62e06c68-3b97-ce39-558f-20189775b00c@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [tcpm] way forward (was Re: ECN++: Whether to allow ECT/CE marking of pure ACKs and what response to recommend to feedback reporting that a pure ACK was CE marked. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 13 Oct 2017 11:42:22 -0000 El 13/10/17 a las 12:44, Mirja Kühlewind escribió: > > > Anyway we seem to agree below on using ECN for pure ACKs only with > AccECN, right? > I am ok with that, other peopel feel this is a good way forward? Regards, marcelo > Mirja > > >> In AccECN, the bias can be less, i think, because since the pure ACK has >> not data, the amount of bits that experienced congestion is small, so >> the bias is small. This is the reason why i think it is more acceptable >> to have this behaviour with AccECN than with no AccECN. >> >> So, my understanding is that the options are >> - not ECN marking of pure ACKs, which results in higher loss probability >> - marking pure ACKs but not responding to congestion, bad precedent >> - marking pure ACKs and responding to congestion, bias towards >> decreasing the CWND >> - marking pure ACKs, responding to congestion and adding some way to >> increase the CWND, complicated and inaccurate. >> >> So, from my side, I think your proposal of only supporting ECN marking >> of pure ACK when AccECN is supported seems a good trade-off, while not >> perfect, may be a good way forward >> >>> If there is a congestion marking that means the link is congested >>> and you should react to it. Now the question is what’s the right >>> reaction, and there multiple cases here: >>> >>> 1) You send pure ACKs interleaved with data packets that means your >>> congestion window might be large and any indicate of congestion >>> should trigger a congestion control reaction accordingly. >>> >>> 2) You only send pure ACKs; in this case your congestion window >>> should reduce to min_win sooner or later anyway; if there is >>> congestion this might happen a bit quicker but if there is >>> congestion and you already know about this, you should also not just >>> resume sending with your previous rate. Then if you are at min_cwnd >>> you cannot reduce it any further, therefore you MAY consider using >>> AckCC in this case, or more generally speaking apply some algorithm >>> increase your delayed ack factor. >> >> See above, the concern here is the biased introduced towards reducing >> the CWND. >> >>> I really don’t think that increasing the congestion window based on >>> ACK is even a possible option. You don’t get ACKs for ACKs so you >>> never know if an ACK was successfully received. That means you don’t >>> even have any information that would allow you to react on. >> >> You do get some idea of what ACKs got through, but i agree that given >> the cumulative nature of ACKs, some acks can get lost undetected. >> I agree this is not perfect, but not of the options are. >> That being said, I also think that this option introduces complexity >> with little benefit, so if all solutions are imperfect, we should at >> least choose one that is at least simple. >> >> Regards, marcelo >> >>> Mirja >>> >>>> Am 09.10.2017 um 12:34 schrieb marcelo bagnulo braun >>>> : >>>> >>>> Hi, >>>> >>>> Regarding, draft-ietf-tcpm-generalized-ecn, we still have the open >>>> issue regarding whether to allow ECT/CE marking in pure acks and >>>> what response to reccomend if a pure ack encountered congestion. >>>> >>>> After considering the discussion in the last meeting and in the ml, >>>> we propose the following text in the draft: >>>> >>>> --------------------- >>>> >>>> For the experiments proposed here, the TCP implementation will set >>>> ECT on pure ACKs. It can ignore the requirement in section 6.1.4 of >>>> RFC 3168 to set not-ECT on a pure ACK. >>>> >>>> A host that sets ECT on pure ACKs SHOULD respond to the congestion >>>> signal resulting from pure ACKs being marked with the CE codepoint. >>>> The specific response will need to be defined as an update to each >>>> congestion control specification. Possible responses to congestion >>>> feedback include regulating the pure ACK rate (see AckCC [RFC5690]) >>>> or reducing the congestion window (CWND). >>>> >>>> However, if the congestion response implemented reduces the CWND >>>> upon the report of CE marking of Pure ACKs, then the congestion >>>> control algorithm must also increase the CWND upon delivery of pure >>>> ACKs without a CE mark, to avoid a bias in the congestion control >>>> algorithm. >>>> >>>> (We can also include some of the description of how to do this >>>> based on the text below for RFC3168 and AccECN in an appendix.) >>>> >>>> --------------------- >>>> >>>> Some background about this proposal: >>>> >>>> First of all, it's worth reminding that without ECN++, TCP >>>> currently is not required to detect loss of pure ACKs and is not >>>> required to react to them. >>>> The current draft states that it is allowed to ECT/CE mark the pure >>>> ACKs and that: >>>> " A host that sets ECT on pure ACKs MUST reduce its congestion >>>> window >>>> in response to any congestion feedback, in order to regulate >>>> any data >>>> segments it might be sending amongst the pure ACKs. It MAY also >>>> implement AckCC [RFC5690] to regulate the pure ACK rate, but >>>> this is >>>> not required. " >>>> >>>> The feedback we received in the Prague meeting was: >>>> >>>> - It is valuable to allow ECT/CE marking of pure ACK to avoid high >>>> drop rate when there is congestion. There is a strong case for >>>> ECN-capable pure ACKs as they are critical for connection performance. >>>> >>>> - The sender of the pure acks must respond (somehow) to the >>>> congestion signal resulting from getting CE marks in pure ACKs. >>>> Recommending not to respond to a received congestion signal seem >>>> like a bad recommendation to make in general and setting a bad >>>> precedent. >>>> >>>> There are two possible responses: reduce CWND (somehow) and/or ACK >>>> congestion control (ACK CC) (as defined in RFC5690). >>>> >>>> - The feedback regarding ACK CC is that it is too complex and with >>>> too many corner cases to mandate its implementation, so we should >>>> not mandate it. >>>> >>>> - Regarding reducing the CWND, there were several arguments against >>>> doing this. A very compelling argument is that since we do not >>>> increase the CWND when pure ACKs are successfully delivered, if we >>>> reduce the CWND when they are CE marked, then we have a strong bias >>>> towards reducing the CWND. In particular, in the case the one >>>> endpoint is only sending pure ACKs, the likely result is that the >>>> CWND will be 1 after a while. >>>> >>>> It is possible to address this issue by allowing the increase of >>>> CWND in case there are no CE marks in the pure ACKs. >>>> >>>> A possible approach for this would be the following: >>>> >>>> - if ECN++ is being used with RFC3168 ECN, then we simply do what >>>> is done with data packets, i.e. if during a RTT no ECE is received, >>>> the sender increases its CWND and if the sender receives one or >>>> more ECE marks, then it reduces its CWND. The only difference is >>>> that we include pure ACKs as well. >>>> >>>> - if ECN++ is used with AccECN, the situation is slightly more >>>> complex because the sender of the pure ACKs needs to keep track of >>>> the pure ACKs that got CE marked and those that didnt. But the >>>> sender of the pure ACKs knows how many pure ACKs it has sent. The >>>> other endpoint includes pure ACKs in the packet count of CE marked >>>> packets that is reported using AccECN, then the sender of the pure >>>> ACKs can figure out how many pure ACKs have been CE marked and how >>>> many were not. It then can feed this information to the congestion >>>> control algorithm. >>>> >>>> (The limitation of this approach is that lost pure ACKs are >>>> accounted as delivered pure ACKs without any CE marks, meaning that >>>> in the case of severe congestion, when pure ACKs are being dropped, >>>> the congestion control algorithm will include those lost pure ACK >>>> packets as delivered and increase the CWND the corresponding share. >>>> Since pure ACKs are small packets, it is not clear how much of a >>>> problem is this. Similarly (but worse), with 3168 feedback, even if >>>> detecting CE on pure ACKs, if pure ACKs are lost and there's no CE >>>> on a pure ACK within an RTT, cwnd will continue to increase. >>>> However, in both cases, it is still better with ECN++, because >>>> without ECN++ there was no response to either dropped or CE-marked >>>> pure ACKs.) >>>> >>>> It might be useful for the congestion response to be proportionate >>>> to an estimate of the bytes marked rather than packets marked, by >>>> adding an assumed header size on the wire to the size of every >>>> segment (otherwise pure ACKs would have zero size and not require >>>> any response). This would be up to the implementation. >>>> >>>> >>>> Note that the response to the congestion signal is outside the >>>> scope of draft-ietf-generalized-ecn, because it depends on the >>>> specific CC, e.g. Reno, Cubic, Compound, etc) >>>> >>>> That being said, we should include some guidance of what type of >>>> response is sensible, particularly for the standards track CC >>>> [RFC5681]. >>>> >>>> thoughts? >>>> >>>> Bob & Marcelo >>>> >>> >> > From nobody Sun Oct 15 19:08:22 2017 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 D0A81120724 for ; Sun, 15 Oct 2017 19:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 lwdmwpFseMw9 for ; Sun, 15 Oct 2017 19:08:20 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD2B124239 for ; Sun, 15 Oct 2017 19:08:20 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 03AD3174D3 for ; Sun, 15 Oct 2017 19:08:23 -0700 (PDT) Date: Sun, 15 Oct 2017 19:08:22 -0700 From: hiren panchasara To: tcpm@ietf.org Message-ID: <20171016020822.GC34412@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2/5bycvrmDh4d1IB" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [tcpm] RTO and PTO (tlp) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Oct 2017 02:08:21 -0000 --2/5bycvrmDh4d1IB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Seems that only one "timeout" mechanism needs to be active at any point in time. Is that the correct assessment? It seems to me that linux schedules RTO only when PTO can't be scheduled. And when that PTO fires, at the end it makes sure either PTO or RTO is scheduled. Cheers, Hiren --2/5bycvrmDh4d1IB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJZ5BSTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l97gH/3WNAyeKm3EMQYSx7jxtFm4V C61ZMbjnZfaH/OWWFd3cyraNLjRmwfSxC3J70RlstQpxZldQwYxPc+jAK1SyW87m Vk5XJwOwUCQsnATbDo/NgqvVA7ILnLOqN/KS4/+EYQTuBffsjF7i04G/7m5ShtJZ zPVMvNHv3Rrh6KJjlOF4pmMU8crvNqIXxo19793NwuwhPDLKLdYufg80u/WRlEcv 4lMBaGy32V+RNZubcc75Rfx464jxgeDmjrNq9u1d05va73hElF+TnW/XG6SO+TyR pjpkuedxfeeosOEUu9XQuNTKhXnp7eF1FaRnkP5oEngUhJDPqbCNCFqVYYhuUUw= =76pb -----END PGP SIGNATURE----- --2/5bycvrmDh4d1IB-- From nobody Sun Oct 15 19:49:30 2017 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 66B57133341 for ; Sun, 15 Oct 2017 19:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 NJbbJCQEj4Ru for ; Sun, 15 Oct 2017 19:49:28 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0114.outbound.protection.outlook.com [104.47.42.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1FD1320DC for ; Sun, 15 Oct 2017 19:49:28 -0700 (PDT) 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=HI0XMSboONAY774mqtWnB662+tYEhl9s4X8fcWsuc/o=; b=DBpxObFh/vdwgSyxoVNpLaiGc3Zbw2aWRDiVYkx5mt/7SXBQ3wInioCwEq6zGOQA6k8KOXCHd5SX0sBeq6yBaymE6JAytOOEhNt64pAro2UqZG0EdP6bVKmruOyJPFVNdSDeXUm1yWagK3mD1mZDG1QA9gNpFjPHYq1wYWo6Thg= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0758.namprd21.prod.outlook.com (10.173.192.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.178.1; Mon, 16 Oct 2017 02:49:26 +0000 Received: from CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) by CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) with mapi id 15.20.0156.003; Mon, 16 Oct 2017 02:49:26 +0000 From: Praveen Balasubramanian To: hiren panchasara , "tcpm@ietf.org" Thread-Topic: [tcpm] RTO and PTO (tlp) Thread-Index: AQHTRiOnXqju3jzhGkGWwbMOo3UxrqLlxH8w Date: Mon, 16 Oct 2017 02:49:26 +0000 Message-ID: References: <20171016020822.GC34412@strugglingcoder.info> In-Reply-To: <20171016020822.GC34412@strugglingcoder.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:2::7a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0758; 6:VpakiUsZfUP3e9v06jWE1jkkkPkx+kHimf/WmlBaIn8hUXUfeU7UqdL3D8XyizIvwX9EWsu1iAzVs4htzBXfK1cqh1xrir7mQi2niFznlpTLfEIigaGqlFWp1nZdeC7hyvueI/Oka+tR8KJpit6rArMKZV3/vN0U5L+82SIdgOIER7GSqpdATzGHPoUzAClzLO3YkTqsXYd00l2diJMFTJBMwlXyyWN6bnxDfKvqV32mcZbQJAsQb+LXRevhiKZS1b5VOMc5hGvDL72PvSoDPaZCqS1oW2+329o5XQOlxTuVD5Pg8YT8Pi+s1DRlEOzsArW/9A9HW3BvQKxH9jHZi4udsPTtaJev/EAPGi6eTt0=; 5:t6xdjiM5K0N/P1d6T14zDGq1uAbHEA22rJflFGm+0BB4qeR5kGt4hRFeyDIcPIdFzSYLwotKDR4aDM+8Z7ajTsXMqO8cTvYLM9CPWm/xpsHSR/Ifs1fsKAV77kiId8inwXyXFfB9qhGmlEz7BbtOTik7cNeWxQswZ+Xxm5jTxO0=; 24:pRQD8ZxRfy8+7hOejc3WdIAs9D4n4vaV3n25d4RDI/TJJzlrTfso+O1E+AmKFGk2t0buL9sXLV6HhuuDkLVSCg3HbfVYBBLuD4JSlyWL6po=; 7:Kv6E0y5W4DoNATfQ6gI4JPrXVuhLM7GVIUCW5a/osjd8D8WpoblBXPy4TAYYPlBUlwGzQADu7hj3PUplxXpOAfnoTyrShKDt0wG71mI84R/otIzBvKuzFqjcZvcsdLoiIqOKEqxXNDr1O6LKzr3LijyJCYrvcxrQAQwHCPuGhBB8S1mtxMcDt2EpBeAf0hkp4c/D6AxCbt07yKFMGSvRblUjYp54JZVgUZqksHpCo6+pFTls14Y2htXC7cT4FXHL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 83236e4b-f404-4040-d040-08d5144083be x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603219)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0758; x-ms-traffictypediagnostic: CY4PR21MB0758: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0758; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0758; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(47760400005)(199003)(189002)(13464003)(377454003)(53936002)(2900100001)(8676002)(5660300001)(6246003)(81166006)(81156014)(77096006)(7736002)(99286003)(6506006)(2950100002)(74316002)(101416001)(33656002)(55016002)(305945005)(6436002)(7696004)(102836003)(6116002)(229853002)(9686003)(105586002)(106356001)(53546010)(10290500003)(189998001)(25786009)(14454004)(478600001)(8990500004)(3660700001)(10090500001)(8936002)(2906002)(3280700002)(54356999)(76176999)(2501003)(97736004)(50986999)(316002)(68736007)(22452003)(110136005)(86362001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0758; H:CY4PR21MB0277.namprd21.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 83236e4b-f404-4040-d040-08d5144083be X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2017 02:49:26.1404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0758 Archived-At: Subject: Re: [tcpm] RTO and PTO (tlp) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Oct 2017 02:49:29 -0000 In the Windows implementation of TLP, the retransmit timer (which typically= schedules RTO) is used for scheduling PTO. Only one timeout mechanism is a= ctive and it simplifies the logic. The implementation can distinguish in th= e expiration handler that PTO was armed versus the RTO by using a bit that = tracks this. -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of hiren panchasara Sent: Sunday, October 15, 2017 7:08 PM To: tcpm@ietf.org Subject: [tcpm] RTO and PTO (tlp) Seems that only one "timeout" mechanism needs to be active at any point in = time. Is that the correct assessment? It seems to me that linux schedules RTO only when PTO can't be scheduled. A= nd when that PTO fires, at the end it makes sure either PTO or RTO is sched= uled. Cheers, Hiren From nobody Sun Oct 15 22:57:53 2017 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 81EAF1342EE for ; Sun, 15 Oct 2017 22:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 VIjw_c5BrE8J for ; Sun, 15 Oct 2017 22:57:50 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 B924A1342ED for ; Sun, 15 Oct 2017 22:57:50 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 31so3989453qtz.9 for ; Sun, 15 Oct 2017 22:57:50 -0700 (PDT) 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=VuJ6BmqKsDMRhGESel31rTIOE7Om6hV+oCJx7qaAAfo=; b=gu89bIMK62bApheV5QSOYF4GsEpEsXzQ8cQEN2YxRAXhjSws6dRWcY/EpFcC646cQY CywQZUSG0ck14+N5Dz7M89vT9Qed5di8SyOn+O8PoJtZ/z4Y8b+NnJoiQTKG6cf64jyv PAWDgi8vL/iNyKexjIySo633Ct6dI1x9gVO6ZbHSKAxuhjEgu/6D0wb7rGpYHGhu29z2 32vw9A6PDEAA7m2iKebOMp8wAPPbPsL2t5rJXWTVFSNoBCirnesafJ6IHxe3CGNNqovm zfppQqT+UQUP+iXX2QSI8sh7phZqmyeEWYr03NuG6V3NXVciF1E4f/pKAq7l3S1YvkiW 3OWQ== 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=VuJ6BmqKsDMRhGESel31rTIOE7Om6hV+oCJx7qaAAfo=; b=L5RYlsCm78Uq1V7KEmb++lACTCu7JKXDRk49Nft44rQudKQvUWUPngM++oJCC+o/UT z3/+MJ+AFs+1ejJj2U/z7FUYRRnIz4W/y/kRIU7uRHZWiJ3ML+FdnYvjwe+6s9HNmPIR ULBbrsUbKqOUtJ6klPC1j8WEq5lbV6gSCF2wfI0lbnx0cVOZbz1lJMHWY1y+Kc5dzASz vSf8+AMhwU1k5uVfyJdrQHOw8j2YTRzdYaiBzWgvQZXXyFZ6jro3JwJHBHWeJmd9slN2 VNJKozbqwovEnu1Go/pwDIoIXhY/NKQoFS9T7EvtT/0ETOl8t2MSawjlA7lkovYUaBZj 8+zA== X-Gm-Message-State: AMCzsaXuP5GjlVHZmqP/7EZg3ZUHOZEbHUeDVcHsjn5YJ+j5li0/MbOx UzljXsD4hhb+JwJd2bDyAblx1UmF99SZ4X4DnI4yd7yr X-Google-Smtp-Source: ABhQp+RIOPPMPdz0ilC0QU+tsHiFCLNBs9gY5wdg2hOgT86KtfvWkLZaXmPVks1os2ic4UgKC7v32Kdk1jyaL/gJEb0= X-Received: by 10.37.186.8 with SMTP id t8mr5998252ybg.91.1508133469335; Sun, 15 Oct 2017 22:57:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.70.5 with HTTP; Sun, 15 Oct 2017 22:57:48 -0700 (PDT) In-Reply-To: <20171016020822.GC34412@strugglingcoder.info> References: <20171016020822.GC34412@strugglingcoder.info> From: Jana Iyengar Date: Sun, 15 Oct 2017 22:57:48 -0700 Message-ID: To: hiren panchasara Cc: tcpm IETF list Content-Type: multipart/alternative; boundary="f403043da404b74d37055ba3af0b" Archived-At: Subject: Re: [tcpm] RTO and PTO (tlp) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Oct 2017 05:57:52 -0000 --f403043da404b74d37055ba3af0b Content-Type: text/plain; charset="UTF-8" Hi Hiren, This is how we implement it in QUIC. We use the same timer, first for TLP and then after for RTO. - jana On Sun, Oct 15, 2017 at 7:08 PM, hiren panchasara < hiren@strugglingcoder.info> wrote: > Seems that only one "timeout" mechanism needs to be active at any point > in time. Is that the correct assessment? > > It seems to me that linux schedules RTO only when PTO can't be > scheduled. And when that PTO fires, at the end it makes sure either PTO > or RTO is scheduled. > > Cheers, > Hiren > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --f403043da404b74d37055ba3af0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hiren,

This is how we implement it i= n QUIC. We use the same timer, first for TLP and then after for RTO.
<= div>
- jana

On Sun, Oct 15, 2017 at 7:08 PM, hiren panchasara <hiren@strugglingcoder.info> wrote:
Seems that only one "timeout" mechanism needs to be= active at any point
in time. Is that the correct assessment?

It seems to me that linux schedules RTO only when PTO can't be
scheduled. And when that PTO fires, at the end it makes sure either PTO
or RTO is scheduled.

Cheers,
Hiren

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


--f403043da404b74d37055ba3af0b-- From nobody Mon Oct 16 00:25:15 2017 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 2A797134330 for ; Mon, 16 Oct 2017 00:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 igiWUpoXe_M1 for ; Mon, 16 Oct 2017 00:25:12 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8A46613432A for ; Mon, 16 Oct 2017 00:25:12 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 7A3751761D for ; Mon, 16 Oct 2017 00:25:15 -0700 (PDT) Date: Mon, 16 Oct 2017 00:25:15 -0700 From: hiren panchasara To: tcpm@ietf.org Message-ID: <20171016072515.GF34412@strugglingcoder.info> References: <20171016020822.GC34412@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Il7n/DHsA0sMLmDu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [tcpm] RTO and PTO (tlp) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Oct 2017 07:25:13 -0000 --Il7n/DHsA0sMLmDu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Thanks Praveen and Jana! This seems quite logical and at least 3 major implementations are also doing this so I wonder if this is something that can be noted in the TLP draft to help implementers. Or is it too much of an implementation detail? Cheers, Hiren --Il7n/DHsA0sMLmDu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJZ5F7bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lpkEH/j1RutP/yKrigLUnS/qzUG3X MrfKKybsQxm3qeC49HsityQZM615GlLIM9SE4oukGrb17mV/5EYscvY8Sssbw+p4 8dUgusK/kGIHc1jGnmRfBPwB4xeFoEtGMtpsMSvzuBQkiKaitvyiaS1ptXHM4Mj/ sUNpXhDlYLUerkzsMgP85s4xsmferjK3ekTB6vK1zFmE8lLVxRtoRUy5yhLl2GCd YwCRrkkBWaUiZV10SwMq8waD5/fOJXdwQ5C0nxDoUP1I7KB6Hfnt+KChHKwiVXJ+ E0FqVWaQmbCfGQBu/jEQtpP7D136Ck/zHQGh+lDh225rW/iyoX0YU+cXjeqJu6A= =dfoE -----END PGP SIGNATURE----- --Il7n/DHsA0sMLmDu-- From nobody Mon Oct 16 06:50:22 2017 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 6C928132D96 for ; Mon, 16 Oct 2017 06:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 vSPnTs7Oz5hD for ; Mon, 16 Oct 2017 06:50:15 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 5AEDF124B17 for ; Mon, 16 Oct 2017 06:50:15 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id u138so3549716wmu.4 for ; Mon, 16 Oct 2017 06:50:15 -0700 (PDT) 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=priJdOvPkiPgYTXmG+NwS1qYNZZUDci3K59cXffJrF0=; b=kHp95dq9/yVcphW33w99WMBinwqqBx0hXvg6dbu+Lgb9K3rpYurY+AG7rlBaxqo/bh 4JVI++sCPT0E1tG3hGATaPIcbGHoXYwC37j4AEM/m4Gbv4pHpxKFoJt6Utio9Torj+IA qwRG0THF5QXgCdSDhdXwDFmagmhpq9hJaFD/RSYFdwnG1lVfY5INBIhZkfR39Cguyovo dHGzUXvFc6+6Jy4TCZQwTVxDtEAfTp0HumYMLezzhpJ+r93KoN62Uw6a5AkmgKls10K5 L7qH3SMXwqwvUYbLqSg0oxYI+RYi5mEzecIrcpo81CQzdmQi3vh97x+QrHLt4zE9o+ko wRaw== 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=priJdOvPkiPgYTXmG+NwS1qYNZZUDci3K59cXffJrF0=; b=rIWfOByHu/Lny4KvkmkkuYIisc0oKAXhlg3mbF9ARxZCpSMSSCy+tDWEv9U3sRVG6D e6V8jIV0c0N1CS1ZRtlVMCtW4Ut2UY6v91zHvU7cM8/p4lTX5csr4eharq1HFRzerbvV sUatbolBxB+7yIszEXsbtpwK1nt41ToPhmIBir5JblNn/cjQ50fEZmhWKq8uFyKlnSdc 22hYR9S3DKinPaWGNglWPo95L0QWdEiVb9HpZvD83XWf99LO90GDtXwaBBa0NDxLOjlo fkSYID2doYT3UjtqyqagNEBQtK7zuwnh2AONPLoan5T5/Os5x0YkBkLhlf8zzm7o9Tpp k1hw== X-Gm-Message-State: AMCzsaWp0GRjgxt7cL2uVsI+GYmuqEEdGe3pARnDZ9uSUOcZ0xs9+jIt p+GdrIULr/cDF/9+PhfWwBFDfOPIvC51XlCLX7i46Plh X-Google-Smtp-Source: ABhQp+R7+uIS5FLjcjBIb1H6AOdScfglcPg6H8lv0QmWY0OOjy4hhDhX9fTOGz4yl5UKlFEmp+RQfNxYw1LxkbgybV8= X-Received: by 10.28.180.2 with SMTP id d2mr901000wmf.118.1508161813477; Mon, 16 Oct 2017 06:50:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.146.137 with HTTP; Mon, 16 Oct 2017 06:49:52 -0700 (PDT) In-Reply-To: <20171016072515.GF34412@strugglingcoder.info> References: <20171016020822.GC34412@strugglingcoder.info> <20171016072515.GF34412@strugglingcoder.info> From: Neal Cardwell Date: Mon, 16 Oct 2017 06:49:52 -0700 Message-ID: To: hiren panchasara Cc: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="001a114b00cc2890bc055baa49a1" Archived-At: Subject: Re: [tcpm] RTO and PTO (tlp) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Oct 2017 13:50:17 -0000 --001a114b00cc2890bc055baa49a1 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 16, 2017 at 12:25 AM, hiren panchasara < hiren@strugglingcoder.info> wrote: > Thanks Praveen and Jana! > > This seems quite logical and at least 3 major implementations are also > doing this so I wonder if this is something that can be noted in the TLP > draft to help implementers. Or is it too much of an implementation > detail? > Hiren - Good point. I agree it would be useful to clarify this in the RACK+TLP draft. I have proposed some text to my co-authors, and we will iterate on this. So hopefully this should be more clear in the next revision. thanks, neal --001a114b00cc2890bc055baa49a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Oct 16, 2017 at 12:25 AM, hiren panchasara <hiren@strugglingc= oder.info> wrote:
Thanks P= raveen and Jana!

This seems quite logical and at least 3 major implementations are also
doing this so I wonder if this is something that can be noted in the TLP draft to help implementers. Or is it too much of an implementation
detail?

Hiren - Good point. I agree it = would be useful to clarify this in the RACK+TLP draft. I have proposed some= text to my co-authors, and we will iterate on this. So hopefully this shou= ld be more clear in the next revision.

thanks,
neal

--001a114b00cc2890bc055baa49a1-- From nobody Mon Oct 16 07:24:02 2017 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 D586B1344EF for ; Mon, 16 Oct 2017 07:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 Duy4xPR9uxaq for ; Mon, 16 Oct 2017 07:23:57 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id 366A51344E6 for ; Mon, 16 Oct 2017 07:23:41 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 4DB7A179FC; Mon, 16 Oct 2017 07:23:44 -0700 (PDT) Date: Mon, 16 Oct 2017 07:23:44 -0700 From: hiren panchasara To: Neal Cardwell Cc: "tcpm@ietf.org" Message-ID: <20171016142344.GH34412@strugglingcoder.info> References: <20171016020822.GC34412@strugglingcoder.info> <20171016072515.GF34412@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KscVNZbUup0vZz0f" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [tcpm] RTO and PTO (tlp) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Oct 2017 14:24:00 -0000 --KscVNZbUup0vZz0f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/16/17 at 06:49P, Neal Cardwell wrote: > On Mon, Oct 16, 2017 at 12:25 AM, hiren panchasara < > hiren@strugglingcoder.info> wrote: >=20 > > Thanks Praveen and Jana! > > > > This seems quite logical and at least 3 major implementations are also > > doing this so I wonder if this is something that can be noted in the TLP > > draft to help implementers. Or is it too much of an implementation > > detail? > > >=20 > Hiren - Good point. I agree it would be useful to clarify this in the > RACK+TLP draft. I have proposed some text to my co-authors, and we will > iterate on this. So hopefully this should be more clear in the next > revision. Thank you! Cheers, Hiren --KscVNZbUup0vZz0f Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJZ5MDwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lUK0H/jJOxA/1bFPEnK1reV2aK7qq Y1J/CW4CKRMaUSs+cNG+SO8Metkfq9592S5P/Rp8m8M7rWQnOkocPOroPYv/nrgk htu9E7jjUtWTxaRfXBc1hYcYYcYbm+eACp3oE5QNqNQWpJ35HY3vHfKcTgmZcwfO Qjz+jgSHKUl+itsxHOOIuVCWqd6kVWels7dIyvA1mEXFEqYcfvUjwpK8zaFpkPcY jQpCTiGILObj1JvmMFgDefMSFSBssSPR3gQjpfChQsz78VTdP7apyPu644NnCd1R MENNdB+DT5CLYUH/EKIKPRtwHpIWwp4egJ/7X6y+kridpE3cXdEErw23CbHvmIw= =hvyF -----END PGP SIGNATURE----- --KscVNZbUup0vZz0f-- From nobody Mon Oct 16 11:37:07 2017 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 649A2134541 for ; Mon, 16 Oct 2017 11:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 NO9_wgIjfFX0 for ; Mon, 16 Oct 2017 11:37:03 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0101.outbound.protection.outlook.com [104.47.1.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478E313453F for ; Mon, 16 Oct 2017 11:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+ZhqNTJLxmapMwy4QZr71g97Pc5vassqeTv8UxrDAYs=; b=DsiJTM24oL4QFAOXBzsFL447pxunOkzXCN6fZ/QFWfm1L80yEAOr8py8knyCc4z4Ey978pvcQAqBOZJyNXtQF/LTxT95vgats/3bRo1I/3saMt6vyiHX67U2MkPE+HAlrwiclyeV1f3ZkTIzMFACIDWA1QnZjoNH5JWXroOOF+U= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2548.eurprd07.prod.outlook.com (10.173.92.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Mon, 16 Oct 2017 18:36:58 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::9d2f:1a66:87da:209e]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::9d2f:1a66:87da:209e%18]) with mapi id 15.20.0077.022; Mon, 16 Oct 2017 18:36:58 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: Carles Gomez Montenegro , "jon.crowcroft@cl.cam.ac.uk" Thread-Topic: [Lwip] FW: I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-01.txt Thread-Index: AQHTRq2/mkLrFz+cQki5pQ+TGk8SIQ== Date: Mon, 16 Oct 2017 18:36:58 +0000 Message-ID: References: <150809235685.12141.6306659248838809120@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [131.228.32.169] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2548; 6:YrNrWdCW3lUsjbHpFrJizvNpfV34QOim4IhAayZ3pNhsuYSE0jNa5nTgMf9tiwX7GjKRu1os2rb6wTLB6NcSXONCOonmlbc6ibg5ayJI1PRvZppX+N0Bb1jxzu78P0ez6Ny7j29EKkkZXOMj08isV1tAXVwHHRIk53I24WzZ/dvweOVyrjmJ7KiLCNOwlZ6cduWUEmNEKF4N6vM903yAbkif3wmBI2fAZpAuc2pfjB29cTMqqfbGkjSp9NBZKidjfTzFReimkj0fxYeG6dSr5bHZr9nnJOCj0rO/7F876aTUg0mZ84uDQgLKgkfN3ikl3w3c+16uNk90IWfC7246Cg==; 5:GUYVUZ9ruMKm6+AUBTVQOrgy4jcE5cFgjBQRWcqMDSrebBtx4bY68LOjskxszc0+r2L/TDQNzIz72zqS7yCRv0DIrA6peBzt0dST6mzljWguef9T1LRlVpeyg2eaUplIh5iXGmrPoOC+8QpwrdSp0uAK9CinHCNnLvBJOSi/q+M=; 24:XTQ42vHdnxEJtEuMte/LGf8XLAZpNXnCqduoUCKSkf36r5oITrSpaNMqGUkJzAJoSUDMMzOoAWLfKghEDlhjFFoo4GTl4JEK80Bw5uPwZBg=; 7:JKCXmtxyTPb0qH83B987/WmqZykRi+F+tP51K/74WSEDbVuo/ZuYfTfAwBExEdroMBJw0PI9DJdFjRhuYgynl55mkxm853E9YlCpNuoOqAa/Sun45IwPpsofivpHQyGh1WGqJx5MIwjAjFIiNN2dNp+c/73hPJbV5748LceIBW7a3McyG2J061MEQi0STKCZhRl/Lnpv+44RrrFI5uvk9BTtI34MOt5Yjee38pnwmAI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9de5c1fb-c913-4352-1957-08d514c4e270 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM5PR0701MB2548; x-ms-traffictypediagnostic: AM5PR0701MB2548: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2548; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2548; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(13464003)(377454003)(53754006)(377424004)(199003)(189002)(86362001)(66066001)(53546010)(53936002)(5660300001)(6916009)(54906003)(2950100002)(105586002)(316002)(2351001)(106356001)(8936002)(2501003)(74316002)(5250100002)(8676002)(81166006)(1730700003)(97736004)(81156014)(4001150100001)(6506006)(5640700003)(6436002)(9686003)(2900100001)(230783001)(6306002)(2473003)(229853002)(7736002)(55016002)(2940100002)(99286003)(3846002)(102836003)(6116002)(76176999)(54356999)(50986999)(3280700002)(33656002)(478600001)(305945005)(2906002)(25786009)(189998001)(966005)(7696004)(101416001)(4326008)(3660700001)(68736007)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2548; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2017 18:36:58.6998 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2548 Archived-At: Subject: [tcpm] FW: [Lwip] FW: I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Oct 2017 18:37:05 -0000 I believe that this version should address the key comments received so far= from TCPM contributors. Further improvements are planned. Please feel free= to review this new version, and please post comments to the lwip list. Thanks Michael -----Original Message----- From: Lwip [mailto:lwip-bounces@ietf.org] On Behalf Of Scharf, Michael (Nok= ia - DE/Stuttgart) Sent: Monday, October 16, 2017 8:29 PM To: lwip@ietf.org Cc: Jon Crowcroft Subject: [Lwip] FW: I-D Action: draft-ietf-lwig-tcp-constrained-node-networ= ks-01.txt Hi all, Version -01 should address all recent feedback and comments. Here is an ove= rview of the changes compared to -00: o Changed title and abstract o Clarification that communication with standard-compliant TCP endpoint= s is required, based on feedback from Joe Touch o Additional discussion on communication patters o Numerous changes to address a comprehensive review from Hannes Tschof= enig o Reworded security considerations o Additional references and better distinction between normative and in= formative entries o Feedback from Rahul Jadhav on the uIP TCP implementation o Basic data for the TinyOS TCP implementation added, based on source c= ode analysis Please have a look at the new version and please feel free to comment. Further extensions and improvements are planned for the next version. Thanks Michael -----Original Message----- From: Lwip [mailto:lwip-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Sunday, October 15, 2017 8:33 PM To: i-d-announce@ietf.org Cc: lwip@ietf.org Subject: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-0= 1.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Light-Weight Implementation Guidance WG of= the IETF. Title : TCP Usage Guidance in the Internet of Things (IoT= ) Authors : Carles Gomez Jon Crowcroft Michael Scharf Filename : draft-ietf-lwig-tcp-constrained-node-networks-01.txt Pages : 20 Date : 2017-10-15 Abstract: This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characterstic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-netwo= rks/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-0= 1 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-= networks-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lwig-tcp-constrained-node-ne= tworks-01 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip From nobody Tue Oct 17 16:28:24 2017 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 CA0571331E3; Tue, 17 Oct 2017 16:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 J6PpMgX93KEM; Tue, 17 Oct 2017 16:28:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE1F13319E; Tue, 17 Oct 2017 16:28:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E24A1B812E7; Tue, 17 Oct 2017 16:27:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, tcpm@ietf.org Message-Id: <20171017232748.E24A1B812E7@rfc-editor.org> Date: Tue, 17 Oct 2017 16:27:48 -0700 (PDT) Archived-At: Subject: [tcpm] RFC 8257 on Data Center TCP (DCTCP): TCP Congestion Control for Data Centers X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 17 Oct 2017 23:28:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8257 Title: Data Center TCP (DCTCP): TCP Congestion Control for Data Centers Author: S. Bensley, D. Thaler, P. Balasubramanian, L. Eggert, G. Judd Status: Informational Stream: IETF Date: October 2017 Mailbox: sbens@microsoft.com, dthaler@microsoft.com, pravb@microsoft.com, lars@netapp.com, glenn.judd@morganstanley.com Pages: 17 Characters: 37357 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-dctcp-10.txt URL: https://www.rfc-editor.org/info/rfc8257 DOI: 10.17487/RFC8257 This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Oct 20 14:26:50 2017 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 06D0B132D79; Fri, 20 Oct 2017 14:26:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150853480297.15481.2414721387863272966@ietfa.amsl.com> Date: Fri, 20 Oct 2017 14:26:43 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-alternativebackoff-ecn-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 21:26:43 -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 WG of the IETF. Title : TCP Alternative Backoff with ECN (ABE) Authors : Naeem Khademi Michael Welzl Grenville Armitage Godred Fairhurst Filename : draft-ietf-tcpm-alternativebackoff-ecn-02.txt Pages : 12 Date : 2017-10-20 Abstract: Recent Active Queue Management (AQM) mechanisms instantiate shallow buffers with burst tolerance to minimise the time that packets spend enqueued at a bottleneck. However, shallow buffering can cause noticeable performance degradation when TCP is used over a network path with a large bandwidth-delay-product. Traditional methods rely on detecting network congestion through reported loss of transport packets. Explicit Congestion Notification (ECN) instead allows a router to directly signal incipient congestion. A sending endpoint can distinguish when congestion is signalled via ECN, rather than by packet loss. An ECN signal indicates that an AQM mechanism has done its job, and therefore the bottleneck network queue is likely to be shallow. This document therefore proposes an update to the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to loss. This document also recommends this approach to be adopted by any other transport protocol that implements a congestion control reduction to an ECN congestion signal. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-02 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-alternativebackoff-ecn-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-alternativebackoff-ecn-02 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 Oct 20 17:25:25 2017 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 1EEC713448F; Fri, 20 Oct 2017 17:24:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tcpm@ietf.org, ietf@kuehlewind.net X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854545412.20809.4482319349743782781.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:14 -0700 Archived-At: Subject: [tcpm] tcpm - Requested session has been scheduled for IETF 100 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:14 -0000 Dear Michael Scharf, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tcpm Session 1 (2:30:00) Thursday, Morning Session I 0930-1200 Room Name: Olivia size: 150 --------------------------------------------- Request Information: --------------------------------------------------------- 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 People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 20 19:09:53 2017 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 A28EB13207A for ; Fri, 20 Oct 2017 19:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xhxafwZQdH0s for ; Fri, 20 Oct 2017 19:09:49 -0700 (PDT) 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 C43BA128D0D for ; Fri, 20 Oct 2017 19:09:49 -0700 (PDT) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6A48F278515 for ; Sat, 21 Oct 2017 11:09:47 +0900 (JST) Received: by mail-wm0-f46.google.com with SMTP id m72so2335691wmc.0 for ; Fri, 20 Oct 2017 19:09:47 -0700 (PDT) X-Gm-Message-State: AMCzsaV24lcN1iILAMhwLuPzaqCaiKMzMeEOrnmeUxGu1xEnyJApYomt 4KOIYPFozkASroNTcEqbdEFUo0e8/7SrJxGj4K8= X-Google-Smtp-Source: ABhQp+RdLiw3Cc7gRPIOH0Fpa62QaHWUNYNUV7bOSPj7+HPzCOlJVtpQDu6V0EsXDR7ZETx0/ZdfJtGUcF1HGPjmUQE= X-Received: by 10.28.199.75 with SMTP id x72mr448279wmf.119.1508551785292; Fri, 20 Oct 2017 19:09:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.141.148 with HTTP; Fri, 20 Oct 2017 19:09:44 -0700 (PDT) From: Yoshifumi Nishida Date: Fri, 20 Oct 2017 19:09:44 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0d7e8a49a8c2055c05156c" Archived-At: Subject: [tcpm] tcpm agenda request for IETF100 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Oct 2017 02:09:52 -0000 --94eb2c0d7e8a49a8c2055c05156c Content-Type: text/plain; charset="UTF-8" Hello, According to the agenda, we have a 2.5 hours slot at Singapore. (9:30-12:00 11/16 Thursday) If you plan to present something, please let the chairs know the following info. * Title / draft name * Presenter's name * Total time (including Q/A) Thanks, -- tcpm co-chairs --94eb2c0d7e8a49a8c2055c05156c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
According to the agenda, we have a 2.5 hours sl= ot at Singapore. (9:30-12:00 11/16 Thursday)
If you plan to prese= nt something, please let the chairs know the following info.

=
* Title / draft name
* Presenter's name
* Total time (= including Q/A)

Thanks,
--
= tcpm co-chairs
--94eb2c0d7e8a49a8c2055c05156c-- From nobody Mon Oct 23 03:12:41 2017 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 3091013F3B6 for ; Mon, 23 Oct 2017 03:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 huds3TK_GG4C for ; Mon, 23 Oct 2017 03:12:37 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 3135213F3AC for ; Mon, 23 Oct 2017 03:12:36 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1e6Zih-00085Z-V0; Mon, 23 Oct 2017 12:12:32 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id DA7C9B0058A; Mon, 23 Oct 2017 12:12:31 +0200 (CEST) To: "tcpm@ietf.org Extensions" Cc: Naeem Khademi , Michael Welzl , Gorry Fairhurst , grenville armitage From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Mon, 23 Oct 2017 12:12:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1508753552.064516603 Archived-At: Subject: [tcpm] Review of draft-ietf-tcpm-alternativebackoff-ecn-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Oct 2017 10:12:41 -0000 Hi, as promised at the last IETF meeting, here is my (lengthy) review of draft-ietf-tcpm-alternativebackoff-ecn-02. In summary: 1) more precise terminology, e.g., better distinction between buffer and queue, also use same terminology as in RFC 5681 (largely done in -02 already). 2) state more clearly that the concrete recommendations are tailored to specific congestion controls and be more open to other congestion control variants 3) the abstract is too long and section 4 contains a bit redundancy w.r.t. sections 2 and 3. in more detail 1) I would prefer to use _buffer_ for the maximum memory space that is allocated for potentially enqueued packets and _queue_ for the amount of actually queued packets, i.e., current buffer occupancy. Therefore, IMHO it makes sense to speak of shallow buffers and short queues, but not of "shallow queues". In particular, an AQM tries to keep the (longer-term) queue short in a buffer while accepting transient bursts -- the behavior therefore also differs from a "shallow buffer". 2) the main point of this draft is: it makes sense to behave different to CE-ECN marked packets than to packet loss. One benefit is to achieve higher utilization by adjusting the backoff to be less. The recommendation for two backoff factors is specific for two congestion controls, CUBIC and New Reno. For other congestion controls it may also make sense to adapt differently, but the draft doesn't provide any recommendations for them. In general, there can be lots of different congestion controls that do not need this kind of modification to keep the utilization high. 3) The abstract should be corrected according to 1 and shortened, such as: Recent Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if they are only a few or their bandwidth-delay-product is large. An Explicit Congestion Notification (ECN) signal indicates that an AQM mechanism is used at the bottleneck, and therefore the bottleneck network queue is likely to be short. This document therefore proposes an update to the TCP sender-side ECN reaction in congestion avoidance to reduce the congestion window by a smaller amount than the congestion control algorithm's reaction to loss. ------------------ Walk through: Section 2. ========== > Research has demonstrated the benefits of reducing network delays due > to excessive buffering [BUFFERBLOAT]; this has led to the creation of > new AQM mechanisms like PIE [RFC8033] and CoDel [CODEL2012] > [I-D.CoDel], which avoid causing the bloated queues that are common > with a simple tail-drop behaviour (also known as a First-In First- > Out, FIFO, queue). The first sentence is confusingly put: "reducing network delays due to excessive buffering", better rephrase. Moreover, I'd like to see a more precise description of the problem here: The main problem is here that existing loss-based congestion controls complete fill available bottleneck buffer capacity. So it's primarily _not_ the tail-drop behavior causing bloated queues, but the congestion control. There exist two approaches to reduce the queues: use different a different congestion control (modify end points) or enforce short queues in routers by using AQMs (modify intermediate systems). So a delay-based congestion control can use a tail-drop FIFO queue and still avoid excessive queuing delays, i.e., not even requiring an AQM to control the queue. > These AQM mechanisms instantiate short queues that are designed to > tolerate packet bursts. More precisely: These AQM mechanisms aim to keep a sustained queue short while tolerating transient (short-term) packet bursts. > However, congestion control mechanisms > cannot always utilise a bottleneck link well where there are short > queues. => However, currently used loss-based congestion control mechanisms > to compensate for TCP halving the "cwnd" and "ssthresh" variables in > response to a lost packet [RFC5681]. see 1), cwnd is set to FlightSize/2, not cwnd/2 (RFC5681 is quite specific about this). > This requires the bottleneck > queue to be able to store at least an end-to-end bandwidth-delay queue => buffer > product (BDP) of data, which effectively doubles both the amount of > data that can be in flight and the round-trip time (RTT) experience > using the network path. it effectively doubles the RTT only if the buffer is completely filled, usually the queue is varying over time. > ABE improves the > performance when routers use shallow buffered AQM mechanisms. See 1), e.g., "when routers use AQM controlled buffers that allow for short queues only." Section 3. ========== > This specification describes an update to the congestion control > algorithm of an ECN-capable TCP transport protocol. See 2.) This statement is very generic, whereas the recommendation is quite specific to CUBIC and NewReno. It may be useful for other congestion controls as well if they require also a more moderate response/backoff in order to keep the utilization high. Their backoff modification may however, be different. Moreover, there exist other congestion controls that don't suffer from underutilization if they react to a congestion signal. > It RECOMMENDS that a TCP > sender multiplies the cwnd by 0.8 and reduces the slow start > threshold (ssthresh) in congestion avoidance following reception of a > TCP segment that sets the ECN-Echo flag (defined in [RFC3168]). See previous comment: here you should be explicit about the particular congestion controls where the recommended behavior and parameter can be applied to. Moreover, "cwnd= max (FlightSize * beta_{ecn}, 2 * SMSS)", which is a bit different from cwnd= cwnd * beta_{ecn} (this is what the text suggests). Section 4. ========== > performance gains in lightly-multiplexed scenarios, without losing "lightly-multiplexed scenarios" means presumably that only a few flows traverse the considered bottleneck, but how many are "a few" then? three or nine or twenty? Later on it is defined as "lightly-multiplexed case (few concurrent connections)", better mention this at first use already.> > loss is detected (regarded as a notification of congestion), Standard > TCP halves the cwnd and ssthresh [RFC5681], which causes the TCP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ See 1), roughly speaking yes, but not quite correct. Moreover, packet loss can be detected by various ways, e.g., by using the retransmission timer or not; the congestion control response may differ then, too. > delay target in routers and use congestion notifications to constrain > the queuing delays experienced by packets, rather than in response to if AQMs set CE, they hope for an appropriate action, however, they'll limit the queueing delays by actively dropping packets. > that were not necessarily configured to emulate a > shallow queue see 1), short queue vs. shallow buffer > However, it interacts badly for a lightly-multiplexed > case (few concurrent connections) over a path with a large BDP. > Conventional TCP backoff in such cases leads to gaps in packet > transmission and under-utilisation of the path. Maybe combine these two sentences: However, in a lightly-multiplexed case (few concurrent connections) over a path with a large BDP, conventional TCP backoff leads to gaps in packet transmission and under-utilisation of the path. > hence the CE-mark likely came from a bottleneck with a shallow queue. controlled and short queue > Reacting differently to an ECN CE-mark than to packet loss can then > yield the benefit of a reduced back-off, as with CUBIC [I-D.CUBIC], > when queues are short, yet it can avoid generating excessive delay > when queues are long. I'm not sure that I understood the gist in this statement, better rephrase and split up into two sentences? > For non-ECN-enabled > TCP connections, Not fully clear what this means. Are the end-systems ECN capable, but the routers in between do not mark? Or does it mean that at least one end-system isn't ECN capable? > ssthresh_(t+1) = max (FlightSize_t * beta_{loss}, 2 * SMSS) RFC 5681 doesn't use any notation with "t". If you are using t, you should specify what it means. My suggestion is to avoid introducing it and to use the same terminology as in RFC 5681. I think that the beginning of section 4.3 belongs more to section 3 while that rest fits to the section title (discussion of the ABE multiplier). Section 5. =========== > 5. Status of the Update I don't understand the purpose of this section or the section title is weird at least. Is it meant to describe required changes? The use this as section title. > congestion-control algorithms, it does not require any change to the everywhere else it is "congestion control" without dash. > The currently published ECN specification requires that the > congestion control response to a CE-marked packet is the same as the > response to a dropped packet [RFC3168]. The specification is > currently being updated to allow for specifications that do not > follow this rule [I-D.ECN-exp]. The present specification defines > such an experiment and has thus been assigned an Experimental status > before being proposed as a Standards-Track update. This is largely a repetition from the introduction. > Because this advantage applies only to ECN-marked packets and not to > loss indications, the new method cannot lead to congestion collapse. I'm not sure that I can follow here. There are several forms of congestion collapse and the classical one causes unnecessary retransmissions by a timer mismatch. Maybe you can elaborate a bit more here. Section 8. ========== > http://heim.ifi.uio.no/naeemk/research/ABE/ This code was used to Full stop missing here (presumably to avoid problems with the URL). Maybe put the (most important) changes into an appendix? I'm not sure how long this URL will be valid after the RFC has been published. Regards, Roland From nobody Tue Oct 24 06:04:46 2017 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 D7E9D13F46B for ; Tue, 24 Oct 2017 06:04:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150885028488.25237.17732051012816678937.idtracker@ietfa.amsl.com> Date: Tue, 24 Oct 2017 06:04:44 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 13:04:45 -0000 Deleted milestone "Submit 2140bis document to the IESG for publication targeting a Best Current Practice RFC". URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Tue Oct 24 11:27:32 2017 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 CB37D1395E9 for ; Tue, 24 Oct 2017 11:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 ajFJPJqs-sS1 for ; Tue, 24 Oct 2017 11:27:28 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 9997B139567 for ; Tue, 24 Oct 2017 11:27:28 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id o44so21603715wrf.11 for ; Tue, 24 Oct 2017 11:27:28 -0700 (PDT) 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=1RNa5fws24fV7MGQyxRWwobqgJAv5KGAlYqlFimn7II=; b=GOSaLWyrfCQrLXBLyTDxus6XafcWjH4FAAXV727FpAmQ2aUikvyz/A87wDH4NMclAo R9neHzEhWYUgXELPU4Rwm9IKVW55I6RJKN4qd9CDEcSgkhAaMsx9+8W8oN91T2L7Sr9C FLIqFUABZJIyFjyeuPd1OqAryrF02tfjgxlaXma8Zuqx9sKbrJ1g7Gmj7/GnzuIFGrEC 3+WVne9qzaQuiMwxUEE8kfca1K0nGyWRvseCzHPU51rS705jL+5aOCBsNlJoH/G2qQNe xENbQBT6QtV0Bm0/gBB3k2kkN9Atrp4oH3Hjnpcxv7EtnjJNwk3ugC5Z43YO9AvWPewt b3Zw== 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=1RNa5fws24fV7MGQyxRWwobqgJAv5KGAlYqlFimn7II=; b=hPIFQCJ9nvrRsY/X5WEZgUjeqHrhCoDBOcZs3I7AljHRWJ3D/XFvTfFI1KbAolIg45 VRwgNq6YIRcwA+c+F+MKJD9FKC45g81lG62Kp4gCsSxoMoK8lRFGspLlcS9N9EWwY8y6 iQhTi0xD9D7nzmIdfRC7trFawVYpf5RqA0tMITrqrd7mZ7lAl2dBNj9S0ZduIAhqmv0s U8pjzZvOqMdHYEJqyGmLKo6j68GNIVFRVs9xGnAbEAqVEfmO0skABJZHIK55+ai+NSo4 Qjvo9xUIrsdINlzwlcs+oGZYIIoTBkRrU8Y+/e1k63LcblDaikikRbm1ndufgkGLJdJp EKXQ== X-Gm-Message-State: AMCzsaXoOYGOfHVVHyBIXZHWjALoVvKFSuxKFGdTC4VOPlR8WQPvV6vi QDMAvvhF45C8BwUS4T+KjT38xdMCtQJvVR7ZgD9N/A== X-Google-Smtp-Source: ABhQp+T8iidb/LgoFORuQg48Ca9BzatIq3buGPTVRXics6OhcNMk5lCPz24EsoHVChKUd/NtXWoyDvTJ5NcrbDdQu0I= X-Received: by 10.223.146.197 with SMTP id 63mr14098337wrn.180.1508869646892; Tue, 24 Oct 2017 11:27:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.91.134 with HTTP; Tue, 24 Oct 2017 11:26:46 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Tue, 24 Oct 2017 11:26:46 -0700 Message-ID: To: Yoshifumi Nishida Cc: "tcpm@ietf.org" , Neal Cardwell , Priyaranjan Jha Content-Type: multipart/alternative; boundary="94eb2c0d22c2517e34055c4f1762" Archived-At: Subject: Re: [tcpm] tcpm agenda request for IETF100 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 24 Oct 2017 18:27:31 -0000 --94eb2c0d22c2517e34055c4f1762 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 20, 2017 at 7:09 PM, Yoshifumi Nishida wrote: > Hello, > According to the agenda, we have a 2.5 hours slot at Singapore. > (9:30-12:00 11/16 Thursday) > If you plan to present something, please let the chairs know the following > info. > > * Title / draft name > Update of RACK draft-ietf-tcpm-rack-02 > * Presenter's name > Yuchung Cheng > * Total time (including Q/A) > 20m I will participate and present remotely > Thanks, > -- > tcpm co-chairs > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --94eb2c0d22c2517e34055c4f1762 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 20, 2017 at 7:09 PM, Yoshifumi Nishida &l= t;nishida@sfc.w= ide.ad.jp> wrote:
Hello,
According to the agenda, we have a 2= .5 hours slot at Singapore. (9:30-12:00 11/16 Thursday)
If you pl= an to present something, please let the chairs know the following info.

* Title / draft name
Update of RACK draft-ietf-tcpm-rack-02
* Presenter's name
<= /div>
Yuchung Cheng=C2=A0=C2=A0
* Total time (including = Q/A)
20m

I will p= articipate and present remotely


=
Thanks,
--
tcpm co-chairs

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


--94eb2c0d22c2517e34055c4f1762-- From nobody Mon Oct 30 11:51:01 2017 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 75C8E13A1F4; Mon, 30 Oct 2017 11:50:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150938945944.7819.14642479423507366996@ietfa.amsl.com> Date: Mon, 30 Oct 2017 11:50:59 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-generalized-ecn-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 18:50:59 -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 WG of the IETF. Title : ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets Authors : Marcelo Bagnulo Bob Briscoe Filename : draft-ietf-tcpm-generalized-ecn-02.txt Pages : 37 Date : 2017-10-30 Abstract: This document describes an experimental modification to ECN when used with TCP. It allows the use of ECN on the following TCP packets: SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-02 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-generalized-ecn-02 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 Mon Oct 30 16:05:54 2017 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 36CC9C6F2; Mon, 30 Oct 2017 16:05:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940474518.28258.16124842117044342946@ietfa.amsl.com> Date: Mon, 30 Oct 2017 16:05:45 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-alternativebackoff-ecn-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:05:45 -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 WG of the IETF. Title : TCP Alternative Backoff with ECN (ABE) Authors : Naeem Khademi Michael Welzl Grenville Armitage Godred Fairhurst Filename : draft-ietf-tcpm-alternativebackoff-ecn-03.txt Pages : 12 Date : 2017-10-30 Abstract: Recent Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if they are only a few or their bandwidth- delay-product is large. An Explicit Congestion Notification (ECN) signal indicates that an AQM mechanism is used at the bottleneck, and therefore the bottleneck network queue is likely to be short. This document therefore proposes an update to the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-03 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-alternativebackoff-ecn-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-alternativebackoff-ecn-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 Mon Oct 30 16:56:59 2017 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 09856CE28; Mon, 30 Oct 2017 16:56:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940779800.28290.16909023366349102749@ietfa.amsl.com> Date: Mon, 30 Oct 2017 16:56:38 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:56:38 -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 WG of the IETF. Title : More Accurate ECN Feedback in TCP Authors : Bob Briscoe Mirja Kühlewind Richard Scheffenegger Filename : draft-ietf-tcpm-accurate-ecn-04.txt Pages : 43 Date : 2017-10-30 Abstract: Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate incipient congestion to the end-points. Receivers with an ECN- capable transport protocol feed back this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently, new TCP mechanisms like Congestion Exposure (ConEx) or Data Center TCP (DCTCP) need more accurate ECN feedback information whenever more than one marking is received in one RTT. This document specifies an experimental scheme to provide more than one feedback signal per RTT in the TCP header. Given TCP header space is scarce, it overloads the three existing ECN-related flags in the TCP header and provides additional information in a new TCP option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-04 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-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 Tue Oct 31 03:06:13 2017 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 7078D13F6D8 for ; Tue, 31 Oct 2017 03:06:08 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.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 EsmsvyaZ-_Yu for ; Tue, 31 Oct 2017 03:06:03 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 2DEA213B11B for ; Tue, 31 Oct 2017 03:06:03 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id a132so18275521lfa.7 for ; Tue, 31 Oct 2017 03:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=B2eKebLj8MORYA/VsEAEBDdpx1DU5f+gwpiPlJUT/1k=; b=haDMCZYsTfwhbIGzZcRNdAMAUkGMjXuIj0W6E9WvojnV+oyL6sVyJH9AKdj4BckG9h 3mmYDcQ2fp0YfyFgdIhnqqlKuVfpdDsN1590lsCHmm04SanG7Hw3LeZtIk8Bw7H8tGt/ ADAGMOeEk+Vm79jSHcLr2tKopBHI3Ebl5uJFPlmE3RObiwOXLx1DjzXbEj5cNSGpfOWK 23RoHpGq+XoxsD98cirKPQ8SSxOlxLOLe/hqKyrZRjI2chYOKQE+YLqOlfDi6HXJ+7ou M5wsi3xTtUsgr7rH3qydu5O3zcQ9NuKiNUkaKt4SdT/j3lTecrh2/utRVIzvI/3BJQnY D4oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=B2eKebLj8MORYA/VsEAEBDdpx1DU5f+gwpiPlJUT/1k=; b=DgDfjjkNNcrSBjfxb9pn9fDmTJ33SPYYdPGccDXagxc2FjG2V6PFC0IwdnMcWAfOmr tSqkV42DoeTsoARUs8As/wYntUqy0WeXydkXom1mQlGnvLWFGw1eRKeXxp6Zbfi24QXe LZIb9Vg4KhBsL1APHITDn6muWp10RQL2qM0tauU4HggtshUNRvqn4Y1c6tEYPZoQkB4d T87xND++JAKBQfsY6VVT0tLwumHzq5rfjglUt6y+Yi8L+VdNd7r638g3WNKIx27ZH2s6 Y+wf2TVaexcGHYY9MrGgx4tRXaBLFJNhSyrKlyKXGRI6hTF31BaYN6B6PeKzx50ty7BD L+Cw== X-Gm-Message-State: AMCzsaXu0bA1kjA2g77zB+aIGECbu1uzbCQd7i88AeVzus2DN64hBO8x 1MeaD7NwQZ0+mtXLtt3Srr6M1lbAbn3tPLDLY9Z0dKhOHub5bJPFBhINekYMJsfGzkc8LodLVqw k0tZvnH3G2+9xug== X-Google-Smtp-Source: ABhQp+R0MPlgwmwcvJQHX4qAFdzgnf656DqoBGOcQwctUOafcF6FObaZ9PtDiO6SddrnjqH08dJpArqxZpkUv5Akudo= X-Received: by 10.46.95.155 with SMTP id x27mr761871lje.184.1509444361016; Tue, 31 Oct 2017 03:06:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.24.160 with HTTP; Tue, 31 Oct 2017 03:05:59 -0700 (PDT) From: Anand Nandugudi Date: Tue, 31 Oct 2017 11:05:59 +0100 Message-ID: To: multipathtcp@ietf.org, tcpm@ietf.org Content-Type: multipart/alternative; boundary="001a114b52def2696b055cd4e6f5" Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-bonaventure-mptcp-converters-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 31 Oct 2017 10:06:08 -0000 --001a114b52def2696b055cd4e6f5 Content-Type: text/plain; charset="UTF-8" Name: draft-bonaventure-mptcp-converters Revision: 02 Title: 0-RTT TCP Converter Document date: 2017-10-30 Group: Individual Submission Pages: 32 URL: https://www.ietf.org/internet-drafts/draft-bonaventure- mptcp-converters-02.txt Status: https://datatracker.ietf.org/doc/draft-bonaventure-mptcp- converters/ Htmlized: https://tools.ietf.org/html/draft-bonaventure-mptcp- converters-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-bonaventure- mptcp-converters-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-bonaventure-mptcp- converters-02 Abstract: This document specifies an application proxy, called Transport Converter, to assist the deployment of Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network- assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. 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. The IETF Secretariat -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. --001a114b52def2696b055cd4e6f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Name:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0draft-bonaventure-mptcp-converters
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0-RTT TCP Converter
Document date:=C2=A0 2017-10-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 32
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-bon= aventure-mptcp-converters-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-bonaventure-mptcp-converters/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-bonaventure-mptcp-converters-0= 2
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-bonaventure-mptcp-converters-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-bonaventu= re-mptcp-converters-02

Abstract:
=C2=A0 =C2=A0This document specifies an application proxy, called Transport=
=C2=A0 =C2=A0Converter, to assist the deployment of Multipath TCP.=C2=A0 Th= is proxy is
=C2=A0 =C2=A0designed to avoid inducing extra delay when involved in a netw= ork-
=C2=A0 =C2=A0assisted connection (that is, 0-RTT).=C2=A0 This specification= assumes an
=C2=A0 =C2=A0explicit model, where the proxy is explicitly configured on ho= sts.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




DISCLAIMER.
This email and any files transmitted with it are confidential an= d intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the syste= m manager. This message contains confidential information and is intended o= nly for the individual named. If you are not the named addressee you should= not disseminate, distribute or copy this e-mail. Please notify the sender = immediately by e-mail if you have received this e-mail by mistake and delet= e this e-mail from your system. If you are not the intended recipient you a= re notified that disclosing, copying, distributing or taking any action in = reliance on the contents of this information is strictly prohibited.= --001a114b52def2696b055cd4e6f5--