From nobody Sat Apr 1 00:56: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 653B4124BFA; Sat, 1 Apr 2017 00:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 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.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 X-c9Ywmz7Jod; Sat, 1 Apr 2017 00:55:58 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00130.outbound.protection.outlook.com [40.107.0.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441E212025C; Sat, 1 Apr 2017 00:55:58 -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=+xlGxImlDrEn5fsskbf20WI+CHDYQ9nXLI+OgSRpYWw=; b=VpqgpDW1YHOEkjcPYUPYWEOEKIP62EZTfBpVjOB8BDvdGEgyjBjMK1dUyBRSE+ibjYRi17YGlP2P6oamJ7DF+bjZQEpr2dxMxhVu39Mv52f/sUFaxiivW5xDmWjXQDBGNYdZ3QT0Or3WyjOHkjhmPABzWThZIWstpKX41EU3SKk= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Sat, 1 Apr 2017 07:55:56 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1005.016; Sat, 1 Apr 2017 07:55:55 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "Scharf, Michael (Nokia - DE/Stuttgart)" , "Gengxuesong (Geng Xuesong)" , "Carles Gomez Montenegro" CC: "tcpm@ietf.org" , "draft-ietf-core-cocoa@ietf.org" Thread-Topic: [tcpm] RFC 793 (bis) vs. rto-consider Thread-Index: AdKowj/uHBlAvttmR5O5bK3orMhOogAXUEIAAAnLLSAAFUGNgAAMGoyAABgCz+AAI2PN8A== Date: Sat, 1 Apr 2017 07:55:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [46.183.103.17] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2547; 7:QiXuE9Uo84fB5r6Su+C3Cd43Xd/0lkg+sIKLBHIH+cVFTe4johKrF7ktQTNV4guFzEh/TjaEJ92VAgGqaxKtL/whSgpPgUcNaXMq2v61dx9Cnw+jZxBp6yVCHiuZ5FvpGo/CBvXuef0QMQ75cXxjPM7x75//Irr0luXRTS6KRc/J2zSSvx1OjpVTeqiRaIkdez0qu6zWppQhfnJDI74oe7XZZk0A9c8EpRUBiZZgyx4Q2aMVBUmXV2WfoNy9q9WW+hIhzO0Vnc6tgVczS/1MAhzYvtQ5tF+aNkIKl2ywiD1czWcG0DZlPlWdqktZbmXzfRXlAZdCD2AYlJJvBfLa0w== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39840400002)(39850400002)(39400400002)(39410400002)(2950100002)(93886004)(66066001)(74316002)(305945005)(7736002)(50986999)(76176999)(54356999)(5660300001)(122556002)(7696004)(189998001)(2900100001)(2906002)(53936002)(2171002)(4326008)(25786009)(38730400002)(229853002)(102836003)(3846002)(6116002)(86362001)(8676002)(81166006)(8936002)(77096006)(33656002)(3660700001)(99286003)(9686003)(55016002)(54906002)(3280700002)(6506006)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2547; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 814971bc-232a-44a0-22d4-08d478d486d4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2547; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:AM5PR0701MB2547; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2547; x-forefront-prvs: 0264FEA5C3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2017 07:55:55.3729 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2547 Archived-At: Subject: Re: [tcpm] RFC 793 (bis) vs. rto-consider 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, 01 Apr 2017 07:56:00 -0000 PiBUaGUgaXNzdWUgaXMgdGhhdCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBJLUQgcnRvLWNv bnNpZGVyIGFsbG93cyBhIGxvd2VyDQo+IGZyZXF1ZW5jeSBkdWUgdG8gdGhlIHVzZSBvZiB0aGUg U0hPVUxELiBBbmQgdGhpcyBpcyBkaWZmZXJlbnQgdG8gbXkgcmVhZGluZw0KPiBvZiBSRkMgNzkz IGFuZCB0aGUgc3RhbmRhcmRzLXRyYWNrIHNwZWNpZmljYXRpb24gb2YgVENQLCBpLmUuLCBpdCBp cyBub3QNCj4gY29uc2lzdGVudCB3aXRoIHRoZSBUQ1Agc3RhbmRhcmRzLg0KDQpJIHJlYWxpemUg dGhhdCBteSB3b3JkICJjb25zaXN0ZW50IiBtYXkgbm90IGJlIHBlcmZlY3QgaGVyZSwgYXMgYSBU Q1AgaW1wbGVtZW50YXRpb24gZm9sbG93aW5nIHRoZSBjdXJyZW50IHN0YW5kYXJkcy10cmFjayBU Q1AgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBzaG91bGQgaW5kZWVkIG1lZXQgdGhlIHJlcXVpcmVt ZW50cyBvZiBydG8tY29uc2lkZXIuIFNvIGEgVENQIGltcGxlbWVudGF0aW9uIHNlZW1zICJjb25z aXN0ZW50IiB3aXRoIHRoZSBndWlkYW5jZSBpbiBydG8tY29uc2lkZXIuIFRoZSBjdXJyZW50IFRD UCBzdGFuZGFyZHMganVzdCBoYXZlIGFkZGl0aW9uYWwgbm9ybWF0aXZlIHJlcXVpcmVtZW50cyBi ZXlvbmQgdGhlIHByb3RvY29sLWFnbm9zdGljIGd1aWRhbmNlIG9mIHJ0by1jb25zaWRlci4gQnV0 IGl0IGFjdHVhbGx5IGRvZXMgbm90IG1hdHRlciAgZm9yIHRoZSBydG8tY29uc2lkZXIgZG9jdW1l bnQgaWYgVENQIGRlZmluZXMgc3RyaWN0ZXIgcmVxdWlyZW1lbnRzIChlLmcuLCBhIE1VU1QgaW5z dGVhZCBvZiBhIFNIT1VMRCkuIE9ubHkgdGhlIG9wcG9zaXRlIHdvdWxkIGJlIGEgZm9ybWFsIGlz c3VlIGFzIGl0IHdvdWxkIGJlIGEgZG93bmdyYWRlLg0KDQpTb3JyeSBteSBmdXp6eSB3b3JkaW5n DQoNCk1pY2hhZWwNCg0K From nobody Mon Apr 3 06:51:00 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 81F73128BB6 for ; Mon, 3 Apr 2017 06:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09TSGx0wbL6I for ; Mon, 3 Apr 2017 06:50:58 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33729126CD8 for ; Mon, 3 Apr 2017 06:50:58 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id v33Dou3l006653; Mon, 3 Apr 2017 06:50:57 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D19E07402630; Mon, 3 Apr 2017 09:50:56 -0400 (EDT) To: jtl.ietf@gmail.com Cc: tcpm@ietf.org From: Mark Allman Reply-To: mallman@icir.org Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Piano Man X-URL-0: https://www.icir.org/mallman-files/Document81730.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 03 Apr 2017 09:50:56 -0400 Message-ID: <54222.1491227456@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: [tcpm] 64bit draft & PAWS 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, 03 Apr 2017 13:50:59 -0000 --=-------459435943823349593450 Content-Type: text/plain Hi Jonathan! I watched your presentation about 64bit sequence numbers at last week's meeting. And, I then read the draft. The first question I have comes from the intro. The intro calls out wrap rates given fast networks. Fine enough. But, nothing is ever said about PAWS. Maybe I am missing something obvious, but I expected the standard thing that protects against wrap to be at least mentioned. Why is PAWS not good enough here? Probably you have some good reason and it seems obvious and so you didn't think to write it down, but could you sketch the relationship here? Thanks! allman -- https://www.icir.org/mallman/ @mallman_icsi --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljiU0AACgkQWyrrWs4yIs7qkwCeJsFj24C41535lKs2xJ38aDod QqgAn0EmkhQGqUQSktfDsh2PXuxqN1lJ =dODi -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Apr 3 10:00:00 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 9A1E9128656 for ; Mon, 3 Apr 2017 09:59:58 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUhn9HFLqHGg for ; Mon, 3 Apr 2017 09:59:56 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04E8120046 for ; Mon, 3 Apr 2017 09:59:55 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id r69so146010423vke.2 for ; Mon, 03 Apr 2017 09:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FchvGOrvQ5VThbsSBXj86GFT0IBkUTzuEjt5zFVz0Q4=; b=rY9PZG9nCf063l66W1pXFbGo3KjXngoKRP21uqyALV1joE97Wd1bQY7k2YQssLPds5 0jCpx4t/KtBf4vSFPYfmL1ewjO2kUi23ZVrXAeOVsBPOHYAyItxBE2ep/9AXkPf5JQOL cexqm+mzpbAs2gPM46r46uMiSmYw7cdJqv6ipTiyKvncr1Vi/RE5mPHKunwWo42GPiiO EQfSdYhVzPq+wKOcguvj407ltZMX5AK0Fj+yd5Sl7yUbfrg4zFAntGoLf9O3kTw1eETZ 6A9NRrXq8hlYHOQ+XdMj7TU7qFjFvLJF7Z0qAnoQAxI+To7AZ4lGwbZkPVPkkjI0SwfW bDMQ== 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=FchvGOrvQ5VThbsSBXj86GFT0IBkUTzuEjt5zFVz0Q4=; b=IrX01ewjSa2hI71k0BPkKbFPam69Y5WxwW7C96KeAmI2PoLXqdKnmFZJ0IetUaVd4+ oPDEw/lNlq5bAPDns3FrIq03IuKNl07cJsr6DtErnoABKM1exllVGNCeHkOLEsZlW2v+ HMua712oQKBuCkE0E46WCf6uS0/U/Qr/4auyo62pLd/XeNPqjmHVDu0NoWuFrq9qNfQX 2x6k/MDid4aiyotxhPRK9x1NICCYXJ151IgNzduZIDPfCF+bPriPK3hln+TurfRWAN3L xmeJQq+B86o+999MZW0Az766SX5WBNWHNQwUbL7txm82C1skm8FBjvDJP0TqLIpC8YnD T8uw== X-Gm-Message-State: AFeK/H2Wu9xd+9ivl/Ei4/hG1feLPbvckCPoZI1m36ibCk0dUTjqtBfLuSUeuoynDC+o9FsZ35gTtptyze3djw== X-Received: by 10.159.38.12 with SMTP id 12mr6510540uag.136.1491238794733; Mon, 03 Apr 2017 09:59:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.5.196 with HTTP; Mon, 3 Apr 2017 09:59:54 -0700 (PDT) In-Reply-To: <54222.1491227456@lawyers.icir.org> References: <54222.1491227456@lawyers.icir.org> From: Jonathan Looney Date: Mon, 3 Apr 2017 12:59:54 -0400 Message-ID: To: mallman@icir.org Cc: tcpm@ietf.org Content-Type: multipart/alternative; boundary=001a113e2654a2ac47054c4616d0 Archived-At: Subject: Re: [tcpm] 64bit draft & PAWS 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, 03 Apr 2017 16:59:59 -0000 --001a113e2654a2ac47054c4616d0 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 9:50 AM, Mark Allman wrote: > > Hi Jonathan! > > I watched your presentation about 64bit sequence numbers at last > week's meeting. And, I then read the draft. > > The first question I have comes from the intro. The intro calls out > wrap rates given fast networks. Fine enough. But, nothing is ever > said about PAWS. Maybe I am missing something obvious, but I > expected the standard thing that protects against wrap to be at > least mentioned. Why is PAWS not good enough here? Probably you > have some good reason and it seems obvious and so you didn't think > to write it down, but could you sketch the relationship here? > Hi Mark, Thanks for your question! The impetus for this was the combination of two proposals at Seoul: 1. Allowing window sizes up to 2 ** 31. 2. Allowing timestamps up to nanosecond granularity. I think the individuals making these presentations had good reasons for their proposals; however, I think the combination makes PAWS considerably more fragile than it is today. Also, importantly, if people already need 2 ** 31 window sizes for high-bandwidth transfers, it seems like it may be only a matter of time before people need even larger window sizes. Jonathan --001a113e2654a2ac47054c4616d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 3, 2017 at 9:50 AM, Mark Allman <mallman@icir.org> wr= ote:

Hi Jonathan!

I watched your presentation about 64bit sequence numbers at last
week's meeting.=C2=A0 And, I then read the draft.

The first question I have comes from the intro.=C2=A0 The intro calls out wrap rates given fast networks.=C2=A0 Fine enough.=C2=A0 But, nothing is ev= er
said about PAWS.=C2=A0 Maybe I am missing something obvious, but I
expected the standard thing that protects against wrap to be at
least mentioned.=C2=A0 Why is PAWS not good enough here?=C2=A0 Probably you=
have some good reason and it seems obvious and so you didn't think
to write it down, but could you sketch the relationship here?


Hi Mark,

Tha= nks for your question!

The impetus for this was th= e combination of two proposals at Seoul:
1. Allowing window sizes= up to 2 ** 31.
2. Allowing timestamps up to nanosecond granulari= ty.

I think the individuals making these presentat= ions had good reasons for their proposals; however, I think the combination= makes PAWS considerably more fragile than it is today.

Also, importantly, if people already need 2 ** 31 window sizes for hi= gh-bandwidth transfers, it seems like it may be only a matter of time befor= e people need even larger window sizes.

Jonathan
--001a113e2654a2ac47054c4616d0-- From nobody Mon Apr 3 13:36: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 3EB5F129443 for ; Mon, 3 Apr 2017 13:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 wZGljtZXYyqL for ; Mon, 3 Apr 2017 13:36:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D61B128C83 for ; Mon, 3 Apr 2017 13:36:40 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v33Ka1LQ024273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 3 Apr 2017 13:36:02 -0700 (PDT) To: mallman@icir.org, jtl.ietf@gmail.com References: <54222.1491227456@lawyers.icir.org> Cc: tcpm@ietf.org From: Joe Touch Message-ID: <40f0b8a8-b2cb-f785-e8e2-dce604bbbd00@isi.edu> Date: Mon, 3 Apr 2017 13:36:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <54222.1491227456@lawyers.icir.org> Content-Type: multipart/alternative; boundary="------------0EAA10E2D4D1F30E9E03E3EE" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] 64bit draft & PAWS 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, 03 Apr 2017 20:36:42 -0000 This is a multi-part message in MIME format. --------------0EAA10E2D4D1F30E9E03E3EE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi, Mark, Not sure if it matters, but PAWS is about stale data corrupting new data. 64bit windows is about allowing a much larger amount of outstanding data (in the pipe) - all of which is valid. AFAICT. Then again, I do wonder about the impact on the ISN if a machine goes back and forth between using 64-bit and not. (e.g., as might happen in a server pool during an upgrade). Joe On 4/3/2017 6:50 AM, Mark Allman wrote: > Hi Jonathan! > > I watched your presentation about 64bit sequence numbers at last > week's meeting. And, I then read the draft. > > The first question I have comes from the intro. The intro calls out > wrap rates given fast networks. Fine enough. But, nothing is ever > said about PAWS. Maybe I am missing something obvious, but I > expected the standard thing that protects against wrap to be at > least mentioned. Why is PAWS not good enough here? Probably you > have some good reason and it seems obvious and so you didn't think > to write it down, but could you sketch the relationship here? > > Thanks! > > allman > > > -- > https://www.icir.org/mallman/ > @mallman_icsi > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------0EAA10E2D4D1F30E9E03E3EE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Hi, Mark,

Not sure if it matters, but PAWS is about stale data corrupting new data.

64bit windows is about allowing a much larger amount of outstanding data (in the pipe) - all of which is valid.

AFAICT.

Then again, I do wonder about the impact on the ISN if a machine goes back and forth between using 64-bit and not. (e.g., as might happen in a server pool during an upgrade).

Joe


On 4/3/2017 6:50 AM, Mark Allman wrote:
Hi Jonathan!

I watched your presentation about 64bit sequence numbers at last
week's meeting.  And, I then read the draft.

The first question I have comes from the intro.  The intro calls out
wrap rates given fast networks.  Fine enough.  But, nothing is ever
said about PAWS.  Maybe I am missing something obvious, but I
expected the standard thing that protects against wrap to be at
least mentioned.  Why is PAWS not good enough here?  Probably you
have some good reason and it seems obvious and so you didn't think
to write it down, but could you sketch the relationship here?

Thanks!

allman


--
https://www.icir.org/mallman/
@mallman_icsi






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

--------------0EAA10E2D4D1F30E9E03E3EE-- From nobody Mon Apr 3 13:42:40 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 9472E1294FB for ; Mon, 3 Apr 2017 13:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jcV54iGiQ2C for ; Mon, 3 Apr 2017 13:42:37 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76D1128C83 for ; Mon, 3 Apr 2017 13:42:34 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id v33KgXMk005630; Mon, 3 Apr 2017 13:42:33 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2035F7430965; Mon, 3 Apr 2017 16:42:33 -0400 (EDT) To: Joe Touch From: Mark Allman Reply-To: mallman@icir.org cc: jtl.ietf@gmail.com, tcpm@ietf.org In-Reply-To: <40f0b8a8-b2cb-f785-e8e2-dce604bbbd00@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Piano Man X-URL-0: https://www.icir.org/mallman-files/Document98702.jpg X-URL-1: https://www.icir.org/mallman-files/Document35542.doc X-URL-2: https://www.icir.org/mallman-files/Document40429.docx X-URL-3: https://www.icir.org/mallman-files/Document2050.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 03 Apr 2017 16:42:33 -0400 Message-ID: <38975.1491252153@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: Re: [tcpm] 64bit draft & PAWS 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, 03 Apr 2017 20:42:39 -0000 --=-------459435943823349593450 Content-Type: text/plain > Not sure if it matters, but PAWS is about stale data corrupting new > data. Yes. > 64bit windows is about allowing a much larger amount of outstanding > data (in the pipe) - all of which is valid. Just to be clear, the draft proposes 64 bit SEQUENCE NUMBERS (not windows). Bigger sequence numbers then then allows for the window scale to increase---to 46, if I recall correctly---but, I was reacting to the words about quick sequence wrap in the intro (which is in fact what PAWS aims to help). So, yes, they're related, but not the same. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljis7YACgkQWyrrWs4yIs7CpQCeOjYw3wBwsbRIKFFCm1nvS28n +oMAn289XNVedy7iQ3XpMY3NPumTH+wx =X374 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Apr 3 13:50: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 818D2129415 for ; Mon, 3 Apr 2017 13:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 oKZMExw02Rai for ; Mon, 3 Apr 2017 13:50:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C69128C83 for ; Mon, 3 Apr 2017 13:50:39 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v33KoSAa027248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 3 Apr 2017 13:50:28 -0700 (PDT) To: mallman@icir.org References: <38975.1491252153@lawyers.icir.org> Cc: jtl.ietf@gmail.com, tcpm@ietf.org From: Joe Touch Message-ID: Date: Mon, 3 Apr 2017 13:50:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <38975.1491252153@lawyers.icir.org> Content-Type: multipart/alternative; boundary="------------206FC864C7FD12A68E2C3466" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] 64bit draft & PAWS 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, 03 Apr 2017 20:50:41 -0000 This is a multi-part message in MIME format. --------------206FC864C7FD12A68E2C3466 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 4/3/2017 1:42 PM, Mark Allman wrote: >> 64bit windows is about allowing a much larger amount of outstanding >> data (in the pipe) - all of which is valid. > Just to be clear, the draft proposes 64 bit SEQUENCE NUMBERS (not > windows). > > Bigger sequence numbers then then allows for the window scale to > increase---to 46, if I recall correctly Right - there were two rationales presented in the intro: 1) (and the primary one, AFAICT) While sequence number wrapping is a basic feature of TCP, the specified wrapping mechanism only supports having a theoretical maximum of 2**31 bytes outstanding at any given time. 2) (and somewhat secondary, as "Additionally" suggests): Additionally, when you are re-using sequence number space in such a short timeframe, it is unclear that the existing mechanisms for detecting duplicate packets will be sufficient > ---but, I was reacting to the > words about quick sequence wrap in the intro (which is in fact what > PAWS aims to help). I agree you might argue that PAWS may undermine the second benefit, but not the first... Joe --------------206FC864C7FD12A68E2C3466 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 4/3/2017 1:42 PM, Mark Allman wrote:
64bit windows is about allowing a much larger amount of outstanding
data (in the pipe) - all of which is valid.

Just to be clear, the draft proposes 64 bit SEQUENCE NUMBERS (not
windows).

Bigger sequence numbers then then allows for the window scale to
increase---to 46, if I recall correctly

Right -  there were two rationales presented in the intro:

1) (and the primary one, AFAICT) 
   While sequence number wrapping is a basic feature of
   TCP, the specified wrapping mechanism only supports having a
   theoretical maximum of 2**31 bytes outstanding at any given time.
2) (and somewhat secondary, as "Additionally" suggests):

   Additionally, when you are re-using sequence number space in such a
   short timeframe, it is unclear that the existing mechanisms for
   detecting duplicate packets will be sufficient

---but, I was reacting to the
words about quick sequence wrap in the intro (which is in fact what
PAWS aims to help).

I agree you might argue that PAWS may undermine the second benefit, but not the first...

Joe

--------------206FC864C7FD12A68E2C3466-- From nobody Thu Apr 6 17:45:52 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 7E2A21296C8 for ; Thu, 6 Apr 2017 17:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 tH36Bj3Yv2qA for ; Thu, 6 Apr 2017 17:45:42 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::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 5B23F126FB3 for ; Thu, 6 Apr 2017 17:45:42 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id x125so50367002pgb.0 for ; Thu, 06 Apr 2017 17:45:42 -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=ChBC9M1/hkYtNwk3RGl7PXtUmMbN3O2gXQUoqePtd8E=; b=Sh1vLdDbdsz2KTrMZwEzCcoZubGJhU2+T4/JHcjBZBnmsasQTBEs1jU9lcXDlOnoy7 rIvqFrRnHfW3GrDQEeCtuBiF9QEYjdwY4nF70RImQfVqpHPp5c2Z/gtF7dKJRkh38SG9 iUnT/8kT+DOifiWvu3ZxGDp26lAGXvsrCCbFr6qrqSqZDSD0sODvyGH2iyR+gWqD8cuB NMoo+14PkIiWhABHwendJi44CP7yrwaJZNLE+Qk9CpGRvJOhWd59EeichcgRRUDZwzzf TMu+AnO1EyiVCyoDM1hGV7aVfpO0seofSOhhDvXCRhGVgTZa3mmQlaiGD9eRfH7IGbWD R9wQ== 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=ChBC9M1/hkYtNwk3RGl7PXtUmMbN3O2gXQUoqePtd8E=; b=uTNv2AKRBZXO1MImviAn40YCzmZuI0G40E+FSckziJdObs6baeA6aAgDPIjtJMcsyM 1/08iEmV6ybmjadQBKNA6mvuntXL/ZAMazqZQljVluhxsPJp081XtWvzxR3jg2aoB24D Ar+E19qCKUYqWy5XOvlmCT3en0PITEB/AHM+DEMVJmqoNpkxqnUNaxQrByR62234xaHz UBtcDwPm8pEeRLFy0tEH0heVOV9E30wxIn1afHVl0ONDPbLJGyDzv5DcYpsQO1MuEY3K QZZXNP0K9NFFSKP+sW0GjyRV4ftNxM+QDRdTxz5kaSyFjxv9Hy9tFN5xH/w5WU+3svT2 gbPQ== X-Gm-Message-State: AFeK/H1e0BocjvAc0rrXWY1ggAPaXhy+cucTfbkgx6dNKHoAWrfJlPRGSl4woilXLZTunP15hHNNLVYsQG2tBvsr X-Received: by 10.99.185.1 with SMTP id z1mr38880335pge.165.1491525941577; Thu, 06 Apr 2017 17:45:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.164.209 with HTTP; Thu, 6 Apr 2017 17:45:40 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Thu, 6 Apr 2017 17:45:40 -0700 Message-ID: To: Ingemar Johansson S Cc: Yuchung Cheng , Michael Welzl , "tcpm@ietf.org Extensions" , tsvwg IETF list , Ian Swett Content-Type: multipart/alternative; boundary=94eb2c078a88ec29ff054c88f172 Archived-At: Subject: Re: [tcpm] [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) 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, 07 Apr 2017 00:45:46 -0000 --94eb2c078a88ec29ff054c88f172 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the presentation Ingemar; unfortunately I missed this at the IETF. As one of the authors of RFC 5690, I'm familiar with the pitfalls of doing ack CC, but I think we may be able to get around them in QUIC since there's explicit ack information in QUIC. We are experimenting with this in QUIC, and we'll be happy to bring data when we have some. On Fri, Mar 31, 2017 at 10:35 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Thanks for the details. It may be the case that it can be tricky to get a > decent understanding of what is possible in terms of ACK rate reduction f= or > TCP. The middlebox behavior to discard everything except the last ACK has > also been proposed in the RAN2 WG in 3GPP. > > > > /Ingemar > > > > *From:* Yuchung Cheng [mailto:ycheng@google.com] > *Sent:* den 31 mars 2017 00:17 > *To:* Michael Welzl > *Cc:* Ingemar Johansson S ; tsvwg IETF > list ; tcpm@ietf.org Extensions > *Subject:* Re: [tsvwg] TCP ACK-CC (re: Transport protocol feedback > overhead ) > > > > regarding the question in the slide 5. > > "Is immediate ACK needed for out of order segments if RACK is used ?" > > > > The answer is both yes and no: a timely feedback is appreciated (yes). Bu= t > RACK does not need 100 DUPACKs each telling one more packet is delivered > out of order (no). In other words if the ACK is timely and precise about > the delivery process, RACK would work well (so does BBR). However this ca= n > go terribly wrong if the middle-box sends only the last ACK/SACK. It has > happened in one major cloud platform. > > > > On Thu, Mar 30, 2017 at 2:14 PM, Michael Welzl wrote= : > > Hi, > > > > Thanks Ingemar for your interesting presentation today: > > https://www.ietf.org/proceedings/98/slides/slides- > 98-tsvwg-sessb-7-transport-protocol-feedback-overhead- > issues-and-solutions-00.pdf > > > > I wanted to share with you, and the list, that David Ros (one of the > original authors of ACK-CC, RFC 5690) and I once advised a master student > to: > > - implement ACK-CC > > - test it > > - analyze all RFC 2119 - style keywords in RFC 5690, to see how they > should be changed (if at all) in a possible update > > > > Back then, our thinking was that we could write a paper about it, and try > to get this deployed as a way of doing the Experiment and moving this to = PS > status. > > However, we were less and less sure about the real value of this - whethe= r > actual networks need this? Then, we had less and less time available and = at > some point dropped the ball. > > I of course found it interesting to hear that it *is* a real problem, eve= n > today. > > > > Anyway: this master thesis is available here: http://heim.ifi.uio.no/ > michawe/teaching/dipls/marius-olsen/mastersthesis-mariusno.pdf > > and I think I can safely say on behalf of David, Marius (the master > student who did this) and myself that we=E2=80=99re happy if someone pick= s this up > and continues the work. > > It would require some digging, but I might also still have the code lying > around somewhere - for some outdated version of Linux=E2=80=A6 > > > > Cheers, > > Michael > > > > > --94eb2c078a88ec29ff054c88f172 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the presentation Ingemar; unfortunately I misse= d this at the IETF. As one of the authors of RFC 5690, I'm familiar wit= h the pitfalls of doing ack CC, but I think we may be able to get around th= em in QUIC since there's explicit ack information in QUIC. We are exper= imenting with this in QUIC, and we'll be happy to bring data when we ha= ve some.

On = Fri, Mar 31, 2017 at 10:35 AM, Ingemar Johansson S <ingemar= .s.johansson@ericsson.com> wrote:

Thanks for the details. It may be the case that it = can be tricky to get a decent understanding of what is possible in terms of= ACK rate reduction for TCP. The middlebox behavior to discard everything except the last ACK has also been proposed in the RA= N2 WG in 3GPP.

=C2=A0

/Ingemar

=C2=A0

From: Yuchung Cheng [mailto:ycheng@google.com]
Sent: den 31 mars 2017 00:17
To: Michael Welzl <michawe@ifi.uio.no>
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>= ; tsvwg IETF list <t= svwg@ietf.org>; t= cpm@ietf.org Extensions <tcpm@ietf.org>
Subject: Re: [tsvwg] TCP ACK-CC (re: Transport protocol feedback ove= rhead )

=C2=A0

regarding the question in the slide 5.=

"Is immediate ACK needed for out of order segme= nts if RACK is used ?"

=C2=A0

The answer is both yes and no: a timely feedback is = appreciated (yes). But RACK does not need 100 DUPACKs each telling one more= packet is delivered out of order (no). In other words if the ACK is timely= and precise about the delivery process, RACK would work well (so does BBR). However this can go terribly wrong if = the middle-box sends only the last ACK/SACK. It has happened in one major c= loud platform.

=C2=A0

On Thu, Mar 30, 2017 at 2:14 PM, Michael Welzl <<= a href=3D"mailto:michawe@ifi.uio.no" target=3D"_blank">michawe@ifi.uio.no> wrote:

Hi,

=C2=A0

Thanks Ingemar for your interesting presentation tod= ay:

=C2=A0

I wanted to share with you, and the list, that David= Ros =C2=A0(one of the original authors of ACK-CC, RFC 5690) and I once adv= ised a master student to:

- implement ACK-CC

- test it

- analyze all RFC 2119 - style keywords in RFC 5690,= to see how they should be changed (if at all) in a possible update<= u>

=C2=A0

Back then, our thinking was that we could write a pa= per about it, and try to get this deployed as a way of doing the Experiment= and moving this to PS status.

However, we were less and less sure about the real v= alue of this - whether actual networks need this? Then, we had less and les= s time available and at some point dropped the ball.

I of course found it interesting to hear that it *is= * a real problem, even today.

=C2=A0

and I think I can safely say on behalf of David, Mar= ius (the master student who did this) and myself that we=E2=80=99re happy i= f someone picks this up and continues the work.

It would require some digging, but I might also stil= l have the code lying around somewhere - for some outdated version of Linux= =E2=80=A6

=C2=A0

Cheers,

Michael

=C2=A0

=C2=A0


--94eb2c078a88ec29ff054c88f172-- From nobody Thu Apr 6 23:43: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 95AC71201F2; Thu, 6 Apr 2017 23:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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_MED=-2.3, 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=ericsson.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 3xjKMqGcrFlj; Thu, 6 Apr 2017 23:43:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 2A0371293F5; Thu, 6 Apr 2017 23:43:27 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-18-58e7350db4e1 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id FB.F1.21650.D0537E85; Fri, 7 Apr 2017 08:43:25 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 7 Apr 2017 08:43:22 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cx9EDX0LyFwn5eqK+2lZbpYcwfK2nsdExKJRYGPoObA=; b=gVrS9vpI6Uvf++383E+Zk0WjLhPmF5I4d0EIHFhyM+5+7FwR8Lz2caJeyg5j6qoEqgx/wk5kub4grJayalhPJ4A97dK0/b8SYgXeG6Bq1/4B+6fIOpoANB/Acg4De6Y/oAC0Xca4Y8SdBGF7sPad3+6I1TDsPuJgoq0AptKPmPs= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Fri, 7 Apr 2017 06:43:21 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::8cab:8aee:920b:657d]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::8cab:8aee:920b:657d%16]) with mapi id 15.01.1034.005; Fri, 7 Apr 2017 06:43:21 +0000 From: Ingemar Johansson S To: Jana Iyengar CC: Yuchung Cheng , Michael Welzl , "tcpm@ietf.org Extensions" , tsvwg IETF list , Ian Swett , Ingemar Johansson S Thread-Topic: [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) Thread-Index: AQHSqZq/4RHrIyBgtUCygnpI+u3trKGt82KAgAFBFtCACejhAIAAYUeQ Date: Fri, 7 Apr 2017 06:43:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.82] x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 7:FB9Q95uCgEwkhGD8vnmFh50VM+/kWwwywraM0L3dbaioSNsTz7CbLFDJpjKSbydltNqWD2TZ++8NT7fi9KKid5EOwLzxFwzNNYmU+XjXzZH7OH05TmuDbTt227ORg0rnpHDPD6gyL9nI167G4Ph9aHdw/leSiCQ7Cx+H8k5RcIXY467hkpSV1rGsruzJOAejaeNjlXTsbqXPXkJi85wv0h0tP+riFHvZdGTYnn0t0FSbfDABUlZuK7ulAUYLmNWv96BjXDUB8PzREnX0PA/VIkKWw6ckVQCx8ZZO2CmbW2GmnWbPdimIAXlwEU4paoNPFR9/2bxWfiCNIvEbt++uBg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(39410400002)(39400400002)(39850400002)(39840400002)(377454003)(24454002)(7696004)(93886004)(3280700002)(50986999)(54356999)(76176999)(74316002)(3660700001)(25786009)(5660300001)(53546009)(8676002)(2900100001)(5250100002)(9326002)(6116002)(3846002)(81166006)(102836003)(8936002)(7906003)(6916009)(2950100002)(790700001)(107886003)(54896002)(9686003)(6306002)(38730400002)(236005)(229853002)(99286003)(19609705001)(6246003)(55016002)(6506006)(606005)(966004)(189998001)(7736002)(6436002)(2906002)(4326008)(33656002)(66066001)(53936002)(110136004)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: f7d9a739-10cc-4147-7528-08d47d8161ed x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB346; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB346; x-forefront-prvs: 0270ED2845 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3480CBD915CC92D63747315C20C0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2017 06:43:21.1881 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfSzUcRzH+/6e7ne3zr4O89nRxmlDm2fqMhr/NOthk63NtMUtv7g87n4o bZaUrSiMEMtDwyos8xy5Ww6VP4qFpFA4TyllI9Sy7u6nzX+vz/vz/r6/n893X5aU9dFyVp2Y wmkSVfEKRkKVhXcedpP6LYZ7Dkw4Kbenu2hl4cBDSrn1xkgdg1WE8uW3KUa5PjfGBDEh1S2p IbW120RIQ8MMGUpGSAKiuXh1GqfxOBYlib2+3MMkd+vQlZ+3tEwmautCOUjMAvaFhdElMgdJ WBluQtDf+B0JxSsEpYZqxlRQ+C4JzbqRXVsxAUO/80RC8QVBXWWNOYzBAfBEv2lma+wI89sb ZhOJfyH4u66jTA0rfBK0H1YpwXQK2lpqjMwa+Tisl8pNMoUPwsZwndkixRFQ8XZi97JRAnQN N2mTX4zPQFneRZMH4QPweXPa7CexLXw0VBHCchhqe4ZIgW1geW6HNuUgnI9gZOUTYcoB7AB9 X6UmHXAuCcuP5mnhwDQNqzkJAp+G1vr7lMAZMJs7JxJYDQWblbv6OVhc7SOFoCECmuq6dxv2 0PPuPSksL4ep0dtIYHtYmtTSBcilfM/gAifBZNcYU25+AEsYLDNQ5cZZSewKTd0egsUR7uXO iAR2gewHFaK9ejUS1SMbnuP5hBhvb3dOo77A80mJ7olcSgsyfq3etj/+z1DvYrAeYRYp9kuj tgzhMlqVxqcn6BGwpMJa6vzDKEmjVelXOU1SpCY1nuP1yI6lFLbSIN1wuAzHqFK4OI5L5jT/ uwQrlmeirEiLjhPr3iVr7PZkZ12Ra6fvplS7Mo4Ci+1kW553Asqrzuv9Xmz0Jjn5+MPRsP7Q OcuIdu2STaOS9vJcDHSWPZflFwWvzluMN+/ofCrJ9izD2uOF4Ev7MsQOZElr3pHC8TjirNVy Wsc1h2xldFrPZQfRxGzlDbfXJWJ5xtMwBcXHqrwOkRpe9Q9MOf5HVgMAAA== Archived-At: Subject: Re: [tcpm] [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) 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, 07 Apr 2017 06:43:31 -0000 --_000_DB4PR07MB3480CBD915CC92D63747315C20C0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNClRoYW5rcywgbG9va2luZyBmb3J3YXJkIHRvIHNlZSB0aGUgcmVzdWx0cyBvZiB5b3VyIGV4 cGVyaW1lbnRzLg0KSW1wb3J0YW50IHRvIHVuZGVyc3RhbmQgaXMgdGhhdCB0aGUgZ29hbCBpcyBu b3Qg4oCccmVkdWNlZCBBQ0sgcmF0ZSBhdCBhbnkgY29zdOKAnS4gQ2VydGFpbiBhcnJhbmdlbWVu dHMgd2lsbCBuZWVkIGEgaGlnaGVyIEFDSyByYXRlIHRoYW4gb3RoZXJzIGZvciBpbnN0YW5jZSBk ZXBlbmRpbmcgb24gY29uZ2VzdGlvbiBjb250cm9sIHNwZWNpZmljcy4NCg0KQnV0IGhvcGVmdWxs eSB0aGUgQUNLIHJhdGUgd2lsbCBkZWNyZWFzZSBpbiBhIHN0YXRpc3RpY2FsIHNlbnNlIGFuZCB0 aGF0IGlzIGdvb2QsIGZ1cnRoZXJtb3JlIHdvcmsgb24gdGhpcyB3aWxsIChwb3NzaWJseSBpbiBh biBpZGVhbCB3b3JsZCkgc2VuZCBhIHNpZ25hbCB0aGF0IHRoZSBBQ0tzIHRoYXQgdHJhdmVyc2Ug dGhlIG5ldHdvcmsgYXJlIG5lZWRlZCBmb3Igb25lIHJlYXNvbiBvciB0aGUgb3RoZXIgYW5kIHRo YXQgbWlkZGxlYm94ZXMgc2hvdWxkIG5vdCB0cnkgdG8gdGFtcGVyIHdpdGggIHRoZXNlIEFDS3Mg LCBjYWxsIG1lIGEgZHJlYW1lcuKApg0KDQovSW5nZW1hcg0KDQpGcm9tOiBKYW5hIEl5ZW5nYXIg W21haWx0bzpqcmlAZ29vZ2xlLmNvbV0NClNlbnQ6IGRlbiA3IGFwcmlsIDIwMTcgMDI6NDYNClRv OiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4N CkNjOiBZdWNodW5nIENoZW5nIDx5Y2hlbmdAZ29vZ2xlLmNvbT47IE1pY2hhZWwgV2VsemwgPG1p Y2hhd2VAaWZpLnVpby5ubz47IHRjcG1AaWV0Zi5vcmcgRXh0ZW5zaW9ucyA8dGNwbUBpZXRmLm9y Zz47IHRzdndnIElFVEYgbGlzdCA8dHN2d2dAaWV0Zi5vcmc+OyBJYW4gU3dldHQgPGlhbnN3ZXR0 QGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBUQ1AgQUNLLUNDIChyZTogVHJhbnNw b3J0IHByb3RvY29sIGZlZWRiYWNrIG92ZXJoZWFkICkNCg0KVGhhbmtzIGZvciB0aGUgcHJlc2Vu dGF0aW9uIEluZ2VtYXI7IHVuZm9ydHVuYXRlbHkgSSBtaXNzZWQgdGhpcyBhdCB0aGUgSUVURi4g QXMgb25lIG9mIHRoZSBhdXRob3JzIG9mIFJGQyA1NjkwLCBJJ20gZmFtaWxpYXIgd2l0aCB0aGUg cGl0ZmFsbHMgb2YgZG9pbmcgYWNrIENDLCBidXQgSSB0aGluayB3ZSBtYXkgYmUgYWJsZSB0byBn ZXQgYXJvdW5kIHRoZW0gaW4gUVVJQyBzaW5jZSB0aGVyZSdzIGV4cGxpY2l0IGFjayBpbmZvcm1h dGlvbiBpbiBRVUlDLiBXZSBhcmUgZXhwZXJpbWVudGluZyB3aXRoIHRoaXMgaW4gUVVJQywgYW5k IHdlJ2xsIGJlIGhhcHB5IHRvIGJyaW5nIGRhdGEgd2hlbiB3ZSBoYXZlIHNvbWUuDQoNCk9uIEZy aSwgTWFyIDMxLCAyMDE3IGF0IDEwOjM1IEFNLCBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTxtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20+PiB3cm90ZToNClRoYW5rcyBmb3IgdGhlIGRldGFpbHMuIEl0IG1heSBiZSB0aGUg Y2FzZSB0aGF0IGl0IGNhbiBiZSB0cmlja3kgdG8gZ2V0IGEgZGVjZW50IHVuZGVyc3RhbmRpbmcg b2Ygd2hhdCBpcyBwb3NzaWJsZSBpbiB0ZXJtcyBvZiBBQ0sgcmF0ZSByZWR1Y3Rpb24gZm9yIFRD UC4gVGhlIG1pZGRsZWJveCBiZWhhdmlvciB0byBkaXNjYXJkIGV2ZXJ5dGhpbmcgZXhjZXB0IHRo ZSBsYXN0IEFDSyBoYXMgYWxzbyBiZWVuIHByb3Bvc2VkIGluIHRoZSBSQU4yIFdHIGluIDNHUFAu DQoNCi9JbmdlbWFyDQoNCkZyb206IFl1Y2h1bmcgQ2hlbmcgW21haWx0bzp5Y2hlbmdAZ29vZ2xl LmNvbTxtYWlsdG86eWNoZW5nQGdvb2dsZS5jb20+XQ0KU2VudDogZGVuIDMxIG1hcnMgMjAxNyAw MDoxNw0KVG86IE1pY2hhZWwgV2VsemwgPG1pY2hhd2VAaWZpLnVpby5ubzxtYWlsdG86bWljaGF3 ZUBpZmkudWlvLm5vPj4NCkNjOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5z c29uQGVyaWNzc29uLmNvbTxtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+ PjsgdHN2d2cgSUVURiBsaXN0IDx0c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+ PjsgdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4gRXh0ZW5zaW9ucyA8dGNwbUBp ZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBUQ1Ag QUNLLUNDIChyZTogVHJhbnNwb3J0IHByb3RvY29sIGZlZWRiYWNrIG92ZXJoZWFkICkNCg0KcmVn YXJkaW5nIHRoZSBxdWVzdGlvbiBpbiB0aGUgc2xpZGUgNS4NCiJJcyBpbW1lZGlhdGUgQUNLIG5l ZWRlZCBmb3Igb3V0IG9mIG9yZGVyIHNlZ21lbnRzIGlmIFJBQ0sgaXMgdXNlZCA/Ig0KDQpUaGUg YW5zd2VyIGlzIGJvdGggeWVzIGFuZCBubzogYSB0aW1lbHkgZmVlZGJhY2sgaXMgYXBwcmVjaWF0 ZWQgKHllcykuIEJ1dCBSQUNLIGRvZXMgbm90IG5lZWQgMTAwIERVUEFDS3MgZWFjaCB0ZWxsaW5n IG9uZSBtb3JlIHBhY2tldCBpcyBkZWxpdmVyZWQgb3V0IG9mIG9yZGVyIChubykuIEluIG90aGVy IHdvcmRzIGlmIHRoZSBBQ0sgaXMgdGltZWx5IGFuZCBwcmVjaXNlIGFib3V0IHRoZSBkZWxpdmVy eSBwcm9jZXNzLCBSQUNLIHdvdWxkIHdvcmsgd2VsbCAoc28gZG9lcyBCQlIpLiBIb3dldmVyIHRo aXMgY2FuIGdvIHRlcnJpYmx5IHdyb25nIGlmIHRoZSBtaWRkbGUtYm94IHNlbmRzIG9ubHkgdGhl IGxhc3QgQUNLL1NBQ0suIEl0IGhhcyBoYXBwZW5lZCBpbiBvbmUgbWFqb3IgY2xvdWQgcGxhdGZv cm0uDQoNCk9uIFRodSwgTWFyIDMwLCAyMDE3IGF0IDI6MTQgUE0sIE1pY2hhZWwgV2VsemwgPG1p Y2hhd2VAaWZpLnVpby5ubzxtYWlsdG86bWljaGF3ZUBpZmkudWlvLm5vPj4gd3JvdGU6DQpIaSwN Cg0KVGhhbmtzIEluZ2VtYXIgZm9yIHlvdXIgaW50ZXJlc3RpbmcgcHJlc2VudGF0aW9uIHRvZGF5 Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC10 c3Z3Zy1zZXNzYi03LXRyYW5zcG9ydC1wcm90b2NvbC1mZWVkYmFjay1vdmVyaGVhZC1pc3N1ZXMt YW5kLXNvbHV0aW9ucy0wMC5wZGYNCg0KSSB3YW50ZWQgdG8gc2hhcmUgd2l0aCB5b3UsIGFuZCB0 aGUgbGlzdCwgdGhhdCBEYXZpZCBSb3MgIChvbmUgb2YgdGhlIG9yaWdpbmFsIGF1dGhvcnMgb2Yg QUNLLUNDLCBSRkMgNTY5MCkgYW5kIEkgb25jZSBhZHZpc2VkIGEgbWFzdGVyIHN0dWRlbnQgdG86 DQotIGltcGxlbWVudCBBQ0stQ0MNCi0gdGVzdCBpdA0KLSBhbmFseXplIGFsbCBSRkMgMjExOSAt IHN0eWxlIGtleXdvcmRzIGluIFJGQyA1NjkwLCB0byBzZWUgaG93IHRoZXkgc2hvdWxkIGJlIGNo YW5nZWQgKGlmIGF0IGFsbCkgaW4gYSBwb3NzaWJsZSB1cGRhdGUNCg0KQmFjayB0aGVuLCBvdXIg dGhpbmtpbmcgd2FzIHRoYXQgd2UgY291bGQgd3JpdGUgYSBwYXBlciBhYm91dCBpdCwgYW5kIHRy eSB0byBnZXQgdGhpcyBkZXBsb3llZCBhcyBhIHdheSBvZiBkb2luZyB0aGUgRXhwZXJpbWVudCBh bmQgbW92aW5nIHRoaXMgdG8gUFMgc3RhdHVzLg0KSG93ZXZlciwgd2Ugd2VyZSBsZXNzIGFuZCBs ZXNzIHN1cmUgYWJvdXQgdGhlIHJlYWwgdmFsdWUgb2YgdGhpcyAtIHdoZXRoZXIgYWN0dWFsIG5l dHdvcmtzIG5lZWQgdGhpcz8gVGhlbiwgd2UgaGFkIGxlc3MgYW5kIGxlc3MgdGltZSBhdmFpbGFi bGUgYW5kIGF0IHNvbWUgcG9pbnQgZHJvcHBlZCB0aGUgYmFsbC4NCkkgb2YgY291cnNlIGZvdW5k IGl0IGludGVyZXN0aW5nIHRvIGhlYXIgdGhhdCBpdCAqaXMqIGEgcmVhbCBwcm9ibGVtLCBldmVu IHRvZGF5Lg0KDQpBbnl3YXk6IHRoaXMgbWFzdGVyIHRoZXNpcyBpcyBhdmFpbGFibGUgaGVyZTog IGh0dHA6Ly9oZWltLmlmaS51aW8ubm8vbWljaGF3ZS90ZWFjaGluZy9kaXBscy9tYXJpdXMtb2xz ZW4vbWFzdGVyc3RoZXNpcy1tYXJpdXNuby5wZGYNCmFuZCBJIHRoaW5rIEkgY2FuIHNhZmVseSBz YXkgb24gYmVoYWxmIG9mIERhdmlkLCBNYXJpdXMgKHRoZSBtYXN0ZXIgc3R1ZGVudCB3aG8gZGlk IHRoaXMpIGFuZCBteXNlbGYgdGhhdCB3ZeKAmXJlIGhhcHB5IGlmIHNvbWVvbmUgcGlja3MgdGhp cyB1cCBhbmQgY29udGludWVzIHRoZSB3b3JrLg0KSXQgd291bGQgcmVxdWlyZSBzb21lIGRpZ2dp bmcsIGJ1dCBJIG1pZ2h0IGFsc28gc3RpbGwgaGF2ZSB0aGUgY29kZSBseWluZyBhcm91bmQgc29t ZXdoZXJlIC0gZm9yIHNvbWUgb3V0ZGF0ZWQgdmVyc2lvbiBvZiBMaW51eOKApg0KDQpDaGVlcnMs DQpNaWNoYWVsDQoNCg0KDQo= --_000_DB4PR07MB3480CBD915CC92D63747315C20C0DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcywgbG9va2luZyBm b3J3YXJkIHRvIHNlZSB0aGUgcmVzdWx0cyBvZiB5b3VyIGV4cGVyaW1lbnRzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SW1wb3J0 YW50IHRvIHVuZGVyc3RhbmQgaXMgdGhhdCB0aGUgZ29hbCBpcyBub3Qg4oCccmVkdWNlZCBBQ0sg cmF0ZSBhdCBhbnkgY29zdOKAnS4gQ2VydGFpbiBhcnJhbmdlbWVudHMgd2lsbCBuZWVkIGEgaGln aGVyIEFDSyByYXRlIHRoYW4gb3RoZXJzIGZvciBpbnN0YW5jZSBkZXBlbmRpbmcgb24gY29uZ2Vz dGlvbg0KIGNvbnRyb2wgc3BlY2lmaWNzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QnV0IGhvcGVmdWxseSB0 aGUgQUNLIHJhdGUgd2lsbCBkZWNyZWFzZSBpbiBhIHN0YXRpc3RpY2FsIHNlbnNlIGFuZCB0aGF0 IGlzIGdvb2QsIGZ1cnRoZXJtb3JlIHdvcmsgb24gdGhpcyB3aWxsIChwb3NzaWJseSBpbiBhbiBp ZGVhbCB3b3JsZCkgc2VuZCBhIHNpZ25hbCB0aGF0IHRoZSBBQ0tzIHRoYXQNCiB0cmF2ZXJzZSB0 aGUgbmV0d29yayBhcmUgbmVlZGVkIGZvciBvbmUgcmVhc29uIG9yIHRoZSBvdGhlciBhbmQgdGhh dCBtaWRkbGVib3hlcyBzaG91bGQgbm90IHRyeSB0byB0YW1wZXIgd2l0aCAmbmJzcDt0aGVzZSBB Q0tzICwgY2FsbCBtZSBhIGRyZWFtZXLigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+L0luZ2VtYXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSmFuYSBJeWVu Z2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDcgYXBy aWwgMjAxNyAwMjo0Njxicj4NCjxiPlRvOjwvYj4gSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7aW5n ZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBZdWNodW5n IENoZW5nICZsdDt5Y2hlbmdAZ29vZ2xlLmNvbSZndDs7IE1pY2hhZWwgV2VsemwgJmx0O21pY2hh d2VAaWZpLnVpby5ubyZndDs7IHRjcG1AaWV0Zi5vcmcgRXh0ZW5zaW9ucyAmbHQ7dGNwbUBpZXRm Lm9yZyZndDs7IHRzdndnIElFVEYgbGlzdCAmbHQ7dHN2d2dAaWV0Zi5vcmcmZ3Q7OyBJYW4gU3dl dHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb dHN2d2ddIFRDUCBBQ0stQ0MgKHJlOiBUcmFuc3BvcnQgcHJvdG9jb2wgZmVlZGJhY2sgb3Zlcmhl YWQgKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MgZm9yIHRoZSBwcmVzZW50YXRpb24gSW5nZW1hcjsgdW5mb3J0dW5hdGVseSBJIG1p c3NlZCB0aGlzIGF0IHRoZSBJRVRGLiBBcyBvbmUgb2YgdGhlIGF1dGhvcnMgb2YgUkZDIDU2OTAs IEknbSBmYW1pbGlhciB3aXRoIHRoZSBwaXRmYWxscyBvZiBkb2luZyBhY2sgQ0MsIGJ1dCBJIHRo aW5rIHdlIG1heSBiZSBhYmxlIHRvIGdldCBhcm91bmQgdGhlbSBpbiBRVUlDIHNpbmNlIHRoZXJl J3MgZXhwbGljaXQNCiBhY2sgaW5mb3JtYXRpb24gaW4gUVVJQy4gV2UgYXJlIGV4cGVyaW1lbnRp bmcgd2l0aCB0aGlzIGluIFFVSUMsIGFuZCB3ZSdsbCBiZSBoYXBweSB0byBicmluZyBkYXRhIHdo ZW4gd2UgaGF2ZSBzb21lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gRnJpLCBNYXIgMzEsIDIwMTcgYXQgMTA6MzUgQU0sIEluZ2VtYXIgSm9oYW5zc29u IFMgJmx0OzxhIGhyZWY9Im1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciB0aGUgZGV0YWlscy4g SXQgbWF5IGJlIHRoZSBjYXNlIHRoYXQgaXQgY2FuIGJlIHRyaWNreSB0byBnZXQgYSBkZWNlbnQg dW5kZXJzdGFuZGluZyBvZiB3aGF0IGlzIHBvc3NpYmxlDQogaW4gdGVybXMgb2YgQUNLIHJhdGUg cmVkdWN0aW9uIGZvciBUQ1AuIFRoZSBtaWRkbGVib3ggYmVoYXZpb3IgdG8gZGlzY2FyZCBldmVy eXRoaW5nIGV4Y2VwdCB0aGUgbGFzdCBBQ0sgaGFzIGFsc28gYmVlbiBwcm9wb3NlZCBpbiB0aGUg UkFOMiBXRyBpbiAzR1BQLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+L0luZ2VtYXI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFl1Y2h1bmcgQ2hl bmcgW21haWx0bzo8YSBocmVmPSJtYWlsdG86eWNoZW5nQGdvb2dsZS5jb20iIHRhcmdldD0iX2Js YW5rIj55Y2hlbmdAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDMxIG1h cnMgMjAxNyAwMDoxNzxicj4NCjxiPlRvOjwvYj4gTWljaGFlbCBXZWx6bCAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1pY2hhd2VAaWZpLnVpby5ubyIgdGFyZ2V0PSJfYmxhbmsiPm1pY2hhd2VAaWZpLnVp by5ubzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJbmdlbWFyIEpvaGFuc3NvbiBTICZsdDs8YSBo cmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2Js YW5rIj5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7OyB0c3Z3ZyBJRVRG IGxpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnRzdndnQGlldGYub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0Zi5vcmc8L2E+IEV4dGVuc2lvbnMgJmx0OzxhIGhyZWY9 Im1haWx0bzp0Y3BtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGNwbUBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHN2d2ddIFRDUCBBQ0stQ0MgKHJlOiBUcmFu c3BvcnQgcHJvdG9jb2wgZmVlZGJhY2sgb3ZlcmhlYWQgKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5yZWdhcmRp bmcgdGhlIHF1ZXN0aW9uIGluIHRoZSBzbGlkZSA1LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+JnF1b3Q7SXMgaW1tZWRpYXRlIEFDSyBuZWVkZWQgZm9yIG91 dCBvZiBvcmRlciBzZWdtZW50cyBpZiBSQUNLIGlzIHVzZWQgPyZxdW90OzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGFuc3dlciBp cyBib3RoIHllcyBhbmQgbm86IGEgdGltZWx5IGZlZWRiYWNrIGlzIGFwcHJlY2lhdGVkICh5ZXMp LiBCdXQgUkFDSyBkb2VzIG5vdCBuZWVkIDEwMCBEVVBBQ0tzIGVhY2ggdGVsbGluZyBvbmUgbW9y ZSBwYWNrZXQgaXMgZGVsaXZlcmVkIG91dCBvZiBvcmRlciAobm8pLiBJbiBvdGhlciB3b3Jkcw0K IGlmIHRoZSBBQ0sgaXMgdGltZWx5IGFuZCBwcmVjaXNlIGFib3V0IHRoZSBkZWxpdmVyeSBwcm9j ZXNzLCBSQUNLIHdvdWxkIHdvcmsgd2VsbCAoc28gZG9lcyBCQlIpLiBIb3dldmVyIHRoaXMgY2Fu IGdvIHRlcnJpYmx5IHdyb25nIGlmIHRoZSBtaWRkbGUtYm94IHNlbmRzIG9ubHkgdGhlIGxhc3Qg QUNLL1NBQ0suIEl0IGhhcyBoYXBwZW5lZCBpbiBvbmUgbWFqb3IgY2xvdWQgcGxhdGZvcm0uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBUaHUsIE1hciAzMCwgMjAxNyBhdCAyOjE0IFBNLCBNaWNoYWVsIFdlbHpsICZsdDs8YSBocmVm PSJtYWlsdG86bWljaGF3ZUBpZmkudWlvLm5vIiB0YXJnZXQ9Il9ibGFuayI+bWljaGF3ZUBpZmku dWlvLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgSW5nZW1hciBmb3IgeW91ciBpbnRlcmVzdGlu ZyBwcmVzZW50YXRpb24gdG9kYXk6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzLzk4L3NsaWRlcy9zbGlkZXMtOTgtdHN2d2ctc2Vzc2ItNy10cmFuc3BvcnQtcHJvdG9jb2wt ZmVlZGJhY2stb3ZlcmhlYWQtaXNzdWVzLWFuZC1zb2x1dGlvbnMtMDAucGRmIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05 OC10c3Z3Zy1zZXNzYi03LXRyYW5zcG9ydC1wcm90b2NvbC1mZWVkYmFjay1vdmVyaGVhZC1pc3N1 ZXMtYW5kLXNvbHV0aW9ucy0wMC5wZGY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdhbnRlZCB0byBzaGFyZSB3aXRoIHlvdSwg YW5kIHRoZSBsaXN0LCB0aGF0IERhdmlkIFJvcyAmbmJzcDsob25lIG9mIHRoZSBvcmlnaW5hbCBh dXRob3JzIG9mIEFDSy1DQywgUkZDIDU2OTApIGFuZCBJIG9uY2UgYWR2aXNlZCBhIG1hc3RlciBz dHVkZW50IHRvOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4tIGltcGxlbWVudCBBQ0stQ0M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSB0ZXN0IGl0PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gYW5hbHl6ZSBhbGwgUkZDIDIxMTkgLSBz dHlsZSBrZXl3b3JkcyBpbiBSRkMgNTY5MCwgdG8gc2VlIGhvdyB0aGV5IHNob3VsZCBiZSBjaGFu Z2VkIChpZiBhdCBhbGwpIGluIGEgcG9zc2libGUgdXBkYXRlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CYWNrIHRoZW4sIG91ciB0aGlu a2luZyB3YXMgdGhhdCB3ZSBjb3VsZCB3cml0ZSBhIHBhcGVyIGFib3V0IGl0LCBhbmQgdHJ5IHRv IGdldCB0aGlzIGRlcGxveWVkIGFzIGEgd2F5IG9mIGRvaW5nIHRoZSBFeHBlcmltZW50IGFuZCBt b3ZpbmcgdGhpcyB0byBQUyBzdGF0dXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkhvd2V2ZXIsIHdlIHdlcmUgbGVzcyBhbmQgbGVzcyBzdXJl IGFib3V0IHRoZSByZWFsIHZhbHVlIG9mIHRoaXMgLSB3aGV0aGVyIGFjdHVhbCBuZXR3b3JrcyBu ZWVkIHRoaXM/IFRoZW4sIHdlIGhhZCBsZXNzIGFuZCBsZXNzIHRpbWUgYXZhaWxhYmxlIGFuZCBh dCBzb21lIHBvaW50IGRyb3BwZWQgdGhlIGJhbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgb2YgY291cnNlIGZvdW5kIGl0IGludGVyZXN0 aW5nIHRvIGhlYXIgdGhhdCBpdCAqaXMqIGEgcmVhbCBwcm9ibGVtLCBldmVuIHRvZGF5LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW55 d2F5OiB0aGlzIG1hc3RlciB0aGVzaXMgaXMgYXZhaWxhYmxlIGhlcmU6ICZuYnNwOzxhIGhyZWY9 Imh0dHA6Ly9oZWltLmlmaS51aW8ubm8vbWljaGF3ZS90ZWFjaGluZy9kaXBscy9tYXJpdXMtb2xz ZW4vbWFzdGVyc3RoZXNpcy1tYXJpdXNuby5wZGYiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vaGVp bS5pZmkudWlvLm5vL21pY2hhd2UvdGVhY2hpbmcvZGlwbHMvbWFyaXVzLW9sc2VuL21hc3RlcnN0 aGVzaXMtbWFyaXVzbm8ucGRmPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5hbmQgSSB0aGluayBJIGNhbiBzYWZlbHkgc2F5IG9uIGJlaGFs ZiBvZiBEYXZpZCwgTWFyaXVzICh0aGUgbWFzdGVyIHN0dWRlbnQgd2hvIGRpZCB0aGlzKSBhbmQg bXlzZWxmIHRoYXQgd2XigJlyZSBoYXBweSBpZiBzb21lb25lIHBpY2tzIHRoaXMgdXAgYW5kIGNv bnRpbnVlcyB0aGUgd29yay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SXQgd291bGQgcmVxdWlyZSBzb21lIGRpZ2dpbmcsIGJ1dCBJIG1pZ2h0 IGFsc28gc3RpbGwgaGF2ZSB0aGUgY29kZSBseWluZyBhcm91bmQgc29tZXdoZXJlIC0gZm9yIHNv bWUgb3V0ZGF0ZWQgdmVyc2lvbiBvZiBMaW51eOKApjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NaWNoYWVsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB4PR07MB3480CBD915CC92D63747315C20C0DB4PR07MB348eurprd_-- From nobody Fri Apr 7 08:46: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 36D5A128959 for ; Fri, 7 Apr 2017 08:46:39 -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 (1024-bit key) header.d=dell.com header.b=ETWKD16r; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=p2Vnhweq 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 Srj54iZNuAXm for ; Fri, 7 Apr 2017 08:46:37 -0700 (PDT) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (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 2C01B1293D6 for ; Fri, 7 Apr 2017 08:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1491579699; x=1523115699; h=from:cc:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=qBzGdrUyBj5fNzPWstDxunYQzw8BdsYsvd7WorF9zeo=; b=ETWKD16rhVd/tOuJCsUFdYn5g+oparyM9fpkvvUvgebjJCmkmr4pvCcw lcQwNFXbd6qfLewqx0kwKkdwUQBJtcRTO3nPu/gMWnFRCXI8DpidGzzqD yySAyrtOsL69vvqmjnMXIsUuZIzQVzV20NixaAaD4gfFWc5vFDsFbYbAj g=; Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 10:41:39 -0500 From: "Black, David" Cc: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 21:44:45 +0600 Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v37FkXxA029053 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 7 Apr 2017 11:46:35 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v37FkXxA029053 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1491579995; bh=ZvNKz00YuGBEb3YLVRwT1USc2fQ=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=p2VnhweqKv0cS0QoO+eoFe8gTTh7qi2t1fXWs3uC28KdW+a1F5qoP5g51wGxtPy6k ZdFNCqU9D8aOI2iooXfLcYcxdwGFJil3Prm2zcI4pcqACTOhKdybC1dE0ceL+aMIt5 kXO7dWJconwrbxlqMWBYBnR9EvAnf9whyikcjYpc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v37FkXxA029053 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd04.lss.emc.com (RSA Interceptor) for ; Fri, 7 Apr 2017 11:45:09 -0400 Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v37FkH9K024204 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Fri, 7 Apr 2017 11:46:17 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0266.001; Fri, 7 Apr 2017 11:46:17 -0400 To: "tcpm@ietf.org" Thread-Topic: FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black) Thread-Index: AdKvtheSW8e/Q8HxSQe3bn4h+L8u/Q== Date: Fri, 7 Apr 2017 15:46:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.125] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black) 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, 07 Apr 2017 15:46:39 -0000 I sent this review to the draft authors privately, and they asked that I fo= rward to the TCPM list; this version had been edited slightly from what I s= ent to the draft authors. Please cc: me directly on any responses or follo= w-up emails, as I'm not currently on the TCPM list. In general, I think this draft is headed in the right direction. I've limi= ted this review to items with at least moderate technical impact. I apolog= ize that it's taken over 4 months to get this review done - the day job has= been putting much more pressure on my IETF activity that expected since th= e start of this year. Overall concern: Abstract and Introduction should make it clear that this = draft is primarily about Accurate ECN, with applicability to vanilla RFC 31= 68 ECN being an open question for further discussion. It's also not clear = to me whether applicability to vanilla RFC 3168 ECN is a single global deci= sion for all packet types vs. a per-packet-type decision. -- Section 1.3 OLD RFC3168 does not prevents from using ECN in TCP control packets lightly. It provides a number of specific reasons for each packet type. In this Section 4, we revisit each of the arguments provided by RFC3168 and explore possibilities to enable the ECN capability in the different packet types. NEW RFC3168 does not prohibit use of ECN for TCP control packets lightly. It provides a number of specific reasons why ECN should not be used for each packet type. In this Section 4, we anal= yze each of the reasons provided by RFC3168 as part of explaining why this experiment is reasonable to conduct for each of the different packet typ= es. Last sentence in old text is too weak - "explore possibilities" doesn't sou= nd like providing a solid rationale for experimentation. -- Section 2 OLD Retransmission: A TCP segment that has been retransmitted by the TCP sender because it determined that the original segment was lost, which may or may not be the case. NEW Retransmission: A TCP segment that has been retransmitted by the TCP sender. Shortened definition to improve clarity. -- Section 3.1 This section is problematic as written, as it appears to require a router t= o parse TCP packets and maintain enough state to detect retransmissions. T= hat's surely not what was intended ;-). This section should be rewritten = and dramatically shorted to require that routers treat ECT-marked TCP contr= ol packets and retransmissions just like any other ECT-marked packet, as sp= ecified in RFC 3168 (and don't repeat lengthy RFC 3168 text here). The reason to rewrite this section to point to RFC 3168 is that any diverge= nce from RFC 3168 network node behavior for other ECT-marked packets is lik= ely to not only be a bad idea, but to also be fatal to this proposal. It's= ok to cite RFCs beyond 3168 if needed to specify the network node behavio= r. -- Section 3.2.1.1 The server SHOULD not set any of the ECT codepoints if the server is included in the cache as not supporting ECN in the SYN packet. Which cache? The natural reading of this text is "the client's cache" in w= hich case this requirement is unimplementable as written because the server= can't see the client's cache. I suspect that the actual requirement is th= at the server not change its ECN behavior until any client cache entry for = it is certain to have aged out (how long would that be? provide an answer .= ..). There appears to be an analogous concern with the server cache in 3.= 2.1.2. --Section 3.2.2.1 Also, it should be noted than if an ACK is dropped due to congestion the sender of the ACK does not react by reducing the load in any way. Given that statement, much of the discussion of how to reduce sender load o= n the network may be irrelevant. In the quoted sentence, at least the fi= rst instance of "ACK" should be "pure ACK". -- Section 3.2.3.1 I think the reduction in offered load discussion in this section is pointle= ss; the sender should behave as if the Zero Window Probe were dropped. -- End of Section 3.2 This would be a good place to summarize sender and receiver behavior change= s. That summary is needed anyhow, as the changes to RFC 3168 need to be cl= early called out, and preferably summarized in one place. -- Section 4.1 In particular, setting the CE codepoint in the very same packet seem to fulfill this criteria, since either the packet is delivered and the CE codepoint signal is delivered to the endpoint, or the packet is dropped, so the original congestion signal through the packet loss is delivered to the endpoint. That assumes that "the very same packet" will be retransmitted, which is co= rrect for data packets, but not control packets (e.g., a pure ACK or a zer= o window probe). What may be missing (or not well stated in the rest of th= is paragraph) is that drops of these packets don't cause congestion reactio= ns.=20 As currently specified, ECN adoption implies an increased reliability of the ECN congestion signal and a decrease in the reliability in the TCP control packets. We believe that it is possible and desirable to restore the tradeoff existent in non ECN capable networks in terms of reliability, where the congestion signal delivery is as reliable as in a non ECN capable network and so it is the delivery of TCP control packets. Add a section reference for decrease in reliability - to Section 1.1 ?? Thanks, --David -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- From nobody Fri Apr 7 15:05:50 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 B8F1C127B5A for ; Fri, 7 Apr 2017 15:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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=bobbriscoe.net 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 hY9y6kJe8DcZ for ; Fri, 7 Apr 2017 15:05:34 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 2AA56129457 for ; Fri, 7 Apr 2017 15:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CJkxmqAA1+6DRd3KREMVgRGz5YP4kkVglu5iFhXBsyM=; b=YNMegG/RLF9/V48iy5v+LolOe1 U3Ua02bKiIADXdWkYffZCGKDYVLirKQrZnIHe3wLk1XZiTd3A+N7fQmobYrZtzd9gsGnyxPd20gFg ZNcGo03ExklZM7wrAF8RjKpKppEYW0/uk4uZm2TcpWE11cVGGhJXtFdiP2Q4CI9sL1PPnKQyGsSTz Q+EalM0um6n1uvaWYycNVXWNILHQThV0HCExaqPcgCnbjrO1e+n7LEZBc7H9lgPXyyTakxsBiD3pb JSpk55Fqge5KA9G0pQZjUAx3xQ3QdlVrck6US704N25pLGPDXQuSSAak7r508y6tS2WaDGO0Qctwa +aSDP/0g==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:50370 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cwc0K-0005Vy-PB; Fri, 07 Apr 2017 23:05:17 +0100 To: "Black, David" References: Cc: "tcpm@ietf.org" From: Bob Briscoe Message-ID: <3d53f6a4-697b-0c7a-8c71-524890312beb@bobbriscoe.net> Date: Fri, 7 Apr 2017 23:05:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black) 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, 07 Apr 2017 22:05:41 -0000 David, Thank you for these useful comments. Detailed responses inline. In summary, I think all your proposed changes improve clarity. I don't think you've disagreed with any technical effect of the proposed protocol. On 07/04/17 16:46, Black, David wrote: > I sent this review to the draft authors privately, and they asked that I forward to the TCPM list; this version had been edited slightly from what I sent to the draft authors. Please cc: me directly on any responses or follow-up emails, as I'm not currently on the TCPM list. > > In general, I think this draft is headed in the right direction. I've limited this review to items with at least moderate technical impact. I apologize that it's taken over 4 months to get this review done - the day job has been putting much more pressure on my IETF activity that expected since the start of this year. > > Overall concern: Abstract and Introduction should make it clear that this draft is primarily about Accurate ECN, with applicability to vanilla RFC 3168 ECN being an open question for further discussion. [BB] We obviously need to clarify that AccECN is solely relevant to SYNs, and all other control packets could be made ECN-capable whether or not AccECN was being used. Actually, AccECN is only mentioned in the sections about SYNs. However, I accept that it would help to point that out explicitly. And to explain why. Here's why: In RFC3168 ECN feedback, the Echo Congestion Experienced (ECE) flag is used for capability negotiation during the 3WHS. So, even if the client makes the SYN ECN-capable and then it's marked CE, the SYN-ACK has nowhere for the server to feed this back. In contrast, an AccECN server supports feedback in the SYN/ACK of any CE on the SYN. The relevant sections of AccECN are: https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-02#section-2.5 https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-02#section-3.1 BTW, there is one mention of AccECN in the section on Pure ACKs as well - necessary to consider whether AccECN would count CE on Pure ACKs. We'll clarify that this is not saying that AccECN is necessary. > It's also not clear to me whether applicability to vanilla RFC 3168 ECN is a single global decision for all packet types vs. a per-packet-type decision. [BB] This is a consequence of the process of reaching consensus. Initially, we had to assume that someone might come up with a good argument against setting ECT on one of the types. So it is written as if the decision on each type is independent. Nonetheless, I think it would now make sense to add a sentence saying: To comply with this spec, a TCP sender will set ECT on all types of control packets. However, RFC3168 allows an ECN sender to choose not to set ECT on any individual packet (although it gives no example reasons why a sender would not set ECT). So I don't think we don't need to /require/ a TCP sender to set all types of packet to ECT. > > -- Section 1.3 > > OLD > RFC3168 does not prevents from using ECN in TCP > control packets lightly. It provides a number of specific reasons > for each packet type. In this Section 4, we revisit each of the > arguments provided by RFC3168 and explore possibilities to enable the > ECN capability in the different packet types. > NEW > RFC3168 does not prohibit use of ECN for TCP > control packets lightly. It provides a number of specific reasons why > ECN should not be used for each packet type. In this Section 4, we analyze > each of the reasons provided by RFC3168 as part of explaining why this > experiment is reasonable to conduct for each of the different packet types. > > Last sentence in old text is too weak - "explore possibilities" doesn't sound like providing a solid rationale for experimentation. > > -- Section 2 > > OLD > Retransmission: A TCP segment that has been retransmitted by the TCP > sender because it determined that the original segment was lost, > which may or may not be the case. > NEW > Retransmission: A TCP segment that has been retransmitted by the TCP > sender. > > Shortened definition to improve clarity. [BB] AOK so far > -- Section 3.1 > > This section is problematic as written, as it appears to require a router to parse TCP packets and maintain enough state to detect retransmissions. That's surely not what was intended ;-). [BB] Indeed. We intended this to apply to any middlebox (e.g. firewall) that already parses the TCP header. > This section should be rewritten and dramatically shorted to require that routers treat ECT-marked TCP control packets and retransmissions just like any other ECT-marked packet, [BB] I agree (and I hope my co-author does) that it would be clearer just to say this. > as specified in RFC 3168 (and don't repeat lengthy RFC 3168 text here). [BB] Unfortunately, RFC3168 does not specify anything about network node forwarding behaviour wrt ECT. So some firewall policies could have decided to block any TCP control packets that contravene RFC3168. That's why we wrote this section. However I admit that, by not explaining that DPI was the problem we were trying to solve, it reads like we are advocating DPI, rather than removing any ambiguity that might have been interpreted as a need for DPI. We'll fix this. > > The reason to rewrite this section to point to RFC 3168 is that any divergence from RFC 3168 network node behavior for other ECT-marked packets is likely to not only be a bad idea, but to also be fatal to this proposal. It's ok to cite RFCs beyond 3168 if needed to specify the network node behavior. [BB] As above, no network node behaviour wrt ECT is specified in RFC 3168 (unless you can point to it - I just checked again, and I couldn't find it). > > -- Section 3.2.1.1 > > The server SHOULD not set any of the ECT codepoints if > the server is included in the cache as not supporting ECN in the SYN > packet. > > Which cache? The natural reading of this text is "the client's cache" in which case this requirement is unimplementable as written because the server can't see the client's cache. I suspect that the actual requirement is that the server not change its ECN behavior until any client cache entry for it is certain to have aged out (how long would that be? provide an answer ...). [BB] This is a simple typo. I'm sure the sentence was intended to start "The client SHOULD...", not "The server SHOULD..." (The section is entitled "TCP client behaviour"). Sorry about that. > There appears to be an analogous concern with the server cache in 3.2.1.2. [BB] I'm not sure I agree with the need for a server cache about clients at all. The incoming SYNs unambiguously say what type of client they came from. I will check with my co-author why this sentence is here. > > --Section 3.2.2.1 > > Also, it should be noted than if an ACK > is dropped due to congestion the sender of the ACK does not react by > reducing the load in any way. > > Given that statement, much of the discussion of how to reduce sender load on the network may be irrelevant. [BB] I agree. We will put this sentence first. Then say that ECT on pure ACKs could be used for ACK CC and refer to RFC 5690 rather than describing a possible ACK CC scheme here. Then make the point that an ECN connection not implementing ACK CC is hardly worse than a non-ECN connection not implementing ACK CC, both of which are the norm. > In the quoted sentence, at least the first instance of "ACK" should be "pure ACK". [BB] Yup. > > -- Section 3.2.3.1 > > I think the reduction in offered load discussion in this section is pointless; [BB] The text is sort-of saying that. But I admit it could be clearer - we'll sort it. > the sender should behave as if the Zero Window Probe were dropped. [BB] Well, I don't know that any TCP implementation does anything specific in this case. And I certainly can't find anything written in RFC793 or RFC5681 about this. > > -- End of Section 3.2 > > This would be a good place to summarize sender and receiver behavior changes. That summary is needed anyhow, as the changes to RFC 3168 need to be clearly called out, and preferably summarized in one place. [BB] Good, yes. > > -- Section 4.1 > > In particular, setting the CE > codepoint in the very same packet seem to fulfill this criteria, > since either the packet is delivered and the CE codepoint signal is > delivered to the endpoint, or the packet is dropped, so the original > congestion signal through the packet loss is delivered to the > endpoint. > > That assumes that "the very same packet" will be retransmitted, which is correct for data packets, but not control packets (e.g., a pure ACK or a zero window probe). What may be missing (or not well stated in the rest of this paragraph) is that drops of these packets don't cause congestion reactions. [BB] Yes, we'll make this point clearer. > > As currently specified, ECN adoption implies an increased reliability > of the ECN congestion signal and a decrease in the reliability in the > TCP control packets. We believe that it is possible and desirable to > restore the tradeoff existent in non ECN capable networks in terms of > reliability, where the congestion signal delivery is as reliable as > in a non ECN capable network and so it is the delivery of TCP control > packets. > > Add a section reference for decrease in reliability - to Section 1.1 ?? [BB] Will do. Thanks again, Bob > > Thanks, --David > -------------------------------------------------------- > David L. Black, Distinguished Engineer > Dell EMC, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 Cell: +1 (978) 394-7754 > David.Black@dell.com <=== NEW === > -------------------------------------------------------- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Apr 7 15:33:38 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 85075128B8E for ; Fri, 7 Apr 2017 15:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=YqK5b7Oj; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=HCT3WJOf 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 5ucC7kfQaJiV for ; Fri, 7 Apr 2017 15:33:22 -0700 (PDT) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (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 A2BFC12714F for ; Fri, 7 Apr 2017 15:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1491604266; x=1523140266; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dI9PtoKtQpZgH8BZohqSWhWNtpyraIY8O9lgPhZ8bOg=; b=YqK5b7Oj5Ghud5dPsX9cDMIZ9c17ZyFVjQ/+f63nsKCp04gttt+wNRL2 Fn2Eozb5TtDP52NAXT95t9WrP6/wCRETETqPAFl4DWWT4RMX9RgAM7d5Q hmUSKxySsTYgnNUX9HGTjW2NFsDUnxr8VMuiD4heDK/FRYCURmQpFFo2P g=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 17:31:06 -0500 From: "Black, David" Cc: "tcpm@ietf.org" , "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2017 04:27:37 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v37MXJOR026540 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 18:33:20 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v37MXJOR026540 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1491604400; bh=arryHjGYz6+atiGgE/wTatoeyYM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=HCT3WJOft081GktAX0H/e+6YAIwhZ6hCiQJKlcaNYo88tvb3vW6D1OrI3n+lkfXOi buaCtSFK/tI9uZPzF/iia2JZGQ0b479kLz6AEysvBEvmVT5M0su+lGOEigKGz24iJb joWP6ibR8v/D6Y0nuhyPFAy40UKKfykVctBxixaY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v37MXJOR026540 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 7 Apr 2017 18:32:54 -0400 Received: from MXHUB314.corp.emc.com (MXHUB314.corp.emc.com [10.146.3.92]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v37MX9i6019305 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 7 Apr 2017 18:33:09 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB314.corp.emc.com ([10.146.3.92]) with mapi id 14.03.0266.001; Fri, 7 Apr 2017 18:33:09 -0400 To: Bob Briscoe Thread-Topic: [tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black) Thread-Index: AdKvtheSW8e/Q8HxSQe3bn4h+L8u/QAVnh6AAAgFZlA= Date: Fri, 7 Apr 2017 22:33:08 +0000 Message-ID: References: <3d53f6a4-697b-0c7a-8c71-524890312beb@bobbriscoe.net> In-Reply-To: <3d53f6a4-697b-0c7a-8c71-524890312beb@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black) 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, 07 Apr 2017 22:33:30 -0000 Bob, Two comments: 1) I'll wait for new text before commenting further on Accurate ECN vs. van= illa RFC 3168 ECN. The current text left me somewhat confused, and the sum= mary of changes from RFC 3168 will almost certainly help. 2) On network node treatment of ECT, RFC 3168 is brief, e.g. (Section 5, to= p of p.7): The CE codepoint '11' is set by a router to indicate congestion to the end nodes. =20 One wants to avoid text that could be read as modifying that sentence by ad= ding possible exceptions for TCP control packets and/or retransmissions. > [BB] Unfortunately, RFC3168 does not specify anything about network node > forwarding behaviour wrt ECT. So some firewall policies could have > decided to block any TCP control packets that contravene RFC3168. That's > why we wrote this section. If "firewalls" is what was meant, use that word ;-) ... or as you write ... > However I admit that, by not explaining that DPI was the problem we were > trying to solve, rather than removing any ambiguity that might have been > interpreted as a need for DPI. We'll fix this. In doing so, please keep in mind that in this draft, discussion of forwardi= ng and dropping behavior is implicitly about router queue management, not = middlebox access control (e.g., based on DPI), so access control has to be = called out explicitly when that is what is meant. Thanks, --David > -----Original Message----- > From: Bob Briscoe [mailto:ietf@bobbriscoe.net] > Sent: Friday, April 7, 2017 6:05 PM > To: Black, David > Cc: tcpm@ietf.org > Subject: Re: [tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn > (David Black) >=20 > David, >=20 > Thank you for these useful comments. > Detailed responses inline. >=20 > In summary, I think all your proposed changes improve clarity. I don't > think you've disagreed with any technical effect of the proposed protocol= . >=20 >=20 > On 07/04/17 16:46, Black, David wrote: > > I sent this review to the draft authors privately, and they asked that = I > forward to the TCPM list; this version had been edited slightly from what= I > sent to the draft authors. Please cc: me directly on any responses or fo= llow- > up emails, as I'm not currently on the TCPM list. > > > > In general, I think this draft is headed in the right direction. I've = limited this > review to items with at least moderate technical impact. I apologize tha= t it's > taken over 4 months to get this review done - the day job has been puttin= g > much more pressure on my IETF activity that expected since the start of t= his > year. > > > > Overall concern: Abstract and Introduction should make it clear that t= his > draft is primarily about Accurate ECN, with applicability to vanilla RFC = 3168 > ECN being an open question for further discussion. > [BB] We obviously need to clarify that AccECN is solely relevant to > SYNs, and all other control packets could be made ECN-capable whether or > not AccECN was being used. Actually, AccECN is only mentioned in the > sections about SYNs. However, I accept that it would help to point that > out explicitly. And to explain why. Here's why: >=20 > In RFC3168 ECN feedback, the Echo Congestion Experienced (ECE) flag is > used for capability negotiation during the 3WHS. So, even if the client > makes the SYN ECN-capable and then it's marked CE, the SYN-ACK has > nowhere for the server to feed this back. In contrast, an AccECN server > supports feedback in the SYN/ACK of any CE on the SYN. >=20 > The relevant sections of AccECN are: > https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-02#section-2.5 > https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-02#section-3.1 >=20 > BTW, there is one mention of AccECN in the section on Pure ACKs as well > - necessary to consider whether AccECN would count CE on Pure ACKs. > We'll clarify that this is not saying that AccECN is necessary. >=20 > > It's also not clear to me whether applicability to vanilla RFC 3168 ECN= is a > single global decision for all packet types vs. a per-packet-type decisio= n. > [BB] This is a consequence of the process of reaching consensus. >=20 > Initially, we had to assume that someone might come up with a good > argument against setting ECT on one of the types. So it is written as if > the decision on each type is independent. Nonetheless, I think it would > now make sense to add a sentence saying: >=20 > To comply with this spec, a TCP sender will set ECT on all types of > control packets. >=20 > However, RFC3168 allows an ECN sender to choose not to set ECT on any > individual packet (although it gives no example reasons why a sender > would not set ECT). So I don't think we don't need to /require/ a TCP > sender to set all types of packet to ECT. >=20 > > > > -- Section 1.3 > > > > OLD > > RFC3168 does not prevents from using ECN in TCP > > control packets lightly. It provides a number of specific reasons > > for each packet type. In this Section 4, we revisit each of the > > arguments provided by RFC3168 and explore possibilities to enable t= he > > ECN capability in the different packet types. > > NEW > > RFC3168 does not prohibit use of ECN for TCP > > control packets lightly. It provides a number of specific reasons = why > > ECN should not be used for each packet type. In this Section 4, we > analyze > > each of the reasons provided by RFC3168 as part of explaining why t= his > > experiment is reasonable to conduct for each of the different packe= t > types. > > > > Last sentence in old text is too weak - "explore possibilities" doesn't= sound > like providing a solid rationale for experimentation. > > > > -- Section 2 > > > > OLD > > Retransmission: A TCP segment that has been retransmitted by the TC= P > > sender because it determined that the original segment was lost, > > which may or may not be the case. > > NEW > > Retransmission: A TCP segment that has been retransmitted by the TC= P > > sender. > > > > Shortened definition to improve clarity. > [BB] AOK so far > > -- Section 3.1 > > > > This section is problematic as written, as it appears to require a rout= er to > parse TCP packets and maintain enough state to detect retransmissions. > That's surely not what was intended ;-). > [BB] Indeed. We intended this to apply to any middlebox (e.g. firewall) > that already parses the TCP header. > > This section should be rewritten and dramatically shorted to require th= at > routers treat ECT-marked TCP control packets and retransmissions just lik= e > any other ECT-marked packet, > [BB] I agree (and I hope my co-author does) that it would be clearer > just to say this. > > as specified in RFC 3168 (and don't repeat lengthy RFC 3168 text here). >=20 > [BB] Unfortunately, RFC3168 does not specify anything about network node > forwarding behaviour wrt ECT. So some firewall policies could have > decided to block any TCP control packets that contravene RFC3168. That's > why we wrote this section. >=20 > However I admit that, by not explaining that DPI was the problem we were > trying to solve, it reads like we are advocating DPI, rather than > removing any ambiguity that might have been interpreted as a need for > DPI. We'll fix this. > > > > The reason to rewrite this section to point to RFC 3168 is that any > divergence from RFC 3168 network node behavior for other ECT-marked > packets is likely to not only be a bad idea, but to also be fatal to this= proposal. > It's ok to cite RFCs beyond 3168 if needed to specify the network node > behavior. > [BB] As above, no network node behaviour wrt ECT is specified in RFC > 3168 (unless you can point to it - I just checked again, and I couldn't > find it). > > > > -- Section 3.2.1.1 > > > > The server SHOULD not set any of the ECT codepoints if > > the server is included in the cache as not supporting ECN in the SY= N > > packet. > > > > Which cache? The natural reading of this text is "the client's cache" = in > which case this requirement is unimplementable as written because the > server can't see the client's cache. I suspect that the actual requireme= nt is > that the server not change its ECN behavior until any client cache entry = for it > is certain to have aged out (how long would that be? provide an answer ..= .). > [BB] This is a simple typo. I'm sure the sentence was intended to start > "The client SHOULD...", not "The server SHOULD..." (The section is > entitled "TCP client behaviour"). Sorry about that. > > There appears to be an analogous concern with the server cache in 3.2.1= .2. > [BB] I'm not sure I agree with the need for a server cache about clients > at all. The incoming SYNs unambiguously say what type of client they > came from. >=20 > I will check with my co-author why this sentence is here. > > > > --Section 3.2.2.1 > > > > Also, it should be noted than if an ACK > > is dropped due to congestion the sender of the ACK does not react b= y > > reducing the load in any way. > > > > Given that statement, much of the discussion of how to reduce sender > load on the network may be irrelevant. > [BB] I agree. We will put this sentence first. Then say that ECT on pure > ACKs could be used for ACK CC and refer to RFC 5690 rather than > describing a possible ACK CC scheme here. Then make the point that an > ECN connection not implementing ACK CC is hardly worse than a non-ECN > connection not implementing ACK CC, both of which are the norm. > > In the quoted sentence, at least the first instance of "ACK" should be > "pure ACK". > [BB] Yup. > > > > -- Section 3.2.3.1 > > > > I think the reduction in offered load discussion in this section is poi= ntless; > [BB] The text is sort-of saying that. But I admit it could be clearer - > we'll sort it. > > the sender should behave as if the Zero Window Probe were dropped. > [BB] Well, I don't know that any TCP implementation does anything > specific in this case. And I certainly can't find anything written in > RFC793 or RFC5681 about this. > > > > -- End of Section 3.2 > > > > This would be a good place to summarize sender and receiver behavior > changes. That summary is needed anyhow, as the changes to RFC 3168 need > to be clearly called out, and preferably summarized in one place. > [BB] Good, yes. > > > > -- Section 4.1 > > > > In particular, setting the CE > > codepoint in the very same packet seem to fulfill this criteria, > > since either the packet is delivered and the CE codepoint signal is > > delivered to the endpoint, or the packet is dropped, so the origina= l > > congestion signal through the packet loss is delivered to the > > endpoint. > > > > That assumes that "the very same packet" will be retransmitted, which i= s > correct for data packets, but not control packets (e.g., a pure ACK or a= zero > window probe). What may be missing (or not well stated in the rest of th= is > paragraph) is that drops of these packets don't cause congestion reaction= s. > [BB] Yes, we'll make this point clearer. > > > > As currently specified, ECN adoption implies an increased reliabili= ty > > of the ECN congestion signal and a decrease in the reliability in t= he > > TCP control packets. We believe that it is possible and desirable = to > > restore the tradeoff existent in non ECN capable networks in terms = of > > reliability, where the congestion signal delivery is as reliable as > > in a non ECN capable network and so it is the delivery of TCP contr= ol > > packets. > > > > Add a section reference for decrease in reliability - to Section 1.1 ?? > [BB] Will do. >=20 > Thanks again, >=20 >=20 >=20 > Bob > > > > Thanks, --David > > -------------------------------------------------------- > > David L. Black, Distinguished Engineer > > Dell EMC, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 Cell: +1 (978) 394-7754 > > David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D > > -------------------------------------------------------- > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > >=20 > -- > __________________________________________________________ > ______ > Bob Briscoe http://bobbriscoe.net/ From nobody Fri Apr 7 17:12: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 ECBF71279EB for ; Fri, 7 Apr 2017 17:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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=bobbriscoe.net 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 8p9d9PqhLpMH for ; Fri, 7 Apr 2017 17:12:04 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 A7F3E129451 for ; Fri, 7 Apr 2017 17:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UCXanAcx60VSK/pwRCGvWbb7aUCLGda+WdeJjWjex4w=; b=7g+N39a6yhzhzP0Rj85IPSQR3S HBvOLXH0nHMWwTHQiIpUvlPZBCx38QzXQ57jBaCYiS37tGSOaS1N2In7oP2RIGsbSZNYqV363gLGC aPc8X7/++ywNo9h9Lk1D+JHnZVzQU3fHWzCbCmPmilkMd/sVJbIAThcIxU3FmXLLOF5VwzZZe+mxl QNbZ7sdNjE7vMINTTAm0ek2OLrQpvpWaWwFKQd9o54fyrYFmC7tjTE81FEd3R0fCafH1q6jG5XNjJ IZGRlvA5SCHJSXBcb4GVxSsuhZXD92m2qZe15vpvVoEG41ypWQ7htJc24BlWAkDX3PaCENU+UVXuj mttsFT+w==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:52346 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cwdyr-00030v-9g; Sat, 08 Apr 2017 01:11:53 +0100 To: "Black, David" References: <3d53f6a4-697b-0c7a-8c71-524890312beb@bobbriscoe.net> Cc: "tcpm@ietf.org" From: Bob Briscoe Message-ID: <5a4e46a0-bde7-8de5-f6a3-354f06fd9058@bobbriscoe.net> Date: Sat, 8 Apr 2017 01:11:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black) 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, 08 Apr 2017 00:12:09 -0000 David, On 2) I intend to replace the whole of "3.1 Network behaviour" with the following, which calls out the cases explicitly: Previously RFC3168 required the sender to set not-ECT on certain TCP control packets. Some readers might have erroneously interpreted this aspect of RFC3168 as a requirement for firewalls, intrusion detection systems, etc. to check and enforce this behaviour. Now that the present experimental specification allows TCP senders to set ECT on all TCP packets (control and data), it needs to be clear that a firewall (or any network node) SHOULD NOT treat any ECT packet differently dependent on what type of TCP packet it is. One potential exception is envisaged, otherwise the previous sentence could have said "MUST NOT" rather than "SHOULD NOT". The exception allows a security function that has detected an ongoing attack to drop more ECT marked SYNs than not-ECT marked SYNs. Such a policy SHOULD NOT be applied routinely. It SHOULD only be applied if an attack is detected, and then only if it is determined that the ECT capability is intensifying the attack. Bob On 07/04/17 23:33, Black, David wrote: > Bob, > > Two comments: > > 1) I'll wait for new text before commenting further on Accurate ECN vs. vanilla RFC 3168 ECN. The current text left me somewhat confused, and the summary of changes from RFC 3168 will almost certainly help. > > 2) On network node treatment of ECT, RFC 3168 is brief, e.g. (Section 5, top of p.7): > > The CE codepoint '11' is set by a router to indicate congestion to > the end nodes. > > One wants to avoid text that could be read as modifying that sentence by adding possible exceptions for TCP control packets and/or retransmissions. > >> [BB] Unfortunately, RFC3168 does not specify anything about network node >> forwarding behaviour wrt ECT. So some firewall policies could have >> decided to block any TCP control packets that contravene RFC3168. That's >> why we wrote this section. > If "firewalls" is what was meant, use that word ;-) ... or as you write ... > >> However I admit that, by not explaining that DPI was the problem we were >> trying to solve, rather than removing any ambiguity that might have been >> interpreted as a need for DPI. We'll fix this. > In doing so, please keep in mind that in this draft, discussion of forwarding and dropping behavior is implicitly about router queue management, not middlebox access control (e.g., based on DPI), so access control has to be called out explicitly when that is what is meant. > > Thanks, --David > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Apr 12 05:35:16 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 CB8B11316AA; Wed, 12 Apr 2017 05:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RCO3EDOtX0nf; Wed, 12 Apr 2017 05:35:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 8DAEC1316B0; Wed, 12 Apr 2017 05:35:04 -0700 (PDT) X-AuditID: c1b4fb25-c27a798000006af2-d6-58ee1ef6a816 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 2B.2A.27378.6FE1EE85; Wed, 12 Apr 2017 14:35:02 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.253]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Wed, 12 Apr 2017 14:35:02 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" CC: "iccrg@ietf.org" , "tcpm@ietf.org" , "michawe@ifi.uio.no" Thread-Topic: Heads up on the upcoming WGLC for COCOA Thread-Index: AQHSs4k0mnjKYz30k0+Zp7QNidIepA== Date: Wed, 12 Apr 2017 12:35:01 +0000 Message-ID: <23333C37-60FB-41FD-B43B-EDC75F7BBFDB@ericsson.com> Reply-To: "core@ietf.org WG" Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_23333C3760FB41FDB43BEDC75F7BBFDBericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7pe43uXcRBo8m61nse7ue2eLzx8Ws Fj/O7mS12HZyPpMDi8eSJT+ZPFavfsgcwBTFZZOSmpNZllqkb5fAlbF6zy22gqkaFZu6lrE2 MP5S62Lk5JAQMJGYf3MrUxcjF4eQwHpGiVeHt7JAOEsYJe68a2IBqWITcJb49KyRHcQWEVCT aJ30iq2LkYODWaBY4mtrFEhYWMBA4vDeKUwQJaYSSxtPskLYehLTT51gA7FZBFQltt9bygxi 8wrYS0y/PxVsjJCAjsSFdhGQMKOAmMT3U2vAxjALiEvcejKfCeJOAYkle84zQ9iiEi8f/2OF sJUk1h7ezgJRnyzx9mcf1HhBiZMzn7BMYBSehWTULCRls5CUzQJ7RlNi/S59iBJFiSndD9kh bA2J1jlzoWxriZfPrrEjq1nAyLGKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzDODm75rbqD 8fIbx0OMAhyMSjy8CQ/fRAixJpYVV+YeYpTgYFYS4VW/DBTiTUmsrEotyo8vKs1JLT7EKM3B oiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qBUWDx/JX3WKcye3K5uvyJNb9Qbqti4V5n/smN Q6BI63Wlnkr4vmxj7onX8vd94+F69c3UU82uJWCvctfqpOKPEz7NSGL8Kqi+QudeyRl+tYtS bivTJZQnLFjx1cRZJ5Mpwu3PFq2eiWyyHaqp9X7xM8Q3hp73yrgq1Litq/awQHaxjF7PzYlK LMUZiYZazEXFiQBqIepirwIAAA== Archived-At: Subject: [tcpm] Heads up on the upcoming WGLC for COCOA 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, 12 Apr 2017 12:35:07 -0000 --_000_23333C3760FB41FDB43BEDC75F7BBFDBericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ29SRSBXRywNCg0KdGhpcyBpcyBqdXN0IGEgaGVhZHMgdXAgZm9yIHRoZSB1cGNvbWluZyBX R0xDIGZvciAiQ29BUCBTaW1wbGUgQ29uZ2VzdGlvbiBDb250cm9sL0FkdmFuY2Vk4oCdLg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2NvYS0wMQ0KDQpOb3Rl IHRoYXQgdGhlcmUgaXMgc3RpbGwgc29tZSBkaXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgdG8ga2Vl cCB0aGUgYXBwZW5kaXhlcyBvciBub3QsIGFuZCB0aGF0IHRoZXJlIGlzIHRpbWUgdG8gZ2V0IG90 aGVyIGNvbW1lbnRzIGJlZm9yZSBXR0xDLg0KVGhpcyBkb2N1bWVudCBoYXMgYmVlbiBwcmVzZW50 ZWQgbXVsdGlwbGUgdGltZXMgYW5kIEnigJlkIGxpa2UgdG8gcHJvZ3Jlc3Mgd2l0aCBpdCBzb29u LCBpdOKAmWQgYmUgZ3JlYXQgdG8gaGF2ZSBpdCBieSBQcmFndWUuDQoNClRvIElDQ1JHLCBhcyB5 b3Ugbm93IGFscmVhZHksIHRoaXMgd2FzIHByZXNlbnRlZCBxdWl0ZSBzb21lIHRpbWUgYWdvLCBi ZWxvdyBpcyB0aGUgbGlua3MgdG8gdGhlIHNlc3Npb24gYW5kIHRoZSBzbGlkZXMuDQoNClNlc3Np b246IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL2ljY3JnLmh0bWwNClByZXNl bnRhdGlvbjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRl cy05Mi1pY2NyZy0yLnBkZg0KDQpCZXR3ZWVuIHRoZSB0d28gc2Vzc2lvbnMgdGhlIG1haW4gZGlm ZmVyZW5jZSBpcyB0aGUgYWRkaXRpb24gb2YgdGhlIGFwcGVuZGl4ZXM6DQpodHRwczovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNvcmUtY29jb2EtMDEudHh0DQoNCkNp YW8hDQotIC0gSmFpbWUgSmltw6luZXoNCg0K --_000_23333C3760FB41FDB43BEDC75F7BBFDBericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgQ29SRSBXRywNCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPnRoaXMgaXMganVzdCBh IGhlYWRzIHVwIGZvciB0aGUgdXBjb21pbmcgV0dMQyBmb3IgJnF1b3Q7Q29BUCBTaW1wbGUgQ29u Z2VzdGlvbiBDb250cm9sL0FkdmFuY2Vk4oCdLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvY29h LTAxIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl LWNvY29hLTAxPC9hPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tm90ZSB0aGF0IHRoZXJlIGlzIHN0aWxsIHNvbWUgZGlzY3Vz c2lvbiBhYm91dCB3aGV0aGVyIHRvIGtlZXAgdGhlIGFwcGVuZGl4ZXMgb3Igbm90LCBhbmQgdGhh dCB0aGVyZSBpcyB0aW1lIHRvIGdldCBvdGhlciBjb21tZW50cyBiZWZvcmUgV0dMQy4mbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhpcyBkb2N1bWVudCBoYXMgYmVlbiBwcmVzZW50ZWQgbXVs dGlwbGUgdGltZXMgYW5kIEnigJlkIGxpa2UgdG8gcHJvZ3Jlc3Mgd2l0aCBpdCBzb29uLCBpdOKA mWQgYmUgZ3JlYXQgdG8gaGF2ZSBpdCBieSBQcmFndWUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UbyBJQ0NSRywgYXMgeW91 IG5vdyBhbHJlYWR5LCB0aGlzIHdhcyBwcmVzZW50ZWQgcXVpdGUgc29tZSB0aW1lIGFnbywgYmVs b3cgaXMgdGhlIGxpbmtzIHRvIHRoZSBzZXNzaW9uIGFuZCB0aGUgc2xpZGVzLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U2Vzc2lvbjom bmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9pY2NyZy5o dG1sIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9pY2NyZy5o dG1sPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QcmVzZW50YXRpb246Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRlcy05Mi1pY2Ny Zy0yLnBkZiIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xp ZGVzL3NsaWRlcy05Mi1pY2NyZy0yLnBkZjwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJldHdlZW4gdGhlIHR3byBzZXNz aW9ucyB0aGUgbWFpbiBkaWZmZXJlbmNlIGlzIHRoZSBhZGRpdGlvbiBvZiB0aGUgYXBwZW5kaXhl czo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLWNvY29hLTAxLnR4dCIgY2xhc3M9IiI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLWNvY29hLTAxLnR4 dDwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkNpYW8hPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQot IC0gSmFpbWUgSmltw6luZXo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_23333C3760FB41FDB43BEDC75F7BBFDBericssoncom_-- From nobody Wed Apr 12 05:38:27 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 1FDE1129AB8; Wed, 12 Apr 2017 05:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 qdyZgMZYDdiI; Wed, 12 Apr 2017 05:38:19 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 D00E71316B7; Wed, 12 Apr 2017 05:38:17 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-ed-58ee1fb8faa4 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 6C.C0.21650.8BF1EE85; Wed, 12 Apr 2017 14:38:16 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.253]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Wed, 12 Apr 2017 14:38:01 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" CC: "iccrg@irtf.org" , "tcpm@ietf.org" , "michawe@ifi.uio.no" Thread-Topic: Heads up on the upcoming WGLC for COCOA Thread-Index: AQHSs4mfQjrNXAdDOU6pskdy1cCI4w== Date: Wed, 12 Apr 2017 12:38:01 +0000 Message-ID: <623D63BA-FCEA-411C-B0C0-03EF4978FA47@ericsson.com> Reply-To: "core@ietf.org WG" Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_623D63BAFCEA411CB0C003EF4978FA47ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7qO4O+XcRBqf+Clrse7ue2eLAgp3s Fj/O7mS12HZyPpMDi8eSJT+ZPFavfsjsMXnjYbYA5igum5TUnMyy1CJ9uwSujJ7dF9gKzipX vNu9kqmB8ZBSFyMnh4SAicTO+y/Yuxi5OIQE1jNK7Jt7kBXCWcIo8XHCdRaQKjYBZ4lPzxrZ QWwRATWJ1kmv2EBsZoFiiSn/vzGC2MIChhL/ftxmgagxk1i1Yg0jhK0nsX5jM5jNIqAqcb9x MpDNwcErYC9xb1UciCkkoCNxoV0EpIJRQEzi+6k1TBDTxSVuPZnPBHGngMSSPeeZIWxRiZeP /7FC2EoSK7ZfYoSoT5b4uWcDWD2vgKDEyZlPWCYwCs9CMmoWkrJZSMpmAV3BLKApsX6XPkSJ osSU7ofsELaGROucuVC2tcSHp9uZkNUsYORYxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREY cQe3/LbawXjwueMhRgEORiUe3oSHbyKEWBPLiitzDzFKcDArifCqXwYK8aYkVlalFuXHF5Xm pBYfYpTmYFES53XYdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwNjM8KA1t+/ywaOaBwoF/yxf0dWm +1vCqX3fugXHI+J11IQivKvWvzngs/u/xL2FBhd049028M57xbZE1mzuS6U9bKxntBjuTOs/ FxD5RVmp+qlIp4WlcdPpZK/vGgfWd6nEzzz4fuLG/nA9rW+TcvNe3WdY9oHr2yeOHdo39dQT Wd70Hpm/ZbMSS3FGoqEWc1FxIgCztiY0tAIAAA== Archived-At: Subject: [tcpm] Heads up on the upcoming WGLC for COCOA 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, 12 Apr 2017 12:38:20 -0000 --_000_623D63BAFCEA411CB0C003EF4978FA47ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ29SRSBXRywNCg0KdGhpcyBpcyBqdXN0IGEgaGVhZHMgdXAgZm9yIHRoZSB1cGNvbWluZyBX R0xDIGZvciAiQ29BUCBTaW1wbGUgQ29uZ2VzdGlvbiBDb250cm9sL0FkdmFuY2Vk4oCdLg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1jb2NvYS0wMQ0KDQpOb3Rl IHRoYXQgdGhlcmUgaXMgc3RpbGwgc29tZSBkaXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgdG8ga2Vl cCB0aGUgYXBwZW5kaXhlcyBvciBub3QsIGFuZCB0aGF0IHRoZXJlIGlzIHRpbWUgdG8gZ2V0IG90 aGVyIGNvbW1lbnRzIGJlZm9yZSBXR0xDLg0KVGhpcyBkb2N1bWVudCBoYXMgYmVlbiBwcmVzZW50 ZWQgbXVsdGlwbGUgdGltZXMgYW5kIEnigJlkIGxpa2UgdG8gcHJvZ3Jlc3Mgd2l0aCBpdCBzb29u LCBpdOKAmWQgYmUgZ3JlYXQgdG8gaGF2ZSBpdCBieSBQcmFndWUuDQoNClRvIElDQ1JHLCBhcyB5 b3Ugbm93IGFscmVhZHksIHRoaXMgd2FzIHByZXNlbnRlZCBxdWl0ZSBzb21lIHRpbWUgYWdvLCBi ZWxvdyBpcyB0aGUgbGlua3MgdG8gdGhlIHNlc3Npb24gYW5kIHRoZSBzbGlkZXMuDQoNClNlc3Np b246IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL2ljY3JnLmh0bWwNClByZXNl bnRhdGlvbjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRl cy05Mi1pY2NyZy0yLnBkZg0KDQpCZXR3ZWVuIHRoZSB0d28gc2Vzc2lvbnMgdGhlIG1haW4gZGlm ZmVyZW5jZSBpcyB0aGUgYWRkaXRpb24gb2YgdGhlIGFwcGVuZGl4ZXM6DQpodHRwczovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNvcmUtY29jb2EtMDEudHh0DQoNCkNp YW8hDQotIC0gSmFpbWUgSmltw6luZXoNCg== --_000_623D63BAFCEA411CB0C003EF4978FA47ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgQ29SRSBXRywNCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPnRoaXMgaXMganVzdCBh IGhlYWRzIHVwIGZvciB0aGUgdXBjb21pbmcgV0dMQyBmb3IgJnF1b3Q7Q29BUCBTaW1wbGUgQ29u Z2VzdGlvbiBDb250cm9sL0FkdmFuY2Vk4oCdLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWNvY29h LTAxIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl LWNvY29hLTAxPC9hPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tm90ZSB0aGF0IHRoZXJlIGlzIHN0aWxsIHNvbWUgZGlzY3Vz c2lvbiBhYm91dCB3aGV0aGVyIHRvIGtlZXAgdGhlIGFwcGVuZGl4ZXMgb3Igbm90LCBhbmQgdGhh dCB0aGVyZSBpcyB0aW1lIHRvIGdldCBvdGhlciBjb21tZW50cyBiZWZvcmUgV0dMQy4mbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhpcyBkb2N1bWVudCBoYXMgYmVlbiBwcmVzZW50ZWQgbXVs dGlwbGUgdGltZXMgYW5kIEnigJlkIGxpa2UgdG8gcHJvZ3Jlc3Mgd2l0aCBpdCBzb29uLCBpdOKA mWQgYmUgZ3JlYXQgdG8gaGF2ZSBpdCBieSBQcmFndWUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UbyBJQ0NSRywgYXMgeW91 IG5vdyBhbHJlYWR5LCB0aGlzIHdhcyBwcmVzZW50ZWQgcXVpdGUgc29tZSB0aW1lIGFnbywgYmVs b3cgaXMgdGhlIGxpbmtzIHRvIHRoZSBzZXNzaW9uIGFuZCB0aGUgc2xpZGVzLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U2Vzc2lvbjom bmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9pY2NyZy5o dG1sIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9pY2NyZy5o dG1sPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QcmVzZW50YXRpb246Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRlcy05Mi1pY2Ny Zy0yLnBkZiIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xp ZGVzL3NsaWRlcy05Mi1pY2NyZy0yLnBkZjwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJldHdlZW4gdGhlIHR3byBzZXNz aW9ucyB0aGUgbWFpbiBkaWZmZXJlbmNlIGlzIHRoZSBhZGRpdGlvbiBvZiB0aGUgYXBwZW5kaXhl czo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLWNvY29hLTAxLnR4dCIgY2xhc3M9IiI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jb3JlLWNvY29hLTAxLnR4 dDwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkNpYW8hPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNz PSIiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KLSAtIEphaW1lIEpp bcOpbmV6PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_623D63BAFCEA411CB0C003EF4978FA47ericssoncom_-- From nobody Thu Apr 13 18:14: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 B13A81242EA for ; Thu, 13 Apr 2017 18:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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=bobbriscoe.net 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 K0JXfgiMjMTm for ; Thu, 13 Apr 2017 18:14:03 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 01F5B127599 for ; Thu, 13 Apr 2017 18:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gc7MeMQpYj4jvmTaWHujPbMjUcY/P8vvFWDBY5BqSRc=; b=snBN3eT7d9i9cPeOmYvtDgxiN8 Cs5xm9DdEmqTjw4sMgrfUe5FiHu5vbwBrcSLeloJRWoT9IKG3Nbi40nMJdklP12yzHPWVhnQv5S3I 1kJ50f38r3QLCmF5yMIfAGWUkrVL57b2Yf8eBtIaQxHy4HHQ1tYBhz4tGeykVlKf0Qy8ua9P7rRjI G8sgtRgaT5ZB3j2yOIysxlRHta+F8ffeJZXcHrvt4Ts1F4Bmij2SxoS9RldSX9HRGfT+VDGCfBtSP ItQKGWfrnqs+9yfrbsB9i2Pvc9Jbp+JWLpG8fbikBV75oJOHje5lrVTK2sWS/JQeNKqYPA9f5X1mw W2VMgGSg==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:38728 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cypoF-0000l3-Jt; Fri, 14 Apr 2017 02:13:59 +0100 To: "Black, David" References: <3d53f6a4-697b-0c7a-8c71-524890312beb@bobbriscoe.net> <5a4e46a0-bde7-8de5-f6a3-354f06fd9058@bobbriscoe.net> Cc: "tcpm@ietf.org" , marcelo bagnulo braun From: Bob Briscoe Message-ID: <94ff22d6-69b3-164a-8bdb-07149f3e58b3@bobbriscoe.net> Date: Fri, 14 Apr 2017 02:13:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5a4e46a0-bde7-8de5-f6a3-354f06fd9058@bobbriscoe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black) 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, 14 Apr 2017 01:14:06 -0000 David, I hope you will find that I have addressed all your concerns - so at least you will be able to understand it now. The draft is now unexpired. I have also addressed all the points in Mirja's review (some intersecting with your points). You will see that it's actually turned into quite a major re-write. The diff is nearly total, mainly cos I was turning Spanglish into English as I went (Marcelo, it was quite understandable, but just not quite how a native English speaker would say it). However, I have changed technical points in a few places too - the more one thinks about this, the more depth one finds. I just noticed I missed one of your nits (shortening the definition of Retransmission), which I have already fixed in my local copy of the xml for the next rev. Bob On 08/04/17 01:11, Bob Briscoe wrote: > David, > > On 2) I intend to replace the whole of "3.1 Network behaviour" with > the following, which calls out the cases explicitly: > > Previously RFC3168 required the sender to set not-ECT on certain TCP > control packets. Some readers might have erroneously interpreted this > aspect of RFC3168 as a requirement for firewalls, intrusion detection > systems, etc. to check and enforce this behaviour. Now that the > present experimental specification allows TCP senders to set ECT on > all TCP packets (control and data), it needs to be clear that a > firewall (or any network node) SHOULD NOT treat any ECT packet > differently dependent on what type of TCP packet it is. > > One potential exception is envisaged, otherwise the previous sentence > could have said "MUST NOT" rather than "SHOULD NOT". The exception > allows a security function that has detected an ongoing attack to drop > more ECT marked SYNs than not-ECT marked SYNs. Such a policy SHOULD > NOT be applied routinely. It SHOULD only be applied if an attack is > detected, and then only if it is determined that the ECT capability is > intensifying the attack. > > > Bob > > On 07/04/17 23:33, Black, David wrote: >> Bob, >> >> Two comments: >> >> 1) I'll wait for new text before commenting further on Accurate ECN >> vs. vanilla RFC 3168 ECN. The current text left me somewhat >> confused, and the summary of changes from RFC 3168 will almost >> certainly help. >> >> 2) On network node treatment of ECT, RFC 3168 is brief, e.g. (Section >> 5, top of p.7): >> >> The CE codepoint '11' is set by a router to indicate congestion to >> the end nodes. >> >> One wants to avoid text that could be read as modifying that sentence >> by adding possible exceptions for TCP control packets and/or >> retransmissions. >> >>> [BB] Unfortunately, RFC3168 does not specify anything about network >>> node >>> forwarding behaviour wrt ECT. So some firewall policies could have >>> decided to block any TCP control packets that contravene RFC3168. >>> That's >>> why we wrote this section. >> If "firewalls" is what was meant, use that word ;-) ... or as you >> write ... >> >>> However I admit that, by not explaining that DPI was the problem we >>> were >>> trying to solve, rather than removing any ambiguity that might have >>> been >>> interpreted as a need for DPI. We'll fix this. >> In doing so, please keep in mind that in this draft, discussion of >> forwarding and dropping behavior is implicitly about router queue >> management, not middlebox access control (e.g., based on DPI), so >> access control has to be called out explicitly when that is what is >> meant. >> >> Thanks, --David >> > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Tue Apr 18 02:40: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 C9A16129A91 for ; Tue, 18 Apr 2017 02:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 raB1Vz7p7fbi for ; Tue, 18 Apr 2017 02:40:54 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 9CE54129A9B for ; Tue, 18 Apr 2017 02:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:Cc:References:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oab7e+t0iJTpcrUZWJO7IL9U7oqqI7IhE8Sdc6ime68=; b=8nkP7YSrgCzZdZdFB3BMXHkZF prM57EgLNREaK4J0HLxQ0T/ofjZN7fLNTYI0/F1urIY0cHUEAvAZFdmhpKaBkn7iOBPNfuxsYQwr6 pMncfDNufrIOBe3pHNzR6RzpwrNrlqBtyAWrV8lJa8BXqoHoCL+RWIBxLjtfda0vUQo3DJW34F+Km WR651qUgRigbZnIAOOkZBfUKQiDJPvyuI8ihKqqwg5kJaK9MlBCm6W51+oFCfLIM71Z9i+aloxQOU U0tENYawCdDU00UorDTVaPK3Wv1ftBTKeMpcgHUSUj3nanp47yYqeIiL8MuK9ch0WDk76LHz8rzPZ oWErMJcQg==; Received: from 188.6.208.46.dyn.plus.net ([46.208.6.188]:44628 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d0Pcx-0006XZ-Dm; Tue, 18 Apr 2017 10:40:51 +0100 To: "Black, David" , "tcpm@ietf.org" , Mirja Kuehlewind References: <3d53f6a4-697b-0c7a-8c71-524890312beb@bobbriscoe.net> <5a4e46a0-bde7-8de5-f6a3-354f06fd9058@bobbriscoe.net> <94ff22d6-69b3-164a-8bdb-07149f3e58b3@bobbriscoe.net> From: Bob Briscoe Message-ID: <9796d961-292e-e257-a2d8-c0321f61b31a@bobbriscoe.net> Date: Tue, 18 Apr 2017 10:40:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <94ff22d6-69b3-164a-8bdb-07149f3e58b3@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------E7B35680930C707647B26088" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black) 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, 18 Apr 2017 09:40:57 -0000 This is a multi-part message in MIME format. --------------E7B35680930C707647B26088 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit David, Mirja, list, Thanks again for your reviews of the -00. I've been busy over the w/e after thinking more deeply about some of your comments and after realizing that RFC3168 contained an assumption that a single pure ACK implies that all other packets in that direction are pure ACKs, which is not true in general. We've produced another rev (draft-bagnulo-tcpm-generalized-ecn-02 ). This is a general invitation for anyone on the list, including you two, to review this again, so we can ask for an informed adoption call. We need people with the following expertise: * TCP hijacking and DoS/flooding attacks * Specific TCP implementations (Linux, FreeBSD, iOS, Windows, etc). * All the common variants of TCP We have identified clearly where decisions are needed. As well as where more measurements are needed. Main changes: * Moved more discursive text from S.3 (Spec) to S.5 (Arguments against RFCs) * Major changes to Pure ACK sections and the reliability argument, to address Mirja's arguments better, and to separately address cwnd response (required) and ACK-rate response (optional but not required). * Referred to Network Behaviour in ecn-experimentation, rather than repeating it. * Fixed description of window probe. * Recommended RFC 5961, which gives much stronger packet validity checks for retransmissions, RSTs & FINs. Cheers Bob On 14/04/17 02:13, Bob Briscoe wrote: > David, > > I hope you will find that I have addressed all your concerns - so at > least you will be able to understand it now. > The draft is now unexpired. > > I have also addressed all the points in Mirja's review (some > intersecting with your points). > > You will see that it's actually turned into quite a major re-write. > The diff is nearly total, mainly cos I was turning Spanglish into > English as I went (Marcelo, it was quite understandable, but just not > quite how a native English speaker would say it). > > However, I have changed technical points in a few places too - the > more one thinks about this, the more depth one finds. > > I just noticed I missed one of your nits (shortening the definition of > Retransmission), which I have already fixed in my local copy of the > xml for the next rev. > > > > Bob > > > On 08/04/17 01:11, Bob Briscoe wrote: >> David, >> >> On 2) I intend to replace the whole of "3.1 Network behaviour" with >> the following, which calls out the cases explicitly: >> >> Previously RFC3168 required the sender to set not-ECT on certain TCP >> control packets. Some readers might have erroneously interpreted this >> aspect of RFC3168 as a requirement for firewalls, intrusion detection >> systems, etc. to check and enforce this behaviour. Now that the >> present experimental specification allows TCP senders to set ECT on >> all TCP packets (control and data), it needs to be clear that a >> firewall (or any network node) SHOULD NOT treat any ECT packet >> differently dependent on what type of TCP packet it is. >> >> One potential exception is envisaged, otherwise the previous sentence >> could have said "MUST NOT" rather than "SHOULD NOT". The exception >> allows a security function that has detected an ongoing attack to >> drop more ECT marked SYNs than not-ECT marked SYNs. Such a policy >> SHOULD NOT be applied routinely. It SHOULD only be applied if an >> attack is detected, and then only if it is determined that the ECT >> capability is intensifying the attack. >> >> >> Bob >> >> On 07/04/17 23:33, Black, David wrote: >>> Bob, >>> >>> Two comments: >>> >>> 1) I'll wait for new text before commenting further on Accurate ECN >>> vs. vanilla RFC 3168 ECN. The current text left me somewhat >>> confused, and the summary of changes from RFC 3168 will almost >>> certainly help. >>> >>> 2) On network node treatment of ECT, RFC 3168 is brief, e.g. >>> (Section 5, top of p.7): >>> >>> The CE codepoint '11' is set by a router to indicate congestion to >>> the end nodes. >>> >>> One wants to avoid text that could be read as modifying that >>> sentence by adding possible exceptions for TCP control packets >>> and/or retransmissions. >>> >>>> [BB] Unfortunately, RFC3168 does not specify anything about network >>>> node >>>> forwarding behaviour wrt ECT. So some firewall policies could have >>>> decided to block any TCP control packets that contravene RFC3168. >>>> That's >>>> why we wrote this section. >>> If "firewalls" is what was meant, use that word ;-) ... or as you >>> write ... >>> >>>> However I admit that, by not explaining that DPI was the problem we >>>> were >>>> trying to solve, rather than removing any ambiguity that might have >>>> been >>>> interpreted as a need for DPI. We'll fix this. >>> In doing so, please keep in mind that in this draft, discussion of >>> forwarding and dropping behavior is implicitly about router queue >>> management, not middlebox access control (e.g., based on DPI), so >>> access control has to be called out explicitly when that is what is >>> meant. >>> >>> Thanks, --David >>> >> >> > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------E7B35680930C707647B26088 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit David, Mirja, list,

Thanks again for your reviews of the -00. I've been busy over the w/e after thinking more deeply about some of your comments and after realizing that RFC3168 contained an assumption that a single pure ACK implies that all other packets in that direction are pure ACKs, which is not true in general.

We've produced another rev (draft-bagnulo-tcpm-generalized-ecn-02).

This is a general invitation for anyone on the list, including you two, to review this again, so we can ask for an informed adoption call.

We need people with the following expertise:
* TCP hijacking and DoS/flooding attacks
* Specific TCP implementations (Linux, FreeBSD, iOS, Windows, etc).
* All the common variants of TCP

We have identified clearly where decisions are needed.
As well as where more measurements are needed.

Main changes:
* Moved more discursive text from S.3 (Spec) to S.5 (Arguments against RFCs)
* Major changes to Pure ACK sections and the reliability argument, to address Mirja's arguments better, and to separately address cwnd response (required) and ACK-rate response (optional but not required).
* Referred to Network Behaviour in ecn-experimentation, rather than repeating it.
* Fixed description of window probe.
* Recommended RFC 5961, which gives much stronger packet validity checks for retransmissions, RSTs & FINs.

Cheers


Bob


On 14/04/17 02:13, Bob Briscoe wrote:
David,

I hope you will find that I have addressed all your concerns - so at least you will be able to understand it now.
The draft is now unexpired.

I have also addressed all the points in Mirja's review (some intersecting with your points).

You will see that it's actually turned into quite a major re-write. The diff is nearly total, mainly cos I was turning Spanglish into English as I went (Marcelo, it was quite understandable, but just not quite how a native English speaker would say it).

However, I have changed technical points in a few places too - the more one thinks about this, the more depth one finds.

I just noticed I missed one of your nits (shortening the definition of Retransmission), which I have already fixed in my local copy of the xml for the next rev.



Bob


On 08/04/17 01:11, Bob Briscoe wrote:
David,

On 2) I intend to replace the whole of "3.1 Network behaviour" with the following, which calls out the cases explicitly:

Previously RFC3168 required the sender to set not-ECT on certain TCP control packets. Some readers might have erroneously interpreted this aspect of RFC3168 as a requirement for firewalls, intrusion detection systems, etc. to check and enforce this behaviour. Now that the present experimental specification allows TCP senders to set ECT on all TCP packets (control and data), it needs to be clear that a firewall (or any network node) SHOULD NOT treat any ECT packet differently dependent on what type of TCP packet it is.

One potential exception is envisaged, otherwise the previous sentence could have said "MUST NOT" rather than "SHOULD NOT". The exception allows a security function that has detected an ongoing attack to drop more ECT marked SYNs than not-ECT marked SYNs. Such a policy SHOULD NOT be applied routinely. It SHOULD only be applied if an attack is detected, and then only if it is determined that the ECT capability is intensifying the attack.


Bob

On 07/04/17 23:33, Black, David wrote:
Bob,

Two comments:

1) I'll wait for new text before commenting further on Accurate ECN vs. vanilla RFC 3168 ECN.  The current text left me somewhat confused, and the summary of changes from RFC 3168 will almost certainly help.

2) On network node treatment of ECT, RFC 3168 is brief, e.g. (Section 5, top of p.7):

    The CE codepoint '11' is set by a router to indicate congestion to
    the end nodes.

One wants to avoid text that could be read as modifying that sentence by adding possible exceptions for TCP control packets and/or retransmissions.

[BB] Unfortunately, RFC3168 does not specify anything about network node
forwarding behaviour wrt ECT. So some firewall policies could have
decided to block any TCP control packets that contravene RFC3168. That's
why we wrote this section.
If "firewalls" is what was meant, use that word ;-) ... or as you write ...

However I admit that, by not explaining that DPI was the problem we were
trying to solve, rather than removing any ambiguity that might have been
interpreted as a need for DPI. We'll fix this.
In doing so, please keep in mind that in this draft, discussion of forwarding  and dropping behavior is implicitly about router queue management, not middlebox access control (e.g., based on DPI), so access control has to be called out explicitly when that is what is meant.

Thanks, --David 





-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------E7B35680930C707647B26088-- From nobody Wed Apr 19 23:42:47 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 4B00E12EB1C for ; Wed, 19 Apr 2017 23:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 YCkVQDkDwGRx for ; Wed, 19 Apr 2017 23:42:43 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 36D59127ABE for ; Wed, 19 Apr 2017 23:42:43 -0700 (PDT) X-AuditID: c1b4fb2d-88bff70000004c5d-fc-58f858608d08 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 54.38.19549.06858F85; Thu, 20 Apr 2017 08:42:41 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.339.0; Thu, 20 Apr 2017 08:42:39 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lt+4/WR3iz0sKBaeJhKRTKh+wDB/INhM7+8qyKH4KuE=; b=lxrWT/mCZASXCctRSXvDzjZfvK9whCyP4llRXfhsHg7reNQoQ8jgDtjWR8R0uylSora2Uj2yeWlx89IC23r0tSoYigkQYo1bfDvQgCkUPHgeusoei9tOgRFRssa2fFjlXZBOoksSKVFi7qpBEzRDNBgSdvLNEEvLDmsHnsTTw5Q= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Thu, 20 Apr 2017 06:42:39 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0%15]) with mapi id 15.01.1061.005; Thu, 20 Apr 2017 06:42:39 +0000 From: Ingemar Johansson S To: "tcpm@ietf.org" Thread-Topic: slowstart after idle question Thread-Index: AdK5nxhjv+VuMbRUSMuzc2ftLD14pg== Date: Thu, 20 Apr 2017 06:42:38 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.95] x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:fQSVanc5So3wxHHAePyB8fXqMjjkvUeCXeDrm/+bfZ0r/aXngpxIu1ClmqB+lpsZDOBhtZAsOl3yUL7ln6KJ/o3+IXa4qb6/geZNzNw/UciMIngna0APX2Q8pNeKPmPV6M2jqrzVbUxchZm7zv1MDf3AsKi3X7M5lSvcboWwfcAroiFxNvu+U8cvsV38XxuOnhT6a46po3n/qWxbAAr0n3pjqXtRh+J5cy5WvqZUncdd7qj+v/KLoOJcGDYOrMpiUWEUXeybe7r0TY1A/eMpTK0N2PPaqXaVYFlFpHkIny9dwdP1NFDrq0R77GUr64VThXYWi2rnIb/njniSi9WR0g== x-ms-office365-filtering-correlation-id: 44d90f81-4b68-40be-eb2f-08d487b87017 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DB4PR07MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39850400002)(39840400002)(39860400002)(39450400003)(39410400002)(2501003)(6916009)(7696004)(33656002)(7736002)(74316002)(5250100002)(7906003)(54356999)(50986999)(5630700001)(189998001)(5660300001)(2351001)(1730700003)(81166006)(8676002)(86362001)(3480700004)(9326002)(8936002)(38730400002)(6116002)(790700001)(102836003)(110136004)(606005)(19609705001)(6436002)(66066001)(99286003)(3846002)(55016002)(236005)(9686003)(53936002)(6306002)(54896002)(3280700002)(6506006)(5640700003)(25786009)(2900100001)(3660700001)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB34868321AFBE4D762C18FB3C21B0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 06:42:38.8243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGOffezbvh4Dg138woFvaHOssKiZIywhArFJIaRuXSq86Pqfc6 yZAyyD82STQ1tiWaNhQVEj+yD8ts+R2ipIWYH0WGpoVC+BHKyusx2H/P+b3Pc87zwmFpZbnE m9Xpszher01VSeWMRfNMrdZq1jQHjWbF0bb+SioUhdtsf6goFCMPiedSddkcf+BErDzJ0fvB JWMs5Ialc5DOQ7+CTUjGAj4CzbZaxoTkrBI3Iigc76bFgRL3Idh4lyMOGHyPhumNPJq4HlBQ uLhIkcNXBPVPHRIxIsUhUGdfRaL2wPugYXppU7OsO94PA7MBBPvD70kHI2IPHAjfy6NFzGBf GO2Z2koqcAw0femUihrh3TC9OsWImsZeMD5TSZHWGGyvhmiiPeHHN7GBfNNfgGCp4tO2aS8Y O39u9QRcQEPdcotUfBjweVjIDye8EMGb7kaacB28z08g2ctQ2mOSEs8QBesj5u2sD3RZwwgf kUBvde3W7u7YGyZHjYhoH5ibeC0hrdNh3NJJkc3coN8yw5B7ouDjQFYR8rU67WZ1SlidEoQH wlhZqZRof6ipWqCJVoPZYWec+SPkUo88BU4Q0hIPHQ7keF2cIKTrA/VcVjPa/DNvW9fVz1HD wik7wixSuSpi01Y1Sok2W8hJsyNgaZWH4oxuEynitTk3OT79Gm9I5QQ72sUyKi9FaMewRokT tVlcCsdlcPz/KcXKvPPQ44pbsg6Z8WHy7ZYLwSklCW7V0xczo1z97safKzfHxZTN76kKejl0 JTpBnTyrGDakX5W0smGfi6rUbjukLXckpweLzz5aaTK4Lcv7aF/7fLWji7euBew0xz6ZiEwy RRyrSS06yXRH3vdva/+7tGLIvXS948VwcnFE+9zo8cwSWa6KEZK0QX40L2j/Ac2g03MvAwAA Archived-At: Subject: [tcpm] slowstart after idle question 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, 20 Apr 2017 06:42:45 -0000 --_000_DB4PR07MB34868321AFBE4D762C18FB3C21B0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Possibly a question that would fit better in a Linux net dev forum but anyw= ay.. I have one short question. Is slow start after idle generally disabled (net= .ipv4.tcp_slow_start_after_idle=3D0) for instance for HTTP video streaming= ?. I can imagine that there are some benefits with avoiding the CWND decrease = in idle periods. Of course there is a problem that a large amount of data is transmitted whe= n new objects are sent to the TCP sockets (shown on page 12 in https://www.= ietf.org/proceedings/96/slides/slides-96-iccrg-1.pdf ), but packet pacing c= an solve this issue. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB34868321AFBE4D762C18FB3C21B0DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Possibly a question that would fit better in a Linux= net dev forum but anyway..

 

I have one short question. Is slow start after idle = generally disabled (net.ipv4.tcp_slow_start_after_idle=3D0) for instance &n= bsp;for HTTP video streaming ?.

 

I can imagine that there are some benefits with avoi= ding the CWND decrease in idle periods.

Of course there is a problem that a large amount of = data is transmitted when new objects are sent to the TCP sockets (shown on = page 12 in https://www.ietf.org/proceedings/96/slides/slides-96-iccrg-1.pdf ), b= ut packet pacing can solve this issue.

 

 

/Ingemar

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB34868321AFBE4D762C18FB3C21B0DB4PR07MB348eurprd_-- From nobody Wed Apr 19 23:43: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 AA14B127ABE for ; Wed, 19 Apr 2017 23:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 yQUV1trsxRrg for ; Wed, 19 Apr 2017 23:42:45 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 DD22912EB15 for ; Wed, 19 Apr 2017 23:42:43 -0700 (PDT) X-AuditID: c1b4fb2d-89fff70000004c5d-04-58f858618ac2 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id D5.38.19549.16858F85; Thu, 20 Apr 2017 08:42:41 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.339.0; Thu, 20 Apr 2017 08:42:41 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lt+4/WR3iz0sKBaeJhKRTKh+wDB/INhM7+8qyKH4KuE=; b=lxrWT/mCZASXCctRSXvDzjZfvK9whCyP4llRXfhsHg7reNQoQ8jgDtjWR8R0uylSora2Uj2yeWlx89IC23r0tSoYigkQYo1bfDvQgCkUPHgeusoei9tOgRFRssa2fFjlXZBOoksSKVFi7qpBEzRDNBgSdvLNEEvLDmsHnsTTw5Q= Received: from AM3PR07MB337.eurprd07.prod.outlook.com (10.242.109.17) by AM3PR07MB337.eurprd07.prod.outlook.com (10.242.109.17) with ShadowRedundancy id 15.1.1047.6; Thu, 20 Apr 2017 06:42:40 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by AM3PR07MB337.eurprd07.prod.outlook.com (10.242.109.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Thu, 20 Apr 2017 06:42:39 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0%15]) with mapi id 15.01.1061.005; Thu, 20 Apr 2017 06:42:39 +0000 From: Ingemar Johansson S To: "tcpm@ietf.org" Thread-Topic: slowstart after idle question Thread-Index: AdK5nxhjv+VuMbRUSMuzc2ftLD14pg== Date: Thu, 20 Apr 2017 06:42:38 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.95] x-microsoft-exchange-diagnostics: 1; AM3PR07MB337; 7:wi2SrMrnkSrOvaf1H4UwiXGmTCM3HPiwAA+lMDK2q2+D/Z9LEi0JP+hRsbh3/Pp8dTWk3jIqEjBREsVs3v2j4JVhgYM0H+NXgfmA8I8mBrKgSi0ly9+oLkP2DWxOJbSam318MKUbJw1OaKos55fo62e9DO6pFsE8jMlES5IrfHgSQ5ixB8K+213wvxZwZqINcHFpM3U6CLboVnDYmXFons3d8a4AQa1XLdqUwJWQq8N0vYa0FfZPC3WcmkGms5mjqEfZ+goEOcyF4WWye90tPIr3JhB9hfrgpuZ21NqiFBg8EF6E6vm4TsvAt8EjX5TjEOgzRJgO1RSKCleAziDJbw== x-ms-office365-filtering-correlation-id: 44d90f81-4b68-40be-eb2f-08d487b87017 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB337; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(6072148); SRVR:AM3PR07MB337; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB337; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400002)(39400400002)(39410400002)(39840400002)(39860400002)(39450400003)(3480700004)(6436002)(5660300001)(6506006)(6916009)(2501003)(33656002)(81166006)(3660700001)(3280700002)(8936002)(86362001)(19609705001)(1730700003)(5250100002)(8676002)(74316002)(606005)(7906003)(2906002)(5630700001)(54896002)(66066001)(50986999)(2900100001)(6116002)(102836003)(7696004)(9326002)(5640700003)(7736002)(38730400002)(3846002)(189998001)(25786009)(790700001)(9686003)(110136004)(99286003)(54356999)(53936002)(55016002)(6306002)(2351001)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB337; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB34868321AFBE4D762C18FB3C21B0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 06:42:38.8243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB337 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURzGO/febdfh4jgV/84FsnAfNFdalJGEfkiFyvxQMFTK4a46cpvs LkkpEHvzpTLfwK1Qg2WkkSmmSSlzyXSGmWUllq7I0liSZWWvI693gd9+/+c8zzn/Bw5NShsF MlpnMDMmgyZfIRRTFnVPZLRG/UO9ZeRsXFy3q4lIQCk2208iDaWL47VMvq6QMW3enSXO8w49 ERVMxh+32EfJErSwvQL50YC3QUNNNVmBxLQUtyNo6h0Q8MMwgjp3A8ENFL5AgvtPic/mQtAy fpHgh3oCSk/d9mXeIGi94xVwNwtxPNxwLCOOg/BGaHMvrjBNB2IljMxt4uUoWJr2UpwchFXw 7spBTqZwBEw4Z1aTEpwOHa/tQo4R3gDu5RmKYxKHwNRsE8F3wGC7P0byHAwf3npX10G4EsFi 43OfKRzK7R9XlwZcSUJf9aSIexjwfvCcSeE9J+Hht2YRzzoY+jLoy2ZAnbNCyGfHCKhyPkB8 Vg6D1j2856kAhm5FcByIZTA9UY54lsP8qz4Bv7QRpix2gi8WAC7LLHUJKa1r+ljX2KxrbLyu gsn6OiHPUdBy1UPyHA0NXge1Vm9GolYUzDIsq8+N3apiTLpsljUaVAbG3IlWfs1A1+/ou6jN k+hAmEYKf0mWflktFWgK2SK9AwFNKoIkSboVSaLVFBUzJuMR07F8hnWgMJpShEgS+h+rpThX Y2aOMkwBY/p/StB+shK0XlhLjKXWVxUTwS8uj38qM+eEu2KmDR02vzJxZ1+N/PsCeShRSy5N ne8M1SrClMpadf+9ruRC8ua+l7OZpaPDyV9jJ+LD53Wpj2p2dsx5eg+/PydvE30+0f63mJB1 E/p1GUZPQFKmtkqi9b8WmuM8sGPX3rTrcm3Xr4LTz7J7FBSbp4mJJE2s5h/4kav2MQMAAA== Archived-At: Subject: [tcpm] slowstart after idle question 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, 20 Apr 2017 06:42:47 -0000 --_000_DB4PR07MB34868321AFBE4D762C18FB3C21B0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Possibly a question that would fit better in a Linux net dev forum but anyw= ay.. I have one short question. Is slow start after idle generally disabled (net= .ipv4.tcp_slow_start_after_idle=3D0) for instance for HTTP video streaming= ?. I can imagine that there are some benefits with avoiding the CWND decrease = in idle periods. Of course there is a problem that a large amount of data is transmitted whe= n new objects are sent to the TCP sockets (shown on page 12 in https://www.= ietf.org/proceedings/96/slides/slides-96-iccrg-1.pdf ), but packet pacing c= an solve this issue. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB34868321AFBE4D762C18FB3C21B0DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Possibly a question that would fit better in a Linux= net dev forum but anyway..

 

I have one short question. Is slow start after idle = generally disabled (net.ipv4.tcp_slow_start_after_idle=3D0) for instance &n= bsp;for HTTP video streaming ?.

 

I can imagine that there are some benefits with avoi= ding the CWND decrease in idle periods.

Of course there is a problem that a large amount of = data is transmitted when new objects are sent to the TCP sockets (shown on = page 12 in https://www.ietf.org/proceedings/96/slides/slides-96-iccrg-1.pdf ), b= ut packet pacing can solve this issue.

 

 

/Ingemar

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB34868321AFBE4D762C18FB3C21B0DB4PR07MB348eurprd_-- From nobody Thu Apr 20 02: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 AC75112EBDF for ; Thu, 20 Apr 2017 02:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 XW2AJGTKBDBD for ; Thu, 20 Apr 2017 02:38:29 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0132.outbound.protection.outlook.com [104.47.0.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903D412EBDA for ; Thu, 20 Apr 2017 02:38:28 -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=C+SB1yeCzOr3S4Ih5UAQdYgqpL+9cZs+wKSQi1UFeBw=; b=N7SkA2iwGJXd0BXumAsxvHztIELIC8Mo4VjpM8c7A8AEm2WWxJU/DmJxacwJeA+kvZVXJc/MmrJ9+sKaeEQOwsDibJULfOq+KPcQIJDLLJEUxVT9b/uUOYkPkIZlD8NjU4JVa3ofcF7iUNAFPTevaXpOYcfVAqV/QqlB5ieuh+w= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2546.eurprd07.prod.outlook.com (10.173.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Thu, 20 Apr 2017 09:38:26 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1047.008; Thu, 20 Apr 2017 09:38:26 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" Thread-Topic: TCPM minutes (draft) ... Thread-Index: AdK5uUxWn9RbX5NOQZi9/36lHZRZwA== Date: Thu, 20 Apr 2017 09:38:26 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.29] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2546; 7:VjZbgz+VaMOeL0N3rjbD4eXVmIfdV0C/xPXBmf0inX9CIUTcOl5DdAcieCgji1ot+D8XSAfNQROTd8c6gzhROVDB8uZyhM8Sa1a1BwyKxZUZ+hsx5LOqZ6dLS77QgmzIAyqbq7Z7LC5U8r0cCblqtk7RXNK2//Oci+k+A4cYk6PAtRjoRtLkDLRSZ2wfYtsBhCG1/VGwWr3NvSUiGjI87Sn9VDzN/dqZNBUYdZ6pjXAM6VQ5Hr+Wk7KXvJLq7lud8k1qIhYDAzWZj96QNdsg+IPqygszWwWhn4KduBZnXWwvY3/iU+IPhYmX6WGtBxbevslc/PQlGVDu+xy9Ykr1Xg== x-ms-office365-filtering-correlation-id: 79ce6a11-57d5-457e-cad1-08d487d0febd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2546; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:AM5PR0701MB2546; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2546; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39860400002)(39850400002)(39400400002)(39410400002)(66654002)(38730400002)(2900100001)(110136004)(5640700003)(606005)(7906003)(86362001)(25786009)(5630700001)(54356999)(50986999)(7736002)(77096006)(66066001)(6436002)(189998001)(6506006)(33656002)(2501003)(2906002)(5660300001)(122556002)(558084003)(7696004)(6916009)(102836003)(3846002)(790700001)(6116002)(6306002)(54896002)(53936002)(9686003)(2351001)(8936002)(74316002)(81166006)(1730700003)(236005)(55016002)(8676002)(99286003)(3280700002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2546; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB254737400FB6669B76A7E022931B0AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 09:38:26.1099 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2546 Archived-At: Subject: [tcpm] TCPM minutes (draft) ... 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, 20 Apr 2017 09:38:32 -0000 --_000_AM5PR0701MB254737400FB6669B76A7E022931B0AM5PR0701MB2547_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ... can be found here: https://www.ietf.org/proceedings/98/minutes/minutes-= 98-tcpm-01.txt If there are suggestions or comments, please let the chairs know. Many thanks to Gorry, who has taken excellent notes (as usually) Michael --_000_AM5PR0701MB254737400FB6669B76A7E022931B0AM5PR0701MB2547_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

… can be found here: https://www.ietf.org/proceedings/98/minutes/minutes-98-tcpm-01.txt<= o:p>

 

If there are suggestions or comments, please let the= chairs know.

 

Many thanks to Gorry, who has taken excellent notes = (as usually)

 

Michael

 

--_000_AM5PR0701MB254737400FB6669B76A7E022931B0AM5PR0701MB2547_-- From nobody Thu Apr 20 02:54: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 524B712EC4E; Thu, 20 Apr 2017 02:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 zOXj9LRYJPGZ; Thu, 20 Apr 2017 02:54:16 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0109.outbound.protection.outlook.com [104.47.2.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6D612EC51; Thu, 20 Apr 2017 02:54:15 -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=Hpln2btI/a+cqI0UqX5XIwWfdLUVd9jNdE8rXo1O1VU=; b=sfpGmRXK8qY8tYWFvTtZm7FlP8hdxsf4lClhA95u9TcLykvgSBfCMJEeuiQ7ThQY8fSZtdp3Ezb6fwhJdXzW1BPLhO+IzLT5vWLB9IOT1JzFLeJ77VSAkHDgZD+fo7eSERw1uis7cvUOZCtB2k4VmqGHr50pg4WGswv6UKlySGA= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2546.eurprd07.prod.outlook.com (10.173.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Thu, 20 Apr 2017 09:54:13 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1047.008; Thu, 20 Apr 2017 09:54:13 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" Thread-Topic: Shepherd write-up for draft-ietf-tcpm-dctcp-05 Thread-Index: AdK5uzCLm+LcOBzQT5aDLOsPaI+tEg== Date: Thu, 20 Apr 2017 09:54:13 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.29] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2546; 7:mAyovQK6wzu/V84duRyQxSt6IBxwa7w2OE1HndXeVoev73xEB8MPVEccrIqaSEFcF74xKp8D+PIpOiGgwNuyXrfPd/BjIYwYvAjkW4QeyTHRXGIPblxRxvzNN/yf9u4TjygU9iDGTdkKXIoxeA+YQ7fR0TgepkSZyB/WxcdqZQ6MhNFH7s8qhthKYyzVXZctlLSth90G1PU0l3lWpjI75ZJhpGbQKdx7LFlPJwNbcH+lKPeV9VPoaJI7Hny3AL7xH1D+JSJZcvb9WLWcPyks4Y6rLTDLv+zYeFx6O0nX6SuOh1wrxr5JrMwFgnaHaFNwVNivhcFb2o6TwickFK4Vfw== x-ms-office365-filtering-correlation-id: 743bfa44-7be9-42f6-bf43-08d487d3333b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2546; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:AM5PR0701MB2546; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2546; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39840400002)(39860400002)(39450400003)(53754006)(6916009)(7696004)(6116002)(790700001)(102836003)(3846002)(5660300001)(122556002)(3280700002)(230783001)(3660700001)(9686003)(54896002)(6306002)(53936002)(55016002)(8676002)(99286003)(2351001)(81166006)(1730700003)(74316002)(8936002)(86362001)(25786009)(54356999)(50986999)(5630700001)(5640700003)(110136004)(38730400002)(2900100001)(450100002)(2501003)(2906002)(6436002)(7736002)(77096006)(66066001)(4326008)(33656002)(189998001)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2546; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2547570111614BE15A9DC8ED931B0AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 09:54:13.0743 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2546 Archived-At: Subject: [tcpm] Shepherd write-up for draft-ietf-tcpm-dctcp-05 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, 20 Apr 2017 09:54:17 -0000 --_000_AM5PR0701MB2547570111614BE15A9DC8ED931B0AM5PR0701MB2547_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As far as I can see, all WGLC comments for draft-ietf-tcpm-dctcp have been = addressed in -05 and the WGLC can therefore be closed. The current draft for my shepherd write-up can be found at: https://datatra= cker.ietf.org/doc/draft-ietf-tcpm-dctcp/shepherdwriteup/ Unless I should have missed something in my write-up, I plan to submit the = document to the IESG until Sunday. Thanks Michael --_000_AM5PR0701MB2547570111614BE15A9DC8ED931B0AM5PR0701MB2547_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As far as I can see, all WGLC comments for draft-iet= f-tcpm-dctcp have been addressed in -05 and the WGLC can therefore be close= d.

 

The current draft for my shepherd write-up can be fo= und at: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/shepherdwrit= eup/

 

Unless I should have missed something in my write-up= , I plan to submit the document to the IESG until Sunday.

 

Thanks

 

Michael

--_000_AM5PR0701MB2547570111614BE15A9DC8ED931B0AM5PR0701MB2547_-- From nobody Thu Apr 20 10:26: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 0155A129ADC for ; Thu, 20 Apr 2017 10:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 IlkRPvPJ170d for ; Thu, 20 Apr 2017 10:26:48 -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 8E1A7129B26 for ; Thu, 20 Apr 2017 10:26:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3w85QH1YsbzMn7h; Thu, 20 Apr 2017 19:26:47 +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 IOhtVk2ZoGUh; Thu, 20 Apr 2017 19:26:45 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 20 Apr 2017 19:26:45 +0200 (CEST) To: Bob Briscoe References: <3d53f6a4-697b-0c7a-8c71-524890312beb@bobbriscoe.net> <5a4e46a0-bde7-8de5-f6a3-354f06fd9058@bobbriscoe.net> <94ff22d6-69b3-164a-8bdb-07149f3e58b3@bobbriscoe.net> <9796d961-292e-e257-a2d8-c0321f61b31a@bobbriscoe.net> Cc: "Black, David" , "tcpm@ietf.org" , marcelo bagnulo braun From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <0533c69e-617e-fb5d-af97-4a603eb29d8d@tik.ee.ethz.ch> Date: Thu, 20 Apr 2017 19:26:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9796d961-292e-e257-a2d8-c0321f61b31a@bobbriscoe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black) 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, 20 Apr 2017 17:26:56 -0000 Hi Bob, given it seems I spend most of my time these days to worry about different ECN-related RFCs, I've also reviewed this draft (actually only sections 1-4; I may review section 5 at a later point of time but I trust you that you have addressed my previous comments here). Here is my feedback as individual contributor: In general, I'm happy with the spec and the overall draft now. Thanks for the work! It reads very well now. I have a few minor technical comments and some editorial proposals and a proposal to restructure some smaller parts below. So te document is in really good shape and the technical specification is good. So I think that this version is definitely ready for adoption and would like to see an adoption call very soon! Mirja ----------------- High-level, minor technical points: 1) The description of TFO in section 4.2 is not quite correct: "If a TFO initiator has cached that the server supported ECN in the previous connection, it would be safe to set ECT on any data segments it sends before a SYN-ACK returns from the responder (server). Note that there is no space in the SYN-ACK itself (whether classic or AccECN feedback has been negotiated) to include feedback about any CE on data packets. Nonetheless, it is safe to set ECT on data packets within the handshake because any CE-marking on these data segments can be fed back by the responder on the first data segment it sends after the SYN-ACK (or on an additional pure ACK if it has no more data to send)." TFO allows the initiator to send data in the SYN but no additional data packets, and the responder to send the SYN/ACK as well as an IW full of data packets. So I think the problem here goes away. However, accECN actually does feedback information of CE marked data in the SYN/ACK because the SYN/ACK carries the AccECN option that holds this information. 2) Regarding this question in section 3.2.3 "DISCUSSION: An AccECN deployment or an implementation of RFC 3168 that feeds back CE on pure ACKs will be at a disadvantage compared to an RFC 3168 implementation that does not. To solve this, the WG could decide to prohibit setting ECT on pure ACKs unless AccECN has been negotiated." I've checked REF3168 and it does not say anything about handling of pure ACKs that are CE marked because it probably just assumes that that case will never happen. However, implementations may or may not provide feedback. I think I would support to only have pure ACKs ECT marked if AccECN is supported because of this. I also think that losing ACKs is probably less bad that losing any of the other (control) packets that are discussed in this document. So I think this restriction would be okay. 3) This is a suggestion to improve the situation, however it probably needs further discussion: in sect 3.2.1.4 you say that one should still use ECT SYNs even if a connection attempt previously failed. Maybe we can use a smaller time-out in this case...? And now first a couple of comments on the structure: 1) I would move the network behavior in any case AFTER the endpoint behavior spec. Actually I would even propose to have it in a different section (not under 3. Specification) because it actually does not specify anything; it only comments on the current situation. 2) And then you would actually not need a separate subsection for the Endpoint behavior; you could just call section 3 "Specification of Endpoint Behavior" or even "Specification of Sender Behavior" and move the first two paragraphs of section 3.2 to the intro that explains that this mechanism/document only needs to talk about the sender behavior. 3) I would include the text on TFO and IW10 directly into section 3.2.1.3 instead of just giving a reference to a later section. 4) The rationale in section 3.2.6.1 could also go somewhere into section 5 (to keep the spec part as short as possible). At least I think you don't need the whole text here. If you want to keep something you probably only need the second paragraph (and not an own subsection). 5) Maybe have the section on Retransmissions (3.2.7.) earlier before RST, FIN, and Window probe because it seems more "important". But actually I don't think the order matters that much. So this is a minor comment only. 6) The paragraph on SCTP (section 4.1) could go into the intro. And if you then also integrate the TFP and IW10 stuff into section 3.2.1.3, section 4 would actually go away completely. And now a bunch of editorial comments/proposals: 1) I though that it might be good to mention AccECN already in the Intro because that the enabler for the SYN part... 2) section 1.1: OLD "Preventing TCP control packets from obtaining the benefits of ECN would not only expose them to the prevailing level of congestion loss, but it would also stop them from being classified into the low latency (L4S) queue, which would greatly degrade L4S performance." I think this can be phrased more general: NEW "Preventing TCP control packets from obtaining the benefits of ECN would not only expose them to the prevailing level of congestion loss, but it would also put control packet into a different queue with different network treatment, which may also lead to reordering and therefore can greatly degrade TCP performance." 3) section 3.2.1.1: OLD "Accurate ECN (AccECN) feedback [I-D.ietf-tcpm-accurate-ecn] provides two codepoints in the SYN-ACK" NEW "Accurate ECN (AccECN) feedback [I-D.ietf-tcpm-accurate-ecn] provides one flag in the SYN-ACK" I think that's clearer, at least for me. 4) section 3.2.1.2 This sentence is correct but I had to read it twice to make sure it's correct: "Servers that do not support ECN as a whole probably do not need to be recorded separately from non-support of AccECN because, even when a server does not support classic [RFC3168] ECN, there is no performance penalty in always requesting to use it." NEW "Servers that do not support ECN as a whole probably do not need to be recorded separately from non-support of AccECN. Meaning, if AccECN is noted as not supported by the server, the initiator may decide to not mark the SAN as ECT but it still may try to negotiate classic ECN or even AccECN (to quickly detect server upgrades)." 5) section 3.2.1.4: OLD "To expedite connection set-up if, after sending an ECT SYN, the retransmission timer expires, the TCP initiator SHOULD send a SYN with the not-ECT codepoint in the IP header and not attempt to negotiate AccECN. It would make sense to also remove any other experimental fields or options on the SYN, but that will depend on the specification of the other option(s). " I wouldn't make any statements about things that are not in scope of this doc, so I would remove the later part (including fallback for AccECN): NEW "To expedite connection set-up if, after sending an ECT SYN, the retransmission timer expires, the TCP initiator SHOULD send a SYN with the not-ECT codepoint in the IP header." 6) section 3.2.2 says: "In either case no change is required to RFC 5562 or the AccECN specification." It would probably be good to also state in this draft what the procedure is that is described in RFC5562: "When the responder (node B) receives the ECN-Echo packet reporting the Congestion Experienced indication in the SYN/ACK packet, the responder sets the initial congestion window to one segment, instead of two segments as allowed by [RFC2581], or three or four segments allowed by [RFC3390]. As illustrated in Figure 2, if the responder (node B) receives an ECN-Echo packet informing it of a Congestion Experienced indication on its SYN/ACK packet, the responder sends a SYN/ACK packet that is not ECN-Capable, in addition to setting the initial window to one segment. The responder does not advance the send sequence number. The responder also sets the retransmission timer. The responder follows RFC 2988 [RFC2988] in setting the RTO (retransmission timeout)." 7) section 3.2.3: OLD "It MAY also implement AckCC [RFC5690] to regulate the pure ACK rate, but this is not required. Note that, in comparison, [RFC5681] does not require..." NEW "It MAY also implement Acknowledgement Congestion Control (AckCC) [RFC5690] to regulate the pure ACK rate, but this is not required. Note that, in comparison, TCP Congestion Control [RFC5681] does not require..." 8) section 3.2.3: "The question of whether the receiver of pure ACKs is required to feed back any CE marks on them is a matter for the relevant feedback specification ([RFC3168] or [I-D.ietf-tcpm-accurate-ecn]). It is outside the scope of the present specification." However, as mention about I believe that RFC3168 does not say anything about feedback how to handle CE marks of pure ACK because it assumes that this case never occurs. So that might be implementation dependent, so it might be better to spell that out: "[I-D.ietf-tcpm-accurate-ecn] includes handling of control packets. However, [RFC3168] does not specify handling of pure ACKs that are CE mark, so it might be implementation specific if feedback is provided or not." Related to this comment in the same section: "DISCUSSION: Before the AccECN specification is published, a requirement to count CE marks on all packets could be added." I pretty sure that this is what the AccECN draft is doing but I can double check. If not it clearly should be added. Maybe it's not spelled out clearly enough. I'll check! 9) section 3.2.6.1: OLD "The following factors have been considered before deciding whether ECT ought to be allowed on a RST message:" NEW "The following factors have been considered before deciding whether the RST message should be ECT marked:" That's it. So nothing big. Let move on with this draft! On 18.04.2017 11:40, Bob Briscoe wrote: > David, Mirja, list, > > Thanks again for your reviews of the -00. I've been busy over the w/e after > thinking more deeply about some of your comments and after realizing that > RFC3168 contained an assumption that a single pure ACK implies that all other > packets in that direction are pure ACKs, which is not true in general. > > We've produced another rev (draft-bagnulo-tcpm-generalized-ecn-02 > ). > > This is a general invitation for anyone on the list, including you two, to > review this again, so we can ask for an informed adoption call. > > We need people with the following expertise: > * TCP hijacking and DoS/flooding attacks > * Specific TCP implementations (Linux, FreeBSD, iOS, Windows, etc). > * All the common variants of TCP > > We have identified clearly where decisions are needed. > As well as where more measurements are needed. > > Main changes: > * Moved more discursive text from S.3 (Spec) to S.5 (Arguments against RFCs) > * Major changes to Pure ACK sections and the reliability argument, to address > Mirja's arguments better, and to separately address cwnd response (required) > and ACK-rate response (optional but not required). > * Referred to Network Behaviour in ecn-experimentation, rather than repeating > it. > * Fixed description of window probe. > * Recommended RFC 5961, which gives much stronger packet validity checks for > retransmissions, RSTs & FINs. > > Cheers > > > Bob > > > On 14/04/17 02:13, Bob Briscoe wrote: >> David, >> >> I hope you will find that I have addressed all your concerns - so at least >> you will be able to understand it now. >> The draft is now unexpired. >> >> I have also addressed all the points in Mirja's review (some intersecting >> with your points). >> >> You will see that it's actually turned into quite a major re-write. The >> diff is nearly total, mainly cos I was turning Spanglish into English as I >> went (Marcelo, it was quite understandable, but just not quite how a native >> English speaker would say it). >> >> However, I have changed technical points in a few places too - the more one >> thinks about this, the more depth one finds. >> >> I just noticed I missed one of your nits (shortening the definition of >> Retransmission), which I have already fixed in my local copy of the xml for >> the next rev. >> >> >> >> Bob >> >> >> On 08/04/17 01:11, Bob Briscoe wrote: >>> David, >>> >>> On 2) I intend to replace the whole of "3.1 Network behaviour" with the >>> following, which calls out the cases explicitly: >>> >>> Previously RFC3168 required the sender to set not-ECT on certain TCP >>> control packets. Some readers might have erroneously interpreted this >>> aspect of RFC3168 as a requirement for firewalls, intrusion detection >>> systems, etc. to check and enforce this behaviour. Now that the present >>> experimental specification allows TCP senders to set ECT on all TCP >>> packets (control and data), it needs to be clear that a firewall (or any >>> network node) SHOULD NOT treat any ECT packet differently dependent on >>> what type of TCP packet it is. >>> >>> One potential exception is envisaged, otherwise the previous sentence >>> could have said "MUST NOT" rather than "SHOULD NOT". The exception allows >>> a security function that has detected an ongoing attack to drop more ECT >>> marked SYNs than not-ECT marked SYNs. Such a policy SHOULD NOT be applied >>> routinely. It SHOULD only be applied if an attack is detected, and then >>> only if it is determined that the ECT capability is intensifying the attack. >>> >>> >>> Bob >>> >>> On 07/04/17 23:33, Black, David wrote: >>>> Bob, >>>> >>>> Two comments: >>>> >>>> 1) I'll wait for new text before commenting further on Accurate ECN vs. >>>> vanilla RFC 3168 ECN. The current text left me somewhat confused, and >>>> the summary of changes from RFC 3168 will almost certainly help. >>>> >>>> 2) On network node treatment of ECT, RFC 3168 is brief, e.g. (Section 5, >>>> top of p.7): >>>> >>>> The CE codepoint '11' is set by a router to indicate congestion to >>>> the end nodes. >>>> >>>> One wants to avoid text that could be read as modifying that sentence by >>>> adding possible exceptions for TCP control packets and/or retransmissions. >>>> >>>>> [BB] Unfortunately, RFC3168 does not specify anything about network node >>>>> forwarding behaviour wrt ECT. So some firewall policies could have >>>>> decided to block any TCP control packets that contravene RFC3168. That's >>>>> why we wrote this section. >>>> If "firewalls" is what was meant, use that word ;-) ... or as you write ... >>>> >>>>> However I admit that, by not explaining that DPI was the problem we were >>>>> trying to solve, rather than removing any ambiguity that might have been >>>>> interpreted as a need for DPI. We'll fix this. >>>> In doing so, please keep in mind that in this draft, discussion of >>>> forwarding and dropping behavior is implicitly about router queue >>>> management, not middlebox access control (e.g., based on DPI), so access >>>> control has to be called out explicitly when that is what is meant. >>>> >>>> Thanks, --David >>>> >>> >>> >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > From nobody Thu Apr 20 14:27:20 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 B301212E76A for ; Thu, 20 Apr 2017 14:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 tUXXH5P2j8eX for ; Thu, 20 Apr 2017 14:27:17 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2722C12AF77 for ; Thu, 20 Apr 2017 14:27:16 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id r203so68387375oib.3 for ; Thu, 20 Apr 2017 14:27: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:content-transfer-encoding; bh=rn1zEIm4L38qy2CEn5j+XBgVOdCAz8JceVfLXk1hBXs=; b=q0Vjt1eTD0OeDSD4RTLHDS1XYTfBCA/+wH0YaAtGoP4PlVX6Dav26e1iiWJ4nd4gR2 9d5xga9zT2e3bm7BYwLaHlaBN0nPAcc1soKEKCNBxEZd6n3AnCz+oZ99YUEfz7HCsuBF 2FcvLwDi1GrA23SE0RhQlIyUxLJG6oEtzpDXtvVLWPYVyur5xEfvpxXI4M4tmuQoxfZV GjZS8Upe87vp/YWqNMOiuu/5NnImG00Uu80j6tsooBGUEWWIOAxyxVT/U5PJR//KscBV t3LBt6l6+NEcH9o7b2Xot4KYGwh0ocDnU12mKQVTGSScIQKJQWt5O/glK48pKqBrO2Ht /CHQ== 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=rn1zEIm4L38qy2CEn5j+XBgVOdCAz8JceVfLXk1hBXs=; b=A0Zc8Qll3CGjveRORMkgc6zn37ZBqEfl9woNf0KswuzkofdBKbmSLTIlpk+1fvQhtj dMe9L5qNRanY2j0phtdBZ+Nj56A1L0phu/BXKa6BbOxkOaqxxi1l0wfxo5m+PDnZsLRm iAu2labs/pZm8Kx9cJajIL7tfyfruJgwus6tmPi8OnvaB3tllMfRT9KAQsml2K8ABtgw 7zEUGar0qmS/q1ltHZo0H1XQfTci/y3GSW05eA1WmNDoFdOeSTRKlcLDsK5sYam/In/K afWy9KUkQCmgu/aXUl+thasPG+TdE4t+ERwYoS87A7wELTXVqhg/U2eOcXhP2FbA04zh Ub1w== X-Gm-Message-State: AN3rC/7k0cDKY4wfQ8qYdcnScb1hz5yv7pB8hA+bJAPAsT6zS+5fs5o1 qrCtQhE4LoloDHomfBOac1q3F9FfLDJ8 X-Received: by 10.157.57.183 with SMTP id y52mr5511875otb.51.1492723635251; Thu, 20 Apr 2017 14:27:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.56.6 with HTTP; Thu, 20 Apr 2017 14:26:44 -0700 (PDT) In-Reply-To: References: From: Neal Cardwell Date: Thu, 20 Apr 2017 14:26:44 -0700 Message-ID: To: Ingemar Johansson S Cc: "tcpm@ietf.org" , Yuchung Cheng Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] slowstart after idle question 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, 20 Apr 2017 21:27:19 -0000 Hi Ingemar, As one data point, YouTube disables tcp_slow_start_after_idle, but paces when restarting from idle. This is true both in the previous CUBIC era and also now that BBR is deployed for YouTube TCP traffic. Yuchung's presentation from a few years back also has a nice discussion of some of the related issues: https://www.ietf.org/proceedings/88/slides/slides-88-tcpm-9.pdf neal On Wed, Apr 19, 2017 at 11:42 PM, Ingemar Johansson S wrote: > Hi > > > > Possibly a question that would fit better in a Linux net dev forum but > anyway.. > > > > I have one short question. Is slow start after idle generally disabled > (net.ipv4.tcp_slow_start_after_idle=3D0) for instance for HTTP video > streaming ?. > > > > I can imagine that there are some benefits with avoiding the CWND decreas= e > in idle periods. > > Of course there is a problem that a large amount of data is transmitted w= hen > new objects are sent to the TCP sockets (shown on page 12 in > https://www.ietf.org/proceedings/96/slides/slides-96-iccrg-1.pdf ), but > packet pacing can solve this issue. > > > > > > /Ingemar > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Master Researcher > > > > Ericsson AB > > Wireless Access Networks > > Labratoriegr=C3=A4nd 11 > > 971 28, Lule=C3=A5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > A mistake is to commit a misunderstanding > Bob Dylan > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri Apr 21 03:25: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 D5405129B52 for ; Fri, 21 Apr 2017 03:25:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.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 ZC5qkumZ9sB6 for ; Fri, 21 Apr 2017 03:25:41 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 C7DE5129B6A for ; Fri, 21 Apr 2017 03:25:40 -0700 (PDT) X-AuditID: c1b4fb3a-7cfff70000005492-18-58f9de21ec09 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id BF.84.21650.12ED9F85; Fri, 21 Apr 2017 12:25:38 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 21 Apr 2017 12:25:37 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D+TEjyvqKxoipU41828mVnZV2NR7Eotuy3D0tJZUfCc=; b=YN44Pi8qMIO3wrYN+/PnNHN+X1vf4ln4xkaeJM2oZrdQhlmiCi3hurHf15/4fehbA8Q96KusW3vPIH/1LprfiGr8KmLj0tWDL1yR8wLq+QvyNRGtNf3JsJfzTlE5r4UeDy25JLZyn073YSPGsWwbIEkmu3KBJjofiW3YsuxAKsA= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Fri, 21 Apr 2017 10:25:35 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0%15]) with mapi id 15.01.1061.005; Fri, 21 Apr 2017 10:25:36 +0000 From: Ingemar Johansson S To: Neal Cardwell CC: "tcpm@ietf.org" , Yuchung Cheng Thread-Topic: [tcpm] slowstart after idle question Thread-Index: AdK5nxhjv+VuMbRUSMuzc2ftLD14pgAfbaAAABsQv1A= Date: Fri, 21 Apr 2017 10:25:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.95] x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:2hrQQMpOzuq5kb8kyOeS28BTEf/dxXHiPeSWVq+3a7ClzDfib8IVSppHOnK5hInK8h7hU3r11kPf8mBSUbhq7eDVvhC317QK4sdJHb5+Zim0AtoWvqELPkYhUVET7k7yorbStaCXlGnGNNtw+O/0SboO+3Mtj6gTk4mrKrZHAW6ZhkUWDjCgqGXnbkcZ5u+bMyw6RQ6cqVCzBFkoUDKFdA4c4yPDpEgff/xaqkn+Ti2mLLHftwdAoHkywTlC+QEF2AZ9wbA33rqkeB9y7e0AJ1xEcmM/waFLrWlg3lqN/m8YsHz/tr5a8taLnbmBOg6ivCYXJb1fyYK0fPj0g+i7oA== x-ms-office365-filtering-correlation-id: 88f95057-d0f5-4cea-ed0e-08d488a0bfcd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB345; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(211936372134217)(202460600054446); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406103)(20161123558050)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39410400002)(39400400002)(39850400002)(39860400002)(39840400002)(377454003)(24454002)(13464003)(8936002)(15974865002)(110136004)(86362001)(6246003)(5660300001)(25786009)(81166006)(5250100002)(6506006)(8676002)(53546009)(6306002)(50986999)(2900100001)(54356999)(76176999)(4326008)(38730400002)(7696004)(6916009)(2950100002)(2906002)(6116002)(102836003)(3846002)(66066001)(7736002)(33656002)(74316002)(305945005)(53936002)(55016002)(189998001)(6436002)(54906002)(99286003)(3280700002)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 10:25:35.8139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42KZGbHdT1fp3s8Ig0WtshYdd/ayWGw7OZ/J 4svjq2wOzB4LNpV6LFnykymAKYrLJiU1J7MstUjfLoEr4/v6d4wFKyQqjp2zbGC8Id7FyMkh IWAi8WHpLvYuRi4OIYH1jBLrf+5jhnBOMEpsOHuKGaSKRaCXWWLBE0YQW0hgGpPE+9fiEEUP GSVetR1kBUmwCdhIrDz0HaxIREBD4u6iB2A2s4CbxJbV98AGCQsYSnw9tZENosZIountU2YI 20ri8J1udohlqhIrFjcygdi8AlESLZO/MEIsW8gosb1vItgyToFAicvb/oAVMQrIStz/fo8F Ypm4xK0n85kgfhOQWLLnPDOELSrx8vE/VpBBjAL9jBKXX9+GKlKQ6DzwhgkkISHQzSxxbX0v VMJXonniESi7VuJBZwOUnSkxdeZFVgg7RuLWxztQzR+YJL7c2QzkcAA5MhLPP8ZDxFexSrS3 nmKC+F9K4u6VTkYIW0bixZ29rBMYNWchuXwWUDuzgKbE+l36EGFFiSndD9lngUNDUOLkzCcs CxhZVjGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIEpo+DW35b7WA8+NzxEKMAB6MSD++DfT8i hFgTy4orcw8xSnAwK4nw9m4HCvGmJFZWpRblxxeV5qQWH2KU5mBREud12HchQkggPbEkNTs1 tSC1CCbLxMEp1cCodfN2hYPxmYvBsmcKhBz4bm/+KLN2xcm5s+8yTHV4l7ep9PDxly9ynCSE A42XffA4z3RFdp/rkXC7vc9dtxVvmy1nu4TjS5qAwUWd2OUGbBYzWB/2yPN/zlUruBmve8K7 PddrXlJ1xaVMhafnn/6N2m/lfudW4qFjC6cxfWyzZFU2mPh9ceR1JZbijERDLeai4kQAnEGm QBsDAAA= Archived-At: Subject: Re: [tcpm] slowstart after idle question 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, 21 Apr 2017 10:25:43 -0000 VGhhbmtzIGZvciB0aGUgaGVscCAhDQoNCi9JbmdlbWFyDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBOZWFsIENhcmR3ZWxsIFttYWlsdG86bmNhcmR3ZWxsQGdvb2ds ZS5jb21dDQo+IFNlbnQ6IGRlbiAyMCBhcHJpbCAyMDE3IDIzOjI3DQo+IFRvOiBJbmdlbWFyIEpv aGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gQ2M6IHRjcG1A aWV0Zi5vcmc7IFl1Y2h1bmcgQ2hlbmcgPHljaGVuZ0Bnb29nbGUuY29tPg0KPiBTdWJqZWN0OiBS ZTogW3RjcG1dIHNsb3dzdGFydCBhZnRlciBpZGxlIHF1ZXN0aW9uDQo+IA0KPiBIaSBJbmdlbWFy LA0KPiANCj4gQXMgb25lIGRhdGEgcG9pbnQsIFlvdVR1YmUgZGlzYWJsZXMgdGNwX3Nsb3dfc3Rh cnRfYWZ0ZXJfaWRsZSwgYnV0IHBhY2VzDQo+IHdoZW4gcmVzdGFydGluZyBmcm9tIGlkbGUuIFRo aXMgaXMgdHJ1ZSBib3RoIGluIHRoZSBwcmV2aW91cyBDVUJJQyBlcmEgYW5kIGFsc28NCj4gbm93 IHRoYXQgQkJSIGlzIGRlcGxveWVkIGZvciBZb3VUdWJlIFRDUCB0cmFmZmljLg0KPiANCj4gWXVj aHVuZydzICBwcmVzZW50YXRpb24gZnJvbSBhIGZldyB5ZWFycyBiYWNrIGFsc28gaGFzIGEgbmlj ZSBkaXNjdXNzaW9uIG9mDQo+IHNvbWUgb2YgdGhlIHJlbGF0ZWQgaXNzdWVzOg0KPiANCj4gICBo dHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84OC9zbGlkZXMvc2xpZGVzLTg4LXRjcG0t OS5wZGYNCj4gDQo+IG5lYWwNCj4gDQo+IA0KPiBPbiBXZWQsIEFwciAxOSwgMjAxNyBhdCAxMTo0 MiBQTSwgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb20+IHdyb3RlOg0KPiA+IEhpDQo+ID4NCj4gPg0KPiA+DQo+ID4gUG9zc2libHkgYSBxdWVz dGlvbiB0aGF0IHdvdWxkIGZpdCBiZXR0ZXIgaW4gYSBMaW51eCBuZXQgZGV2IGZvcnVtIGJ1dA0K PiA+IGFueXdheS4uDQo+ID4NCj4gPg0KPiA+DQo+ID4gSSBoYXZlIG9uZSBzaG9ydCBxdWVzdGlv bi4gSXMgc2xvdyBzdGFydCBhZnRlciBpZGxlIGdlbmVyYWxseSBkaXNhYmxlZA0KPiA+IChuZXQu aXB2NC50Y3Bfc2xvd19zdGFydF9hZnRlcl9pZGxlPTApIGZvciBpbnN0YW5jZSAgZm9yIEhUVFAg dmlkZW8NCj4gPiBzdHJlYW1pbmcgPy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBJIGNhbiBpbWFnaW5l IHRoYXQgdGhlcmUgYXJlIHNvbWUgYmVuZWZpdHMgd2l0aCBhdm9pZGluZyB0aGUgQ1dORA0KPiA+ IGRlY3JlYXNlIGluIGlkbGUgcGVyaW9kcy4NCj4gPg0KPiA+IE9mIGNvdXJzZSB0aGVyZSBpcyBh IHByb2JsZW0gdGhhdCBhIGxhcmdlIGFtb3VudCBvZiBkYXRhIGlzDQo+ID4gdHJhbnNtaXR0ZWQg d2hlbiBuZXcgb2JqZWN0cyBhcmUgc2VudCB0byB0aGUgVENQIHNvY2tldHMgKHNob3duIG9uDQo+ ID4gcGFnZSAxMiBpbg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L3Ns aWRlcy9zbGlkZXMtOTYtaWNjcmctMS5wZGYgKSwgYnV0DQo+IHBhY2tldCBwYWNpbmcgY2FuIHNv bHZlIHRoaXMgaXNzdWUuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IC9JbmdlbWFyDQo+ ID4NCj4gPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4NCj4gPiBJbmdl bWFyIEpvaGFuc3NvbiAgTS5TYy4NCj4gPg0KPiA+IE1hc3RlciBSZXNlYXJjaGVyDQo+ID4NCj4g Pg0KPiA+DQo+ID4gRXJpY3Nzb24gQUINCj4gPg0KPiA+IFdpcmVsZXNzIEFjY2VzcyBOZXR3b3Jr cw0KPiA+DQo+ID4gTGFicmF0b3JpZWdyw6RuZCAxMQ0KPiA+DQo+ID4gOTcxIDI4LCBMdWxlw6Us IFN3ZWRlbg0KPiA+DQo+ID4gUGhvbmUgKzQ2LTEwNzEgNDMwNDINCj4gPg0KPiA+IFNNUy9NTVMg KzQ2LTczIDA3OCAzMjg5DQo+ID4NCj4gPiBpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNv bQ0KPiA+DQo+ID4gd3d3LmVyaWNzc29uLmNvbQ0KPiA+DQo+ID4NCj4gPg0KPiA+IEEgbWlzdGFr ZSBpcyB0byBjb21taXQgYSBtaXN1bmRlcnN0YW5kaW5nDQo+ID4gICAgICAgICAgICAgICAgICAg ICAgQm9iIER5bGFuDQo+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA+ DQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+IHRjcG1AaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCj4gPg0K From nobody Sat Apr 22 10:45: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 5F45A1294B9; Sat, 22 Apr 2017 10:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 5TcRpLWJFges; Sat, 22 Apr 2017 10:45:21 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30112.outbound.protection.outlook.com [40.107.3.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6C8128B8F; Sat, 22 Apr 2017 10:45:20 -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=f0tVLJ/PxTCazr7eKnliBWkLbD4p+Z3iyU+1cnX6iiI=; b=pL8mvLxTHWGT307cF5h4EGGj2Qbhpw3fiCTs8ETs1KSF58eK73zLG9/IKu5/TnwAllxXwCSV7C1jdSgMxrXKTjSfKdxvKTW6ySzQMfexDqR9DgRA4XFhnL9Jt7fDn2t6E7s4SBrVYf+tFCfaHAxeIM0sv310eJetd0J8GpvA6E8= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Sat, 22 Apr 2017 17:45:18 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1047.018; Sat, 22 Apr 2017 17:45:18 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "core@ietf.org WG" CC: "tcpm@ietf.org" , "iccrg@ietf.org" , "michawe@ifi.uio.no" Thread-Topic: Heads up on the upcoming WGLC for COCOA Thread-Index: AQHSs4k0mnjKYz30k0+Zp7QNidIepKHRhciX Date: Sat, 22 Apr 2017 17:45:18 +0000 Message-ID: References: <23333C37-60FB-41FD-B43B-EDC75F7BBFDB@ericsson.com> In-Reply-To: <23333C37-60FB-41FD-B43B-EDC75F7BBFDB@ericsson.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [25.163.180.4] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2547; 7:TmsjZpbQYd5hTSFMOpyo/8h5hykDiw7eUR6AW4+LdE1mOTSQ1HCPqjA96HRoVwfgGtwD+jJupP1d7OPFW7hvv7TFQx96t9ACtvvL2Ge4WC4LHKOGoiQ16TEMsa/jnrgxn0zLhrMbZyB4wcTl2k4O7LOvKcZ9F8sK1hMlzkXrCEXoUzKB/dQTUjxW4XTHHVEjAuhTuSWyLR1PAm/NhBbrkCIm4ShvyplFkVIz0XZeFmnZ67pw0NXBKTZ/eal6KayiFFtLVQxFBM1S6v3a6I8Wg6Tewpm/FxKRaKedb/ixr/eumDiCsZa1BzWf1V3JRHhnDzFiN1lgoy+gQvk+Wm1/sg== x-ms-office365-filtering-correlation-id: eed05b5c-7b4c-43b2-1d1a-08d489a75796 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:AM5PR0701MB2547; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:AM5PR0701MB2547; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2547; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39840400002)(39410400002)(39400400002)(39450400003)(54094003)(53754006)(6436002)(53936002)(9686003)(6306002)(102836003)(3846002)(6116002)(99286003)(54906002)(50986999)(54356999)(76176999)(55016002)(3660700001)(3280700002)(77096006)(6506006)(81166006)(2900100001)(110136004)(6246003)(38730400002)(8676002)(33656002)(66066001)(8936002)(2906002)(53546009)(189998001)(25786009)(6916009)(7696004)(229853002)(4326008)(5660300001)(7736002)(305945005)(2950100002)(74316002)(122556002)(86362001)(557034004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2547; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2017 17:45:18.6440 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2547 Archived-At: Subject: Re: [tcpm] Heads up on the upcoming WGLC for COCOA 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, 22 Apr 2017 17:45:24 -0000 Hi all, I have read draft-ietf-core-cocoa-01 as a contributor to TCPM, in particula= r since TCP documents are mentioned therein. Please find below my comments.= Note that I have not followed discussions on this document and I also do n= ot monitor the CoRE mailing list, i.e., I may lack some context. If topics = have been discussed already, I apologize for that. I wonder if this document is already ready for WGLC. There is missing text,= and to me the alorithm is not very well motivated. A formal issue is the e= xplicit violation of the BCP RFC 8085 but this is more something for the IE= SG to care about. If the document should continue to use an algorithm contradicting RFC 8085,= I think Appendix B should be in the document. I have not read Appendix A. An algorithm like the one mentioned in Appendix= A IMHO requires comprehensive simulation and empirical evaluation to ensur= e it is robust in all possible corner cases. This may be a topic e.g. for I= CCRG. In my option, either evidence should be included or referenced in the= document, or the Appendix A should be removed. It seems to me that Appendi= x A could be moved to another draft without impacting the rest of this docu= ment. Major issues: - Abstract: The abstract does not explain well the actual content of the do= cument. For instance, it does not mention that an RTO algorithm is describe= d in the document. - Abstract: The abstract should mention that the document is informational. - Section 3: I think the area of applicability should be better explained. = As far as I can see, the document focuses on low-bandwidth and high-latency= links. This is probably a relevant application scenario for CoAP. However,= I wonder if the mechanism would be equally well applicable to other transp= orts built for constrained network, see e.g. the "IoT" work in 4G/5G. I am = not sure if they have the same delay characteristics. Also, the document se= ems to assume later "naturally lossy networks"; this is not generally true = in the Internet. All in all, it really would make sense to explicitly spell= out for what environments the algorithms have been designed. - Section 4: Somewhat related, I think at the beginning of Section 4 a bett= er description is needed for the design rationale of the algorithms, e.g., = on underlying assumptions on the absolute values of delays. The current dra= ft basically presents an algorithm without much discussion on the design ch= oices, and whether alternatives would exist. For instance, I believe that t= he document implicitly assumes that delays/RTT can be larger than 1s. Such = assumptions should be spelt out.=20 - Section 4, Section 4.2, and Section 4.2.2: Indeed, BCP RFC 8085 defines "= Latency samples MUST NOT be derived from ambiguous transactions." As far as= I understand, this document explicitly violates the IETF concensus on RFC = 8085. Whether this is acceptable from a process perspective probably needs = IESG discussion. From a formal perspective, at minimum, I would expect this= deviation to be mentioned very explicitly in the introduction and at the b= eginning of Section 4. I'll comment below on some technical aspects. - Section 4.2 and in particular 4.2.1: This document should use a terminolg= y like "differences to the algorithm in RFC 6298". Using the term "modifica= tion" is confusing. This (informational) document does not *modify* RFC 629= 8 or the algorithms therein. Minor issues: - I find the title "CoAP Simple Congestion Control/Advanced" confusing. To= me the terms "simple" and "adanced" don't fit together very well. If the o= bjective is to use the acronym "CoCoA", this could be better explained, e.g= ., in the abstract. - Section 1: I think "(See Abstract.)" should be replaced by actual text. A= s mentioned separately, IMHO the abstract does not well describe the docume= nt neither. - Section 1 and 2: I would avoid that a long-lasting document refers to "mi= nutes of the IEFT 84 CoRE WG meetings". I think a document should be reason= ably self-contained, in particular in the introduction. I also think that s= ome content of Section 2 would well fit into the introduction. But this may= be a personal preference of me. - Section 3: As already mentioned, if "aggregate congestion control (Append= ix A) is not yet supported by research", I wonder why not to move this to a= separate document and publish that other document once there is research. = In any case, the term "cloud side" in that paragraph is not well defined an= d the use case assumed here is not clear to me. - Section 4: "This is based on the usual algorithms for RTO estimation [RFC= 6298]". RFC 6298 describes the standardized TCP algorithm; I think "usual" = is not a precise characterization as some TCP stacks may not exactly follow= RFC 6298. - Section 4: "One important consideration not relevant for TCP is the fact = that a CoAP round-trip may include application processing time". If the doc= ument wants to compare to TCP, it may be worthwile here to discuss the TCP = delayed acks. - Section 4.2 (and follow-up): I don't think the use of the weak estimator = is well motivated. The document does not give a good explanation why using = ambiguous samples is really useful, except for the observation that there h= ave been some (small?) benefits in some studies, without looking into root = causes. For instance, the weak estimator can be significantly larger than t= he actual network delay. Why does it make sense to increase the RTO way bey= ond the actual network delay in that case? Wouldn't this impact the deliver= y delay if a follow-up packet gets lost, and thus degrade the application p= erformance more than needed? In what network scenarios does using ambiguous= samples really help? And why does it even make sense to calculate the vari= ance of a sample that is ambiguous? Unfortunately, there is no single set o= f delay and loss characteristics in the Internet that a performance study c= ould use. Therefore, arguments on functional properties of an algorithm (e.= g., in simple example scenarios) would be quite helpful. - Section 4.2 (and follow-ups): I don't think the document addresses well h= ow close or far away the estimates of the strong and weak estimator can be = to each other. For instance, in a network without much congestion, would th= e weak estimator get updated if the latency in the network changes? How doe= s the Aging according to Section 4.3 tie in in that case? Based on the docu= ment it is difficult to understand how the various different algorithms wit= h conditional statements finally react altogether, and whether they are saf= e in all corner cases. It may be simpler to present the complete algorithms= as a sequence of processing steps. Alternatively or in addition, some exam= ples for simple scenarios could help to better understand what the algorith= ms would converge to (e.g., one example with rather low RTT samples and one= with rather large ones). Such examples may not be mandatory in an RFC, but= this would really be nice-to-have, IMHO. - Section 4.2: If we assume that the weak estimator is used (see my other c= omments), it seems that a sender would *either* use (1) or (2), right? If s= o, this could be better spelt out. - Section 4.2.1: "For RTO estimations below 1 s, the RTO for a retransmiss= ion is multiplied by 3, while for estimations above 3 s, the RTO is multip= lied only by 1.5 (this updated choice of numbers to be verified by more si= mulations)". Will the document be updated with results from more simulation= s prior to WGLC? - Section 4.2.2 "In contrast to [RFC6298], this algorithm attempts to make = use of ambiguous information from retransmissions. This is motivated by th= e high non-congestion loss rates expected in constrained node networks, an= d the need to update the RTO estimators even in the presence of loss." I be= lieve this assumption does not generally apply to all network technologies.= Several technologies have ARQ or FEC mechanisms below IP to make the rate = of non-congestion loss extremely small. I think this should be discussed. I= t would be worthwile to expand on what benefits (if any) the weak estimator= might have in networks without non-congestion loss. - Section 4.2.2: "However, those samples are not simply combined into the s= trong estimator, but are used to correct the limited knowledge that can be = gained from the strong RTT measurements by employing an additional weak est= imator." If there is benefit, it would be useful to add an example that exp= lains that "limited knowledge" and why such a correction could be useful. - Section 7: Security considerations seem to be missing. I wonder about the= scenario that an attacker only has temporary access to the network path. B= y causing some packets to be dropped, can he increase the RTOs in a large n= umber of senders for a relatively long time, thus degrading the performance= significantly? Thanks Michael ________________________________________ From: tcpm on behalf of Jaime Jim=E9nez Sent: Wednesday, April 12, 2017 14:35 To: core@ietf.org WG Cc: tcpm@ietf.org; iccrg@ietf.org; michawe@ifi.uio.no Subject: [tcpm] Heads up on the upcoming WGLC for COCOA Hi CoRE WG, this is just a heads up for the upcoming WGLC for "CoAP Simple Congestion C= ontrol/Advanced=94. https://tools.ietf.org/html/draft-ietf-core-cocoa-01 Note that there is still some discussion about whether to keep the appendix= es or not, and that there is time to get other comments before WGLC. This document has been presented multiple times and I=92d like to progress = with it soon, it=92d be great to have it by Prague. To ICCRG, as you now already, this was presented quite some time ago, below= is the links to the session and the slides. Session: https://www.ietf.org/proceedings/92/iccrg.html Presentation: https://www.ietf.org/proceedings/92/slides/slides-92-iccrg-2.= pdf Between the two sessions the main difference is the addition of the appendi= xes: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-cocoa-01.txt Ciao! - - Jaime Jim=E9nez From nobody Mon Apr 24 10:02:35 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 0D517131887 for ; Mon, 24 Apr 2017 10:02:34 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149305335405.25781.15654136096515641516.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 10:02:34 -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: Mon, 24 Apr 2017 17:02:34 -0000 Changed milestone "Submit document on Datacenter TCP (DCTCP) to the IESG for publication as Informational RFC", resolved as "Done". URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Mon Apr 24 12:41: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 C58F612709D for ; Mon, 24 Apr 2017 12:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 WbmBZtG9xbgp for ; Mon, 24 Apr 2017 12:41:39 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 11ADE1294AB for ; Mon, 24 Apr 2017 12:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:Cc:References:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gz+0/ndYaWQdHfaOFqX5dB3qEkz7lVhrevFLxVbIMqQ=; b=VPIXAjIyofrAsqpxFG68O8i1l jJCRPF/hHstp8uatgHng0Do91efAGi1KQLSBkG0df079lcTBUZtccw+fRrYl7HmKqSEzC9gZC9Ndr H0dmlFQKURjE3KOAxcqw2v4eN+cCtEGPAZseCMh5LvX8cLAzl2impbtCXcPbRRFIvzkEfkIU9MzFD fPn8QhiM53CWentzdxf2eLr+7cEerV43IQDtJM/bDuZilS16oykk2ypPz4qwY24oEJHGDfUQxjorb U055cdBuMofTqj92LwnyDmz7spIAMIB8bKApQhmag4o2RmS+O0nd79i1mugRMi9I8eYZEcmy9cqBT ZazeP+SZQ==; Received: from 188.6.208.46.dyn.plus.net ([46.208.6.188]:58866 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d2jrb-0004F6-2B; Mon, 24 Apr 2017 20:41:35 +0100 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <3d53f6a4-697b-0c7a-8c71-524890312beb@bobbriscoe.net> <5a4e46a0-bde7-8de5-f6a3-354f06fd9058@bobbriscoe.net> <94ff22d6-69b3-164a-8bdb-07149f3e58b3@bobbriscoe.net> <9796d961-292e-e257-a2d8-c0321f61b31a@bobbriscoe.net> <0533c69e-617e-fb5d-af97-4a603eb29d8d@tik.ee.ethz.ch> Cc: "Black, David" , "tcpm@ietf.org" , marcelo bagnulo braun From: Bob Briscoe Message-ID: Date: Mon, 24 Apr 2017 20:41:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0533c69e-617e-fb5d-af97-4a603eb29d8d@tik.ee.ethz.ch> Content-Type: multipart/alternative; boundary="------------516AAE1E979D1EB3AA7FCBAC" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black) 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, 24 Apr 2017 19:41:44 -0000 This is a multi-part message in MIME format. --------------516AAE1E979D1EB3AA7FCBAC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Mirja, Thx for the rapid and extensive re-review. I shall get on with making the edits outlined below and, unless I see objections to anything in this email, I'll submit an update when done. On 20/04/17 18:26, Mirja Kühlewind wrote: > Hi Bob, > > given it seems I spend most of my time these days to worry about > different ECN-related RFCs, I've also reviewed this draft (actually > only sections 1-4; I may review section 5 at a later point of time but > I trust you that you have addressed my previous comments here). > > Here is my feedback as individual contributor: In general, I'm happy > with the spec and the overall draft now. Thanks for the work! It reads > very well now. I have a few minor technical comments and some > editorial proposals and a proposal to restructure some smaller parts > below. > > So te document is in really good shape and the technical specification > is good. So I think that this version is definitely ready for adoption > and would like to see an adoption call very soon! [BB] Strongly agree :) Seriously, I think you should make it clear whether you are saying this as AD or individual. > > Mirja > > ----------------- > High-level, minor technical points: > > 1) The description of TFO in section 4.2 is not quite correct: > "If a TFO initiator has cached that the server supported ECN in the > previous connection, it would be safe to set ECT on any data segments > it sends before a SYN-ACK returns from the responder (server). Note > that there is no space in the SYN-ACK itself (whether classic or > AccECN feedback has been negotiated) to include feedback about any CE > on data packets. Nonetheless, it is safe to set ECT on data packets > within the handshake because any CE-marking on these data segments > can be fed back by the responder on the first data segment it sends > after the SYN-ACK (or on an additional pure ACK if it has no more > data to send)." > TFO allows the initiator to send data in the SYN but no additional > data packets, and the responder to send the SYN/ACK as well as an IW > full of data packets. So I think the problem here goes away. However, > accECN actually does feedback information of CE marked data in the > SYN/ACK because the SYN/ACK carries the AccECN option that holds this > information. [BB] I'll remove the whole section about TFO, and instead include a brief sentence explaining why TFO is not relevant in the intro to S.4. Thanks. I was thinking that there is nothing in TFO [RFC7413] to preclude the initiator sending data segments before receiving the SYN-ACK. However, you've made me think this through further, and I've realized the initiator would have to send data without the ACK flag set (or with the ACK flag faked but no valid ackno). Altho the TFO cookie would make this safe from a security perspective, it's not going to happen due to middleboxes. > 2) Regarding this question in section 3.2.3 > "DISCUSSION: An AccECN deployment or an implementation of RFC 3168 > that feeds back CE on pure ACKs will be at a disadvantage compared > to an RFC 3168 implementation that does not. To solve this, the > WG could decide to prohibit setting ECT on pure ACKs unless AccECN > has been negotiated." > I've checked REF3168 and it does not say anything about handling of > pure ACKs that are CE marked because it probably just assumes that > that case will never happen. However, implementations may or may not > provide feedback. I think I would support to only have pure ACKs ECT > marked if AccECN is supported because of this. I also think that > losing ACKs is probably less bad that losing any of the other > (control) packets that are discussed in this document. So I think this > restriction would be okay. [BB] OK, it's good to have one opinion on this. We'd like to hear more opinions before changing this tho. FYI, RFC3168 does vaguely hint that the receiver of Pure ACKs carrying ECT (or CE) probably ought not to reject them (but it doesn't say what to do with a CE mark). In S.6.1.4 it says: For the current generation of TCP congestion control algorithms, pure acknowledgement packets [...] MUST be sent with the not-ECT codepoint. Saying "current generation" implies a future generation might change this, which ought to make an implementer wary of rejecting ECT on Pure ACKs. > > 3) This is a suggestion to improve the situation, however it probably > needs further discussion: in sect 3.2.1.4 you say that one should > still use ECT SYNs even if a connection attempt previously failed. > Maybe we can use a smaller time-out in this case...? [BB] I'm wary of jumping to the conclusion that a loss is not due to congestion just because it's becoming more likely it could be due to a black hole. E.g. if there's a black hole, the probability of losing an ECT SYN is 100%, but if the underlying loss level is 1%, the probability that 2 SYNs are lost is 0.01% as an alternative. So, when 2 ECT SYNs at different times have timed out, but non-ECT SYNs got through, I suppose it's possible to argue that the probability that the second loss was due to congestion has reduced. So the timeout could be reduced. I'll add this, and flag it "FOR DISCUSSION". > > And now first a couple of comments on the structure: > > 1) I would move the network behavior in any case AFTER the endpoint > behavior spec. Actually I would even propose to have it in a different > section (not under 3. Specification) because it actually does not > specify anything; it only comments on the current situation. [BB] I did consider this when I removed the normative text from this section. But this this section is intended to do more than just comment. We want it to incorporate the "SHOULD" in ecn-experimentation as part of the specification for this experiment. And we figured this text is short enough to put first, to reduce the chance it gets buried and overlooked operators, without distracting host implementers too much. So I would rather make the following change than move the section: s/So operators are encouraged to alter their firewall rules/ /So operators are RECOMMENDED to alter their firewall rules/ Rationale: When updates to a system for an experiment are all spread about in different docs, it's not just helpful but also necessary to call out all the parts in their different docs. Similarly, we have incorporated RFC5562 (ECT on SYN-ACK) and AccECN into this draft - both as normative references. > > 2) And then you would actually not need a separate subsection for the > Endpoint behavior; you could just call section 3 "Specification of > Endpoint Behavior" or even "Specification of Sender Behavior" and move > the first two paragraphs of section 3.2 to the intro that explains > that this mechanism/document only needs to talk about the sender > behavior. [BB] Depends on resolution of the above. > > 3) I would include the text on TFO and IW10 directly into section > 3.2.1.3 instead of just giving a reference to a later section. [BB] This is a matter of style. I prefer to distinguish normative dependencies between * dependencies that are essential, * and then to split optional dependencies between: - STD - EXPT The above structure forces implementers (and authors) to make dependencies modular, in case an experiment fails. E.g. we do not yet know whether an attack will be invented against TFO. For instance, look at all the mess that has had to be cleared up because everyone assumed the ECN nonce experiment would succeed. > > 4) The rationale in section 3.2.6.1 could also go somewhere into > section 5 (to keep the spec part as short as possible). At least I > think you don't need the whole text here. If you want to keep > something you probably only need the second paragraph (and not an own > subsection). [BB] The scope of Section 5 is (currently) countering arguments in other RFCs (mostly RFC3168). ECT on RSTs wasn't mentioned in an RFC so far, which is I why I put this section here. One solution would be to rename section 5 "Rationale". Then I would be happy to move 3.2.6.1 to section 5. I'll do that. > > 5) Maybe have the section on Retransmissions (3.2.7.) earlier before > RST, FIN, and Window probe because it seems more "important". But > actually I don't think the order matters that much. So this is a minor > comment only. [BB] Currently the order is chosen to match the order of the lists in the introduction so they can be summarized as "control packets and retransmissions". I'll leave it as it is. > > 6) The paragraph on SCTP (section 4.1) could go into the intro. And if > you then also integrate the TFP and IW10 stuff into section 3.2.1.3, > section 4 would actually go away completely. [BB] Now, with the removal of the TFO section, none of S.4 contains anything normative. Now it is just saying "For all these variants, here's why you don't need to do anything different". So I am inclined to move it /after/ section 5. I certainly don't want to integrate the TFO and IW10 comments into the spec section, because that would just complicate the spec with text that essentially ends up saying "You didn't need to read this to implement the spec". I also don't want to add a detailed para about SCTP to a nice 3-para Intro to a spec about a modification to TCP. However, I agree that "scope" is one of the important things to cover in an introduction. In summary, I would rather move this section about variants to after S.5. And in the intro, say this is an experimental modification to standards track TCP, but also flag that it discusses (non-)interaction with variants such as SCTP, TFO, IW10. > > And now a bunch of editorial comments/proposals: > > 1) I though that it might be good to mention AccECN already in the > Intro because that the enabler for the SYN part... [BB] OK, that would be sensible, along with the above sentence about variants. Will do. > > 2) section 1.1: > OLD > "Preventing TCP control > packets from obtaining the benefits of ECN would not only expose them > to the prevailing level of congestion loss, but it would also stop > them from being classified into the low latency (L4S) queue, which > would greatly degrade L4S performance." > I think this can be phrased more general: > NEW > "Preventing TCP control > packets from obtaining the benefits of ECN would not only expose them > to the prevailing level of congestion loss, but it would also put > control > packet into a different queue with different network treatment, which > may also lead to reordering and therefore can greatly degrade TCP > performance." [BB] Good point. Given this sentence was in a para about L4S, I shall split it off and make it into a summary section. > > > 3) section 3.2.1.1: > OLD > "Accurate ECN (AccECN) > feedback [I-D.ietf-tcpm-accurate-ecn] provides two codepoints in the > SYN-ACK" > NEW > "Accurate ECN (AccECN) > feedback [I-D.ietf-tcpm-accurate-ecn] provides one flag in the > SYN-ACK" > I think that's clearer, at least for me. [BB] Eh? I'm not going to change this, cos the word flag would imply this is a bit with a meaning orthogonal to the other bits. Here's a copy of the relevant part of the table... | NS CWR ECE | | | 0 1 0 | AccECN | | 1 1 0 | AccECN (CE on SYN) | | 1 0 1 | classic ECN | ... etc The first bit only distinguishes "whether or not the SYN arrived marked CE" when the 3-bit codepoint as a whole is 'X10'. So it's not a flag, it's 2 codepoints. > > 4) section 3.2.1.2 > This sentence is correct but I had to read it twice to make sure it's > correct: > "Servers that > do not support ECN as a whole probably do not need to be recorded > separately from non-support of AccECN because, even when a server > does not support classic [RFC3168] ECN, there is no performance > penalty in always requesting to use it." > NEW > "Servers that > do not support ECN as a whole probably do not need to be recorded > separately from non-support of AccECN. Meaning, if AccECN is noted > as not supported by the server, the initiator may decide to not mark > the SAN as ECT but it still may try to negotiate classic ECN or even > AccECN (to quickly detect server upgrades)." [BB] I realize now that this text is all wrong. I shall attempt a rewrite. I now realize my heading of 3.2.1.2 is wrong; it was not meant to be about "Caching Failed Connection Attempts". It was meant to be mostly about "Caching Lack of Recognition of ECT SYNs", with just a reference forward to caching failed connection attempts ("3.2.1.4 Fall-Back Following No Response to an ECT SYN"). I intended to say that, when a server is cached as not supporting AccECN, subsequent attempts should still request AccECN, but not with ECT on the SYN. Because there is no harm in always attempting to negotiate AccECN (as long as such requests are not black-holed), because the responder will still respond properly to an AccECN request if it only supports classic ECN or no ECN at all, without any performance penalty. I shall also make the point in S.3.2.1.4 that if an ECT SYN is black-holed, it might still be possible to request AccECN, but without ECT on the SYN. > > 5) section 3.2.1.4: > OLD > "To expedite connection set-up if, after sending an ECT SYN, the > retransmission timer expires, the TCP initiator SHOULD send a SYN > with the not-ECT codepoint in the IP header and not attempt to > negotiate AccECN. It would make sense to also remove any other > experimental fields or options on the SYN, but that will depend on > the specification of the other option(s). " > I wouldn't make any statements about things that are not in scope of > this doc, so I would remove the later part (including fallback for > AccECN): > NEW > "To expedite connection set-up if, after sending an ECT SYN, the > retransmission timer expires, the TCP initiator SHOULD send a SYN > with the not-ECT codepoint in the IP header." [BB] I agree that I shouldn't have said to not attempt AccECN. So I will use your new text. But I disagree about not even mentioning that the cause might be other experimental options, and to encourage the reader to read those specs as well. I'll use the following unless you shout: "To expedite connection set-up if, after sending an ECT SYN, the retransmission timer expires, the TCP initiator SHOULD send a SYN with the not-ECT codepoint in the IP header. If other experimental fields or options were on the SYN, it will also be necessary to follow their specifications for fall-back too. It would make sense to co- ordinate all the strategies for fall-back in order to isolate the specific cause of the problem." > > 6) section 3.2.2 says: > "In either case no change is required to RFC 5562 or the AccECN > specification." > > It would probably be good to also state in this draft what the > procedure is that is described in RFC5562: > "When the responder (node B) receives the ECN-Echo packet reporting > the Congestion Experienced indication in the SYN/ACK packet, the > responder sets the initial congestion window to one segment, instead > of two segments as allowed by [RFC2581], or three or four segments > allowed by [RFC3390]. As illustrated in Figure 2, if the responder > (node B) receives an ECN-Echo packet informing it of a Congestion > Experienced indication on its SYN/ACK packet, the responder sends a > SYN/ACK packet that is not ECN-Capable, in addition to setting the > initial window to one segment. The responder does not advance the > send sequence number. The responder also sets the retransmission > timer. The responder follows RFC 2988 [RFC2988] in setting the RTO > (retransmission timeout)." [BB] Two responses: 1) I think it's dangerous to quote a small part of another spec. as if it's a good summary of the behaviour. This loses all the detail in RFC 5562 (e.g. what if the responder implements SYN cookies, yada yada). 2) Oh dear. I had forgotten that RFC5562 specified a different protocol to the "ECN+" paper. It's ultra-ultra-conservative. So, I think we had better include the original proposal in the "ECN+" paper within the generalized ECN draft, and include a counter-argument to RFC5562 as well as to RFC3168. > > 7) section 3.2.3: > OLD > "It MAY also > implement AckCC [RFC5690] to regulate the pure ACK rate, but this is > not required. Note that, in comparison, [RFC5681] does not > require..." > NEW > "It MAY also > implement Acknowledgement Congestion Control (AckCC) [RFC5690] to > regulate the pure ACK rate, but this is > not required. Note that, in comparison, TCP Congestion Control > [RFC5681] does not require..." [BB] OK. > > > 8) section 3.2.3: > "The question of whether the receiver of pure ACKs is required to feed > back any CE marks on them is a matter for the relevant feedback > specification ([RFC3168] or [I-D.ietf-tcpm-accurate-ecn]). It is > outside the scope of the present specification." > However, as mention about I believe that RFC3168 does not say anything > about feedback how to handle CE marks of pure ACK because it assumes > that this case never occurs. So that might be implementation > dependent, so it might be better to spell that out: > "[I-D.ietf-tcpm-accurate-ecn] includes handling of control packets. > However, [RFC3168] does not specify handling of pure ACKs that are CE > mark, so it might be implementation specific if feedback is provided > or not." [BB] OK. Anyway, this will be moot if we do not allow ECT on Pure ACKs unless AccECN has been negotiated. > > Related to this comment in the same section: > "DISCUSSION: Before the AccECN specification is published, a > requirement to count CE marks on all packets could be added." > I pretty sure that this is what the AccECN draft is doing but I can > double check. If not it clearly should be added. Maybe it's not > spelled out clearly enough. I'll check! [BB] You're right. I will fix this. I too thought that AccECN counted CE on pure ACKs, but I checked the AccECN draft by searching for "pure ACK" and couldn't find any mention of this aspect. However, I've just done a more thorough search, and you're right - it says so three times, but none use the words "pure ACK": The fourth counts the number of packets arriving marked with a CE codepoint (including control packets without payload if they are CE-marked). [...] The CE packet counter includes control packets that do not have payload data, [...] The CE packet counter (r.cep), counts the number of packets the host receives with the CE code point in the IP ECN field, including CE marks on control packets without data. > > 9) section 3.2.6.1: > OLD > "The following factors have been considered before deciding whether > ECT ought to be allowed on a RST message:" > NEW > "The following factors have been considered before deciding whether > the RST message should be ECT marked:" [BB] * I had already edited out any occurrence of the phrase "ECT marked" (because "marked" generally implies a congestion marking, so this could be misinterpreted). * I always avoid the word "should" in lower case. * I try to avoid writing sentences in the passive (but I missed this one). Other than all that, I grok what you mean; I will use: "The following factors have been considered before deciding whether the sender ought to set ECT on a RST message:" > > That's it. So nothing big. Let move on with this draft! [BB] Cheers Bob > > > > > On 18.04.2017 11:40, Bob Briscoe wrote: >> David, Mirja, list, >> >> Thanks again for your reviews of the -00. I've been busy over the w/e >> after >> thinking more deeply about some of your comments and after realizing >> that >> RFC3168 contained an assumption that a single pure ACK implies that >> all other >> packets in that direction are pure ACKs, which is not true in general. >> >> We've produced another rev (draft-bagnulo-tcpm-generalized-ecn-02 >> ). >> >> This is a general invitation for anyone on the list, including you >> two, to >> review this again, so we can ask for an informed adoption call. >> >> We need people with the following expertise: >> * TCP hijacking and DoS/flooding attacks >> * Specific TCP implementations (Linux, FreeBSD, iOS, Windows, etc). >> * All the common variants of TCP >> >> We have identified clearly where decisions are needed. >> As well as where more measurements are needed. >> >> Main changes: >> * Moved more discursive text from S.3 (Spec) to S.5 (Arguments >> against RFCs) >> * Major changes to Pure ACK sections and the reliability argument, to >> address >> Mirja's arguments better, and to separately address cwnd response >> (required) >> and ACK-rate response (optional but not required). >> * Referred to Network Behaviour in ecn-experimentation, rather than >> repeating >> it. >> * Fixed description of window probe. >> * Recommended RFC 5961, which gives much stronger packet validity >> checks for >> retransmissions, RSTs & FINs. >> >> Cheers >> >> >> Bob >> >> >> On 14/04/17 02:13, Bob Briscoe wrote: >>> David, >>> >>> I hope you will find that I have addressed all your concerns - so at >>> least >>> you will be able to understand it now. >>> The draft is now unexpired. >>> >>> I have also addressed all the points in Mirja's review (some >>> intersecting >>> with your points). >>> >>> You will see that it's actually turned into quite a major re-write. The >>> diff is nearly total, mainly cos I was turning Spanglish into >>> English as I >>> went (Marcelo, it was quite understandable, but just not quite how a >>> native >>> English speaker would say it). >>> >>> However, I have changed technical points in a few places too - the >>> more one >>> thinks about this, the more depth one finds. >>> >>> I just noticed I missed one of your nits (shortening the definition of >>> Retransmission), which I have already fixed in my local copy of the >>> xml for >>> the next rev. >>> >>> >>> >>> Bob >>> >>> >>> On 08/04/17 01:11, Bob Briscoe wrote: >>>> David, >>>> >>>> On 2) I intend to replace the whole of "3.1 Network behaviour" with >>>> the >>>> following, which calls out the cases explicitly: >>>> >>>> Previously RFC3168 required the sender to set not-ECT on certain TCP >>>> control packets. Some readers might have erroneously interpreted this >>>> aspect of RFC3168 as a requirement for firewalls, intrusion detection >>>> systems, etc. to check and enforce this behaviour. Now that the >>>> present >>>> experimental specification allows TCP senders to set ECT on all TCP >>>> packets (control and data), it needs to be clear that a firewall >>>> (or any >>>> network node) SHOULD NOT treat any ECT packet differently dependent on >>>> what type of TCP packet it is. >>>> >>>> One potential exception is envisaged, otherwise the previous sentence >>>> could have said "MUST NOT" rather than "SHOULD NOT". The exception >>>> allows >>>> a security function that has detected an ongoing attack to drop >>>> more ECT >>>> marked SYNs than not-ECT marked SYNs. Such a policy SHOULD NOT be >>>> applied >>>> routinely. It SHOULD only be applied if an attack is detected, and >>>> then >>>> only if it is determined that the ECT capability is intensifying >>>> the attack. >>>> >>>> >>>> Bob >>>> >>>> On 07/04/17 23:33, Black, David wrote: >>>>> Bob, >>>>> >>>>> Two comments: >>>>> >>>>> 1) I'll wait for new text before commenting further on Accurate >>>>> ECN vs. >>>>> vanilla RFC 3168 ECN. The current text left me somewhat confused, >>>>> and >>>>> the summary of changes from RFC 3168 will almost certainly help. >>>>> >>>>> 2) On network node treatment of ECT, RFC 3168 is brief, e.g. >>>>> (Section 5, >>>>> top of p.7): >>>>> >>>>> The CE codepoint '11' is set by a router to indicate >>>>> congestion to >>>>> the end nodes. >>>>> >>>>> One wants to avoid text that could be read as modifying that >>>>> sentence by >>>>> adding possible exceptions for TCP control packets and/or >>>>> retransmissions. >>>>> >>>>>> [BB] Unfortunately, RFC3168 does not specify anything about >>>>>> network node >>>>>> forwarding behaviour wrt ECT. So some firewall policies could have >>>>>> decided to block any TCP control packets that contravene RFC3168. >>>>>> That's >>>>>> why we wrote this section. >>>>> If "firewalls" is what was meant, use that word ;-) ... or as you >>>>> write ... >>>>> >>>>>> However I admit that, by not explaining that DPI was the problem >>>>>> we were >>>>>> trying to solve, rather than removing any ambiguity that might >>>>>> have been >>>>>> interpreted as a need for DPI. We'll fix this. >>>>> In doing so, please keep in mind that in this draft, discussion of >>>>> forwarding and dropping behavior is implicitly about router queue >>>>> management, not middlebox access control (e.g., based on DPI), so >>>>> access >>>>> control has to be called out explicitly when that is what is meant. >>>>> >>>>> Thanks, --David >>>>> >>>> >>>> >>> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------516AAE1E979D1EB3AA7FCBAC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Mirja,

Thx for the rapid and extensive re-review.

I shall get on with making the edits outlined below and, unless I see objections to anything in this email, I'll submit an update when done.


On 20/04/17 18:26, Mirja Kühlewind wrote:
Hi Bob,

given it seems I spend most of my time these days to worry about different ECN-related RFCs, I've also reviewed this draft (actually only sections 1-4; I may review section 5 at a later point of time but I trust you that you have addressed my previous comments here).

Here is my feedback as individual contributor: In general, I'm happy with the spec and the overall draft now. Thanks for the work! It reads very well now. I have a few minor technical comments and some editorial proposals and a proposal to restructure some smaller parts below.

So te document is in really good shape and the technical specification is good. So I think that this version is definitely ready for adoption and would like to see an adoption call very soon!
[BB] Strongly agree :)

Seriously, I think you should make it clear whether you are saying this as AD or individual.


Mirja

-----------------
High-level, minor technical points:

1) The description of TFO in section 4.2 is not quite correct:
"If a TFO initiator has cached that the server supported ECN in the
   previous connection, it would be safe to set ECT on any data segments
   it sends before a SYN-ACK returns from the responder (server).  Note
   that there is no space in the SYN-ACK itself (whether classic or
   AccECN feedback has been negotiated) to include feedback about any CE
   on data packets.  Nonetheless, it is safe to set ECT on data packets
   within the handshake because any CE-marking on these data segments
   can be fed back by the responder on the first data segment it sends
   after the SYN-ACK (or on an additional pure ACK if it has no more
   data to send)."
TFO allows the initiator to send data in the SYN but no additional data packets, and the responder to send the SYN/ACK as well as an IW full of data packets. So I think the problem here goes away. However, accECN actually does feedback information of CE marked data in the SYN/ACK because the SYN/ACK carries the AccECN option that holds this information.

[BB] I'll remove the whole section about TFO, and instead include a brief sentence explaining why TFO is not relevant in the intro to S.4. Thanks.

I was thinking that there is nothing in TFO [RFC7413] to preclude the initiator sending data segments before receiving the SYN-ACK.
However, you've made me think this through further, and I've realized the initiator would have to send data without the ACK flag set (or with the ACK flag faked but no valid ackno). Altho the TFO cookie would make this safe from a security perspective, it's not going to happen due to middleboxes.


2) Regarding this question in section 3.2.3
"DISCUSSION: An AccECN deployment or an implementation of RFC 3168
      that feeds back CE on pure ACKs will be at a disadvantage compared
      to an RFC 3168 implementation that does not.  To solve this, the
      WG could decide to prohibit setting ECT on pure ACKs unless AccECN
      has been negotiated."
I've checked REF3168 and it does not say anything about handling of pure ACKs that are CE marked because it probably just assumes that that case will never happen. However, implementations may or may not provide feedback. I think I would support to only have pure ACKs ECT marked if AccECN is supported because of this. I also think that losing ACKs is probably less bad that losing any of the other (control) packets that are discussed in this document. So I think this restriction would be okay.
[BB] OK, it's good to have one opinion on this.
We'd like to hear more opinions before changing this tho.

FYI, RFC3168 does vaguely hint that the receiver of Pure ACKs carrying ECT (or CE) probably ought not to reject them (but it doesn't say what to do with a CE mark). In S.6.1.4 it says:
      For the current generation of TCP congestion control algorithms,
      pure acknowledgement packets [...] MUST be sent with the not-ECT codepoint.
Saying "current generation" implies a future generation might change this, which ought to make an implementer wary of rejecting ECT on Pure ACKs.


3) This is a suggestion to improve the situation, however it probably needs further discussion: in sect 3.2.1.4 you say that one should still use ECT SYNs even if a connection attempt previously failed. Maybe we can use a smaller time-out in this case...?
[BB] I'm wary of jumping to the conclusion that a loss is not due to congestion just because it's becoming more likely it could be due to a black hole. E.g. if there's a black hole, the probability of losing an ECT SYN is 100%, but if the underlying loss level is 1%, the probability that 2 SYNs are lost is 0.01% as an alternative.

So, when 2 ECT SYNs at different times have timed out, but non-ECT SYNs got through, I suppose it's possible to argue that the probability that the second loss was due to congestion has reduced. So the timeout could be reduced.

I'll add this, and flag it "FOR DISCUSSION".


And now first a couple of comments on the structure:

1) I would move the network behavior in any case AFTER the endpoint behavior spec. Actually I would even propose to have it in a different section (not under 3. Specification) because it actually does not specify anything; it only comments on the current situation.
[BB] I did consider this when I removed the normative text from this section. But this this section is intended to do more than just comment. We want it to incorporate the "SHOULD" in ecn-experimentation as part of the specification for this experiment. And we figured this text is short enough to put first, to reduce the chance it gets buried and overlooked operators, without distracting host implementers too much.

So I would rather make the following change than move the section:
s/So operators are encouraged to alter their firewall rules/
 /So operators are RECOMMENDED to alter their firewall rules/
Rationale: When updates to a system for an experiment are all spread about in different docs, it's not just helpful but also necessary to call out all the parts in their different docs. Similarly, we have incorporated RFC5562 (ECT on SYN-ACK) and AccECN into this draft - both as normative references.


2) And then you would actually not need a separate subsection for the Endpoint behavior; you could just call section 3 "Specification of Endpoint Behavior" or even "Specification of Sender Behavior" and move the first two paragraphs of section 3.2 to the intro that explains that this mechanism/document only needs to talk about the sender behavior.
[BB] Depends on resolution of the above.

3) I would include the text on TFO and IW10 directly into section 3.2.1.3 instead of just giving a reference to a later section.
[BB] This is a matter of style. I prefer to distinguish normative dependencies between
* dependencies that are essential,
* and then to split optional dependencies between:
  - STD
  - EXPT

The above structure forces implementers (and authors) to make dependencies modular, in case an experiment fails. E.g. we do not yet know whether an attack will be invented against TFO.

For instance, look at all the mess that has had to be cleared up because everyone assumed the ECN nonce experiment would succeed.


4) The rationale in section 3.2.6.1 could also go somewhere into section 5 (to keep the spec part as short as possible). At least I think you don't need the whole text here. If you want to keep something you probably only need the second paragraph (and not an own subsection).
[BB] The scope of Section 5 is (currently) countering arguments in other RFCs (mostly RFC3168).
ECT on RSTs wasn't mentioned in an RFC so far, which is I why I put this section here.

One solution would be to rename section 5 "Rationale". Then I would be happy to move 3.2.6.1 to section 5. I'll do that.


5) Maybe have the section on Retransmissions (3.2.7.) earlier before RST, FIN, and Window probe because it seems more "important". But actually I don't think the order matters that much. So this is a minor comment only.
[BB] Currently the order is chosen to match the order of the lists in the introduction so they can be summarized as "control packets and retransmissions". I'll leave it as it is.

6) The paragraph on SCTP (section 4.1) could go into the intro. And if you then also integrate the TFP and IW10 stuff into section 3.2.1.3, section 4 would actually go away completely.
[BB] Now, with the removal of the TFO section, none of S.4 contains anything normative. Now it is just saying "For all these variants, here's why you don't need to do anything different". So I am inclined to move it /after/ section 5.

I certainly don't want to integrate the TFO and IW10 comments into the spec section, because that would just complicate the spec with text that essentially ends up saying "You didn't need to read this to implement the spec".

I also don't want to add a detailed para about SCTP to a nice 3-para Intro to a spec about a modification to TCP.
However, I agree that "scope" is one of the important things to cover in an introduction.

In summary, I would rather move this section about variants to after S.5. And in the intro, say this is an experimental modification to standards track TCP, but also flag that it discusses (non-)interaction with variants such as SCTP, TFO, IW10.


And now a bunch of editorial comments/proposals:

1) I though that it might be good to mention AccECN already in the Intro because that the enabler for the SYN part...
[BB] OK, that would be sensible, along with the above sentence about variants. Will do.

2) section 1.1:
OLD
"Preventing TCP control
   packets from obtaining the benefits of ECN would not only expose them
   to the prevailing level of congestion loss, but it would also stop
   them from being classified into the low latency (L4S) queue, which
   would greatly degrade L4S performance."
I think this can be phrased more general:
NEW
 "Preventing TCP control
   packets from obtaining the benefits of ECN would not only expose them
   to the prevailing level of congestion loss, but it would also put control
   packet into a different queue with different network treatment, which
   may also lead to reordering and therefore can greatly degrade TCP
   performance."
[BB] Good point. Given this sentence was in a para about L4S, I shall split it off and make it into a summary section.


3) section 3.2.1.1:
OLD
"Accurate ECN (AccECN)
   feedback [I-D.ietf-tcpm-accurate-ecn] provides two codepoints in the
   SYN-ACK"
NEW
"Accurate ECN (AccECN)
   feedback [I-D.ietf-tcpm-accurate-ecn] provides one flag in the
   SYN-ACK"
I think that's clearer, at least for me.
[BB] Eh? I'm not going to change this, cos the word flag would imply this is a bit with a meaning orthogonal to the other bits.

Here's a copy of the relevant part of the table...
   |  NS CWR ECE  |                      |
   |  0   1   0   | AccECN               |
   |  1   1   0   | AccECN (CE on SYN)   |
   |  1   0   1   | classic ECN          | 
... etc
The first bit only distinguishes "whether or not the SYN arrived marked CE" when the 3-bit codepoint as a whole is 'X10'. So it's not a flag, it's 2 codepoints.


4) section 3.2.1.2
This sentence is correct but I had to read it twice to make sure it's correct:
"Servers that
   do not support ECN as a whole probably do not need to be recorded
   separately from non-support of AccECN because, even when a server
   does not support classic [RFC3168] ECN, there is no performance
   penalty in always requesting to use it."
NEW
"Servers that
   do not support ECN as a whole probably do not need to be recorded
   separately from non-support of AccECN. Meaning, if AccECN is noted as not supported by the server, the initiator may decide to not mark the SAN as ECT but it still may try to negotiate classic ECN or even AccECN (to quickly detect server upgrades)."
[BB] I realize now that this text is all wrong. I shall attempt a rewrite.

I now realize my heading of 3.2.1.2 is wrong; it was not meant to be about "Caching Failed Connection Attempts". It was meant to be mostly about "Caching Lack of Recognition of ECT SYNs", with just a reference forward to caching failed connection attempts ("3.2.1.4 Fall-Back Following No Response to an ECT SYN").

I intended to say that, when a server is cached as not supporting AccECN, subsequent attempts should still request AccECN, but not with ECT on the SYN. Because there is no harm in always attempting to negotiate AccECN (as long as such requests are not black-holed), because the responder will still respond properly to an AccECN request if it only supports classic ECN or no ECN at all, without any performance penalty.

I shall also make the point in S.3.2.1.4 that if an ECT SYN is black-holed, it might still be possible to request AccECN, but without ECT on the SYN.


5) section 3.2.1.4:
OLD
"To expedite connection set-up if, after sending an ECT SYN, the
   retransmission timer expires, the TCP initiator SHOULD send a SYN
   with the not-ECT codepoint in the IP header and not attempt to
   negotiate AccECN.  It would make sense to also remove any other
   experimental fields or options on the SYN, but that will depend on
   the specification of the other option(s). "
I wouldn't make any statements about things that are not in scope of this doc, so I would remove the later part (including fallback for AccECN):
NEW
"To expedite connection set-up if, after sending an ECT SYN, the
   retransmission timer expires, the TCP initiator SHOULD send a SYN
   with the not-ECT codepoint in the IP header."
[BB] I agree that I shouldn't have said to not attempt AccECN. So I will use your new text.

But I disagree about not even mentioning that the cause might be other experimental options, and to encourage the reader to read those specs as well. I'll use the following unless you shout:

"To expedite connection set-up if, after sending an ECT SYN, the
   retransmission timer expires, the TCP initiator SHOULD send a SYN
   with the not-ECT codepoint in the IP header.  If other experimental
   fields or options were on the SYN, it will also be necessary to follow
   their specifications for fall-back too. It would make sense to co-
   ordinate all the strategies for fall-back in order to isolate the specific
   cause of the problem."


6) section 3.2.2 says:
"In either case no change is required to RFC 5562 or the AccECN specification."

It would probably be good to also state in this draft what the procedure is that is described in RFC5562:
"When the responder (node B) receives the ECN-Echo packet reporting
   the Congestion Experienced indication in the SYN/ACK packet, the
   responder sets the initial congestion window to one segment, instead
   of two segments as allowed by [RFC2581], or three or four segments
   allowed by [RFC3390].  As illustrated in Figure 2, if the responder
   (node B) receives an ECN-Echo packet informing it of a Congestion
   Experienced indication on its SYN/ACK packet, the responder sends a
   SYN/ACK packet that is not ECN-Capable, in addition to setting the
   initial window to one segment.  The responder does not advance the
   send sequence number.  The responder also sets the retransmission
   timer.  The responder follows RFC 2988 [RFC2988] in setting the RTO
   (retransmission timeout)."
[BB] Two responses:

1) I think it's dangerous to quote a small part of another spec. as if it's a good summary of the behaviour. This loses all the detail in RFC 5562 (e.g. what if the responder implements SYN cookies, yada yada).

2) Oh dear. I had forgotten that RFC5562 specified a different protocol to the "ECN+" paper. It's ultra-ultra-conservative.

So, I think we had better include the original proposal in the "ECN+" paper within the generalized ECN draft, and include a counter-argument to RFC5562 as well as to RFC3168.


7) section 3.2.3:
OLD
"It MAY also
   implement AckCC [RFC5690] to regulate the pure ACK rate, but this is
   not required.  Note that, in comparison, [RFC5681] does not require..."
NEW
"It MAY also
   implement Acknowledgement Congestion Control (AckCC) [RFC5690] to regulate the pure ACK rate, but this is
   not required.  Note that, in comparison, TCP Congestion Control [RFC5681] does not require..."
[BB] OK.


8) section 3.2.3:
"The question of whether the receiver of pure ACKs is required to feed back any CE marks on them is a matter for the relevant feedback specification ([RFC3168] or [I-D.ietf-tcpm-accurate-ecn]).  It is outside the scope of the present specification."
However, as mention about I believe that RFC3168 does not say anything about feedback how to handle CE marks of pure ACK because it assumes that this case never occurs. So that might be implementation dependent, so it might be better to spell that out:
"[I-D.ietf-tcpm-accurate-ecn] includes handling of control packets. However, [RFC3168] does not specify handling of pure ACKs that are CE mark, so it might be implementation specific if feedback is provided or not."
[BB] OK.

Anyway, this will be moot if we do not allow ECT on Pure ACKs unless AccECN has been negotiated.

Related to this comment in the same section:
"DISCUSSION: Before the AccECN specification is published, a
      requirement to count CE marks on all packets could be added."
I pretty sure that this is what the AccECN draft is doing but I can double check. If not it clearly should be added. Maybe it's not spelled out clearly enough. I'll check!

[BB] You're right. I will fix this.

I too thought that AccECN counted CE on pure ACKs, but I checked the AccECN draft by searching for "pure ACK" and couldn't find any mention of this aspect. However, I've just done a more thorough search, and you're right - it says so three times, but none use the words "pure ACK":
   The fourth counts
   the number of packets arriving marked with a CE codepoint (including
   control packets without payload if they are CE-marked).
[...]
   The CE
   packet counter includes control packets that do not have payload
   data,
[...]
   The CE packet counter (r.cep), counts the number of packets
   the host receives with the CE code point in the IP ECN field,
   including CE marks on control packets without data.


9) section 3.2.6.1:
OLD
"The following factors have been considered before deciding whether
   ECT ought to be allowed on a RST message:"
NEW
"The following factors have been considered before deciding whether
   the RST message should be ECT marked:"
[BB]
* I had already edited out any occurrence of the phrase "ECT marked" (because "marked" generally implies a congestion marking, so this could be misinterpreted).
* I always avoid the word "should" in lower case.
* I try to avoid writing sentences in the passive (but I missed this one).

Other than all that, I grok what you mean; I will use:

"The following factors have been considered before deciding whether
   the sender ought to set ECT on a RST message:"

That's it. So nothing big. Let move on with this draft!

[BB]
Cheers


Bob




On 18.04.2017 11:40, Bob Briscoe wrote:
David, Mirja, list,

Thanks again for your reviews of the -00. I've been busy over the w/e after
thinking more deeply about some of your comments and after realizing that
RFC3168 contained an assumption that a single pure ACK implies that all other
packets in that direction are pure ACKs, which is not true in general.

We've produced another rev (draft-bagnulo-tcpm-generalized-ecn-02
<https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-02>).

This is a general invitation for anyone on the list, including you two, to
review this again, so we can ask for an informed adoption call.

We need people with the following expertise:
* TCP hijacking and DoS/flooding attacks
* Specific TCP implementations (Linux, FreeBSD, iOS, Windows, etc).
* All the common variants of TCP

We have identified clearly where decisions are needed.
As well as where more measurements are needed.

Main changes:
* Moved more discursive text from S.3 (Spec) to S.5 (Arguments against RFCs)
* Major changes to Pure ACK sections and the reliability argument, to address
Mirja's arguments better, and to separately address cwnd response (required)
and ACK-rate response (optional but not required).
* Referred to Network Behaviour in ecn-experimentation, rather than repeating
it.
* Fixed description of window probe.
* Recommended RFC 5961, which gives much stronger packet validity checks for
retransmissions, RSTs & FINs.

Cheers


Bob


On 14/04/17 02:13, Bob Briscoe wrote:
David,

I hope you will find that I have addressed all your concerns - so at least
you will be able to understand it now.
The draft is now unexpired.

I have also addressed all the points in Mirja's review (some intersecting
with your points).

You will see that it's actually turned into quite a major re-write. The
diff is nearly total, mainly cos I was turning Spanglish into English as I
went (Marcelo, it was quite understandable, but just not quite how a native
English speaker would say it).

However, I have changed technical points in a few places too - the more one
thinks about this, the more depth one finds.

I just noticed I missed one of your nits (shortening the definition of
Retransmission), which I have already fixed in my local copy of the xml for
the next rev.



Bob


On 08/04/17 01:11, Bob Briscoe wrote:
David,

On 2) I intend to replace the whole of "3.1 Network behaviour" with the
following, which calls out the cases explicitly:

Previously RFC3168 required the sender to set not-ECT on certain TCP
control packets. Some readers might have erroneously interpreted this
aspect of RFC3168 as a requirement for firewalls, intrusion detection
systems, etc. to check and enforce this behaviour. Now that the present
experimental specification allows TCP senders to set ECT on all TCP
packets (control and data), it needs to be clear that a firewall (or any
network node) SHOULD NOT treat any ECT packet differently dependent on
what type of TCP packet it is.

One potential exception is envisaged, otherwise the previous sentence
could have said "MUST NOT" rather than "SHOULD NOT". The exception allows
a security function that has detected an ongoing attack to drop more ECT
marked SYNs than not-ECT marked SYNs. Such a policy SHOULD NOT be applied
routinely. It SHOULD only be applied if an attack is detected, and then
only if it is determined that the ECT capability is intensifying the attack.


Bob

On 07/04/17 23:33, Black, David wrote:
Bob,

Two comments:

1) I'll wait for new text before commenting further on Accurate ECN vs.
vanilla RFC 3168 ECN.  The current text left me somewhat confused, and
the summary of changes from RFC 3168 will almost certainly help.

2) On network node treatment of ECT, RFC 3168 is brief, e.g. (Section 5,
top of p.7):

    The CE codepoint '11' is set by a router to indicate congestion to
    the end nodes.

One wants to avoid text that could be read as modifying that sentence by
adding possible exceptions for TCP control packets and/or retransmissions.

[BB] Unfortunately, RFC3168 does not specify anything about network node
forwarding behaviour wrt ECT. So some firewall policies could have
decided to block any TCP control packets that contravene RFC3168. That's
why we wrote this section.
If "firewalls" is what was meant, use that word ;-) ... or as you write ...

However I admit that, by not explaining that DPI was the problem we were
trying to solve, rather than removing any ambiguity that might have been
interpreted as a need for DPI. We'll fix this.
In doing so, please keep in mind that in this draft, discussion of
forwarding  and dropping behavior is implicitly about router queue
management, not middlebox access control (e.g., based on DPI), so access
control has to be called out explicitly when that is what is meant.

Thanks, --David





--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/ 


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------516AAE1E979D1EB3AA7FCBAC-- From nobody Mon Apr 24 13:57:11 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 6BAB21201F8 for ; Mon, 24 Apr 2017 13:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 rzcx55qjp2vV for ; Mon, 24 Apr 2017 13:57:04 -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 74FDA1272E1 for ; Mon, 24 Apr 2017 13:57:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3wBdv24K3rz15MDK; Mon, 24 Apr 2017 22:57:02 +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 2HyDVxl0VjRw; Mon, 24 Apr 2017 22:57:00 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (pD9E11120.dip0.t-ipconnect.de [217.225.17.32]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 24 Apr 2017 22:57:00 +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: Date: Mon, 24 Apr 2017 22:56:59 +0200 Cc: "Black, David" , "tcpm@ietf.org" , marcelo bagnulo braun Content-Transfer-Encoding: quoted-printable Message-Id: References: <3d53f6a4-697b-0c7a-8c71-524890312beb@bobbriscoe.net> <5a4e46a0-bde7-8de5-f6a3-354f06fd9058@bobbriscoe.net> <94ff22d6-69b3-164a-8bdb-07149f3e58b3@bobbriscoe.net> <9796d961-292e-e257-a2d8-c0321f61b31a@bobbriscoe.net> <0533c69e-617e-fb5d-af97-4a603eb29d8d@tik.ee.ethz.ch> To: Bob Briscoe X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tcpm] Review of draft-bagnulo-tcpm-generalized-ecn (David Black) 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, 24 Apr 2017 20:57:09 -0000 Sorry, yes to be clear: this feedback was all meant as individual. = It=E2=80=99s the chairs decision to run the adoption call. It=E2=80=99s = just my personal opinion that we could do this right now with the = current version (or we can also wait for your next version if you anyway = working on it right now). Mirja > Am 24.04.2017 um 21:41 schrieb Bob Briscoe : >=20 > Mirja, >=20 > Thx for the rapid and extensive re-review.=20 >=20 > I shall get on with making the edits outlined below and, unless I see = objections to anything in this email, I'll submit an update when done. >=20 >=20 > On 20/04/17 18:26, Mirja K=C3=BChlewind wrote: >> Hi Bob,=20 >>=20 >> given it seems I spend most of my time these days to worry about = different ECN-related RFCs, I've also reviewed this draft (actually only = sections 1-4; I may review section 5 at a later point of time but I = trust you that you have addressed my previous comments here).=20 >>=20 >> Here is my feedback as individual contributor: In general, I'm happy = with the spec and the overall draft now. Thanks for the work! It reads = very well now. I have a few minor technical comments and some editorial = proposals and a proposal to restructure some smaller parts below. =20= >>=20 >> So te document is in really good shape and the technical = specification is good. So I think that this version is definitely ready = for adoption and would like to see an adoption call very soon!=20 > [BB] Strongly agree :) >=20 > Seriously, I think you should make it clear whether you are saying = this as AD or individual. >=20 >>=20 >> Mirja=20 >>=20 >> -----------------=20 >> High-level, minor technical points:=20 >>=20 >> 1) The description of TFO in section 4.2 is not quite correct:=20 >> "If a TFO initiator has cached that the server supported ECN in the=20= >> previous connection, it would be safe to set ECT on any data = segments=20 >> it sends before a SYN-ACK returns from the responder (server). = Note=20 >> that there is no space in the SYN-ACK itself (whether classic or=20= >> AccECN feedback has been negotiated) to include feedback about any = CE=20 >> on data packets. Nonetheless, it is safe to set ECT on data = packets=20 >> within the handshake because any CE-marking on these data segments=20= >> can be fed back by the responder on the first data segment it = sends=20 >> after the SYN-ACK (or on an additional pure ACK if it has no more=20= >> data to send)."=20 >> TFO allows the initiator to send data in the SYN but no additional = data packets, and the responder to send the SYN/ACK as well as an IW = full of data packets. So I think the problem here goes away. However, = accECN actually does feedback information of CE marked data in the = SYN/ACK because the SYN/ACK carries the AccECN option that holds this = information.=20 >=20 > [BB] I'll remove the whole section about TFO, and instead include a = brief sentence explaining why TFO is not relevant in the intro to S.4. = Thanks. >=20 > I was thinking that there is nothing in TFO [RFC7413] to preclude the = initiator sending data segments before receiving the SYN-ACK. > However, you've made me think this through further, and I've realized = the initiator would have to send data without the ACK flag set (or with = the ACK flag faked but no valid ackno). Altho the TFO cookie would make = this safe from a security perspective, it's not going to happen due to = middleboxes. >=20 >=20 >> 2) Regarding this question in section 3.2.3=20 >> "DISCUSSION: An AccECN deployment or an implementation of RFC 3168=20 >> that feeds back CE on pure ACKs will be at a disadvantage = compared=20 >> to an RFC 3168 implementation that does not. To solve this, = the=20 >> WG could decide to prohibit setting ECT on pure ACKs unless = AccECN=20 >> has been negotiated."=20 >> I've checked REF3168 and it does not say anything about handling of = pure ACKs that are CE marked because it probably just assumes that that = case will never happen. However, implementations may or may not provide = feedback. I think I would support to only have pure ACKs ECT marked if = AccECN is supported because of this. I also think that losing ACKs is = probably less bad that losing any of the other (control) packets that = are discussed in this document. So I think this restriction would be = okay.=20 > [BB] OK, it's good to have one opinion on this. > We'd like to hear more opinions before changing this tho. >=20 > FYI, RFC3168 does vaguely hint that the receiver of Pure ACKs carrying = ECT (or CE) probably ought not to reject them (but it doesn't say what = to do with a CE mark). In S.6.1.4 it says: > For the current generation of TCP congestion control algorithms, > pure acknowledgement packets [...] MUST be sent with the not-ECT = codepoint. >=20 > Saying "current generation" implies a future generation might change = this, which ought to make an implementer wary of rejecting ECT on Pure = ACKs. >=20 >>=20 >> 3) This is a suggestion to improve the situation, however it probably = needs further discussion: in sect 3.2.1.4 you say that one should still = use ECT SYNs even if a connection attempt previously failed. Maybe we = can use a smaller time-out in this case...?=20 > [BB] I'm wary of jumping to the conclusion that a loss is not due to = congestion just because it's becoming more likely it could be due to a = black hole. E.g. if there's a black hole, the probability of losing an = ECT SYN is 100%, but if the underlying loss level is 1%, the probability = that 2 SYNs are lost is 0.01% as an alternative.=20 >=20 > So, when 2 ECT SYNs at different times have timed out, but non-ECT = SYNs got through, I suppose it's possible to argue that the probability = that the second loss was due to congestion has reduced. So the timeout = could be reduced. >=20 > I'll add this, and flag it "FOR DISCUSSION". >=20 >>=20 >> And now first a couple of comments on the structure:=20 >>=20 >> 1) I would move the network behavior in any case AFTER the endpoint = behavior spec. Actually I would even propose to have it in a different = section (not under 3. Specification) because it actually does not = specify anything; it only comments on the current situation.=20 > [BB] I did consider this when I removed the normative text from this = section. But this this section is intended to do more than just comment. = We want it to incorporate the "SHOULD" in ecn-experimentation as part of = the specification for this experiment. And we figured this text is short = enough to put first, to reduce the chance it gets buried and overlooked = operators, without distracting host implementers too much. >=20 > So I would rather make the following change than move the section: > s/So operators are encouraged to alter their firewall rules/ > /So operators are RECOMMENDED to alter their firewall rules/ >=20 > Rationale: When updates to a system for an experiment are all spread = about in different docs, it's not just helpful but also necessary to = call out all the parts in their different docs. Similarly, we have = incorporated RFC5562 (ECT on SYN-ACK) and AccECN into this draft - both = as normative references. >=20 >>=20 >> 2) And then you would actually not need a separate subsection for the = Endpoint behavior; you could just call section 3 "Specification of = Endpoint Behavior" or even "Specification of Sender Behavior" and move = the first two paragraphs of section 3.2 to the intro that explains that = this mechanism/document only needs to talk about the sender behavior.=20 > [BB] Depends on resolution of the above. >>=20 >> 3) I would include the text on TFO and IW10 directly into section = 3.2.1.3 instead of just giving a reference to a later section.=20 > [BB] This is a matter of style. I prefer to distinguish normative = dependencies between=20 > * dependencies that are essential,=20 > * and then to split optional dependencies between: > - STD > - EXPT >=20 > The above structure forces implementers (and authors) to make = dependencies modular, in case an experiment fails. E.g. we do not yet = know whether an attack will be invented against TFO.=20 >=20 > For instance, look at all the mess that has had to be cleared up = because everyone assumed the ECN nonce experiment would succeed. >=20 >>=20 >> 4) The rationale in section 3.2.6.1 could also go somewhere into = section 5 (to keep the spec part as short as possible). At least I think = you don't need the whole text here. If you want to keep something you = probably only need the second paragraph (and not an own subsection).=20 > [BB] The scope of Section 5 is (currently) countering arguments in = other RFCs (mostly RFC3168). > ECT on RSTs wasn't mentioned in an RFC so far, which is I why I put = this section here. >=20 > One solution would be to rename section 5 "Rationale". Then I would be = happy to move 3.2.6.1 to section 5. I'll do that. >=20 >>=20 >> 5) Maybe have the section on Retransmissions (3.2.7.) earlier before = RST, FIN, and Window probe because it seems more "important". But = actually I don't think the order matters that much. So this is a minor = comment only.=20 > [BB] Currently the order is chosen to match the order of the lists in = the introduction so they can be summarized as "control packets and = retransmissions". I'll leave it as it is. >>=20 >> 6) The paragraph on SCTP (section 4.1) could go into the intro. And = if you then also integrate the TFP and IW10 stuff into section 3.2.1.3, = section 4 would actually go away completely.=20 > [BB] Now, with the removal of the TFO section, none of S.4 contains = anything normative. Now it is just saying "For all these variants, = here's why you don't need to do anything different". So I am inclined to = move it /after/ section 5. >=20 > I certainly don't want to integrate the TFO and IW10 comments into the = spec section, because that would just complicate the spec with text that = essentially ends up saying "You didn't need to read this to implement = the spec". >=20 > I also don't want to add a detailed para about SCTP to a nice 3-para = Intro to a spec about a modification to TCP. > However, I agree that "scope" is one of the important things to cover = in an introduction. >=20 > In summary, I would rather move this section about variants to after = S.5. And in the intro, say this is an experimental modification to = standards track TCP, but also flag that it discusses (non-)interaction = with variants such as SCTP, TFO, IW10.=20 >=20 >>=20 >> And now a bunch of editorial comments/proposals:=20 >>=20 >> 1) I though that it might be good to mention AccECN already in the = Intro because that the enabler for the SYN part...=20 > [BB] OK, that would be sensible, along with the above sentence about = variants. Will do. >>=20 >> 2) section 1.1:=20 >> OLD=20 >> "Preventing TCP control=20 >> packets from obtaining the benefits of ECN would not only expose = them=20 >> to the prevailing level of congestion loss, but it would also stop=20= >> them from being classified into the low latency (L4S) queue, which=20= >> would greatly degrade L4S performance."=20 >> I think this can be phrased more general:=20 >> NEW=20 >> "Preventing TCP control=20 >> packets from obtaining the benefits of ECN would not only expose = them=20 >> to the prevailing level of congestion loss, but it would also put = control=20 >> packet into a different queue with different network treatment, = which=20 >> may also lead to reordering and therefore can greatly degrade TCP=20= >> performance."=20 > [BB] Good point. Given this sentence was in a para about L4S, I shall = split it off and make it into a summary section. >>=20 >>=20 >> 3) section 3.2.1.1:=20 >> OLD=20 >> "Accurate ECN (AccECN)=20 >> feedback [I-D.ietf-tcpm-accurate-ecn] provides two codepoints in = the=20 >> SYN-ACK"=20 >> NEW=20 >> "Accurate ECN (AccECN)=20 >> feedback [I-D.ietf-tcpm-accurate-ecn] provides one flag in the=20 >> SYN-ACK"=20 >> I think that's clearer, at least for me.=20 > [BB] Eh? I'm not going to change this, cos the word flag would imply = this is a bit with a meaning orthogonal to the other bits. >=20 > Here's a copy of the relevant part of the table... > | NS CWR ECE | | > | 0 1 0 | AccECN | > | 1 1 0 | AccECN (CE on SYN) | > | 1 0 1 | classic ECN |=20 > ... etc >=20 >=20 > The first bit only distinguishes "whether or not the SYN arrived = marked CE" when the 3-bit codepoint as a whole is 'X10'. So it's not a = flag, it's 2 codepoints. >=20 >>=20 >> 4) section 3.2.1.2=20 >> This sentence is correct but I had to read it twice to make sure it's = correct:=20 >> "Servers that=20 >> do not support ECN as a whole probably do not need to be recorded=20= >> separately from non-support of AccECN because, even when a server=20= >> does not support classic [RFC3168] ECN, there is no performance=20 >> penalty in always requesting to use it."=20 >> NEW=20 >> "Servers that=20 >> do not support ECN as a whole probably do not need to be recorded=20= >> separately from non-support of AccECN. Meaning, if AccECN is noted = as not supported by the server, the initiator may decide to not mark the = SAN as ECT but it still may try to negotiate classic ECN or even AccECN = (to quickly detect server upgrades)."=20 > [BB] I realize now that this text is all wrong. I shall attempt a = rewrite. >=20 > I now realize my heading of 3.2.1.2 is wrong; it was not meant to be = about "Caching Failed Connection Attempts". It was meant to be mostly = about "Caching Lack of Recognition of ECT SYNs", with just a reference = forward to caching failed connection attempts ("3.2.1.4 Fall-Back = Following No Response to an ECT SYN").=20 >=20 > I intended to say that, when a server is cached as not supporting = AccECN, subsequent attempts should still request AccECN, but not with = ECT on the SYN. Because there is no harm in always attempting to = negotiate AccECN (as long as such requests are not black-holed), because = the responder will still respond properly to an AccECN request if it = only supports classic ECN or no ECN at all, without any performance = penalty.=20 >=20 > I shall also make the point in S.3.2.1.4 that if an ECT SYN is = black-holed, it might still be possible to request AccECN, but without = ECT on the SYN. >=20 >>=20 >> 5) section 3.2.1.4:=20 >> OLD=20 >> "To expedite connection set-up if, after sending an ECT SYN, the=20 >> retransmission timer expires, the TCP initiator SHOULD send a SYN=20= >> with the not-ECT codepoint in the IP header and not attempt to=20 >> negotiate AccECN. It would make sense to also remove any other=20 >> experimental fields or options on the SYN, but that will depend on=20= >> the specification of the other option(s). "=20 >> I wouldn't make any statements about things that are not in scope of = this doc, so I would remove the later part (including fallback for = AccECN):=20 >> NEW=20 >> "To expedite connection set-up if, after sending an ECT SYN, the=20 >> retransmission timer expires, the TCP initiator SHOULD send a SYN=20= >> with the not-ECT codepoint in the IP header."=20 > [BB] I agree that I shouldn't have said to not attempt AccECN. So I = will use your new text. >=20 > But I disagree about not even mentioning that the cause might be other = experimental options, and to encourage the reader to read those specs as = well. I'll use the following unless you shout: >=20 > "To expedite connection set-up if, after sending an ECT SYN, the=20 > retransmission timer expires, the TCP initiator SHOULD send a SYN=20= > with the not-ECT codepoint in the IP header. If other experimental=20= > fields or options were on the SYN, it will also be necessary to = follow=20 > their specifications for fall-back too. It would make sense to co- > ordinate all the strategies for fall-back in order to isolate the = specific=20 > cause of the problem." >=20 >>=20 >> 6) section 3.2.2 says:=20 >> "In either case no change is required to RFC 5562 or the AccECN = specification."=20 >>=20 >> It would probably be good to also state in this draft what the = procedure is that is described in RFC5562:=20 >> "When the responder (node B) receives the ECN-Echo packet reporting=20= >> the Congestion Experienced indication in the SYN/ACK packet, the=20= >> responder sets the initial congestion window to one segment, = instead=20 >> of two segments as allowed by [RFC2581], or three or four segments=20= >> allowed by [RFC3390]. As illustrated in Figure 2, if the = responder=20 >> (node B) receives an ECN-Echo packet informing it of a Congestion=20= >> Experienced indication on its SYN/ACK packet, the responder sends = a=20 >> SYN/ACK packet that is not ECN-Capable, in addition to setting the=20= >> initial window to one segment. The responder does not advance the=20= >> send sequence number. The responder also sets the retransmission=20= >> timer. The responder follows RFC 2988 [RFC2988] in setting the = RTO=20 >> (retransmission timeout)."=20 > [BB] Two responses: >=20 > 1) I think it's dangerous to quote a small part of another spec. as if = it's a good summary of the behaviour. This loses all the detail in RFC = 5562 (e.g. what if the responder implements SYN cookies, yada yada). >=20 > 2) Oh dear. I had forgotten that RFC5562 specified a different = protocol to the "ECN+" paper. It's ultra-ultra-conservative. >=20 > So, I think we had better include the original proposal in the "ECN+" = paper within the generalized ECN draft, and include a counter-argument = to RFC5562 as well as to RFC3168. >=20 >>=20 >> 7) section 3.2.3:=20 >> OLD=20 >> "It MAY also=20 >> implement AckCC [RFC5690] to regulate the pure ACK rate, but this = is=20 >> not required. Note that, in comparison, [RFC5681] does not = require..."=20 >> NEW=20 >> "It MAY also=20 >> implement Acknowledgement Congestion Control (AckCC) [RFC5690] to = regulate the pure ACK rate, but this is=20 >> not required. Note that, in comparison, TCP Congestion Control = [RFC5681] does not require..."=20 > [BB] OK. >>=20 >>=20 >> 8) section 3.2.3:=20 >> "The question of whether the receiver of pure ACKs is required to = feed back any CE marks on them is a matter for the relevant feedback = specification ([RFC3168] or [I-D.ietf-tcpm-accurate-ecn]). It is = outside the scope of the present specification."=20 >> However, as mention about I believe that RFC3168 does not say = anything about feedback how to handle CE marks of pure ACK because it = assumes that this case never occurs. So that might be implementation = dependent, so it might be better to spell that out:=20 >> "[I-D.ietf-tcpm-accurate-ecn] includes handling of control packets. = However, [RFC3168] does not specify handling of pure ACKs that are CE = mark, so it might be implementation specific if feedback is = provided or not."=20 > [BB] OK. >=20 > Anyway, this will be moot if we do not allow ECT on Pure ACKs unless = AccECN has been negotiated. >>=20 >> Related to this comment in the same section:=20 >> "DISCUSSION: Before the AccECN specification is published, a=20 >> requirement to count CE marks on all packets could be added."=20= >> I pretty sure that this is what the AccECN draft is doing but I can = double check. If not it clearly should be added. Maybe it's not spelled = out clearly enough. I'll check!=20 >=20 > [BB] You're right. I will fix this. >=20 > I too thought that AccECN counted CE on pure ACKs, but I checked the = AccECN draft by searching for "pure ACK" and couldn't find any mention = of this aspect. However, I've just done a more thorough search, and = you're right - it says so three times, but none use the words "pure = ACK": > The fourth counts > the number of packets arriving marked with a CE codepoint = (including > control packets without payload if they are CE-marked). >=20 > [...] > The CE > packet counter includes control packets that do not have payload > data, >=20 > [...] > The CE packet counter (r.cep), counts the number of packets > the host receives with the CE code point in the IP ECN field, > including CE marks on control packets without data. >=20 >=20 >>=20 >> 9) section 3.2.6.1:=20 >> OLD=20 >> "The following factors have been considered before deciding whether=20= >> ECT ought to be allowed on a RST message:"=20 >> NEW=20 >> "The following factors have been considered before deciding whether=20= >> the RST message should be ECT marked:"=20 > [BB]=20 > * I had already edited out any occurrence of the phrase "ECT marked" = (because "marked" generally implies a congestion marking, so this could = be misinterpreted).=20 > * I always avoid the word "should" in lower case. > * I try to avoid writing sentences in the passive (but I missed this = one). >=20 > Other than all that, I grok what you mean; I will use: >=20 > "The following factors have been considered before deciding whether=20 > the sender ought to set ECT on a RST message:"=20 >>=20 >> That's it. So nothing big. Let move on with this draft!=20 >=20 > [BB]=20 > Cheers >=20 >=20 > Bob >>=20 >>=20 >>=20 >>=20 >> On 18.04.2017 11:40, Bob Briscoe wrote:=20 >>> David, Mirja, list,=20 >>>=20 >>> Thanks again for your reviews of the -00. I've been busy over the = w/e after=20 >>> thinking more deeply about some of your comments and after realizing = that=20 >>> RFC3168 contained an assumption that a single pure ACK implies that = all other=20 >>> packets in that direction are pure ACKs, which is not true in = general.=20 >>>=20 >>> We've produced another rev (draft-bagnulo-tcpm-generalized-ecn-02=20 >>> = ).=20 >>>=20 >>> This is a general invitation for anyone on the list, including you = two, to=20 >>> review this again, so we can ask for an informed adoption call.=20 >>>=20 >>> We need people with the following expertise:=20 >>> * TCP hijacking and DoS/flooding attacks=20 >>> * Specific TCP implementations (Linux, FreeBSD, iOS, Windows, etc).=20= >>> * All the common variants of TCP=20 >>>=20 >>> We have identified clearly where decisions are needed.=20 >>> As well as where more measurements are needed.=20 >>>=20 >>> Main changes:=20 >>> * Moved more discursive text from S.3 (Spec) to S.5 (Arguments = against RFCs)=20 >>> * Major changes to Pure ACK sections and the reliability argument, = to address=20 >>> Mirja's arguments better, and to separately address cwnd response = (required)=20 >>> and ACK-rate response (optional but not required).=20 >>> * Referred to Network Behaviour in ecn-experimentation, rather than = repeating=20 >>> it.=20 >>> * Fixed description of window probe.=20 >>> * Recommended RFC 5961, which gives much stronger packet validity = checks for=20 >>> retransmissions, RSTs & FINs.=20 >>>=20 >>> Cheers=20 >>>=20 >>>=20 >>> Bob=20 >>>=20 >>>=20 >>> On 14/04/17 02:13, Bob Briscoe wrote:=20 >>>> David,=20 >>>>=20 >>>> I hope you will find that I have addressed all your concerns - so = at least=20 >>>> you will be able to understand it now.=20 >>>> The draft is now unexpired.=20 >>>>=20 >>>> I have also addressed all the points in Mirja's review (some = intersecting=20 >>>> with your points).=20 >>>>=20 >>>> You will see that it's actually turned into quite a major re-write. = The=20 >>>> diff is nearly total, mainly cos I was turning Spanglish into = English as I=20 >>>> went (Marcelo, it was quite understandable, but just not quite how = a native=20 >>>> English speaker would say it).=20 >>>>=20 >>>> However, I have changed technical points in a few places too - the = more one=20 >>>> thinks about this, the more depth one finds.=20 >>>>=20 >>>> I just noticed I missed one of your nits (shortening the definition = of=20 >>>> Retransmission), which I have already fixed in my local copy of the = xml for=20 >>>> the next rev.=20 >>>>=20 >>>>=20 >>>>=20 >>>> Bob=20 >>>>=20 >>>>=20 >>>> On 08/04/17 01:11, Bob Briscoe wrote:=20 >>>>> David,=20 >>>>>=20 >>>>> On 2) I intend to replace the whole of "3.1 Network behaviour" = with the=20 >>>>> following, which calls out the cases explicitly:=20 >>>>>=20 >>>>> Previously RFC3168 required the sender to set not-ECT on certain = TCP=20 >>>>> control packets. Some readers might have erroneously interpreted = this=20 >>>>> aspect of RFC3168 as a requirement for firewalls, intrusion = detection=20 >>>>> systems, etc. to check and enforce this behaviour. Now that the = present=20 >>>>> experimental specification allows TCP senders to set ECT on all = TCP=20 >>>>> packets (control and data), it needs to be clear that a firewall = (or any=20 >>>>> network node) SHOULD NOT treat any ECT packet differently = dependent on=20 >>>>> what type of TCP packet it is.=20 >>>>>=20 >>>>> One potential exception is envisaged, otherwise the previous = sentence=20 >>>>> could have said "MUST NOT" rather than "SHOULD NOT". The exception = allows=20 >>>>> a security function that has detected an ongoing attack to drop = more ECT=20 >>>>> marked SYNs than not-ECT marked SYNs. Such a policy SHOULD NOT be = applied=20 >>>>> routinely. It SHOULD only be applied if an attack is detected, and = then=20 >>>>> only if it is determined that the ECT capability is intensifying = the attack.=20 >>>>>=20 >>>>>=20 >>>>> Bob=20 >>>>>=20 >>>>> On 07/04/17 23:33, Black, David wrote:=20 >>>>>> Bob,=20 >>>>>>=20 >>>>>> Two comments:=20 >>>>>>=20 >>>>>> 1) I'll wait for new text before commenting further on Accurate = ECN vs.=20 >>>>>> vanilla RFC 3168 ECN. The current text left me somewhat = confused, and=20 >>>>>> the summary of changes from RFC 3168 will almost certainly help.=20= >>>>>>=20 >>>>>> 2) On network node treatment of ECT, RFC 3168 is brief, e.g. = (Section 5,=20 >>>>>> top of p.7):=20 >>>>>>=20 >>>>>> The CE codepoint '11' is set by a router to indicate = congestion to=20 >>>>>> the end nodes.=20 >>>>>>=20 >>>>>> One wants to avoid text that could be read as modifying that = sentence by=20 >>>>>> adding possible exceptions for TCP control packets and/or = retransmissions.=20 >>>>>>=20 >>>>>>> [BB] Unfortunately, RFC3168 does not specify anything about = network node=20 >>>>>>> forwarding behaviour wrt ECT. So some firewall policies could = have=20 >>>>>>> decided to block any TCP control packets that contravene = RFC3168. That's=20 >>>>>>> why we wrote this section.=20 >>>>>> If "firewalls" is what was meant, use that word ;-) ... or as you = write ...=20 >>>>>>=20 >>>>>>> However I admit that, by not explaining that DPI was the problem = we were=20 >>>>>>> trying to solve, rather than removing any ambiguity that might = have been=20 >>>>>>> interpreted as a need for DPI. We'll fix this.=20 >>>>>> In doing so, please keep in mind that in this draft, discussion = of=20 >>>>>> forwarding and dropping behavior is implicitly about router = queue=20 >>>>>> management, not middlebox access control (e.g., based on DPI), so = access=20 >>>>>> control has to be called out explicitly when that is what is = meant.=20 >>>>>>=20 >>>>>> Thanks, --David=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> --=20 >>> ________________________________________________________________=20 >>> Bob Briscoe http://bobbriscoe.net/=20 >>>=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe =20 > http://bobbriscoe.net/ From nobody Tue Apr 25 13:34:52 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 DF1D912951C; Tue, 25 Apr 2017 13:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 SLuAbuDHuy4N; Tue, 25 Apr 2017 13:34:49 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40118.outbound.protection.outlook.com [40.107.4.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16090129466; Tue, 25 Apr 2017 13:34:49 -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=JjKUp9+fSqfzVcHGGPLMvMnKopZi57NBO8QL8Lzcevk=; b=pCWBTGw+1isgkPVN3C1Cx3ewp7mD57eR7L9STKakJq3aY4szcKEDAKAwvFATnsyOp+cAtpX5BYDCpYlb20BiJe5ppBWMMtnpUEjsZvKvyowUhAjet4+9eu2XMBmjyL+22jJmck548wdg/62ZOtrpWm296BhHq8UdJkb3ystM6xI= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2545.eurprd07.prod.outlook.com (10.173.92.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Tue, 25 Apr 2017 20:34:46 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1061.010; Tue, 25 Apr 2017 20:34:46 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Joe Touch , Tom Herbert CC: tsvwg , "tcpm@ietf.org" Thread-Topic: [tsvwg] Inconsistencies between TCP RFCs and Linux implementation (was Re: Comments on draft-touch-tsvwg-udp-option)s-08 Thread-Index: AQHSvfjgkRpnlSVAxE67P4m3suQfs6HWhEwAgAADG4CAAAIM0g== Date: Tue, 25 Apr 2017 20:34:46 +0000 Message-ID: References: <6e301f3d-0ec3-2ef3-eafa-6facdea0053d@isi.edu>, In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [25.163.180.4] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2545; 7:lf0A9WnqvsoxeLgOh8Zi3Qqr2v9rZfv2GqsJ6F2UjuduPrf9m3kgCnBXxESP8GUa4S1QuoUkHIhD+5w3ZhaEAY/s254RM257uQgZAR/eGVu59BfX1FfU1adFDsklZWzv+vJO3c6upj8Y9uxJkHpSxYk2iuHR+5InsB1/PZAKIi632wHNBqS7XPx9fnfsBCGTR9H3jSGIhp1t5Z9vzuUZDYF2rq5KggAVIf+CfW1uVf/nOrTMvUg+DY/p3EI4YRg4W6j1S0/LH3e9kmRe4RmArUHCf3ODx6kJcSoiOuWkiIyb23ZpQuIzONhNmCQdklTcbJpSjjM2XF9MkrHza2M/BA== x-ms-office365-filtering-correlation-id: 045241dc-6a21-4b74-fef3-08d48c1a8389 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2545; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(6072148); SRVR:AM5PR0701MB2545; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2545; x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39840400002)(39450400003)(39850400002)(39410400002)(39860400002)(102836003)(3846002)(8936002)(2900100001)(81166006)(6506006)(8676002)(86362001)(2950100002)(558084003)(6116002)(6436002)(25786009)(77096006)(5660300001)(74316002)(7696004)(33656002)(122556002)(7736002)(305945005)(4326008)(76176999)(50986999)(230783001)(54356999)(66066001)(38730400002)(53936002)(6246003)(3280700002)(55016002)(9686003)(2906002)(54906002)(2171002)(3660700001)(99286003)(229853002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2545; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 20:34:46.7697 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2545 Archived-At: Subject: Re: [tcpm] [tsvwg] Inconsistencies between TCP RFCs and Linux implementation (was Re: Comments on draft-touch-tsvwg-udp-option)s-08 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, 25 Apr 2017 20:34:51 -0000 +TCPM > - an Experimental RFC (TFO) is deployed as default enabled in the wild beyond those actively involved in the experiment (see RFC2026) IMHO a 7413bis could target standards track. Of course, details would have = to be sorted out. Michael (with no hat on) From nobody Tue Apr 25 14:06: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 532A2128D3E; Tue, 25 Apr 2017 14:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 n-ExjhiJGk7x; Tue, 25 Apr 2017 14:06:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730591252BA; Tue, 25 Apr 2017 14:06:48 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3PL6BOL027817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 14:06:12 -0700 (PDT) To: "Scharf, Michael (Nokia - DE/Stuttgart)" , Tom Herbert Cc: tsvwg , "tcpm@ietf.org" References: <6e301f3d-0ec3-2ef3-eafa-6facdea0053d@isi.edu> From: Joe Touch Message-ID: Date: Tue, 25 Apr 2017 14:06:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] [tsvwg] Inconsistencies between TCP RFCs and Linux implementation (was Re: Comments on draft-touch-tsvwg-udp-option)s-08 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, 25 Apr 2017 21:06:49 -0000 On 4/25/2017 1:34 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > +TCPM > >> - an Experimental RFC (TFO) is deployed as default enabled in the > wild beyond those actively involved in the experiment (see RFC2026) > > IMHO a 7413bis could target standards track. Of course, details would have to be sorted out. It certainly could, but until then, Linux has jumped the gun. Joe From nobody Tue Apr 25 16:23: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 0D18813145A for ; Tue, 25 Apr 2017 16:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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=bobbriscoe.net 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 oD-dSvQfZ9vd for ; Tue, 25 Apr 2017 16:22:55 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 9AF7F12785F for ; Tue, 25 Apr 2017 16:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NgKeLzl7tsXEiqgsLNhBvUnxy0jV8LlY3+3AklXTxjg=; b=Kg0ItfJ1IClBiKdaGxOqO2MlcX SJotHxiyHgYmJmjkZl1Tban+Fz5Bk9Otbs4lVRvV2PGn18tx12mUTS2E5Mou3lAppZi87irK4RdGK SW0FOxbU4VDSC3zzcCVv7EL4w6qz1vI8PLGloSZ+Lyi88ZppiOj0UowcE282gM4w80DF8bfmluwNw 0rsFx3tpEHXIB20pFLQzC+j+VShVaxOR4wPqtxcH5JGgpbrAwHSaiQbwY7T5v2A/OQmI28xrYnN/L lvNNRwWWpzlRyMGQPofjpYBJXay0nCVIuu4jhqTIF8V0keqo7u8TjrHzLkeAyeVxYiNHFIIpawwS7 m/rZ96Jg==; Received: from 188.6.208.46.dyn.plus.net ([46.208.6.188]:59118 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d39nI-0005qJ-4m; Wed, 26 Apr 2017 00:22:52 +0100 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <3d53f6a4-697b-0c7a-8c71-524890312beb@bobbriscoe.net> <5a4e46a0-bde7-8de5-f6a3-354f06fd9058@bobbriscoe.net> <94ff22d6-69b3-164a-8bdb-07149f3e58b3@bobbriscoe.net> <9796d961-292e-e257-a2d8-c0321f61b31a@bobbriscoe.net> <0533c69e-617e-fb5d-af97-4a603eb29d8d@tik.ee.ethz.ch> Cc: "Black, David" , "tcpm@ietf.org" , marcelo bagnulo braun From: Bob Briscoe Message-ID: <712a8015-9f42-3da0-269f-6df126289711@bobbriscoe.net> Date: Wed, 26 Apr 2017 00:22:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] Review of draft-bagnulo-tcpm-generalized-ecn (David Black) 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, 25 Apr 2017 23:23:00 -0000 Mirja, list, Thanks again for your re-review. I've posted another non-trivial rev - now https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-03 The spec section is now succinct, with all rationale in a following section. I did all the changes I promised in my responses to your review below. One addition: cos I had added stuff about ECT on SYN-ACK, I also added stuff about the interaction between TFO and ECT on SYN-ACK. Still none of the TCP variants like TFO, IW10 require any normative text to be any different from ECT on all regular TCP packets. So I have relegated the variants section to the end, and not incorporated it into the main spec at all - didn't want unnecessary distractions in the normative spec text. Main changes this rev: * Added para to intro highlighting the main TCP variants that are discussed wrt (non)interaction (SCTP, IW10, TFO, AccECN). * Mostly new text in "3.2.1.2 Caching Lack of Support for ECT on SYNs", and some changes to 3.2.1.4 SYN fall-back * Completely new S.3.2.2 on SYN-ACK and new rationale S.4.3 for SYN-ACK (no longer uses RFC5622) * Renamed section heading "Discussion of the Arguments in the RFC Series" to "Rationale" * New rationale subsections for ECT on FINs and RSTs (the latter was previously elsewhere) * Moved TCP Variants section to the end and added interaction between ECT on SYN-ACK and IW10, TFO Bob On 24/04/17 21:56, Mirja Kühlewind wrote: > Sorry, yes to be clear: this feedback was all meant as individual. It’s the chairs decision to run the adoption call. It’s just my personal opinion that we could do this right now with the current version (or we can also wait for your next version if you anyway working on it right now). > > Mirja > > >> Am 24.04.2017 um 21:41 schrieb Bob Briscoe : >> >> Mirja, >> >> Thx for the rapid and extensive re-review. >> >> I shall get on with making the edits outlined below and, unless I see objections to anything in this email, I'll submit an update when done. >> >> >> On 20/04/17 18:26, Mirja Kühlewind wrote: >>> Hi Bob, >>> >>> given it seems I spend most of my time these days to worry about different ECN-related RFCs, I've also reviewed this draft (actually only sections 1-4; I may review section 5 at a later point of time but I trust you that you have addressed my previous comments here). >>> >>> Here is my feedback as individual contributor: In general, I'm happy with the spec and the overall draft now. Thanks for the work! It reads very well now. I have a few minor technical comments and some editorial proposals and a proposal to restructure some smaller parts below. >>> >>> So te document is in really good shape and the technical specification is good. So I think that this version is definitely ready for adoption and would like to see an adoption call very soon! >> [BB] Strongly agree :) >> >> Seriously, I think you should make it clear whether you are saying this as AD or individual. >> >>> Mirja >>> >>> ----------------- >>> High-level, minor technical points: >>> >>> 1) The description of TFO in section 4.2 is not quite correct: >>> "If a TFO initiator has cached that the server supported ECN in the >>> previous connection, it would be safe to set ECT on any data segments >>> it sends before a SYN-ACK returns from the responder (server). Note >>> that there is no space in the SYN-ACK itself (whether classic or >>> AccECN feedback has been negotiated) to include feedback about any CE >>> on data packets. Nonetheless, it is safe to set ECT on data packets >>> within the handshake because any CE-marking on these data segments >>> can be fed back by the responder on the first data segment it sends >>> after the SYN-ACK (or on an additional pure ACK if it has no more >>> data to send)." >>> TFO allows the initiator to send data in the SYN but no additional data packets, and the responder to send the SYN/ACK as well as an IW full of data packets. So I think the problem here goes away. However, accECN actually does feedback information of CE marked data in the SYN/ACK because the SYN/ACK carries the AccECN option that holds this information. >> [BB] I'll remove the whole section about TFO, and instead include a brief sentence explaining why TFO is not relevant in the intro to S.4. Thanks. >> >> I was thinking that there is nothing in TFO [RFC7413] to preclude the initiator sending data segments before receiving the SYN-ACK. >> However, you've made me think this through further, and I've realized the initiator would have to send data without the ACK flag set (or with the ACK flag faked but no valid ackno). Altho the TFO cookie would make this safe from a security perspective, it's not going to happen due to middleboxes. >> >> >>> 2) Regarding this question in section 3.2.3 >>> "DISCUSSION: An AccECN deployment or an implementation of RFC 3168 >>> that feeds back CE on pure ACKs will be at a disadvantage compared >>> to an RFC 3168 implementation that does not. To solve this, the >>> WG could decide to prohibit setting ECT on pure ACKs unless AccECN >>> has been negotiated." >>> I've checked REF3168 and it does not say anything about handling of pure ACKs that are CE marked because it probably just assumes that that case will never happen. However, implementations may or may not provide feedback. I think I would support to only have pure ACKs ECT marked if AccECN is supported because of this. I also think that losing ACKs is probably less bad that losing any of the other (control) packets that are discussed in this document. So I think this restriction would be okay. >> [BB] OK, it's good to have one opinion on this. >> We'd like to hear more opinions before changing this tho. >> >> FYI, RFC3168 does vaguely hint that the receiver of Pure ACKs carrying ECT (or CE) probably ought not to reject them (but it doesn't say what to do with a CE mark). In S.6.1.4 it says: >> For the current generation of TCP congestion control algorithms, >> pure acknowledgement packets [...] MUST be sent with the not-ECT codepoint. >> >> Saying "current generation" implies a future generation might change this, which ought to make an implementer wary of rejecting ECT on Pure ACKs. >> >>> 3) This is a suggestion to improve the situation, however it probably needs further discussion: in sect 3.2.1.4 you say that one should still use ECT SYNs even if a connection attempt previously failed. Maybe we can use a smaller time-out in this case...? >> [BB] I'm wary of jumping to the conclusion that a loss is not due to congestion just because it's becoming more likely it could be due to a black hole. E.g. if there's a black hole, the probability of losing an ECT SYN is 100%, but if the underlying loss level is 1%, the probability that 2 SYNs are lost is 0.01% as an alternative. >> >> So, when 2 ECT SYNs at different times have timed out, but non-ECT SYNs got through, I suppose it's possible to argue that the probability that the second loss was due to congestion has reduced. So the timeout could be reduced. >> >> I'll add this, and flag it "FOR DISCUSSION". >> >>> And now first a couple of comments on the structure: >>> >>> 1) I would move the network behavior in any case AFTER the endpoint behavior spec. Actually I would even propose to have it in a different section (not under 3. Specification) because it actually does not specify anything; it only comments on the current situation. >> [BB] I did consider this when I removed the normative text from this section. But this this section is intended to do more than just comment. We want it to incorporate the "SHOULD" in ecn-experimentation as part of the specification for this experiment. And we figured this text is short enough to put first, to reduce the chance it gets buried and overlooked operators, without distracting host implementers too much. >> >> So I would rather make the following change than move the section: >> s/So operators are encouraged to alter their firewall rules/ >> /So operators are RECOMMENDED to alter their firewall rules/ >> >> Rationale: When updates to a system for an experiment are all spread about in different docs, it's not just helpful but also necessary to call out all the parts in their different docs. Similarly, we have incorporated RFC5562 (ECT on SYN-ACK) and AccECN into this draft - both as normative references. >> >>> 2) And then you would actually not need a separate subsection for the Endpoint behavior; you could just call section 3 "Specification of Endpoint Behavior" or even "Specification of Sender Behavior" and move the first two paragraphs of section 3.2 to the intro that explains that this mechanism/document only needs to talk about the sender behavior. >> [BB] Depends on resolution of the above. >>> 3) I would include the text on TFO and IW10 directly into section 3.2.1.3 instead of just giving a reference to a later section. >> [BB] This is a matter of style. I prefer to distinguish normative dependencies between >> * dependencies that are essential, >> * and then to split optional dependencies between: >> - STD >> - EXPT >> >> The above structure forces implementers (and authors) to make dependencies modular, in case an experiment fails. E.g. we do not yet know whether an attack will be invented against TFO. >> >> For instance, look at all the mess that has had to be cleared up because everyone assumed the ECN nonce experiment would succeed. >> >>> 4) The rationale in section 3.2.6.1 could also go somewhere into section 5 (to keep the spec part as short as possible). At least I think you don't need the whole text here. If you want to keep something you probably only need the second paragraph (and not an own subsection). >> [BB] The scope of Section 5 is (currently) countering arguments in other RFCs (mostly RFC3168). >> ECT on RSTs wasn't mentioned in an RFC so far, which is I why I put this section here. >> >> One solution would be to rename section 5 "Rationale". Then I would be happy to move 3.2.6.1 to section 5. I'll do that. >> >>> 5) Maybe have the section on Retransmissions (3.2.7.) earlier before RST, FIN, and Window probe because it seems more "important". But actually I don't think the order matters that much. So this is a minor comment only. >> [BB] Currently the order is chosen to match the order of the lists in the introduction so they can be summarized as "control packets and retransmissions". I'll leave it as it is. >>> 6) The paragraph on SCTP (section 4.1) could go into the intro. And if you then also integrate the TFP and IW10 stuff into section 3.2.1.3, section 4 would actually go away completely. >> [BB] Now, with the removal of the TFO section, none of S.4 contains anything normative. Now it is just saying "For all these variants, here's why you don't need to do anything different". So I am inclined to move it /after/ section 5. >> >> I certainly don't want to integrate the TFO and IW10 comments into the spec section, because that would just complicate the spec with text that essentially ends up saying "You didn't need to read this to implement the spec". >> >> I also don't want to add a detailed para about SCTP to a nice 3-para Intro to a spec about a modification to TCP. >> However, I agree that "scope" is one of the important things to cover in an introduction. >> >> In summary, I would rather move this section about variants to after S.5. And in the intro, say this is an experimental modification to standards track TCP, but also flag that it discusses (non-)interaction with variants such as SCTP, TFO, IW10. >> >>> And now a bunch of editorial comments/proposals: >>> >>> 1) I though that it might be good to mention AccECN already in the Intro because that the enabler for the SYN part... >> [BB] OK, that would be sensible, along with the above sentence about variants. Will do. >>> 2) section 1.1: >>> OLD >>> "Preventing TCP control >>> packets from obtaining the benefits of ECN would not only expose them >>> to the prevailing level of congestion loss, but it would also stop >>> them from being classified into the low latency (L4S) queue, which >>> would greatly degrade L4S performance." >>> I think this can be phrased more general: >>> NEW >>> "Preventing TCP control >>> packets from obtaining the benefits of ECN would not only expose them >>> to the prevailing level of congestion loss, but it would also put control >>> packet into a different queue with different network treatment, which >>> may also lead to reordering and therefore can greatly degrade TCP >>> performance." >> [BB] Good point. Given this sentence was in a para about L4S, I shall split it off and make it into a summary section. >>> >>> 3) section 3.2.1.1: >>> OLD >>> "Accurate ECN (AccECN) >>> feedback [I-D.ietf-tcpm-accurate-ecn] provides two codepoints in the >>> SYN-ACK" >>> NEW >>> "Accurate ECN (AccECN) >>> feedback [I-D.ietf-tcpm-accurate-ecn] provides one flag in the >>> SYN-ACK" >>> I think that's clearer, at least for me. >> [BB] Eh? I'm not going to change this, cos the word flag would imply this is a bit with a meaning orthogonal to the other bits. >> >> Here's a copy of the relevant part of the table... >> | NS CWR ECE | | >> | 0 1 0 | AccECN | >> | 1 1 0 | AccECN (CE on SYN) | >> | 1 0 1 | classic ECN | >> ... etc >> >> >> The first bit only distinguishes "whether or not the SYN arrived marked CE" when the 3-bit codepoint as a whole is 'X10'. So it's not a flag, it's 2 codepoints. >> >>> 4) section 3.2.1.2 >>> This sentence is correct but I had to read it twice to make sure it's correct: >>> "Servers that >>> do not support ECN as a whole probably do not need to be recorded >>> separately from non-support of AccECN because, even when a server >>> does not support classic [RFC3168] ECN, there is no performance >>> penalty in always requesting to use it." >>> NEW >>> "Servers that >>> do not support ECN as a whole probably do not need to be recorded >>> separately from non-support of AccECN. Meaning, if AccECN is noted as not supported by the server, the initiator may decide to not mark the SAN as ECT but it still may try to negotiate classic ECN or even AccECN (to quickly detect server upgrades)." >> [BB] I realize now that this text is all wrong. I shall attempt a rewrite. >> >> I now realize my heading of 3.2.1.2 is wrong; it was not meant to be about "Caching Failed Connection Attempts". It was meant to be mostly about "Caching Lack of Recognition of ECT SYNs", with just a reference forward to caching failed connection attempts ("3.2.1.4 Fall-Back Following No Response to an ECT SYN"). >> >> I intended to say that, when a server is cached as not supporting AccECN, subsequent attempts should still request AccECN, but not with ECT on the SYN. Because there is no harm in always attempting to negotiate AccECN (as long as such requests are not black-holed), because the responder will still respond properly to an AccECN request if it only supports classic ECN or no ECN at all, without any performance penalty. >> >> I shall also make the point in S.3.2.1.4 that if an ECT SYN is black-holed, it might still be possible to request AccECN, but without ECT on the SYN. >> >>> 5) section 3.2.1.4: >>> OLD >>> "To expedite connection set-up if, after sending an ECT SYN, the >>> retransmission timer expires, the TCP initiator SHOULD send a SYN >>> with the not-ECT codepoint in the IP header and not attempt to >>> negotiate AccECN. It would make sense to also remove any other >>> experimental fields or options on the SYN, but that will depend on >>> the specification of the other option(s). " >>> I wouldn't make any statements about things that are not in scope of this doc, so I would remove the later part (including fallback for AccECN): >>> NEW >>> "To expedite connection set-up if, after sending an ECT SYN, the >>> retransmission timer expires, the TCP initiator SHOULD send a SYN >>> with the not-ECT codepoint in the IP header." >> [BB] I agree that I shouldn't have said to not attempt AccECN. So I will use your new text. >> >> But I disagree about not even mentioning that the cause might be other experimental options, and to encourage the reader to read those specs as well. I'll use the following unless you shout: >> >> "To expedite connection set-up if, after sending an ECT SYN, the >> retransmission timer expires, the TCP initiator SHOULD send a SYN >> with the not-ECT codepoint in the IP header. If other experimental >> fields or options were on the SYN, it will also be necessary to follow >> their specifications for fall-back too. It would make sense to co- >> ordinate all the strategies for fall-back in order to isolate the specific >> cause of the problem." >> >>> 6) section 3.2.2 says: >>> "In either case no change is required to RFC 5562 or the AccECN specification." >>> >>> It would probably be good to also state in this draft what the procedure is that is described in RFC5562: >>> "When the responder (node B) receives the ECN-Echo packet reporting >>> the Congestion Experienced indication in the SYN/ACK packet, the >>> responder sets the initial congestion window to one segment, instead >>> of two segments as allowed by [RFC2581], or three or four segments >>> allowed by [RFC3390]. As illustrated in Figure 2, if the responder >>> (node B) receives an ECN-Echo packet informing it of a Congestion >>> Experienced indication on its SYN/ACK packet, the responder sends a >>> SYN/ACK packet that is not ECN-Capable, in addition to setting the >>> initial window to one segment. The responder does not advance the >>> send sequence number. The responder also sets the retransmission >>> timer. The responder follows RFC 2988 [RFC2988] in setting the RTO >>> (retransmission timeout)." >> [BB] Two responses: >> >> 1) I think it's dangerous to quote a small part of another spec. as if it's a good summary of the behaviour. This loses all the detail in RFC 5562 (e.g. what if the responder implements SYN cookies, yada yada). >> >> 2) Oh dear. I had forgotten that RFC5562 specified a different protocol to the "ECN+" paper. It's ultra-ultra-conservative. >> >> So, I think we had better include the original proposal in the "ECN+" paper within the generalized ECN draft, and include a counter-argument to RFC5562 as well as to RFC3168. >> >>> 7) section 3.2.3: >>> OLD >>> "It MAY also >>> implement AckCC [RFC5690] to regulate the pure ACK rate, but this is >>> not required. Note that, in comparison, [RFC5681] does not require..." >>> NEW >>> "It MAY also >>> implement Acknowledgement Congestion Control (AckCC) [RFC5690] to regulate the pure ACK rate, but this is >>> not required. Note that, in comparison, TCP Congestion Control [RFC5681] does not require..." >> [BB] OK. >>> >>> 8) section 3.2.3: >>> "The question of whether the receiver of pure ACKs is required to feed back any CE marks on them is a matter for the relevant feedback specification ([RFC3168] or [I-D.ietf-tcpm-accurate-ecn]). It is outside the scope of the present specification." >>> However, as mention about I believe that RFC3168 does not say anything about feedback how to handle CE marks of pure ACK because it assumes that this case never occurs. So that might be implementation dependent, so it might be better to spell that out: >>> "[I-D.ietf-tcpm-accurate-ecn] includes handling of control packets. However, [RFC3168] does not specify handling of pure ACKs that are CE mark, so it might be implementation specific if feedback is provided or not." >> [BB] OK. >> >> Anyway, this will be moot if we do not allow ECT on Pure ACKs unless AccECN has been negotiated. >>> Related to this comment in the same section: >>> "DISCUSSION: Before the AccECN specification is published, a >>> requirement to count CE marks on all packets could be added." >>> I pretty sure that this is what the AccECN draft is doing but I can double check. If not it clearly should be added. Maybe it's not spelled out clearly enough. I'll check! >> [BB] You're right. I will fix this. >> >> I too thought that AccECN counted CE on pure ACKs, but I checked the AccECN draft by searching for "pure ACK" and couldn't find any mention of this aspect. However, I've just done a more thorough search, and you're right - it says so three times, but none use the words "pure ACK": >> The fourth counts >> the number of packets arriving marked with a CE codepoint (including >> control packets without payload if they are CE-marked). >> >> [...] >> The CE >> packet counter includes control packets that do not have payload >> data, >> >> [...] >> The CE packet counter (r.cep), counts the number of packets >> the host receives with the CE code point in the IP ECN field, >> including CE marks on control packets without data. >> >> >>> 9) section 3.2.6.1: >>> OLD >>> "The following factors have been considered before deciding whether >>> ECT ought to be allowed on a RST message:" >>> NEW >>> "The following factors have been considered before deciding whether >>> the RST message should be ECT marked:" >> [BB] >> * I had already edited out any occurrence of the phrase "ECT marked" (because "marked" generally implies a congestion marking, so this could be misinterpreted). >> * I always avoid the word "should" in lower case. >> * I try to avoid writing sentences in the passive (but I missed this one). >> >> Other than all that, I grok what you mean; I will use: >> >> "The following factors have been considered before deciding whether >> the sender ought to set ECT on a RST message:" >>> That's it. So nothing big. Let move on with this draft! >> [BB] >> Cheers >> >> >> Bob >>> >>> >>> >>> On 18.04.2017 11:40, Bob Briscoe wrote: >>>> David, Mirja, list, >>>> >>>> Thanks again for your reviews of the -00. I've been busy over the w/e after >>>> thinking more deeply about some of your comments and after realizing that >>>> RFC3168 contained an assumption that a single pure ACK implies that all other >>>> packets in that direction are pure ACKs, which is not true in general. >>>> >>>> We've produced another rev (draft-bagnulo-tcpm-generalized-ecn-02 >>>> ). >>>> >>>> This is a general invitation for anyone on the list, including you two, to >>>> review this again, so we can ask for an informed adoption call. >>>> >>>> We need people with the following expertise: >>>> * TCP hijacking and DoS/flooding attacks >>>> * Specific TCP implementations (Linux, FreeBSD, iOS, Windows, etc). >>>> * All the common variants of TCP >>>> >>>> We have identified clearly where decisions are needed. >>>> As well as where more measurements are needed. >>>> >>>> Main changes: >>>> * Moved more discursive text from S.3 (Spec) to S.5 (Arguments against RFCs) >>>> * Major changes to Pure ACK sections and the reliability argument, to address >>>> Mirja's arguments better, and to separately address cwnd response (required) >>>> and ACK-rate response (optional but not required). >>>> * Referred to Network Behaviour in ecn-experimentation, rather than repeating >>>> it. >>>> * Fixed description of window probe. >>>> * Recommended RFC 5961, which gives much stronger packet validity checks for >>>> retransmissions, RSTs & FINs. >>>> >>>> Cheers >>>> >>>> >>>> Bob >>>> >>>> >>>> On 14/04/17 02:13, Bob Briscoe wrote: >>>>> David, >>>>> >>>>> I hope you will find that I have addressed all your concerns - so at least >>>>> you will be able to understand it now. >>>>> The draft is now unexpired. >>>>> >>>>> I have also addressed all the points in Mirja's review (some intersecting >>>>> with your points). >>>>> >>>>> You will see that it's actually turned into quite a major re-write. The >>>>> diff is nearly total, mainly cos I was turning Spanglish into English as I >>>>> went (Marcelo, it was quite understandable, but just not quite how a native >>>>> English speaker would say it). >>>>> >>>>> However, I have changed technical points in a few places too - the more one >>>>> thinks about this, the more depth one finds. >>>>> >>>>> I just noticed I missed one of your nits (shortening the definition of >>>>> Retransmission), which I have already fixed in my local copy of the xml for >>>>> the next rev. >>>>> >>>>> >>>>> >>>>> Bob >>>>> >>>>> >>>>> On 08/04/17 01:11, Bob Briscoe wrote: >>>>>> David, >>>>>> >>>>>> On 2) I intend to replace the whole of "3.1 Network behaviour" with the >>>>>> following, which calls out the cases explicitly: >>>>>> >>>>>> Previously RFC3168 required the sender to set not-ECT on certain TCP >>>>>> control packets. Some readers might have erroneously interpreted this >>>>>> aspect of RFC3168 as a requirement for firewalls, intrusion detection >>>>>> systems, etc. to check and enforce this behaviour. Now that the present >>>>>> experimental specification allows TCP senders to set ECT on all TCP >>>>>> packets (control and data), it needs to be clear that a firewall (or any >>>>>> network node) SHOULD NOT treat any ECT packet differently dependent on >>>>>> what type of TCP packet it is. >>>>>> >>>>>> One potential exception is envisaged, otherwise the previous sentence >>>>>> could have said "MUST NOT" rather than "SHOULD NOT". The exception allows >>>>>> a security function that has detected an ongoing attack to drop more ECT >>>>>> marked SYNs than not-ECT marked SYNs. Such a policy SHOULD NOT be applied >>>>>> routinely. It SHOULD only be applied if an attack is detected, and then >>>>>> only if it is determined that the ECT capability is intensifying the attack. >>>>>> >>>>>> >>>>>> Bob >>>>>> >>>>>> On 07/04/17 23:33, Black, David wrote: >>>>>>> Bob, >>>>>>> >>>>>>> Two comments: >>>>>>> >>>>>>> 1) I'll wait for new text before commenting further on Accurate ECN vs. >>>>>>> vanilla RFC 3168 ECN. The current text left me somewhat confused, and >>>>>>> the summary of changes from RFC 3168 will almost certainly help. >>>>>>> >>>>>>> 2) On network node treatment of ECT, RFC 3168 is brief, e.g. (Section 5, >>>>>>> top of p.7): >>>>>>> >>>>>>> The CE codepoint '11' is set by a router to indicate congestion to >>>>>>> the end nodes. >>>>>>> >>>>>>> One wants to avoid text that could be read as modifying that sentence by >>>>>>> adding possible exceptions for TCP control packets and/or retransmissions. >>>>>>> >>>>>>>> [BB] Unfortunately, RFC3168 does not specify anything about network node >>>>>>>> forwarding behaviour wrt ECT. So some firewall policies could have >>>>>>>> decided to block any TCP control packets that contravene RFC3168. That's >>>>>>>> why we wrote this section. >>>>>>> If "firewalls" is what was meant, use that word ;-) ... or as you write ... >>>>>>> >>>>>>>> However I admit that, by not explaining that DPI was the problem we were >>>>>>>> trying to solve, rather than removing any ambiguity that might have been >>>>>>>> interpreted as a need for DPI. We'll fix this. >>>>>>> In doing so, please keep in mind that in this draft, discussion of >>>>>>> forwarding and dropping behavior is implicitly about router queue >>>>>>> management, not middlebox access control (e.g., based on DPI), so access >>>>>>> control has to be called out explicitly when that is what is meant. >>>>>>> >>>>>>> Thanks, --David >>>>>>> >>>>>> >>>> -- >>>> ________________________________________________________________ >>>> Bob Briscoe http://bobbriscoe.net/ >>>> >> -- >> ________________________________________________________________ >> Bob Briscoe >> http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Apr 27 14:45: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 90154129B9B for ; Thu, 27 Apr 2017 14:45:02 -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, RP_MATCHES_RCVD=-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 lP78aQvv6knR for ; Thu, 27 Apr 2017 14:45:00 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 C054A1270A3 for ; Thu, 27 Apr 2017 14:42:02 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3RLfghn021361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Apr 2017 14:41:43 -0700 (PDT) To: Wesley Eddy , tcpm@ietf.org References: <149073784890.1172.13660402558896010585@ietfa.amsl.com> From: Joe Touch Message-ID: <3ec5395d-5996-6c3b-ea2a-3b6b1f13a097@isi.edu> Date: Thu, 27 Apr 2017 14:41:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-MailScanner-ID: v3RLfghn021361 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-05.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: Thu, 27 Apr 2017 21:45:03 -0000 Hi, Wes (et al.), Picking this thread back up... On 3/28/2017 3:18 PM, Wesley Eddy wrote: > On 3/28/2017 6:06 PM, Joe Touch wrote: >> Some observations: >> >> 3.1 currently defined options >> this either needs to be the complete current list or indicate that >> the list is elsewhere (the latter seems better to me) >> if list elsewhere, the discussion should be clear that this doc >> defines only the following options; others are defined elsewhere >> is there any notion of the minimum required options? if so, is this >> that set? (it might be useful to say so) > > I propose that this should be described as the minimum required set, > and that we add pointer to the IANA registry of TCP Option Kind > Numbers for the complete set: > https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml IMO, the text that follows should be replaced: Currently defined options include (kind indicated in octal): Kind Length Meaning ---- ------ ------- 0 - End of option list. 1 - No-Operation. 2 4 Maximum Segment Size. TODO - I think we may need to include designated experimental options and RFC 6994 reference here Here's a suggestion of the new text: The list of all currently defined options is managed by IANA [ref], and each option is defined in other RFCs, as indicated there. That set includes experimental options that can be extended to support multiple concurrent uses [RFC6994]. A given TCP implementation can support any currently defined options, but the following options MUST be supported (kind indicated in octal): Kind Length Meaning ---- ------ ------- 0 - End of option list. 1 - No-Operation. 2 4 Maximum Segment Size. > > >> throughout >> the discussion of PMTU and MSS might benefit from an update as per >> draft-iett-intarea-tunnels >> key points: >> PMTU discovery assumes TCP set IP to prevent both on-path (for >> IPv4) and source fragmentation (IPv4 and IPv6), otherwise it optimizes >> source fragment size rather than avoiding source fragmentation >> MSS is defined in terms of EMTU_R, which is independent of PMTU >> there are two effective MTUs - EMTU_S and EMTU_R. The former is >> set and may or may not be limited by PMTU. > > If clarity can be improved in 793bis, that sounds good to me. The > text currently is patched together from bits of many other RFCs. Some suggestions: ------------------------------------------------------------ In Sec 3.1, change: Maximum Segment Size Option Data: 16 bits If this option is present, then it communicates the maximum receive segment size at the TCP which sends this segment. This To: Maximum Segment Size Option Data: 16 bits If this option is present, then it communicates the maximum receive segment size at the TCP which sends this segment. This value is limited by the IP reassembly limit. This and in Sec 7.3.1, change: The maximum size of a segment that TCP really sends, the "effective send MSS," MUST be the smaller of the send MSS (which reflects the available reassembly buffer size at the remote host) and the largest size permitted by the IP layer: Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize where: o SendMSS is the MSS value received from the remote host, or the default 536 for IPv4 or 1220 for IPv6, if no MSS option is received. o MMS_S is the maximum size for a transport-layer message that TCP may send. o TCPhdrsize is the size of the fixed TCP header and any options. This is 20 in the (rare) case that no options are present, but may be larger if TCP options are to be sent. Note that some options may not be included on all segments, but that for each segment sent, the sender should adjust the data length accordingly, within the Eff.snd.MSS. o IPoptionsize is the size of any IP options associated with a TCP connection. Note that some options may not be included on all packets, but that for each segment sent, the sender should adjust the data length accordingly, within the Eff.snd.MSS. The MSS value to be sent in an MSS option should be equal to the effective MTU minus the fixed IP and TCP headers. By ignoring both IP and TCP options when calculating the value for the MSS option, if there are any IP or TCP options to be sent in a packet, then the sender must decrease the size of the TCP data accordingly. RFC 6691 [21] discusses this in greater detail. The MSS value to be sent in an MSS option must be less than or equal to: MMS_R - 20 where MMS_R is the maximum size for a transport-layer message that can be received (and reassembled). TCP obtains MMS_R and MMS_S from the IP layer; see the generic call GET_MAXSIZES in Section 3.4 of RFC 1122. To: The maximum size of a segment that TCP really sends, the "effective send MSS," MUST be the smaller of the send MSS (which reflects the available reassembly buffer size at the remote host, the EMTU_R [RFC1122]) and the largest transmission size permitted by the IP layer (EMTU_S [RFC1122]): Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize where: o SendMSS is the MSS value received from the remote host, or the default 536 for IPv4 or 1220 for IPv6, if no MSS option is received. o MMS_S is the maximum size for a transport-layer message that TCP may send. o TCPhdrsize is the size of the fixed TCP header and any options. This is 20 in the (rare) case that no options are present, but may be larger if TCP options are to be sent. Note that some options may not be included on all segments, but that for each segment sent, the sender should adjust the data length accordingly, within the Eff.snd.MSS. o IPoptionsize is the size of any IP options associated with a TCP connection. Note that some options may not be included on all packets, but that for each segment sent, the sender should adjust the data length accordingly, within the Eff.snd.MSS. The MSS value to be sent in an MSS option should be equal to the effective MTU minus the fixed IP and TCP headers. By ignoring both IP and TCP options when calculating the value for the MSS option, if there are any IP or TCP options to be sent in a packet, then the sender must decrease the size of the TCP data accordingly. RFC 6691 [21] discusses this in greater detail. The MSS value to be sent in an MSS option must be less than or equal to: MMS_R - 20 where MMS_R is the maximum size for a transport-layer message that can be received (and reassembled at the IP layer). TCP obtains MMS_R and MMS_S from the IP layer; see the generic call GET_MAXSIZES in Section 3.4 of RFC 1122. These are defined in terms of their IP MTU equivalents, EMTU_R and EMTU_S [RFC1122]. --------------------------------------------- In Sec 3.7.2, change: A TCP implementation may be aware of the MTU on directly connected links, but will rarely have insight about MTUs across an entire network path. For IPv4, RFC 1122 provides an IP-layer recommendation on the default effective MTU for sending to be less than or equal to 576 for destinations not directly connected. For IPv6, this would be 1280. In all cases, however, implementation of Path MTU Discovery (PMTUD) and Packetization Layer Path MTU Discovery (PLPMTUD) is strongly recommended in order for TCP to improve segmentation decisions. PMTUD for IPv4 [2] or IPv6 [3] is implemented in conjunction between TCP, IP, and ICMP protocols. Several adjustments to a TCP implementation with PMTUD are described in RFC 2923 in order to deal with problems experienced in practice [6]. PLPMTUD [13] is a Standards Track improvement to PMTUD that relaxes the requirement for ICMP support across a path, and improves performance in cases where ICMP is not consistently conveyed. The mechanisms in all four of these RFCs are recommended to be included in TCP implementations. To: A TCP implementation may be aware of the MTU on directly connected links, but will rarely have insight about MTUs across an entire network path. For IPv4, RFC 1122 provides an IP-layer recommendation on the default effective MTU for sending to be less than or equal to 576 for destinations not directly connected. For IPv6, this would be 1280. In all cases, however, implementation of Path MTU Discovery (PMTUD) and Packetization Layer Path MTU Discovery (PLPMTUD) is strongly recommended in order for TCP to improve segmentation decisions. Both PMTUD and PLPMTUD help TCP choose segment sizes that avoid both on-path (for IPv4) and source fragmentation (IPv4 and IPv6). PMTUD for IPv4 [2] or IPv6 [3] is implemented in conjunction between TCP, IP, and ICMP protocols. It relies both on avoiding source fragmentation and setting the IPv4 DF (don't fragment) flag, the latter to inhibit on-path fragmentation. It relies on ICMP errors from routers along the path, whenever a segment is too large to traverse a link. Several adjustments to a TCP implementation with PMTUD are described in RFC 2923 in order to deal with problems experienced in practice [6]. PLPMTUD [13] is a Standards Track improvement to PMTUD that relaxes the requirement for ICMP support across a path, and improves performance in cases where ICMP is not consistently conveyed, but still tries to avoid source fragmentation. The mechanisms in all four of these RFCs are recommended to be included in TCP implementations. ------------------------------------------------------------