From nobody Sun Apr 2 04:24:36 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3FE124282 for ; Sun, 2 Apr 2017 04:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 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_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kdp70mfeiSQS for ; Sun, 2 Apr 2017 04:24:31 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20128.outbound.protection.outlook.com [40.107.2.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9939B127599 for ; Sun, 2 Apr 2017 04:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AR/4dLBHmzvjisnpo8cjWiT+8Gxf3Xu5CXncenfrVf8=; b=kLQSz+SDlZMC4d65XJpjU1jv0SD+QM8S9VsUv5HEsnqw5qptuBHz+g1N4x4CqSXlF0h0eKrKRTR9xumJk/d76uRCmifG3XC2acYVOIyw8lwi6PsyRQO28BwNIbxtyOZBp+C8SQQ5cAgWyY3YjyHyT8x+kXrnTfjUNbhnf8JJo6w= Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com (10.169.137.7) by VI1PR0701MB2128.eurprd07.prod.outlook.com (10.169.137.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Sun, 2 Apr 2017 11:24:27 +0000 Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com ([10.169.137.7]) by VI1PR0701MB2126.eurprd07.prod.outlook.com ([10.169.137.7]) with mapi id 15.01.1019.014; Sun, 2 Apr 2017 11:24:27 +0000 From: "De Schepper, Koen (Nokia - BE/Antwerp)" To: Michael Welzl , tsvwg IETF list Thread-Topic: [tsvwg] confirming adoption of L4S drafts Thread-Index: AQHSqihArKe78a7syEqLOjHC3StAmqGvWu4AgAKK+XA= Date: Sun, 2 Apr 2017 11:24:27 +0000 Message-ID: References: <138206D2-85DF-4CAC-B196-7FC59304546A@ifi.uio.no> In-Reply-To: <138206D2-85DF-4CAC-B196-7FC59304546A@ifi.uio.no> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ifi.uio.no; dkim=none (message not signed) header.d=none;ifi.uio.no; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [213.49.141.226] x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2128; 7:h7QZfjXW+0IqQvyuVcEAtFrDiZxgy7tRgna5CZQqXYx1aoxkW+mtTbOJEBsAKkaOSgZl3wSInIpGTbbvMHzTQ4YlTMokVdCUXlsb6KzvPKCdJTm6s0h1e9+1v5NncoHRYWK/4JXLQOl3mNcAnhDaoP/+EOFgz4l6gJyCDCY1RQd2NIxNbXRvbrt8+5QXeM/81cCpbsiZd6Ld14Xcw9jfwKUHF4sbBv5c3OlHvH9dWcz9+bLZDz+E6QVEf54naxS3Sr10VsJukJwwSb1ABPuEODBft40yl4NAXmouVMj6NbR/VwtJQp96dKzEJnxeyG2rJTjBtbqHd3xFNNDLZp7mfA== x-ms-office365-filtering-correlation-id: 75f38d6c-c589-4df9-d4b6-08d479bad325 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR0701MB2128; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155)(17755550239193); 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)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:VI1PR0701MB2128; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2128; x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39840400002)(39860400002)(39850400002)(39450400003)(377454003)(53754006)(24454002)(3846002)(53936002)(790700001)(77096006)(6116002)(102836003)(55016002)(6436002)(606005)(66066001)(6506006)(9686003)(5660300001)(54356999)(76176999)(7696004)(50986999)(81166006)(8936002)(8676002)(86362001)(7736002)(33656002)(7906003)(74316002)(6246003)(38730400002)(6306002)(236005)(54896002)(2950100002)(189998001)(2900100001)(2906002)(3280700002)(229853002)(3660700001)(53546009)(122556002)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2128; H:VI1PR0701MB2126.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB2126A018EF85F434588A0948B9090VI1PR0701MB2126_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2017 11:24:27.7400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2128 Archived-At: Subject: Re: [tsvwg] confirming adoption of L4S drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 11:24:34 -0000 --_000_VI1PR0701MB2126A018EF85F434588A0948B9090VI1PR0701MB2126_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwNCg0KVGhhbmtzIGZvciBicmluZ2luZyB1cCB0aGVzZSBwb2ludHMuIFNlZSBp bmxpbmU6DQoNCg0KRnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgTWljaGFlbCBXZWx6bA0KU2VudDogdnJpamRhZyAzMSBtYWFydCAyMDE3IDIx OjQ3DQpUbzogdHN2d2cgSUVURiBsaXN0IDx0c3Z3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb dHN2d2ddIGNvbmZpcm1pbmcgYWRvcHRpb24gb2YgTDRTIGRyYWZ0cw0KDQpIaSBhbGwsDQoNClNv cnJ5LCBJIHdvdWxkIGhhdmUgZ29uZSB0byB0aGUgbWljIHRvIHNheSB0aGlzIHllc3RlcmRheSwg YnV0IHRpbWUgd2FzIHJ1bm5pbmcgc2hvcnQsIHRoZXJlIHdlcmUgbG90cyBvZiBvdGhlcnMgZ29p bmcgdGhlcmUsIEFORCBJIHdhcyBzY3JpYmluZ+KApiBoZW5jZSBub3cgdGhpcyBlbWFpbDoNCg0K SeKAmW0gYSBsaXR0bGUgd29ycmllZCB0aGF0IHdl4oCZcmUgYWRvcHRpbmcgYSBiZWhhdmlvciBp bnNpZGUgdGhlIG5ldHdvcmssIHdpdGhvdXQgc3BlY2lmeWluZyBob3cgZW5kIHN5c3RlbXMgc2hv dWxkIHdvcmsgd2l0aCBpdC4NCg0KW0tEU10gQ3VycmVudGx5IHRoZSBMNFMgSWRlbnRpZmllciBk cmFmdCBpcyBzcGVjaWZ5aW5nIGhvdyBhIENDIHNob3VsZCBiZWhhdmUgYW5kIHJlc3BvbmQgdG8g Q0UsIHdoZW4gaXQgdXNlcyB0aGUgTDRTLUVDVCBjb2RlIHBvaW50LiBUaGUgaWRlYSBpcyB0byB3 cml0ZSBpdCByYXRoZXIgaW4gcmVxdWlyZW1lbnRzIHRoYW4gc3BlY2lmaWMgbWVjaGFuaXNtcy4g UHJvYmFibHkgYWxzbyB0aGUgY29ycmVjdCBwbGFjZSB0byB3cml0ZSBkb3duIHRoZSBUQ1AtUHJh Z3VlIHJlcXVpcmVtZW50cyAoY3VycmVudGx5IHRoZXkgYXJlIGEgYml0IGxvc3QgaW4gYW4gYXBw ZW5kaXggaW4gdGhlIER1YWxRIGRyYWZ0KS4gQSBzZXBhcmF0ZSBkcmFmdCBjYW4gdGhlbiBiZSBt YWRlIHBlciBzcGVjaWZpYyBMNFMgY29tcGxhaW50IENDIHRvIGV4cGxhaW4gaXRzIG1lY2hhbmlz bXMuIFdvdWxkIHRoYXQgaGVscD8NCg0KSW4gcGFydGljdWxhciwgd2hhdCBtYWtlcyBtZSBmZWVs IHVuZWFzeSBpcyBzbGlkZSAyIGZyb20geWVzdGVyZGF54oCZcyBwcmVzZW50YXRpb246DQpodHRw czovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85OC9zbGlkZXMvc2xpZGVzLTk4LXRzdndnLXNl c3NiLWw0cy1kcmFmdHMtMDEucGRmDQp3aGljaCBzaG93ZWQgVENQIFByYWd1ZSBhcyBhbiBJQ0NS RyBpdGVtLiBJIHRoaW5rIHRoaXMgbWlzcmVwcmVzZW50cyB0aGUgcm9sZSBvZiBhbiBJUlRGIGdy b3VwOiB5ZXMgSUNDUkcgY2FuIHB1Ymxpc2ggZG9jdW1lbnRzLCBidXQgdGhlc2UgaGF2ZSBhbiBJ UlRGIGJvaWxlcnBsYXRlLCBhbmQgSSBkb27igJl0IHRoaW5rIHRoYXTigJlzIHRoZSByaWdodCB3 YXkgdG8gcHVibGlzaCBhbiBlMmUgY291bnRlcnBhcnQgdG8gYW4gSUVURiBFeHBlcmltZW50YWwg UkZDLiBBcyBJIGV4cGxhaW5lZCBpbiB0c3ZhcmVhIGVhcmxpZXIgdGhpcyB3ZWVrOg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC10c3ZhcmVhLXNl c3NiLWRpc2N1c3Npb24tb24tY29uZ2VzdGlvbi1jb250cm9sLXdvcmstaW4tdGhlLWlldGYtdGhl LXJvbGUtb2YtaWNjcmctbWljaGFlbC13ZWx6bC0wMC5wZGYNCuKApiB0aGUgbW9yZSBjb21tb24g cm9sZSBvZiBJQ0NSRyBpcyB0byBwcmUtZXZhbHVhdGUgcHJvcG9zYWxzIGJlZm9yZSB0aGV54oCZ cmUgZXZlbiByZWFkeSBmb3IgdGhlIElFVEYuDQoNCltLRFNdIFllcywgc29ycnkgZm9yIHRoZSBj b25mdXNpb24uIEZvciBUQ1AtUHJhZ3VlLCB0aGUgSUNDUkcgcmVmZXJlbmNlIHdhcyBtYWlubHkg dG8gc2hvdyB3aGVyZSBjdXJyZW50bHkgdGhlIHdvcmsgaXMgcHJlc2VudGVkICh3aGljaCBJIHRo aW5rIGlzIHRoZSByaWdodCB3ZyBmb3IgdGhpcywgbm90PykuIEFzIEkgc2FpZCBpbiB0aGUgdHN2 d2cgcHJlc2VudGF0aW9uLCBzZWVuIHRoZSByZWNlbnQgaWNjcmcgYW5kIHRzdndnIGRpc2N1c3Np b25zIGl0IGlzIG5vdCBjbGVhciB0byBtZSBpZiBhIENDIGRyYWZ0IHdpbGwgYmUgbmVlZGVkLiBB cyBmYXIgYXMgSSB1bmRlcnN0b29kLCBpZiBhY2NlcHRlZCBieSBJQ0NSRyB0aGUgcHJvY2VzcyBh bGxvd3MgYSBkcmFmdCBpbiBUQ1BNLg0KDQpUZWNobmljYWxseSwgdGhlc2UgYXJlIG5vdCBzbyBt aW5vciBpc3N1ZXMuIERDVENQLCBhcyBpdCBzdGFuZHMsIGRvZXNu4oCZdCB3b3JrIG9uIHRoZSBJ bnRlcm5ldDsgdGhlcmUgYXJlIEludGVybmV0LXNwZWNpZmljIHByb2JsZW1zIHRoYXQgd291bGQg Zmlyc3QgbmVlZCB0byBiZSBhZGRyZXNzZWQuIFR3byBjYXNlcyB3ZXJlIGRpc2N1c3NlZCB5ZXN0 ZXJkYXk6DQoxKSBob3cgd2lsbCB0aGlzIHdvcmsgd2hlbiB0aGVyZSBhcmUgdHdvIGJvdHRsZW5l Y2tzIGluIGEgcm93Pw0KMikgd2hhdCBpZiBUQ1AgUHJhZ3VlIHRyYWZmaWMgZ2V0cyBpbnRvIGEg 4oCcY2xhc3NpY+KAnSBFQ04gcXVldWU/DQrigKYgYW5kIHRoZXNlIGFyZSBsaWtlbHkgbm90IHRo ZSBvbmx5IG9uZXMuIEUuZy4sIHRoZSBzZWNvbmQgcHJvYmxlbSB3YXMgaWRlbnRpZmllZCBsb25n IGFnbywgYXQgdGhlIEw0UyBCb0YgLSBzZWUgc2xpZGUgMzoNCmh0dHBzOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtbDRzLTYucGRmDQp3aGVyZSBpdCBzYXlz ICJGYWxsLWJhY2sgdG8gY2xhc3NpYyBUQ1Agb24gY2xhc3NpYyBFQ04gYm90dGxlbmVja+KAnS4g V29ycnlpbmdseSwgdGhlIOKAnHN0YXJ0aW5nIHBvaW504oCdIGNvbHVtbiBzYXlzIOKAnG5vbmXi gJ0sIGFuZCBzbyBmYXIgaXQgZG9lc27igJl0IHNlZW0gdGhhdCB3ZSBoYXZlIGFuIGFuc3dlciB0 byB0aGlzIHF1ZXN0aW9uLg0KPT4gd2hhdCB3aWxsIHRoaXMgZG8gdG8gdGhlIG9uZ29pbmcgZWZm b3J0IG9mIEFwcGxlIHRvIGVuYWJsZSAoY2xhc3NpYykgRUNOPw0KDQpbS0RTXSBJbmRlZWQsIERD VENQIGNhbiBiZSB1c2VkIHdpdGggRHVhbFEgaW4gZmFpci1zaGFyZSBtb2RlIHdpdGggY2xhc3Np YyBUQ1AsIGJ1dCBpbiBhIGNvbnRyb2xsZWQgZW52aXJvbm1lbnQgb25seS4gVGhpcyBjb3VsZCBi ZSBpbiBhIGRhdGEgY2VudGVyLCBvciBpbiBhIHNlcnZpY2UgcHJvdmlkZXLigJlzIG5ldHdvcmss IHdoZXJlIHRoZSBjb25nZXN0aW9uIHBvaW50cyBhcmUga25vd24gYW5kIHN1cHBvcnQgTDRTLiBF eHRyYSBMNFMgaWRlbnRpZmljYXRpb24gKGRpZmZzZXJ2IGNvZGVwb2ludHMvSVAgcmFuZ2VzKSBj b3VsZCBiZSB1c2VkIGlmIG5lZWRlZC4gQXMsIEkgdGhpbmsgR29ycnkgc3RhdGVkLCB0aGUgY3Vy cmVudCBEQ1RDUCBkcmFmdCByZXN0cmljdHMgaXRzIHVzZSB0byBjb250cm9sbGVkIGVudmlyb25t ZW50cyBvbmx5Og0KICAgRENUQ1AgYXMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQNCiAgIGlzIGFw cGxpY2FibGUgdG8gZGVwbG95bWVudHMgaW4gY29udHJvbGxlZCBlbnZpcm9ubWVudHMgbGlrZQ0K ICAgZGF0YWNlbnRlcnMgYnV0IGl0IE1VU1QgTk9UIGJlIGRlcGxveWVkIG92ZXIgdGhlIHB1Ymxp YyBJbnRlcm5ldA0KICAgd2l0aG91dCBhZGRpdGlvbmFsIG1lYXN1cmVzDQpUbyBteSB1bmRlcnN0 YW5kaW5nIHRoaXMgYWxsb3dzIHRoZSBhYm92ZSBkZXNjcmliZWQgY29udHJvbGxlZCBzZXJ2aWNl IHByb3ZpZGVyIGVudmlyb25tZW50IHRvby4NCg0KQXJlIHlvdXIgb3RoZXIgY29uY2VybnMgYWxs IGNvdmVyZWQgYnkgdGhlIFRDUC1QcmFndWUgcmVxdWlyZW1lbnRzPyBTaG91bGQgd2UgYWRkIG1v cmU/DQoNClJlZ2FyZHMsDQpLb2VuLg0KDQoNCkNoZWVycywNCk1pY2hhZWwNCg0KDQoNCk9uIE1h ciAzMSwgMjAxNywgYXQgOTowOCBBTSwgV2VzbGV5IEVkZHkgPHdlc0BtdGktc3lzdGVtcy5jb208 bWFpbHRvOndlc0BtdGktc3lzdGVtcy5jb20+PiB3cm90ZToNCg0KSGVsbG8sIHRoaXMgaXMgYSBu b3RlIHRvIGNvbmZpcm0gdGhhdCBkdWUgdG8gdGhlIHBvc2l0dmUgcmVzcG9uc2UgYXQgdGhlIGxh c3QgY291cGxlIElFVEYgbWVldGluZ3MgYW5kIG9uIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCBjdXJy ZW50bHkgbm8gbmVnYXRpdmUgcmVzcG9uc2VzLCB3ZSAoVFNWV0cgY28tY2hhaXJzKSB0aGluayB0 aGVyZSdzIGNvbnNlbnN1cyB0byBhZG9wdCB0aGUgc2V0IG9mIDMgTDRTIGRyYWZ0cy4NCg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyaXNjb2UtdHN2d2ctbDRzLWFyY2gNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icmlzY29lLXRzdndnLWFxbS1kdWFscS1j b3VwbGVkDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJpc2NvZS10c3Z3Zy1l Y24tbDRzLWlkDQoNCldlJ3ZlIGFza2VkIHRoZSBhdXRob3JzIHRvIHdhaXQgYSB3ZWVrLCBqdXN0 IHRvIGNvbmZpcm0gdGhpcyB3aXRoIHRoZSBtYWlsaW5nIGxpc3QsIGJlZm9yZSBzdWJtaXR0aW5n IHRoZSBkb2N1bWVudHMgYXMgZHJhZnQtaWV0Zi10c3Z3Zy0uLi4NCg0KUGxlYXNlIGRvbid0IGhl c2l0YXRlIHRvIHN0YXJ0IHJldmlld2luZyBhbmQgZGlzY3Vzc2luZyB0aGUgb3BlbiBpdGVtcyBL b2VuIGhpZ2hsaWdodGVkIHllc3RlcmRheS4NCg0KDQo= --_000_VI1PR0701MB2126A018EF85F434588A0948B9090VI1PR0701MB2126_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9Ik5MLUJFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBNaWNo YWVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3IgYnJp bmdpbmcgdXAgdGhlc2UgcG9pbnRzLiBTZWUgaW5saW5lOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pY2hhZWwgV2Vsemw8YnI+DQo8Yj5T ZW50OjwvYj4gdnJpamRhZyAzMSBtYWFydCAyMDE3IDIxOjQ3PGJyPg0KPGI+VG86PC9iPiB0c3Z3 ZyBJRVRGIGxpc3QgJmx0O3RzdndnQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3RzdndnXSBjb25maXJtaW5nIGFkb3B0aW9uIG9mIEw0UyBkcmFmdHM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+U29ycnksIEkgd291bGQgaGF2ZSBnb25lIHRvIHRoZSBtaWMgdG8gc2F5 IHRoaXMgeWVzdGVyZGF5LCBidXQgdGltZSB3YXMgcnVubmluZyBzaG9ydCwgdGhlcmUgd2VyZSBs b3RzIG9mIG90aGVycyBnb2luZyB0aGVyZSwgQU5EIEkgd2FzIHNjcmliaW5n4oCmIGhlbmNlIG5v dyB0aGlzIGVtYWlsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SeKAmW0gYSBsaXR0bGUgd29ycmllZCB0aGF0IHdl4oCZcmUgYWRvcHRpbmcgYSBiZWhh dmlvciBpbnNpZGUgdGhlIG5ldHdvcmssIHdpdGhvdXQgc3BlY2lmeWluZyBob3cgZW5kIHN5c3Rl bXMgc2hvdWxkIHdvcmsgd2l0aCBpdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5bS0RTXSBDdXJyZW50bHkgdGhlIEw0UyBJZGVudGlm aWVyIGRyYWZ0IGlzIHNwZWNpZnlpbmcgaG93IGEgQ0Mgc2hvdWxkIGJlaGF2ZSBhbmQgcmVzcG9u ZCB0byBDRSwgd2hlbiBpdCB1c2VzIHRoZSBMNFMtRUNUIGNvZGUgcG9pbnQuDQogVGhlIGlkZWEg aXMgdG8gd3JpdGUgaXQgcmF0aGVyIGluIHJlcXVpcmVtZW50cyB0aGFuIHNwZWNpZmljIG1lY2hh bmlzbXMuIFByb2JhYmx5IGFsc28gdGhlIGNvcnJlY3QgcGxhY2UgdG8gd3JpdGUgZG93biB0aGUg VENQLVByYWd1ZSByZXF1aXJlbWVudHMgKGN1cnJlbnRseSB0aGV5IGFyZSBhIGJpdCBsb3N0IGlu IGFuIGFwcGVuZGl4IGluIHRoZSBEdWFsUSBkcmFmdCkuIEEgc2VwYXJhdGUgZHJhZnQgY2FuIHRo ZW4gYmUgbWFkZSBwZXIgc3BlY2lmaWMNCiBMNFMgY29tcGxhaW50IENDIHRvIGV4cGxhaW4gaXRz IG1lY2hhbmlzbXMuIFdvdWxkIHRoYXQgaGVscD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHBhcnRp Y3VsYXIsIHdoYXQgbWFrZXMgbWUgZmVlbCB1bmVhc3kgaXMgc2xpZGUgMiBmcm9tIHllc3RlcmRh eeKAmXMgcHJlc2VudGF0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC10c3Z3 Zy1zZXNzYi1sNHMtZHJhZnRzLTAxLnBkZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvOTgvc2xpZGVzL3NsaWRlcy05OC10c3Z3Zy1zZXNzYi1sNHMtZHJhZnRzLTAxLnBkZjwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+d2hpY2ggc2hvd2VkIFRDUCBQcmFndWUgYXMgYW4gSUNDUkcg aXRlbS4gSSB0aGluayB0aGlzIG1pc3JlcHJlc2VudHMgdGhlIHJvbGUgb2YgYW4gSVJURiBncm91 cDogeWVzIElDQ1JHIGNhbiBwdWJsaXNoIGRvY3VtZW50cywgYnV0IHRoZXNlIGhhdmUgYW4gSVJU RiBib2lsZXJwbGF0ZSwgYW5kIEkgZG9u4oCZdCB0aGluayB0aGF04oCZcyB0aGUgcmlnaHQgd2F5 IHRvIHB1Ymxpc2ggYW4NCiBlMmUgY291bnRlcnBhcnQgdG8gYW4gSUVURiBFeHBlcmltZW50YWwg UkZDLiBBcyBJIGV4cGxhaW5lZCBpbiB0c3ZhcmVhIGVhcmxpZXIgdGhpcyB3ZWVrOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk4L3NsaWRlcy9zbGlkZXMtOTgt dHN2YXJlYS1zZXNzYi1kaXNjdXNzaW9uLW9uLWNvbmdlc3Rpb24tY29udHJvbC13b3JrLWluLXRo ZS1pZXRmLXRoZS1yb2xlLW9mLWljY3JnLW1pY2hhZWwtd2VsemwtMDAucGRmIj48c3BhbiBsYW5n PSJFTi1VUyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvc2xpZGVzL3NsaWRl cy05OC10c3ZhcmVhLXNlc3NiLWRpc2N1c3Npb24tb24tY29uZ2VzdGlvbi1jb250cm9sLXdvcmst aW4tdGhlLWlldGYtdGhlLXJvbGUtb2YtaWNjcmctbWljaGFlbC13ZWx6bC0wMC5wZGY8L3NwYW4+ PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+4oCmIHRoZSBtb3Jl IGNvbW1vbiByb2xlIG9mIElDQ1JHIGlzIHRvIHByZS1ldmFsdWF0ZSBwcm9wb3NhbHMgYmVmb3Jl IHRoZXnigJlyZSBldmVuIHJlYWR5IGZvciB0aGUgSUVURi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+W0tEU10g WWVzLCBzb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4gRm9yIFRDUC1QcmFndWUsIHRoZSBJQ0NSRyBy ZWZlcmVuY2Ugd2FzIG1haW5seSB0byBzaG93IHdoZXJlIGN1cnJlbnRseSB0aGUgd29yayBpcyBw cmVzZW50ZWQgKHdoaWNoDQogSSB0aGluayBpcyB0aGUgcmlnaHQgd2cgZm9yIHRoaXMsIG5vdD8p LiBBcyBJIHNhaWQgaW4gdGhlIHRzdndnIHByZXNlbnRhdGlvbiwgc2VlbiB0aGUgcmVjZW50IGlj Y3JnIGFuZCB0c3Z3ZyBkaXNjdXNzaW9ucyBpdCBpcyBub3QgY2xlYXIgdG8gbWUgaWYgYSBDQyBk cmFmdCB3aWxsIGJlIG5lZWRlZC4gQXMgZmFyIGFzIEkgdW5kZXJzdG9vZCwgaWYgYWNjZXB0ZWQg YnkgSUNDUkcgdGhlIHByb2Nlc3MgYWxsb3dzIGEgZHJhZnQgaW4gVENQTS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRlY2huaWNhbGx5LCB0aGVzZSBhcmUgbm90IHNvIG1pbm9y IGlzc3Vlcy4gRENUQ1AsIGFzIGl0IHN0YW5kcywgZG9lc27igJl0IHdvcmsgb24gdGhlIEludGVy bmV0OyB0aGVyZSBhcmUgSW50ZXJuZXQtc3BlY2lmaWMgcHJvYmxlbXMgdGhhdCB3b3VsZCBmaXJz dCBuZWVkIHRvIGJlIGFkZHJlc3NlZC4gVHdvIGNhc2VzIHdlcmUgZGlzY3Vzc2VkIHllc3RlcmRh eTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4xKSBob3cgd2lsbCB0aGlzIHdvcmsgd2hl biB0aGVyZSBhcmUgdHdvIGJvdHRsZW5lY2tzIGluIGEgcm93PzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4yKSB3aGF0IGlmIFRDUCBQcmFndWUgdHJhZmZpYyBnZXRzIGludG8gYSDigJxjbGFzc2lj4oCd IEVDTiBxdWV1ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+4oCmIGFuZCB0aGVzZSBhcmUgbGlrZWx5 IG5vdCB0aGUgb25seSBvbmVzLiBFLmcuLCB0aGUgc2Vjb25kIHByb2JsZW0gd2FzIGlkZW50aWZp ZWQgbG9uZyBhZ28sIGF0IHRoZSBMNFMgQm9GIC0gc2VlIHNsaWRlIDM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni1sNHMtNi5w ZGYiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 Ni9zbGlkZXMvc2xpZGVzLTk2LWw0cy02LnBkZjwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj53aGVyZSBpdCBzYXlzICZxdW90O0ZhbGwtYmFjayB0byBj bGFzc2ljIFRDUCBvbiBjbGFzc2ljIEVDTiBib3R0bGVuZWNr4oCdLiBXb3JyeWluZ2x5LCB0aGUg 4oCcc3RhcnRpbmcgcG9pbnTigJ0gY29sdW1uIHNheXMg4oCcbm9uZeKAnSwgYW5kIHNvIGZhciBp dCBkb2VzbuKAmXQgc2VlbSB0aGF0IHdlIGhhdmUgYW4gYW5zd2VyIHRvIHRoaXMgcXVlc3Rpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPj0mZ3Q7IHdoYXQgd2lsbCB0aGlzIGRvIHRvIHRoZSBvbmdv aW5nIGVmZm9ydCBvZiBBcHBsZSB0byBlbmFibGUgKGNsYXNzaWMpIEVDTj88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+W0tEU10gSW5kZWVkLCBEQ1RDUCBjYW4gYmUgdXNlZCB3aXRoIER1YWxRIGluIGZhaXItc2hh cmUgbW9kZSB3aXRoIGNsYXNzaWMgVENQLCBidXQgaW4gYSBjb250cm9sbGVkIGVudmlyb25tZW50 IG9ubHkuIFRoaXMgY291bGQgYmUNCiBpbiBhIGRhdGEgY2VudGVyLCBvciBpbiBhIHNlcnZpY2Ug cHJvdmlkZXLigJlzIG5ldHdvcmssIHdoZXJlIHRoZSBjb25nZXN0aW9uIHBvaW50cyBhcmUga25v d24gYW5kIHN1cHBvcnQgTDRTLiBFeHRyYSBMNFMgaWRlbnRpZmljYXRpb24gKGRpZmZzZXJ2IGNv ZGVwb2ludHMvSVAgcmFuZ2VzKSBjb3VsZCBiZSB1c2VkIGlmIG5lZWRlZC4gQXMsIEkgdGhpbmsg R29ycnkgc3RhdGVkLCB0aGUgY3VycmVudCBEQ1RDUCBkcmFmdCByZXN0cmljdHMgaXRzIHVzZQ0K IHRvIGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzIG9ubHk6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IERDVENQIGFzIGRlc2Ny aWJlZCBpbiB0aGlzIGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IGlzIGFwcGxpY2FibGUgdG8gZGVwbG95bWVudHMg aW4gY29udHJvbGxlZCBlbnZpcm9ubWVudHMgbGlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyBkYXRhY2VudGVycyBidXQg aXQgTVVTVCBOT1QgYmUgZGVwbG95ZWQgb3ZlciB0aGUgcHVibGljIEludGVybmV0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7 IHdpdGhvdXQgYWRkaXRpb25hbCBtZWFzdXJlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlRvIG15IHVuZGVyc3RhbmRpbmcgdGhpcyBhbGxvd3MgdGhlIGFib3Zl IGRlc2NyaWJlZCBjb250cm9sbGVkIHNlcnZpY2UgcHJvdmlkZXIgZW52aXJvbm1lbnQgdG9vLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFyZSB5b3VyIG90aGVyIGNvbmNl cm5zIGFsbCBjb3ZlcmVkIGJ5IHRoZSBUQ1AtUHJhZ3VlIHJlcXVpcmVtZW50cz8gU2hvdWxkIHdl IGFkZCBtb3JlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+S29lbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWljaGFl bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5PbiBNYXIgMzEsIDIwMTcsIGF0IDk6MDggQU0sIFdlc2xleSBFZGR5ICZsdDs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOndlc0BtdGktc3lzdGVtcy5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIj53ZXNA bXRpLXN5c3RlbXMuY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPkhlbGxvLCB0aGlzIGlzIGEgbm90ZSB0byBjb25maXJtIHRoYXQgZHVlIHRv IHRoZSBwb3NpdHZlIHJlc3BvbnNlIGF0IHRoZSBsYXN0IGNvdXBsZSBJRVRGIG1lZXRpbmdzIGFu ZCBvbiB0aGUgbWFpbGluZyBsaXN0LCBhbmQgY3VycmVudGx5IG5vIG5lZ2F0aXZlIHJlc3BvbnNl cywgd2UgKFRTVldHIGNvLWNoYWlycykgdGhpbmsNCiB0aGVyZSdzIGNvbnNlbnN1cyB0byBhZG9w dCB0aGUgc2V0IG9mIDMgTDRTIGRyYWZ0cy48YnI+DQo8YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyaXNjb2UtdHN2d2ctbDRzLWFyY2giPjxz cGFuIGxhbmc9IkVOLVVTIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJpc2Nv ZS10c3Z3Zy1sNHMtYXJjaDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjwvc3Bh bj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJpc2NvZS10c3Z3 Zy1hcW0tZHVhbHEtY291cGxlZCI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1icmlzY29lLXRzdndnLWFxbS1kdWFscS1jb3VwbGVkPC9zcGFuPjwv YT48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1icmlzY29lLXRzdndnLWVjbi1sNHMtaWQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJpc2NvZS10c3Z3Zy1l Y24tbDRzLWlkPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KV2UndmUg YXNrZWQgdGhlIGF1dGhvcnMgdG8gd2FpdCBhIHdlZWssIGp1c3QgdG8gY29uZmlybSB0aGlzIHdp dGggdGhlIG1haWxpbmcgbGlzdCwgYmVmb3JlIHN1Ym1pdHRpbmcgdGhlIGRvY3VtZW50cyBhcyBk cmFmdC1pZXRmLXRzdndnLS4uLjxicj4NCjxicj4NClBsZWFzZSBkb24ndCBoZXNpdGF0ZSB0byBz dGFydCByZXZpZXdpbmcgYW5kIGRpc2N1c3NpbmcgdGhlIG9wZW4gaXRlbXMgS29lbiBoaWdobGln aHRlZCB5ZXN0ZXJkYXkuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR0701MB2126A018EF85F434588A0948B9090VI1PR0701MB2126_-- From nobody Sun Apr 2 14:33:41 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BB5127F0E for ; Sun, 2 Apr 2017 14:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_KAM_HTML_FONT_INVALID=0.01, 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 mhobquDEL0Mv for ; Sun, 2 Apr 2017 14:33:36 -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 D1A1C12940F for ; Sun, 2 Apr 2017 14:33:35 -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=NXq+jLSlFNwbpkLPQeNuRcqhq8+OjUOKlITdVO4p6wM=; b=ybdiwH4OSqja5xK2lau92YnEu bPetp409YcHaoidzsY1cAHBQKr7nDfvOSwUMOSHGLu46BA0OIY/LIvdnILAZaTQe8aTvoxZOAcomn tLscbMmE5j+/gUny5EG7E4S/SkNYO7sUsb8UjElq19wm4uJD0KNqXj/Xq4Uke1hCsSLZZmPkfSzfl XE//3fDz9H4vz98VX/hidoTV7SHUu+T5qHB2veG0kHe5H907NIC2Qsc7H6VstIzv0iSq/mkc6pt4N IL6oq3s1y1FLNAn2xlSJ6NmrTEHbaKN7VUgxZe0jjR7xNlYoaxs/vaQvsRBAxgS9Fks0z4ZoaN7Eu 8Tk+IyyGQ==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:34226 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 1cun7s-0006JH-QW; Sun, 02 Apr 2017 22:33:33 +0100 To: "Weixinpeng (Jackie)" , "Black, David" , "draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org" References: Cc: tsvwg IETF list From: Bob Briscoe Message-ID: Date: Sun, 2 Apr 2017 22:33:32 +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: multipart/alternative; boundary="------------69A810EBC124154D3D0B34AA" 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: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 21:33:39 -0000 This is a multi-part message in MIME format. --------------69A810EBC124154D3D0B34AA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Weixinpeng, co-authors, and David, I had promised a review of the latest TCF draft, but failed to provide it so far. I half read it through on Friday, and I will finish and write up my review this week. Here' a quick summary of the main points so far: *S.1. Intro: **Motivation *The motivation should also include a heavy load from a much larger than expected number of responsive flows *S.1 Intro: Scope** *I think the draft should say that * it gives no advice on how to select which tunnel endpoints should be used in order to manage traffic over a network criss-crossed by multiple tunnels. * if a congested node is part of multiple tunnels, and it causes congestion feedback to multiple traffic management functions at the ingresses of all the tunnels, the draft gives no advice on how all the traffic management functions should respond. * etc. (in my full review, I will provide a full list of subjects that are out of scope). *S.3. Feedback Models: ** *The architecture diagrams and text need to include components that apply a consistent measurement policy (template records in IPFIX-speak) at both ingress and egress. This is a key part of interoperability, which is what the IETF should be all about. Template records are described later when the mechanism is specified, but they are not shown in the layout of the components in S.3. *S.4. Congestion Level Measurement:** *Measurement of ECN has been changed without thinking clearly whether it needed to change. a) Earlier drafts exploited the fact that the inner holds a "frozen" record of the ECN field at the ingress. So ECN measurements could be made solely at the egress (comparing the outer with the inner). In draft-04, ECN codepoints are measured at the ingress and at the egress, with the ingress sending regular measurement reports to the egress for comparison. However, it is always safer to measure ECN solely at the egress, even though a different mechanism has to measure drops within the tunnel (due to non-ECN nodes, or nodes that have switched off ECN due to overload, or due to causes of loss other than congestion, e.g. transmission errors). - It is always safer to solely measure ECN at the egress, because it is not vulnerable to ingress-egress measurement packets being dropped. - Solely measuring ECN at egress is no less precise, because only the proportion of the different ECN fields is needed, and that stays approximately the same even if there is drop, assuming drop is not biased towards certain ECN codepoints (no known mechanism does that). b) In draft-04 the faked ECT approach has been left unchanged at the ingress, but it is no longer used at the egress for detecting deferred drops (by looking for a Not-ECN inner and a CE outer). Again, there is nothing wrong with measuring ECN and detecting deferred drops solely at the egress, even if there are drops within the tunnel. To measure drops within the tunnel, it is necessary to compare ingress and egress bytes, but that does not make it wrong to still measure and compare ECN solely at the egress. *S.4. Congestion Level Measurement: Units** *Throughout measurement involves counting packets. However, it should count the bytes in packets with each type of marking, not just the number of packets. See RFC7141 section 2.3 . Although the recommendation in that RFC is about what a /transport/ should measure when responding to congestion, logically it should apply in this case when a traffic management function is responding in place of a transport. RFC7141 also gives recommendations on which headers to count. I shall add to this review later in the week. One question for Weixinpeng: Have you implemented this mechanism? Bob On 01/11/16 01:49, Weixinpeng (Jackie) wrote: > > Hi Bob and David, > > Because the deadline has passed, I will update it as part of post-WGLC > update. Thanks. > > Regards, > > -Xinpeng (Jackie) > > *From:*Black, David [mailto:David.Black@dell.com] > *Sent:* Tuesday, November 01, 2016 12:14 AM > *To:* Bob Briscoe; Weixinpeng (Jackie); > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > *Cc:* tsvwg IETF list; Black, David > *Subject:* RE: Tunnel Congestion Feedback: (non-)update to RFC6040 > > > I assume you will update the TCF draft today before the deadline. > > (As draft shepherd) That’s not really necessary - the TCF draft is in > WGLC, so this change can be done as part of a post-WGLC update. > > Thanks, --David > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Monday, October 31, 2016 11:22 AM > *To:* Weixinpeng (Jackie); Black, David; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list > *Subject:* Re: Tunnel Congestion Feedback: (non-)update to RFC6040 > > Xinpeng, > > I agree that TCF does not update RFC6040 (as I said). > > But David is right that the TCF draft itself needs to be updated to > say that it modifies the behaviour of a RFC6040 egress so as to issue > or log any warnings when it receives an ECT(0) or CE outer with a > Not-ECT inner. > > I assume you will update the TCF draft today before the deadline. > > Cheers > > Bob > > On 31/10/16 02:38, Weixinpeng (Jackie) wrote: > > Hi David, Bob, > > I agree that the behavior defined in RFC6040 doesn’t to be updated > due to the TCF draft, because what’s defined in RFC 6040 has a > broader usage and not just for TCF. > > I think David has provided a good suggestion below. Thanks. > > Regards, > > -Xinpeng (Jackie) > > *From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of *Black, > David > *Sent:* Saturday, October 29, 2016 10:28 AM > *To:* Bob Briscoe; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list > *Subject:* Re: [tsvwg] Tunnel Congestion Feedback: (non-)update to > RFC6040 > > Bob, > > I think you’ve found something. The TCF draft currently uses RFC > 6040 behavior by reference: > > when decapsulating packets at egress, > > RFC6040 defined decapsulation behavior is used, and according to > > RFC6040, the packets marked as CE|N-ECT will be dropped by egress. > > I think this needs to be slightly revised to say that CE|N-ECT is > dropped without any other > > action, and all other behavior is as per RFC 6040, as CE|N-ECT is > expected at a TCF egress and > > hence the logging and alarm behavior for that combination in RFC > 6040 is inappropriate. > > Once that’s done, I think your reasoning in the following sentence > becomes correct: > > If the network is not valid, these combination could become > visible to a 6040-decap, > > which would then (correctly) log warnings that it was seeing > invalid codepoint combinations. > > Thanks, --David (as draft shepherd) > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Thursday, October 27, 2016 4:39 PM > *To:* draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > ; > Black, David > *Cc:* tsvwg IETF list > *Subject:* Tunnel Congestion Feedback: (non-)update to RFC6040 > > Tunnel congestion feedback authors, David as shepherd, > > FYI. No action needed. > > This email documents an argument with myself. After a few seconds, > I agreed with myself that one of me was wrong. I thought I had > better raise this on the list, to check that others agree with > both of me. If you wish to argue with just one of me, please bear > in mind that we both have the same email address (and anyway, we > both agree so an argument with one is an argument with all). > _________________________ > > Figure 4 of RFC6040 specifies which ECN codepoint a decap must > forward, for each combination of arriving inner (row) and outer > (column). > > > +---------+------------------------------------------------+ > > |Arriving | Arriving Outer Header > | > > | Inner > +---------+------------+------------+------------+ > > | Header | Not-ECT | ECT(0) | ECT(1) | > CE | > > > +---------+---------+------------+------------+------------+ > > | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| > (!!!)| > > | ECT(0) | ECT(0) | ECT(0) | ECT(1) | > CE | > > | ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | > CE | > > | CE | CE | CE | CE(!!!)| > CE | > > > +---------+---------+------------+------------+------------+ > > RFC6040 goes on to say: > > [...] These currently unused (CU) > combinations are > > indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' > means the > > combination is CU and always potentially dangerous, while '(!)' > > means it is CU and possibly dangerous. In these cases, > > particularly the more dangerous ones, the decapsulator > SHOULD log > > the event and MAY also raise an alarm. > > TCF uses the following combinations of inner : outer > Not-ECT : ECT(0) > Not-ECT : CE > > For a moment, I thought we would have to update RFC6040 to say > that TCF makes these combinations no longer CU, so they are now > valid, not dangerous, and they no longer need to be logged. This > would have meant that Tunnel Congestion Feedback (TCF) > (informational) would have to update RFC6040 (proposed standard). > > Here's why I was wrong. These two combinations are certainly valid > at a TCF decap. But there is still no way that, in a valid > network, they would arrive at any RFC6040 (non-TCF) decap. > > One might think that this combination could arrive at a 6040-decap > if there was a tunnel inside a tunnel, as follows > > TCF-encap ---> 6040-decap ---> TCF-decap > > However, that's not a valid configuration. The following > tunnel-in-tunnel would be valid: > > TCF-encap ---> 6040-encap ---> 6040-decap ---> TCF-decap > > ...then, the above two "CU" combinations would be buried within a > double inner, so only the TCF decap would see them, not the > 6040-decap. > > So, TCF does not need to update RFC6040. Because, in a valid > network, TCF will be hidden from any 6040-decap. If the network is > not valid, these combination could become visible to a 6040-decap, > which would then (correctly) log warnings that it was seeing > invalid codepoint combinations. > > I just thought you'd like to know... no action required. > > > > Bob > > -- > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------69A810EBC124154D3D0B34AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Weixinpeng, co-authors,  and David,

I had promised a review of the latest TCF draft, but failed to provide it so far.
I half read it through on Friday, and I will finish and write up my review this week.

Here' a quick summary of the main points so far:

S.1. Intro: Motivation
The motivation should also include a heavy load from a much larger than expected number of responsive flows

S.1 Intro: Scope
I think the draft should say that
* it gives no advice on how to select which tunnel endpoints should be used in order to manage traffic over a network criss-crossed by multiple tunnels.
* if a congested node is part of multiple tunnels, and it causes congestion feedback to multiple traffic management functions at the ingresses of all the tunnels, the draft gives no advice on how all the traffic management functions should respond.
* etc. (in my full review, I will provide a full list of subjects that are out of scope).

S.3. Feedback Models:
The architecture diagrams and text need to include components that apply a consistent measurement policy (template records in IPFIX-speak) at both ingress and egress. This is a key part of interoperability, which is what the IETF should be all about. Template records are described later when the mechanism is specified, but they are not shown in the layout of the components in S.3.

S.4. Congestion Level Measurement:
Measurement of ECN has been changed without thinking clearly whether it needed to change.

    a) Earlier drafts exploited the fact that the inner holds a "frozen" record of the ECN field at the ingress. So ECN measurements could be made solely at the egress (comparing the outer with the inner). In draft-04, ECN codepoints are measured at the ingress and at the egress, with the ingress sending regular measurement reports to the egress for comparison. However, it is always safer to measure ECN solely at the egress, even though a different mechanism has to measure drops within the tunnel (due to non-ECN nodes, or nodes that have switched off ECN due to overload, or due to causes of loss other than congestion, e.g. transmission errors).
     - It is always safer to solely measure ECN at the egress, because it is not vulnerable to ingress-egress measurement packets being dropped.
     - Solely measuring ECN at egress is no less precise, because only the proportion of the different ECN fields is needed, and that stays approximately the same even if there is drop, assuming drop is not biased towards certain ECN codepoints (no known mechanism does that).

    b) In draft-04 the faked ECT approach has been left unchanged at the ingress, but it is no longer used at the egress for detecting deferred drops (by looking for a Not-ECN inner and a CE outer). Again, there is nothing wrong with measuring ECN and detecting deferred drops solely at the egress, even if there are drops within the tunnel. To measure drops within the tunnel, it is necessary to compare ingress and egress bytes, but that does not make it wrong to still measure and compare ECN solely at the egress.

S.4. Congestion Level Measurement: Units
Throughout measurement involves counting packets. However, it should count the bytes in packets with each type of marking, not just the number of packets. See RFC7141 section 2.3. Although the recommendation in that RFC is about what a /transport/ should measure when responding to congestion, logically it should apply in this case when a traffic management function is responding in place of a transport. RFC7141 also gives recommendations on which headers to count.


I shall add to this review later in the week.

One question for Weixinpeng: Have you implemented this mechanism?


Bob


On 01/11/16 01:49, Weixinpeng (Jackie) wrote:

Hi Bob and David,

Because the deadline has passed, I will update it as part of post-WGLC update. Thanks.

 

Regards,

-Xinpeng (Jackie)

 

From: Black, David [mailto:David.Black@dell.com]
Sent: Tuesday, November 01, 2016 12:14 AM
To: Bob Briscoe; Weixinpeng (Jackie); draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list; Black, David
Subject: RE: Tunnel Congestion Feedback: (non-)update to RFC6040

 

> I assume you will update the TCF draft today before the deadline.

 

(As draft shepherd) That’s not really necessary - the TCF draft is in WGLC, so this change can be done as part of a post-WGLC update.

 

Thanks, --David

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Monday, October 31, 2016 11:22 AM
To: Weixinpeng (Jackie); Black, David; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Xinpeng,

I agree that TCF does not update RFC6040 (as I said).

But David is right that the TCF draft itself needs to be updated to say that it modifies the behaviour of a RFC6040 egress so as to issue or log any warnings when it receives an ECT(0) or CE outer with a Not-ECT inner.

I assume you will update the TCF draft today before the deadline.

Cheers

Bob

On 31/10/16 02:38, Weixinpeng (Jackie) wrote:

Hi David, Bob,

I agree that the behavior defined in RFC6040 doesn’t to be updated due to the TCF draft, because what’s defined in RFC 6040 has a broader usage and not just for TCF.

I think David has provided a good suggestion below. Thanks.

 

Regards,

-Xinpeng (Jackie)

 

From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David
Sent: Saturday, October 29, 2016 10:28 AM
To: Bob Briscoe; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040

 

Bob,

 

I think you’ve found something.  The TCF draft currently uses RFC 6040 behavior by reference:

 

   when decapsulating packets at egress,

   RFC6040 defined decapsulation behavior is used, and according to

   RFC6040, the packets marked as CE|N-ECT will be dropped by egress.

 

I think this needs to be slightly revised to say that CE|N-ECT is dropped without any other

action, and all other behavior is as per RFC 6040, as CE|N-ECT is expected at a TCF egress and

hence the logging and alarm behavior for that combination in RFC 6040 is inappropriate.

 

Once that’s done, I think your reasoning in the following sentence becomes correct:

 

If the network is not valid, these combination could become visible to a 6040-decap,

which would then (correctly) log warnings that it was seeing invalid codepoint combinations.

Thanks, --David (as draft shepherd)

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Thursday, October 27, 2016 4:39 PM
To: draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org; Black, David
Cc: tsvwg IETF list
Subject: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Tunnel congestion feedback authors, David as shepherd,

FYI. No action needed.

This email documents an argument with myself. After a few seconds, I agreed with myself that one of me was wrong. I thought I had better raise this on the list, to check that others agree with both of me. If you wish to argue with just one of me, please bear in mind that we both have the same email address (and anyway, we both agree so an argument with one is an argument with all).
_________________________

Figure 4 of RFC6040 specifies which ECN codepoint a decap must forward, for each combination of arriving inner (row) and outer (column).

            +---------+------------------------------------------------+
            |Arriving |            Arriving Outer Header               |
            |   Inner +---------+------------+------------+------------+
            |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
            +---------+---------+------------+------------+------------+
            | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
            |  ECT(0) |  ECT(0) | ECT(0)     | ECT(1)     |     CE     |
            |  ECT(1) |  ECT(1) | ECT(1) (!) | ECT(1)     |     CE     |
            |    CE   |      CE |     CE     |     CE(!!!)|     CE     |
            +---------+---------+------------+------------+------------+

RFC6040 goes on to say:

                      [...] These currently unused (CU) combinations are
      indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the
      combination is CU and always potentially dangerous, while '(!)'
      means it is CU and possibly dangerous.  In these cases,
      particularly the more dangerous ones, the decapsulator SHOULD log
      the event and MAY also raise an alarm.
 

TCF uses the following combinations of inner : outer
    Not-ECT : ECT(0)
    Not-ECT : CE

For a moment, I thought we would have to update RFC6040 to say that TCF makes these combinations no longer CU, so they are now valid, not dangerous, and they no longer need to be logged. This would have meant that Tunnel Congestion Feedback (TCF) (informational) would have to update RFC6040 (proposed standard).

Here's why I was wrong. These two combinations are certainly valid at a TCF decap. But there is still no way that, in a valid network, they would arrive at any RFC6040 (non-TCF) decap.

One might think that this combination could arrive at a 6040-decap if there was a tunnel inside a tunnel, as follows

  TCF-encap                 ---> 6040-decap ---> TCF-decap

However, that's not a valid configuration. The following tunnel-in-tunnel would be valid:

  TCF-encap ---> 6040-encap ---> 6040-decap ---> TCF-decap

...then, the above two "CU" combinations would be buried within a double inner, so only the TCF decap would see them, not the 6040-decap.

So, TCF does not need to update RFC6040. Because, in a valid network, TCF will be hidden from any 6040-decap. If the network is not valid, these combination could become visible to a 6040-decap, which would then (correctly) log warnings that it was seeing invalid codepoint combinations.

I just thought you'd like to know... no action required.



Bob

-- 

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

 

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------69A810EBC124154D3D0B34AA-- From nobody Mon Apr 3 02:08:44 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5F812955D for ; Mon, 3 Apr 2017 02:08:43 -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, RP_MATCHES_RCVD=-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 fbDr1biyYRoV for ; Mon, 3 Apr 2017 02:08:40 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 E845D1295E3 for ; Mon, 3 Apr 2017 02:08:39 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cuxyY-000C6H-Aa; Mon, 03 Apr 2017 11:08:38 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx03.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cuxyS-000BzQ-LM; Mon, 03 Apr 2017 11:08:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Mon, 3 Apr 2017 11:08:32 +0200 Cc: tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <372AFF1E-A1B4-4710-9EA5-25DBD74ED2FA@ifi.uio.no> References: <138206D2-85DF-4CAC-B196-7FC59304546A@ifi.uio.no> To: "De Schepper, Koen (Nokia - BE/Antwerp)" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 5 sum msgs/h 2 total rcpts 53471 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.007, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E71B97A3F65BAF7AA5E76AC350788EAFAFA0930F X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 12816 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tsvwg] confirming adoption of L4S drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 09:08:44 -0000 Hi, In line: > On 02 Apr 2017, at 13:24, De Schepper, Koen (Nokia - BE/Antwerp) = wrote: >=20 > Hi Michael, > =20 > Thanks for bringing up these points. See inline: > =20 > =20 > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Michael Welzl > Sent: vrijdag 31 maart 2017 21:47 > To: tsvwg IETF list > Subject: Re: [tsvwg] confirming adoption of L4S drafts > =20 > Hi all, > =20 > Sorry, I would have gone to the mic to say this yesterday, but time = was running short, there were lots of others going there, AND I was = scribing=E2=80=A6 hence now this email: > =20 > I=E2=80=99m a little worried that we=E2=80=99re adopting a behavior = inside the network, without specifying how end systems should work with = it. > =20 > [KDS] Currently the L4S Identifier draft is specifying how a CC should = behave and respond to CE, when it uses the L4S-ECT code point. The idea = is to write it rather in requirements than specific mechanisms. Probably = also the correct place to write down the TCP-Prague requirements = (currently they are a bit lost in an appendix in the DualQ draft). A = separate draft can then be made per specific L4S complaint CC to explain = its mechanisms. Would that help? I don't know? It's certainly a good starting point but I'm a little = concerned that we'll end up with RFCs to describe an inner network = behavior (and reserve a codepoint for it!), but maybe never with an end = system mechanism *for the Internet* that uses it (because there are some = issues to be addressed to which I've so far not even seen hints of a = solution). > In particular, what makes me feel uneasy is slide 2 from = yesterday=E2=80=99s presentation: > = https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-sessb-l4s-draft= s-01.pdf > which showed TCP Prague as an ICCRG item. I think this misrepresents = the role of an IRTF group: yes ICCRG can publish documents, but these = have an IRTF boilerplate, and I don=E2=80=99t think that=E2=80=99s the = right way to publish an e2e counterpart to an IETF Experimental RFC. As = I explained in tsvarea earlier this week: > = https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-sessb-discuss= ion-on-congestion-control-work-in-the-ietf-the-role-of-iccrg-michael-welzl= -00.pdf > =E2=80=A6 the more common role of ICCRG is to pre-evaluate proposals = before they=E2=80=99re even ready for the IETF. > =20 > [KDS] Yes, sorry for the confusion. For TCP-Prague, the ICCRG = reference was mainly to show where currently the work is presented = (which I think is the right wg for this, not?). As I said in the tsvwg = presentation, seen the recent iccrg and tsvwg discussions it is not = clear to me if a CC draft will be needed. I heard you say this but I don't understand your point. Why should a CC = draft not be needed? > As far as I understood, if accepted by ICCRG the process allows a = draft in TCPM. I confirm that ICCRG is the right place to present such work, for now. "if accepted by ICCRG the process allows a draft in TCPM" doesn't sound = right. It's not like we (ICCRG) accept anything and that then = automatically has a meaning in TCPM. We just review things until they = are ready for the IETF. So given that this is one piece of a larger = puzzle, I think we should first see a dedication from TCPM or TSVWG that = they'd accept a CC draft following the requirements that you lay out = (the envisioned draft about CC requirements that you mention above). = Then I think that would be a better basis. But that's just my personal = opinion. I only wanted to make it clear that the ICCRG doesn't have any direct = influence and presenting something there doesn't automatically mean = anything in the IETF. > Technically, these are not so minor issues. DCTCP, as it stands, = doesn=E2=80=99t work on the Internet; there are Internet-specific = problems that would first need to be addressed. Two cases were discussed = yesterday: > 1) how will this work when there are two bottlenecks in a row? > 2) what if TCP Prague traffic gets into a =E2=80=9Cclassic=E2=80=9D = ECN queue? > =E2=80=A6 and these are likely not the only ones. E.g., the second = problem was identified long ago, at the L4S BoF - see slide 3: > https://www.ietf.org/proceedings/96/slides/slides-96-l4s-6.pdf > where it says "Fall-back to classic TCP on classic ECN bottleneck=E2=80=9D= . Worryingly, the =E2=80=9Cstarting point=E2=80=9D column says = =E2=80=9Cnone=E2=80=9D, and so far it doesn=E2=80=99t seem that we have = an answer to this question. > =3D> what will this do to the ongoing effort of Apple to enable = (classic) ECN? > =20 > [KDS] Indeed, DCTCP can be used with DualQ in fair-share mode with = classic TCP, but in a controlled environment only. This could be in a = data center, or in a service provider=E2=80=99s network, where the = congestion points are known and support L4S. Extra L4S identification = (diffserv codepoints/IP ranges) could be used if needed. As, I think = Gorry stated, the current DCTCP draft restricts its use to controlled = environments only: > DCTCP as described in this draft > is applicable to deployments in controlled environments like > datacenters but it MUST NOT be deployed over the public Internet > without additional measures > To my understanding this allows the above described controlled service = provider environment too. Ah... understood. The "controlled service provider environment" scenario = makes sense to me. To be clear, this would be about situations where = both the sender and receiver are also within the same controlled ISP = network.=20 Yet: the intention of L4S is not to be limited to such scenarios only, I = suppose? If the plan is still to try this more openly across the = Internet, then I think my concerns are unchanged... > Are your other concerns all covered by the TCP-Prague requirements? = Should we add more? Actually I think my concern is covered well by requirement #4.2 here:=20 https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-02#appendix-A However I disagree with the discussion: *** Discussion: It is not clear at this point if it is possible to design a mechanism that always detect the aforementioned cases. One possibility is to base the detection on an increase on top of a minimum RTT, but it is not yet clear which value should trigger this. Having a delay based fall back response on L4S may as well be beneficial for preserving low latency without legacy network nodes. Even if it possible to design such a mechanism, it may well be that it would encompass additional complexity that implementers may consider unnecessary. The need for this mechanism depends on the extent of classic ECN deployment. *** I can't understand how having such a mechanism would be unnecessary: = that would be assume that EVERYONE who would enable ECN would ONLY = enable it using L4S. (there's no old code out there that treats ECT(1) and ECT(0) equal, and = nobody would just turn it on - even today that's probably already = wrong). I also can't understand why it might not be possible: I'd say it's a = strong requirement. What might happen is that you get false positives - = so be it. Then you'll just have to be conservative. BTW I guess there's more input you could use - possibly the pattern of = returning ECN-marks can also be a hint as to the use of an L4S vs. = classic ECN queue. Cheers, Michael From nobody Tue Apr 4 19:17:04 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FF8127ABE for ; Tue, 4 Apr 2017 19:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 pIJvRuearBeX for ; Tue, 4 Apr 2017 19:17:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42807120727 for ; Tue, 4 Apr 2017 19:17:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DED49032; Wed, 05 Apr 2017 02:16:58 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 5 Apr 2017 03:16:57 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.121]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 5 Apr 2017 10:16:53 +0800 From: "Weixinpeng (Jackie)" To: Joe Touch , tsvwg CC: Mark Townsley Thread-Topic: [tsvwg] question about layered congestion issue - draft-ietf-tsvwg-tunnel-congestion-feedback Thread-Index: AQHSqbXLprHSjHac3keA1AehQPXQlKG2CFYA Date: Wed, 5 Apr 2017 02:16:52 +0000 Message-ID: References: <77bbceb7-d905-d4b0-a250-41450ee56645@isi.edu> In-Reply-To: <77bbceb7-d905-d4b0-a250-41450ee56645@isi.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58E4539A.008B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.121, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5805aff07649fa40f646ec01ed773191 Archived-At: Subject: Re: [tsvwg] question about layered congestion issue - draft-ietf-tsvwg-tunnel-congestion-feedback X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 02:17:03 -0000 SGkgSm9lLA0KIFRoYW5rcyBmb3IgeW91ciBjb21tZW50cyBhbmQgcGxlYXNlIHNlZSBteSByZXBs aWVzIGlubGluZS4NCg0KUmVnYXJkcywNCi1YaW5wZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEpvZSBUb3VjaA0KPlNlbnQ6IEZyaWRheSwgTWFyY2ggMzEsIDIwMTcgODoyOCBB TQ0KPlRvOiB0c3Z3Zw0KPkNjOiBNYXJrIFRvd25zbGV5DQo+U3ViamVjdDogW3RzdndnXSBxdWVz dGlvbiBhYm91dCBsYXllcmVkIGNvbmdlc3Rpb24gaXNzdWUgLQ0KPmRyYWZ0LWlldGYtdHN2d2ct dHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2sNCj4NCj5IaSwgYWxsLA0KPg0KPkRpc2N1c3Npbmcg dGhpcyBvZmYtbGlzdCB3aXRoIG15IGNvLWF1dGhvciBvbiB0aGUgZHJhZnQtaWV0Zi1pbnRhcmVh LXR1bm5lbHMgZG9jDQo+KE1hcmsgVG93bnNsZXksIGNjJ2QpLCB3ZSB3YXMgd29uZGVyaW5nIHdo YXQgaGFzIGJlZW4gZG9uZSB0byB2YWxpZGF0ZSB0aGlzDQo+d29yayBhZ2FpbnN0IHRoZSBwb3Rl bnRpYWwgZm9yIGxheWVyZWQgY29uZ2VzdGlvbiBpbnRlcmZlcmVuY2U/DQo+DQo+SS5lLiwgcHJv cGFnYXRpbmcgRUNOIGZyb20gaW5zaWRlIHRoZSB0dW5uZWwgdG8gb3V0c2lkZSAoUkZDIDYwNDAp IGlzIHNhZmUsIGJ1dA0KPnVzaW5nIHRoYXQgaW5mb3JtYXRpb24gdG8gZ292ZXJuIHR1bm5lbCBh ZG1pc3Npb24gc2VlbXMgbGlrZSBpdCdzIHVzaW5nIEVDTiB0bw0KPmRldGVybWluZSBwZXItaG9w IGZvcndhcmRpbmcuIEkgd291bGQgZXhwZWN0IHRoYXQgdG8gYmUgdGhlIHB1cnZpZXcgb2YgdGhl DQo+cm91dGVyIHdoZXJlIHRoZSB0dW5uZWwgaXMgYXR0YWNoZWQgKHdoZXJlIHRoZSB0dW5uZWwg aW5ncmVzcyBhbmQgZWdyZXNzIGFjdCBhcw0KPippbnRlcmZhY2VzKiBhdCBlaXRoZXIgcm91dGVy cyBvciBob3N0cyB3aGVyZSB0aGUgdHVubmVsIG9yaWdpbmF0ZXMvdGVybWluYXRlcw0KPi0gYXMg cGVyIGRyYWZ0LWlldGYtaW50YXJlYS10dW5uZWxzKS4NCj4NCj5JTU8sIHRoZXJlIGFyZSB0d28g Y2xlYXJseSB2YWxpZCBhcHByb2FjaGVzICh3aGljaCBoYXZlIGFscmVhZHkgYmVlbg0KPmFkZHJl c3NlZCBieSBSRkNzKToNCj4NCj4gICAgMSkgdXNlIHRoZSBpbnRyYS10dW5uZWwgRUNOIHRvIHRy aWdnZXIgY2lyY3VpdCBicmVha2VycyAoUkZDIDgwODQpDQo+DQo+ICAgIDIpIHByb3BhZ2F0ZSB0 aGUgaW50cmEtdHVubmVsIEVDTiB0byBvdXRzaWRlIHRoZSB0dW5uZWwgKFJGQyA2MDQwKQ0KPg0K Pkhvd2V2ZXIsIHRoaXMgZG9jdW1lbnQgYXBwZWFycyB0byByZWNvbW1lbmQgYW4gYXBwcm9hY2gg dGhhdCByZXN1bHRzIGluDQo+bGF5ZXJlZCBjb25nZXN0aW9uIGNvbnRyb2wsIGJ1dCBkb2Vzbid0 IGFwcGVhciB0byBhZGRyZXNzIGRlY291cGxpbmcNCj5pbnRlcmFjdGlvbnMgd2l0aCBFMkUgY29u Z2VzdGlvbiBjb250cm9sIChlLmcuLCBUQ1AsIERDQ1AsIFNDVFApLCBub3IgZG9lcyBpdA0KPnNl ZW0gdG8gcHJlc2VudCBhbnkgYW5hbHlzaXMgKGluY2wuIGV4cGVyaW1lbnRzKSB0byBkZW1vbnN0 cmF0ZSB0aGF0IHRoaXMgaXNuJ3QgYQ0KPmNvbmNlcm4uIEluIGZhY3QsIGl0IG1lbnRpb25zIHRo ZXNlIHByb3RvY29scyBvbmx5IGluIHBhc3NpbmcgaW4gdGhlIGludHJvZHVjdGlvbi4NCj4NCj5I YXMgdGhpcyBiZWVuIGFkZHJlc3NlZD8gSWYgbm90LCBjYW4gaXQgYmU/DQo+DQoNCltXZWldIFRo ZSBzZWN0aW9uIDYgb2YgdGhlIGRvY3VtZW50IGhhcyBwcm92aWRlZCBzb21lIGRlc2NyaXB0aW9u IG9uIGhvdyB0aGUgbWVjaGFuaXNtIGRpc2N1c3Npb24gc2hvdWxkIGNvZXhpc3RlbmNlIHdpdGgg ZTJlIGNvbmdlc3Rpb24gY29udHJvbC4NCkxldCBtZSBrbm93IGlmIGl0IGRvZXNuJ3QgYWRkcmVz cyB5b3VyIGNvbmNlcm5zLiBUaGFua3MuDQoNCj5UaGFua3MsDQo+DQo+Sm9lDQoNCg== From nobody Tue Apr 4 19:46:17 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57755128ACA for ; Tue, 4 Apr 2017 19:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzd_OQ3oDo2R for ; Tue, 4 Apr 2017 19:46:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3078F1204DA for ; Tue, 4 Apr 2017 19:46:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DED51497; Wed, 05 Apr 2017 02:46:06 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 5 Apr 2017 03:46:04 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.121]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 5 Apr 2017 10:45:53 +0800 From: "Weixinpeng (Jackie)" To: Bob Briscoe , "Black, David" , "draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org" CC: tsvwg IETF list Thread-Topic: Tunnel Congestion Feedback: (non-)update to RFC6040 Thread-Index: AQHSMJIdqgBqqFRtE0e6Mhkxp5lkF6C+tKeAgAMnj6CAAFF9gIAADsOAgPFUCkmAA2oncA== Date: Wed, 5 Apr 2017 02:45:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B48B3B21E1nkgeml514mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58E45A6E.0116, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.121, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 44e43831c21cb6ed217a001306853d6b Archived-At: Subject: Re: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 02:46:15 -0000 --_000_C5C3BB522B1DDF478AA09545169155B48B3B21E1nkgeml514mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQm9iLA0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBhbmQgcGxlYXNlIHNlZSBpbmxpbmUu DQpSZWdhcmRzLA0KLVhpbnBlbmcNCg0KRnJvbTogQm9iIEJyaXNjb2UgW21haWx0bzppZXRmQGJv YmJyaXNjb2UubmV0XQ0KU2VudDogTW9uZGF5LCBBcHJpbCAwMywgMjAxNyA1OjM0IEFNDQpUbzog V2VpeGlucGVuZyAoSmFja2llKTsgQmxhY2ssIERhdmlkOyBkcmFmdC1pZXRmLXRzdndnLXR1bm5l bC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnDQpDYzogdHN2d2cgSUVURiBsaXN0 DQpTdWJqZWN0OiBSZTogVHVubmVsIENvbmdlc3Rpb24gRmVlZGJhY2s6IChub24tKXVwZGF0ZSB0 byBSRkM2MDQwDQoNCldlaXhpbnBlbmcsIGNvLWF1dGhvcnMsICBhbmQgRGF2aWQsDQoNCkkgaGFk IHByb21pc2VkIGEgcmV2aWV3IG9mIHRoZSBsYXRlc3QgVENGIGRyYWZ0LCBidXQgZmFpbGVkIHRv IHByb3ZpZGUgaXQgc28gZmFyLg0KSSBoYWxmIHJlYWQgaXQgdGhyb3VnaCBvbiBGcmlkYXksIGFu ZCBJIHdpbGwgZmluaXNoIGFuZCB3cml0ZSB1cCBteSByZXZpZXcgdGhpcyB3ZWVrLg0KDQpIZXJl JyBhIHF1aWNrIHN1bW1hcnkgb2YgdGhlIG1haW4gcG9pbnRzIHNvIGZhcjoNCg0KUy4xLiBJbnRy bzogTW90aXZhdGlvbg0KVGhlIG1vdGl2YXRpb24gc2hvdWxkIGFsc28gaW5jbHVkZSBhIGhlYXZ5 IGxvYWQgZnJvbSBhIG11Y2ggbGFyZ2VyIHRoYW4gZXhwZWN0ZWQgbnVtYmVyIG9mIHJlc3BvbnNp dmUgZmxvd3MNCltXZWldIE9rLCBJIHdpbGwgYWRkIGl0Lg0KDQpTLjEgSW50cm86IFNjb3BlDQpJ IHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgc2F5IHRoYXQNCiogaXQgZ2l2ZXMgbm8gYWR2aWNlIG9u IGhvdyB0byBzZWxlY3Qgd2hpY2ggdHVubmVsIGVuZHBvaW50cyBzaG91bGQgYmUgdXNlZCBpbiBv cmRlciB0byBtYW5hZ2UgdHJhZmZpYyBvdmVyIGEgbmV0d29yayBjcmlzcy1jcm9zc2VkIGJ5IG11 bHRpcGxlIHR1bm5lbHMuDQoqIGlmIGEgY29uZ2VzdGVkIG5vZGUgaXMgcGFydCBvZiBtdWx0aXBs ZSB0dW5uZWxzLCBhbmQgaXQgY2F1c2VzIGNvbmdlc3Rpb24gZmVlZGJhY2sgdG8gbXVsdGlwbGUg dHJhZmZpYyBtYW5hZ2VtZW50IGZ1bmN0aW9ucyBhdCB0aGUgaW5ncmVzc2VzIG9mIGFsbCB0aGUg dHVubmVscywgdGhlIGRyYWZ0IGdpdmVzIG5vIGFkdmljZSBvbiBob3cgYWxsIHRoZSB0cmFmZmlj IG1hbmFnZW1lbnQgZnVuY3Rpb25zIHNob3VsZCByZXNwb25kLg0KKiBldGMuIChpbiBteSBmdWxs IHJldmlldywgSSB3aWxsIHByb3ZpZGUgYSBmdWxsIGxpc3Qgb2Ygc3ViamVjdHMgdGhhdCBhcmUg b3V0IG9mIHNjb3BlKS4NCltXZWldIE9rLg0KDQpTLjMuIEZlZWRiYWNrIE1vZGVsczoNClRoZSBh cmNoaXRlY3R1cmUgZGlhZ3JhbXMgYW5kIHRleHQgbmVlZCB0byBpbmNsdWRlIGNvbXBvbmVudHMg dGhhdCBhcHBseSBhIGNvbnNpc3RlbnQgbWVhc3VyZW1lbnQgcG9saWN5ICh0ZW1wbGF0ZSByZWNv cmRzIGluIElQRklYLXNwZWFrKSBhdCBib3RoIGluZ3Jlc3MgYW5kIGVncmVzcy4gVGhpcyBpcyBh IGtleSBwYXJ0IG9mIGludGVyb3BlcmFiaWxpdHksIHdoaWNoIGlzIHdoYXQgdGhlIElFVEYgc2hv dWxkIGJlIGFsbCBhYm91dC4gVGVtcGxhdGUgcmVjb3JkcyBhcmUgZGVzY3JpYmVkIGxhdGVyIHdo ZW4gdGhlIG1lY2hhbmlzbSBpcyBzcGVjaWZpZWQsIGJ1dCB0aGV5IGFyZSBub3Qgc2hvd24gaW4g dGhlIGxheW91dCBvZiB0aGUgY29tcG9uZW50cyBpbiBTLjMuDQpbV2VpXSBJIHdpbGwgcHJvdmlk ZSBhIGRlc2NyaXB0aW9uIG9mIFRlbXBsYXRlIHJlY29yZCBpbiB0aGlzIHNlY3Rpb24uIEJ1dCBJ IGFtIHdvbmRlcmluZyB3aGV0aGVyIGEgZGV0YWlsZWQgZGVzY3JpcHRpb24gb2YgVGVtcGxhdGUg UmVjb3JkIGFzIHNlY3Rpb24gNi4xIGlzIG5lZWRlZCBoZXJlIG9yIG5vdD8NCg0KDQpTLjQuIENv bmdlc3Rpb24gTGV2ZWwgTWVhc3VyZW1lbnQ6DQpNZWFzdXJlbWVudCBvZiBFQ04gaGFzIGJlZW4g Y2hhbmdlZCB3aXRob3V0IHRoaW5raW5nIGNsZWFybHkgd2hldGhlciBpdCBuZWVkZWQgdG8gY2hh bmdlLg0KDQogICAgYSkgRWFybGllciBkcmFmdHMgZXhwbG9pdGVkIHRoZSBmYWN0IHRoYXQgdGhl IGlubmVyIGhvbGRzIGEgImZyb3plbiIgcmVjb3JkIG9mIHRoZSBFQ04gZmllbGQgYXQgdGhlIGlu Z3Jlc3MuIFNvIEVDTiBtZWFzdXJlbWVudHMgY291bGQgYmUgbWFkZSBzb2xlbHkgYXQgdGhlIGVn cmVzcyAoY29tcGFyaW5nIHRoZSBvdXRlciB3aXRoIHRoZSBpbm5lcikuIEluIGRyYWZ0LTA0LCBF Q04gY29kZXBvaW50cyBhcmUgbWVhc3VyZWQgYXQgdGhlIGluZ3Jlc3MgYW5kIGF0IHRoZSBlZ3Jl c3MsIHdpdGggdGhlIGluZ3Jlc3Mgc2VuZGluZyByZWd1bGFyIG1lYXN1cmVtZW50IHJlcG9ydHMg dG8gdGhlIGVncmVzcyBmb3IgY29tcGFyaXNvbi4gSG93ZXZlciwgaXQgaXMgYWx3YXlzIHNhZmVy IHRvIG1lYXN1cmUgRUNOIHNvbGVseSBhdCB0aGUgZWdyZXNzLCBldmVuIHRob3VnaCBhIGRpZmZl cmVudCBtZWNoYW5pc20gaGFzIHRvIG1lYXN1cmUgZHJvcHMgd2l0aGluIHRoZSB0dW5uZWwgKGR1 ZSB0byBub24tRUNOIG5vZGVzLCBvciBub2RlcyB0aGF0IGhhdmUgc3dpdGNoZWQgb2ZmIEVDTiBk dWUgdG8gb3ZlcmxvYWQsIG9yIGR1ZSB0byBjYXVzZXMgb2YgbG9zcyBvdGhlciB0aGFuIGNvbmdl c3Rpb24sIGUuZy4gdHJhbnNtaXNzaW9uIGVycm9ycykuDQogICAgIC0gSXQgaXMgYWx3YXlzIHNh ZmVyIHRvIHNvbGVseSBtZWFzdXJlIEVDTiBhdCB0aGUgZWdyZXNzLCBiZWNhdXNlIGl0IGlzIG5v dCB2dWxuZXJhYmxlIHRvIGluZ3Jlc3MtZWdyZXNzIG1lYXN1cmVtZW50IHBhY2tldHMgYmVpbmcg ZHJvcHBlZC4NCiAgICAgLSBTb2xlbHkgbWVhc3VyaW5nIEVDTiBhdCBlZ3Jlc3MgaXMgbm8gbGVz cyBwcmVjaXNlLCBiZWNhdXNlIG9ubHkgdGhlIHByb3BvcnRpb24gb2YgdGhlIGRpZmZlcmVudCBF Q04gZmllbGRzIGlzIG5lZWRlZCwgYW5kIHRoYXQgc3RheXMgYXBwcm94aW1hdGVseSB0aGUgc2Ft ZSBldmVuIGlmIHRoZXJlIGlzIGRyb3AsIGFzc3VtaW5nIGRyb3AgaXMgbm90IGJpYXNlZCB0b3dh cmRzIGNlcnRhaW4gRUNOIGNvZGVwb2ludHMgKG5vIGtub3duIG1lY2hhbmlzbSBkb2VzIHRoYXQp Lg0KDQogICAgYikgSW4gZHJhZnQtMDQgdGhlIGZha2VkIEVDVCBhcHByb2FjaCBoYXMgYmVlbiBs ZWZ0IHVuY2hhbmdlZCBhdCB0aGUgaW5ncmVzcywgYnV0IGl0IGlzIG5vIGxvbmdlciB1c2VkIGF0 IHRoZSBlZ3Jlc3MgZm9yIGRldGVjdGluZyBkZWZlcnJlZCBkcm9wcyAoYnkgbG9va2luZyBmb3Ig YSBOb3QtRUNOIGlubmVyIGFuZCBhIENFIG91dGVyKS4gQWdhaW4sIHRoZXJlIGlzIG5vdGhpbmcg d3Jvbmcgd2l0aCBtZWFzdXJpbmcgRUNOIGFuZCBkZXRlY3RpbmcgZGVmZXJyZWQgZHJvcHMgc29s ZWx5IGF0IHRoZSBlZ3Jlc3MsIGV2ZW4gaWYgdGhlcmUgYXJlIGRyb3BzIHdpdGhpbiB0aGUgdHVu bmVsLiBUbyBtZWFzdXJlIGRyb3BzIHdpdGhpbiB0aGUgdHVubmVsLCBpdCBpcyBuZWNlc3Nhcnkg dG8gY29tcGFyZSBpbmdyZXNzIGFuZCBlZ3Jlc3MgYnl0ZXMsIGJ1dCB0aGF0IGRvZXMgbm90IG1h a2UgaXQgd3JvbmcgdG8gc3RpbGwgbWVhc3VyZSBhbmQgY29tcGFyZSBFQ04gc29sZWx5IGF0IHRo ZSBlZ3Jlc3MuDQpbV2VpXSBJIGFncmVlIHRoYXQgc29sZWx5IG1lYXN1cmluZyBFQ04gYXQgZWdy ZXNzIGlzIGVub3VnaCB0byBnZXQgdGhlIHByb3BvcnRpb24gb2YgZGlmZmVyZW50IEVDTiBmaWVs ZHMsIGJ1dCB0aGUgcmVhc29uIHdoeSBFQ04gY29kZXBvaW50cyBhcmUgbWVhc3VyZWQgYm90aCBh dCBpbmdyZXNzIGFuZCBlZ3Jlc3MgaXMgdG8gbWVhc3VyZSB0aGUgcGFja2V0cyBkcm9wcGVkIHdp dGhpbiB0aGUgdHVubmVsIGJ5IGNvbXBhcmluZyBjb3VudHMgYXQgaW5ncmVzcyBhbmQgZWdyZXNz Lg0KDQoNClMuNC4gQ29uZ2VzdGlvbiBMZXZlbCBNZWFzdXJlbWVudDogVW5pdHMNClRocm91Z2hv dXQgbWVhc3VyZW1lbnQgaW52b2x2ZXMgY291bnRpbmcgcGFja2V0cy4gSG93ZXZlciwgaXQgc2hv dWxkIGNvdW50IHRoZSBieXRlcyBpbiBwYWNrZXRzIHdpdGggZWFjaCB0eXBlIG9mIG1hcmtpbmcs IG5vdCBqdXN0IHRoZSBudW1iZXIgb2YgcGFja2V0cy4gU2VlIFJGQzcxNDEgc2VjdGlvbiAyLjM8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxNDEjc2VjdGlvbi0yLjM+LiBBbHRob3Vn aCB0aGUgcmVjb21tZW5kYXRpb24gaW4gdGhhdCBSRkMgaXMgYWJvdXQgd2hhdCBhIC90cmFuc3Bv cnQvIHNob3VsZCBtZWFzdXJlIHdoZW4gcmVzcG9uZGluZyB0byBjb25nZXN0aW9uLCBsb2dpY2Fs bHkgaXQgc2hvdWxkIGFwcGx5IGluIHRoaXMgY2FzZSB3aGVuIGEgdHJhZmZpYyBtYW5hZ2VtZW50 IGZ1bmN0aW9uIGlzIHJlc3BvbmRpbmcgaW4gcGxhY2Ugb2YgYSB0cmFuc3BvcnQuIFJGQzcxNDEg YWxzbyBnaXZlcyByZWNvbW1lbmRhdGlvbnMgb24gd2hpY2ggaGVhZGVycyB0byBjb3VudC4NCltX ZWldIE9rLCBpdOKAmXMgYSBnb29kIHN1Z2dlc3Rpb24uDQoNCg0KDQpJIHNoYWxsIGFkZCB0byB0 aGlzIHJldmlldyBsYXRlciBpbiB0aGUgd2Vlay4NCg0KT25lIHF1ZXN0aW9uIGZvciBXZWl4aW5w ZW5nOiBIYXZlIHlvdSBpbXBsZW1lbnRlZCB0aGlzIG1lY2hhbmlzbT8NCltXZWldIEN1cnJlbnRs eSwgd2Ugb25seSBpbXBsZW1lbnQgdGhpcyBtZWNoYW5pc20gaW4gYSBzaW11bGF0aW9uIGVudmly b25tZW50Lg0KDQoNCg0KQm9iDQoNCk9uIDAxLzExLzE2IDAxOjQ5LCBXZWl4aW5wZW5nIChKYWNr aWUpIHdyb3RlOg0KSGkgQm9iIGFuZCBEYXZpZCwNCkJlY2F1c2UgdGhlIGRlYWRsaW5lIGhhcyBw YXNzZWQsIEkgd2lsbCB1cGRhdGUgaXQgYXMgcGFydCBvZiBwb3N0LVdHTEMgdXBkYXRlLiBUaGFu a3MuDQoNClJlZ2FyZHMsDQotWGlucGVuZyAoSmFja2llKQ0KDQpGcm9tOiBCbGFjaywgRGF2aWQg W21haWx0bzpEYXZpZC5CbGFja0BkZWxsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDAx LCAyMDE2IDEyOjE0IEFNDQpUbzogQm9iIEJyaXNjb2U7IFdlaXhpbnBlbmcgKEphY2tpZSk7IGRy YWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMu aWV0Zi5vcmc+DQpDYzogdHN2d2cgSUVURiBsaXN0OyBCbGFjaywgRGF2aWQNClN1YmplY3Q6IFJF OiBUdW5uZWwgQ29uZ2VzdGlvbiBGZWVkYmFjazogKG5vbi0pdXBkYXRlIHRvIFJGQzYwNDANCg0K PiBJIGFzc3VtZSB5b3Ugd2lsbCB1cGRhdGUgdGhlIFRDRiBkcmFmdCB0b2RheSBiZWZvcmUgdGhl IGRlYWRsaW5lLg0KDQooQXMgZHJhZnQgc2hlcGhlcmQpIFRoYXTigJlzIG5vdCByZWFsbHkgbmVj ZXNzYXJ5IC0gdGhlIFRDRiBkcmFmdCBpcyBpbiBXR0xDLCBzbyB0aGlzIGNoYW5nZSBjYW4gYmUg ZG9uZSBhcyBwYXJ0IG9mIGEgcG9zdC1XR0xDIHVwZGF0ZS4NCg0KVGhhbmtzLCAtLURhdmlkDQoN CkZyb206IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldF0NClNlbnQ6IE1v bmRheSwgT2N0b2JlciAzMSwgMjAxNiAxMToyMiBBTQ0KVG86IFdlaXhpbnBlbmcgKEphY2tpZSk7 IEJsYWNrLCBEYXZpZDsgZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFj a0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlv bi1mZWVkYmFja0B0b29scy5pZXRmLm9yZz4NCkNjOiB0c3Z3ZyBJRVRGIGxpc3QNClN1YmplY3Q6 IFJlOiBUdW5uZWwgQ29uZ2VzdGlvbiBGZWVkYmFjazogKG5vbi0pdXBkYXRlIHRvIFJGQzYwNDAN Cg0KWGlucGVuZywNCg0KSSBhZ3JlZSB0aGF0IFRDRiBkb2VzIG5vdCB1cGRhdGUgUkZDNjA0MCAo YXMgSSBzYWlkKS4NCg0KQnV0IERhdmlkIGlzIHJpZ2h0IHRoYXQgdGhlIFRDRiBkcmFmdCBpdHNl bGYgbmVlZHMgdG8gYmUgdXBkYXRlZCB0byBzYXkgdGhhdCBpdCBtb2RpZmllcyB0aGUgYmVoYXZp b3VyIG9mIGEgUkZDNjA0MCBlZ3Jlc3Mgc28gYXMgdG8gaXNzdWUgb3IgbG9nIGFueSB3YXJuaW5n cyB3aGVuIGl0IHJlY2VpdmVzIGFuIEVDVCgwKSBvciBDRSBvdXRlciB3aXRoIGEgTm90LUVDVCBp bm5lci4NCg0KSSBhc3N1bWUgeW91IHdpbGwgdXBkYXRlIHRoZSBUQ0YgZHJhZnQgdG9kYXkgYmVm b3JlIHRoZSBkZWFkbGluZS4NCg0KQ2hlZXJzDQoNCkJvYg0KT24gMzEvMTAvMTYgMDI6MzgsIFdl aXhpbnBlbmcgKEphY2tpZSkgd3JvdGU6DQpIaSBEYXZpZCwgQm9iLA0KSSBhZ3JlZSB0aGF0IHRo ZSBiZWhhdmlvciBkZWZpbmVkIGluIFJGQzYwNDAgZG9lc27igJl0IHRvIGJlIHVwZGF0ZWQgZHVl IHRvIHRoZSBUQ0YgZHJhZnQsIGJlY2F1c2Ugd2hhdOKAmXMgZGVmaW5lZCBpbiBSRkMgNjA0MCBo YXMgYSBicm9hZGVyIHVzYWdlIGFuZCBub3QganVzdCBmb3IgVENGLg0KSSB0aGluayBEYXZpZCBo YXMgcHJvdmlkZWQgYSBnb29kIHN1Z2dlc3Rpb24gYmVsb3cuIFRoYW5rcy4NCg0KUmVnYXJkcywN Ci1YaW5wZW5nIChKYWNraWUpDQoNCkZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJsYWNrLCBEYXZpZA0KU2VudDogU2F0dXJkYXksIE9jdG9i ZXIgMjksIDIwMTYgMTA6MjggQU0NClRvOiBCb2IgQnJpc2NvZTsgZHJhZnQtaWV0Zi10c3Z3Zy10 dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0 Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9yZz4NCkNjOiB0 c3Z3ZyBJRVRGIGxpc3QNClN1YmplY3Q6IFJlOiBbdHN2d2ddIFR1bm5lbCBDb25nZXN0aW9uIEZl ZWRiYWNrOiAobm9uLSl1cGRhdGUgdG8gUkZDNjA0MA0KDQpCb2IsDQoNCkkgdGhpbmsgeW914oCZ dmUgZm91bmQgc29tZXRoaW5nLiAgVGhlIFRDRiBkcmFmdCBjdXJyZW50bHkgdXNlcyBSRkMgNjA0 MCBiZWhhdmlvciBieSByZWZlcmVuY2U6DQoNCiAgIHdoZW4gZGVjYXBzdWxhdGluZyBwYWNrZXRz IGF0IGVncmVzcywNCiAgIFJGQzYwNDAgZGVmaW5lZCBkZWNhcHN1bGF0aW9uIGJlaGF2aW9yIGlz IHVzZWQsIGFuZCBhY2NvcmRpbmcgdG8NCiAgIFJGQzYwNDAsIHRoZSBwYWNrZXRzIG1hcmtlZCBh cyBDRXxOLUVDVCB3aWxsIGJlIGRyb3BwZWQgYnkgZWdyZXNzLg0KDQpJIHRoaW5rIHRoaXMgbmVl ZHMgdG8gYmUgc2xpZ2h0bHkgcmV2aXNlZCB0byBzYXkgdGhhdCBDRXxOLUVDVCBpcyBkcm9wcGVk IHdpdGhvdXQgYW55IG90aGVyDQphY3Rpb24sIGFuZCBhbGwgb3RoZXIgYmVoYXZpb3IgaXMgYXMg cGVyIFJGQyA2MDQwLCBhcyBDRXxOLUVDVCBpcyBleHBlY3RlZCBhdCBhIFRDRiBlZ3Jlc3MgYW5k DQpoZW5jZSB0aGUgbG9nZ2luZyBhbmQgYWxhcm0gYmVoYXZpb3IgZm9yIHRoYXQgY29tYmluYXRp b24gaW4gUkZDIDYwNDAgaXMgaW5hcHByb3ByaWF0ZS4NCg0KT25jZSB0aGF04oCZcyBkb25lLCBJ IHRoaW5rIHlvdXIgcmVhc29uaW5nIGluIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgYmVjb21lcyBj b3JyZWN0Og0KDQpJZiB0aGUgbmV0d29yayBpcyBub3QgdmFsaWQsIHRoZXNlIGNvbWJpbmF0aW9u IGNvdWxkIGJlY29tZSB2aXNpYmxlIHRvIGEgNjA0MC1kZWNhcCwNCndoaWNoIHdvdWxkIHRoZW4g KGNvcnJlY3RseSkgbG9nIHdhcm5pbmdzIHRoYXQgaXQgd2FzIHNlZWluZyBpbnZhbGlkIGNvZGVw b2ludCBjb21iaW5hdGlvbnMuDQoNClRoYW5rcywgLS1EYXZpZCAoYXMgZHJhZnQgc2hlcGhlcmQp DQoNCkZyb206IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldF0NClNlbnQ6 IFRodXJzZGF5LCBPY3RvYmVyIDI3LCAyMDE2IDQ6MzkgUE0NClRvOiBkcmFmdC1pZXRmLXRzdndn LXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1p ZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnPjsgQmxh Y2ssIERhdmlkDQpDYzogdHN2d2cgSUVURiBsaXN0DQpTdWJqZWN0OiBUdW5uZWwgQ29uZ2VzdGlv biBGZWVkYmFjazogKG5vbi0pdXBkYXRlIHRvIFJGQzYwNDANCg0KVHVubmVsIGNvbmdlc3Rpb24g ZmVlZGJhY2sgYXV0aG9ycywgRGF2aWQgYXMgc2hlcGhlcmQsDQoNCkZZSS4gTm8gYWN0aW9uIG5l ZWRlZC4NCg0KVGhpcyBlbWFpbCBkb2N1bWVudHMgYW4gYXJndW1lbnQgd2l0aCBteXNlbGYuIEFm dGVyIGEgZmV3IHNlY29uZHMsIEkgYWdyZWVkIHdpdGggbXlzZWxmIHRoYXQgb25lIG9mIG1lIHdh cyB3cm9uZy4gSSB0aG91Z2h0IEkgaGFkIGJldHRlciByYWlzZSB0aGlzIG9uIHRoZSBsaXN0LCB0 byBjaGVjayB0aGF0IG90aGVycyBhZ3JlZSB3aXRoIGJvdGggb2YgbWUuIElmIHlvdSB3aXNoIHRv IGFyZ3VlIHdpdGgganVzdCBvbmUgb2YgbWUsIHBsZWFzZSBiZWFyIGluIG1pbmQgdGhhdCB3ZSBi b3RoIGhhdmUgdGhlIHNhbWUgZW1haWwgYWRkcmVzcyAoYW5kIGFueXdheSwgd2UgYm90aCBhZ3Jl ZSBzbyBhbiBhcmd1bWVudCB3aXRoIG9uZSBpcyBhbiBhcmd1bWVudCB3aXRoIGFsbCkuDQpfX19f X19fX19fX19fX19fX19fX19fX19fDQoNCkZpZ3VyZSA0IG9mIFJGQzYwNDAgc3BlY2lmaWVzIHdo aWNoIEVDTiBjb2RlcG9pbnQgYSBkZWNhcCBtdXN0IGZvcndhcmQsIGZvciBlYWNoIGNvbWJpbmF0 aW9uIG9mIGFycml2aW5nIGlubmVyIChyb3cpIGFuZCBvdXRlciAoY29sdW1uKS4NCg0KICAgICAg ICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQoNCiAgICAgICAgICAgIHxBcnJpdmluZyB8ICAgICAgICAgICAgQXJyaXZpbmcg T3V0ZXIgSGVhZGVyICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICB8ICAgSW5uZXIgKy0t LS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCg0KICAgICAg ICAgICAgfCAgSGVhZGVyIHwgTm90LUVDVCB8IEVDVCgwKSAgICAgfCBFQ1QoMSkgICAgIHwgICAg IENFICAgICB8DQoNCiAgICAgICAgICAgICstLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KDQogICAgICAgICAgICB8IE5vdC1FQ1QgfCBO b3QtRUNUIHxOb3QtRUNUKCEhISl8Tm90LUVDVCghISEpfCA8ZHJvcD4oISEhKXwNCg0KICAgICAg ICAgICAgfCAgRUNUKDApIHwgIEVDVCgwKSB8IEVDVCgwKSAgICAgfCBFQ1QoMSkgICAgIHwgICAg IENFICAgICB8DQoNCiAgICAgICAgICAgIHwgIEVDVCgxKSB8ICBFQ1QoMSkgfCBFQ1QoMSkgKCEp IHwgRUNUKDEpICAgICB8ICAgICBDRSAgICAgfA0KDQogICAgICAgICAgICB8ICAgIENFICAgfCAg ICAgIENFIHwgICAgIENFICAgICB8ICAgICBDRSghISEpfCAgICAgQ0UgICAgIHwNCg0KICAgICAg ICAgICAgKy0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0rDQpSRkM2MDQwIGdvZXMgb24gdG8gc2F5Og0KDQogICAgICAgICAgICAgICAgICAg ICAgWy4uLl0gVGhlc2UgY3VycmVudGx5IHVudXNlZCAoQ1UpIGNvbWJpbmF0aW9ucyBhcmUNCg0K ICAgICAgaW5kaWNhdGVkIGluIEZpZ3VyZSA0IGJ5ICcoISEhKScgb3IgJyghKScsIHdoZXJlICco ISEhKScgbWVhbnMgdGhlDQoNCiAgICAgIGNvbWJpbmF0aW9uIGlzIENVIGFuZCBhbHdheXMgcG90 ZW50aWFsbHkgZGFuZ2Vyb3VzLCB3aGlsZSAnKCEpJw0KDQogICAgICBtZWFucyBpdCBpcyBDVSBh bmQgcG9zc2libHkgZGFuZ2Vyb3VzLiAgSW4gdGhlc2UgY2FzZXMsDQoNCiAgICAgIHBhcnRpY3Vs YXJseSB0aGUgbW9yZSBkYW5nZXJvdXMgb25lcywgdGhlIGRlY2Fwc3VsYXRvciBTSE9VTEQgbG9n DQoNCiAgICAgIHRoZSBldmVudCBhbmQgTUFZIGFsc28gcmFpc2UgYW4gYWxhcm0uDQoNCg0KVENG IHVzZXMgdGhlIGZvbGxvd2luZyBjb21iaW5hdGlvbnMgb2YgaW5uZXIgOiBvdXRlcg0KICAgIE5v dC1FQ1QgOiBFQ1QoMCkNCiAgICBOb3QtRUNUIDogQ0UNCg0KRm9yIGEgbW9tZW50LCBJIHRob3Vn aHQgd2Ugd291bGQgaGF2ZSB0byB1cGRhdGUgUkZDNjA0MCB0byBzYXkgdGhhdCBUQ0YgbWFrZXMg dGhlc2UgY29tYmluYXRpb25zIG5vIGxvbmdlciBDVSwgc28gdGhleSBhcmUgbm93IHZhbGlkLCBu b3QgZGFuZ2Vyb3VzLCBhbmQgdGhleSBubyBsb25nZXIgbmVlZCB0byBiZSBsb2dnZWQuIFRoaXMg d291bGQgaGF2ZSBtZWFudCB0aGF0IFR1bm5lbCBDb25nZXN0aW9uIEZlZWRiYWNrIChUQ0YpIChp bmZvcm1hdGlvbmFsKSB3b3VsZCBoYXZlIHRvIHVwZGF0ZSBSRkM2MDQwIChwcm9wb3NlZCBzdGFu ZGFyZCkuDQoNCkhlcmUncyB3aHkgSSB3YXMgd3JvbmcuIFRoZXNlIHR3byBjb21iaW5hdGlvbnMg YXJlIGNlcnRhaW5seSB2YWxpZCBhdCBhIFRDRiBkZWNhcC4gQnV0IHRoZXJlIGlzIHN0aWxsIG5v IHdheSB0aGF0LCBpbiBhIHZhbGlkIG5ldHdvcmssIHRoZXkgd291bGQgYXJyaXZlIGF0IGFueSBS RkM2MDQwIChub24tVENGKSBkZWNhcC4NCg0KT25lIG1pZ2h0IHRoaW5rIHRoYXQgdGhpcyBjb21i aW5hdGlvbiBjb3VsZCBhcnJpdmUgYXQgYSA2MDQwLWRlY2FwIGlmIHRoZXJlIHdhcyBhIHR1bm5l bCBpbnNpZGUgYSB0dW5uZWwsIGFzIGZvbGxvd3MNCg0KICBUQ0YtZW5jYXAgICAgICAgICAgICAg ICAgIC0tLT4gNjA0MC1kZWNhcCAtLS0+IFRDRi1kZWNhcA0KDQpIb3dldmVyLCB0aGF0J3Mgbm90 IGEgdmFsaWQgY29uZmlndXJhdGlvbi4gVGhlIGZvbGxvd2luZyB0dW5uZWwtaW4tdHVubmVsIHdv dWxkIGJlIHZhbGlkOg0KDQogIFRDRi1lbmNhcCAtLS0+IDYwNDAtZW5jYXAgLS0tPiA2MDQwLWRl Y2FwIC0tLT4gVENGLWRlY2FwDQoNCi4uLnRoZW4sIHRoZSBhYm92ZSB0d28gIkNVIiBjb21iaW5h dGlvbnMgd291bGQgYmUgYnVyaWVkIHdpdGhpbiBhIGRvdWJsZSBpbm5lciwgc28gb25seSB0aGUg VENGIGRlY2FwIHdvdWxkIHNlZSB0aGVtLCBub3QgdGhlIDYwNDAtZGVjYXAuDQoNClNvLCBUQ0Yg ZG9lcyBub3QgbmVlZCB0byB1cGRhdGUgUkZDNjA0MC4gQmVjYXVzZSwgaW4gYSB2YWxpZCBuZXR3 b3JrLCBUQ0Ygd2lsbCBiZSBoaWRkZW4gZnJvbSBhbnkgNjA0MC1kZWNhcC4gSWYgdGhlIG5ldHdv cmsgaXMgbm90IHZhbGlkLCB0aGVzZSBjb21iaW5hdGlvbiBjb3VsZCBiZWNvbWUgdmlzaWJsZSB0 byBhIDYwNDAtZGVjYXAsIHdoaWNoIHdvdWxkIHRoZW4gKGNvcnJlY3RseSkgbG9nIHdhcm5pbmdz IHRoYXQgaXQgd2FzIHNlZWluZyBpbnZhbGlkIGNvZGVwb2ludCBjb21iaW5hdGlvbnMuDQoNCkkg anVzdCB0aG91Z2h0IHlvdSdkIGxpa2UgdG8ga25vdy4uLiBubyBhY3Rpb24gcmVxdWlyZWQuDQoN Cg0KDQpCb2INCg0KLS0NCg0KLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQoNCg0KLS0NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8v Ym9iYnJpc2NvZS5uZXQvDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg== --_000_C5C3BB522B1DDF478AA09545169155B48B3B21E1nkgeml514mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8 jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5N c29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om5 5rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci LCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLm ibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6Ymxh Y2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6 YmxhY2s7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0dGVkLCBkaXYuSFRN TFByZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuQmFsbG9vblRleHQs IGxpLkJhbGxvb25UZXh0LCBkaXYuQmFsbG9vblRleHQNCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1h bDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNw YW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiM5OTMzNjY7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZv bnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhpIEJvYiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoYW5rcyBmb3IgeW91ciBjb21tZW50cywgYW5kIHBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1YaW5wZW5nPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBCb2IgQnJpc2NvZSBb bWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBB cHJpbCAwMywgMjAxNyA1OjM0IEFNPGJyPg0KPGI+VG86PC9iPiBXZWl4aW5wZW5nIChKYWNraWUp OyBCbGFjaywgRGF2aWQ7IGRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJh Y2tAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IHRzdndnIElFVEYgbGlzdDxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogVHVubmVsIENvbmdlc3Rpb24gRmVlZGJhY2s6IChub24tKXVwZGF0 ZSB0byBSRkM2MDQwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIj5XZWl4aW5wZW5nLCBjby1hdXRob3JzLCZuYnNwOyBhbmQgRGF2 aWQsPGJyPg0KPGJyPg0KSSBoYWQgcHJvbWlzZWQgYSByZXZpZXcgb2YgdGhlIGxhdGVzdCBUQ0Yg ZHJhZnQsIGJ1dCBmYWlsZWQgdG8gcHJvdmlkZSBpdCBzbyBmYXIuPGJyPg0KSSBoYWxmIHJlYWQg aXQgdGhyb3VnaCBvbiBGcmlkYXksIGFuZCBJIHdpbGwgZmluaXNoIGFuZCB3cml0ZSB1cCBteSBy ZXZpZXcgdGhpcyB3ZWVrLjxicj4NCjxicj4NCkhlcmUnIGEgcXVpY2sgc3VtbWFyeSBvZiB0aGUg bWFpbiBwb2ludHMgc28gZmFyOiA8YnI+DQo8YnI+DQo8Yj5TLjEuIEludHJvOiBNb3RpdmF0aW9u PGJyPg0KPC9iPlRoZSBtb3RpdmF0aW9uIHNob3VsZCBhbHNvIGluY2x1ZGUgYSBoZWF2eSBsb2Fk IGZyb20gYSBtdWNoIGxhcmdlciB0aGFuIGV4cGVjdGVkIG51bWJlciBvZiByZXNwb25zaXZlIGZs b3dzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPltXZWldIE9rLCBJIHdpbGwgYWRkIGl0Ljwvc3Bhbj48L2k+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8Yj5TLjEgSW50cm86IFNjb3BlPGJyPg0KPC9i PkkgdGhpbmsgdGhlIGRyYWZ0IHNob3VsZCBzYXkgdGhhdDxicj4NCiogaXQgZ2l2ZXMgbm8gYWR2 aWNlIG9uIGhvdyB0byBzZWxlY3Qgd2hpY2ggdHVubmVsIGVuZHBvaW50cyBzaG91bGQgYmUgdXNl ZCBpbiBvcmRlciB0byBtYW5hZ2UgdHJhZmZpYyBvdmVyIGEgbmV0d29yayBjcmlzcy1jcm9zc2Vk IGJ5IG11bHRpcGxlIHR1bm5lbHMuDQo8YnI+DQoqIGlmIGEgY29uZ2VzdGVkIG5vZGUgaXMgcGFy dCBvZiBtdWx0aXBsZSB0dW5uZWxzLCBhbmQgaXQgY2F1c2VzIGNvbmdlc3Rpb24gZmVlZGJhY2sg dG8gbXVsdGlwbGUgdHJhZmZpYyBtYW5hZ2VtZW50IGZ1bmN0aW9ucyBhdCB0aGUgaW5ncmVzc2Vz IG9mIGFsbCB0aGUgdHVubmVscywgdGhlIGRyYWZ0IGdpdmVzIG5vIGFkdmljZSBvbiBob3cgYWxs IHRoZSB0cmFmZmljIG1hbmFnZW1lbnQgZnVuY3Rpb25zIHNob3VsZCByZXNwb25kLjxicj4NCiog ZXRjLiAoaW4gbXkgZnVsbCByZXZpZXcsIEkgd2lsbCBwcm92aWRlIGEgZnVsbCBsaXN0IG9mIHN1 YmplY3RzIHRoYXQgYXJlIG91dCBvZiBzY29wZSkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48aT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltXZWldIE9rLjwvc3Bh bj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8Yj5TLjMuIEZlZWRiYWNr IE1vZGVsczogPGJyPg0KPC9iPlRoZSBhcmNoaXRlY3R1cmUgZGlhZ3JhbXMgYW5kIHRleHQgbmVl ZCB0byBpbmNsdWRlIGNvbXBvbmVudHMgdGhhdCBhcHBseSBhIGNvbnNpc3RlbnQgbWVhc3VyZW1l bnQgcG9saWN5ICh0ZW1wbGF0ZSByZWNvcmRzIGluIElQRklYLXNwZWFrKSBhdCBib3RoIGluZ3Jl c3MgYW5kIGVncmVzcy4gVGhpcyBpcyBhIGtleSBwYXJ0IG9mIGludGVyb3BlcmFiaWxpdHksIHdo aWNoIGlzIHdoYXQgdGhlIElFVEYgc2hvdWxkIGJlIGFsbCBhYm91dC4gVGVtcGxhdGUNCiByZWNv cmRzIGFyZSBkZXNjcmliZWQgbGF0ZXIgd2hlbiB0aGUgbWVjaGFuaXNtIGlzIHNwZWNpZmllZCwg YnV0IHRoZXkgYXJlIG5vdCBzaG93biBpbiB0aGUgbGF5b3V0IG9mIHRoZSBjb21wb25lbnRzIGlu IFMuMy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+W1dlaV0gSSB3aWxsIHByb3ZpZGUgYSBkZXNjcmlwdGlvbiBvZiBU ZW1wbGF0ZSByZWNvcmQgaW4gdGhpcyBzZWN0aW9uLiBCdXQgSSBhbSB3b25kZXJpbmcgd2hldGhl ciBhIGRldGFpbGVkDQogZGVzY3JpcHRpb24gb2YgVGVtcGxhdGUgUmVjb3JkIGFzIHNlY3Rpb24g Ni4xIGlzIG5lZWRlZCBoZXJlIG9yIG5vdD88bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxiPlMuNC4gQ29uZ2VzdGlvbiBMZXZlbCBNZWFzdXJl bWVudDo8YnI+DQo8L2I+TWVhc3VyZW1lbnQgb2YgRUNOIGhhcyBiZWVuIGNoYW5nZWQgd2l0aG91 dCB0aGlua2luZyBjbGVhcmx5IHdoZXRoZXIgaXQgbmVlZGVkIHRvIGNoYW5nZS48YnI+DQo8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgYSkgRWFybGllciBkcmFmdHMgZXhwbG9pdGVkIHRoZSBmYWN0 IHRoYXQgdGhlIGlubmVyIGhvbGRzIGEgJnF1b3Q7ZnJvemVuJnF1b3Q7IHJlY29yZCBvZiB0aGUg RUNOIGZpZWxkIGF0IHRoZSBpbmdyZXNzLiBTbyBFQ04gbWVhc3VyZW1lbnRzIGNvdWxkIGJlIG1h ZGUgc29sZWx5IGF0IHRoZSBlZ3Jlc3MgKGNvbXBhcmluZyB0aGUgb3V0ZXIgd2l0aCB0aGUgaW5u ZXIpLiBJbiBkcmFmdC0wNCwgRUNOIGNvZGVwb2ludHMgYXJlIG1lYXN1cmVkIGF0IHRoZSBpbmdy ZXNzDQogYW5kIGF0IHRoZSBlZ3Jlc3MsIHdpdGggdGhlIGluZ3Jlc3Mgc2VuZGluZyByZWd1bGFy IG1lYXN1cmVtZW50IHJlcG9ydHMgdG8gdGhlIGVncmVzcyBmb3IgY29tcGFyaXNvbi4gSG93ZXZl ciwgaXQgaXMgYWx3YXlzIHNhZmVyIHRvIG1lYXN1cmUgRUNOIHNvbGVseSBhdCB0aGUgZWdyZXNz LCBldmVuIHRob3VnaCBhIGRpZmZlcmVudCBtZWNoYW5pc20gaGFzIHRvIG1lYXN1cmUgZHJvcHMg d2l0aGluIHRoZSB0dW5uZWwgKGR1ZSB0byBub24tRUNODQogbm9kZXMsIG9yIG5vZGVzIHRoYXQg aGF2ZSBzd2l0Y2hlZCBvZmYgRUNOIGR1ZSB0byBvdmVybG9hZCwgb3IgZHVlIHRvIGNhdXNlcyBv ZiBsb3NzIG90aGVyIHRoYW4gY29uZ2VzdGlvbiwgZS5nLiB0cmFuc21pc3Npb24gZXJyb3JzKS4N Cjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIEl0IGlzIGFsd2F5cyBzYWZlciB0byBz b2xlbHkgbWVhc3VyZSBFQ04gYXQgdGhlIGVncmVzcywgYmVjYXVzZSBpdCBpcyBub3QgdnVsbmVy YWJsZSB0byBpbmdyZXNzLWVncmVzcyBtZWFzdXJlbWVudCBwYWNrZXRzIGJlaW5nIGRyb3BwZWQu PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gU29sZWx5IG1lYXN1cmluZyBFQ04gYXQg ZWdyZXNzIGlzIG5vIGxlc3MgcHJlY2lzZSwgYmVjYXVzZSBvbmx5IHRoZSBwcm9wb3J0aW9uIG9m IHRoZSBkaWZmZXJlbnQgRUNOIGZpZWxkcyBpcyBuZWVkZWQsIGFuZCB0aGF0IHN0YXlzIGFwcHJv eGltYXRlbHkgdGhlIHNhbWUgZXZlbiBpZiB0aGVyZSBpcyBkcm9wLCBhc3N1bWluZyBkcm9wIGlz IG5vdCBiaWFzZWQgdG93YXJkcyBjZXJ0YWluIEVDTiBjb2RlcG9pbnRzIChubyBrbm93biBtZWNo YW5pc20NCiBkb2VzIHRoYXQpLiA8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgYikgSW4g ZHJhZnQtMDQgdGhlIGZha2VkIEVDVCBhcHByb2FjaCBoYXMgYmVlbiBsZWZ0IHVuY2hhbmdlZCBh dCB0aGUgaW5ncmVzcywgYnV0IGl0IGlzIG5vIGxvbmdlciB1c2VkIGF0IHRoZSBlZ3Jlc3MgZm9y IGRldGVjdGluZyBkZWZlcnJlZCBkcm9wcyAoYnkgbG9va2luZyBmb3IgYSBOb3QtRUNOIGlubmVy IGFuZCBhIENFIG91dGVyKS4gQWdhaW4sIHRoZXJlIGlzIG5vdGhpbmcgd3Jvbmcgd2l0aCBtZWFz dXJpbmcgRUNOIGFuZCBkZXRlY3RpbmcNCiBkZWZlcnJlZCBkcm9wcyBzb2xlbHkgYXQgdGhlIGVn cmVzcywgZXZlbiBpZiB0aGVyZSBhcmUgZHJvcHMgd2l0aGluIHRoZSB0dW5uZWwuIFRvIG1lYXN1 cmUgZHJvcHMgd2l0aGluIHRoZSB0dW5uZWwsIGl0IGlzIG5lY2Vzc2FyeSB0byBjb21wYXJlIGlu Z3Jlc3MgYW5kIGVncmVzcyBieXRlcywgYnV0IHRoYXQgZG9lcyBub3QgbWFrZSBpdCB3cm9uZyB0 byBzdGlsbCBtZWFzdXJlIGFuZCBjb21wYXJlIEVDTiBzb2xlbHkgYXQgdGhlIGVncmVzcy48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W1dlaV0gSSBhZ3JlZSB0aGF0IHNvbGVseSBtZWFzdXJpbmcgRUNOIGF0IGVncmVz cyBpcyBlbm91Z2ggdG8gZ2V0IHRoZSBwcm9wb3J0aW9uIG9mIGRpZmZlcmVudCBFQ04gZmllbGRz LCBidXQNCiB0aGUgcmVhc29uIHdoeSBFQ04gY29kZXBvaW50cyBhcmUgbWVhc3VyZWQgYm90aCBh dCBpbmdyZXNzIGFuZCBlZ3Jlc3MgaXMgdG8gbWVhc3VyZSB0aGUgcGFja2V0cyBkcm9wcGVkIHdp dGhpbiB0aGUgdHVubmVsIGJ5IGNvbXBhcmluZyBjb3VudHMgYXQgaW5ncmVzcyBhbmQgZWdyZXNz Lg0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+ DQo8Yj5TLjQuIENvbmdlc3Rpb24gTGV2ZWwgTWVhc3VyZW1lbnQ6IFVuaXRzPGJyPg0KPC9iPlRo cm91Z2hvdXQgbWVhc3VyZW1lbnQgaW52b2x2ZXMgY291bnRpbmcgcGFja2V0cy4gSG93ZXZlciwg aXQgc2hvdWxkIGNvdW50IHRoZSBieXRlcyBpbiBwYWNrZXRzIHdpdGggZWFjaCB0eXBlIG9mIG1h cmtpbmcsIG5vdCBqdXN0IHRoZSBudW1iZXIgb2YgcGFja2V0cy4gU2VlDQo8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzE0MSNzZWN0aW9uLTIuMyI+UkZDNzE0MSBzZWN0 aW9uIDIuMzwvYT4uIEFsdGhvdWdoIHRoZSByZWNvbW1lbmRhdGlvbiBpbiB0aGF0IFJGQyBpcyBh Ym91dCB3aGF0IGEgL3RyYW5zcG9ydC8gc2hvdWxkIG1lYXN1cmUgd2hlbiByZXNwb25kaW5nIHRv IGNvbmdlc3Rpb24sIGxvZ2ljYWxseSBpdCBzaG91bGQgYXBwbHkgaW4gdGhpcyBjYXNlIHdoZW4g YSB0cmFmZmljIG1hbmFnZW1lbnQNCiBmdW5jdGlvbiBpcyByZXNwb25kaW5nIGluIHBsYWNlIG9m IGEgdHJhbnNwb3J0LiBSRkM3MTQxIGFsc28gZ2l2ZXMgcmVjb21tZW5kYXRpb25zIG9uIHdoaWNo IGhlYWRlcnMgdG8gY291bnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltXZWldIE9rLCBpdOKAmXMgYSBnb29kIHN1 Z2dlc3Rpb24uPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQo8YnI+DQo8YnI+DQpJIHNoYWxsIGFkZCB0byB0aGlzIHJldmlldyBsYXRlciBpbiB0aGUgd2Vl ay48YnI+DQo8YnI+DQpPbmUgcXVlc3Rpb24gZm9yIFdlaXhpbnBlbmc6IEhhdmUgeW91IGltcGxl bWVudGVkIHRoaXMgbWVjaGFuaXNtPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bV2VpXSBDdXJyZW50bHksIHdlIG9u bHkgaW1wbGVtZW50IHRoaXMgbWVjaGFuaXNtIGluIGEgc2ltdWxhdGlvbiBlbnZpcm9ubWVudC48 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxi cj4NCkJvYjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gMDEvMTEvMTYgMDE6NDksIFdlaXhp bnBlbmcgKEphY2tpZSkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGkgQm9iIGFuZCBEYXZpZCw8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVjYXVzZSB0 aGUgZGVhZGxpbmUgaGFzIHBhc3NlZCwgSSB3aWxsIHVwZGF0ZSBpdCBhcyBwYXJ0IG9mIHBvc3Qt V0dMQyB1cGRhdGUuIFRoYW5rcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPi1YaW5wZW5nIChKYWNraWUpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gQmxhY2ssIERhdmlkIFs8YSBocmVmPSJt YWlsdG86RGF2aWQuQmxhY2tAZGVsbC5jb20iPm1haWx0bzpEYXZpZC5CbGFja0BkZWxsLmNvbTwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIgMDEsIDIwMTYgMTI6MTQg QU08YnI+DQo8Yj5Ubzo8L2I+IEJvYiBCcmlzY29lOyBXZWl4aW5wZW5nIChKYWNraWUpOyA8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0 b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRi YWNrQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gdHN2d2cgSUVURiBsaXN0OyBC bGFjaywgRGF2aWQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFR1bm5lbCBDb25nZXN0aW9uIEZl ZWRiYWNrOiAobm9uLSl1cGRhdGUgdG8gUkZDNjA0MDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM5OTMzNjYiPiZndDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+SSBhc3N1bWUg eW91IHdpbGwgdXBkYXRlIHRoZSBUQ0YgZHJhZnQgdG9kYXkgYmVmb3JlIHRoZSBkZWFkbGluZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTkzMzY2Ij4o QXMgZHJhZnQgc2hlcGhlcmQpIFRoYXTigJlzIG5vdCByZWFsbHkgbmVjZXNzYXJ5IC0gdGhlIFRD RiBkcmFmdCBpcyBpbiBXR0xDLCBzbyB0aGlzIGNoYW5nZSBjYW4gYmUgZG9uZSBhcyBwYXJ0IG9m IGEgcG9zdC1XR0xDIHVwZGF0ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk5MzM2NiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTkzMzY2 Ij5UaGFua3MsIC0tRGF2aWQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTkzMzY2Ij4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRv d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlzY29lIFs8YSBocmVmPSJtYWlsdG86aWV0 ZkBib2JicmlzY29lLm5ldCI+bWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQ8L2E+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAzMSwgMjAxNiAxMToyMiBBTTxicj4NCjxiPlRv OjwvYj4gV2VpeGlucGVuZyAoSmFja2llKTsgQmxhY2ssIERhdmlkOyA8YSBocmVmPSJtYWlsdG86 ZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9y ZyI+DQpkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmll dGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gdHN2d2cgSUVURiBsaXN0PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBUdW5uZWwgQ29uZ2VzdGlvbiBGZWVkYmFjazogKG5vbi0pdXBkYXRlIHRvIFJG QzYwNDA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+WGlucGVuZyw8YnI+DQo8YnI+ DQpJIGFncmVlIHRoYXQgVENGIGRvZXMgbm90IHVwZGF0ZSBSRkM2MDQwIChhcyBJIHNhaWQpLjxi cj4NCjxicj4NCkJ1dCBEYXZpZCBpcyByaWdodCB0aGF0IHRoZSBUQ0YgZHJhZnQgaXRzZWxmIG5l ZWRzIHRvIGJlIHVwZGF0ZWQgdG8gc2F5IHRoYXQgaXQgbW9kaWZpZXMgdGhlIGJlaGF2aW91ciBv ZiBhIFJGQzYwNDAgZWdyZXNzIHNvIGFzIHRvIGlzc3VlIG9yIGxvZyBhbnkgd2FybmluZ3Mgd2hl biBpdCByZWNlaXZlcyBhbiBFQ1QoMCkgb3IgQ0Ugb3V0ZXIgd2l0aCBhIE5vdC1FQ1QgaW5uZXIu PGJyPg0KPGJyPg0KSSBhc3N1bWUgeW91IHdpbGwgdXBkYXRlIHRoZSBUQ0YgZHJhZnQgdG9kYXkg YmVmb3JlIHRoZSBkZWFkbGluZS48YnI+DQo8YnI+DQpDaGVlcnM8YnI+DQo8YnI+DQpCb2I8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPk9uIDMxLzEwLzE2IDAyOjM4LCBXZWl4aW5wZW5nIChKYWNraWUpIHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIERh dmlkLCBCb2IsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCB0aGUgYmVoYXZpb3IgZGVmaW5lZCBp biBSRkM2MDQwIGRvZXNu4oCZdCB0byBiZSB1cGRhdGVkIGR1ZSB0byB0aGUgVENGIGRyYWZ0LCBi ZWNhdXNlIHdoYXTigJlzIGRlZmluZWQgaW4gUkZDIDYwNDAgaGFzIGEgYnJvYWRlciB1c2FnZQ0K IGFuZCBub3QganVzdCBmb3IgVENGLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIERhdmlkIGhhcyBwcm92 aWRlZCBhIGdvb2Qgc3VnZ2VzdGlvbiBiZWxvdy4gVGhhbmtzLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVhpbnBlbmcgKEphY2tpZSk8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiB0c3Z3ZyBb PGEgaHJlZj0ibWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzp0c3Z3Zy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmxhY2ssIERhdmlkPGJyPg0K PGI+U2VudDo8L2I+IFNhdHVyZGF5LCBPY3RvYmVyIDI5LCAyMDE2IDEwOjI4IEFNPGJyPg0KPGI+ VG86PC9iPiBCb2IgQnJpc2NvZTsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdHN2d2ctdHVu bmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi10c3Z3 Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5D Yzo8L2I+IHRzdndnIElFVEYgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RzdndnXSBU dW5uZWwgQ29uZ2VzdGlvbiBGZWVkYmFjazogKG5vbi0pdXBkYXRlIHRvIFJGQzYwNDA8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Cb2IsPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JIHRoaW5rIHlvdeKAmXZlIGZvdW5kIHNvbWV0aGluZy4mbmJzcDsgVGhl IFRDRiBkcmFmdCBjdXJyZW50bHkgdXNlcyBSRkMgNjA0MCBiZWhhdmlvciBieSByZWZlcmVuY2U6 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgd2hlbiBkZWNhcHN1bGF0aW5nIHBhY2tldHMg YXQgZWdyZXNzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgUkZDNjA0MCBkZWZpbmVkIGRlY2Fwc3VsYXRpb24gYmVoYXZp b3IgaXMgdXNlZCwgYW5kIGFjY29yZGluZyB0bzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgUkZDNjA0MCwgdGhlIHBhY2tl dHMgbWFya2VkIGFzIENFfE4tRUNUIHdpbGwgYmUgZHJvcHBlZCBieSBlZ3Jlc3MuDQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUg c2xpZ2h0bHkgcmV2aXNlZCB0byBzYXkgdGhhdCBDRXxOLUVDVCBpcyBkcm9wcGVkIHdpdGhvdXQg YW55IG90aGVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFjdGlvbiwgYW5kIGFsbCBvdGhlciBiZWhhdmlvciBpcyBh cyBwZXIgUkZDIDYwNDAsIGFzIENFfE4tRUNUIGlzIGV4cGVjdGVkIGF0IGEgVENGIGVncmVzcyBh bmQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+aGVuY2UgdGhlIGxvZ2dpbmcgYW5kIGFsYXJtIGJlaGF2aW9yIGZvciB0 aGF0IGNvbWJpbmF0aW9uIGluIFJGQyA2MDQwIGlzIGluYXBwcm9wcmlhdGUuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5PbmNlIHRoYXTigJlzIGRvbmUsIEkgdGhpbmsgeW91ciByZWFz b25pbmcgaW4gdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBiZWNvbWVzIGNvcnJlY3Q6PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoZSBuZXR3b3JrIGlzIG5v dCB2YWxpZCwgdGhlc2UgY29tYmluYXRpb24gY291bGQgYmVjb21lIHZpc2libGUgdG8gYSA2MDQw LWRlY2FwLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj53aGljaCB3b3VsZCB0aGVuIChjb3JyZWN0bHkpIGxvZyB3YXJuaW5ncyB0 aGF0IGl0IHdhcyBzZWVpbmcgaW52YWxpZCBjb2RlcG9pbnQgY29tYmluYXRpb25zLjxicj4NCjxi cj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoYW5rcywgLS1EYXZpZCAoYXMgZHJhZnQgc2hlcGhlcmQpPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBCb2Ig QnJpc2NvZSBbPGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiPm1haWx0bzppZXRm QGJvYmJyaXNjb2UubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgT2N0b2Jl ciAyNywgMjAxNiA0OjM5IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQt aWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9yZyI+DQpk cmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3Jn PC9hPjsgQmxhY2ssIERhdmlkPGJyPg0KPGI+Q2M6PC9iPiB0c3Z3ZyBJRVRGIGxpc3Q8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gVHVubmVsIENvbmdlc3Rpb24gRmVlZGJhY2s6IChub24tKXVwZGF0ZSB0 byBSRkM2MDQwPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5UdW5uZWwgY29uZ2VzdGlvbiBmZWVkYmFjayBhdXRob3JzLCBEYXZpZCBh cyBzaGVwaGVyZCw8YnI+DQo8YnI+DQpGWUkuIE5vIGFjdGlvbiBuZWVkZWQuPGJyPg0KPGJyPg0K VGhpcyBlbWFpbCBkb2N1bWVudHMgYW4gYXJndW1lbnQgd2l0aCBteXNlbGYuIEFmdGVyIGEgZmV3 IHNlY29uZHMsIEkgYWdyZWVkIHdpdGggbXlzZWxmIHRoYXQgb25lIG9mIG1lIHdhcyB3cm9uZy4g SSB0aG91Z2h0IEkgaGFkIGJldHRlciByYWlzZSB0aGlzIG9uIHRoZSBsaXN0LCB0byBjaGVjayB0 aGF0IG90aGVycyBhZ3JlZSB3aXRoIGJvdGggb2YgbWUuIElmIHlvdSB3aXNoIHRvIGFyZ3VlIHdp dGgganVzdCBvbmUgb2YgbWUsIHBsZWFzZSBiZWFyDQogaW4gbWluZCB0aGF0IHdlIGJvdGggaGF2 ZSB0aGUgc2FtZSBlbWFpbCBhZGRyZXNzIChhbmQgYW55d2F5LCB3ZSBib3RoIGFncmVlIHNvIGFu IGFyZ3VtZW50IHdpdGggb25lIGlzIGFuIGFyZ3VtZW50IHdpdGggYWxsKS48YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KRmlndXJlIDQgb2YgUkZDNjA0MCBzcGVjaWZp ZXMgd2hpY2ggRUNOIGNvZGVwb2ludCBhIGRlY2FwIG11c3QgZm9yd2FyZCwgZm9yIGVhY2ggY29t YmluYXRpb24gb2YgYXJyaXZpbmcgaW5uZXIgKHJvdykgYW5kIG91dGVyIChjb2x1bW4pLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfEFycml2aW5nIHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXJyaXZpbmcg T3V0ZXIgSGVhZGVyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IElubmVyICYj NDM7LS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0t LS0tLS0tJiM0Mzs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7IEhlYWRlciB8IE5vdC1FQ1QgfCBFQ1QoMCkmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCBFQ1QoMSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBDRSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0mIzQzOy0tLS0tLS0t LSYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBOb3Qt RUNUIHwgTm90LUVDVCB8Tm90LUVDVCghISEpfE5vdC1FQ1QoISEhKXwgJmx0O2Ryb3AmZ3Q7KCEh ISl8PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyBFQ1QoMCkgfCZuYnNwOyBFQ1QoMCkgfCBFQ1QoMCkmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCBFQ1QoMSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBDRSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBFQ1QoMSkgfCZuYnNwOyBFQ1QoMSkg fCBFQ1QoMSkgKCEpIHwgRUNUKDEpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQ0UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsg Q0UmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDRSB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IENFJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQ0UoISEhKXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0UmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0MzstLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0t LSYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+UkZDNjA0MCBnb2VzIG9uIHRvIHNheTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFsuLi5dIFRoZXNlIGN1cnJlbnRseSB1bnVzZWQgKENVKSBjb21iaW5hdGlvbnMg YXJlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgaW5kaWNhdGVkIGluIEZpZ3VyZSA0IGJ5ICcoISEhKScgb3IgJygh KScsIHdoZXJlICcoISEhKScgbWVhbnMgdGhlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Y29tYmluYXRpb24gaXMg Q1UgYW5kIGFsd2F5cyBwb3RlbnRpYWxseSBkYW5nZXJvdXMsIHdoaWxlICcoISknPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgbWVhbnMgaXQgaXMgQ1UgYW5kIHBvc3NpYmx5IGRhbmdlcm91cy4mbmJzcDsgSW4gdGhl c2UgY2FzZXMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFydGljdWxhcmx5IHRoZSBtb3JlIGRhbmdlcm91cyBv bmVzLCB0aGUgZGVjYXBzdWxhdG9yIFNIT1VMRCBsb2c8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgZXZlbnQg YW5kIE1BWSBhbHNvIHJhaXNlIGFuIGFsYXJtLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRDRiB1c2VzIHRoZSBmb2xsb3dpbmcgY29tYmluYXRp b25zIG9mIGlubmVyIDogb3V0ZXINCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBOb3QtRUNUIDog RUNUKDApPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IE5vdC1FQ1QgOiBDRTxicj4NCjxicj4NCkZv ciBhIG1vbWVudCwgSSB0aG91Z2h0IHdlIHdvdWxkIGhhdmUgdG8gdXBkYXRlIFJGQzYwNDAgdG8g c2F5IHRoYXQgVENGIG1ha2VzIHRoZXNlIGNvbWJpbmF0aW9ucyBubyBsb25nZXIgQ1UsIHNvIHRo ZXkgYXJlIG5vdyB2YWxpZCwgbm90IGRhbmdlcm91cywgYW5kIHRoZXkgbm8gbG9uZ2VyIG5lZWQg dG8gYmUgbG9nZ2VkLiBUaGlzIHdvdWxkIGhhdmUgbWVhbnQgdGhhdCBUdW5uZWwgQ29uZ2VzdGlv biBGZWVkYmFjayAoVENGKSAoaW5mb3JtYXRpb25hbCkNCiB3b3VsZCBoYXZlIHRvIHVwZGF0ZSBS RkM2MDQwIChwcm9wb3NlZCBzdGFuZGFyZCkuPGJyPg0KPGJyPg0KSGVyZSdzIHdoeSBJIHdhcyB3 cm9uZy4gVGhlc2UgdHdvIGNvbWJpbmF0aW9ucyBhcmUgY2VydGFpbmx5IHZhbGlkIGF0IGEgVENG IGRlY2FwLiBCdXQgdGhlcmUgaXMgc3RpbGwgbm8gd2F5IHRoYXQsIGluIGEgdmFsaWQgbmV0d29y aywgdGhleSB3b3VsZCBhcnJpdmUgYXQgYW55IFJGQzYwNDAgKG5vbi1UQ0YpIGRlY2FwLjxicj4N Cjxicj4NCk9uZSBtaWdodCB0aGluayB0aGF0IHRoaXMgY29tYmluYXRpb24gY291bGQgYXJyaXZl IGF0IGEgNjA0MC1kZWNhcCBpZiB0aGVyZSB3YXMgYSB0dW5uZWwgaW5zaWRlIGEgdHVubmVsLCBh cyBmb2xsb3dzPGJyPg0KPGJyPg0KPC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyBUQ0YtZW5jYXAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0tJmd0OyA2MDQwLWRlY2FwIC0tLSZndDsgVENGLWRlY2FwPC9z cGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCkhvd2V2ZXIsIHRoYXQncyBub3QgYSB2YWxp ZCBjb25maWd1cmF0aW9uLiBUaGUgZm9sbG93aW5nIHR1bm5lbC1pbi10dW5uZWwgd291bGQgYmUg dmFsaWQ6PGJyPg0KPGJyPg0KPC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZuYnNwOyBUQ0YtZW5jYXAgLS0tJmd0OyA2MDQwLWVuY2FwIC0tLSZn dDsgNjA0MC1kZWNhcCAtLS0mZ3Q7IFRDRi1kZWNhcDwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48YnI+DQouLi50aGVuLCB0aGUgYWJvdmUgdHdvICZxdW90O0NVJnF1b3Q7IGNvbWJpbmF0aW9u cyB3b3VsZCBiZSBidXJpZWQgd2l0aGluIGEgZG91YmxlIGlubmVyLCBzbyBvbmx5IHRoZSBUQ0Yg ZGVjYXAgd291bGQgc2VlIHRoZW0sIG5vdCB0aGUgNjA0MC1kZWNhcC48YnI+DQo8YnI+DQpTbywg VENGIGRvZXMgbm90IG5lZWQgdG8gdXBkYXRlIFJGQzYwNDAuIEJlY2F1c2UsIGluIGEgdmFsaWQg bmV0d29yaywgVENGIHdpbGwgYmUgaGlkZGVuIGZyb20gYW55IDYwNDAtZGVjYXAuIElmIHRoZSBu ZXR3b3JrIGlzIG5vdCB2YWxpZCwgdGhlc2UgY29tYmluYXRpb24gY291bGQgYmVjb21lIHZpc2li bGUgdG8gYSA2MDQwLWRlY2FwLCB3aGljaCB3b3VsZCB0aGVuIChjb3JyZWN0bHkpIGxvZyB3YXJu aW5ncyB0aGF0IGl0IHdhcyBzZWVpbmcgaW52YWxpZA0KIGNvZGVwb2ludCBjb21iaW5hdGlvbnMu PGJyPg0KPGJyPg0KSSBqdXN0IHRob3VnaHQgeW91J2QgbGlrZSB0byBrbm93Li4uIG5vIGFjdGlv biByZXF1aXJlZC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpCb2I8YnI+DQo8YnI+DQotLSA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+LS0gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Cb2IgQnJpc2NvZSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2Nv ZS5uZXQvPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPi0tIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Qm9iIEJyaXNjb2Um bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2JvYmJyaXNjb2UubmV0LyI+aHR0cDovL2JvYmJyaXNj b2UubmV0LzwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkJvYiBCcmlzY29l Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2Jicmlz Y29lLm5ldC88L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_C5C3BB522B1DDF478AA09545169155B48B3B21E1nkgeml514mbschi_-- From nobody Wed Apr 5 10:32:48 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBA212704B for ; Wed, 5 Apr 2017 10:32:46 -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 hdvaZ60vRsc1 for ; Wed, 5 Apr 2017 10:32:44 -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 948AD12945B for ; Wed, 5 Apr 2017 10:32:37 -0700 (PDT) Received: from [128.9.184.101] ([128.9.184.101]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v35HVmJp029228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Apr 2017 10:31:48 -0700 (PDT) To: "Weixinpeng (Jackie)" , tsvwg References: <77bbceb7-d905-d4b0-a250-41450ee56645@isi.edu> Cc: Mark Townsley From: Joe Touch Message-ID: Date: Wed, 5 Apr 2017 10:31:48 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v35HVmJp029228 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] question about layered congestion issue - draft-ietf-tsvwg-tunnel-congestion-feedback X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 17:32:46 -0000 Hi, Xinpeng, On 4/4/2017 7:16 PM, Weixinpeng (Jackie) wrote: > ... > [Wei] The section 6 of the document has provided some description on how the mechanism discussion should coexistence with e2e congestion control. > Let me know if it doesn't address your concerns. Thanks. It does not. Merely asserting that having a control loop that is larger than your assumption about global RTT is insufficient for many reasons: - many systems experience RTTs that are much larger - in the 250ms-2s ranges, either because they use satellite connections, typical network queuing, or bufferbloat - simply using a larger RTT does not avoid having the two systems fight each other You have no analysis, no measurements, no experiments, and no related work cited. The entirety of this approach is based on the assumption that using this mechanism is both safe and helpful. You need to *demonstrate* that this is possible and integrate constraints to ensure so, not merely claim that it's up to the implementer to ensure that this has been accomplished. Joe From nobody Wed Apr 5 18:41:56 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4D4126B6E for ; Wed, 5 Apr 2017 18:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4pZovdTgmMJ for ; Wed, 5 Apr 2017 18:41:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5758124BE8 for ; Wed, 5 Apr 2017 18:41:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKJ47348; Thu, 06 Apr 2017 01:41:49 +0000 (GMT) Received: from DGGEMA406-HUB.china.huawei.com (10.3.20.47) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Apr 2017 02:41:48 +0100 Received: from DGGEMA501-MBX.china.huawei.com ([169.254.1.85]) by DGGEMA406-HUB.china.huawei.com ([10.3.20.47]) with mapi id 14.03.0301.000; Thu, 6 Apr 2017 09:41:45 +0800 From: "Gengxuesong (Geng Xuesong)" To: Bob Briscoe , Ingemar Johansson S , tsvwg IETF list Thread-Topic: [tsvwg] transport protocol feedback overhead Thread-Index: AQHSqZLE7ApBcd6XQUiJZ0pUEcVZ+aG3mmaQ Date: Thu, 6 Apr 2017 01:41:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58E59CDE.0001, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.85, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4eeb8088ecf3d418deabdd8b1d3ba88a Archived-At: Subject: Re: [tsvwg] transport protocol feedback overhead X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 01:41:55 -0000 SGkgQm9iLA0KDQoNCkkgdGhpbmsgaXQgaXMgYW4gaW50ZXJlc3RpbmcgaWRlYSB0byBzb2x2ZSB0 aGUgcHJvYmxlbSwgYnV0IEkgd29uZGVyIHRoYXQgd2hldGhlciBkb2luZyB0aGlzIHdpbGwgY2F1 c2Ugb3RoZXIgcHJvYmxlbSwgYmVjYXVzZSB0aGUgQUNLIGNhcnJpZXMgbW9yZSBpbmZvcm1hdGlv biB0aGFuIGFycml2YWwgdGltZS4NCkZvciBleGFtcGxlIGlmIGFuIEFDSyB3aXRoIGNvbmdlc3Rp b24gaW5mb3JtYXRpb24gYXJyaXZlcyBsYXRlciB0aGFuIGJlZm9yZSwgdGhlbiB0aGUgY29uZ2Vz dGlvbiByZXNwb25zZSB3aWxsIGJlIGRlbGF5ZWQgZWl0aGVyLCB3aGljaCBtYXkgZG8gaGFybSB0 byB0aGUgY29uZ2VzdGVkIG5ldHdvcmsuDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpYdWVzb25nDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCb2IgQnJpc2NvZQ0KU2VudDogRnJpZGF5LCBN YXJjaCAzMSwgMjAxNyA0OjE4IEFNDQpUbzogSW5nZW1hciBKb2hhbnNzb24gUzsgdHN2d2cgSUVU RiBsaXN0DQpTdWJqZWN0OiBbdHN2d2ddIHRyYW5zcG9ydCBwcm90b2NvbCBmZWVkYmFjayBvdmVy aGVhZA0KDQpJbmdlbWFyLCBsaXN0LA0KDQpJIHNlZW1lZCB0byBnZXQgYmxvY2tlZCBmcm9tIHRh bGtpbmcgYWZ0ZXIgSSB3YXMgdHJ5aW5nIHRvIGJlIHBvbGl0ZSAtIGxldHRpbmcgeW91IGZpbmlz aCB5b3VyIHRhbGsuLi4NCg0KWW91IGRlc2NyaWJlZCBvbmUgcHJvYmxlbToNCiAgKEEpIEluIG1v YmlsZSAoYW5kIG90aGVyIG5ldHdvcmtzKSAgdXBzdHJlYW0gQUNLIGxvYWQgaXMgYSBwcm9ibGVt Lg0KDQpUaGVyZSBpcyBhIGNvbXBsZW1lbnRhcnkgcHJvYmxlbSB0b286DQooQikgQ2FwYWNpdHkg dmFyaWF0aW9uIGlzIGdldHRpbmcgaHVnZSBhcyByYWRpbyB3YXZlbGVuZ3RoIGluY3JlYXNlcy4g U28gaXQncyB1c2VmdWwgZm9yIHRoZSBzZW5kZXIgdG8gd2F0Y2ggdGhlIHRpbWluZyBvZiB0aGUg QUNLcyB0byBiZSBhYmxlIHRvIHRyYWNrIGNoYW5nZXMgaW4gY2FwYWNpdHkgYXMgZmFzdCBhcyBw b3NzaWJsZS4gSXQncyBhbHNvIHVzZWZ1bCB0byBiZSBhYmxlIHRvIHZhcnkgdGhlIHNwYWNpbmcg YmV0d2VlbiB0aGUgcGFja2V0cyB5b3Ugc2VuZCB0byBwcm9iZSBmb3IgaW5jcmVhc2VzIGluIGNh cGFjaXR5IGJ5IHdhdGNoaW5nIHRoZSBBQ0sgc3BhY2luZyBpbiByZXNwb25zZS4NCg0KVGhlc2Ug dHdvIGFyZSBpbiB0ZW5zaW9uIC0gKEEpIHdhbnRzIGxlc3MgQUNLcywgKEIpIHdhbnRzIHRoZW0g YWxsLg0KDQpBIHBvc3NpYmxlIHNvbHV0aW9uLCBpcyBhIGRhdGEgc3RydWN0dXJlIGluIGEgc3Ry ZXRjaCBBQ0sgdG8gYmUgYWJsZSB0byByZXBvcnQgdGhlIHRpbWUgb2YgYXJyaXZhbCBvZiBhbGwg dGhlIHByZXZpb3VzIGRhdGEgcGFja2V0cyAoaWUuIHRoZSBwYWNrZXRzIHRoYXQgdGhlIHN0cmV0 Y2ggQUNLIGlzIEFDS2luZy4NCg0KRXZlbiB0aG8gdGhpcyBpbmZvIHdpbGwgYXJyaXZlIGF0IHRo ZSBzZW5kZXIgbGF0ZXIgdGhhbiBpdCB3b3VsZCBoYXZlIGRvbmUgaWYgdGhlIEFDS3MgaGFkIG5v dCBiZWVuIHN1cHByZXNzZWQsIGFzIGxvbmcgYXMgeW91IGFyZSBzdGlsbCBnZXR0aW5nIGEgcmVh c29uYWJsZSBudW1iZXIgb2YgQUNLcyBldmVyeSBSVFQsIGl0IHJlc29sdmVzIHRoZSB0ZW5zaW9u IGJldHdlZW4gQSBhbmQgQi4NCg0KVGhvdWdodHM/DQpEb2VzIHRoaXMgaWRlYSBhbHJlYWR5IGV4 aXN0Pw0KDQoNCg0KQm9iDQoNClBTLiBBcG9sb2dpZXMgZm9yIGRyb3BwaW5nIGFuIGlubm92YXRp dmUgaWRlYSBpbnRvIGEgc3RhbmRhcmRzIG1lZXRpbmcuIA0KVGhpcyBwcm9iYWJseSBvdWdodCB0 byBiZSBhIHJlc2VhcmNoIHBhcGVyIGZpcnN0Lg0KDQoNCi0tDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpCb2IgQnJpc2Nv ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQoN Cg== From nobody Thu Apr 6 17:45:46 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D68212965A for ; Thu, 6 Apr 2017 17:45:45 -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=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 a2hL9lTy5G5m for ; Thu, 6 Apr 2017 17:45:42 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB8612932A for ; Thu, 6 Apr 2017 17:45:42 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id 21so50410800pgg.1 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=RoiiPKeWCEXcUaZ9avFd8M/bc0L/QTz5Drl7U0QyaM0eZfh44Bgzj9oVB3GvQpRcyp EI/W6zB+dFCIVMfeHJTcEH0yv5xl6NFYvS7VviWxqFWDCPyoYNzh4wVCLwPHdhlTf3pS 9KvVKwN0GNWLycRItVsHY5pBU6uH3LRyjlRKM70Fid6M+uWRrBbS7sCZ7HYBdVLDu2yP TkOuk/llXjpeYikoRNFZu3gochUBOWD5Otd+H+kKiAO65bSjTjcGe/IATnjl8hyp0quC OwE/A2IHTWRr4zUBpOwIkAxWKJMXTFwKT0EA9GoBZDLdK6ljZDsQLyOU3SefYywBYeh0 WzcQ== X-Gm-Message-State: AFeK/H0H1sMk/wsKG/mmYUetvLnups1JYdwd4REyibm9k4WazPSl02p7Nm/3MyHGkNLbD4xp1DTRrSmg6mXLWLmx 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: [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 00:45:45 -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:39 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@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: [tsvwg] TCP ACK-CC (re: Transport protocol feedback overhead ) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area 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 Thu Apr 6 23:50:47 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B6A1201F2 for ; Thu, 6 Apr 2017 23:50:44 -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, 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 RopCaE8OjGUO for ; Thu, 6 Apr 2017 23:50:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 A32A31252BA for ; Thu, 6 Apr 2017 23:50:39 -0700 (PDT) X-AuditID: c1b4fb30-ea83298000006667-20-58e736bd4da3 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 5A.2D.26215.DB637E85; Fri, 7 Apr 2017 08:50:37 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 7 Apr 2017 08:50:35 +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=W/BXVjTSxf7/Z6jaQwIMpmlFfgukY0JrUKUsBA2ANRU=; b=G8baUP7XX7rLgQ541cBSIFcP7VYuz6BNDyqoOdoK8hST151UKigYXuNxeOxlEbGTLalCNDHjrJv+8K27AXU/Alss6R9Y8aXIG3k7NgNcYF2NRAoGRCUtUOPtfuyUJ33AfvLxgTfghJ1lpf9/gpKXP7SG18EZ1ujVwKlqdFdRx6E= 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.1034.5; Fri, 7 Apr 2017 06:50:34 +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:50:34 +0000 From: Ingemar Johansson S To: "Gengxuesong (Geng Xuesong)" , Bob Briscoe , tsvwg IETF list Thread-Topic: [tsvwg] transport protocol feedback overhead Thread-Index: AQHSqZLOdmB+LdBFN0Wl5nbQvPjKQ6G3mr+AgAHnFIA= Date: Fri, 7 Apr 2017 06:50:34 +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: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.82] x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:GAwNIa0ExtM4e4gPBlIqcmujxCcUPV9dQRjkjm+hPD7tUd7pnsUDCAA2NKXm7lDKWTVgItz57KpaWpBmNpHAoM5l+OpNHS0SSGUDyGRDYc+1ql4IxjD2Ur0KonlGqTnJVoLG5hduKzhgaFPxOd2LIcdApMOLtPNAIGipPgghw+84EABFnSKYAMJs44ljFcqb8LUvEWW9FILx8qJKx7RvsWBYvL8PGpoDYcQRHc1c7gMvXsXXLA4OeCSguYaeHdIJA3+MlrSB8IOpQnz90WgAg7V6FMotrbCg+0NeRg6afBF06NXN1LU4BVcoYaL9zdtTwfowcinuLSdbRK0OJm9THw== x-ms-office365-filtering-correlation-id: d1e23404-e9db-41ce-89cf-08d47d826429 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)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39400400002)(39410400002)(39850400002)(377454003)(13464003)(86362001)(305945005)(7736002)(74316002)(6116002)(5250100002)(102836003)(3846002)(2900100001)(189998001)(2906002)(81166006)(8936002)(3660700001)(8676002)(55016002)(6246003)(3280700002)(50986999)(38730400002)(53376002)(53936002)(229853002)(33656002)(66066001)(5660300001)(966004)(53546009)(7696004)(2950100002)(6306002)(99286003)(54356999)(76176999)(6436002)(9686003)(25786009)(6506006)(336755003)(18886065003); 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: 07 Apr 2017 06:50:34.4809 (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: H4sIAAAAAAAAA02Sa0hTcRjG+++cs50tF/8tL6+2hQ4hDfJGeCmL9EsiBEJ9mBrozIMO55TN RI1ikBh5a6Bim1CuJEpJRcyp6ch5SaNQzFaJ90vLoYiE2Mgst2OXb7/3eZ734f8eDk2Iqyg/ WqkuYDRqhUrGFZAGuTngVH+kXR7mqD0RbV66TUUPLzZS0SPrs9wLRIJjfoJKKB3aoBKampyc JCJFEJvJqJSFjCb0fLog+3GXicxvP160/dNfh95KyxFNAz4NLbpz5UhAi3EbAnN7L8kOrxE4 N58QroHEVQQ837XwWKeOA45tK5cdFhB8cHbu7/BpLo6FZ9Yd5GJPrENQ2Rrl4qM4BlZLHSSr n4GPprm/bHhZz3ExiQPhnXme52IhToGthfqDd1QgWDVtuUN8fAW6e1+4QwhLYX6HLSKwD0yv PHRnAGNo6hsnWPaCteU9ylWE8D0ElqEygr3aHwYdQpcOuIKAsZZKkl24BNV2/UHRTVi4q+Ow eSV86o9i5URor57hsrvjHPgyu8tjDQn0TdoI1tBTUPVmhGDP94PZqbuIZQl8nemnXKUEDoa2 3lA9CjL+d4Pxn8PKAVBbscgzur+LCMYMK2QjIpuRl5bRZuRmRUSEMBrlNa02Tx2iZgo60P5P MtD5I6wbrdnjrAjTSOYhTP++IhdTikJtca4VAU3IPIXL4Xa5WJipKC5hNHlpmusqRmtFx2hS 5iOMs0zIxThLUcDkMEw+o/njcmi+nw4dtjWkfn6qEg43l9WJ3ktUFwdGRTVLyToPb9+8B10Z dxrCxi4H5iTuFWVbmm6N8ku8r2oyf8XYJrsTDY9qWkcPbVc7zTMe6Wk9QfqNdd+pvUhp4Y2k +8mmjClRKccYL/cP3kyVdCi+OW1H0syvYnbixjumz65L6wd7JPGq8rk+GanNVoSfJDRaxW/f 8DksIAMAAA== Archived-At: Subject: Re: [tsvwg] transport protocol feedback overhead X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 06:50:44 -0000 SGkNCg0KU3VyZSwgQUNLcyBjYXJyeSBhIGxvdCBvZiBpbmZvcm1hdGlvbiwgdGhpcyBpcyB0aGUg c3Ryb25nZXN0IGFyZ3VtZW50IGFnYWluc3QgbWlkZGxlYm94IGludGVyYWN0aW9uIEJUVy4gDQpB bHNvIHRoZSBpbnRlbnRpb24gd2l0aCBBQ0sgcmF0ZSByZWR1Y3Rpb24gaXMgbm90ICJhdCBhbnkg Y29zdCIuIE9uZSBuZWVkIHRvIHN0cmlrZSBhIGJhbGFuY2UgYmV0d2VlbiBBQ0sgcmF0ZSBhbmQg cGVyZm9ybWFuY2Ugd2hlcmUgdGhlIHRvbGVyYW5jZSBhZ2FpbnN0IHJlZHVjZWQgcGVyZm9ybWFu Y2Ugc2hvdWxkIGJlIHZlcnkgbG93Lg0KDQovSW5nZW1hcg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IEdlbmd4dWVzb25nIChHZW5nIFh1ZXNvbmcpIFttYWlsdG86Z2Vu Z3h1ZXNvbmdAaHVhd2VpLmNvbV0NCj4gU2VudDogZGVuIDYgYXByaWwgMjAxNyAwMzo0Mg0KPiBU bzogQm9iIEJyaXNjb2UgPGlldGZAYm9iYnJpc2NvZS5uZXQ+OyBJbmdlbWFyIEpvaGFuc3NvbiBT DQo+IDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT47IHRzdndnIElFVEYgbGlzdCA8 dHN2d2dAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJFOiBbdHN2d2ddIHRyYW5zcG9ydCBwcm90b2Nv bCBmZWVkYmFjayBvdmVyaGVhZA0KPiANCj4gSGkgQm9iLA0KPiANCj4gDQo+IEkgdGhpbmsgaXQg aXMgYW4gaW50ZXJlc3RpbmcgaWRlYSB0byBzb2x2ZSB0aGUgcHJvYmxlbSwgYnV0IEkgd29uZGVy IHRoYXQNCj4gd2hldGhlciBkb2luZyB0aGlzIHdpbGwgY2F1c2Ugb3RoZXIgcHJvYmxlbSwgYmVj YXVzZSB0aGUgQUNLIGNhcnJpZXMgbW9yZQ0KPiBpbmZvcm1hdGlvbiB0aGFuIGFycml2YWwgdGlt ZS4NCj4gRm9yIGV4YW1wbGUgaWYgYW4gQUNLIHdpdGggY29uZ2VzdGlvbiBpbmZvcm1hdGlvbiBh cnJpdmVzIGxhdGVyIHRoYW4gYmVmb3JlLA0KPiB0aGVuIHRoZSBjb25nZXN0aW9uIHJlc3BvbnNl IHdpbGwgYmUgZGVsYXllZCBlaXRoZXIsIHdoaWNoIG1heSBkbyBoYXJtIHRvDQo+IHRoZSBjb25n ZXN0ZWQgbmV0d29yay4NCj4gDQo+IA0KPiBCZXN0IFJlZ2FyZHMsDQo+IA0KPiBYdWVzb25nDQo+ IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRz dndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCb2IgQnJpc2NvZQ0KPiBTZW50OiBG cmlkYXksIE1hcmNoIDMxLCAyMDE3IDQ6MTggQU0NCj4gVG86IEluZ2VtYXIgSm9oYW5zc29uIFM7 IHRzdndnIElFVEYgbGlzdA0KPiBTdWJqZWN0OiBbdHN2d2ddIHRyYW5zcG9ydCBwcm90b2NvbCBm ZWVkYmFjayBvdmVyaGVhZA0KPiANCj4gSW5nZW1hciwgbGlzdCwNCj4gDQo+IEkgc2VlbWVkIHRv IGdldCBibG9ja2VkIGZyb20gdGFsa2luZyBhZnRlciBJIHdhcyB0cnlpbmcgdG8gYmUgcG9saXRl IC0gbGV0dGluZw0KPiB5b3UgZmluaXNoIHlvdXIgdGFsay4uLg0KPiANCj4gWW91IGRlc2NyaWJl ZCBvbmUgcHJvYmxlbToNCj4gICAoQSkgSW4gbW9iaWxlIChhbmQgb3RoZXIgbmV0d29ya3MpICB1 cHN0cmVhbSBBQ0sgbG9hZCBpcyBhIHByb2JsZW0uDQo+IA0KPiBUaGVyZSBpcyBhIGNvbXBsZW1l bnRhcnkgcHJvYmxlbSB0b286DQo+IChCKSBDYXBhY2l0eSB2YXJpYXRpb24gaXMgZ2V0dGluZyBo dWdlIGFzIHJhZGlvIHdhdmVsZW5ndGggaW5jcmVhc2VzLiBTbyBpdCdzDQo+IHVzZWZ1bCBmb3Ig dGhlIHNlbmRlciB0byB3YXRjaCB0aGUgdGltaW5nIG9mIHRoZSBBQ0tzIHRvIGJlIGFibGUgdG8g dHJhY2sNCj4gY2hhbmdlcyBpbiBjYXBhY2l0eSBhcyBmYXN0IGFzIHBvc3NpYmxlLiBJdCdzIGFs c28gdXNlZnVsIHRvIGJlIGFibGUgdG8gdmFyeSB0aGUNCj4gc3BhY2luZyBiZXR3ZWVuIHRoZSBw YWNrZXRzIHlvdSBzZW5kIHRvIHByb2JlIGZvciBpbmNyZWFzZXMgaW4gY2FwYWNpdHkgYnkNCj4g d2F0Y2hpbmcgdGhlIEFDSyBzcGFjaW5nIGluIHJlc3BvbnNlLg0KPiANCj4gVGhlc2UgdHdvIGFy ZSBpbiB0ZW5zaW9uIC0gKEEpIHdhbnRzIGxlc3MgQUNLcywgKEIpIHdhbnRzIHRoZW0gYWxsLg0K PiANCj4gQSBwb3NzaWJsZSBzb2x1dGlvbiwgaXMgYSBkYXRhIHN0cnVjdHVyZSBpbiBhIHN0cmV0 Y2ggQUNLIHRvIGJlIGFibGUgdG8gcmVwb3J0DQo+IHRoZSB0aW1lIG9mIGFycml2YWwgb2YgYWxs IHRoZSBwcmV2aW91cyBkYXRhIHBhY2tldHMgKGllLiB0aGUgcGFja2V0cyB0aGF0IHRoZQ0KPiBz dHJldGNoIEFDSyBpcyBBQ0tpbmcuDQo+IA0KPiBFdmVuIHRobyB0aGlzIGluZm8gd2lsbCBhcnJp dmUgYXQgdGhlIHNlbmRlciBsYXRlciB0aGFuIGl0IHdvdWxkIGhhdmUgZG9uZSBpZiB0aGUNCj4g QUNLcyBoYWQgbm90IGJlZW4gc3VwcHJlc3NlZCwgYXMgbG9uZyBhcyB5b3UgYXJlIHN0aWxsIGdl dHRpbmcgYSByZWFzb25hYmxlDQo+IG51bWJlciBvZiBBQ0tzIGV2ZXJ5IFJUVCwgaXQgcmVzb2x2 ZXMgdGhlIHRlbnNpb24gYmV0d2VlbiBBIGFuZCBCLg0KPiANCj4gVGhvdWdodHM/DQo+IERvZXMg dGhpcyBpZGVhIGFscmVhZHkgZXhpc3Q/DQo+IA0KPiANCj4gDQo+IEJvYg0KPiANCj4gUFMuIEFw b2xvZ2llcyBmb3IgZHJvcHBpbmcgYW4gaW5ub3ZhdGl2ZSBpZGVhIGludG8gYSBzdGFuZGFyZHMg bWVldGluZy4NCj4gVGhpcyBwcm9iYWJseSBvdWdodCB0byBiZSBhIHJlc2VhcmNoIHBhcGVyIGZp cnN0Lg0KPiANCj4gDQo+IC0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fDQo+IEJvYiBCcmlzY29lICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0K From nobody Fri Apr 7 00:12:21 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E9B12025C for ; Fri, 7 Apr 2017 00:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCIh9vC6ImRx for ; Fri, 7 Apr 2017 00:12:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93900129430 for ; Fri, 7 Apr 2017 00:12:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKL52214; Fri, 07 Apr 2017 07:12:12 +0000 (GMT) Received: from DGGEMA404-HUB.china.huawei.com (10.3.20.45) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 7 Apr 2017 08:12:10 +0100 Received: from DGGEMA501-MBX.china.huawei.com ([169.254.1.85]) by DGGEMA404-HUB.china.huawei.com ([10.3.20.45]) with mapi id 14.03.0301.000; Fri, 7 Apr 2017 15:12:06 +0800 From: "Gengxuesong (Geng Xuesong)" To: Ingemar Johansson S , Bob Briscoe , tsvwg IETF list Thread-Topic: [tsvwg] transport protocol feedback overhead Thread-Index: AQHSqZLE7ApBcd6XQUiJZ0pUEcVZ+aG3mmaQgAFi2gCAAIcB4A== Date: Fri, 7 Apr 2017 07:12:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58E73BCD.001C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.85, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4eeb8088ecf3d418deabdd8b1d3ba88a Archived-At: Subject: Re: [tsvwg] transport protocol feedback overhead X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 07:12:20 -0000 SGkgSW5nZW1hciwNCg0KVGhhbmsgeW91IGZvciBvdXIgcmVzcG9uc2UuDQpJdCBpcyByZWFzb25h YmxlIHRvIGZpbmQgYSBwb2ludCB0aGF0IGNhbiByZWR1Y2UgdGhlIEFDSyByYXRlIHdpdGhvdXQg aHVydGluZyBpdHMgcGVyZm9ybWFuY2UsIGJ1dCBJIGFsc28gd29uZGVyIHRoYXQgd2hldGhlciBB Q0sgY2FycmllcyB0b28gbXVjaCBpbmZvcm1hdGlvbiB3aGljaCBjYW4gYmUgY29uc2lkZXJlZCB0 byBnaXZlIHRvIHRoZSBtaWRkbGVib3guDQpGb3IgZXhhbXBsZSB0aGUgY29uZ2VzdGlvbiBub3Rp ZmljYXRpb24gZ2VuZXJhdGVkIGluIHRoZSBtaWRkbGUgYm94IGNhbiBiZSBzZW50IHRvIHRoZSBz b3VyY2UgZGlyZWN0bHkgd2l0aG91dCBnb2luZyB0aHJvdWdoIHRoZSByZWNlaXZlciwganVzdCBs aWtlIFFDTiBpbiBMYXllciAyLg0KSSBkb24ndCBrbm93IHdoZXRoZXIgdGhpcyBhbHNvIGJlbG9u Z3MgdG8gdGhlICJtaWRkbGVib3ggaW50ZXJhY3Rpb24iIHlvdSBoYXZlIG1lbnRpb25lZCA6ICkN Cg0KDQpCZXN0IFJlZ2FyZHMsDQoNClh1ZXNvbmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEluZ2VtYXIgSm9oYW5zc29uIFMgW21haWx0bzppbmdlbWFyLnMuam9oYW5zc29u QGVyaWNzc29uLmNvbV0gDQpTZW50OiBGcmlkYXksIEFwcmlsIDA3LCAyMDE3IDI6NTEgUE0NClRv OiBHZW5neHVlc29uZyAoR2VuZyBYdWVzb25nKTsgQm9iIEJyaXNjb2U7IHRzdndnIElFVEYgbGlz dA0KU3ViamVjdDogUkU6IFt0c3Z3Z10gdHJhbnNwb3J0IHByb3RvY29sIGZlZWRiYWNrIG92ZXJo ZWFkDQoNCkhpDQoNClN1cmUsIEFDS3MgY2FycnkgYSBsb3Qgb2YgaW5mb3JtYXRpb24sIHRoaXMg aXMgdGhlIHN0cm9uZ2VzdCBhcmd1bWVudCBhZ2FpbnN0IG1pZGRsZWJveCBpbnRlcmFjdGlvbiBC VFcuIA0KQWxzbyB0aGUgaW50ZW50aW9uIHdpdGggQUNLIHJhdGUgcmVkdWN0aW9uIGlzIG5vdCAi YXQgYW55IGNvc3QiLiBPbmUgbmVlZCB0byBzdHJpa2UgYSBiYWxhbmNlIGJldHdlZW4gQUNLIHJh dGUgYW5kIHBlcmZvcm1hbmNlIHdoZXJlIHRoZSB0b2xlcmFuY2UgYWdhaW5zdCByZWR1Y2VkIHBl cmZvcm1hbmNlIHNob3VsZCBiZSB2ZXJ5IGxvdy4NCg0KL0luZ2VtYXINCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHZW5neHVlc29uZyAoR2VuZyBYdWVzb25nKSBbbWFp bHRvOmdlbmd4dWVzb25nQGh1YXdlaS5jb21dDQo+IFNlbnQ6IGRlbiA2IGFwcmlsIDIwMTcgMDM6 NDINCj4gVG86IEJvYiBCcmlzY29lIDxpZXRmQGJvYmJyaXNjb2UubmV0PjsgSW5nZW1hciBKb2hh bnNzb24gUyANCj4gPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPjsgdHN2d2cgSUVU RiBsaXN0IDx0c3Z3Z0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IFt0c3Z3Z10gdHJhbnNwb3J0 IHByb3RvY29sIGZlZWRiYWNrIG92ZXJoZWFkDQo+IA0KPiBIaSBCb2IsDQo+IA0KPiANCj4gSSB0 aGluayBpdCBpcyBhbiBpbnRlcmVzdGluZyBpZGVhIHRvIHNvbHZlIHRoZSBwcm9ibGVtLCBidXQg SSB3b25kZXIgDQo+IHRoYXQgd2hldGhlciBkb2luZyB0aGlzIHdpbGwgY2F1c2Ugb3RoZXIgcHJv YmxlbSwgYmVjYXVzZSB0aGUgQUNLIA0KPiBjYXJyaWVzIG1vcmUgaW5mb3JtYXRpb24gdGhhbiBh cnJpdmFsIHRpbWUuDQo+IEZvciBleGFtcGxlIGlmIGFuIEFDSyB3aXRoIGNvbmdlc3Rpb24gaW5m b3JtYXRpb24gYXJyaXZlcyBsYXRlciB0aGFuIA0KPiBiZWZvcmUsIHRoZW4gdGhlIGNvbmdlc3Rp b24gcmVzcG9uc2Ugd2lsbCBiZSBkZWxheWVkIGVpdGhlciwgd2hpY2ggbWF5IA0KPiBkbyBoYXJt IHRvIHRoZSBjb25nZXN0ZWQgbmV0d29yay4NCj4gDQo+IA0KPiBCZXN0IFJlZ2FyZHMsDQo+IA0K PiBYdWVzb25nDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0c3Z3 ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCb2IgQnJpc2Nv ZQ0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDMxLCAyMDE3IDQ6MTggQU0NCj4gVG86IEluZ2VtYXIg Sm9oYW5zc29uIFM7IHRzdndnIElFVEYgbGlzdA0KPiBTdWJqZWN0OiBbdHN2d2ddIHRyYW5zcG9y dCBwcm90b2NvbCBmZWVkYmFjayBvdmVyaGVhZA0KPiANCj4gSW5nZW1hciwgbGlzdCwNCj4gDQo+ IEkgc2VlbWVkIHRvIGdldCBibG9ja2VkIGZyb20gdGFsa2luZyBhZnRlciBJIHdhcyB0cnlpbmcg dG8gYmUgcG9saXRlIC0gDQo+IGxldHRpbmcgeW91IGZpbmlzaCB5b3VyIHRhbGsuLi4NCj4gDQo+ IFlvdSBkZXNjcmliZWQgb25lIHByb2JsZW06DQo+ICAgKEEpIEluIG1vYmlsZSAoYW5kIG90aGVy IG5ldHdvcmtzKSAgdXBzdHJlYW0gQUNLIGxvYWQgaXMgYSBwcm9ibGVtLg0KPiANCj4gVGhlcmUg aXMgYSBjb21wbGVtZW50YXJ5IHByb2JsZW0gdG9vOg0KPiAoQikgQ2FwYWNpdHkgdmFyaWF0aW9u IGlzIGdldHRpbmcgaHVnZSBhcyByYWRpbyB3YXZlbGVuZ3RoIGluY3JlYXNlcy4gDQo+IFNvIGl0 J3MgdXNlZnVsIGZvciB0aGUgc2VuZGVyIHRvIHdhdGNoIHRoZSB0aW1pbmcgb2YgdGhlIEFDS3Mg dG8gYmUgDQo+IGFibGUgdG8gdHJhY2sgY2hhbmdlcyBpbiBjYXBhY2l0eSBhcyBmYXN0IGFzIHBv c3NpYmxlLiBJdCdzIGFsc28gDQo+IHVzZWZ1bCB0byBiZSBhYmxlIHRvIHZhcnkgdGhlIHNwYWNp bmcgYmV0d2VlbiB0aGUgcGFja2V0cyB5b3Ugc2VuZCB0byANCj4gcHJvYmUgZm9yIGluY3JlYXNl cyBpbiBjYXBhY2l0eSBieSB3YXRjaGluZyB0aGUgQUNLIHNwYWNpbmcgaW4gcmVzcG9uc2UuDQo+ IA0KPiBUaGVzZSB0d28gYXJlIGluIHRlbnNpb24gLSAoQSkgd2FudHMgbGVzcyBBQ0tzLCAoQikg d2FudHMgdGhlbSBhbGwuDQo+IA0KPiBBIHBvc3NpYmxlIHNvbHV0aW9uLCBpcyBhIGRhdGEgc3Ry dWN0dXJlIGluIGEgc3RyZXRjaCBBQ0sgdG8gYmUgYWJsZSANCj4gdG8gcmVwb3J0IHRoZSB0aW1l IG9mIGFycml2YWwgb2YgYWxsIHRoZSBwcmV2aW91cyBkYXRhIHBhY2tldHMgKGllLiANCj4gdGhl IHBhY2tldHMgdGhhdCB0aGUgc3RyZXRjaCBBQ0sgaXMgQUNLaW5nLg0KPiANCj4gRXZlbiB0aG8g dGhpcyBpbmZvIHdpbGwgYXJyaXZlIGF0IHRoZSBzZW5kZXIgbGF0ZXIgdGhhbiBpdCB3b3VsZCBo YXZlIA0KPiBkb25lIGlmIHRoZSBBQ0tzIGhhZCBub3QgYmVlbiBzdXBwcmVzc2VkLCBhcyBsb25n IGFzIHlvdSBhcmUgc3RpbGwgDQo+IGdldHRpbmcgYSByZWFzb25hYmxlIG51bWJlciBvZiBBQ0tz IGV2ZXJ5IFJUVCwgaXQgcmVzb2x2ZXMgdGhlIHRlbnNpb24gYmV0d2VlbiBBIGFuZCBCLg0KPiAN Cj4gVGhvdWdodHM/DQo+IERvZXMgdGhpcyBpZGVhIGFscmVhZHkgZXhpc3Q/DQo+IA0KPiANCj4g DQo+IEJvYg0KPiANCj4gUFMuIEFwb2xvZ2llcyBmb3IgZHJvcHBpbmcgYW4gaW5ub3ZhdGl2ZSBp ZGVhIGludG8gYSBzdGFuZGFyZHMgbWVldGluZy4NCj4gVGhpcyBwcm9iYWJseSBvdWdodCB0byBi ZSBhIHJlc2VhcmNoIHBhcGVyIGZpcnN0Lg0KPiANCj4gDQo+IC0tDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fDQo+ IEJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2Jicmlz Y29lLm5ldC8NCg0K From nobody Fri Apr 7 00:44:25 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AD6128CD5 for ; Fri, 7 Apr 2017 00:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 e97a6PuqAG61 for ; Fri, 7 Apr 2017 00:44:22 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 A59A4128B4E for ; Fri, 7 Apr 2017 00:44:22 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cwOZ1-000DGi-J7; Fri, 07 Apr 2017 09:44:11 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx04.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cwOZ0-000D9o-K3; Fri, 07 Apr 2017 09:44:11 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Fri, 7 Apr 2017 09:44:07 +0200 Cc: Ingemar Johansson S , Bob Briscoe , tsvwg IETF list , iccrg@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: <79981E87-BB9E-455B-9D82-09F14C48B2FB@ifi.uio.no> References: To: "Gengxuesong (Geng Xuesong)" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 14 msgs/h 4 sum rcpts/h 16 sum msgs/h 4 total rcpts 53667 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.065, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C09500F1830D2C6E59B89DF04BF7C6F0803B3395 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 12901 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tsvwg] transport protocol feedback overhead X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 07:44:24 -0000 All, I'm cc'ing ICCRG because these are truly research musings IMO. Maybe, if = folks agree, we can truly move this thread and drop the tsvwg list from = recipients? A thought: One reason we didn't continue our own work on this (the master thesis I = mentioned previously) was that it wasn't 100% clear to us whether this = is a *real* problem - is it a problem worth solving? How often does it = occur? How problematic is it? I think Ingemar made a good point in his presentation about the problem = being real. Still, often ACKs are mixed with payload traffic. Consider = the following scenario: Say, I have a thin uplink. In parallel, I download a file, and I upload a file (just as a simple = model). Both take long, there is congestion, packets are dropped. =3D> should the rate of outgoing payload be reduced, or should the ACK = rate be reduced? Or both? Given that ACKs tend to be smaller, losing too many ACKs could be quite = harmful, and the Internet has survived very long without ACK rate = reduction, I'd tend to think the payload should be the first to react. So then, a scheme that changes the ACK rate could try to figure out if = it truly was the ACKs that created congestion. This could be done by checking the impact of one's actions with some = heuristics. For example: if I increase the rate, does delay increase = with it, and does it decrease again if I decrease the rate? What if, different from a "normal" congestion control reaction where = senders try to back off immediately upon any form of congestion = indication, ACK rate reduction would do such tests for 2-3 round trips = before actually backing off? This would avoid a situation where, in my = example, both the download and the upload traffic would back off = together (which might be overdoing it). Just some thoughts - as I said, research ideas. Cheers, Michael > On 07 Apr 2017, at 09:12, Gengxuesong (Geng Xuesong) = wrote: >=20 > Hi Ingemar, >=20 > Thank you for our response. > It is reasonable to find a point that can reduce the ACK rate without = hurting its performance, but I also wonder that whether ACK carries too = much information which can be considered to give to the middlebox. > For example the congestion notification generated in the middle box = can be sent to the source directly without going through the receiver, = just like QCN in Layer 2. > I don't know whether this also belongs to the "middlebox interaction" = you have mentioned : ) >=20 >=20 > Best Regards, >=20 > Xuesong >=20 > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]=20 > Sent: Friday, April 07, 2017 2:51 PM > To: Gengxuesong (Geng Xuesong); Bob Briscoe; tsvwg IETF list > Subject: RE: [tsvwg] transport protocol feedback overhead >=20 > Hi >=20 > Sure, ACKs carry a lot of information, this is the strongest argument = against middlebox interaction BTW.=20 > Also the intention with ACK rate reduction is not "at any cost". One = need to strike a balance between ACK rate and performance where the = tolerance against reduced performance should be very low. >=20 > /Ingemar >=20 >> -----Original Message----- >> From: Gengxuesong (Geng Xuesong) [mailto:gengxuesong@huawei.com] >> Sent: den 6 april 2017 03:42 >> To: Bob Briscoe ; Ingemar Johansson S=20 >> ; tsvwg IETF list >> Subject: RE: [tsvwg] transport protocol feedback overhead >>=20 >> Hi Bob, >>=20 >>=20 >> I think it is an interesting idea to solve the problem, but I wonder=20= >> that whether doing this will cause other problem, because the ACK=20 >> carries more information than arrival time. >> For example if an ACK with congestion information arrives later than=20= >> before, then the congestion response will be delayed either, which = may=20 >> do harm to the congested network. >>=20 >>=20 >> Best Regards, >>=20 >> Xuesong >>=20 >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Bob Briscoe >> Sent: Friday, March 31, 2017 4:18 AM >> To: Ingemar Johansson S; tsvwg IETF list >> Subject: [tsvwg] transport protocol feedback overhead >>=20 >> Ingemar, list, >>=20 >> I seemed to get blocked from talking after I was trying to be polite = -=20 >> letting you finish your talk... >>=20 >> You described one problem: >> (A) In mobile (and other networks) upstream ACK load is a problem. >>=20 >> There is a complementary problem too: >> (B) Capacity variation is getting huge as radio wavelength increases.=20= >> So it's useful for the sender to watch the timing of the ACKs to be=20= >> able to track changes in capacity as fast as possible. It's also=20 >> useful to be able to vary the spacing between the packets you send to=20= >> probe for increases in capacity by watching the ACK spacing in = response. >>=20 >> These two are in tension - (A) wants less ACKs, (B) wants them all. >>=20 >> A possible solution, is a data structure in a stretch ACK to be able=20= >> to report the time of arrival of all the previous data packets (ie.=20= >> the packets that the stretch ACK is ACKing. >>=20 >> Even tho this info will arrive at the sender later than it would have=20= >> done if the ACKs had not been suppressed, as long as you are still=20 >> getting a reasonable number of ACKs every RTT, it resolves the = tension between A and B. >>=20 >> Thoughts? >> Does this idea already exist? >>=20 >>=20 >>=20 >> Bob >>=20 >> PS. Apologies for dropping an innovative idea into a standards = meeting. >> This probably ought to be a research paper first. >>=20 >>=20 >> -- >> __________________________________________________________ >> ______ >> Bob Briscoe http://bobbriscoe.net/ >=20 From nobody Fri Apr 7 00:50:52 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FE11274D0 for ; Fri, 7 Apr 2017 00:50:51 -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, 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 oIlXyYSuO6_I for ; Fri, 7 Apr 2017 00:50:49 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 4A16F1293F3 for ; Fri, 7 Apr 2017 00:50:49 -0700 (PDT) X-AuditID: c1b4fb30-ea83298000006667-dd-58e744d7215d Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 8C.CA.26215.7D447E85; Fri, 7 Apr 2017 09:50:47 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 7 Apr 2017 09:50:45 +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=/yZgUyP4Dgsv0YY7S4I5347gbe/31z8JAHPNiabAEhI=; b=br/RByO1LjvrYJZHxIuKmv2MSkUgKO3khpD8nqqyj1ufoFOLYKw3aWk2/I4cjolJMhfda5e0axTCxzq7Kht/JuoaW4ft7CXiRsmZSYntSwaAUeC82Gy54vfNhKDO/Bc2rR+auZa72PWU4x1D5LM2dQCG0K2pY0BFugcWcln8Eks= 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.1034.5; Fri, 7 Apr 2017 07:50:42 +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 07:50:42 +0000 From: Ingemar Johansson S To: "Gengxuesong (Geng Xuesong)" , Bob Briscoe , tsvwg IETF list CC: Ingemar Johansson S Thread-Topic: [tsvwg] transport protocol feedback overhead Thread-Index: AQHSqZLOdmB+LdBFN0Wl5nbQvPjKQ6G3mr+AgAHnFICAAAeNgIAACWuw Date: Fri, 7 Apr 2017 07:50:41 +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: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.82] x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:82tF09oAvJnVqbP+63C+6jP7bc4fMB8KHH0vc3ApNHzeAODkZ9mwM91u5h7Nl+XTGOMHo2UzQMPIw3Bt4j1EeX5RPwVY4OGoX07IUFRx1N8VgsxKF+w8e15gI67gobs+9mmwD7bLTZ9pCZAHV/0H89ABmrlXTtQbP7V/Pp2IthTDTiA930As3Z8DcYCQOJlXwIEeD/pyPLFS9KcwAyeHWjlEQqKZuTpEJ2XR1QUndM8oeZf/VEsvHuwf4VcTPUuuTX+ZXPaW9+A+saPkfOC4S9Dirbd/EF4W22uxD535HNhxMHPtKREFU7jtPE3g4Oiytx/J/yA1wQXTN81Eq0oRyA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39840400002)(39410400002)(377454003)(13464003)(86362001)(305945005)(74316002)(6116002)(102836003)(3846002)(2900100001)(189998001)(345774005)(2906002)(4326008)(81166006)(3660700001)(8936002)(8676002)(55016002)(6246003)(50986999)(3280700002)(38730400002)(53376002)(107886003)(53936002)(5660300001)(66066001)(33656002)(53546009)(966004)(7696004)(2950100002)(6306002)(99286003)(54356999)(76176999)(6436002)(25786009)(93886004)(9686003)(6506006)(336755003)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 71133f5d-9a0a-4a0f-64cb-08d47d8aca5d 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)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 0270ED2845 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: 07 Apr 2017 07:50:41.6878 (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: H4sIAAAAAAAAA02SfUhTYRTGfXd3t7vZ7G0pHnRRrsAPyC8iTbSyxFbRxx8SQypdedHhnLa7 JMXK0CQ1p2kFk8IlS0szxYpJLMXvSsgPIsOP1JyakhQhLDMz7+6C/vud8zznPO+BlyKkJaQX pdbqaZ1WpZELxHyj0hK3czhmThlsKfMNt3zOI8O7p0xkeM/XccF+QrEwMUAq8rsWSYXZvMw7 ScSLI5NojTqT1gXtTRSnjPQNoozXIZcmKrNzkTm4CIkowLvA0v2MKEJiSoobEcxUfCO5ohfB 2sdmR8HHJQS0NNUL2BEpvsODUssZzjWJoOrJOMEKAhwJjzvsiGV3nIvg5tMwlgkcAUu9qw7P ZrwHZvIX+JwnAoYffHJyLAxWvCNZ5uMdMFRmEhYhipLgeCj9nsNl1fBg+l6DkPWIcBwsXzc6 ZhHeAhN2bg+BPWHEVsXjbsNgtvYTHHvA/PQfxzUIlyJo7Sog2ADA26BzQcL2ARcTYDWNElxR S0KnfcRpOga3XmznFl2GycJcZ4AazIO9Qo6PQJNhTMDN9vNgdvy3U5CBdeiD83ovGH9fiDiW wZexV2QZ8q/87+GV63EE9ofGl0Fc2wduF08JWZbgTfDGaOObEL8OeTA0cy4tOTQ0kNapzzNM ujZQS+ub0fonaX++EtyC5ueiOxCmkHyDJPGnTSklVZlMVloHAoqQu0tGD84ppZIkVVY2rUtP 0F3U0EwH8qb4ck9JdOuAUoqTVXo6laYzaN0/lUeJvHLRKdfi2b46b7fZs6bWG4S+WvFwbEnW 267PPH4fku37ihIepQwxvxiX0yeypCJmxLoirfFxvetraJsT5enyXQau9MjKA0Q5NYfLQzfa 3voFXIs1RYYVa5pqY/wONPTvXjvamaoOMqweilJEudVPbTUoVcaogj43z+rMq20XVhd/yPlM iiokgNAxqr9heXbLIAMAAA== Archived-At: Subject: Re: [tsvwg] transport protocol feedback overhead X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 07:50:52 -0000 SGkNCg0KQXMgSSBzZWUgaXQsIHRoZXNlIGtpbmRzIG9mIG1pZGRsZWJveCBnZW5lcmF0ZWQgZmVl ZGJhY2sgaWRlYXMgaXMgcHJvYmFibHkgYSBkaWZmZXJlbnQgdG9waWMgYW5kIEkgYmVsaWV2ZSB0 aGF0IGNhbiBiZSBnb29kIHRvIGtlZXAgdGhlIHR3byB0b3BpY3MgKG1pZGRsZWJveCBnZW5lcmF0 ZWQgQUNLcywgYW5kIEFDSyByYXRlIGluIGVuZCBob3N0cykgc2VwYXJhdGVkLCBiZWNhdXNlIHRo ZSBtaWRkbGVib3ggQUNLIGludm9sdmVzIG90aGVyIGNvbmNlcm5zIGFyb3VuZCBhdXRoZW50aWNh dGlvbiBldC5jLg0KTXkgbWFpbiBpbnRlcmVzdCBmb3Igbm93IGlzIGluIGdldHRpbmcgdGhlIEFD SyByYXRlIHJlZHVjZWQgd2hlcmUgcG9zc2libGUgYW5kIGFsc28gc29tZSBraW5kIG9mIGRvY3Vt ZW50YXRpb24gdGhhdCBkZXNjcmliZXMgd2hhdCBpcyBkb25lIGFscmVhZHkgdG9kYXkuDQogDQov SW5nZW1hcg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdlbmd4dWVz b25nIChHZW5nIFh1ZXNvbmcpIFttYWlsdG86Z2VuZ3h1ZXNvbmdAaHVhd2VpLmNvbV0NCj4gU2Vu dDogZGVuIDcgYXByaWwgMjAxNyAwOToxMg0KPiBUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5n ZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+OyBCb2IgQnJpc2NvZQ0KPiA8aWV0ZkBib2Ji cmlzY29lLm5ldD47IHRzdndnIElFVEYgbGlzdCA8dHN2d2dAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6 IFJFOiBbdHN2d2ddIHRyYW5zcG9ydCBwcm90b2NvbCBmZWVkYmFjayBvdmVyaGVhZA0KPiANCj4g SGkgSW5nZW1hciwNCj4gDQo+IFRoYW5rIHlvdSBmb3Igb3VyIHJlc3BvbnNlLg0KPiBJdCBpcyBy ZWFzb25hYmxlIHRvIGZpbmQgYSBwb2ludCB0aGF0IGNhbiByZWR1Y2UgdGhlIEFDSyByYXRlIHdp dGhvdXQgaHVydGluZw0KPiBpdHMgcGVyZm9ybWFuY2UsIGJ1dCBJIGFsc28gd29uZGVyIHRoYXQg d2hldGhlciBBQ0sgY2FycmllcyB0b28gbXVjaA0KPiBpbmZvcm1hdGlvbiB3aGljaCBjYW4gYmUg Y29uc2lkZXJlZCB0byBnaXZlIHRvIHRoZSBtaWRkbGVib3guDQo+IEZvciBleGFtcGxlIHRoZSBj b25nZXN0aW9uIG5vdGlmaWNhdGlvbiBnZW5lcmF0ZWQgaW4gdGhlIG1pZGRsZSBib3ggY2FuIGJl DQo+IHNlbnQgdG8gdGhlIHNvdXJjZSBkaXJlY3RseSB3aXRob3V0IGdvaW5nIHRocm91Z2ggdGhl IHJlY2VpdmVyLCBqdXN0IGxpa2UgUUNODQo+IGluIExheWVyIDIuDQo+IEkgZG9uJ3Qga25vdyB3 aGV0aGVyIHRoaXMgYWxzbyBiZWxvbmdzIHRvIHRoZSAibWlkZGxlYm94IGludGVyYWN0aW9uIiB5 b3UNCj4gaGF2ZSBtZW50aW9uZWQgOiApDQo+IA0KPiANCj4gQmVzdCBSZWdhcmRzLA0KPiANCj4g WHVlc29uZw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSW5nZW1h ciBKb2hhbnNzb24gUyBbbWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tXQ0K PiBTZW50OiBGcmlkYXksIEFwcmlsIDA3LCAyMDE3IDI6NTEgUE0NCj4gVG86IEdlbmd4dWVzb25n IChHZW5nIFh1ZXNvbmcpOyBCb2IgQnJpc2NvZTsgdHN2d2cgSUVURiBsaXN0DQo+IFN1YmplY3Q6 IFJFOiBbdHN2d2ddIHRyYW5zcG9ydCBwcm90b2NvbCBmZWVkYmFjayBvdmVyaGVhZA0KPiANCj4g SGkNCj4gDQo+IFN1cmUsIEFDS3MgY2FycnkgYSBsb3Qgb2YgaW5mb3JtYXRpb24sIHRoaXMgaXMg dGhlIHN0cm9uZ2VzdCBhcmd1bWVudCBhZ2FpbnN0DQo+IG1pZGRsZWJveCBpbnRlcmFjdGlvbiBC VFcuDQo+IEFsc28gdGhlIGludGVudGlvbiB3aXRoIEFDSyByYXRlIHJlZHVjdGlvbiBpcyBub3Qg ImF0IGFueSBjb3N0Ii4gT25lIG5lZWQgdG8NCj4gc3RyaWtlIGEgYmFsYW5jZSBiZXR3ZWVuIEFD SyByYXRlIGFuZCBwZXJmb3JtYW5jZSB3aGVyZSB0aGUgdG9sZXJhbmNlDQo+IGFnYWluc3QgcmVk dWNlZCBwZXJmb3JtYW5jZSBzaG91bGQgYmUgdmVyeSBsb3cuDQo+IA0KPiAvSW5nZW1hcg0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEdlbmd4dWVzb25nIChH ZW5nIFh1ZXNvbmcpIFttYWlsdG86Z2VuZ3h1ZXNvbmdAaHVhd2VpLmNvbV0NCj4gPiBTZW50OiBk ZW4gNiBhcHJpbCAyMDE3IDAzOjQyDQo+ID4gVG86IEJvYiBCcmlzY29lIDxpZXRmQGJvYmJyaXNj b2UubmV0PjsgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA+IDxpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbT47IHRzdndnIElFVEYgbGlzdCA8dHN2d2dAaWV0Zi5vcmc+DQo+ID4gU3ViamVj dDogUkU6IFt0c3Z3Z10gdHJhbnNwb3J0IHByb3RvY29sIGZlZWRiYWNrIG92ZXJoZWFkDQo+ID4N Cj4gPiBIaSBCb2IsDQo+ID4NCj4gPg0KPiA+IEkgdGhpbmsgaXQgaXMgYW4gaW50ZXJlc3Rpbmcg aWRlYSB0byBzb2x2ZSB0aGUgcHJvYmxlbSwgYnV0IEkgd29uZGVyDQo+ID4gdGhhdCB3aGV0aGVy IGRvaW5nIHRoaXMgd2lsbCBjYXVzZSBvdGhlciBwcm9ibGVtLCBiZWNhdXNlIHRoZSBBQ0sNCj4g PiBjYXJyaWVzIG1vcmUgaW5mb3JtYXRpb24gdGhhbiBhcnJpdmFsIHRpbWUuDQo+ID4gRm9yIGV4 YW1wbGUgaWYgYW4gQUNLIHdpdGggY29uZ2VzdGlvbiBpbmZvcm1hdGlvbiBhcnJpdmVzIGxhdGVy IHRoYW4NCj4gPiBiZWZvcmUsIHRoZW4gdGhlIGNvbmdlc3Rpb24gcmVzcG9uc2Ugd2lsbCBiZSBk ZWxheWVkIGVpdGhlciwgd2hpY2ggbWF5DQo+ID4gZG8gaGFybSB0byB0aGUgY29uZ2VzdGVkIG5l dHdvcmsuDQo+ID4NCj4gPg0KPiA+IEJlc3QgUmVnYXJkcywNCj4gPg0KPiA+IFh1ZXNvbmcNCj4g Pg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogdHN2d2cgW21haWx0 bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQm9iIEJyaXNjb2UNCj4gPiBT ZW50OiBGcmlkYXksIE1hcmNoIDMxLCAyMDE3IDQ6MTggQU0NCj4gPiBUbzogSW5nZW1hciBKb2hh bnNzb24gUzsgdHN2d2cgSUVURiBsaXN0DQo+ID4gU3ViamVjdDogW3RzdndnXSB0cmFuc3BvcnQg cHJvdG9jb2wgZmVlZGJhY2sgb3ZlcmhlYWQNCj4gPg0KPiA+IEluZ2VtYXIsIGxpc3QsDQo+ID4N Cj4gPiBJIHNlZW1lZCB0byBnZXQgYmxvY2tlZCBmcm9tIHRhbGtpbmcgYWZ0ZXIgSSB3YXMgdHJ5 aW5nIHRvIGJlIHBvbGl0ZSAtDQo+ID4gbGV0dGluZyB5b3UgZmluaXNoIHlvdXIgdGFsay4uLg0K PiA+DQo+ID4gWW91IGRlc2NyaWJlZCBvbmUgcHJvYmxlbToNCj4gPiAgIChBKSBJbiBtb2JpbGUg KGFuZCBvdGhlciBuZXR3b3JrcykgIHVwc3RyZWFtIEFDSyBsb2FkIGlzIGEgcHJvYmxlbS4NCj4g Pg0KPiA+IFRoZXJlIGlzIGEgY29tcGxlbWVudGFyeSBwcm9ibGVtIHRvbzoNCj4gPiAoQikgQ2Fw YWNpdHkgdmFyaWF0aW9uIGlzIGdldHRpbmcgaHVnZSBhcyByYWRpbyB3YXZlbGVuZ3RoIGluY3Jl YXNlcy4NCj4gPiBTbyBpdCdzIHVzZWZ1bCBmb3IgdGhlIHNlbmRlciB0byB3YXRjaCB0aGUgdGlt aW5nIG9mIHRoZSBBQ0tzIHRvIGJlDQo+ID4gYWJsZSB0byB0cmFjayBjaGFuZ2VzIGluIGNhcGFj aXR5IGFzIGZhc3QgYXMgcG9zc2libGUuIEl0J3MgYWxzbw0KPiA+IHVzZWZ1bCB0byBiZSBhYmxl IHRvIHZhcnkgdGhlIHNwYWNpbmcgYmV0d2VlbiB0aGUgcGFja2V0cyB5b3Ugc2VuZCB0bw0KPiA+ IHByb2JlIGZvciBpbmNyZWFzZXMgaW4gY2FwYWNpdHkgYnkgd2F0Y2hpbmcgdGhlIEFDSyBzcGFj aW5nIGluIHJlc3BvbnNlLg0KPiA+DQo+ID4gVGhlc2UgdHdvIGFyZSBpbiB0ZW5zaW9uIC0gKEEp IHdhbnRzIGxlc3MgQUNLcywgKEIpIHdhbnRzIHRoZW0gYWxsLg0KPiA+DQo+ID4gQSBwb3NzaWJs ZSBzb2x1dGlvbiwgaXMgYSBkYXRhIHN0cnVjdHVyZSBpbiBhIHN0cmV0Y2ggQUNLIHRvIGJlIGFi bGUNCj4gPiB0byByZXBvcnQgdGhlIHRpbWUgb2YgYXJyaXZhbCBvZiBhbGwgdGhlIHByZXZpb3Vz IGRhdGEgcGFja2V0cyAoaWUuDQo+ID4gdGhlIHBhY2tldHMgdGhhdCB0aGUgc3RyZXRjaCBBQ0sg aXMgQUNLaW5nLg0KPiA+DQo+ID4gRXZlbiB0aG8gdGhpcyBpbmZvIHdpbGwgYXJyaXZlIGF0IHRo ZSBzZW5kZXIgbGF0ZXIgdGhhbiBpdCB3b3VsZCBoYXZlDQo+ID4gZG9uZSBpZiB0aGUgQUNLcyBo YWQgbm90IGJlZW4gc3VwcHJlc3NlZCwgYXMgbG9uZyBhcyB5b3UgYXJlIHN0aWxsDQo+ID4gZ2V0 dGluZyBhIHJlYXNvbmFibGUgbnVtYmVyIG9mIEFDS3MgZXZlcnkgUlRULCBpdCByZXNvbHZlcyB0 aGUgdGVuc2lvbg0KPiBiZXR3ZWVuIEEgYW5kIEIuDQo+ID4NCj4gPiBUaG91Z2h0cz8NCj4gPiBE b2VzIHRoaXMgaWRlYSBhbHJlYWR5IGV4aXN0Pw0KPiA+DQo+ID4NCj4gPg0KPiA+IEJvYg0KPiA+ DQo+ID4gUFMuIEFwb2xvZ2llcyBmb3IgZHJvcHBpbmcgYW4gaW5ub3ZhdGl2ZSBpZGVhIGludG8g YSBzdGFuZGFyZHMgbWVldGluZy4NCj4gPiBUaGlzIHByb2JhYmx5IG91Z2h0IHRvIGJlIGEgcmVz ZWFyY2ggcGFwZXIgZmlyc3QuDQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IF9fX19f Xw0KPiA+IEJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9i b2JicmlzY29lLm5ldC8NCg0K From nobody Fri Apr 7 01:12:30 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B36E129464 for ; Fri, 7 Apr 2017 01:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do6Sa77H-aDw for ; Fri, 7 Apr 2017 01:12:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33E01289B0 for ; Fri, 7 Apr 2017 01:12:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEH16155; Fri, 07 Apr 2017 08:12:16 +0000 (GMT) Received: from DGGEMA403-HUB.china.huawei.com (10.3.20.44) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 7 Apr 2017 09:12:16 +0100 Received: from DGGEMA501-MBX.china.huawei.com ([169.254.1.85]) by DGGEMA403-HUB.china.huawei.com ([10.3.20.44]) with mapi id 14.03.0301.000; Fri, 7 Apr 2017 16:12:08 +0800 From: "Gengxuesong (Geng Xuesong)" To: Ingemar Johansson S , Bob Briscoe , tsvwg IETF list Thread-Topic: [tsvwg] transport protocol feedback overhead Thread-Index: AQHSqZLE7ApBcd6XQUiJZ0pUEcVZ+aG3mmaQgAFi2gCAAIcB4P//icuAgACGg9A= Date: Fri, 7 Apr 2017 08:12:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58E749E1.0069, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.85, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d76f1ab2daf3e7072e57d3f57a18249d Archived-At: Subject: Re: [tsvwg] transport protocol feedback overhead X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 08:12:28 -0000 SGkgSW5nZW1hciwNCg0KQWN0dWFsbHkgSSB0aGluayB0aGV5IGNhbiBiZSByZWxhdGVkLg0KQmVj YXVzZSB0aGVyZSBhcmUgc29tZSBmdW5jdGlvbnMgaW4gQUNLIHdoaWNoIHJlcXVpcmUgcmFwaWQg cmVzcG9uc2UuIElmIHdlIGNhbiByZW1vdmUgc29tZSBvZiB0aGVzZSBmdW5jdGlvbnMgb3V0IG9m IEFDSywgd2UgY2FuIHJlZHVjZSB0aGUgQUNLIHJhdGUgaW4gdGhlIGhvc3QgbW9yZSBlYXNpbHku DQpCdXQgeWVzLCB3ZSBjYW4gYWxzbyBkaXNjdXNzIHRoZXNlIHR3byB0b3BpY3Mgc2VwYXJhdGVs eSwgc2VlIHdoYXQgY2FuIGJlIGRvbmUgaW4gdGhlIEFDSyByYXRlIHdpdGggY3VycmVudCBBQ0sg ZnVuY3Rpb25zLg0KDQpCZXN0IFJlZ2FyZHMsDQpYdWVzb25nDQoNCiANCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEluZ2VtYXIgSm9oYW5zc29uIFMgW21haWx0bzppbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbV0gDQpTZW50OiBGcmlkYXksIEFwcmlsIDA3LCAyMDE3 IDM6NTEgUE0NClRvOiBHZW5neHVlc29uZyAoR2VuZyBYdWVzb25nKTsgQm9iIEJyaXNjb2U7IHRz dndnIElFVEYgbGlzdA0KQ2M6IEluZ2VtYXIgSm9oYW5zc29uIFMNClN1YmplY3Q6IFJFOiBbdHN2 d2ddIHRyYW5zcG9ydCBwcm90b2NvbCBmZWVkYmFjayBvdmVyaGVhZA0KDQpIaQ0KDQpBcyBJIHNl ZSBpdCwgdGhlc2Uga2luZHMgb2YgbWlkZGxlYm94IGdlbmVyYXRlZCBmZWVkYmFjayBpZGVhcyBp cyBwcm9iYWJseSBhIGRpZmZlcmVudCB0b3BpYyBhbmQgSSBiZWxpZXZlIHRoYXQgY2FuIGJlIGdv b2QgdG8ga2VlcCB0aGUgdHdvIHRvcGljcyAobWlkZGxlYm94IGdlbmVyYXRlZCBBQ0tzLCBhbmQg QUNLIHJhdGUgaW4gZW5kIGhvc3RzKSBzZXBhcmF0ZWQsIGJlY2F1c2UgdGhlIG1pZGRsZWJveCBB Q0sgaW52b2x2ZXMgb3RoZXIgY29uY2VybnMgYXJvdW5kIGF1dGhlbnRpY2F0aW9uIGV0LmMuDQpN eSBtYWluIGludGVyZXN0IGZvciBub3cgaXMgaW4gZ2V0dGluZyB0aGUgQUNLIHJhdGUgcmVkdWNl ZCB3aGVyZSBwb3NzaWJsZSBhbmQgYWxzbyBzb21lIGtpbmQgb2YgZG9jdW1lbnRhdGlvbiB0aGF0 IGRlc2NyaWJlcyB3aGF0IGlzIGRvbmUgYWxyZWFkeSB0b2RheS4NCiANCi9JbmdlbWFyDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogR2VuZ3h1ZXNvbmcgKEdlbmcgWHVl c29uZykgW21haWx0bzpnZW5neHVlc29uZ0BodWF3ZWkuY29tXQ0KPiBTZW50OiBkZW4gNyBhcHJp bCAyMDE3IDA5OjEyDQo+IFRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5z c29uQGVyaWNzc29uLmNvbT47IEJvYiANCj4gQnJpc2NvZSA8aWV0ZkBib2JicmlzY29lLm5ldD47 IHRzdndnIElFVEYgbGlzdCA8dHN2d2dAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJFOiBbdHN2d2dd IHRyYW5zcG9ydCBwcm90b2NvbCBmZWVkYmFjayBvdmVyaGVhZA0KPiANCj4gSGkgSW5nZW1hciwN Cj4gDQo+IFRoYW5rIHlvdSBmb3Igb3VyIHJlc3BvbnNlLg0KPiBJdCBpcyByZWFzb25hYmxlIHRv IGZpbmQgYSBwb2ludCB0aGF0IGNhbiByZWR1Y2UgdGhlIEFDSyByYXRlIHdpdGhvdXQgDQo+IGh1 cnRpbmcgaXRzIHBlcmZvcm1hbmNlLCBidXQgSSBhbHNvIHdvbmRlciB0aGF0IHdoZXRoZXIgQUNL IGNhcnJpZXMgDQo+IHRvbyBtdWNoIGluZm9ybWF0aW9uIHdoaWNoIGNhbiBiZSBjb25zaWRlcmVk IHRvIGdpdmUgdG8gdGhlIG1pZGRsZWJveC4NCj4gRm9yIGV4YW1wbGUgdGhlIGNvbmdlc3Rpb24g bm90aWZpY2F0aW9uIGdlbmVyYXRlZCBpbiB0aGUgbWlkZGxlIGJveCANCj4gY2FuIGJlIHNlbnQg dG8gdGhlIHNvdXJjZSBkaXJlY3RseSB3aXRob3V0IGdvaW5nIHRocm91Z2ggdGhlIHJlY2VpdmVy LCANCj4ganVzdCBsaWtlIFFDTiBpbiBMYXllciAyLg0KPiBJIGRvbid0IGtub3cgd2hldGhlciB0 aGlzIGFsc28gYmVsb25ncyB0byB0aGUgIm1pZGRsZWJveCBpbnRlcmFjdGlvbiIgDQo+IHlvdSBo YXZlIG1lbnRpb25lZCA6ICkNCj4gDQo+IA0KPiBCZXN0IFJlZ2FyZHMsDQo+IA0KPiBYdWVzb25n DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJbmdlbWFyIEpvaGFu c3NvbiBTIFttYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6 IEZyaWRheSwgQXByaWwgMDcsIDIwMTcgMjo1MSBQTQ0KPiBUbzogR2VuZ3h1ZXNvbmcgKEdlbmcg WHVlc29uZyk7IEJvYiBCcmlzY29lOyB0c3Z3ZyBJRVRGIGxpc3QNCj4gU3ViamVjdDogUkU6IFt0 c3Z3Z10gdHJhbnNwb3J0IHByb3RvY29sIGZlZWRiYWNrIG92ZXJoZWFkDQo+IA0KPiBIaQ0KPiAN Cj4gU3VyZSwgQUNLcyBjYXJyeSBhIGxvdCBvZiBpbmZvcm1hdGlvbiwgdGhpcyBpcyB0aGUgc3Ry b25nZXN0IGFyZ3VtZW50IA0KPiBhZ2FpbnN0IG1pZGRsZWJveCBpbnRlcmFjdGlvbiBCVFcuDQo+ IEFsc28gdGhlIGludGVudGlvbiB3aXRoIEFDSyByYXRlIHJlZHVjdGlvbiBpcyBub3QgImF0IGFu eSBjb3N0Ii4gT25lIA0KPiBuZWVkIHRvIHN0cmlrZSBhIGJhbGFuY2UgYmV0d2VlbiBBQ0sgcmF0 ZSBhbmQgcGVyZm9ybWFuY2Ugd2hlcmUgdGhlIA0KPiB0b2xlcmFuY2UgYWdhaW5zdCByZWR1Y2Vk IHBlcmZvcm1hbmNlIHNob3VsZCBiZSB2ZXJ5IGxvdy4NCj4gDQo+IC9JbmdlbWFyDQo+IA0KPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogR2VuZ3h1ZXNvbmcgKEdlbmcg WHVlc29uZykgW21haWx0bzpnZW5neHVlc29uZ0BodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IGRlbiA2 IGFwcmlsIDIwMTcgMDM6NDINCj4gPiBUbzogQm9iIEJyaXNjb2UgPGlldGZAYm9iYnJpc2NvZS5u ZXQ+OyBJbmdlbWFyIEpvaGFuc3NvbiBTIA0KPiA+IDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNz c29uLmNvbT47IHRzdndnIElFVEYgbGlzdCA8dHN2d2dAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDog UkU6IFt0c3Z3Z10gdHJhbnNwb3J0IHByb3RvY29sIGZlZWRiYWNrIG92ZXJoZWFkDQo+ID4NCj4g PiBIaSBCb2IsDQo+ID4NCj4gPg0KPiA+IEkgdGhpbmsgaXQgaXMgYW4gaW50ZXJlc3RpbmcgaWRl YSB0byBzb2x2ZSB0aGUgcHJvYmxlbSwgYnV0IEkgd29uZGVyIA0KPiA+IHRoYXQgd2hldGhlciBk b2luZyB0aGlzIHdpbGwgY2F1c2Ugb3RoZXIgcHJvYmxlbSwgYmVjYXVzZSB0aGUgQUNLIA0KPiA+ IGNhcnJpZXMgbW9yZSBpbmZvcm1hdGlvbiB0aGFuIGFycml2YWwgdGltZS4NCj4gPiBGb3IgZXhh bXBsZSBpZiBhbiBBQ0sgd2l0aCBjb25nZXN0aW9uIGluZm9ybWF0aW9uIGFycml2ZXMgbGF0ZXIg dGhhbiANCj4gPiBiZWZvcmUsIHRoZW4gdGhlIGNvbmdlc3Rpb24gcmVzcG9uc2Ugd2lsbCBiZSBk ZWxheWVkIGVpdGhlciwgd2hpY2ggDQo+ID4gbWF5IGRvIGhhcm0gdG8gdGhlIGNvbmdlc3RlZCBu ZXR3b3JrLg0KPiA+DQo+ID4NCj4gPiBCZXN0IFJlZ2FyZHMsDQo+ID4NCj4gPiBYdWVzb25nDQo+ ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHRzdndnIFttYWls dG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJvYiBCcmlzY29lDQo+ID4g U2VudDogRnJpZGF5LCBNYXJjaCAzMSwgMjAxNyA0OjE4IEFNDQo+ID4gVG86IEluZ2VtYXIgSm9o YW5zc29uIFM7IHRzdndnIElFVEYgbGlzdA0KPiA+IFN1YmplY3Q6IFt0c3Z3Z10gdHJhbnNwb3J0 IHByb3RvY29sIGZlZWRiYWNrIG92ZXJoZWFkDQo+ID4NCj4gPiBJbmdlbWFyLCBsaXN0LA0KPiA+ DQo+ID4gSSBzZWVtZWQgdG8gZ2V0IGJsb2NrZWQgZnJvbSB0YWxraW5nIGFmdGVyIEkgd2FzIHRy eWluZyB0byBiZSBwb2xpdGUgDQo+ID4gLSBsZXR0aW5nIHlvdSBmaW5pc2ggeW91ciB0YWxrLi4u DQo+ID4NCj4gPiBZb3UgZGVzY3JpYmVkIG9uZSBwcm9ibGVtOg0KPiA+ICAgKEEpIEluIG1vYmls ZSAoYW5kIG90aGVyIG5ldHdvcmtzKSAgdXBzdHJlYW0gQUNLIGxvYWQgaXMgYSBwcm9ibGVtLg0K PiA+DQo+ID4gVGhlcmUgaXMgYSBjb21wbGVtZW50YXJ5IHByb2JsZW0gdG9vOg0KPiA+IChCKSBD YXBhY2l0eSB2YXJpYXRpb24gaXMgZ2V0dGluZyBodWdlIGFzIHJhZGlvIHdhdmVsZW5ndGggaW5j cmVhc2VzLg0KPiA+IFNvIGl0J3MgdXNlZnVsIGZvciB0aGUgc2VuZGVyIHRvIHdhdGNoIHRoZSB0 aW1pbmcgb2YgdGhlIEFDS3MgdG8gYmUgDQo+ID4gYWJsZSB0byB0cmFjayBjaGFuZ2VzIGluIGNh cGFjaXR5IGFzIGZhc3QgYXMgcG9zc2libGUuIEl0J3MgYWxzbyANCj4gPiB1c2VmdWwgdG8gYmUg YWJsZSB0byB2YXJ5IHRoZSBzcGFjaW5nIGJldHdlZW4gdGhlIHBhY2tldHMgeW91IHNlbmQgDQo+ ID4gdG8gcHJvYmUgZm9yIGluY3JlYXNlcyBpbiBjYXBhY2l0eSBieSB3YXRjaGluZyB0aGUgQUNL IHNwYWNpbmcgaW4gcmVzcG9uc2UuDQo+ID4NCj4gPiBUaGVzZSB0d28gYXJlIGluIHRlbnNpb24g LSAoQSkgd2FudHMgbGVzcyBBQ0tzLCAoQikgd2FudHMgdGhlbSBhbGwuDQo+ID4NCj4gPiBBIHBv c3NpYmxlIHNvbHV0aW9uLCBpcyBhIGRhdGEgc3RydWN0dXJlIGluIGEgc3RyZXRjaCBBQ0sgdG8g YmUgYWJsZSANCj4gPiB0byByZXBvcnQgdGhlIHRpbWUgb2YgYXJyaXZhbCBvZiBhbGwgdGhlIHBy ZXZpb3VzIGRhdGEgcGFja2V0cyAoaWUuDQo+ID4gdGhlIHBhY2tldHMgdGhhdCB0aGUgc3RyZXRj aCBBQ0sgaXMgQUNLaW5nLg0KPiA+DQo+ID4gRXZlbiB0aG8gdGhpcyBpbmZvIHdpbGwgYXJyaXZl IGF0IHRoZSBzZW5kZXIgbGF0ZXIgdGhhbiBpdCB3b3VsZCANCj4gPiBoYXZlIGRvbmUgaWYgdGhl IEFDS3MgaGFkIG5vdCBiZWVuIHN1cHByZXNzZWQsIGFzIGxvbmcgYXMgeW91IGFyZSANCj4gPiBz dGlsbCBnZXR0aW5nIGEgcmVhc29uYWJsZSBudW1iZXIgb2YgQUNLcyBldmVyeSBSVFQsIGl0IHJl c29sdmVzIHRoZSANCj4gPiB0ZW5zaW9uDQo+IGJldHdlZW4gQSBhbmQgQi4NCj4gPg0KPiA+IFRo b3VnaHRzPw0KPiA+IERvZXMgdGhpcyBpZGVhIGFscmVhZHkgZXhpc3Q/DQo+ID4NCj4gPg0KPiA+ DQo+ID4gQm9iDQo+ID4NCj4gPiBQUy4gQXBvbG9naWVzIGZvciBkcm9wcGluZyBhbiBpbm5vdmF0 aXZlIGlkZWEgaW50byBhIHN0YW5kYXJkcyBtZWV0aW5nLg0KPiA+IFRoaXMgcHJvYmFibHkgb3Vn aHQgdG8gYmUgYSByZXNlYXJjaCBwYXBlciBmaXJzdC4NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gX19fX19fDQo+ID4gQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KDQo= From nobody Fri Apr 7 07:47:51 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A70B1287A0 for ; Fri, 7 Apr 2017 07:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_KAM_HTML_FONT_INVALID=0.01, 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 NQTmBi-mdsSI for ; Fri, 7 Apr 2017 07:47:46 -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 0AEA1127333 for ; Fri, 7 Apr 2017 07:47:44 -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=08Y/lxCDZflBgEIO4oPxlYQaVgoIVF/kf56roxBgL4g=; b=82Sy1dJiYQa+6oOu/cvAyPmj8 pJ9Tj6xeBa9lWJgsGmzz7LyciBPu6iKxPOlUBhhB6qnmEyyTek8BOb2RE4ogZS1KYXLjptXIYoErz uBiMirlyfW1SwkTWPb2S9Aw5h5Fck+J3rr6lQsd7s8zbXIv3Q0bXLiAFT6vgk8YuvMr+iEKj2Ifa+ oGGsF4UNZdI5G49DzbntRLbFndAj1jEZqEoAvY2agLqV7guxx+P2zb27FYEUZWSb050V4wuIWdtyt qfX/xDWX/d7SyGTt8wiWlrIcezR+m4HTtC3qaWudMuggPOT061Rj/P3iUV7NzF3kKFa3Dy5bB7Ea0 emACTr1rw==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:48780 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 1cwVAp-0000iV-3Q; Fri, 07 Apr 2017 15:47:40 +0100 To: "Weixinpeng (Jackie)" , "Black, David" , "draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org" References: Cc: tsvwg IETF list From: Bob Briscoe Message-ID: <712bfd85-39e5-bcae-f9b9-0035ef5cf654@bobbriscoe.net> Date: Fri, 7 Apr 2017 15:47:38 +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: multipart/alternative; boundary="------------767D862E8BF4B693388D5004" 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: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:47:50 -0000 This is a multi-part message in MIME format. --------------767D862E8BF4B693388D5004 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Weixinpeng, On 05/04/17 03:45, Weixinpeng (Jackie) wrote: > > Hi Bob, > > Thanks for your comments, and please see inline. > > Regards, > > -Xinpeng > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Monday, April 03, 2017 5:34 AM > *To:* Weixinpeng (Jackie); Black, David; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > *Cc:* tsvwg IETF list > *Subject:* Re: Tunnel Congestion Feedback: (non-)update to RFC6040 > > Weixinpeng, co-authors, and David, > > I had promised a review of the latest TCF draft, but failed to provide > it so far. > I half read it through on Friday, and I will finish and write up my > review this week. > > Here' a quick summary of the main points so far: > > *S.1. Intro: Motivation > *The motivation should also include a heavy load from a much larger > than expected number of responsive flows > > */[Wei] Ok, I will add it./* > > *S.1 Intro: Scope > *I think the draft should say that > * it gives no advice on how to select which tunnel endpoints should be > used in order to manage traffic over a network criss-crossed by > multiple tunnels. > * if a congested node is part of multiple tunnels, and it causes > congestion feedback to multiple traffic management functions at the > ingresses of all the tunnels, the draft gives no advice on how all the > traffic management functions should respond. > * etc. (in my full review, I will provide a full list of subjects that > are out of scope). > > */[Wei] Ok./* > > *S.3. Feedback Models: > *The architecture diagrams and text need to include components that > apply a consistent measurement policy (template records in > IPFIX-speak) at both ingress and egress. This is a key part of > interoperability, which is what the IETF should be all about. Template > records are described later when the mechanism is specified, but they > are not shown in the layout of the components in S.3. > > */[Wei] I will provide a description of Template record in this > section. But I am wondering whether a detailed description of Template > Record as section 6.1 is needed here or not?/* > I suggest that, at this stage in the doc, it would be best not to be specific to one technology (IPFIX) but instead to talk more generally about setting and storing measurement policy (at the decision point and the egress meter). BTW, did you invent the terminology decision point (DP) and action point (AP)? Because there is already IETF terminology for these: * Policy Decision Point (PDP) * Policy Enforcement Point (PEP). See COPS (Common Open Policy Service) Protocol [RFC2748] or terminology for policy-based management [RFC3198] > > *//* > > > > *S.4. Congestion Level Measurement: > *Measurement of ECN has been changed without thinking clearly whether > it needed to change. > > a) Earlier drafts exploited the fact that the inner holds a > "frozen" record of the ECN field at the ingress. So ECN measurements > could be made solely at the egress (comparing the outer with the > inner). In draft-04, ECN codepoints are measured at the ingress and at > the egress, with the ingress sending regular measurement reports to > the egress for comparison. However, it is always safer to measure ECN > solely at the egress, even though a different mechanism has to measure > drops within the tunnel (due to non-ECN nodes, or nodes that have > switched off ECN due to overload, or due to causes of loss other than > congestion, e.g. transmission errors). > - It is always safer to solely measure ECN at the egress, because > it is not vulnerable to ingress-egress measurement packets being dropped. > - Solely measuring ECN at egress is no less precise, because only > the proportion of the different ECN fields is needed, and that stays > approximately the same even if there is drop, assuming drop is not > biased towards certain ECN codepoints (no known mechanism does that). > > b) In draft-04 the faked ECT approach has been left unchanged at > the ingress, but it is no longer used at the egress for detecting > deferred drops (by looking for a Not-ECN inner and a CE outer). Again, > there is nothing wrong with measuring ECN and detecting deferred drops > solely at the egress, even if there are drops within the tunnel. To > measure drops within the tunnel, it is necessary to compare ingress > and egress bytes, but that does not make it wrong to still measure and > compare ECN solely at the egress. > > */[Wei] I agree that solely measuring ECN at egress is enough to get > the proportion of different ECN fields, but the reason why ECN > codepoints are measured both at ingress and egress is to measure the > packets dropped within the tunnel by comparing counts at ingress and > egress. /* > I am not saying you should not also measure drop by measuring total bytes at ingress and egress. However, I am saying it is less robust to have to measure at both ingress and egress, because it involves sending synch / measurement messages from ingress to egress, which can be lost/delayed. So, I would recommend the more robust egress-only method for ECN, and the ingress-egress method only for total drop. The only extra thing you learn by the currently proposed approach is how many of each ECN codepoint were dropped. If you think that's important, argue for it. I don't see any need for it tho. If you insist on keeping the ingress-egress approach, why do you need the faked ECN text? > *//* > > > > *S.4. Congestion Level Measurement: Units > *Throughout measurement involves counting packets. However, it should > count the bytes in packets with each type of marking, not just the > number of packets. See RFC7141 section 2.3 > . Although the > recommendation in that RFC is about what a /transport/ should measure > when responding to congestion, logically it should apply in this case > when a traffic management function is responding in place of a > transport. RFC7141 also gives recommendations on which headers to count. > > */[Wei] Ok, it’s a good suggestion./* > > > > > I shall add to this review later in the week. > > One question for Weixinpeng: Have you implemented this mechanism? > > */[Wei] Currently, we only implement this mechanism in a simulation > environment./* > I suspected as much, because the lack of detail in some places implies it is a bit theoretical. I would encourage you to implement. Bob > > > > Bob > > On 01/11/16 01:49, Weixinpeng (Jackie) wrote: > > Hi Bob and David, > > Because the deadline has passed, I will update it as part of > post-WGLC update. Thanks. > > Regards, > > -Xinpeng (Jackie) > > *From:*Black, David [mailto:David.Black@dell.com] > *Sent:* Tuesday, November 01, 2016 12:14 AM > *To:* Bob Briscoe; Weixinpeng (Jackie); > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list; Black, David > *Subject:* RE: Tunnel Congestion Feedback: (non-)update to RFC6040 > > > I assume you will update the TCF draft today before the deadline. > > (As draft shepherd) That’s not really necessary - the TCF draft is > in WGLC, so this change can be done as part of a post-WGLC update. > > Thanks, --David > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Monday, October 31, 2016 11:22 AM > *To:* Weixinpeng (Jackie); Black, David; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list > *Subject:* Re: Tunnel Congestion Feedback: (non-)update to RFC6040 > > Xinpeng, > > I agree that TCF does not update RFC6040 (as I said). > > But David is right that the TCF draft itself needs to be updated > to say that it modifies the behaviour of a RFC6040 egress so as to > issue or log any warnings when it receives an ECT(0) or CE outer > with a Not-ECT inner. > > I assume you will update the TCF draft today before the deadline. > > Cheers > > Bob > > On 31/10/16 02:38, Weixinpeng (Jackie) wrote: > > Hi David, Bob, > > I agree that the behavior defined in RFC6040 doesn’t to be > updated due to the TCF draft, because what’s defined in RFC > 6040 has a broader usage and not just for TCF. > > I think David has provided a good suggestion below. Thanks. > > Regards, > > -Xinpeng (Jackie) > > *From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of > *Black, David > *Sent:* Saturday, October 29, 2016 10:28 AM > *To:* Bob Briscoe; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list > *Subject:* Re: [tsvwg] Tunnel Congestion Feedback: > (non-)update to RFC6040 > > Bob, > > I think you’ve found something. The TCF draft currently uses > RFC 6040 behavior by reference: > > when decapsulating packets at egress, > > RFC6040 defined decapsulation behavior is used, and according to > > RFC6040, the packets marked as CE|N-ECT will be dropped by > egress. > > I think this needs to be slightly revised to say that CE|N-ECT > is dropped without any other > > action, and all other behavior is as per RFC 6040, as CE|N-ECT > is expected at a TCF egress and > > hence the logging and alarm behavior for that combination in > RFC 6040 is inappropriate. > > Once that’s done, I think your reasoning in the following > sentence becomes correct: > > If the network is not valid, these combination could become > visible to a 6040-decap, > > which would then (correctly) log warnings that it was seeing > invalid codepoint combinations. > > Thanks, --David (as draft shepherd) > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Thursday, October 27, 2016 4:39 PM > *To:* > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > ; > Black, David > *Cc:* tsvwg IETF list > *Subject:* Tunnel Congestion Feedback: (non-)update to RFC6040 > > Tunnel congestion feedback authors, David as shepherd, > > FYI. No action needed. > > This email documents an argument with myself. After a few > seconds, I agreed with myself that one of me was wrong. I > thought I had better raise this on the list, to check that > others agree with both of me. If you wish to argue with just > one of me, please bear in mind that we both have the same > email address (and anyway, we both agree so an argument with > one is an argument with all). > _________________________ > > Figure 4 of RFC6040 specifies which ECN codepoint a decap must > forward, for each combination of arriving inner (row) and > outer (column). > > > +---------+------------------------------------------------+ > > |Arriving | Arriving Outer > Header | > > | Inner > +---------+------------+------------+------------+ > > | Header | Not-ECT | ECT(0) | ECT(1) > | CE | > > > +---------+---------+------------+------------+------------+ > > | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| > (!!!)| > > | ECT(0) | ECT(0) | ECT(0) | ECT(1) > | CE | > > | ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) > | CE | > > | CE | CE | CE | > CE(!!!)| CE | > > > +---------+---------+------------+------------+------------+ > > RFC6040 goes on to say: > > [...] These currently unused (CU) > combinations are > > indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' > means the > > combination is CU and always potentially dangerous, > while '(!)' > > means it is CU and possibly dangerous. In these cases, > > particularly the more dangerous ones, the decapsulator > SHOULD log > > the event and MAY also raise an alarm. > > TCF uses the following combinations of inner : outer > Not-ECT : ECT(0) > Not-ECT : CE > > For a moment, I thought we would have to update RFC6040 to say > that TCF makes these combinations no longer CU, so they are > now valid, not dangerous, and they no longer need to be > logged. This would have meant that Tunnel Congestion Feedback > (TCF) (informational) would have to update RFC6040 (proposed > standard). > > Here's why I was wrong. These two combinations are certainly > valid at a TCF decap. But there is still no way that, in a > valid network, they would arrive at any RFC6040 (non-TCF) decap. > > One might think that this combination could arrive at a > 6040-decap if there was a tunnel inside a tunnel, as follows > > TCF-encap ---> 6040-decap ---> TCF-decap > > However, that's not a valid configuration. The following > tunnel-in-tunnel would be valid: > > TCF-encap ---> 6040-encap ---> 6040-decap ---> TCF-decap > > ...then, the above two "CU" combinations would be buried > within a double inner, so only the TCF decap would see them, > not the 6040-decap. > > So, TCF does not need to update RFC6040. Because, in a valid > network, TCF will be hidden from any 6040-decap. If the > network is not valid, these combination could become visible > to a 6040-decap, which would then (correctly) log warnings > that it was seeing invalid codepoint combinations. > > I just thought you'd like to know... no action required. > > > > Bob > > -- > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------767D862E8BF4B693388D5004 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Weixinpeng,

On 05/04/17 03:45, Weixinpeng (Jackie) wrote:

Hi Bob,

Thanks for your comments, and please see inline.

Regards,

-Xinpeng

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Monday, April 03, 2017 5:34 AM
To: Weixinpeng (Jackie); Black, David; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Weixinpeng, co-authors,  and David,

I had promised a review of the latest TCF draft, but failed to provide it so far.
I half read it through on Friday, and I will finish and write up my review this week.

Here' a quick summary of the main points so far:

S.1. Intro: Motivation
The motivation should also include a heavy load from a much larger than expected number of responsive flows

[Wei] Ok, I will add it.

S.1 Intro: Scope
I think the draft should say that
* it gives no advice on how to select which tunnel endpoints should be used in order to manage traffic over a network criss-crossed by multiple tunnels.
* if a congested node is part of multiple tunnels, and it causes congestion feedback to multiple traffic management functions at the ingresses of all the tunnels, the draft gives no advice on how all the traffic management functions should respond.
* etc. (in my full review, I will provide a full list of subjects that are out of scope).

[Wei] Ok.

S.3. Feedback Models:
The architecture diagrams and text need to include components that apply a consistent measurement policy (template records in IPFIX-speak) at both ingress and egress. This is a key part of interoperability, which is what the IETF should be all about. Template records are described later when the mechanism is specified, but they are not shown in the layout of the components in S.3.

[Wei] I will provide a description of Template record in this section. But I am wondering whether a detailed description of Template Record as section 6.1 is needed here or not?

I suggest that, at this stage in the doc, it would be best not to be specific to one technology (IPFIX) but instead to talk more generally about setting and storing measurement policy (at the decision point and the egress meter).

BTW, did you invent the terminology decision point (DP) and action point (AP)? Because there is already IETF terminology for these:
* Policy Decision Point (PDP)
* Policy Enforcement Point (PEP).

See COPS (Common Open Policy Service) Protocol [RFC2748] or terminology for policy-based management [RFC3198]



S.4. Congestion Level Measurement:
Measurement of ECN has been changed without thinking clearly whether it needed to change.

    a) Earlier drafts exploited the fact that the inner holds a "frozen" record of the ECN field at the ingress. So ECN measurements could be made solely at the egress (comparing the outer with the inner). In draft-04, ECN codepoints are measured at the ingress and at the egress, with the ingress sending regular measurement reports to the egress for comparison. However, it is always safer to measure ECN solely at the egress, even though a different mechanism has to measure drops within the tunnel (due to non-ECN nodes, or nodes that have switched off ECN due to overload, or due to causes of loss other than congestion, e.g. transmission errors).
     - It is always safer to solely measure ECN at the egress, because it is not vulnerable to ingress-egress measurement packets being dropped.
     - Solely measuring ECN at egress is no less precise, because only the proportion of the different ECN fields is needed, and that stays approximately the same even if there is drop, assuming drop is not biased towards certain ECN codepoints (no known mechanism does that).

    b) In draft-04 the faked ECT approach has been left unchanged at the ingress, but it is no longer used at the egress for detecting deferred drops (by looking for a Not-ECN inner and a CE outer). Again, there is nothing wrong with measuring ECN and detecting deferred drops solely at the egress, even if there are drops within the tunnel. To measure drops within the tunnel, it is necessary to compare ingress and egress bytes, but that does not make it wrong to still measure and compare ECN solely at the egress.

[Wei] I agree that solely measuring ECN at egress is enough to get the proportion of different ECN fields, but the reason why ECN codepoints are measured both at ingress and egress is to measure the packets dropped within the tunnel by comparing counts at ingress and egress.

I am not saying you should not also measure drop by measuring total bytes at ingress and egress.

However, I am saying it is less robust to have to measure at both ingress and egress, because it involves sending synch / measurement messages from ingress to egress, which can be lost/delayed.
So, I would recommend the more robust egress-only method for ECN, and the ingress-egress method only for total drop.

The only extra thing you learn by the currently proposed approach is how many of each ECN codepoint were dropped. If you think that's important, argue for it. I don't see any need for it tho.

If you insist on keeping the ingress-egress approach, why do you need the faked ECN text?



S.4. Congestion Level Measurement: Units
Throughout measurement involves counting packets. However, it should count the bytes in packets with each type of marking, not just the number of packets. See RFC7141 section 2.3. Although the recommendation in that RFC is about what a /transport/ should measure when responding to congestion, logically it should apply in this case when a traffic management function is responding in place of a transport. RFC7141 also gives recommendations on which headers to count.

[Wei] Ok, it’s a good suggestion.




I shall add to this review later in the week.

One question for Weixinpeng: Have you implemented this mechanism?

[Wei] Currently, we only implement this mechanism in a simulation environment.

I suspected as much, because the lack of detail in some places implies it is a bit theoretical.
I would encourage you to implement.



Bob



Bob

On 01/11/16 01:49, Weixinpeng (Jackie) wrote:

Hi Bob and David,

Because the deadline has passed, I will update it as part of post-WGLC update. Thanks.

 

Regards,

-Xinpeng (Jackie)

 

From: Black, David [mailto:David.Black@dell.com]
Sent: Tuesday, November 01, 2016 12:14 AM
To: Bob Briscoe; Weixinpeng (Jackie); draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list; Black, David
Subject: RE: Tunnel Congestion Feedback: (non-)update to RFC6040

 

> I assume you will update the TCF draft today before the deadline.

 

(As draft shepherd) That’s not really necessary - the TCF draft is in WGLC, so this change can be done as part of a post-WGLC update.

 

Thanks, --David

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Monday, October 31, 2016 11:22 AM
To: Weixinpeng (Jackie); Black, David; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Xinpeng,

I agree that TCF does not update RFC6040 (as I said).

But David is right that the TCF draft itself needs to be updated to say that it modifies the behaviour of a RFC6040 egress so as to issue or log any warnings when it receives an ECT(0) or CE outer with a Not-ECT inner.

I assume you will update the TCF draft today before the deadline.

Cheers

Bob

On 31/10/16 02:38, Weixinpeng (Jackie) wrote:

Hi David, Bob,

I agree that the behavior defined in RFC6040 doesn’t to be updated due to the TCF draft, because what’s defined in RFC 6040 has a broader usage and not just for TCF.

I think David has provided a good suggestion below. Thanks.

 

Regards,

-Xinpeng (Jackie)

 

From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David
Sent: Saturday, October 29, 2016 10:28 AM
To: Bob Briscoe; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040

 

Bob,

 

I think you’ve found something.  The TCF draft currently uses RFC 6040 behavior by reference:

 

   when decapsulating packets at egress,

   RFC6040 defined decapsulation behavior is used, and according to

   RFC6040, the packets marked as CE|N-ECT will be dropped by egress.

 

I think this needs to be slightly revised to say that CE|N-ECT is dropped without any other

action, and all other behavior is as per RFC 6040, as CE|N-ECT is expected at a TCF egress and

hence the logging and alarm behavior for that combination in RFC 6040 is inappropriate.

 

Once that’s done, I think your reasoning in the following sentence becomes correct:

 

If the network is not valid, these combination could become visible to a 6040-decap,

which would then (correctly) log warnings that it was seeing invalid codepoint combinations.

Thanks, --David (as draft shepherd)

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Thursday, October 27, 2016 4:39 PM
To: draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org; Black, David
Cc: tsvwg IETF list
Subject: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Tunnel congestion feedback authors, David as shepherd,

FYI. No action needed.

This email documents an argument with myself. After a few seconds, I agreed with myself that one of me was wrong. I thought I had better raise this on the list, to check that others agree with both of me. If you wish to argue with just one of me, please bear in mind that we both have the same email address (and anyway, we both agree so an argument with one is an argument with all).
_________________________

Figure 4 of RFC6040 specifies which ECN codepoint a decap must forward, for each combination of arriving inner (row) and outer (column).

            +---------+------------------------------------------------+
            |Arriving |            Arriving Outer Header               |
            |   Inner +---------+------------+------------+------------+
            |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
            +---------+---------+------------+------------+------------+
            | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
            |  ECT(0) |  ECT(0) | ECT(0)     | ECT(1)     |     CE     |
            |  ECT(1) |  ECT(1) | ECT(1) (!) | ECT(1)     |     CE     |
            |    CE   |      CE |     CE     |     CE(!!!)|     CE     |
            +---------+---------+------------+------------+------------+

RFC6040 goes on to say:

                      [...] These currently unused (CU) combinations are
      indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the
      combination is CU and always potentially dangerous, while '(!)'
      means it is CU and possibly dangerous.  In these cases,
      particularly the more dangerous ones, the decapsulator SHOULD log
      the event and MAY also raise an alarm.
 

TCF uses the following combinations of inner : outer
    Not-ECT : ECT(0)
    Not-ECT : CE

For a moment, I thought we would have to update RFC6040 to say that TCF makes these combinations no longer CU, so they are now valid, not dangerous, and they no longer need to be logged. This would have meant that Tunnel Congestion Feedback (TCF) (informational) would have to update RFC6040 (proposed standard).

Here's why I was wrong. These two combinations are certainly valid at a TCF decap. But there is still no way that, in a valid network, they would arrive at any RFC6040 (non-TCF) decap.

One might think that this combination could arrive at a 6040-decap if there was a tunnel inside a tunnel, as follows

  TCF-encap                 ---> 6040-decap ---> TCF-decap

However, that's not a valid configuration. The following tunnel-in-tunnel would be valid:

  TCF-encap ---> 6040-encap ---> 6040-decap ---> TCF-decap

...then, the above two "CU" combinations would be buried within a double inner, so only the TCF decap would see them, not the 6040-decap.

So, TCF does not need to update RFC6040. Because, in a valid network, TCF will be hidden from any 6040-decap. If the network is not valid, these combination could become visible to a 6040-decap, which would then (correctly) log warnings that it was seeing invalid codepoint combinations.

I just thought you'd like to know... no action required.



Bob

-- 

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

 

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



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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------767D862E8BF4B693388D5004-- From nobody Fri Apr 7 08:39:35 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DFD127444 for ; Fri, 7 Apr 2017 08:39:29 -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=unavailable 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 gf5cYN2hWmzp for ; Fri, 7 Apr 2017 08:39:26 -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 E8912127B57 for ; Fri, 7 Apr 2017 08:39:25 -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=JA8uczlpP3gpadYzRA/KYEICCS9HJMtaLs4j6/q6uKM=; b=d7ZGhPHYxYdqGQIkE0p8DoO31q 2iuMJK50+pGiWv4CUyubSp26RERtGcA7yvipX/oAq1pkepnBrv8sb3UGHdUMUdp6EdSCHyxrSxBlw X5wknrAH7yuq3dwBoaWkV1HKPauqJs1pLoNUY4wYsBsKh5WrUD/4w0iwB4IdqxaCD+562UV0tyLh7 cEiuL8RGEQwdKrNUK9m0qyBXx4jLe/DqqqiMF5tkJhFsLOjjHEc8gCpa6dZlGX3ogVT4m4P5Q7Wcv El7hTuVZmx/38KWl8wjYJ8M9YQw8fLsJf2IOapr4siG94RXbCtggcNGM66uPbiwFiTAdvLC3SWFCD ajTa0S1w==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:48916 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 1cwVyt-0007K6-Ih; Fri, 07 Apr 2017 16:39:23 +0100 To: Michael Welzl , "Gengxuesong (Geng Xuesong)" References: <79981E87-BB9E-455B-9D82-09F14C48B2FB@ifi.uio.no> Cc: Ingemar Johansson S , iccrg@irtf.org, tsvwg IETF list From: Bob Briscoe Message-ID: Date: Fri, 7 Apr 2017 16:39:22 +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: <79981E87-BB9E-455B-9D82-09F14C48B2FB@ifi.uio.no> 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: [tsvwg] [iccrg] transport protocol feedback overhead X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:39:29 -0000 Michael, 1/ Real problem? I agree that we should first establish whether ACK load is a problem. I was responding to Ingemar assuming he believed this was true, given that was his presentation. I can understand that ACKs are not so much a problem because of the bits they carry. More because they consume transmission opportunities on wireless links. Also, because they consume processor cycles and interrupts on hosts (which is why ACK thinning is done in DCs). 2/ tsvwg/iccrg? Actually, as Ingemar mentioned in his slides, this is potentially something to consider for AccECN, which is a WG doc in tcpm now. It would at least be useful to consider how this timing info might be added later to the same AccECN TCP option. I mean, perhaps introduce a placeholder so that a further draft can be written later to add timing info to the same TCP option. Note: AccECN is solely about ECN, whereas arrival timing info can be relevant irrespective of ECN support, so they might not fit well. However, in one respect the two functions fit together nicely because like the AccECN option, timing info is truly optional - feedback can still work (minimally) if the TCP option does not traverse a path. Amortizing both into one option should help deployment of both. 3/ Feedback delay To answer Xuesong's initial point, I only proposed including timing info in ACKs /if/ the ACK rate needed to be reduced. Of course missing out some ACKs introduces a delay before another ACK arrives, and delays any timing info it contains. But if ACKs are going to be thinned/stretched, adding timing info about intervening arrivals is better than not adding it. If there are, say, W=100 packets in a window,: * ACKing 1 in 2 packets causes the worst total feedback delay to be 101% of an RTT. * ACKing 1 in 8 packets causes the worst total feedback delay to be 107% of an RTT. More generally, * ACKing 1 in d packets causes the worst total feedback delay to be 1+(d-1)/W of an RTT. Given ACK rate is generally only a problem when W is large, the extra delay could be of concern, but it should not be significant. 4/ Middle-to-sender feedback Re. Xuesong's second point,... been there, doesn't work. See https://www.ietf.org/mail-archive/web/tsvwg/current/msg10843.html This mode of feedback appeared on the tsvwg list in 2006, 2011, 2017... On this basis it should come up again in about 2023 :) Bob On 07/04/17 08:44, Michael Welzl wrote: > All, > > I'm cc'ing ICCRG because these are truly research musings IMO. Maybe, if folks agree, we can truly move this thread and drop the tsvwg list from recipients? > > A thought: > One reason we didn't continue our own work on this (the master thesis I mentioned previously) was that it wasn't 100% clear to us whether this is a *real* problem - is it a problem worth solving? How often does it occur? How problematic is it? > > I think Ingemar made a good point in his presentation about the problem being real. Still, often ACKs are mixed with payload traffic. Consider the following scenario: > Say, I have a thin uplink. > In parallel, I download a file, and I upload a file (just as a simple model). > Both take long, there is congestion, packets are dropped. > > => should the rate of outgoing payload be reduced, or should the ACK rate be reduced? Or both? > > Given that ACKs tend to be smaller, losing too many ACKs could be quite harmful, and the Internet has survived very long without ACK rate reduction, I'd tend to think the payload should be the first to react. > So then, a scheme that changes the ACK rate could try to figure out if it truly was the ACKs that created congestion. > > This could be done by checking the impact of one's actions with some heuristics. For example: if I increase the rate, does delay increase with it, and does it decrease again if I decrease the rate? > What if, different from a "normal" congestion control reaction where senders try to back off immediately upon any form of congestion indication, ACK rate reduction would do such tests for 2-3 round trips before actually backing off? This would avoid a situation where, in my example, both the download and the upload traffic would back off together (which might be overdoing it). > > Just some thoughts - as I said, research ideas. > > Cheers, > Michael > > > >> On 07 Apr 2017, at 09:12, Gengxuesong (Geng Xuesong) wrote: >> >> Hi Ingemar, >> >> Thank you for our response. >> It is reasonable to find a point that can reduce the ACK rate without hurting its performance, but I also wonder that whether ACK carries too much information which can be considered to give to the middlebox. >> For example the congestion notification generated in the middle box can be sent to the source directly without going through the receiver, just like QCN in Layer 2. >> I don't know whether this also belongs to the "middlebox interaction" you have mentioned : ) >> >> >> Best Regards, >> >> Xuesong >> >> -----Original Message----- >> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] >> Sent: Friday, April 07, 2017 2:51 PM >> To: Gengxuesong (Geng Xuesong); Bob Briscoe; tsvwg IETF list >> Subject: RE: [tsvwg] transport protocol feedback overhead >> >> Hi >> >> Sure, ACKs carry a lot of information, this is the strongest argument against middlebox interaction BTW. >> Also the intention with ACK rate reduction is not "at any cost". One need to strike a balance between ACK rate and performance where the tolerance against reduced performance should be very low. >> >> /Ingemar >> >>> -----Original Message----- >>> From: Gengxuesong (Geng Xuesong) [mailto:gengxuesong@huawei.com] >>> Sent: den 6 april 2017 03:42 >>> To: Bob Briscoe ; Ingemar Johansson S >>> ; tsvwg IETF list >>> Subject: RE: [tsvwg] transport protocol feedback overhead >>> >>> Hi Bob, >>> >>> >>> I think it is an interesting idea to solve the problem, but I wonder >>> that whether doing this will cause other problem, because the ACK >>> carries more information than arrival time. >>> For example if an ACK with congestion information arrives later than >>> before, then the congestion response will be delayed either, which may >>> do harm to the congested network. >>> >>> >>> Best Regards, >>> >>> Xuesong >>> >>> -----Original Message----- >>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Bob Briscoe >>> Sent: Friday, March 31, 2017 4:18 AM >>> To: Ingemar Johansson S; tsvwg IETF list >>> Subject: [tsvwg] transport protocol feedback overhead >>> >>> Ingemar, list, >>> >>> I seemed to get blocked from talking after I was trying to be polite - >>> letting you finish your talk... >>> >>> You described one problem: >>> (A) In mobile (and other networks) upstream ACK load is a problem. >>> >>> There is a complementary problem too: >>> (B) Capacity variation is getting huge as radio wavelength increases. >>> So it's useful for the sender to watch the timing of the ACKs to be >>> able to track changes in capacity as fast as possible. It's also >>> useful to be able to vary the spacing between the packets you send to >>> probe for increases in capacity by watching the ACK spacing in response. >>> >>> These two are in tension - (A) wants less ACKs, (B) wants them all. >>> >>> A possible solution, is a data structure in a stretch ACK to be able >>> to report the time of arrival of all the previous data packets (ie. >>> the packets that the stretch ACK is ACKing. >>> >>> Even tho this info will arrive at the sender later than it would have >>> done if the ACKs had not been suppressed, as long as you are still >>> getting a reasonable number of ACKs every RTT, it resolves the tension between A and B. >>> >>> Thoughts? >>> Does this idea already exist? >>> >>> >>> >>> Bob >>> >>> PS. Apologies for dropping an innovative idea into a standards meeting. >>> This probably ought to be a research paper first. >>> >>> >>> -- >>> __________________________________________________________ >>> ______ >>> Bob Briscoe http://bobbriscoe.net/ > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Apr 7 08:43:55 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43AE12773A for ; Fri, 7 Apr 2017 08:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMqd06fxygkK for ; Fri, 7 Apr 2017 08:43:52 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0192C1293D6 for ; Fri, 7 Apr 2017 08:43:51 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id y18so44870995itc.1 for ; Fri, 07 Apr 2017 08:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=EVgLnS3FoWRxSUVFiIKlAfVkLFbQHCocd+G2yHqT2T0=; b=cQwMXuQZZEpW9MrbLfp17nAttjm+dWdnarU59NHLuNIy04auSimjzLFGNoWePwNsBi Nz7mT2u86+qWClIS9hWZiBWjUYUq5aaEm8406YG523BVwgNKYe3aPu2akrFUozl3o3Rl C5b7PIR/EmufUPaKoBOl+f3j//7ud13FZwOd/vlsSo9TLRGtDnjynVeatIJVlQ8hwX+E esZ1/m5wzoJNDso8S+kGIC13zzg2P7JSZdge2Q6bAmEnZOncTa3zYk+KvnKenp7a6hr1 CL2jyHGqTLeeU50s3OlSJQXxriL+heMIgcePCY0kCWOMA0HuNlRKLhNIk/nAe8tLJ0gx ozDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=EVgLnS3FoWRxSUVFiIKlAfVkLFbQHCocd+G2yHqT2T0=; b=XOGxTr02svndtzMcPahxbTgbEVaKMHapX/+rKubUgjnTH12YmJ0BMHPGHPWRw3ESSe eU6TrmcGhm7ikhDb0nXQ3jlJhJ0+bdguwUnd6LYmOLMWok8lmnsuCfGiv3eYrkA8hZgL ltSXN8yYy3eht5boocKm5ZVjA5+gvG7vVPRQI9poblLDJN/Xz8GaK6DaEb4vkmlWf7mp 5GadiNFAVHwYMg1CCLT3mr8nbc3Ba8GEYxQmqGKNTmfj0gASIwj2dAg3D/f2lRY8wDfV Sm1Dp67ezuJQLQj/V44NhlW5NNU1oytlZrlA03qtVPQPS9aQxL9QfkSpmdJnhdZqN6n8 XufA== X-Gm-Message-State: AFeK/H0lYeFdVEUIlks/0o33N0F7/DC7wb6aXV5f9xYaQsboglfuU+sHJ7AfRYs8vxMVvg== X-Received: by 10.36.41.3 with SMTP id p3mr31683738itp.71.1491579830871; Fri, 07 Apr 2017 08:43:50 -0700 (PDT) Received: from [192.168.1.104] (cpe-76-188-215-129.neo.res.rr.com. [76.188.215.129]) by smtp.gmail.com with ESMTPSA id p6sm2558683iof.12.2017.04.07.08.43.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 08:43:50 -0700 (PDT) To: Michael Welzl , "De Schepper, Koen (Nokia - BE/Antwerp)" References: <138206D2-85DF-4CAC-B196-7FC59304546A@ifi.uio.no> <372AFF1E-A1B4-4710-9EA5-25DBD74ED2FA@ifi.uio.no> Cc: tsvwg IETF list From: Wesley Eddy Message-ID: <790d7485-0540-48cf-0b5e-e6eb4c83b2e8@mti-systems.com> Date: Fri, 7 Apr 2017 11:43:40 -0400 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: <372AFF1E-A1B4-4710-9EA5-25DBD74ED2FA@ifi.uio.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] confirming adoption of L4S drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:43:54 -0000 Hi Michael, as co-chair shepherding these documents in TSVWG, I want to make sure if we're okay to proceed. You're obviously right that the corresponding scalable end-host behavior is work that needs to be done, and I agree that where that work is done in terms of WG, RG, etc. will need to be figured out, but I see those more as action items for follow-up in parallel, rather than roadblocks to proceeding with adopting work on the in-network behavior. I think the ADs will make sure this works out (and if it's not working out in time, they could kill off the L4S work at some point). I think your concern about defining the in-network behavior and codepoint without an end-host algorithm is something we should track as that work proceeds in parallel, and evaluate when we think L4S is mature enough for a last call. Certainly nobody would want to just go ahead and publish RFCs here, if it turns out to that there isn't promise of mature end-host algorithm work to go with it! I think WG participants, ADs, chairs, etc, can evaluate this as the work proceeds, but it shouldn't gate adoption. In my personal opinion, the ability to support DCTCP in private/managed networks is probably enough motivation alone, and that something for Internet end-hosts will obviously make it even better, but is just an expansion of the use cases rather than absolutely required to see value out of L4S. Would you agree that we can assume end-host algorithm research will keep proceeding (somewhere to be defined) in parallel, and that TSVWG should be doing these Experimental+Informational in-network pieces in the meantime? From nobody Fri Apr 7 17:35:44 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554BA127978; Fri, 7 Apr 2017 17:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.496 X-Spam-Level: X-Spam-Status: No, score=-5.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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=0JYDn0Ch; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=oH3G/0PO 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 cHyKN2A30gZR; Fri, 7 Apr 2017 17:35:21 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B48128BE1; Fri, 7 Apr 2017 17:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1491611450; x=1523147450; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OfXPGk+4TNoe9dRoEoODY7k9gsLmpWbwc7LvroNjhXs=; b=0JYDn0ChLir8nEGeTmsu918m68pMoH0aOm5WPmz+mW7Nd/7NqxSZfebX mXhv2bwg+gq7hTfsIHubuBVjIW5tAz0pPakQ3z2Eg99Vx2/3GFGZHFL7v 1y1k9YaeKIXfMxXStyV70hw5wWFkWS7Vvt9fwXAVsHIrbUCFqzkCP56GM k=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 19:30:48 -0500 From: "Black, David" Cc: TCP Prague List , tsvwg IETF list , "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2017 06:28:11 +0600 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v380ZApO026744 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 20:35:10 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v380ZApO026744 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1491611710; bh=Tm2zLpDx6g96+xQi+W8WcVSen3k=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=oH3G/0POCTPwwFeIwuNp9oGdpqoqBZ124NOP/tBlxhgUoGwjndOw60dUaDRWmBilP cDAjVpJctPKbflDvgUYdiPIfvw4zpbSlD+ABvOyZELOL1u2NHkphDY8KNIL6PuCd/C hg2+U9UIKms93U3wOvX5O0fyp36lX+4qPzrphoyw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v380ZApO026744 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Fri, 7 Apr 2017 20:34:31 -0400 Received: from MXHUB315.corp.emc.com (MXHUB315.corp.emc.com [10.146.3.93]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v380YsQu018079 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 7 Apr 2017 20:34:54 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB315.corp.emc.com ([10.146.3.93]) with mapi id 14.03.0266.001; Fri, 7 Apr 2017 20:34:54 -0400 To: Bob Briscoe Thread-Topic: [tcpPrague] Treatment of ECT(1) pre L4S Thread-Index: AdHkCFgirgx3HT3iRm+SY64tLECkYTEduXEAAd+VebA= Date: Sat, 8 Apr 2017 00:34:53 +0000 Message-ID: References: <20160722110102.5697618.36413.99476@sandvine.com> <449c5fea-32ba-bf3f-bb7b-8f7b48b22f4f@bobbriscoe.net> In-Reply-To: <449c5fea-32ba-bf3f-bb7b-8f7b48b22f4f@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: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] [tcpPrague] Treatment of ECT(1) pre L4S X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 00:35:28 -0000 This message is written as the author of the ECN Experimentation draft, not= as a WG chair. This topic was discussed in Chicago with a request to me as author of the E= CN experimentation draft to check that both options below are permitted. T= hese options are for network nodes that do not implement L4S dual queues bu= t for which there is a desire to do something reasonable with ECT(1) in lig= ht of L4S usage. The crucial ECN experimentation draft text is in Section = 4.2 (https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimenta= tion#section-4.2): ----------------------------------- 4.2. ECT Differences Section 5 of RFC 3168 specifies that: Routers treat the ECT(0) and ECT(1) codepoints as equivalent. In support of ECT Differences experimentation, this memo updates RFC 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints differently, provided that the changes from RFC 3168 are documented in an Experimental RFC. The specific change to RFC 3168 is to insert the words "unless otherwise specified by an Experimental RFC" at the end of the above sentence. ----------------------------------- The ecn-l4s-id is intended to become an Experimental RFC, and hence would b= enefit from the added "unless otherwise specified by an Experimental RFC" t= ext. That added text imposes no limits on the scope of "otherwise specifie= d" - we are relying on the combined good sense of the draft authors, WG mem= bers, the IETF community and the IESG to ensure that nothing horrendous in = this area makes it into an Experimental RFC ;-). I see no problem with an Experimental RFC for L4S specifying not only exper= imental changes to network nodes that fully participate in the experiment (= dual queues) but also specifying experimental changes for network nodes tha= t only partially participate - the options below are for network nodes that= only partially participate. Thanks, --David > -----Original Message----- > From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Bob > Briscoe > Sent: Wednesday, March 29, 2017 3:26 AM > To: Dave Dolson > Cc: TCP Prague List ; tsvwg IETF list > Subject: Re: [tcpPrague] Treatment of ECT(1) pre L4S >=20 > Dave, >=20 > I've cc'd this to tsvwg. > We will put text in the ecn-l4s-id draft unless there is not consensus > from others about this yet. >=20 > I agree with Koen now. >=20 > To be clear, I believe that a classic AQM supporting only RFC3168 > (Classic) ECN: > * should never alter the ECT(1) field > * should be configurable between the following two behaviours: > - [default] treat ECT(1) as if it does not support ECN, so drop where > it would have marked CE > - treat ECT(1) as if it is ECT(0) >=20 > I am less keen than Koen on adding the latter option - I prefer clear > simple advice to avoid confusion. > So IMO, if you don't want another config knob, it would be OK to just > support the default. >=20 > Ideally, once the DualQ specs are approved, the AQM should also be > upgraded to support Dual Qs and the squared relationship between them. >=20 > Sorry it's taken so long to confirm this. >=20 > Cheers >=20 >=20 >=20 > Bob >=20 > On 22/07/16 12:01, Dave Dolson wrote: > > If an operator were to deploy ECN today, pre L4S, what should be the > treatment of ECT(1)? > > > > I believe, from a discussion with Koen, that the safest approach is for= a pre- > L4S implementation to signal congestion to ECT(1) by dropping. If ECT(1) > were treated the same as ECT(0) then new experimental TCP-Prague flows > would out-compete any ECT(0) traffic. > > > > Is this agreed? If so, should it be recommended somewhere? > > > > Note that I got mixed answers on this from other IETF folks, so I think= it is > worth sorting out. > > > > > > -Dave > > > > > > > > _______________________________________________ > > tcpPrague mailing list > > tcpPrague@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpprague >=20 > -- > __________________________________________________________ > ______ > Bob Briscoe http://bobbriscoe.net/ >=20 > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague From nobody Fri Apr 7 18:11:52 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D4C127275 for ; Fri, 7 Apr 2017 18:11:51 -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=pAeq4QpT; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=vBI7wAtt 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 OzoGE436x-N4 for ; Fri, 7 Apr 2017 18:11:48 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 0937B126C2F for ; Fri, 7 Apr 2017 18:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1491613908; x=1523149908; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dLbZx+C19oiwGWenA18iVNYixIIJdx82mAjM2rIONng=; b=pAeq4QpTyt1Y/wvpDl6P6D0GmG/L84zfDjzg/JK2NWKkMfSavQcE++AT l5RlT7r4NlH+socsYP2GoEFQujqWg8A+7gs8yNSuSxArIaCzVjEkx898F KEHVt4wuvsHDgfjUERFCztmW2oFV81cuAWzhjVV/3ezd1NtkJSailBFeV g=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 20:11:47 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2017 07:11:46 +0600 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v381Bh0n004258 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 21:11:45 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v381Bh0n004258 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1491613905; bh=IBpHohyNFwt4Gyxzr46/BqD0Mfk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=vBI7wAttibK+MGbOUGSOmupR8ajcUJv/IhpZ5wzPTunnfyNfMhRwBt3IasFbXWAoT GT2EbkwS9bJjEdGPP31cPhjZt9r4krwsKuyiN/1qvIQhHSZ/2copl6AkJ3UQwzLvmE 7tdtNNfn3uIkt4NR2/TQ6WRfElVlL/yddR7Ba3yQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v381Bh0n004258 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 7 Apr 2017 21:11:18 -0400 Received: from MXHUB320.corp.emc.com (MXHUB320.corp.emc.com [10.146.3.98]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v381BT4X008501 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 7 Apr 2017 21:11:30 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB320.corp.emc.com ([10.146.3.98]) with mapi id 14.03.0266.001; Fri, 7 Apr 2017 21:11:29 -0400 To: Michael Welzl , "De Schepper, Koen (Nokia - BE/Antwerp)" CC: tsvwg IETF list Thread-Topic: [tsvwg] confirming adoption of L4S drafts Thread-Index: AQHSqihEbx9tciMmmEqtNmIjYbTBLaGvnfwAgAKYIYCAAWxcAIAHD7Pg Date: Sat, 8 Apr 2017 01:11:29 +0000 Message-ID: References: <138206D2-85DF-4CAC-B196-7FC59304546A@ifi.uio.no> <372AFF1E-A1B4-4710-9EA5-25DBD74ED2FA@ifi.uio.no> In-Reply-To: <372AFF1E-A1B4-4710-9EA5-25DBD74ED2FA@ifi.uio.no> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] confirming adoption of L4S drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 01:11:51 -0000 QSBmZXcgY29tbWVudHMgYXMgYSBXRyBjaGFpciAuLi4NCg0KVGhlIGNvbmNlcm4gYWJvdXQgd2hh dCB0cmFuc3BvcnQgcHJvdG9jb2wgdG8gdXNlIHdpdGggTDRTIHdhcyByYWlzZWQgaW4gZGlzY3Vz c2lvbiBpbiBDaGljYWdvLg0KDQo+IEkgY29uZmlybSB0aGF0IElDQ1JHIGlzIHRoZSByaWdodCBw bGFjZSB0byBwcmVzZW50IHN1Y2ggd29yaywgZm9yIG5vdy4NCj4gImlmIGFjY2VwdGVkIGJ5IElD Q1JHIHRoZSBwcm9jZXNzIGFsbG93cyBhIGRyYWZ0IGluIFRDUE0iIGRvZXNuJ3Qgc291bmQNCj4g cmlnaHQuIEl0J3Mgbm90IGxpa2Ugd2UgKElDQ1JHKSBhY2NlcHQgYW55dGhpbmcgYW5kIHRoYXQg dGhlbiBhdXRvbWF0aWNhbGx5IGhhcw0KPiBhIG1lYW5pbmcgaW4gVENQTS4gV2UganVzdCByZXZp ZXcgdGhpbmdzIHVudGlsIHRoZXkgYXJlIHJlYWR5IGZvciB0aGUgSUVURi4NCg0KUHJvY2VzcyBw b2ludCBhY2tub3dsZWRnZWQsIGFsdGhvdWdoIEkgaGFkIHJlYWQgS29lbidzIHVzZSBvZiAiYWNj ZXB0ZWQiIGxvb3NlbHkgYXMgSUNDUkcgZ2VuZXJhbGx5IGhhdmluZyBwb3NpdGl2ZSBmZWVkYmFj ayBvbiB0aGUgd29yay4gIEkgc3VzcGVjdCBldmVyeW9uZSdzIGluIGFncmVlbWVudCBoZXJlLCBh cyB3aGlsZSBJQ0NSRyBkb2VzIG5vdCBoYXZlIGEgZm9ybWFsIElFVEYgcHJvY2VzcyByb2xlLCBp ZiBJQ0NSRyBoYXMgbmVnYXRpdmUgdmlld3Mgb24gYSBjb25nZXN0aW9uLXJlbGF0ZWQgZHJhZnQs IHRoZW4gdGhhdCBkcmFmdCBpcyB1bmxpa2VseSB0byBtYWtlIG11Y2ggcHJvZ3Jlc3MgaW4gYW55 IElFVEYgV0cgaW4gdGhlIFRyYW5zcG9ydCBBcmVhLg0KDQo+IEFoLi4uIHVuZGVyc3Rvb2QuIFRo ZSAiY29udHJvbGxlZCBzZXJ2aWNlIHByb3ZpZGVyIGVudmlyb25tZW50IiBzY2VuYXJpbw0KPiBt YWtlcyBzZW5zZSB0byBtZS4gVG8gYmUgY2xlYXIsIHRoaXMgd291bGQgYmUgYWJvdXQgc2l0dWF0 aW9ucyB3aGVyZSBib3RoDQo+IHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVyIGFyZSBhbHNvIHdpdGhp biB0aGUgc2FtZSBjb250cm9sbGVkIElTUCBuZXR3b3JrLg0KDQpZZXMsIGRlZmluaXRlbHksIGFu ZCBhbHNvIGluIHJlbGF0ZWQgbmV0d29ya3MgdW5kZXIgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGNv bnRyb2wuICBUaGlzICJjb250cm9sbGVkIHNlcnZpY2UgcHJvdmlkZXIgZW52aXJvbm1lbnQiIHNj ZW5hcmlvIGlzIGFudGljaXBhdGVkIGJ5IHRoZSBuZXcgVURQIEd1aWRlbGluZXMgUkZDIChSRkMg ODA4NSksIGFuZCB3b3JrZWQgZXhhbXBsZXMgb2YgYXBwbGljYWJpbGl0eSB0byB0aGF0IHNjZW5h cmlvIGNhbiBiZSBmb3VuZCBpbiBNUExTL1VEUCAoUkZDIDc1MTApIGFuZCBHUkUvVURQIChSRkMg ODA4NikuDQoNClRoYW5rcywgLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE1pY2hhZWwgV2VsemwNCj4gU2VudDogTW9uZGF5LCBBcHJpbCAzLCAyMDE3IDU6MDkgQU0N Cj4gVG86IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApIDxrb2VuLmRlX3Nj aGVwcGVyQG5va2lhLQ0KPiBiZWxsLWxhYnMuY29tPg0KPiBDYzogdHN2d2cgSUVURiBsaXN0IDx0 c3Z3Z0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFt0c3Z3Z10gY29uZmlybWluZyBhZG9wdGlv biBvZiBMNFMgZHJhZnRzDQo+IA0KPiBIaSwNCj4gDQo+IEluIGxpbmU6DQo+IA0KPiANCj4gPiBP biAwMiBBcHIgMjAxNywgYXQgMTM6MjQsIERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0Fu dHdlcnApDQo+IDxrb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb20+IHdyb3RlOg0K PiA+DQo+ID4gSGkgTWljaGFlbCwNCj4gPg0KPiA+IFRoYW5rcyBmb3IgYnJpbmdpbmcgdXAgdGhl c2UgcG9pbnRzLiBTZWUgaW5saW5lOg0KPiA+DQo+ID4NCj4gPiBGcm9tOiB0c3Z3ZyBbbWFpbHRv OnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsIFdlbHpsDQo+ID4g U2VudDogdnJpamRhZyAzMSBtYWFydCAyMDE3IDIxOjQ3DQo+ID4gVG86IHRzdndnIElFVEYgbGlz dCA8dHN2d2dAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFt0c3Z3Z10gY29uZmlybWluZyBh ZG9wdGlvbiBvZiBMNFMgZHJhZnRzDQo+ID4NCj4gPiBIaSBhbGwsDQo+ID4NCj4gPiBTb3JyeSwg SSB3b3VsZCBoYXZlIGdvbmUgdG8gdGhlIG1pYyB0byBzYXkgdGhpcyB5ZXN0ZXJkYXksIGJ1dCB0 aW1lIHdhcw0KPiBydW5uaW5nIHNob3J0LCB0aGVyZSB3ZXJlIGxvdHMgb2Ygb3RoZXJzIGdvaW5n IHRoZXJlLCBBTkQgSSB3YXMgc2NyaWJpbmfigKYNCj4gaGVuY2Ugbm93IHRoaXMgZW1haWw6DQo+ ID4NCj4gPiBJ4oCZbSBhIGxpdHRsZSB3b3JyaWVkIHRoYXQgd2XigJlyZSBhZG9wdGluZyBhIGJl aGF2aW9yIGluc2lkZSB0aGUgbmV0d29yaywNCj4gd2l0aG91dCBzcGVjaWZ5aW5nIGhvdyBlbmQg c3lzdGVtcyBzaG91bGQgd29yayB3aXRoIGl0Lg0KPiA+DQo+ID4gW0tEU10gQ3VycmVudGx5IHRo ZSBMNFMgSWRlbnRpZmllciBkcmFmdCBpcyBzcGVjaWZ5aW5nIGhvdyBhIENDIHNob3VsZA0KPiBi ZWhhdmUgYW5kIHJlc3BvbmQgdG8gQ0UsIHdoZW4gaXQgdXNlcyB0aGUgTDRTLUVDVCBjb2RlIHBv aW50LiBUaGUgaWRlYSBpcw0KPiB0byB3cml0ZSBpdCByYXRoZXIgaW4gcmVxdWlyZW1lbnRzIHRo YW4gc3BlY2lmaWMgbWVjaGFuaXNtcy4gUHJvYmFibHkgYWxzbw0KPiB0aGUgY29ycmVjdCBwbGFj ZSB0byB3cml0ZSBkb3duIHRoZSBUQ1AtUHJhZ3VlIHJlcXVpcmVtZW50cyAoY3VycmVudGx5IHRo ZXkNCj4gYXJlIGEgYml0IGxvc3QgaW4gYW4gYXBwZW5kaXggaW4gdGhlIER1YWxRIGRyYWZ0KS4g QSBzZXBhcmF0ZSBkcmFmdCBjYW4gdGhlbiBiZQ0KPiBtYWRlIHBlciBzcGVjaWZpYyBMNFMgY29t cGxhaW50IENDIHRvIGV4cGxhaW4gaXRzIG1lY2hhbmlzbXMuIFdvdWxkIHRoYXQNCj4gaGVscD8N Cj4gDQo+IEkgZG9uJ3Qga25vdz8gSXQncyBjZXJ0YWlubHkgYSBnb29kIHN0YXJ0aW5nIHBvaW50 IGJ1dCBJJ20gYSBsaXR0bGUgY29uY2VybmVkIHRoYXQNCj4gd2UnbGwgZW5kIHVwIHdpdGggUkZD cyB0byBkZXNjcmliZSBhbiBpbm5lciBuZXR3b3JrIGJlaGF2aW9yIChhbmQgcmVzZXJ2ZSBhDQo+ IGNvZGVwb2ludCBmb3IgaXQhKSwgYnV0IG1heWJlIG5ldmVyIHdpdGggYW4gZW5kIHN5c3RlbSBt ZWNoYW5pc20gKmZvciB0aGUNCj4gSW50ZXJuZXQqIHRoYXQgdXNlcyBpdCAoYmVjYXVzZSB0aGVy ZSBhcmUgc29tZSBpc3N1ZXMgdG8gYmUgYWRkcmVzc2VkIHRvDQo+IHdoaWNoIEkndmUgc28gZmFy IG5vdCBldmVuIHNlZW4gaGludHMgb2YgYSBzb2x1dGlvbikuDQo+IA0KPiANCj4gPiAgSW4gcGFy dGljdWxhciwgd2hhdCBtYWtlcyBtZSBmZWVsIHVuZWFzeSBpcyBzbGlkZSAyIGZyb20geWVzdGVy ZGF54oCZcw0KPiBwcmVzZW50YXRpb246DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTgvc2xpZGVzL3NsaWRlcy05OC10c3Z3Zy1zZXNzYi1sNHMtDQo+IGRyYWZ0cy0wMS5w ZGYNCj4gPiB3aGljaCBzaG93ZWQgVENQIFByYWd1ZSBhcyBhbiBJQ0NSRyBpdGVtLiBJIHRoaW5r IHRoaXMgbWlzcmVwcmVzZW50cyB0aGUNCj4gcm9sZSBvZiBhbiBJUlRGIGdyb3VwOiB5ZXMgSUND UkcgY2FuIHB1Ymxpc2ggZG9jdW1lbnRzLCBidXQgdGhlc2UgaGF2ZSBhbg0KPiBJUlRGIGJvaWxl cnBsYXRlLCBhbmQgSSBkb27igJl0IHRoaW5rIHRoYXTigJlzIHRoZSByaWdodCB3YXkgdG8gcHVi bGlzaCBhbiBlMmUNCj4gY291bnRlcnBhcnQgdG8gYW4gSUVURiBFeHBlcmltZW50YWwgUkZDLiBB cyBJIGV4cGxhaW5lZCBpbiB0c3ZhcmVhIGVhcmxpZXIgdGhpcw0KPiB3ZWVrOg0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk4L3NsaWRlcy9zbGlkZXMtOTgtdHN2YXJlYS1z ZXNzYi0NCj4gZGlzY3Vzc2lvbi1vbi1jb25nZXN0aW9uLWNvbnRyb2wtd29yay1pbi10aGUtaWV0 Zi10aGUtcm9sZS1vZi1pY2NyZy1taWNoYWVsLQ0KPiB3ZWx6bC0wMC5wZGYNCj4gPiDigKYgdGhl IG1vcmUgY29tbW9uIHJvbGUgb2YgSUNDUkcgaXMgdG8gcHJlLWV2YWx1YXRlIHByb3Bvc2FscyBi ZWZvcmUNCj4gdGhleeKAmXJlIGV2ZW4gcmVhZHkgZm9yIHRoZSBJRVRGLg0KPiA+DQo+ID4gW0tE U10gWWVzLCBzb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4gRm9yIFRDUC1QcmFndWUsIHRoZSBJQ0NS RyByZWZlcmVuY2UNCj4gd2FzIG1haW5seSB0byBzaG93IHdoZXJlIGN1cnJlbnRseSB0aGUgd29y ayBpcyBwcmVzZW50ZWQgKHdoaWNoIEkgdGhpbmsgaXMNCj4gdGhlIHJpZ2h0IHdnIGZvciB0aGlz LCBub3Q/KS4gQXMgSSBzYWlkIGluIHRoZSB0c3Z3ZyBwcmVzZW50YXRpb24sIHNlZW4gdGhlDQo+ IHJlY2VudCBpY2NyZyBhbmQgdHN2d2cgZGlzY3Vzc2lvbnMgaXQgaXMgbm90IGNsZWFyIHRvIG1l IGlmIGEgQ0MgZHJhZnQgd2lsbCBiZQ0KPiBuZWVkZWQuDQo+IA0KPiBJIGhlYXJkIHlvdSBzYXkg dGhpcyBidXQgSSBkb24ndCB1bmRlcnN0YW5kIHlvdXIgcG9pbnQuIFdoeSBzaG91bGQgYSBDQyBk cmFmdA0KPiBub3QgYmUgbmVlZGVkPw0KPiANCj4gDQo+ID4gQXMgZmFyIGFzIEkgdW5kZXJzdG9v ZCwgaWYgYWNjZXB0ZWQgYnkgSUNDUkcgdGhlIHByb2Nlc3MgYWxsb3dzIGEgZHJhZnQgaW4NCj4g VENQTS4NCj4gDQo+IEkgY29uZmlybSB0aGF0IElDQ1JHIGlzIHRoZSByaWdodCBwbGFjZSB0byBw cmVzZW50IHN1Y2ggd29yaywgZm9yIG5vdy4NCj4gImlmIGFjY2VwdGVkIGJ5IElDQ1JHIHRoZSBw cm9jZXNzIGFsbG93cyBhIGRyYWZ0IGluIFRDUE0iIGRvZXNuJ3Qgc291bmQNCj4gcmlnaHQuIEl0 J3Mgbm90IGxpa2Ugd2UgKElDQ1JHKSBhY2NlcHQgYW55dGhpbmcgYW5kIHRoYXQgdGhlbiBhdXRv bWF0aWNhbGx5IGhhcw0KPiBhIG1lYW5pbmcgaW4gVENQTS4gV2UganVzdCByZXZpZXcgdGhpbmdz IHVudGlsIHRoZXkgYXJlIHJlYWR5IGZvciB0aGUgSUVURi4NCj4gU28gZ2l2ZW4gdGhhdCB0aGlz IGlzIG9uZSBwaWVjZSBvZiBhIGxhcmdlciBwdXp6bGUsIEkgdGhpbmsgd2Ugc2hvdWxkIGZpcnN0 IHNlZSBhDQo+IGRlZGljYXRpb24gZnJvbSBUQ1BNIG9yIFRTVldHIHRoYXQgdGhleSdkIGFjY2Vw dCBhIENDIGRyYWZ0IGZvbGxvd2luZyB0aGUNCj4gcmVxdWlyZW1lbnRzIHRoYXQgeW91IGxheSBv dXQgKHRoZSBlbnZpc2lvbmVkIGRyYWZ0IGFib3V0IENDIHJlcXVpcmVtZW50cw0KPiB0aGF0IHlv dSBtZW50aW9uIGFib3ZlKS4gVGhlbiBJIHRoaW5rIHRoYXQgd291bGQgYmUgYSBiZXR0ZXIgYmFz aXMuIEJ1dCB0aGF0J3MNCj4ganVzdCBteSBwZXJzb25hbCBvcGluaW9uLg0KPiANCj4gSSBvbmx5 IHdhbnRlZCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgdGhlIElDQ1JHIGRvZXNuJ3QgaGF2ZSBhbnkg ZGlyZWN0DQo+IGluZmx1ZW5jZSBhbmQgcHJlc2VudGluZyBzb21ldGhpbmcgdGhlcmUgZG9lc24n dCBhdXRvbWF0aWNhbGx5IG1lYW4NCj4gYW55dGhpbmcgaW4gdGhlIElFVEYuDQo+IA0KPiANCj4g PiAgVGVjaG5pY2FsbHksIHRoZXNlIGFyZSBub3Qgc28gbWlub3IgaXNzdWVzLiBEQ1RDUCwgYXMg aXQgc3RhbmRzLCBkb2VzbuKAmXQNCj4gd29yayBvbiB0aGUgSW50ZXJuZXQ7IHRoZXJlIGFyZSBJ bnRlcm5ldC1zcGVjaWZpYyBwcm9ibGVtcyB0aGF0IHdvdWxkIGZpcnN0DQo+IG5lZWQgdG8gYmUg YWRkcmVzc2VkLiBUd28gY2FzZXMgd2VyZSBkaXNjdXNzZWQgeWVzdGVyZGF5Og0KPiA+IDEpIGhv dyB3aWxsIHRoaXMgd29yayB3aGVuIHRoZXJlIGFyZSB0d28gYm90dGxlbmVja3MgaW4gYSByb3c/ DQo+ID4gMikgd2hhdCBpZiBUQ1AgUHJhZ3VlIHRyYWZmaWMgZ2V0cyBpbnRvIGEg4oCcY2xhc3Np Y+KAnSBFQ04gcXVldWU/DQo+ID4g4oCmIGFuZCB0aGVzZSBhcmUgbGlrZWx5IG5vdCB0aGUgb25s eSBvbmVzLiBFLmcuLCB0aGUgc2Vjb25kIHByb2JsZW0gd2FzDQo+IGlkZW50aWZpZWQgbG9uZyBh Z28sIGF0IHRoZSBMNFMgQm9GIC0gc2VlIHNsaWRlIDM6DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni1sNHMtNi5wZGYNCj4gPiB3aGVyZSBp dCBzYXlzICJGYWxsLWJhY2sgdG8gY2xhc3NpYyBUQ1Agb24gY2xhc3NpYyBFQ04gYm90dGxlbmVj a+KAnS4NCj4gV29ycnlpbmdseSwgdGhlIOKAnHN0YXJ0aW5nIHBvaW504oCdIGNvbHVtbiBzYXlz IOKAnG5vbmXigJ0sIGFuZCBzbyBmYXIgaXQgZG9lc27igJl0DQo+IHNlZW0gdGhhdCB3ZSBoYXZl IGFuIGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uLg0KPiA+ID0+IHdoYXQgd2lsbCB0aGlzIGRvIHRv IHRoZSBvbmdvaW5nIGVmZm9ydCBvZiBBcHBsZSB0byBlbmFibGUgKGNsYXNzaWMpIEVDTj8NCj4g Pg0KPiA+IFtLRFNdIEluZGVlZCwgRENUQ1AgY2FuIGJlIHVzZWQgd2l0aCBEdWFsUSBpbiBmYWly LXNoYXJlIG1vZGUgd2l0aCBjbGFzc2ljDQo+IFRDUCwgYnV0IGluIGEgY29udHJvbGxlZCBlbnZp cm9ubWVudCBvbmx5LiBUaGlzIGNvdWxkIGJlIGluIGEgZGF0YSBjZW50ZXIsIG9yIGluDQo+IGEg c2VydmljZSBwcm92aWRlcuKAmXMgbmV0d29yaywgd2hlcmUgdGhlIGNvbmdlc3Rpb24gcG9pbnRz IGFyZSBrbm93biBhbmQNCj4gc3VwcG9ydCBMNFMuIEV4dHJhIEw0UyBpZGVudGlmaWNhdGlvbiAo ZGlmZnNlcnYgY29kZXBvaW50cy9JUCByYW5nZXMpIGNvdWxkIGJlDQo+IHVzZWQgaWYgbmVlZGVk LiBBcywgSSB0aGluayBHb3JyeSBzdGF0ZWQsIHRoZSBjdXJyZW50IERDVENQIGRyYWZ0IHJlc3Ry aWN0cyBpdHMNCj4gdXNlIHRvIGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzIG9ubHk6DQo+ID4gICAg RENUQ1AgYXMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQNCj4gPiAgICBpcyBhcHBsaWNhYmxlIHRv IGRlcGxveW1lbnRzIGluIGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzIGxpa2UNCj4gPiAgICBkYXRh Y2VudGVycyBidXQgaXQgTVVTVCBOT1QgYmUgZGVwbG95ZWQgb3ZlciB0aGUgcHVibGljIEludGVy bmV0DQo+ID4gICAgd2l0aG91dCBhZGRpdGlvbmFsIG1lYXN1cmVzDQo+ID4gVG8gbXkgdW5kZXJz dGFuZGluZyB0aGlzIGFsbG93cyB0aGUgYWJvdmUgZGVzY3JpYmVkIGNvbnRyb2xsZWQgc2Vydmlj ZQ0KPiBwcm92aWRlciBlbnZpcm9ubWVudCB0b28uDQo+IA0KPiBBaC4uLiB1bmRlcnN0b29kLiBU aGUgImNvbnRyb2xsZWQgc2VydmljZSBwcm92aWRlciBlbnZpcm9ubWVudCIgc2NlbmFyaW8NCj4g bWFrZXMgc2Vuc2UgdG8gbWUuIFRvIGJlIGNsZWFyLCB0aGlzIHdvdWxkIGJlIGFib3V0IHNpdHVh dGlvbnMgd2hlcmUgYm90aA0KPiB0aGUgc2VuZGVyIGFuZCByZWNlaXZlciBhcmUgYWxzbyB3aXRo aW4gdGhlIHNhbWUgY29udHJvbGxlZCBJU1AgbmV0d29yay4NCj4gDQo+IFlldDogdGhlIGludGVu dGlvbiBvZiBMNFMgaXMgbm90IHRvIGJlIGxpbWl0ZWQgdG8gc3VjaCBzY2VuYXJpb3Mgb25seSwg SQ0KPiBzdXBwb3NlPyAgSWYgdGhlIHBsYW4gaXMgc3RpbGwgdG8gdHJ5IHRoaXMgbW9yZSBvcGVu bHkgYWNyb3NzIHRoZSBJbnRlcm5ldCwgdGhlbiBJDQo+IHRoaW5rIG15IGNvbmNlcm5zIGFyZSB1 bmNoYW5nZWQuLi4NCj4gDQo+IA0KPiA+ICBBcmUgeW91ciBvdGhlciBjb25jZXJucyBhbGwgY292 ZXJlZCBieSB0aGUgVENQLVByYWd1ZSByZXF1aXJlbWVudHM/DQo+IFNob3VsZCB3ZSBhZGQgbW9y ZT8NCj4gDQo+IEFjdHVhbGx5IEkgdGhpbmsgbXkgY29uY2VybiBpcyBjb3ZlcmVkIHdlbGwgYnkg cmVxdWlyZW1lbnQgIzQuMiBoZXJlOg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtYnJpc2NvZS10c3Z3Zy1sNHMtYXJjaC0wMiNhcHBlbmRpeC1BDQo+IA0KPiBIb3dldmVyIEkg ZGlzYWdyZWUgd2l0aCB0aGUgZGlzY3Vzc2lvbjoNCj4gDQo+ICoqKg0KPiAgICBEaXNjdXNzaW9u OiBJdCBpcyBub3QgY2xlYXIgYXQgdGhpcyBwb2ludCBpZiBpdCBpcyBwb3NzaWJsZSB0byBkZXNp Z24NCj4gICAgYSBtZWNoYW5pc20gdGhhdCBhbHdheXMgZGV0ZWN0IHRoZSBhZm9yZW1lbnRpb25l ZCBjYXNlcy4gIE9uZQ0KPiAgICBwb3NzaWJpbGl0eSBpcyB0byBiYXNlIHRoZSBkZXRlY3Rpb24g b24gYW4gaW5jcmVhc2Ugb24gdG9wIG9mIGENCj4gICAgbWluaW11bSBSVFQsIGJ1dCBpdCBpcyBu b3QgeWV0IGNsZWFyIHdoaWNoIHZhbHVlIHNob3VsZCB0cmlnZ2VyIHRoaXMuDQo+ICAgIEhhdmlu ZyBhIGRlbGF5IGJhc2VkIGZhbGwgYmFjayByZXNwb25zZSBvbiBMNFMgbWF5IGFzIHdlbGwgYmUN Cj4gICAgYmVuZWZpY2lhbCBmb3IgcHJlc2VydmluZyBsb3cgbGF0ZW5jeSB3aXRob3V0IGxlZ2Fj eSBuZXR3b3JrIG5vZGVzLg0KPiAgICBFdmVuIGlmIGl0IHBvc3NpYmxlIHRvIGRlc2lnbiBzdWNo IGEgbWVjaGFuaXNtLCBpdCBtYXkgd2VsbCBiZSB0aGF0DQo+ICAgIGl0IHdvdWxkIGVuY29tcGFz cyBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgdGhhdCBpbXBsZW1lbnRlcnMgbWF5DQo+ICAgIGNvbnNp ZGVyIHVubmVjZXNzYXJ5LiAgVGhlIG5lZWQgZm9yIHRoaXMgbWVjaGFuaXNtIGRlcGVuZHMgb24g dGhlDQo+ICAgIGV4dGVudCBvZiBjbGFzc2ljIEVDTiBkZXBsb3ltZW50Lg0KPiAqKioNCj4gDQo+ IEkgY2FuJ3QgdW5kZXJzdGFuZCBob3cgaGF2aW5nIHN1Y2ggYSBtZWNoYW5pc20gd291bGQgYmUg dW5uZWNlc3Nhcnk6IHRoYXQNCj4gd291bGQgYmUgYXNzdW1lIHRoYXQgRVZFUllPTkUgd2hvIHdv dWxkIGVuYWJsZSBFQ04gd291bGQgT05MWSBlbmFibGUNCj4gaXQgdXNpbmcgTDRTLg0KPiAodGhl cmUncyBubyBvbGQgY29kZSBvdXQgdGhlcmUgdGhhdCB0cmVhdHMgRUNUKDEpIGFuZCBFQ1QoMCkg ZXF1YWwsIGFuZA0KPiBub2JvZHkgd291bGQganVzdCB0dXJuIGl0IG9uIC0gZXZlbiB0b2RheSB0 aGF0J3MgcHJvYmFibHkgYWxyZWFkeSB3cm9uZykuDQo+IA0KPiBJIGFsc28gY2FuJ3QgdW5kZXJz dGFuZCB3aHkgaXQgbWlnaHQgbm90IGJlIHBvc3NpYmxlOiBJJ2Qgc2F5IGl0J3MgYSBzdHJvbmcN Cj4gcmVxdWlyZW1lbnQuIFdoYXQgbWlnaHQgaGFwcGVuIGlzIHRoYXQgeW91IGdldCBmYWxzZSBw b3NpdGl2ZXMgLSBzbyBiZSBpdC4NCj4gVGhlbiB5b3UnbGwganVzdCBoYXZlIHRvIGJlIGNvbnNl cnZhdGl2ZS4NCj4gQlRXIEkgZ3Vlc3MgdGhlcmUncyBtb3JlIGlucHV0IHlvdSBjb3VsZCB1c2Ug LSBwb3NzaWJseSB0aGUgcGF0dGVybiBvZg0KPiByZXR1cm5pbmcgRUNOLW1hcmtzIGNhbiBhbHNv IGJlIGEgaGludCBhcyB0byB0aGUgdXNlIG9mIGFuIEw0UyB2cy4gY2xhc3NpYyBFQ04NCj4gcXVl dWUuDQo+IA0KPiBDaGVlcnMsDQo+IE1pY2hhZWwNCg0K From nobody Fri Apr 7 18:20:27 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E73B12896F for ; Fri, 7 Apr 2017 18:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=gy7BW1Dd; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=fNTmC8v3 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 Nh7v2R6JKJwB for ; Fri, 7 Apr 2017 18:20:22 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 3E6E1126DDF for ; Fri, 7 Apr 2017 18:20: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=1491614422; x=1523150422; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VHIdiKY4jZgRv0M1tOjpJRGv0TIU2mOo94UGPtUwDTA=; b=gy7BW1Ddq6Mvb39RRo2fNVIkp0UWLxHV3+y4qR3/oxvfMlst08ZcTaGI hllyA5rqGH5Zoi5TPmxtEUPSVsToJ8/VJUlHMBpNjIxFX0e+Ij+WZsu1K ISv2UWMAWSuTb66l1oKipvaalATJbCKJW3fZnJxbXYCXSUki6lK0tdm0E o=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 20:20:21 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2017 07:19:19 +0600 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v381KIoJ015731 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 21:20:19 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v381KIoJ015731 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1491614420; bh=MAYg2cbJlvjNXekzRVr36eOb5Fo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=fNTmC8v3XXEyPNXQIHSxdmnUxCnaSFv9h9tGDYC+YOAOuky4GJ9bkTAiuKZRybuc3 axBHYhN78atF31axBwusCsyeiF5Z0wMbQDCdE8J2SHLFj/0MbRoVeFPpirb4gfUNju B32vjxa8zAF9CuJTtmjfvbS8iJJ02mrqo17mpZZc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v381KIoJ015731 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 7 Apr 2017 21:19:54 -0400 Received: from MXHUB304.corp.emc.com (MXHUB304.corp.emc.com [10.146.3.30]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v381K34Z004787 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 7 Apr 2017 21:20:04 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB304.corp.emc.com ([10.146.3.30]) with mapi id 14.03.0266.001; Fri, 7 Apr 2017 21:20:03 -0400 To: Bob Briscoe , "Weixinpeng (Jackie)" , "draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org" CC: tsvwg IETF list Thread-Topic: Tunnel Congestion Feedback: (non-)update to RFC6040 Thread-Index: AQHSMJIdqgBqqFRtE0e6Mhkxp5lkF6C+tKeAgAMnj6CAARqngP//y1HwgADkPACA8C0NAIADe+0AgAPuUwCAAGwmwA== Date: Sat, 8 Apr 2017 01:20:02 +0000 Message-ID: References: <712bfd85-39e5-bcae-f9b9-0035ef5cf654@bobbriscoe.net> In-Reply-To: <712bfd85-39e5-bcae-f9b9-0035ef5cf654@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: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F9B3F09MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 01:20:26 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F9B3F09MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gYW1vbmcgdGhvc2UgcmVzcG9uc2libGUgZm9yIHRoZSBpbmdyZXNzLWVncmVzcyBtZWFz dXJlbWVudCBhZGRpdGlvbiwgc28gd2VpZ2hpbmcgaW4gYXMgZHJhZnQgc2hlcGhlcmQ6DQoNCj4g SG93ZXZlciwgSSBhbSBzYXlpbmcgaXQgaXMgbGVzcyByb2J1c3QgdG8gaGF2ZSB0byBtZWFzdXJl IGF0IGJvdGggaW5ncmVzcyBhbmQgZWdyZXNzLCBiZWNhdXNlIGl0IGludm9sdmVzIHNlbmRpbmcg c3luY2ggLyBtZWFzdXJlbWVudA0KPiBtZXNzYWdlcyBmcm9tIGluZ3Jlc3MgdG8gZWdyZXNzLCB3 aGljaCBjYW4gYmUgbG9zdC9kZWxheWVkLiAgU28sIEkgd291bGQgcmVjb21tZW5kIHRoZSBtb3Jl IHJvYnVzdCBlZ3Jlc3Mtb25seSBtZXRob2QgZm9yIEVDTiwNCj4gYW5kIHRoZSBpbmdyZXNzLWVn cmVzcyBtZXRob2Qgb25seSBmb3IgdG90YWwgZHJvcC4NCg0KVGhhdCBzZWVtcyBmaW5lLCBob3dl dmVyIHRoZSB0b3RhbCBkcm9wIGluZm8gZG9lcyBuZWVkIHRvIGJlIHJlcG9ydGVkIGluIGFkZGl0 aW9uIHRvIEVDTiBpbmZvLg0KDQo+IFRoZSBvbmx5IGV4dHJhIHRoaW5nIHlvdSBsZWFybiBieSB0 aGUgY3VycmVudGx5IHByb3Bvc2VkIGFwcHJvYWNoIGlzIGhvdyBtYW55IG9mIGVhY2ggRUNOIGNv ZGVwb2ludCB3ZXJlIGRyb3BwZWQuIElmIHlvdSB0aGluayB0aGF0J3MgaW1wb3J0YW50LCBhcmd1 ZSBmb3IgaXQuIEkgZG9uJ3Qgc2VlIGFueSBuZWVkIGZvciBpdCB0aG8uDQoNCkkgd291bGQgYWdy ZWUuDQoNCj4gSWYgeW91IGluc2lzdCBvbiBrZWVwaW5nIHRoZSBpbmdyZXNzLWVncmVzcyBhcHBy b2FjaCwgd2h5IGRvIHlvdSBuZWVkIHRoZSBmYWtlZCBFQ04gdGV4dD8NCg0KSWYgb25lIGlzIHRy eWluZyB0byBtZWFzdXJlIGNvbmdlc3Rpb24gaW4gdGhlIHR1bm5lbCwgZHJvcHMgaGF2ZSB0byBi ZSBjb25zaWRlcmVkIOKAkyBldmVuIGlmIGFsbCBub2RlcyBpbiB0aGUgdHVubmVsIHN1cHBvcnQg RUNOLCBhbiBvdmVybG9hZGVkIEVDTiBub2RlIHdpbGwgZHJvcCBwYWNrZXRzLg0KVGhlIHJlYXNv biBmb3IgZmFrZWQtRUNOIGlzIGJ1cmllZCBpbiBCb2LigJlzIOKAnG1vcmUgcm9idXN04oCdIGNv bW1lbnQgYWJvdXQgZWdyZXNzLW9ubHkgRUNOIG1lYXN1cmVtZW50IGFib3ZlIOKAkyB1c2Ugb2Yg RUNOIHNob3VsZCByZXN1bHQgaW4gYmV0dGVyIG1lYXN1cmVtZW50cyBieSBjb21wYXJpc29uIHRv IG5vbi11c2UuDQoNClRoYW5rcywgLS1EYXZpZA0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRv OmlldGZAYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBGcmlkYXksIEFwcmlsIDcsIDIwMTcgMTA6NDgg QU0NClRvOiBXZWl4aW5wZW5nIChKYWNraWUpIDx3ZWl4aW5wZW5nQGh1YXdlaS5jb20+OyBCbGFj aywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb20+OyBkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1j b25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnDQpDYzogdHN2d2cgSUVURiBsaXN0IDx0 c3Z3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBUdW5uZWwgQ29uZ2VzdGlvbiBGZWVkYmFjazog KG5vbi0pdXBkYXRlIHRvIFJGQzYwNDANCg0KV2VpeGlucGVuZywNCk9uIDA1LzA0LzE3IDAzOjQ1 LCBXZWl4aW5wZW5nIChKYWNraWUpIHdyb3RlOg0KSGkgQm9iLA0KVGhhbmtzIGZvciB5b3VyIGNv bW1lbnRzLCBhbmQgcGxlYXNlIHNlZSBpbmxpbmUuDQpSZWdhcmRzLA0KLVhpbnBlbmcNCg0KRnJv bTogQm9iIEJyaXNjb2UgW21haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogTW9uZGF5 LCBBcHJpbCAwMywgMjAxNyA1OjM0IEFNDQpUbzogV2VpeGlucGVuZyAoSmFja2llKTsgQmxhY2ss IERhdmlkOyBkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xz LmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRi YWNrQHRvb2xzLmlldGYub3JnPg0KQ2M6IHRzdndnIElFVEYgbGlzdA0KU3ViamVjdDogUmU6IFR1 bm5lbCBDb25nZXN0aW9uIEZlZWRiYWNrOiAobm9uLSl1cGRhdGUgdG8gUkZDNjA0MA0KDQpXZWl4 aW5wZW5nLCBjby1hdXRob3JzLCAgYW5kIERhdmlkLA0KDQpJIGhhZCBwcm9taXNlZCBhIHJldmll dyBvZiB0aGUgbGF0ZXN0IFRDRiBkcmFmdCwgYnV0IGZhaWxlZCB0byBwcm92aWRlIGl0IHNvIGZh ci4NCkkgaGFsZiByZWFkIGl0IHRocm91Z2ggb24gRnJpZGF5LCBhbmQgSSB3aWxsIGZpbmlzaCBh bmQgd3JpdGUgdXAgbXkgcmV2aWV3IHRoaXMgd2Vlay4NCg0KSGVyZScgYSBxdWljayBzdW1tYXJ5 IG9mIHRoZSBtYWluIHBvaW50cyBzbyBmYXI6DQoNClMuMS4gSW50cm86IE1vdGl2YXRpb24NClRo ZSBtb3RpdmF0aW9uIHNob3VsZCBhbHNvIGluY2x1ZGUgYSBoZWF2eSBsb2FkIGZyb20gYSBtdWNo IGxhcmdlciB0aGFuIGV4cGVjdGVkIG51bWJlciBvZiByZXNwb25zaXZlIGZsb3dzDQpbV2VpXSBP aywgSSB3aWxsIGFkZCBpdC4NCg0KUy4xIEludHJvOiBTY29wZQ0KSSB0aGluayB0aGUgZHJhZnQg c2hvdWxkIHNheSB0aGF0DQoqIGl0IGdpdmVzIG5vIGFkdmljZSBvbiBob3cgdG8gc2VsZWN0IHdo aWNoIHR1bm5lbCBlbmRwb2ludHMgc2hvdWxkIGJlIHVzZWQgaW4gb3JkZXIgdG8gbWFuYWdlIHRy YWZmaWMgb3ZlciBhIG5ldHdvcmsgY3Jpc3MtY3Jvc3NlZCBieSBtdWx0aXBsZSB0dW5uZWxzLg0K KiBpZiBhIGNvbmdlc3RlZCBub2RlIGlzIHBhcnQgb2YgbXVsdGlwbGUgdHVubmVscywgYW5kIGl0 IGNhdXNlcyBjb25nZXN0aW9uIGZlZWRiYWNrIHRvIG11bHRpcGxlIHRyYWZmaWMgbWFuYWdlbWVu dCBmdW5jdGlvbnMgYXQgdGhlIGluZ3Jlc3NlcyBvZiBhbGwgdGhlIHR1bm5lbHMsIHRoZSBkcmFm dCBnaXZlcyBubyBhZHZpY2Ugb24gaG93IGFsbCB0aGUgdHJhZmZpYyBtYW5hZ2VtZW50IGZ1bmN0 aW9ucyBzaG91bGQgcmVzcG9uZC4NCiogZXRjLiAoaW4gbXkgZnVsbCByZXZpZXcsIEkgd2lsbCBw cm92aWRlIGEgZnVsbCBsaXN0IG9mIHN1YmplY3RzIHRoYXQgYXJlIG91dCBvZiBzY29wZSkuDQpb V2VpXSBPay4NCg0KUy4zLiBGZWVkYmFjayBNb2RlbHM6DQpUaGUgYXJjaGl0ZWN0dXJlIGRpYWdy YW1zIGFuZCB0ZXh0IG5lZWQgdG8gaW5jbHVkZSBjb21wb25lbnRzIHRoYXQgYXBwbHkgYSBjb25z aXN0ZW50IG1lYXN1cmVtZW50IHBvbGljeSAodGVtcGxhdGUgcmVjb3JkcyBpbiBJUEZJWC1zcGVh aykgYXQgYm90aCBpbmdyZXNzIGFuZCBlZ3Jlc3MuIFRoaXMgaXMgYSBrZXkgcGFydCBvZiBpbnRl cm9wZXJhYmlsaXR5LCB3aGljaCBpcyB3aGF0IHRoZSBJRVRGIHNob3VsZCBiZSBhbGwgYWJvdXQu IFRlbXBsYXRlIHJlY29yZHMgYXJlIGRlc2NyaWJlZCBsYXRlciB3aGVuIHRoZSBtZWNoYW5pc20g aXMgc3BlY2lmaWVkLCBidXQgdGhleSBhcmUgbm90IHNob3duIGluIHRoZSBsYXlvdXQgb2YgdGhl IGNvbXBvbmVudHMgaW4gUy4zLg0KW1dlaV0gSSB3aWxsIHByb3ZpZGUgYSBkZXNjcmlwdGlvbiBv ZiBUZW1wbGF0ZSByZWNvcmQgaW4gdGhpcyBzZWN0aW9uLiBCdXQgSSBhbSB3b25kZXJpbmcgd2hl dGhlciBhIGRldGFpbGVkIGRlc2NyaXB0aW9uIG9mIFRlbXBsYXRlIFJlY29yZCBhcyBzZWN0aW9u IDYuMSBpcyBuZWVkZWQgaGVyZSBvciBub3Q/DQpJIHN1Z2dlc3QgdGhhdCwgYXQgdGhpcyBzdGFn ZSBpbiB0aGUgZG9jLCBpdCB3b3VsZCBiZSBiZXN0IG5vdCB0byBiZSBzcGVjaWZpYyB0byBvbmUg dGVjaG5vbG9neSAoSVBGSVgpIGJ1dCBpbnN0ZWFkIHRvIHRhbGsgbW9yZSBnZW5lcmFsbHkgYWJv dXQgc2V0dGluZyBhbmQgc3RvcmluZyBtZWFzdXJlbWVudCBwb2xpY3kgKGF0IHRoZSBkZWNpc2lv biBwb2ludCBhbmQgdGhlIGVncmVzcyBtZXRlcikuDQoNCkJUVywgZGlkIHlvdSBpbnZlbnQgdGhl IHRlcm1pbm9sb2d5IGRlY2lzaW9uIHBvaW50IChEUCkgYW5kIGFjdGlvbiBwb2ludCAoQVApPyBC ZWNhdXNlIHRoZXJlIGlzIGFscmVhZHkgSUVURiB0ZXJtaW5vbG9neSBmb3IgdGhlc2U6DQoqIFBv bGljeSBEZWNpc2lvbiBQb2ludCAoUERQKQ0KKiBQb2xpY3kgRW5mb3JjZW1lbnQgUG9pbnQgKFBF UCkuDQoNClNlZSBDT1BTIChDb21tb24gT3BlbiBQb2xpY3kgU2VydmljZSkgUHJvdG9jb2wgW1JG QzI3NDhdIG9yIHRlcm1pbm9sb2d5IGZvciBwb2xpY3ktYmFzZWQgbWFuYWdlbWVudCBbUkZDMzE5 OF0NCg0KDQoNClMuNC4gQ29uZ2VzdGlvbiBMZXZlbCBNZWFzdXJlbWVudDoNCk1lYXN1cmVtZW50 IG9mIEVDTiBoYXMgYmVlbiBjaGFuZ2VkIHdpdGhvdXQgdGhpbmtpbmcgY2xlYXJseSB3aGV0aGVy IGl0IG5lZWRlZCB0byBjaGFuZ2UuDQoNCiAgICBhKSBFYXJsaWVyIGRyYWZ0cyBleHBsb2l0ZWQg dGhlIGZhY3QgdGhhdCB0aGUgaW5uZXIgaG9sZHMgYSAiZnJvemVuIiByZWNvcmQgb2YgdGhlIEVD TiBmaWVsZCBhdCB0aGUgaW5ncmVzcy4gU28gRUNOIG1lYXN1cmVtZW50cyBjb3VsZCBiZSBtYWRl IHNvbGVseSBhdCB0aGUgZWdyZXNzIChjb21wYXJpbmcgdGhlIG91dGVyIHdpdGggdGhlIGlubmVy KS4gSW4gZHJhZnQtMDQsIEVDTiBjb2RlcG9pbnRzIGFyZSBtZWFzdXJlZCBhdCB0aGUgaW5ncmVz cyBhbmQgYXQgdGhlIGVncmVzcywgd2l0aCB0aGUgaW5ncmVzcyBzZW5kaW5nIHJlZ3VsYXIgbWVh c3VyZW1lbnQgcmVwb3J0cyB0byB0aGUgZWdyZXNzIGZvciBjb21wYXJpc29uLiBIb3dldmVyLCBp dCBpcyBhbHdheXMgc2FmZXIgdG8gbWVhc3VyZSBFQ04gc29sZWx5IGF0IHRoZSBlZ3Jlc3MsIGV2 ZW4gdGhvdWdoIGEgZGlmZmVyZW50IG1lY2hhbmlzbSBoYXMgdG8gbWVhc3VyZSBkcm9wcyB3aXRo aW4gdGhlIHR1bm5lbCAoZHVlIHRvIG5vbi1FQ04gbm9kZXMsIG9yIG5vZGVzIHRoYXQgaGF2ZSBz d2l0Y2hlZCBvZmYgRUNOIGR1ZSB0byBvdmVybG9hZCwgb3IgZHVlIHRvIGNhdXNlcyBvZiBsb3Nz IG90aGVyIHRoYW4gY29uZ2VzdGlvbiwgZS5nLiB0cmFuc21pc3Npb24gZXJyb3JzKS4NCiAgICAg LSBJdCBpcyBhbHdheXMgc2FmZXIgdG8gc29sZWx5IG1lYXN1cmUgRUNOIGF0IHRoZSBlZ3Jlc3Ms IGJlY2F1c2UgaXQgaXMgbm90IHZ1bG5lcmFibGUgdG8gaW5ncmVzcy1lZ3Jlc3MgbWVhc3VyZW1l bnQgcGFja2V0cyBiZWluZyBkcm9wcGVkLg0KICAgICAtIFNvbGVseSBtZWFzdXJpbmcgRUNOIGF0 IGVncmVzcyBpcyBubyBsZXNzIHByZWNpc2UsIGJlY2F1c2Ugb25seSB0aGUgcHJvcG9ydGlvbiBv ZiB0aGUgZGlmZmVyZW50IEVDTiBmaWVsZHMgaXMgbmVlZGVkLCBhbmQgdGhhdCBzdGF5cyBhcHBy b3hpbWF0ZWx5IHRoZSBzYW1lIGV2ZW4gaWYgdGhlcmUgaXMgZHJvcCwgYXNzdW1pbmcgZHJvcCBp cyBub3QgYmlhc2VkIHRvd2FyZHMgY2VydGFpbiBFQ04gY29kZXBvaW50cyAobm8ga25vd24gbWVj aGFuaXNtIGRvZXMgdGhhdCkuDQoNCiAgICBiKSBJbiBkcmFmdC0wNCB0aGUgZmFrZWQgRUNUIGFw cHJvYWNoIGhhcyBiZWVuIGxlZnQgdW5jaGFuZ2VkIGF0IHRoZSBpbmdyZXNzLCBidXQgaXQgaXMg bm8gbG9uZ2VyIHVzZWQgYXQgdGhlIGVncmVzcyBmb3IgZGV0ZWN0aW5nIGRlZmVycmVkIGRyb3Bz IChieSBsb29raW5nIGZvciBhIE5vdC1FQ04gaW5uZXIgYW5kIGEgQ0Ugb3V0ZXIpLiBBZ2Fpbiwg dGhlcmUgaXMgbm90aGluZyB3cm9uZyB3aXRoIG1lYXN1cmluZyBFQ04gYW5kIGRldGVjdGluZyBk ZWZlcnJlZCBkcm9wcyBzb2xlbHkgYXQgdGhlIGVncmVzcywgZXZlbiBpZiB0aGVyZSBhcmUgZHJv cHMgd2l0aGluIHRoZSB0dW5uZWwuIFRvIG1lYXN1cmUgZHJvcHMgd2l0aGluIHRoZSB0dW5uZWws IGl0IGlzIG5lY2Vzc2FyeSB0byBjb21wYXJlIGluZ3Jlc3MgYW5kIGVncmVzcyBieXRlcywgYnV0 IHRoYXQgZG9lcyBub3QgbWFrZSBpdCB3cm9uZyB0byBzdGlsbCBtZWFzdXJlIGFuZCBjb21wYXJl IEVDTiBzb2xlbHkgYXQgdGhlIGVncmVzcy4NCltXZWldIEkgYWdyZWUgdGhhdCBzb2xlbHkgbWVh c3VyaW5nIEVDTiBhdCBlZ3Jlc3MgaXMgZW5vdWdoIHRvIGdldCB0aGUgcHJvcG9ydGlvbiBvZiBk aWZmZXJlbnQgRUNOIGZpZWxkcywgYnV0IHRoZSByZWFzb24gd2h5IEVDTiBjb2RlcG9pbnRzIGFy ZSBtZWFzdXJlZCBib3RoIGF0IGluZ3Jlc3MgYW5kIGVncmVzcyBpcyB0byBtZWFzdXJlIHRoZSBw YWNrZXRzIGRyb3BwZWQgd2l0aGluIHRoZSB0dW5uZWwgYnkgY29tcGFyaW5nIGNvdW50cyBhdCBp bmdyZXNzIGFuZCBlZ3Jlc3MuDQpJIGFtIG5vdCBzYXlpbmcgeW91IHNob3VsZCBub3QgYWxzbyBt ZWFzdXJlIGRyb3AgYnkgbWVhc3VyaW5nIHRvdGFsIGJ5dGVzIGF0IGluZ3Jlc3MgYW5kIGVncmVz cy4NCg0KSG93ZXZlciwgSSBhbSBzYXlpbmcgaXQgaXMgbGVzcyByb2J1c3QgdG8gaGF2ZSB0byBt ZWFzdXJlIGF0IGJvdGggaW5ncmVzcyBhbmQgZWdyZXNzLCBiZWNhdXNlIGl0IGludm9sdmVzIHNl bmRpbmcgc3luY2ggLyBtZWFzdXJlbWVudCBtZXNzYWdlcyBmcm9tIGluZ3Jlc3MgdG8gZWdyZXNz LCB3aGljaCBjYW4gYmUgbG9zdC9kZWxheWVkLg0KU28sIEkgd291bGQgcmVjb21tZW5kIHRoZSBt b3JlIHJvYnVzdCBlZ3Jlc3Mtb25seSBtZXRob2QgZm9yIEVDTiwgYW5kIHRoZSBpbmdyZXNzLWVn cmVzcyBtZXRob2Qgb25seSBmb3IgdG90YWwgZHJvcC4NCg0KVGhlIG9ubHkgZXh0cmEgdGhpbmcg eW91IGxlYXJuIGJ5IHRoZSBjdXJyZW50bHkgcHJvcG9zZWQgYXBwcm9hY2ggaXMgaG93IG1hbnkg b2YgZWFjaCBFQ04gY29kZXBvaW50IHdlcmUgZHJvcHBlZC4gSWYgeW91IHRoaW5rIHRoYXQncyBp bXBvcnRhbnQsIGFyZ3VlIGZvciBpdC4gSSBkb24ndCBzZWUgYW55IG5lZWQgZm9yIGl0IHRoby4N Cg0KSWYgeW91IGluc2lzdCBvbiBrZWVwaW5nIHRoZSBpbmdyZXNzLWVncmVzcyBhcHByb2FjaCwg d2h5IGRvIHlvdSBuZWVkIHRoZSBmYWtlZCBFQ04gdGV4dD8NCg0KDQoNCg0KUy40LiBDb25nZXN0 aW9uIExldmVsIE1lYXN1cmVtZW50OiBVbml0cw0KVGhyb3VnaG91dCBtZWFzdXJlbWVudCBpbnZv bHZlcyBjb3VudGluZyBwYWNrZXRzLiBIb3dldmVyLCBpdCBzaG91bGQgY291bnQgdGhlIGJ5dGVz IGluIHBhY2tldHMgd2l0aCBlYWNoIHR5cGUgb2YgbWFya2luZywgbm90IGp1c3QgdGhlIG51bWJl ciBvZiBwYWNrZXRzLiBTZWUgUkZDNzE0MSBzZWN0aW9uIDIuMzxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzE0MSNzZWN0aW9uLTIuMz4uIEFsdGhvdWdoIHRoZSByZWNvbW1lbmRhdGlv biBpbiB0aGF0IFJGQyBpcyBhYm91dCB3aGF0IGEgL3RyYW5zcG9ydC8gc2hvdWxkIG1lYXN1cmUg d2hlbiByZXNwb25kaW5nIHRvIGNvbmdlc3Rpb24sIGxvZ2ljYWxseSBpdCBzaG91bGQgYXBwbHkg aW4gdGhpcyBjYXNlIHdoZW4gYSB0cmFmZmljIG1hbmFnZW1lbnQgZnVuY3Rpb24gaXMgcmVzcG9u ZGluZyBpbiBwbGFjZSBvZiBhIHRyYW5zcG9ydC4gUkZDNzE0MSBhbHNvIGdpdmVzIHJlY29tbWVu ZGF0aW9ucyBvbiB3aGljaCBoZWFkZXJzIHRvIGNvdW50Lg0KW1dlaV0gT2ssIGl04oCZcyBhIGdv b2Qgc3VnZ2VzdGlvbi4NCg0KDQoNCkkgc2hhbGwgYWRkIHRvIHRoaXMgcmV2aWV3IGxhdGVyIGlu IHRoZSB3ZWVrLg0KDQpPbmUgcXVlc3Rpb24gZm9yIFdlaXhpbnBlbmc6IEhhdmUgeW91IGltcGxl bWVudGVkIHRoaXMgbWVjaGFuaXNtPw0KW1dlaV0gQ3VycmVudGx5LCB3ZSBvbmx5IGltcGxlbWVu dCB0aGlzIG1lY2hhbmlzbSBpbiBhIHNpbXVsYXRpb24gZW52aXJvbm1lbnQuDQpJIHN1c3BlY3Rl ZCBhcyBtdWNoLCBiZWNhdXNlIHRoZSBsYWNrIG9mIGRldGFpbCBpbiBzb21lIHBsYWNlcyBpbXBs aWVzIGl0IGlzIGEgYml0IHRoZW9yZXRpY2FsLg0KSSB3b3VsZCBlbmNvdXJhZ2UgeW91IHRvIGlt cGxlbWVudC4NCg0KDQoNCkJvYg0KDQoNCg0KQm9iDQoNCg0KT24gMDEvMTEvMTYgMDE6NDksIFdl aXhpbnBlbmcgKEphY2tpZSkgd3JvdGU6DQpIaSBCb2IgYW5kIERhdmlkLA0KQmVjYXVzZSB0aGUg ZGVhZGxpbmUgaGFzIHBhc3NlZCwgSSB3aWxsIHVwZGF0ZSBpdCBhcyBwYXJ0IG9mIHBvc3QtV0dM QyB1cGRhdGUuIFRoYW5rcy4NCg0KUmVnYXJkcywNCi1YaW5wZW5nIChKYWNraWUpDQoNCkZyb206 IEJsYWNrLCBEYXZpZCBbbWFpbHRvOkRhdmlkLkJsYWNrQGRlbGwuY29tXQ0KU2VudDogVHVlc2Rh eSwgTm92ZW1iZXIgMDEsIDIwMTYgMTI6MTQgQU0NClRvOiBCb2IgQnJpc2NvZTsgV2VpeGlucGVu ZyAoSmFja2llKTsgZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0 b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1m ZWVkYmFja0B0b29scy5pZXRmLm9yZz4NCkNjOiB0c3Z3ZyBJRVRGIGxpc3Q7IEJsYWNrLCBEYXZp ZA0KU3ViamVjdDogUkU6IFR1bm5lbCBDb25nZXN0aW9uIEZlZWRiYWNrOiAobm9uLSl1cGRhdGUg dG8gUkZDNjA0MA0KDQo+IEkgYXNzdW1lIHlvdSB3aWxsIHVwZGF0ZSB0aGUgVENGIGRyYWZ0IHRv ZGF5IGJlZm9yZSB0aGUgZGVhZGxpbmUuDQoNCihBcyBkcmFmdCBzaGVwaGVyZCkgVGhhdOKAmXMg bm90IHJlYWxseSBuZWNlc3NhcnkgLSB0aGUgVENGIGRyYWZ0IGlzIGluIFdHTEMsIHNvIHRoaXMg Y2hhbmdlIGNhbiBiZSBkb25lIGFzIHBhcnQgb2YgYSBwb3N0LVdHTEMgdXBkYXRlLg0KDQpUaGFu a3MsIC0tRGF2aWQNCg0KRnJvbTogQm9iIEJyaXNjb2UgW21haWx0bzppZXRmQGJvYmJyaXNjb2Uu bmV0XQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDMxLCAyMDE2IDExOjIyIEFNDQpUbzogV2VpeGlu cGVuZyAoSmFja2llKTsgQmxhY2ssIERhdmlkOyBkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25n ZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRzdndnLXR1 bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnPg0KQ2M6IHRzdndnIElFVEYg bGlzdA0KU3ViamVjdDogUmU6IFR1bm5lbCBDb25nZXN0aW9uIEZlZWRiYWNrOiAobm9uLSl1cGRh dGUgdG8gUkZDNjA0MA0KDQpYaW5wZW5nLA0KDQpJIGFncmVlIHRoYXQgVENGIGRvZXMgbm90IHVw ZGF0ZSBSRkM2MDQwIChhcyBJIHNhaWQpLg0KDQpCdXQgRGF2aWQgaXMgcmlnaHQgdGhhdCB0aGUg VENGIGRyYWZ0IGl0c2VsZiBuZWVkcyB0byBiZSB1cGRhdGVkIHRvIHNheSB0aGF0IGl0IG1vZGlm aWVzIHRoZSBiZWhhdmlvdXIgb2YgYSBSRkM2MDQwIGVncmVzcyBzbyBhcyB0byBpc3N1ZSBvciBs b2cgYW55IHdhcm5pbmdzIHdoZW4gaXQgcmVjZWl2ZXMgYW4gRUNUKDApIG9yIENFIG91dGVyIHdp dGggYSBOb3QtRUNUIGlubmVyLg0KDQpJIGFzc3VtZSB5b3Ugd2lsbCB1cGRhdGUgdGhlIFRDRiBk cmFmdCB0b2RheSBiZWZvcmUgdGhlIGRlYWRsaW5lLg0KDQpDaGVlcnMNCg0KQm9iDQpPbiAzMS8x MC8xNiAwMjozOCwgV2VpeGlucGVuZyAoSmFja2llKSB3cm90ZToNCkhpIERhdmlkLCBCb2IsDQpJ IGFncmVlIHRoYXQgdGhlIGJlaGF2aW9yIGRlZmluZWQgaW4gUkZDNjA0MCBkb2VzbuKAmXQgdG8g YmUgdXBkYXRlZCBkdWUgdG8gdGhlIFRDRiBkcmFmdCwgYmVjYXVzZSB3aGF04oCZcyBkZWZpbmVk IGluIFJGQyA2MDQwIGhhcyBhIGJyb2FkZXIgdXNhZ2UgYW5kIG5vdCBqdXN0IGZvciBUQ0YuDQpJ IHRoaW5rIERhdmlkIGhhcyBwcm92aWRlZCBhIGdvb2Qgc3VnZ2VzdGlvbiBiZWxvdy4gVGhhbmtz Lg0KDQpSZWdhcmRzLA0KLVhpbnBlbmcgKEphY2tpZSkNCg0KRnJvbTogdHN2d2cgW21haWx0bzp0 c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmxhY2ssIERhdmlkDQpTZW50OiBT YXR1cmRheSwgT2N0b2JlciAyOSwgMjAxNiAxMDoyOCBBTQ0KVG86IEJvYiBCcmlzY29lOyBkcmFm dC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnPG1h aWx0bzpkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmll dGYub3JnPg0KQ2M6IHRzdndnIElFVEYgbGlzdA0KU3ViamVjdDogUmU6IFt0c3Z3Z10gVHVubmVs IENvbmdlc3Rpb24gRmVlZGJhY2s6IChub24tKXVwZGF0ZSB0byBSRkM2MDQwDQoNCkJvYiwNCg0K SSB0aGluayB5b3XigJl2ZSBmb3VuZCBzb21ldGhpbmcuICBUaGUgVENGIGRyYWZ0IGN1cnJlbnRs eSB1c2VzIFJGQyA2MDQwIGJlaGF2aW9yIGJ5IHJlZmVyZW5jZToNCg0KICAgd2hlbiBkZWNhcHN1 bGF0aW5nIHBhY2tldHMgYXQgZWdyZXNzLA0KICAgUkZDNjA0MCBkZWZpbmVkIGRlY2Fwc3VsYXRp b24gYmVoYXZpb3IgaXMgdXNlZCwgYW5kIGFjY29yZGluZyB0bw0KICAgUkZDNjA0MCwgdGhlIHBh Y2tldHMgbWFya2VkIGFzIENFfE4tRUNUIHdpbGwgYmUgZHJvcHBlZCBieSBlZ3Jlc3MuDQoNCkkg dGhpbmsgdGhpcyBuZWVkcyB0byBiZSBzbGlnaHRseSByZXZpc2VkIHRvIHNheSB0aGF0IENFfE4t RUNUIGlzIGRyb3BwZWQgd2l0aG91dCBhbnkgb3RoZXINCmFjdGlvbiwgYW5kIGFsbCBvdGhlciBi ZWhhdmlvciBpcyBhcyBwZXIgUkZDIDYwNDAsIGFzIENFfE4tRUNUIGlzIGV4cGVjdGVkIGF0IGEg VENGIGVncmVzcyBhbmQNCmhlbmNlIHRoZSBsb2dnaW5nIGFuZCBhbGFybSBiZWhhdmlvciBmb3Ig dGhhdCBjb21iaW5hdGlvbiBpbiBSRkMgNjA0MCBpcyBpbmFwcHJvcHJpYXRlLg0KDQpPbmNlIHRo YXTigJlzIGRvbmUsIEkgdGhpbmsgeW91ciByZWFzb25pbmcgaW4gdGhlIGZvbGxvd2luZyBzZW50 ZW5jZSBiZWNvbWVzIGNvcnJlY3Q6DQoNCklmIHRoZSBuZXR3b3JrIGlzIG5vdCB2YWxpZCwgdGhl c2UgY29tYmluYXRpb24gY291bGQgYmVjb21lIHZpc2libGUgdG8gYSA2MDQwLWRlY2FwLA0Kd2hp Y2ggd291bGQgdGhlbiAoY29ycmVjdGx5KSBsb2cgd2FybmluZ3MgdGhhdCBpdCB3YXMgc2VlaW5n IGludmFsaWQgY29kZXBvaW50IGNvbWJpbmF0aW9ucy4NCg0KVGhhbmtzLCAtLURhdmlkIChhcyBk cmFmdCBzaGVwaGVyZCkNCg0KRnJvbTogQm9iIEJyaXNjb2UgW21haWx0bzppZXRmQGJvYmJyaXNj b2UubmV0XQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjcsIDIwMTYgNDozOSBQTQ0KVG86IGRy YWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMu aWV0Zi5vcmc+OyBCbGFjaywgRGF2aWQNCkNjOiB0c3Z3ZyBJRVRGIGxpc3QNClN1YmplY3Q6IFR1 bm5lbCBDb25nZXN0aW9uIEZlZWRiYWNrOiAobm9uLSl1cGRhdGUgdG8gUkZDNjA0MA0KDQpUdW5u ZWwgY29uZ2VzdGlvbiBmZWVkYmFjayBhdXRob3JzLCBEYXZpZCBhcyBzaGVwaGVyZCwNCg0KRllJ LiBObyBhY3Rpb24gbmVlZGVkLg0KDQpUaGlzIGVtYWlsIGRvY3VtZW50cyBhbiBhcmd1bWVudCB3 aXRoIG15c2VsZi4gQWZ0ZXIgYSBmZXcgc2Vjb25kcywgSSBhZ3JlZWQgd2l0aCBteXNlbGYgdGhh dCBvbmUgb2YgbWUgd2FzIHdyb25nLiBJIHRob3VnaHQgSSBoYWQgYmV0dGVyIHJhaXNlIHRoaXMg b24gdGhlIGxpc3QsIHRvIGNoZWNrIHRoYXQgb3RoZXJzIGFncmVlIHdpdGggYm90aCBvZiBtZS4g SWYgeW91IHdpc2ggdG8gYXJndWUgd2l0aCBqdXN0IG9uZSBvZiBtZSwgcGxlYXNlIGJlYXIgaW4g bWluZCB0aGF0IHdlIGJvdGggaGF2ZSB0aGUgc2FtZSBlbWFpbCBhZGRyZXNzIChhbmQgYW55d2F5 LCB3ZSBib3RoIGFncmVlIHNvIGFuIGFyZ3VtZW50IHdpdGggb25lIGlzIGFuIGFyZ3VtZW50IHdp dGggYWxsKS4NCl9fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRmlndXJlIDQgb2YgUkZDNjA0 MCBzcGVjaWZpZXMgd2hpY2ggRUNOIGNvZGVwb2ludCBhIGRlY2FwIG11c3QgZm9yd2FyZCwgZm9y IGVhY2ggY29tYmluYXRpb24gb2YgYXJyaXZpbmcgaW5uZXIgKHJvdykgYW5kIG91dGVyIChjb2x1 bW4pLg0KDQogICAgICAgICAgICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAgfEFycml2aW5nIHwgICAgICAg ICAgICBBcnJpdmluZyBPdXRlciBIZWFkZXIgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAg IHwgICBJbm5lciArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tKw0KDQogICAgICAgICAgICB8ICBIZWFkZXIgfCBOb3QtRUNUIHwgRUNUKDApICAgICB8IEVD VCgxKSAgICAgfCAgICAgQ0UgICAgIHwNCg0KICAgICAgICAgICAgKy0tLS0tLS0tLSstLS0tLS0t LS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAg IHwgTm90LUVDVCB8IE5vdC1FQ1QgfE5vdC1FQ1QoISEhKXxOb3QtRUNUKCEhISl8IDxkcm9wPigh ISEpfA0KDQogICAgICAgICAgICB8ICBFQ1QoMCkgfCAgRUNUKDApIHwgRUNUKDApICAgICB8IEVD VCgxKSAgICAgfCAgICAgQ0UgICAgIHwNCg0KICAgICAgICAgICAgfCAgRUNUKDEpIHwgIEVDVCgx KSB8IEVDVCgxKSAoISkgfCBFQ1QoMSkgICAgIHwgICAgIENFICAgICB8DQoNCiAgICAgICAgICAg IHwgICAgQ0UgICB8ICAgICAgQ0UgfCAgICAgQ0UgICAgIHwgICAgIENFKCEhISl8ICAgICBDRSAg ICAgfA0KDQogICAgICAgICAgICArLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNClJGQzYwNDAgZ29lcyBvbiB0byBzYXk6DQoNCiAgICAg ICAgICAgICAgICAgICAgICBbLi4uXSBUaGVzZSBjdXJyZW50bHkgdW51c2VkIChDVSkgY29tYmlu YXRpb25zIGFyZQ0KDQogICAgICBpbmRpY2F0ZWQgaW4gRmlndXJlIDQgYnkgJyghISEpJyBvciAn KCEpJywgd2hlcmUgJyghISEpJyBtZWFucyB0aGUNCg0KICAgICAgY29tYmluYXRpb24gaXMgQ1Ug YW5kIGFsd2F5cyBwb3RlbnRpYWxseSBkYW5nZXJvdXMsIHdoaWxlICcoISknDQoNCiAgICAgIG1l YW5zIGl0IGlzIENVIGFuZCBwb3NzaWJseSBkYW5nZXJvdXMuICBJbiB0aGVzZSBjYXNlcywNCg0K ICAgICAgcGFydGljdWxhcmx5IHRoZSBtb3JlIGRhbmdlcm91cyBvbmVzLCB0aGUgZGVjYXBzdWxh dG9yIFNIT1VMRCBsb2cNCg0KICAgICAgdGhlIGV2ZW50IGFuZCBNQVkgYWxzbyByYWlzZSBhbiBh bGFybS4NCg0KDQpUQ0YgdXNlcyB0aGUgZm9sbG93aW5nIGNvbWJpbmF0aW9ucyBvZiBpbm5lciA6 IG91dGVyDQogICAgTm90LUVDVCA6IEVDVCgwKQ0KICAgIE5vdC1FQ1QgOiBDRQ0KDQpGb3IgYSBt b21lbnQsIEkgdGhvdWdodCB3ZSB3b3VsZCBoYXZlIHRvIHVwZGF0ZSBSRkM2MDQwIHRvIHNheSB0 aGF0IFRDRiBtYWtlcyB0aGVzZSBjb21iaW5hdGlvbnMgbm8gbG9uZ2VyIENVLCBzbyB0aGV5IGFy ZSBub3cgdmFsaWQsIG5vdCBkYW5nZXJvdXMsIGFuZCB0aGV5IG5vIGxvbmdlciBuZWVkIHRvIGJl IGxvZ2dlZC4gVGhpcyB3b3VsZCBoYXZlIG1lYW50IHRoYXQgVHVubmVsIENvbmdlc3Rpb24gRmVl ZGJhY2sgKFRDRikgKGluZm9ybWF0aW9uYWwpIHdvdWxkIGhhdmUgdG8gdXBkYXRlIFJGQzYwNDAg KHByb3Bvc2VkIHN0YW5kYXJkKS4NCg0KSGVyZSdzIHdoeSBJIHdhcyB3cm9uZy4gVGhlc2UgdHdv IGNvbWJpbmF0aW9ucyBhcmUgY2VydGFpbmx5IHZhbGlkIGF0IGEgVENGIGRlY2FwLiBCdXQgdGhl cmUgaXMgc3RpbGwgbm8gd2F5IHRoYXQsIGluIGEgdmFsaWQgbmV0d29yaywgdGhleSB3b3VsZCBh cnJpdmUgYXQgYW55IFJGQzYwNDAgKG5vbi1UQ0YpIGRlY2FwLg0KDQpPbmUgbWlnaHQgdGhpbmsg dGhhdCB0aGlzIGNvbWJpbmF0aW9uIGNvdWxkIGFycml2ZSBhdCBhIDYwNDAtZGVjYXAgaWYgdGhl cmUgd2FzIGEgdHVubmVsIGluc2lkZSBhIHR1bm5lbCwgYXMgZm9sbG93cw0KDQogIFRDRi1lbmNh cCAgICAgICAgICAgICAgICAgLS0tPiA2MDQwLWRlY2FwIC0tLT4gVENGLWRlY2FwDQoNCkhvd2V2 ZXIsIHRoYXQncyBub3QgYSB2YWxpZCBjb25maWd1cmF0aW9uLiBUaGUgZm9sbG93aW5nIHR1bm5l bC1pbi10dW5uZWwgd291bGQgYmUgdmFsaWQ6DQoNCiAgVENGLWVuY2FwIC0tLT4gNjA0MC1lbmNh cCAtLS0+IDYwNDAtZGVjYXAgLS0tPiBUQ0YtZGVjYXANCg0KLi4udGhlbiwgdGhlIGFib3ZlIHR3 byAiQ1UiIGNvbWJpbmF0aW9ucyB3b3VsZCBiZSBidXJpZWQgd2l0aGluIGEgZG91YmxlIGlubmVy LCBzbyBvbmx5IHRoZSBUQ0YgZGVjYXAgd291bGQgc2VlIHRoZW0sIG5vdCB0aGUgNjA0MC1kZWNh cC4NCg0KU28sIFRDRiBkb2VzIG5vdCBuZWVkIHRvIHVwZGF0ZSBSRkM2MDQwLiBCZWNhdXNlLCBp biBhIHZhbGlkIG5ldHdvcmssIFRDRiB3aWxsIGJlIGhpZGRlbiBmcm9tIGFueSA2MDQwLWRlY2Fw LiBJZiB0aGUgbmV0d29yayBpcyBub3QgdmFsaWQsIHRoZXNlIGNvbWJpbmF0aW9uIGNvdWxkIGJl Y29tZSB2aXNpYmxlIHRvIGEgNjA0MC1kZWNhcCwgd2hpY2ggd291bGQgdGhlbiAoY29ycmVjdGx5 KSBsb2cgd2FybmluZ3MgdGhhdCBpdCB3YXMgc2VlaW5nIGludmFsaWQgY29kZXBvaW50IGNvbWJp bmF0aW9ucy4NCg0KSSBqdXN0IHRob3VnaHQgeW91J2QgbGlrZSB0byBrbm93Li4uIG5vIGFjdGlv biByZXF1aXJlZC4NCg0KDQoNCkJvYg0KDQotLQ0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlz Y29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8N Cg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0KDQoNCg0KLS0NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpC b2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9iYnJpc2Nv ZS5uZXQvDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg== --_000_CE03DB3D7B45C245BCA0D243277949362F9B3F09MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBh bm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IFwsIHNlcmlmIjsNCglwYW5v c2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpwLkhUTUwsIGxpLkhUTUwsIGRpdi5I VE1MDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLmEsIGxpLmEsIGRpdi5hDQoJe21zby1zdHlsZS1u YW1lOuaJueazqOahhuaWh+acrDsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6Ymxh Y2s7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+ac rDsNCglmb250LWZhbWlseTpTaW1TdW47DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1z dHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQpzcGFuLkVtYWlsU3R5 bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiM5OTMzNjY7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFs Ow0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J4oCZbSBhbW9uZyB0aG9zZSByZXNwb25zaWJsZSBm b3IgdGhlIGluZ3Jlc3MtZWdyZXNzIG1lYXN1cmVtZW50IGFkZGl0aW9uLCBzbyB3ZWlnaGluZyBp biBhcyBkcmFmdCBzaGVwaGVyZDo8bzpwPjwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSG93ZXZlciwgSSBhbSBz YXlpbmcgaXQgaXMgbGVzcyByb2J1c3QgdG8gaGF2ZSB0byBtZWFzdXJlIGF0IGJvdGggaW5ncmVz cyBhbmQgZWdyZXNzLCBiZWNhdXNlIGl0IGludm9sdmVzIHNlbmRpbmcgc3luY2ggLyBtZWFzdXJl bWVudDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBtZXNzYWdlcyBm cm9tIGluZ3Jlc3MgdG8gZWdyZXNzLCB3aGljaCBjYW4gYmUgbG9zdC9kZWxheWVkLiAmbmJzcDtT bywgSSB3b3VsZCByZWNvbW1lbmQgdGhlIG1vcmUgcm9idXN0IGVncmVzcy1vbmx5IG1ldGhvZCBm b3IgRUNOLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBhbmQgdGhl IGluZ3Jlc3MtZWdyZXNzIG1ldGhvZCBvbmx5IGZvciB0b3RhbCBkcm9wLjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoYXQgc2VlbXMgZmluZSwgaG93ZXZlciB0aGUgdG90YWwgZHJvcCBpbmZvIGRv ZXMgbmVlZCB0byBiZSByZXBvcnRlZCBpbiBhZGRpdGlvbiB0byBFQ04gaW5mby48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IFRoZSBvbmx5IGV4 dHJhIHRoaW5nIHlvdSBsZWFybiBieSB0aGUgY3VycmVudGx5IHByb3Bvc2VkIGFwcHJvYWNoIGlz IGhvdyBtYW55IG9mIGVhY2ggRUNOIGNvZGVwb2ludCB3ZXJlIGRyb3BwZWQuIElmIHlvdSB0aGlu ayB0aGF0J3MgaW1wb3J0YW50LCBhcmd1ZSBmb3IgaXQuIEkgZG9uJ3Qgc2VlIGFueSBuZWVkIGZv ciBpdCB0aG8uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIHdvdWxkIGFncmVlLjwvc3Bhbj48YnI+DQo8YnI+DQomZ3Q7IElmIHlvdSBpbnNp c3Qgb24ga2VlcGluZyB0aGUgaW5ncmVzcy1lZ3Jlc3MgYXBwcm9hY2gsIHdoeSBkbyB5b3UgbmVl ZCB0aGUgZmFrZWQgRUNOIHRleHQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PklmIG9uZSBpcyB0cnlpbmcgdG8gbWVhc3VyZSBjb25nZXN0aW9uIGluIHRoZSB0dW5uZWwsIGRy b3BzIGhhdmUgdG8gYmUgY29uc2lkZXJlZCDigJMgZXZlbiBpZiBhbGwgbm9kZXMgaW4gdGhlIHR1 bm5lbCBzdXBwb3J0IEVDTiwgYW4gb3ZlcmxvYWRlZCBFQ04gbm9kZSB3aWxsIGRyb3ANCiBwYWNr ZXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgcmVhc29uIGZvciBmYWtlZC1FQ04gaXMgYnVyaWVk IGluIEJvYuKAmXMg4oCcbW9yZSByb2J1c3TigJ0gY29tbWVudCBhYm91dCBlZ3Jlc3Mtb25seSBF Q04gbWVhc3VyZW1lbnQgYWJvdmUg4oCTIHVzZSBvZiBFQ04gc2hvdWxkIHJlc3VsdCBpbiBiZXR0 ZXIgbWVhc3VyZW1lbnRzIGJ5DQogY29tcGFyaXNvbiB0byBub24tdXNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgLS1EYXZpZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlz Y29lIFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIEFwcmlsIDcsIDIwMTcgMTA6NDggQU08YnI+DQo8Yj5Ubzo8L2I+IFdlaXhpbnBlbmcgKEph Y2tpZSkgJmx0O3dlaXhpbnBlbmdAaHVhd2VpLmNvbSZndDs7IEJsYWNrLCBEYXZpZCAmbHQ7ZGF2 aWQuYmxhY2tAZW1jLmNvbSZndDs7IGRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24t ZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IHRzdndnIElFVEYgbGlzdCAm bHQ7dHN2d2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBUdW5uZWwgQ29u Z2VzdGlvbiBGZWVkYmFjazogKG5vbi0pdXBkYXRlIHRvIFJGQzYwNDA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPldlaXhpbnBlbmcsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gMDUvMDQvMTcgMDM6NDUsIFdlaXhpbnBlbmcgKEphY2tpZSkgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkhpIEJvYiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB5b3VyIGNv bW1lbnRzLCBhbmQgcGxlYXNlIHNlZSBpbmxpbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPi1YaW5wZW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPiBCb2IgQnJpc2NvZSBbPGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2Nv ZS5uZXQiPm1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiBNb25kYXksIEFwcmlsIDAzLCAyMDE3IDU6MzQgQU08YnI+DQo8Yj5Ubzo8L2I+IFdlaXhpbnBl bmcgKEphY2tpZSk7IEJsYWNrLCBEYXZpZDsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdHN2 d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtaWV0 Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9yZzwvYT48YnI+ DQo8Yj5DYzo8L2I+IHRzdndnIElFVEYgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVHVu bmVsIENvbmdlc3Rpb24gRmVlZGJhY2s6IChub24tKXVwZGF0ZSB0byBSRkM2MDQwPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5XZWl4aW5wZW5nLCBjby1hdXRob3JzLCZuYnNwOyBhbmQgRGF2aWQsPGJyPg0K PGJyPg0KSSBoYWQgcHJvbWlzZWQgYSByZXZpZXcgb2YgdGhlIGxhdGVzdCBUQ0YgZHJhZnQsIGJ1 dCBmYWlsZWQgdG8gcHJvdmlkZSBpdCBzbyBmYXIuPGJyPg0KSSBoYWxmIHJlYWQgaXQgdGhyb3Vn aCBvbiBGcmlkYXksIGFuZCBJIHdpbGwgZmluaXNoIGFuZCB3cml0ZSB1cCBteSByZXZpZXcgdGhp cyB3ZWVrLjxicj4NCjxicj4NCkhlcmUnIGEgcXVpY2sgc3VtbWFyeSBvZiB0aGUgbWFpbiBwb2lu dHMgc28gZmFyOiA8YnI+DQo8YnI+DQo8Yj5TLjEuIEludHJvOiBNb3RpdmF0aW9uPGJyPg0KPC9i PlRoZSBtb3RpdmF0aW9uIHNob3VsZCBhbHNvIGluY2x1ZGUgYSBoZWF2eSBsb2FkIGZyb20gYSBt dWNoIGxhcmdlciB0aGFuIGV4cGVjdGVkIG51bWJlciBvZiByZXNwb25zaXZlIGZsb3dzPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bV2VpXSBPaywgSSB3aWxs IGFkZCBpdC48L3NwYW4+PC9pPjwvYj48YnI+DQo8YnI+DQo8Yj5TLjEgSW50cm86IFNjb3BlPGJy Pg0KPC9iPkkgdGhpbmsgdGhlIGRyYWZ0IHNob3VsZCBzYXkgdGhhdDxicj4NCiogaXQgZ2l2ZXMg bm8gYWR2aWNlIG9uIGhvdyB0byBzZWxlY3Qgd2hpY2ggdHVubmVsIGVuZHBvaW50cyBzaG91bGQg YmUgdXNlZCBpbiBvcmRlciB0byBtYW5hZ2UgdHJhZmZpYyBvdmVyIGEgbmV0d29yayBjcmlzcy1j cm9zc2VkIGJ5IG11bHRpcGxlIHR1bm5lbHMuDQo8YnI+DQoqIGlmIGEgY29uZ2VzdGVkIG5vZGUg aXMgcGFydCBvZiBtdWx0aXBsZSB0dW5uZWxzLCBhbmQgaXQgY2F1c2VzIGNvbmdlc3Rpb24gZmVl ZGJhY2sgdG8gbXVsdGlwbGUgdHJhZmZpYyBtYW5hZ2VtZW50IGZ1bmN0aW9ucyBhdCB0aGUgaW5n cmVzc2VzIG9mIGFsbCB0aGUgdHVubmVscywgdGhlIGRyYWZ0IGdpdmVzIG5vIGFkdmljZSBvbiBo b3cgYWxsIHRoZSB0cmFmZmljIG1hbmFnZW1lbnQgZnVuY3Rpb25zIHNob3VsZCByZXNwb25kLjxi cj4NCiogZXRjLiAoaW4gbXkgZnVsbCByZXZpZXcsIEkgd2lsbCBwcm92aWRlIGEgZnVsbCBsaXN0 IG9mIHN1YmplY3RzIHRoYXQgYXJlIG91dCBvZiBzY29wZSkuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bV2VpXSBPay48L3NwYW4+PC9pPjwvYj48YnI+DQo8 YnI+DQo8Yj5TLjMuIEZlZWRiYWNrIE1vZGVsczogPGJyPg0KPC9iPlRoZSBhcmNoaXRlY3R1cmUg ZGlhZ3JhbXMgYW5kIHRleHQgbmVlZCB0byBpbmNsdWRlIGNvbXBvbmVudHMgdGhhdCBhcHBseSBh IGNvbnNpc3RlbnQgbWVhc3VyZW1lbnQgcG9saWN5ICh0ZW1wbGF0ZSByZWNvcmRzIGluIElQRklY LXNwZWFrKSBhdCBib3RoIGluZ3Jlc3MgYW5kIGVncmVzcy4gVGhpcyBpcyBhIGtleSBwYXJ0IG9m IGludGVyb3BlcmFiaWxpdHksIHdoaWNoIGlzIHdoYXQgdGhlIElFVEYgc2hvdWxkIGJlIGFsbCBh Ym91dC4gVGVtcGxhdGUNCiByZWNvcmRzIGFyZSBkZXNjcmliZWQgbGF0ZXIgd2hlbiB0aGUgbWVj aGFuaXNtIGlzIHNwZWNpZmllZCwgYnV0IHRoZXkgYXJlIG5vdCBzaG93biBpbiB0aGUgbGF5b3V0 IG9mIHRoZSBjb21wb25lbnRzIGluIFMuMy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPltXZWldIEkgd2lsbCBwcm92aWRlIGEgZGVzY3JpcHRpb24gb2YgVGVt cGxhdGUgcmVjb3JkIGluIHRoaXMgc2VjdGlvbi4gQnV0IEkgYW0gd29uZGVyaW5nIHdoZXRoZXIg YSBkZXRhaWxlZCBkZXNjcmlwdGlvbiBvZg0KIFRlbXBsYXRlIFJlY29yZCBhcyBzZWN0aW9uIDYu MSBpcyBuZWVkZWQgaGVyZSBvciBub3Q/PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VnZ2VzdCB0aGF0 LCBhdCB0aGlzIHN0YWdlIGluIHRoZSBkb2MsIGl0IHdvdWxkIGJlIGJlc3Qgbm90IHRvIGJlIHNw ZWNpZmljIHRvIG9uZSB0ZWNobm9sb2d5IChJUEZJWCkgYnV0IGluc3RlYWQgdG8gdGFsayBtb3Jl IGdlbmVyYWxseSBhYm91dCBzZXR0aW5nIGFuZCBzdG9yaW5nIG1lYXN1cmVtZW50IHBvbGljeSAo YXQgdGhlIGRlY2lzaW9uIHBvaW50IGFuZCB0aGUgZWdyZXNzIG1ldGVyKS48YnI+DQo8YnI+DQpC VFcsIGRpZCB5b3UgaW52ZW50IHRoZSB0ZXJtaW5vbG9neSBkZWNpc2lvbiBwb2ludCAoRFApIGFu ZCBhY3Rpb24gcG9pbnQgKEFQKT8gQmVjYXVzZSB0aGVyZSBpcyBhbHJlYWR5IElFVEYgdGVybWlu b2xvZ3kgZm9yIHRoZXNlOjxicj4NCiogUG9saWN5IERlY2lzaW9uIFBvaW50IChQRFApPGJyPg0K KiBQb2xpY3kgRW5mb3JjZW1lbnQgUG9pbnQgKFBFUCkuPGJyPg0KPGJyPg0KU2VlIENPUFMgKENv bW1vbiBPcGVuIFBvbGljeSBTZXJ2aWNlKSBQcm90b2NvbCBbUkZDMjc0OF0gb3IgdGVybWlub2xv Z3kgZm9yIHBvbGljeS1iYXNlZCBtYW5hZ2VtZW50IFtSRkMzMTk4XTxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8Yj5TLjQuIENvbmdl c3Rpb24gTGV2ZWwgTWVhc3VyZW1lbnQ6PGJyPg0KPC9iPk1lYXN1cmVtZW50IG9mIEVDTiBoYXMg YmVlbiBjaGFuZ2VkIHdpdGhvdXQgdGhpbmtpbmcgY2xlYXJseSB3aGV0aGVyIGl0IG5lZWRlZCB0 byBjaGFuZ2UuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGEpIEVhcmxpZXIgZHJhZnRz IGV4cGxvaXRlZCB0aGUgZmFjdCB0aGF0IHRoZSBpbm5lciBob2xkcyBhICZxdW90O2Zyb3plbiZx dW90OyByZWNvcmQgb2YgdGhlIEVDTiBmaWVsZCBhdCB0aGUgaW5ncmVzcy4gU28gRUNOIG1lYXN1 cmVtZW50cyBjb3VsZCBiZSBtYWRlIHNvbGVseSBhdCB0aGUgZWdyZXNzIChjb21wYXJpbmcgdGhl IG91dGVyIHdpdGggdGhlIGlubmVyKS4gSW4gZHJhZnQtMDQsIEVDTiBjb2RlcG9pbnRzIGFyZSBt ZWFzdXJlZCBhdCB0aGUgaW5ncmVzcw0KIGFuZCBhdCB0aGUgZWdyZXNzLCB3aXRoIHRoZSBpbmdy ZXNzIHNlbmRpbmcgcmVndWxhciBtZWFzdXJlbWVudCByZXBvcnRzIHRvIHRoZSBlZ3Jlc3MgZm9y IGNvbXBhcmlzb24uIEhvd2V2ZXIsIGl0IGlzIGFsd2F5cyBzYWZlciB0byBtZWFzdXJlIEVDTiBz b2xlbHkgYXQgdGhlIGVncmVzcywgZXZlbiB0aG91Z2ggYSBkaWZmZXJlbnQgbWVjaGFuaXNtIGhh cyB0byBtZWFzdXJlIGRyb3BzIHdpdGhpbiB0aGUgdHVubmVsIChkdWUgdG8gbm9uLUVDTg0KIG5v ZGVzLCBvciBub2RlcyB0aGF0IGhhdmUgc3dpdGNoZWQgb2ZmIEVDTiBkdWUgdG8gb3ZlcmxvYWQs IG9yIGR1ZSB0byBjYXVzZXMgb2YgbG9zcyBvdGhlciB0aGFuIGNvbmdlc3Rpb24sIGUuZy4gdHJh bnNtaXNzaW9uIGVycm9ycykuDQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBJdCBp cyBhbHdheXMgc2FmZXIgdG8gc29sZWx5IG1lYXN1cmUgRUNOIGF0IHRoZSBlZ3Jlc3MsIGJlY2F1 c2UgaXQgaXMgbm90IHZ1bG5lcmFibGUgdG8gaW5ncmVzcy1lZ3Jlc3MgbWVhc3VyZW1lbnQgcGFj a2V0cyBiZWluZyBkcm9wcGVkLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFNvbGVs eSBtZWFzdXJpbmcgRUNOIGF0IGVncmVzcyBpcyBubyBsZXNzIHByZWNpc2UsIGJlY2F1c2Ugb25s eSB0aGUgcHJvcG9ydGlvbiBvZiB0aGUgZGlmZmVyZW50IEVDTiBmaWVsZHMgaXMgbmVlZGVkLCBh bmQgdGhhdCBzdGF5cyBhcHByb3hpbWF0ZWx5IHRoZSBzYW1lIGV2ZW4gaWYgdGhlcmUgaXMgZHJv cCwgYXNzdW1pbmcgZHJvcCBpcyBub3QgYmlhc2VkIHRvd2FyZHMgY2VydGFpbiBFQ04gY29kZXBv aW50cyAobm8ga25vd24gbWVjaGFuaXNtDQogZG9lcyB0aGF0KS4gPGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7IGIpIEluIGRyYWZ0LTA0IHRoZSBmYWtlZCBFQ1QgYXBwcm9hY2ggaGFzIGJl ZW4gbGVmdCB1bmNoYW5nZWQgYXQgdGhlIGluZ3Jlc3MsIGJ1dCBpdCBpcyBubyBsb25nZXIgdXNl ZCBhdCB0aGUgZWdyZXNzIGZvciBkZXRlY3RpbmcgZGVmZXJyZWQgZHJvcHMgKGJ5IGxvb2tpbmcg Zm9yIGEgTm90LUVDTiBpbm5lciBhbmQgYSBDRSBvdXRlcikuIEFnYWluLCB0aGVyZSBpcyBub3Ro aW5nIHdyb25nIHdpdGggbWVhc3VyaW5nIEVDTiBhbmQgZGV0ZWN0aW5nDQogZGVmZXJyZWQgZHJv cHMgc29sZWx5IGF0IHRoZSBlZ3Jlc3MsIGV2ZW4gaWYgdGhlcmUgYXJlIGRyb3BzIHdpdGhpbiB0 aGUgdHVubmVsLiBUbyBtZWFzdXJlIGRyb3BzIHdpdGhpbiB0aGUgdHVubmVsLCBpdCBpcyBuZWNl c3NhcnkgdG8gY29tcGFyZSBpbmdyZXNzIGFuZCBlZ3Jlc3MgYnl0ZXMsIGJ1dCB0aGF0IGRvZXMg bm90IG1ha2UgaXQgd3JvbmcgdG8gc3RpbGwgbWVhc3VyZSBhbmQgY29tcGFyZSBFQ04gc29sZWx5 IGF0IHRoZSBlZ3Jlc3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5bV2VpXSBJIGFncmVlIHRoYXQgc29sZWx5IG1lYXN1cmluZyBFQ04gYXQgZWdyZXNzIGlz IGVub3VnaCB0byBnZXQgdGhlIHByb3BvcnRpb24gb2YgZGlmZmVyZW50IEVDTiBmaWVsZHMsIGJ1 dCB0aGUgcmVhc29uIHdoeQ0KIEVDTiBjb2RlcG9pbnRzIGFyZSBtZWFzdXJlZCBib3RoIGF0IGlu Z3Jlc3MgYW5kIGVncmVzcyBpcyB0byBtZWFzdXJlIHRoZSBwYWNrZXRzIGRyb3BwZWQgd2l0aGlu IHRoZSB0dW5uZWwgYnkgY29tcGFyaW5nIGNvdW50cyBhdCBpbmdyZXNzIGFuZCBlZ3Jlc3MuDQo8 L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3Qgc2F5aW5nIHlvdSBzaG91bGQgbm90IGFsc28gbWVh c3VyZSBkcm9wIGJ5IG1lYXN1cmluZyB0b3RhbCBieXRlcyBhdCBpbmdyZXNzIGFuZCBlZ3Jlc3Mu PGJyPg0KPGJyPg0KSG93ZXZlciwgSSBhbSBzYXlpbmcgaXQgaXMgbGVzcyByb2J1c3QgdG8gaGF2 ZSB0byBtZWFzdXJlIGF0IGJvdGggaW5ncmVzcyBhbmQgZWdyZXNzLCBiZWNhdXNlIGl0IGludm9s dmVzIHNlbmRpbmcgc3luY2ggLyBtZWFzdXJlbWVudCBtZXNzYWdlcyBmcm9tIGluZ3Jlc3MgdG8g ZWdyZXNzLCB3aGljaCBjYW4gYmUgbG9zdC9kZWxheWVkLg0KPGJyPg0KU28sIEkgd291bGQgcmVj b21tZW5kIHRoZSBtb3JlIHJvYnVzdCBlZ3Jlc3Mtb25seSBtZXRob2QgZm9yIEVDTiwgYW5kIHRo ZSBpbmdyZXNzLWVncmVzcyBtZXRob2Qgb25seSBmb3IgdG90YWwgZHJvcC48YnI+DQo8YnI+DQpU aGUgb25seSBleHRyYSB0aGluZyB5b3UgbGVhcm4gYnkgdGhlIGN1cnJlbnRseSBwcm9wb3NlZCBh cHByb2FjaCBpcyBob3cgbWFueSBvZiBlYWNoIEVDTiBjb2RlcG9pbnQgd2VyZSBkcm9wcGVkLiBJ ZiB5b3UgdGhpbmsgdGhhdCdzIGltcG9ydGFudCwgYXJndWUgZm9yIGl0LiBJIGRvbid0IHNlZSBh bnkgbmVlZCBmb3IgaXQgdGhvLjxicj4NCjxicj4NCklmIHlvdSBpbnNpc3Qgb24ga2VlcGluZyB0 aGUgaW5ncmVzcy1lZ3Jlc3MgYXBwcm9hY2gsIHdoeSBkbyB5b3UgbmVlZCB0aGUgZmFrZWQgRUNO IHRleHQ/PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCjxicj4NCjxiPlMuNC4gQ29uZ2VzdGlvbiBMZXZlbCBNZWFzdXJlbWVudDogVW5p dHM8YnI+DQo8L2I+VGhyb3VnaG91dCBtZWFzdXJlbWVudCBpbnZvbHZlcyBjb3VudGluZyBwYWNr ZXRzLiBIb3dldmVyLCBpdCBzaG91bGQgY291bnQgdGhlIGJ5dGVzIGluIHBhY2tldHMgd2l0aCBl YWNoIHR5cGUgb2YgbWFya2luZywgbm90IGp1c3QgdGhlIG51bWJlciBvZiBwYWNrZXRzLiBTZWUN CjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTQxI3NlY3Rpb24tMi4z Ij5SRkM3MTQxIHNlY3Rpb24gMi4zPC9hPi4gQWx0aG91Z2ggdGhlIHJlY29tbWVuZGF0aW9uIGlu IHRoYXQgUkZDIGlzIGFib3V0IHdoYXQgYSAvdHJhbnNwb3J0LyBzaG91bGQgbWVhc3VyZSB3aGVu IHJlc3BvbmRpbmcgdG8gY29uZ2VzdGlvbiwgbG9naWNhbGx5IGl0IHNob3VsZCBhcHBseSBpbiB0 aGlzIGNhc2Ugd2hlbiBhIHRyYWZmaWMgbWFuYWdlbWVudA0KIGZ1bmN0aW9uIGlzIHJlc3BvbmRp bmcgaW4gcGxhY2Ugb2YgYSB0cmFuc3BvcnQuIFJGQzcxNDEgYWxzbyBnaXZlcyByZWNvbW1lbmRh dGlvbnMgb24gd2hpY2ggaGVhZGVycyB0byBjb3VudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltXZWldIE9rLCBpdOKAmXMgYSBnb29kIHN1Z2dlc3Rpb24u PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxicj4NCkkgc2hhbGwgYWRkIHRv IHRoaXMgcmV2aWV3IGxhdGVyIGluIHRoZSB3ZWVrLjxicj4NCjxicj4NCk9uZSBxdWVzdGlvbiBm b3IgV2VpeGlucGVuZzogSGF2ZSB5b3UgaW1wbGVtZW50ZWQgdGhpcyBtZWNoYW5pc20/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bV2VpXSBDdXJyZW50bHks IHdlIG9ubHkgaW1wbGVtZW50IHRoaXMgbWVjaGFuaXNtIGluIGEgc2ltdWxhdGlvbiBlbnZpcm9u bWVudC48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdXNwZWN0ZWQgYXMgbXVjaCwgYmVjYXVzZSB0aGUg bGFjayBvZiBkZXRhaWwgaW4gc29tZSBwbGFjZXMgaW1wbGllcyBpdCBpcyBhIGJpdCB0aGVvcmV0 aWNhbC48YnI+DQpJIHdvdWxkIGVuY291cmFnZSB5b3UgdG8gaW1wbGVtZW50Ljxicj4NCjxicj4N Cjxicj4NCjxicj4NCkJvYjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQo8YnI+DQpCb2I8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwMS8xMS8xNiAwMTo0OSwgV2VpeGlucGVu ZyAoSmFja2llKSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQm9iIGFuZCBEYXZpZCw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+QmVjYXVzZSB0aGUgZGVhZGxpbmUgaGFzIHBhc3NlZCwgSSB3aWxs IHVwZGF0ZSBpdCBhcyBwYXJ0IG9mIHBvc3QtV0dMQyB1cGRhdGUuIFRoYW5rcy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPi1YaW5wZW5nIChKYWNraWUpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv d3RleHQiPiBCbGFjaywgRGF2aWQgWzxhIGhyZWY9Im1haWx0bzpEYXZpZC5CbGFja0BkZWxsLmNv bSI+bWFpbHRvOkRhdmlkLkJsYWNrQGRlbGwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBOb3ZlbWJlciAwMSwgMjAxNiAxMjoxNCBBTTxicj4NCjxiPlRvOjwvYj4gQm9iIEJy aXNjb2U7IFdlaXhpbnBlbmcgKEphY2tpZSk7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXRz dndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWll dGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+Q2M6PC9iPiB0c3Z3ZyBJRVRGIGxpc3Q7IEJsYWNrLCBEYXZpZDxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSRTogVHVubmVsIENvbmdlc3Rpb24gRmVlZGJhY2s6IChub24tKXVwZGF0ZSB0byBS RkM2MDQwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzNjYiPiZndDsNCjwvc3Bhbj5JIGFzc3VtZSB5b3Ugd2ls bCB1cGRhdGUgdGhlIFRDRiBkcmFmdCB0b2RheSBiZWZvcmUgdGhlIGRlYWRsaW5lLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzM2NiI+KEFzIGRyYWZ0 IHNoZXBoZXJkKSBUaGF04oCZcyBub3QgcmVhbGx5IG5lY2Vzc2FyeSAtIHRoZSBUQ0YgZHJhZnQg aXMgaW4gV0dMQywgc28gdGhpcyBjaGFuZ2UgY2FuIGJlIGRvbmUgYXMgcGFydCBvZiBhIHBvc3Qt V0dMQyB1cGRhdGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzNjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5 MzM2NiI+VGhhbmtzLCAtLURhdmlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzM2NiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dCI+IEJvYiBCcmlzY29lIFs8YSBocmVmPSJtYWlsdG86aWV0ZkBib2Jicmlz Y29lLm5ldCI+bWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQ8L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgT2N0b2JlciAzMSwgMjAxNiAxMToyMiBBTTxicj4NCjxiPlRvOjwvYj4gV2Vp eGlucGVuZyAoSmFja2llKTsgQmxhY2ssIERhdmlkOyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0 Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9yZyI+DQpkcmFm dC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnPC9h Pjxicj4NCjxiPkNjOjwvYj4gdHN2d2cgSUVURiBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBUdW5uZWwgQ29uZ2VzdGlvbiBGZWVkYmFjazogKG5vbi0pdXBkYXRlIHRvIFJGQzYwNDA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPlhpbnBlbmcsPGJyPg0KPGJyPg0KSSBhZ3JlZSB0aGF0IFRDRiBkb2Vz IG5vdCB1cGRhdGUgUkZDNjA0MCAoYXMgSSBzYWlkKS48YnI+DQo8YnI+DQpCdXQgRGF2aWQgaXMg cmlnaHQgdGhhdCB0aGUgVENGIGRyYWZ0IGl0c2VsZiBuZWVkcyB0byBiZSB1cGRhdGVkIHRvIHNh eSB0aGF0IGl0IG1vZGlmaWVzIHRoZSBiZWhhdmlvdXIgb2YgYSBSRkM2MDQwIGVncmVzcyBzbyBh cyB0byBpc3N1ZSBvciBsb2cgYW55IHdhcm5pbmdzIHdoZW4gaXQgcmVjZWl2ZXMgYW4gRUNUKDAp IG9yIENFIG91dGVyIHdpdGggYSBOb3QtRUNUIGlubmVyLjxicj4NCjxicj4NCkkgYXNzdW1lIHlv dSB3aWxsIHVwZGF0ZSB0aGUgVENGIGRyYWZ0IHRvZGF5IGJlZm9yZSB0aGUgZGVhZGxpbmUuPGJy Pg0KPGJyPg0KQ2hlZXJzPGJyPg0KPGJyPg0KQm9iPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMzEvMTAvMTYgMDI6MzgsIFdlaXhpbnBlbmcgKEphY2tpZSkg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIERhdmlkLCBCb2IsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkkgYWdyZWUgdGhhdCB0aGUgYmVoYXZpb3IgZGVmaW5lZCBpbiBSRkM2MDQwIGRvZXNu4oCZ dCB0byBiZSB1cGRhdGVkIGR1ZSB0byB0aGUgVENGIGRyYWZ0LCBiZWNhdXNlIHdoYXTigJlzIGRl ZmluZWQgaW4gUkZDIDYwNDAgaGFzIGEgYnJvYWRlciB1c2FnZSBhbmQgbm90IGp1c3QgZm9yDQog VENGLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHRoaW5rIERhdmlkIGhhcyBwcm92aWRlZCBhIGdvb2Qg c3VnZ2VzdGlvbiBiZWxvdy4gVGhhbmtzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LVhpbnBlbmcgKEphY2tpZSk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IHRzdndnIFs8YSBocmVm PSJtYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CbGFjaywgRGF2aWQ8YnI+DQo8Yj5TZW50 OjwvYj4gU2F0dXJkYXksIE9jdG9iZXIgMjksIDIwMTYgMTA6MjggQU08YnI+DQo8Yj5Ubzo8L2I+ IEJvYiBCcmlzY29lOyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29u Z2VzdGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRmLXRzdndnLXR1bm5l bC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4g dHN2d2cgSUVURiBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHN2d2ddIFR1bm5lbCBD b25nZXN0aW9uIEZlZWRiYWNrOiAobm9uLSl1cGRhdGUgdG8gUkZDNjA0MDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5Cb2IsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J IHRoaW5rIHlvdeKAmXZlIGZvdW5kIHNvbWV0aGluZy4mbmJzcDsgVGhlIFRDRiBkcmFmdCBjdXJy ZW50bHkgdXNlcyBSRkMgNjA0MCBiZWhhdmlvciBieSByZWZlcmVuY2U6PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 ICwgc2VyaWYmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyB3aGVuIGRlY2Fwc3VsYXRpbmcgcGFj a2V0cyBhdCBlZ3Jlc3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcgLCBzZXJpZiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IFJGQzYwNDAgZGVmaW5lZCBk ZWNhcHN1bGF0aW9uIGJlaGF2aW9yIGlzIHVzZWQsIGFuZCBhY2NvcmRpbmcgdG88L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsIHNlcmlmJnF1b3Q7LHNlcmlm Ij4mbmJzcDsmbmJzcDsgUkZDNjA0MCwgdGhlIHBhY2tldHMgbWFya2VkIGFzIENFfE4tRUNUIHdp bGwgYmUgZHJvcHBlZCBieSBlZ3Jlc3MuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgc2xpZ2h0bHkgcmV2 aXNlZCB0byBzYXkgdGhhdCBDRXxOLUVDVCBpcyBkcm9wcGVkIHdpdGhvdXQgYW55IG90aGVyPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPmFjdGlvbiwgYW5kIGFsbCBvdGhlciBiZWhhdmlvciBpcyBhcyBwZXIg UkZDIDYwNDAsIGFzIENFfE4tRUNUIGlzIGV4cGVjdGVkIGF0IGEgVENGIGVncmVzcyBhbmQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+aGVuY2UgdGhlIGxvZ2dpbmcgYW5kIGFsYXJtIGJlaGF2aW9yIGZvciB0 aGF0IGNvbWJpbmF0aW9uIGluIFJGQyA2MDQwIGlzIGluYXBwcm9wcmlhdGUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbmNlIHRoYXTigJlzIGRvbmUsIEkgdGhp bmsgeW91ciByZWFzb25pbmcgaW4gdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBiZWNvbWVzIGNvcnJl Y3Q6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgbmV0d29yayBpcyBub3Qg dmFsaWQsIHRoZXNlIGNvbWJpbmF0aW9uIGNvdWxkIGJlY29tZSB2aXNpYmxlIHRvIGEgNjA0MC1k ZWNhcCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndoaWNoIHdvdWxkIHRo ZW4gKGNvcnJlY3RseSkgbG9nIHdhcm5pbmdzIHRoYXQgaXQgd2FzIHNlZWluZyBpbnZhbGlkIGNv ZGVwb2ludCBjb21iaW5hdGlvbnMuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlRoYW5rcywgLS1EYXZpZCAoYXMgZHJhZnQgc2hlcGhlcmQpPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlzY29lIFs8YSBocmVm PSJtYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldCI+bWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQ8 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDI3LCAyMDE2IDQ6Mzkg UE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXRzdndnLXR1bm5l bC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYtdHN2d2ct dHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmc8L2E+OyBCbGFjaywgRGF2 aWQ8YnI+DQo8Yj5DYzo8L2I+IHRzdndnIElFVEYgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBU dW5uZWwgQ29uZ2VzdGlvbiBGZWVkYmFjazogKG5vbi0pdXBkYXRlIHRvIFJGQzYwNDA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UdW5uZWwgY29uZ2VzdGlv biBmZWVkYmFjayBhdXRob3JzLCBEYXZpZCBhcyBzaGVwaGVyZCw8YnI+DQo8YnI+DQpGWUkuIE5v IGFjdGlvbiBuZWVkZWQuPGJyPg0KPGJyPg0KVGhpcyBlbWFpbCBkb2N1bWVudHMgYW4gYXJndW1l bnQgd2l0aCBteXNlbGYuIEFmdGVyIGEgZmV3IHNlY29uZHMsIEkgYWdyZWVkIHdpdGggbXlzZWxm IHRoYXQgb25lIG9mIG1lIHdhcyB3cm9uZy4gSSB0aG91Z2h0IEkgaGFkIGJldHRlciByYWlzZSB0 aGlzIG9uIHRoZSBsaXN0LCB0byBjaGVjayB0aGF0IG90aGVycyBhZ3JlZSB3aXRoIGJvdGggb2Yg bWUuIElmIHlvdSB3aXNoIHRvIGFyZ3VlIHdpdGgganVzdCBvbmUgb2YgbWUsIHBsZWFzZSBiZWFy DQogaW4gbWluZCB0aGF0IHdlIGJvdGggaGF2ZSB0aGUgc2FtZSBlbWFpbCBhZGRyZXNzIChhbmQg YW55d2F5LCB3ZSBib3RoIGFncmVlIHNvIGFuIGFyZ3VtZW50IHdpdGggb25lIGlzIGFuIGFyZ3Vt ZW50IHdpdGggYWxsKS48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0K RmlndXJlIDQgb2YgUkZDNjA0MCBzcGVjaWZpZXMgd2hpY2ggRUNOIGNvZGVwb2ludCBhIGRlY2Fw IG11c3QgZm9yd2FyZCwgZm9yIGVhY2ggY29tYmluYXRpb24gb2YgYXJyaXZpbmcgaW5uZXIgKHJv dykgYW5kIG91dGVyIChjb2x1bW4pLjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHxBcnJpdmluZyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFycml2aW5nIE91dGVyIEhlYWRl ciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyBJbm5lciAmIzQzOy0tLS0tLS0t LSYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyBIZWFkZXIgfCBOb3QtRUNUIHwgRUNUKDApJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRUNU KDEpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0Um bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0MzstLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgTm90LUVDVCB8IE5vdC1F Q1QgfE5vdC1FQ1QoISEhKXxOb3QtRUNUKCEhISl8ICZsdDtkcm9wJmd0OyghISEpfDwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgRUNUKDAp IHwmbmJzcDsgRUNUKDApIHwgRUNUKDApJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRUNUKDEp Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0UmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgRUNUKDEpIHwmbmJzcDsgRUNUKDEpIHwgRUNUKDEpICgh KSB8IEVDVCgxKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IENFJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IENFJm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0UgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBDRSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IENFKCEhISl8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENFJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmIzQzOy0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJGQzYwNDAgZ29lcyBvbiB0byBzYXk6PG86cD48L286cD48L3A+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWy4uLl0gVGhlc2UgY3VycmVudGx5IHVudXNl ZCAoQ1UpIGNvbWJpbmF0aW9ucyBhcmU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmRpY2F0ZWQgaW4gRmlndXJl IDQgYnkgJyghISEpJyBvciAnKCEpJywgd2hlcmUgJyghISEpJyBtZWFucyB0aGU8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDtjb21iaW5hdGlvbiBpcyBDVSBhbmQgYWx3YXlzIHBvdGVudGlhbGx5IGRhbmdlcm91cywg d2hpbGUgJyghKSc8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtZWFucyBpdCBpcyBDVSBhbmQgcG9zc2libHkgZGFu Z2Vyb3VzLiZuYnNwOyBJbiB0aGVzZSBjYXNlcyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJ0aWN1bGFybHkg dGhlIG1vcmUgZGFuZ2Vyb3VzIG9uZXMsIHRoZSBkZWNhcHN1bGF0b3IgU0hPVUxEIGxvZzwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRoZSBldmVudCBhbmQgTUFZIGFsc28gcmFpc2UgYW4gYWxhcm0uPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ VENGIHVzZXMgdGhlIGZvbGxvd2luZyBjb21iaW5hdGlvbnMgb2YgaW5uZXIgOiBvdXRlcg0KPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IE5vdC1FQ1QgOiBFQ1QoMCk8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgTm90LUVDVCA6IENFPGJyPg0KPGJyPg0KRm9yIGEgbW9tZW50LCBJIHRob3VnaHQgd2Ug d291bGQgaGF2ZSB0byB1cGRhdGUgUkZDNjA0MCB0byBzYXkgdGhhdCBUQ0YgbWFrZXMgdGhlc2Ug Y29tYmluYXRpb25zIG5vIGxvbmdlciBDVSwgc28gdGhleSBhcmUgbm93IHZhbGlkLCBub3QgZGFu Z2Vyb3VzLCBhbmQgdGhleSBubyBsb25nZXIgbmVlZCB0byBiZSBsb2dnZWQuIFRoaXMgd291bGQg aGF2ZSBtZWFudCB0aGF0IFR1bm5lbCBDb25nZXN0aW9uIEZlZWRiYWNrIChUQ0YpIChpbmZvcm1h dGlvbmFsKQ0KIHdvdWxkIGhhdmUgdG8gdXBkYXRlIFJGQzYwNDAgKHByb3Bvc2VkIHN0YW5kYXJk KS48YnI+DQo8YnI+DQpIZXJlJ3Mgd2h5IEkgd2FzIHdyb25nLiBUaGVzZSB0d28gY29tYmluYXRp b25zIGFyZSBjZXJ0YWlubHkgdmFsaWQgYXQgYSBUQ0YgZGVjYXAuIEJ1dCB0aGVyZSBpcyBzdGls bCBubyB3YXkgdGhhdCwgaW4gYSB2YWxpZCBuZXR3b3JrLCB0aGV5IHdvdWxkIGFycml2ZSBhdCBh bnkgUkZDNjA0MCAobm9uLVRDRikgZGVjYXAuPGJyPg0KPGJyPg0KT25lIG1pZ2h0IHRoaW5rIHRo YXQgdGhpcyBjb21iaW5hdGlvbiBjb3VsZCBhcnJpdmUgYXQgYSA2MDQwLWRlY2FwIGlmIHRoZXJl IHdhcyBhIHR1bm5lbCBpbnNpZGUgYSB0dW5uZWwsIGFzIGZvbGxvd3M8YnI+DQo8YnI+DQo8dHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyBUQ0YtZW5jYXAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tJmd0OyA2MDQwLWRlY2FwIC0tLSZndDsg VENGLWRlY2FwPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90OyxzZXJpZiI+PGJyPg0KPC9zcGFu Pjxicj4NCkhvd2V2ZXIsIHRoYXQncyBub3QgYSB2YWxpZCBjb25maWd1cmF0aW9uLiBUaGUgZm9s bG93aW5nIHR1bm5lbC1pbi10dW5uZWwgd291bGQgYmUgdmFsaWQ6PGJyPg0KPGJyPg0KPHR0Pjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsgVENGLWVuY2FwIC0tLSZndDsgNjA0 MC1lbmNhcCAtLS0mZ3Q7IDYwNDAtZGVjYXAgLS0tJmd0OyBUQ0YtZGVjYXA8L3NwYW4+PC90dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyAsIHNlcmlmJnF1b3Q7LHNlcmlmIj48YnI+DQo8L3NwYW4+PGJyPg0KLi4udGhlbiwgdGhlIGFi b3ZlIHR3byAmcXVvdDtDVSZxdW90OyBjb21iaW5hdGlvbnMgd291bGQgYmUgYnVyaWVkIHdpdGhp biBhIGRvdWJsZSBpbm5lciwgc28gb25seSB0aGUgVENGIGRlY2FwIHdvdWxkIHNlZSB0aGVtLCBu b3QgdGhlIDYwNDAtZGVjYXAuPGJyPg0KPGJyPg0KU28sIFRDRiBkb2VzIG5vdCBuZWVkIHRvIHVw ZGF0ZSBSRkM2MDQwLiBCZWNhdXNlLCBpbiBhIHZhbGlkIG5ldHdvcmssIFRDRiB3aWxsIGJlIGhp ZGRlbiBmcm9tIGFueSA2MDQwLWRlY2FwLiBJZiB0aGUgbmV0d29yayBpcyBub3QgdmFsaWQsIHRo ZXNlIGNvbWJpbmF0aW9uIGNvdWxkIGJlY29tZSB2aXNpYmxlIHRvIGEgNjA0MC1kZWNhcCwgd2hp Y2ggd291bGQgdGhlbiAoY29ycmVjdGx5KSBsb2cgd2FybmluZ3MgdGhhdCBpdCB3YXMgc2VlaW5n IGludmFsaWQNCiBjb2RlcG9pbnQgY29tYmluYXRpb25zLjxicj4NCjxicj4NCkkganVzdCB0aG91 Z2h0IHlvdSdkIGxpa2UgdG8ga25vdy4uLiBubyBhY3Rpb24gcmVxdWlyZWQuPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KQm9iPGJyPg0KPGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4tLSA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJvYiBCcmlzY29lJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5l dC88L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tIDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2JvYmJy aXNjb2UubmV0LyI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8YnI+DQo8YnI+DQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJo dHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9hPjxvOnA+PC9v OnA+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEg aHJlZj0iaHR0cDovL2JvYmJyaXNjb2UubmV0LyI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48 bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CE03DB3D7B45C245BCA0D243277949362F9B3F09MX307CL04corpem_-- From nobody Sat Apr 8 02:00:57 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8B21293F3 for ; Sat, 8 Apr 2017 02:00:56 -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, RP_MATCHES_RCVD=-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 k4HWLui5mUyS for ; Sat, 8 Apr 2017 02:00:54 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BB5120726 for ; Sat, 8 Apr 2017 02:00:53 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cwmEl-0006Cj-Lk for tsvwg@ietf.org; Sat, 08 Apr 2017 11:00:51 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cwmEl-0009Jd-5N; Sat, 08 Apr 2017 11:00:51 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Welzl In-Reply-To: <790d7485-0540-48cf-0b5e-e6eb4c83b2e8@mti-systems.com> Date: Sat, 8 Apr 2017 11:00:56 +0200 Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <0AA31A63-B4C9-4767-8939-4FC0030E65C5@ifi.uio.no> References: <138206D2-85DF-4CAC-B196-7FC59304546A@ifi.uio.no> <372AFF1E-A1B4-4710-9EA5-25DBD74ED2FA@ifi.uio.no> <790d7485-0540-48cf-0b5e-e6eb4c83b2e8@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 53717 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.007, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 107CAD57B8328E358B29209900F57F9C7CE0D192 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1104 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tsvwg] confirming adoption of L4S drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 09:00:57 -0000 Hi, Yes to everything here. My crystal ball says that the work on the necessary heuristics might = never really happen, which is what made me worry: then, what=E2=80=99s = the use of L4S altogether? However, that doesn=E2=80=99t matter much in the =E2=80=9Ccontrolled = service provider=E2=80=9D environment, and this convinces me; sorry, I = hadn=E2=80=99t really thought this scenario through. My bad. So just to restate, I do agree that it would be good to adopt this work = in TSVWG. Cheers, Michael > On Apr 7, 2017, at 5:43 PM, Wesley Eddy wrote: >=20 > Hi Michael, as co-chair shepherding these documents in TSVWG, I want = to make sure if we're okay to proceed. >=20 > You're obviously right that the corresponding scalable end-host = behavior is work that needs to be done, and I agree that where that work = is done in terms of WG, RG, etc. will need to be figured out, but I see = those more as action items for follow-up in parallel, rather than = roadblocks to proceeding with adopting work on the in-network behavior. = I think the ADs will make sure this works out (and if it's not working = out in time, they could kill off the L4S work at some point). I think = your concern about defining the in-network behavior and codepoint = without an end-host algorithm is something we should track as that work = proceeds in parallel, and evaluate when we think L4S is mature enough = for a last call. >=20 > Certainly nobody would want to just go ahead and publish RFCs here, if = it turns out to that there isn't promise of mature end-host algorithm = work to go with it! I think WG participants, ADs, chairs, etc, can = evaluate this as the work proceeds, but it shouldn't gate adoption. >=20 > In my personal opinion, the ability to support DCTCP in = private/managed networks is probably enough motivation alone, and that = something for Internet end-hosts will obviously make it even better, but = is just an expansion of the use cases rather than absolutely required to = see value out of L4S. >=20 > Would you agree that we can assume end-host algorithm research will = keep proceeding (somewhere to be defined) in parallel, and that TSVWG = should be doing these Experimental+Informational in-network pieces in = the meantime? >=20 >=20 >=20 >=20 From nobody Sat Apr 8 02:06:04 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963F41205D3; Sat, 8 Apr 2017 02:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] 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 EpdIQHbS_5jD; Sat, 8 Apr 2017 02:05:52 -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 850B61293EB; Sat, 8 Apr 2017 02:05:49 -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=Q+PzN+hJydlZjAUcnVEdzLwappJmJC28KwGpjZcn0zM=; b=U7yvb249YOgfrNxMRwQY1mIBXQ CEUV97kX+48FMHjRtNt/+fcFo3iNoDqBYUjtEIwgiv7ure9YQfESB1nmjK/mvuLXa3jEXzWd4izGA BaGfMB98gQ0WG73TrEglADRQWX74esC3GISbvRiT+AgRnbE4tgGVnSBVISv+ARz0SFH8VkuAtXzj4 SWySVh+zyyx9mVLvu8XLw43pFxwjbXcT+3pn5/OENYTqkICnlM8ckrBVR74OMFQHQ23nG+WVAFjk+ x1fXWcE4QiGjis3yHiD9d8Xi62yTvGMpGMt68YOk3RMnUZgPN6Q422ND04chJ46zHrYvnB6DGFsp6 NZndrPEg==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:52786 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 1cwmJX-0004NA-K2; Sat, 08 Apr 2017 10:05:47 +0100 To: "Black, David" References: <20160722110102.5697618.36413.99476@sandvine.com> <449c5fea-32ba-bf3f-bb7b-8f7b48b22f4f@bobbriscoe.net> Cc: TCP Prague List , tsvwg IETF list From: Bob Briscoe Message-ID: <0c9f29ef-993d-606a-c0c6-05a411903993@bobbriscoe.net> Date: Sat, 8 Apr 2017 10:05:47 +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: 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: [tsvwg] [tcpPrague] Treatment of ECT(1) pre L4S X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 09:05:55 -0000 David, Thx for confirming we are OK to go ahead with this. What's the status of the ecn-l4s-id adoption call? If it's about to be formally adopted, I could add in this text at the same time as changing the filename to draft-ietf... Bob On 08/04/17 01:34, Black, David wrote: > This message is written as the author of the ECN Experimentation draft, not as a WG chair. > > This topic was discussed in Chicago with a request to me as author of the ECN experimentation draft to check that both options below are permitted. These options are for network nodes that do not implement L4S dual queues but for which there is a desire to do something reasonable with ECT(1) in light of L4S usage. The crucial ECN experimentation draft text is in Section 4.2 (https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimentation#section-4.2): > > ----------------------------------- > 4.2. ECT Differences > > Section 5 of RFC 3168 specifies that: > > Routers treat the ECT(0) and ECT(1) codepoints as equivalent. > > In support of ECT Differences experimentation, this memo updates RFC > 3168 to allow routers to treat the ECT(0) and ECT(1) codepoints > differently, provided that the changes from RFC 3168 are documented > in an Experimental RFC. The specific change to RFC 3168 is to insert > the words "unless otherwise specified by an Experimental RFC" at the > end of the above sentence. > ----------------------------------- > > The ecn-l4s-id is intended to become an Experimental RFC, and hence would benefit from the added "unless otherwise specified by an Experimental RFC" text. That added text imposes no limits on the scope of "otherwise specified" - we are relying on the combined good sense of the draft authors, WG members, the IETF community and the IESG to ensure that nothing horrendous in this area makes it into an Experimental RFC ;-). > > I see no problem with an Experimental RFC for L4S specifying not only experimental changes to network nodes that fully participate in the experiment (dual queues) but also specifying experimental changes for network nodes that only partially participate - the options below are for network nodes that only partially participate. > > Thanks, --David > >> -----Original Message----- >> From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Bob >> Briscoe >> Sent: Wednesday, March 29, 2017 3:26 AM >> To: Dave Dolson >> Cc: TCP Prague List ; tsvwg IETF list >> Subject: Re: [tcpPrague] Treatment of ECT(1) pre L4S >> >> Dave, >> >> I've cc'd this to tsvwg. >> We will put text in the ecn-l4s-id draft unless there is not consensus >> from others about this yet. >> >> I agree with Koen now. >> >> To be clear, I believe that a classic AQM supporting only RFC3168 >> (Classic) ECN: >> * should never alter the ECT(1) field >> * should be configurable between the following two behaviours: >> - [default] treat ECT(1) as if it does not support ECN, so drop where >> it would have marked CE >> - treat ECT(1) as if it is ECT(0) >> >> I am less keen than Koen on adding the latter option - I prefer clear >> simple advice to avoid confusion. >> So IMO, if you don't want another config knob, it would be OK to just >> support the default. >> >> Ideally, once the DualQ specs are approved, the AQM should also be >> upgraded to support Dual Qs and the squared relationship between them. >> >> Sorry it's taken so long to confirm this. >> >> Cheers >> >> >> >> Bob >> >> On 22/07/16 12:01, Dave Dolson wrote: >>> If an operator were to deploy ECN today, pre L4S, what should be the >> treatment of ECT(1)? >>> I believe, from a discussion with Koen, that the safest approach is for a pre- >> L4S implementation to signal congestion to ECT(1) by dropping. If ECT(1) >> were treated the same as ECT(0) then new experimental TCP-Prague flows >> would out-compete any ECT(0) traffic. >>> Is this agreed? If so, should it be recommended somewhere? >>> >>> Note that I got mixed answers on this from other IETF folks, so I think it is >> worth sorting out. >>> >>> -Dave >>> >>> >>> >>> _______________________________________________ >>> tcpPrague mailing list >>> tcpPrague@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpprague >> -- >> __________________________________________________________ >> ______ >> Bob Briscoe http://bobbriscoe.net/ >> >> _______________________________________________ >> tcpPrague mailing list >> tcpPrague@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpprague > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Sat Apr 8 02:15:52 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6FC128CD5 for ; Sat, 8 Apr 2017 02:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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, T_KAM_HTML_FONT_INVALID=0.01] 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 fyZsyEzeQPyw for ; Sat, 8 Apr 2017 02:15:47 -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 ED57B128B4E for ; Sat, 8 Apr 2017 02:15:45 -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=RXaerUHWXSXioSmXqyHJsQa/8qKRDKWyd2nnl6Vtu0I=; b=QA/g34ogEXX/+tvZqqmaC9Or/ +ysOTYNPSDG/Q+W2gD7AIVSpTPagGWGz1Ne91GDIvCMr7giQ9/AShSV2HWnZY5xUohOVV5GoJ+l+T gi2wE046oN3hDmFoloYycAdnvCLrWVLNHno5YeSLCo8xrayvVBiNR5/+NQWKBDWJ39+1xNoRijlbF Kvcwvb3c/5XQU/ud0yeD0WAQM8L62V1Mj2AuRdHs1RNW/TQro0H1aqx8uRk4aeyKKBRvdg3KZhgG8 G4qXsmLhB+a6ZwUk5hvWZ5YbZcC3OEuGbwhijJi2j6lHysOCkVXMM4+5BViWxsktr66qtwZqvIcD9 3Rh03bzOA==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:52826 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 1cwmT9-0005LC-3e; Sat, 08 Apr 2017 10:15:44 +0100 To: "Black, David" , "Weixinpeng (Jackie)" , "draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org" References: <712bfd85-39e5-bcae-f9b9-0035ef5cf654@bobbriscoe.net> Cc: tsvwg IETF list From: Bob Briscoe Message-ID: Date: Sat, 8 Apr 2017 10:15:42 +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: multipart/alternative; boundary="------------2FEDDA9E8A25451C30234705" 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: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 09:15:51 -0000 This is a multi-part message in MIME format. --------------2FEDDA9E8A25451C30234705 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit David, Thx for all your points - all understood and I agreed with them all. I think now that Weixinpeng, you and I all agree that the draft should specify ingress-egress comparison for drop and the egress-only approach for ECN. So then the faked ECN approach can stay, because it shifts some/most drops to the more robust egress-only measurement location. But I suggest the faked ECN text is moved up a paragraph, because the paragraph before it doesn't make sense unless the readers already knows about faked ECN. I will still send a full review, possibly this weekend, but early next week is looking more likely now. Bob On 08/04/17 02:20, Black, David wrote: > > I’m among those responsible for the ingress-egress measurement > addition, so weighing in as draft shepherd: > > > However, I am saying it is less robust to have to measure at both > ingress and egress, because it involves sending synch / measurement > > > messages from ingress to egress, which can be lost/delayed. So, I > would recommend the more robust egress-only method for ECN, > > > and the ingress-egress method only for total drop. > > That seems fine, however the total drop info does need to be reported > in addition to ECN info. > > > > The only extra thing you learn by the currently proposed approach is > how many of each ECN codepoint were dropped. If you think that's > important, argue for it. I don't see any need for it tho. > > I would agree. > > > If you insist on keeping the ingress-egress approach, why do you > need the faked ECN text? > > If one is trying to measure congestion in the tunnel, drops have to be > considered – even if all nodes in the tunnel support ECN, an > overloaded ECN node will drop packets. > > The reason for faked-ECN is buried in Bob’s “more robust” comment > about egress-only ECN measurement above – use of ECN should result in > better measurements by comparison to non-use. > > Thanks, --David > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, April 7, 2017 10:48 AM > *To:* Weixinpeng (Jackie) ; Black, David > ; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > *Cc:* tsvwg IETF list > *Subject:* Re: Tunnel Congestion Feedback: (non-)update to RFC6040 > > Weixinpeng, > > On 05/04/17 03:45, Weixinpeng (Jackie) wrote: > > Hi Bob, > > Thanks for your comments, and please see inline. > > Regards, > > -Xinpeng > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Monday, April 03, 2017 5:34 AM > *To:* Weixinpeng (Jackie); Black, David; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list > *Subject:* Re: Tunnel Congestion Feedback: (non-)update to RFC6040 > > Weixinpeng, co-authors, and David, > > I had promised a review of the latest TCF draft, but failed to > provide it so far. > I half read it through on Friday, and I will finish and write up > my review this week. > > Here' a quick summary of the main points so far: > > *S.1. Intro: Motivation > *The motivation should also include a heavy load from a much > larger than expected number of responsive flows > > */[Wei] Ok, I will add it./* > > *S.1 Intro: Scope > *I think the draft should say that > * it gives no advice on how to select which tunnel endpoints > should be used in order to manage traffic over a network > criss-crossed by multiple tunnels. > * if a congested node is part of multiple tunnels, and it causes > congestion feedback to multiple traffic management functions at > the ingresses of all the tunnels, the draft gives no advice on how > all the traffic management functions should respond. > * etc. (in my full review, I will provide a full list of subjects > that are out of scope). > > */[Wei] Ok./* > > *S.3. Feedback Models: > *The architecture diagrams and text need to include components > that apply a consistent measurement policy (template records in > IPFIX-speak) at both ingress and egress. This is a key part of > interoperability, which is what the IETF should be all about. > Template records are described later when the mechanism is > specified, but they are not shown in the layout of the components > in S.3. > > */[Wei] I will provide a description of Template record in this > section. But I am wondering whether a detailed description of > Template Record as section 6.1 is needed here or not?/* > > I suggest that, at this stage in the doc, it would be best not to be > specific to one technology (IPFIX) but instead to talk more generally > about setting and storing measurement policy (at the decision point > and the egress meter). > > BTW, did you invent the terminology decision point (DP) and action > point (AP)? Because there is already IETF terminology for these: > * Policy Decision Point (PDP) > * Policy Enforcement Point (PEP). > > See COPS (Common Open Policy Service) Protocol [RFC2748] or > terminology for policy-based management [RFC3198] > > > > *S.4. Congestion Level Measurement: > *Measurement of ECN has been changed without thinking clearly > whether it needed to change. > > a) Earlier drafts exploited the fact that the inner holds a > "frozen" record of the ECN field at the ingress. So ECN > measurements could be made solely at the egress (comparing the > outer with the inner). In draft-04, ECN codepoints are measured at > the ingress and at the egress, with the ingress sending regular > measurement reports to the egress for comparison. However, it is > always safer to measure ECN solely at the egress, even though a > different mechanism has to measure drops within the tunnel (due to > non-ECN nodes, or nodes that have switched off ECN due to > overload, or due to causes of loss other than congestion, e.g. > transmission errors). > - It is always safer to solely measure ECN at the egress, > because it is not vulnerable to ingress-egress measurement packets > being dropped. > - Solely measuring ECN at egress is no less precise, because > only the proportion of the different ECN fields is needed, and > that stays approximately the same even if there is drop, assuming > drop is not biased towards certain ECN codepoints (no known > mechanism does that). > > b) In draft-04 the faked ECT approach has been left unchanged > at the ingress, but it is no longer used at the egress for > detecting deferred drops (by looking for a Not-ECN inner and a CE > outer). Again, there is nothing wrong with measuring ECN and > detecting deferred drops solely at the egress, even if there are > drops within the tunnel. To measure drops within the tunnel, it is > necessary to compare ingress and egress bytes, but that does not > make it wrong to still measure and compare ECN solely at the egress. > > */[Wei] I agree that solely measuring ECN at egress is enough to > get the proportion of different ECN fields, but the reason why ECN > codepoints are measured both at ingress and egress is to measure > the packets dropped within the tunnel by comparing counts at > ingress and egress. /* > > I am not saying you should not also measure drop by measuring total > bytes at ingress and egress. > > However, I am saying it is less robust to have to measure at both > ingress and egress, because it involves sending synch / measurement > messages from ingress to egress, which can be lost/delayed. > So, I would recommend the more robust egress-only method for ECN, and > the ingress-egress method only for total drop. > > The only extra thing you learn by the currently proposed approach is > how many of each ECN codepoint were dropped. If you think that's > important, argue for it. I don't see any need for it tho. > > If you insist on keeping the ingress-egress approach, why do you need > the faked ECN text? > > > > > *S.4. Congestion Level Measurement: Units > *Throughout measurement involves counting packets. However, it > should count the bytes in packets with each type of marking, not > just the number of packets. See RFC7141 section 2.3 > . Although the > recommendation in that RFC is about what a /transport/ should > measure when responding to congestion, logically it should apply > in this case when a traffic management function is responding in > place of a transport. RFC7141 also gives recommendations on which > headers to count. > > */[Wei] Ok, it’s a good suggestion./* > > > > > I shall add to this review later in the week. > > One question for Weixinpeng: Have you implemented this mechanism? > > */[Wei] Currently, we only implement this mechanism in a > simulation environment./* > > I suspected as much, because the lack of detail in some places implies > it is a bit theoretical. > I would encourage you to implement. > > > > Bob > > > > Bob > > > On 01/11/16 01:49, Weixinpeng (Jackie) wrote: > > Hi Bob and David, > > Because the deadline has passed, I will update it as part of > post-WGLC update. Thanks. > > Regards, > > -Xinpeng (Jackie) > > *From:*Black, David [mailto:David.Black@dell.com] > *Sent:* Tuesday, November 01, 2016 12:14 AM > *To:* Bob Briscoe; Weixinpeng (Jackie); > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list; Black, David > *Subject:* RE: Tunnel Congestion Feedback: (non-)update to RFC6040 > > > I assume you will update the TCF draft today before the deadline. > > (As draft shepherd) That’s not really necessary - the TCF > draft is in WGLC, so this change can be done as part of a > post-WGLC update. > > Thanks, --David > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Monday, October 31, 2016 11:22 AM > *To:* Weixinpeng (Jackie); Black, David; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list > *Subject:* Re: Tunnel Congestion Feedback: (non-)update to RFC6040 > > Xinpeng, > > I agree that TCF does not update RFC6040 (as I said). > > But David is right that the TCF draft itself needs to be > updated to say that it modifies the behaviour of a RFC6040 > egress so as to issue or log any warnings when it receives an > ECT(0) or CE outer with a Not-ECT inner. > > I assume you will update the TCF draft today before the deadline. > > Cheers > > Bob > > On 31/10/16 02:38, Weixinpeng (Jackie) wrote: > > Hi David, Bob, > > I agree that the behavior defined in RFC6040 doesn’t to be > updated due to the TCF draft, because what’s defined in > RFC 6040 has a broader usage and not just for TCF. > > I think David has provided a good suggestion below. Thanks. > > Regards, > > -Xinpeng (Jackie) > > *From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On Behalf Of > *Black, David > *Sent:* Saturday, October 29, 2016 10:28 AM > *To:* Bob Briscoe; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list > *Subject:* Re: [tsvwg] Tunnel Congestion Feedback: > (non-)update to RFC6040 > > Bob, > > I think you’ve found something. The TCF draft currently > uses RFC 6040 behavior by reference: > > when decapsulating packets at egress, > > RFC6040 defined decapsulation behavior is used, and > according to > > RFC6040, the packets marked as CE|N-ECT will be dropped > by egress. > > I think this needs to be slightly revised to say that > CE|N-ECT is dropped without any other > > action, and all other behavior is as per RFC 6040, as > CE|N-ECT is expected at a TCF egress and > > hence the logging and alarm behavior for that combination > in RFC 6040 is inappropriate. > > Once that’s done, I think your reasoning in the following > sentence becomes correct: > > If the network is not valid, these combination could > become visible to a 6040-decap, > > which would then (correctly) log warnings that it was > seeing invalid codepoint combinations. > > Thanks, --David (as draft shepherd) > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Thursday, October 27, 2016 4:39 PM > *To:* > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > ; > Black, David > *Cc:* tsvwg IETF list > *Subject:* Tunnel Congestion Feedback: (non-)update to RFC6040 > > Tunnel congestion feedback authors, David as shepherd, > > FYI. No action needed. > > This email documents an argument with myself. After a few > seconds, I agreed with myself that one of me was wrong. I > thought I had better raise this on the list, to check that > others agree with both of me. If you wish to argue with > just one of me, please bear in mind that we both have the > same email address (and anyway, we both agree so an > argument with one is an argument with all). > _________________________ > > Figure 4 of RFC6040 specifies which ECN codepoint a decap > must forward, for each combination of arriving inner (row) > and outer (column). > > > +---------+------------------------------------------------+ > > |Arriving | Arriving Outer > Header | > > | Inner > +---------+------------+------------+------------+ > > | Header | Not-ECT | ECT(0) | ECT(1) > | CE | > > > +---------+---------+------------+------------+------------+ > > | Not-ECT | Not-ECT > |Not-ECT(!!!)|Not-ECT(!!!)| (!!!)| > > | ECT(0) | ECT(0) | ECT(0) | ECT(1) > | CE | > > | ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) > | CE | > > | CE | CE | CE | > CE(!!!)| CE | > > > +---------+---------+------------+------------+------------+ > > RFC6040 goes on to say: > > [...] These currently unused (CU) > combinations are > > indicated in Figure 4 by '(!!!)' or '(!)', where > '(!!!)' means the > > combination is CU and always potentially dangerous, > while '(!)' > > means it is CU and possibly dangerous. In these cases, > > particularly the more dangerous ones, the > decapsulator SHOULD log > > the event and MAY also raise an alarm. > > TCF uses the following combinations of inner : outer > Not-ECT : ECT(0) > Not-ECT : CE > > For a moment, I thought we would have to update RFC6040 to > say that TCF makes these combinations no longer CU, so > they are now valid, not dangerous, and they no longer need > to be logged. This would have meant that Tunnel Congestion > Feedback (TCF) (informational) would have to update > RFC6040 (proposed standard). > > Here's why I was wrong. These two combinations are > certainly valid at a TCF decap. But there is still no way > that, in a valid network, they would arrive at any RFC6040 > (non-TCF) decap. > > One might think that this combination could arrive at a > 6040-decap if there was a tunnel inside a tunnel, as follows > > TCF-encap ---> 6040-decap ---> TCF-decap > > However, that's not a valid configuration. The following > tunnel-in-tunnel would be valid: > > TCF-encap ---> 6040-encap ---> 6040-decap ---> TCF-decap > > ...then, the above two "CU" combinations would be buried > within a double inner, so only the TCF decap would see > them, not the 6040-decap. > > So, TCF does not need to update RFC6040. Because, in a > valid network, TCF will be hidden from any 6040-decap. If > the network is not valid, these combination could become > visible to a 6040-decap, which would then (correctly) log > warnings that it was seeing invalid codepoint combinations. > > I just thought you'd like to know... no action required. > > > > Bob > > -- > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------2FEDDA9E8A25451C30234705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit David,

Thx for all your points - all understood and I agreed with them all.

I think now that Weixinpeng, you and I all agree that the draft should specify ingress-egress comparison for drop and the egress-only approach for ECN. So then the faked ECN approach can stay, because it shifts some/most drops to the more robust egress-only measurement location. But I suggest the faked ECN text is moved up a paragraph, because the paragraph before it doesn't make sense unless the readers already knows about faked ECN.

I will still send a full review, possibly this weekend, but early next week is looking more likely now.


Bob

On 08/04/17 02:20, Black, David wrote:

I’m among those responsible for the ingress-egress measurement addition, so weighing in as draft shepherd:

 

> However, I am saying it is less robust to have to measure at both ingress and egress, because it involves sending synch / measurement

> messages from ingress to egress, which can be lost/delayed.  So, I would recommend the more robust egress-only method for ECN,

> and the ingress-egress method only for total drop.

That seems fine, however the total drop info does need to be reported in addition to ECN info.


> The only extra thing you learn by the currently proposed approach is how many of each ECN codepoint were dropped. If you think that's important, argue for it. I don't see any need for it tho.

 

I would agree.

> If you insist on keeping the ingress-egress approach, why do you need the faked ECN text?

 

If one is trying to measure congestion in the tunnel, drops have to be considered – even if all nodes in the tunnel support ECN, an overloaded ECN node will drop packets.

The reason for faked-ECN is buried in Bob’s “more robust” comment about egress-only ECN measurement above – use of ECN should result in better measurements by comparison to non-use.

 

Thanks, --David

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Friday, April 7, 2017 10:48 AM
To: Weixinpeng (Jackie) <weixinpeng@huawei.com>; Black, David <david.black@emc.com>; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list <tsvwg@ietf.org>
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Weixinpeng,

On 05/04/17 03:45, Weixinpeng (Jackie) wrote:

Hi Bob,

Thanks for your comments, and please see inline.

Regards,

-Xinpeng

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Monday, April 03, 2017 5:34 AM
To: Weixinpeng (Jackie); Black, David; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Weixinpeng, co-authors,  and David,

I had promised a review of the latest TCF draft, but failed to provide it so far.
I half read it through on Friday, and I will finish and write up my review this week.

Here' a quick summary of the main points so far:

S.1. Intro: Motivation
The motivation should also include a heavy load from a much larger than expected number of responsive flows

[Wei] Ok, I will add it.

S.1 Intro: Scope
I think the draft should say that
* it gives no advice on how to select which tunnel endpoints should be used in order to manage traffic over a network criss-crossed by multiple tunnels.
* if a congested node is part of multiple tunnels, and it causes congestion feedback to multiple traffic management functions at the ingresses of all the tunnels, the draft gives no advice on how all the traffic management functions should respond.
* etc. (in my full review, I will provide a full list of subjects that are out of scope).

[Wei] Ok.

S.3. Feedback Models:
The architecture diagrams and text need to include components that apply a consistent measurement policy (template records in IPFIX-speak) at both ingress and egress. This is a key part of interoperability, which is what the IETF should be all about. Template records are described later when the mechanism is specified, but they are not shown in the layout of the components in S.3.

[Wei] I will provide a description of Template record in this section. But I am wondering whether a detailed description of Template Record as section 6.1 is needed here or not?

I suggest that, at this stage in the doc, it would be best not to be specific to one technology (IPFIX) but instead to talk more generally about setting and storing measurement policy (at the decision point and the egress meter).

BTW, did you invent the terminology decision point (DP) and action point (AP)? Because there is already IETF terminology for these:
* Policy Decision Point (PDP)
* Policy Enforcement Point (PEP).

See COPS (Common Open Policy Service) Protocol [RFC2748] or terminology for policy-based management [RFC3198]



S.4. Congestion Level Measurement:
Measurement of ECN has been changed without thinking clearly whether it needed to change.

    a) Earlier drafts exploited the fact that the inner holds a "frozen" record of the ECN field at the ingress. So ECN measurements could be made solely at the egress (comparing the outer with the inner). In draft-04, ECN codepoints are measured at the ingress and at the egress, with the ingress sending regular measurement reports to the egress for comparison. However, it is always safer to measure ECN solely at the egress, even though a different mechanism has to measure drops within the tunnel (due to non-ECN nodes, or nodes that have switched off ECN due to overload, or due to causes of loss other than congestion, e.g. transmission errors).
     - It is always safer to solely measure ECN at the egress, because it is not vulnerable to ingress-egress measurement packets being dropped.
     - Solely measuring ECN at egress is no less precise, because only the proportion of the different ECN fields is needed, and that stays approximately the same even if there is drop, assuming drop is not biased towards certain ECN codepoints (no known mechanism does that).

    b) In draft-04 the faked ECT approach has been left unchanged at the ingress, but it is no longer used at the egress for detecting deferred drops (by looking for a Not-ECN inner and a CE outer). Again, there is nothing wrong with measuring ECN and detecting deferred drops solely at the egress, even if there are drops within the tunnel. To measure drops within the tunnel, it is necessary to compare ingress and egress bytes, but that does not make it wrong to still measure and compare ECN solely at the egress.

[Wei] I agree that solely measuring ECN at egress is enough to get the proportion of different ECN fields, but the reason why ECN codepoints are measured both at ingress and egress is to measure the packets dropped within the tunnel by comparing counts at ingress and egress.

I am not saying you should not also measure drop by measuring total bytes at ingress and egress.

However, I am saying it is less robust to have to measure at both ingress and egress, because it involves sending synch / measurement messages from ingress to egress, which can be lost/delayed.
So, I would recommend the more robust egress-only method for ECN, and the ingress-egress method only for total drop.

The only extra thing you learn by the currently proposed approach is how many of each ECN codepoint were dropped. If you think that's important, argue for it. I don't see any need for it tho.

If you insist on keeping the ingress-egress approach, why do you need the faked ECN text?




S.4. Congestion Level Measurement: Units
Throughout measurement involves counting packets. However, it should count the bytes in packets with each type of marking, not just the number of packets. See RFC7141 section 2.3. Although the recommendation in that RFC is about what a /transport/ should measure when responding to congestion, logically it should apply in this case when a traffic management function is responding in place of a transport. RFC7141 also gives recommendations on which headers to count.

[Wei] Ok, it’s a good suggestion.




I shall add to this review later in the week.

One question for Weixinpeng: Have you implemented this mechanism?

[Wei] Currently, we only implement this mechanism in a simulation environment.

I suspected as much, because the lack of detail in some places implies it is a bit theoretical.
I would encourage you to implement.



Bob



Bob


On 01/11/16 01:49, Weixinpeng (Jackie) wrote:

Hi Bob and David,

Because the deadline has passed, I will update it as part of post-WGLC update. Thanks.

 

Regards,

-Xinpeng (Jackie)

 

From: Black, David [mailto:David.Black@dell.com]
Sent: Tuesday, November 01, 2016 12:14 AM
To: Bob Briscoe; Weixinpeng (Jackie); draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list; Black, David
Subject: RE: Tunnel Congestion Feedback: (non-)update to RFC6040

 

> I assume you will update the TCF draft today before the deadline.

 

(As draft shepherd) That’s not really necessary - the TCF draft is in WGLC, so this change can be done as part of a post-WGLC update.

 

Thanks, --David

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Monday, October 31, 2016 11:22 AM
To: Weixinpeng (Jackie); Black, David; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Xinpeng,

I agree that TCF does not update RFC6040 (as I said).

But David is right that the TCF draft itself needs to be updated to say that it modifies the behaviour of a RFC6040 egress so as to issue or log any warnings when it receives an ECT(0) or CE outer with a Not-ECT inner.

I assume you will update the TCF draft today before the deadline.

Cheers

Bob

On 31/10/16 02:38, Weixinpeng (Jackie) wrote:

Hi David, Bob,

I agree that the behavior defined in RFC6040 doesn’t to be updated due to the TCF draft, because what’s defined in RFC 6040 has a broader usage and not just for TCF.

I think David has provided a good suggestion below. Thanks.

 

Regards,

-Xinpeng (Jackie)

 

From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David
Sent: Saturday, October 29, 2016 10:28 AM
To: Bob Briscoe; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040

 

Bob,

 

I think you’ve found something.  The TCF draft currently uses RFC 6040 behavior by reference:

 

   when decapsulating packets at egress,

   RFC6040 defined decapsulation behavior is used, and according to

   RFC6040, the packets marked as CE|N-ECT will be dropped by egress.

 

I think this needs to be slightly revised to say that CE|N-ECT is dropped without any other

action, and all other behavior is as per RFC 6040, as CE|N-ECT is expected at a TCF egress and

hence the logging and alarm behavior for that combination in RFC 6040 is inappropriate.

 

Once that’s done, I think your reasoning in the following sentence becomes correct:

 

If the network is not valid, these combination could become visible to a 6040-decap,

which would then (correctly) log warnings that it was seeing invalid codepoint combinations.

Thanks, --David (as draft shepherd)

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Thursday, October 27, 2016 4:39 PM
To: draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org; Black, David
Cc: tsvwg IETF list
Subject: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Tunnel congestion feedback authors, David as shepherd,

FYI. No action needed.

This email documents an argument with myself. After a few seconds, I agreed with myself that one of me was wrong. I thought I had better raise this on the list, to check that others agree with both of me. If you wish to argue with just one of me, please bear in mind that we both have the same email address (and anyway, we both agree so an argument with one is an argument with all).
_________________________

Figure 4 of RFC6040 specifies which ECN codepoint a decap must forward, for each combination of arriving inner (row) and outer (column).

            +---------+------------------------------------------------+
            |Arriving |            Arriving Outer Header               |
            |   Inner +---------+------------+------------+------------+
            |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
            +---------+---------+------------+------------+------------+
            | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
            |  ECT(0) |  ECT(0) | ECT(0)     | ECT(1)     |     CE     |
            |  ECT(1) |  ECT(1) | ECT(1) (!) | ECT(1)     |     CE     |
            |    CE   |      CE |     CE     |     CE(!!!)|     CE     |
            +---------+---------+------------+------------+------------+

RFC6040 goes on to say:

                      [...] These currently unused (CU) combinations are
      indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the
      combination is CU and always potentially dangerous, while '(!)'
      means it is CU and possibly dangerous.  In these cases,
      particularly the more dangerous ones, the decapsulator SHOULD log
      the event and MAY also raise an alarm.
 

TCF uses the following combinations of inner : outer
    Not-ECT : ECT(0)
    Not-ECT : CE

For a moment, I thought we would have to update RFC6040 to say that TCF makes these combinations no longer CU, so they are now valid, not dangerous, and they no longer need to be logged. This would have meant that Tunnel Congestion Feedback (TCF) (informational) would have to update RFC6040 (proposed standard).

Here's why I was wrong. These two combinations are certainly valid at a TCF decap. But there is still no way that, in a valid network, they would arrive at any RFC6040 (non-TCF) decap.

One might think that this combination could arrive at a 6040-decap if there was a tunnel inside a tunnel, as follows

  TCF-encap                 ---> 6040-decap ---> TCF-decap

However, that's not a valid configuration. The following tunnel-in-tunnel would be valid:

  TCF-encap ---> 6040-encap ---> 6040-decap ---> TCF-decap

...then, the above two "CU" combinations would be buried within a double inner, so only the TCF decap would see them, not the 6040-decap.

So, TCF does not need to update RFC6040. Because, in a valid network, TCF will be hidden from any 6040-decap. If the network is not valid, these combination could become visible to a 6040-decap, which would then (correctly) log warnings that it was seeing invalid codepoint combinations.

I just thought you'd like to know... no action required.



Bob

-- 

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

 

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




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



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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------2FEDDA9E8A25451C30234705-- From nobody Sat Apr 8 04:58:16 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A26B1201FA for ; Sat, 8 Apr 2017 04:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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=G+wA1KeA; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=VrsgzpQr 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 EERFGKPCL3Vn for ; Sat, 8 Apr 2017 04:58:12 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD2A126DEE for ; Sat, 8 Apr 2017 04:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1491652651; x=1523188651; h=from:to:subject:date:message-id:mime-version; bh=1NuxxUI8DgF5fQYe0UeATkjnWXQy6X6FlMwl+xFkG5c=; b=G+wA1KeAl0NLUWqqJqqdM0xvOUBT3ijMW1inv0Bbx+iddnFRofHxvG5K wUXkQ1ScyPgtCLMi3G7gTi/Nwt4MM4YtAiozWezKldN1lIYOrSyQAw48S jdo1eWb6ANshXKal+glel0yVeVbdeOCXEDXnhoL2nnM4mOaqTOpmXxKn6 0=; Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2017 06:57:30 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2017 17:54:58 +0600 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v38Bw9bu011496 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 8 Apr 2017 07:58:10 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v38Bw9bu011496 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1491652690; bh=YMxU89aJ4nUGisYE2noA4FnEc5Q=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=VrsgzpQrQl7O6xRLwcvS709XMKp6riFkgVc8o+gSvN0D9CiCbKaH35oFEOKdcwQzc qLM4WZPm655Er0h/WjTutgYDZNuwLUim57oTVPKvS2k6N6Axdd/iPZjJ9KgY21QI/r AyBCI6NlfC0DoWVJvHvTC0JTTaKxydSz4emeYPfo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v38Bw9bu011496 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd51.lss.emc.com (RSA Interceptor) for ; Sat, 8 Apr 2017 07:57:43 -0400 Received: from MXHUB315.corp.emc.com (MXHUB315.corp.emc.com [10.146.3.93]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v38Bvtkc019716 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Sat, 8 Apr 2017 07:57:56 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB315.corp.emc.com ([10.146.3.93]) with mapi id 14.03.0266.001; Sat, 8 Apr 2017 07:57:55 -0400 To: "tsvwg@ietf.org" Thread-Topic: Status of draft-ietf-tsvwg-tunnel-congestion-feedback Thread-Index: AdKwXaOMYPrzXK9kTkKj+gMJHRT5Qg== Date: Sat, 8 Apr 2017 11:57:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.97.62.161] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F9B4833MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] Status of draft-ietf-tsvwg-tunnel-congestion-feedback X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 11:58:15 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F9B4833MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Between Bob's and Joe's comments, we're going to need another version of th= e draft, although we don't yet have a resolution to Joe's issue around sect= ion 6 (nested/layered congestion management interaction), and more comments= from Bob are inbound. Thanks, --David ---------------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- --_000_CE03DB3D7B45C245BCA0D243277949362F9B4833MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Between Bob’s and Joe’s comments, weR= 17;re going to need another version of the draft, although we don’t y= et have a resolution to Joe’s issue around section 6 (nested/layered = congestion management interaction), and more comments from Bob are inbound.

 

Thanks, --David

----------------------------------------------------= ------------

David L. Black, Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (508) 293-7953    Mobile: += ;1 (978) 394-7754

David.Black@dell.com

----------------------------------------------------= ------------

 

--_000_CE03DB3D7B45C245BCA0D243277949362F9B4833MX307CL04corpem_-- From nobody Sun Apr 9 13:28:39 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4DA12702E; Sun, 9 Apr 2017 13:28:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149176971840.3141.11069042395098536887.idtracker@ietfa.amsl.com> Date: Sun, 09 Apr 2017 13:28:38 -0700 Archived-At: Subject: [tsvwg] The TSVWG WG has placed draft-briscoe-tsvwg-ecn-l4s-id in state "Adopted by a WG" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 20:28:38 -0000 The TSVWG WG has placed draft-briscoe-tsvwg-ecn-l4s-id in state Adopted by a WG (entered by Wesley Eddy) The document is available at https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-ecn-l4s-id/ From nobody Sun Apr 9 13:29:34 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E7B12702E; Sun, 9 Apr 2017 13:29:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149176977328.3153.17755924478369870672.idtracker@ietfa.amsl.com> Date: Sun, 09 Apr 2017 13:29:33 -0700 Archived-At: Subject: [tsvwg] The TSVWG WG has placed draft-briscoe-tsvwg-l4s-arch in state "Adopted by a WG" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 20:29:33 -0000 The TSVWG WG has placed draft-briscoe-tsvwg-l4s-arch in state Adopted by a WG (entered by Wesley Eddy) The document is available at https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-l4s-arch/ From nobody Sun Apr 9 13:31:10 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA50B126C22; Sun, 9 Apr 2017 13:31:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149176986895.3098.5922440127815035870.idtracker@ietfa.amsl.com> Date: Sun, 09 Apr 2017 13:31:08 -0700 Archived-At: Subject: [tsvwg] The TSVWG WG has placed draft-briscoe-tsvwg-aqm-dualq-coupled in state "Adopted by a WG" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 20:31:09 -0000 The TSVWG WG has placed draft-briscoe-tsvwg-aqm-dualq-coupled in state Adopted by a WG (entered by Wesley Eddy) The document is available at https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-aqm-dualq-coupled/ From nobody Sun Apr 9 13:31:48 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE161287A0 for ; Sun, 9 Apr 2017 13:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E-1sTQ9lhbm for ; Sun, 9 Apr 2017 13:31:45 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55D8128854 for ; Sun, 9 Apr 2017 13:31:44 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id v3so41984841qtd.3 for ; Sun, 09 Apr 2017 13:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=8QQX5vyo8ip3oUzNAHbLBU6WeCFPdUD9Y2HHsE0KhFM=; b=LnGOnoooMgOWoJPKOQA/dkldYhYbts/W+atFnh/Nw4OQl70iN1lxi0mCxquoSvW0Jn 7kW9mId/+g+7GZA/BtDS/Ek0tFF+aabr/lszQVwx2BrNutWAppPJcv5Fe74h66ulI4yu PKJMtVzlsPAnmT3YbxAU/+b/fkh1I4Qw9h7ml94/HdWNZ20S0I3aQyY2+S4vpCqMqyzd A+rO98X5a52k6BHWy6eia6NdYnu3MK8yziugXEMX7JFRG8CpBjKV9WCtNhHw3P0hAQem VJTzOHa4JDDjAJTaz4/xQ7YD4123OSlqlqZX0wpUUnv4iL5d51a+qdwv7PWkKcVok0// voMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8QQX5vyo8ip3oUzNAHbLBU6WeCFPdUD9Y2HHsE0KhFM=; b=EWGAZZ7Bl4rlWL4DrCxpHYnHo6EjLr0vNA+E6g13yAur2JzxAC19fb/Qp4WueXMVoz HN1bEOn2SLyGFNarGdQ1DzZfCF16JD48MieL11PsLXT4ic8CLkXI3wgD7gFT4pniACu6 2Ec0/gcEZ01xBeuY/LPfttFkfLjMjArAk4JYdWuZSsPIiIbYqulnXWGY5inDl2Juxosx xIx/xtz0SZr+K6661uXHLPgOp7WN1D/dAFM/z5CvA2656MQO2TaJm+ru9a6KhkXhfn7o dsSc2m/9Cx7trg+ZmOiMlrIwjvTNGaTmrXZE1gSCrNIWZ48rN+w7tSgY4sMV36XkBD91 1Xxg== X-Gm-Message-State: AFeK/H19R4j93ZslLYeGwMvnosS7egPt6qWrE5WgQMvNePxHla2TMFuuj6qL00jK0Y0p+A== X-Received: by 10.237.33.137 with SMTP id l9mr54821343qtc.157.1491769904105; Sun, 09 Apr 2017 13:31:44 -0700 (PDT) Received: from [192.168.1.108] (user-12l31ca.cable.mindspring.com. [69.81.133.138]) by smtp.gmail.com with ESMTPSA id m12sm1404695qtf.2.2017.04.09.13.31.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Apr 2017 13:31:43 -0700 (PDT) To: Michael Welzl References: <138206D2-85DF-4CAC-B196-7FC59304546A@ifi.uio.no> <372AFF1E-A1B4-4710-9EA5-25DBD74ED2FA@ifi.uio.no> <790d7485-0540-48cf-0b5e-e6eb4c83b2e8@mti-systems.com> <0AA31A63-B4C9-4767-8939-4FC0030E65C5@ifi.uio.no> Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" , tsvwg IETF list From: Wesley Eddy Message-ID: <5cec9b3c-dca8-4c89-46d1-561e62137709@mti-systems.com> Date: Sun, 9 Apr 2017 16:31:41 -0400 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: <0AA31A63-B4C9-4767-8939-4FC0030E65C5@ifi.uio.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] confirming adoption of L4S drafts X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 20:31:47 -0000 Ok, thanks for everyone's feedback. Since it's been a week, and there are no objections, I think we've fully confirmed the adoption call, and that the L4S editors should submit the next versions as draft-ietf-tsvwg-$X, and I"ve marked them as adopted in the datatracker. On 4/8/2017 5:00 AM, Michael Welzl wrote: > Hi, > > Yes to everything here. > > My crystal ball says that the work on the necessary heuristics might never really happen, which is what made me worry: then, what’s the use of L4S altogether? > However, that doesn’t matter much in the “controlled service provider” environment, and this convinces me; sorry, I hadn’t really thought this scenario through. My bad. > > So just to restate, I do agree that it would be good to adopt this work in TSVWG. > > Cheers, > Michael > > > >> On Apr 7, 2017, at 5:43 PM, Wesley Eddy wrote: >> >> Hi Michael, as co-chair shepherding these documents in TSVWG, I want to make sure if we're okay to proceed. >> >> You're obviously right that the corresponding scalable end-host behavior is work that needs to be done, and I agree that where that work is done in terms of WG, RG, etc. will need to be figured out, but I see those more as action items for follow-up in parallel, rather than roadblocks to proceeding with adopting work on the in-network behavior. I think the ADs will make sure this works out (and if it's not working out in time, they could kill off the L4S work at some point). I think your concern about defining the in-network behavior and codepoint without an end-host algorithm is something we should track as that work proceeds in parallel, and evaluate when we think L4S is mature enough for a last call. >> >> Certainly nobody would want to just go ahead and publish RFCs here, if it turns out to that there isn't promise of mature end-host algorithm work to go with it! I think WG participants, ADs, chairs, etc, can evaluate this as the work proceeds, but it shouldn't gate adoption. >> >> In my personal opinion, the ability to support DCTCP in private/managed networks is probably enough motivation alone, and that something for Internet end-hosts will obviously make it even better, but is just an expansion of the use cases rather than absolutely required to see value out of L4S. >> >> Would you agree that we can assume end-host algorithm research will keep proceeding (somewhere to be defined) in parallel, and that TSVWG should be doing these Experimental+Informational in-network pieces in the meantime? >> >> >> >> From nobody Sun Apr 9 18:38:03 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D587D128B8D for ; Sun, 9 Apr 2017 18:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 F37Tr7wRSRvg for ; Sun, 9 Apr 2017 18:37:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19D6127866 for ; Sun, 9 Apr 2017 18:37:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEK42270; Mon, 10 Apr 2017 01:37:56 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 10 Apr 2017 02:37:56 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.121]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Mon, 10 Apr 2017 09:37:45 +0800 From: "Weixinpeng (Jackie)" To: Joe Touch , tsvwg CC: Mark Townsley Thread-Topic: [tsvwg] question about layered congestion issue - draft-ietf-tsvwg-tunnel-congestion-feedback Thread-Index: AQHSqbXLprHSjHac3keA1AehQPXQlKG2CFYAgACDIwCAB1LM8A== Date: Mon, 10 Apr 2017 01:37:45 +0000 Message-ID: References: <77bbceb7-d905-d4b0-a250-41450ee56645@isi.edu> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58EAE1F5.001D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.121, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5805aff07649fa40f646ec01ed773191 Archived-At: Subject: Re: [tsvwg] question about layered congestion issue - draft-ietf-tsvwg-tunnel-congestion-feedback X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 01:38:02 -0000 SGkgSm9lLA0KIFRoZSBhcHByb2FjaCBpbiB0aGlzIGRyYWZ0IGFuZCB0aGUgY29uZ2VzdGlvbiBj b250cm9sIG9uIGVuZCBob3N0IHNob3VsZCBiZSBjb25zaWRlcmVkIGFzIHR3byBraW5kcyBvZiBz ZXBhcmF0ZWQgbWV0aG9kcy4NCiBUaGUgYXBwcm9hY2ggaW4gdGhpcyBkcmFmdCBzaG91bGQgYmUg Y29uc2lkZXJlZCBhcyBhIGtpbmQgb2YgdHJhZmZpYyBtYW5hZ2VtZW50IGFwcHJvYWNoLCBhbmQg d2UganVzdCB0cnkgdG8gYXZvaWQgY29uZmxpY3Rpbmcgd2l0aCBlMmUgY29uZ2VzdGlvbiBjb250 cm9sLg0KDQpUaGFua3MuDQoNCi1YaW5wZW5nKEphY2tpZSkNCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+U2VudDog VGh1cnNkYXksIEFwcmlsIDA2LCAyMDE3IDE6MzIgQU0NCj5UbzogV2VpeGlucGVuZyAoSmFja2ll KTsgdHN2d2cNCj5DYzogTWFyayBUb3duc2xleQ0KPlN1YmplY3Q6IFJlOiBbdHN2d2ddIHF1ZXN0 aW9uIGFib3V0IGxheWVyZWQgY29uZ2VzdGlvbiBpc3N1ZSAtDQo+ZHJhZnQtaWV0Zi10c3Z3Zy10 dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFjaw0KPg0KPkhpLCBYaW5wZW5nLA0KPg0KPg0KPk9uIDQv NC8yMDE3IDc6MTYgUE0sIFdlaXhpbnBlbmcgKEphY2tpZSkgd3JvdGU6DQo+PiAuLi4NCj4+IFtX ZWldIFRoZSBzZWN0aW9uIDYgb2YgdGhlIGRvY3VtZW50IGhhcyBwcm92aWRlZCBzb21lIGRlc2Ny aXB0aW9uIG9uIGhvdyB0aGUNCj5tZWNoYW5pc20gZGlzY3Vzc2lvbiBzaG91bGQgY29leGlzdGVu Y2Ugd2l0aCBlMmUgY29uZ2VzdGlvbiBjb250cm9sLg0KPj4gTGV0IG1lIGtub3cgaWYgaXQgZG9l c24ndCBhZGRyZXNzIHlvdXIgY29uY2VybnMuIFRoYW5rcy4NCj5JdCBkb2VzIG5vdC4NCj4NCj5N ZXJlbHkgYXNzZXJ0aW5nIHRoYXQgaGF2aW5nIGEgY29udHJvbCBsb29wIHRoYXQgaXMgbGFyZ2Vy IHRoYW4geW91ciBhc3N1bXB0aW9uDQo+YWJvdXQgZ2xvYmFsIFJUVCBpcyBpbnN1ZmZpY2llbnQg Zm9yIG1hbnkgcmVhc29uczoNCj4tIG1hbnkgc3lzdGVtcyBleHBlcmllbmNlIFJUVHMgdGhhdCBh cmUgbXVjaCBsYXJnZXIgLSBpbiB0aGUgMjUwbXMtMnMgcmFuZ2VzLA0KPmVpdGhlciBiZWNhdXNl IHRoZXkgdXNlIHNhdGVsbGl0ZSBjb25uZWN0aW9ucywgdHlwaWNhbCBuZXR3b3JrIHF1ZXVpbmcs IG9yDQo+YnVmZmVyYmxvYXQNCj4tIHNpbXBseSB1c2luZyBhIGxhcmdlciBSVFQgZG9lcyBub3Qg YXZvaWQgaGF2aW5nIHRoZSB0d28gc3lzdGVtcyBmaWdodCBlYWNoDQo+b3RoZXINCj4NCj5Zb3Ug aGF2ZSBubyBhbmFseXNpcywgbm8gbWVhc3VyZW1lbnRzLCBubyBleHBlcmltZW50cywgYW5kIG5v IHJlbGF0ZWQgd29yaw0KPmNpdGVkLg0KPg0KPlRoZSBlbnRpcmV0eSBvZiB0aGlzIGFwcHJvYWNo IGlzIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgdXNpbmcgdGhpcw0KPm1lY2hhbmlzbSBp cyBib3RoIHNhZmUgYW5kIGhlbHBmdWwuIFlvdSBuZWVkIHRvICpkZW1vbnN0cmF0ZSogdGhhdCB0 aGlzIGlzDQo+cG9zc2libGUgYW5kIGludGVncmF0ZSBjb25zdHJhaW50cyB0byBlbnN1cmUgc28s IG5vdCBtZXJlbHkgY2xhaW0gdGhhdCBpdCdzIHVwIHRvDQo+dGhlIGltcGxlbWVudGVyIHRvIGVu c3VyZSB0aGF0IHRoaXMgaGFzIGJlZW4gYWNjb21wbGlzaGVkLg0KPg0KPkpvZQ0K From nobody Sun Apr 9 19:03:45 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AD9126579 for ; Sun, 9 Apr 2017 19:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRdp0TUHBIk4 for ; Sun, 9 Apr 2017 19:03:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8171293FB for ; Sun, 9 Apr 2017 19:03:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKO99425; Mon, 10 Apr 2017 02:03:35 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 10 Apr 2017 03:03:33 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.121]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 10 Apr 2017 10:03:28 +0800 From: "Weixinpeng (Jackie)" To: Bob Briscoe , "Black, David" , "draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org" CC: tsvwg IETF list Thread-Topic: Tunnel Congestion Feedback: (non-)update to RFC6040 Thread-Index: AQHSMJIdqgBqqFRtE0e6Mhkxp5lkF6C+tKeAgAMnj6CAARqngP//y1HwgADkPACA8C0NAIADe+0AgAPuUwCAAGwmwIAAAEYAgAMvByA= Date: Mon, 10 Apr 2017 02:03:28 +0000 Message-ID: References: <712bfd85-39e5-bcae-f9b9-0035ef5cf654@bobbriscoe.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B48B3B4329nkgeml514mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58EAE7F8.008D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.121, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d24da2a5062a1112b0f5940da8974fa4 Archived-At: Subject: Re: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 02:03:45 -0000 --_000_C5C3BB522B1DDF478AA09545169155B48B3B4329nkgeml514mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIERhdmlkIGFuZCBCb2IsDQpJIHRoaW5rIHdlIGhhdmUgcmVhY2ggYSBjb25zZW5zdXMg dGhhdCBib3RoIGZha2VkIEVDTiArIGVncmVzc+KAk29ubHkgYXBwcm9hY2ggYW5kIGluZ3Jlc3Mt ZWdyZXNzIGNvbXBhcmlzb24gYXBwcm9hY2ggc2hvdWxkIGJlIHVzZSwgdGhlIGZpcnN0IGFwcHJv YWNoIGlzIGZvciAgRUNOIG1lYXN1cmVtZW50IGFuZCB0aGUgc2Vjb25kIGFwcHJvYWNoIGlzIGZv ciBwYWNrZXQgbG9zcyBjb3VudC4NCg0KLVhpbnBlbmcNCg0KRnJvbTogQm9iIEJyaXNjb2UgW21h aWx0bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogU2F0dXJkYXksIEFwcmlsIDA4LCAyMDE3 IDU6MTYgUE0NClRvOiBCbGFjaywgRGF2aWQ7IFdlaXhpbnBlbmcgKEphY2tpZSk7IGRyYWZ0LWll dGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmcNCkNjOiB0 c3Z3ZyBJRVRGIGxpc3QNClN1YmplY3Q6IFJlOiBUdW5uZWwgQ29uZ2VzdGlvbiBGZWVkYmFjazog KG5vbi0pdXBkYXRlIHRvIFJGQzYwNDANCg0KRGF2aWQsDQoNClRoeCBmb3IgYWxsIHlvdXIgcG9p bnRzIC0gYWxsIHVuZGVyc3Rvb2QgYW5kIEkgYWdyZWVkIHdpdGggdGhlbSBhbGwuDQoNCkkgdGhp bmsgbm93IHRoYXQgV2VpeGlucGVuZywgeW91IGFuZCBJIGFsbCBhZ3JlZSB0aGF0IHRoZSBkcmFm dCBzaG91bGQgc3BlY2lmeSBpbmdyZXNzLWVncmVzcyBjb21wYXJpc29uIGZvciBkcm9wIGFuZCB0 aGUgZWdyZXNzLW9ubHkgYXBwcm9hY2ggZm9yIEVDTi4gU28gdGhlbiB0aGUgZmFrZWQgRUNOIGFw cHJvYWNoIGNhbiBzdGF5LCBiZWNhdXNlIGl0IHNoaWZ0cyBzb21lL21vc3QgZHJvcHMgdG8gdGhl IG1vcmUgcm9idXN0IGVncmVzcy1vbmx5IG1lYXN1cmVtZW50IGxvY2F0aW9uLiBCdXQgSSBzdWdn ZXN0IHRoZSBmYWtlZCBFQ04gdGV4dCBpcyBtb3ZlZCB1cCBhIHBhcmFncmFwaCwgYmVjYXVzZSB0 aGUgcGFyYWdyYXBoIGJlZm9yZSBpdCBkb2Vzbid0IG1ha2Ugc2Vuc2UgdW5sZXNzIHRoZSByZWFk ZXJzIGFscmVhZHkga25vd3MgYWJvdXQgZmFrZWQgRUNOLg0KDQpJIHdpbGwgc3RpbGwgc2VuZCBh IGZ1bGwgcmV2aWV3LCBwb3NzaWJseSB0aGlzIHdlZWtlbmQsIGJ1dCBlYXJseSBuZXh0IHdlZWsg aXMgbG9va2luZyBtb3JlIGxpa2VseSBub3cuDQoNCg0KQm9iDQpPbiAwOC8wNC8xNyAwMjoyMCwg QmxhY2ssIERhdmlkIHdyb3RlOg0KSeKAmW0gYW1vbmcgdGhvc2UgcmVzcG9uc2libGUgZm9yIHRo ZSBpbmdyZXNzLWVncmVzcyBtZWFzdXJlbWVudCBhZGRpdGlvbiwgc28gd2VpZ2hpbmcgaW4gYXMg ZHJhZnQgc2hlcGhlcmQ6DQoNCj4gSG93ZXZlciwgSSBhbSBzYXlpbmcgaXQgaXMgbGVzcyByb2J1 c3QgdG8gaGF2ZSB0byBtZWFzdXJlIGF0IGJvdGggaW5ncmVzcyBhbmQgZWdyZXNzLCBiZWNhdXNl IGl0IGludm9sdmVzIHNlbmRpbmcgc3luY2ggLyBtZWFzdXJlbWVudA0KPiBtZXNzYWdlcyBmcm9t IGluZ3Jlc3MgdG8gZWdyZXNzLCB3aGljaCBjYW4gYmUgbG9zdC9kZWxheWVkLiAgU28sIEkgd291 bGQgcmVjb21tZW5kIHRoZSBtb3JlIHJvYnVzdCBlZ3Jlc3Mtb25seSBtZXRob2QgZm9yIEVDTiwN Cj4gYW5kIHRoZSBpbmdyZXNzLWVncmVzcyBtZXRob2Qgb25seSBmb3IgdG90YWwgZHJvcC4NCg0K DQpUaGF0IHNlZW1zIGZpbmUsIGhvd2V2ZXIgdGhlIHRvdGFsIGRyb3AgaW5mbyBkb2VzIG5lZWQg dG8gYmUgcmVwb3J0ZWQgaW4gYWRkaXRpb24gdG8gRUNOIGluZm8uDQoNCj4gVGhlIG9ubHkgZXh0 cmEgdGhpbmcgeW91IGxlYXJuIGJ5IHRoZSBjdXJyZW50bHkgcHJvcG9zZWQgYXBwcm9hY2ggaXMg aG93IG1hbnkgb2YgZWFjaCBFQ04gY29kZXBvaW50IHdlcmUgZHJvcHBlZC4gSWYgeW91IHRoaW5r IHRoYXQncyBpbXBvcnRhbnQsIGFyZ3VlIGZvciBpdC4gSSBkb24ndCBzZWUgYW55IG5lZWQgZm9y IGl0IHRoby4NCg0KSSB3b3VsZCBhZ3JlZS4NCg0KPiBJZiB5b3UgaW5zaXN0IG9uIGtlZXBpbmcg dGhlIGluZ3Jlc3MtZWdyZXNzIGFwcHJvYWNoLCB3aHkgZG8geW91IG5lZWQgdGhlIGZha2VkIEVD TiB0ZXh0Pw0KDQpJZiBvbmUgaXMgdHJ5aW5nIHRvIG1lYXN1cmUgY29uZ2VzdGlvbiBpbiB0aGUg dHVubmVsLCBkcm9wcyBoYXZlIHRvIGJlIGNvbnNpZGVyZWQg4oCTIGV2ZW4gaWYgYWxsIG5vZGVz IGluIHRoZSB0dW5uZWwgc3VwcG9ydCBFQ04sIGFuIG92ZXJsb2FkZWQgRUNOIG5vZGUgd2lsbCBk cm9wIHBhY2tldHMuDQpUaGUgcmVhc29uIGZvciBmYWtlZC1FQ04gaXMgYnVyaWVkIGluIEJvYuKA mXMg4oCcbW9yZSByb2J1c3TigJ0gY29tbWVudCBhYm91dCBlZ3Jlc3Mtb25seSBFQ04gbWVhc3Vy ZW1lbnQgYWJvdmUg4oCTIHVzZSBvZiBFQ04gc2hvdWxkIHJlc3VsdCBpbiBiZXR0ZXIgbWVhc3Vy ZW1lbnRzIGJ5IGNvbXBhcmlzb24gdG8gbm9uLXVzZS4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCkZy b206IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldF0NClNlbnQ6IEZyaWRh eSwgQXByaWwgNywgMjAxNyAxMDo0OCBBTQ0KVG86IFdlaXhpbnBlbmcgKEphY2tpZSkgPHdlaXhp bnBlbmdAaHVhd2VpLmNvbT48bWFpbHRvOndlaXhpbnBlbmdAaHVhd2VpLmNvbT47IEJsYWNrLCBE YXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT48bWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb20+OyBk cmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3Jn PG1haWx0bzpkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xz LmlldGYub3JnPg0KQ2M6IHRzdndnIElFVEYgbGlzdCA8dHN2d2dAaWV0Zi5vcmc+PG1haWx0bzp0 c3Z3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBUdW5uZWwgQ29uZ2VzdGlvbiBGZWVkYmFjazog KG5vbi0pdXBkYXRlIHRvIFJGQzYwNDANCg0KV2VpeGlucGVuZywNCk9uIDA1LzA0LzE3IDAzOjQ1 LCBXZWl4aW5wZW5nIChKYWNraWUpIHdyb3RlOg0KSGkgQm9iLA0KVGhhbmtzIGZvciB5b3VyIGNv bW1lbnRzLCBhbmQgcGxlYXNlIHNlZSBpbmxpbmUuDQpSZWdhcmRzLA0KLVhpbnBlbmcNCg0KRnJv bTogQm9iIEJyaXNjb2UgW21haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogTW9uZGF5 LCBBcHJpbCAwMywgMjAxNyA1OjM0IEFNDQpUbzogV2VpeGlucGVuZyAoSmFja2llKTsgQmxhY2ss IERhdmlkOyBkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xz LmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRi YWNrQHRvb2xzLmlldGYub3JnPg0KQ2M6IHRzdndnIElFVEYgbGlzdA0KU3ViamVjdDogUmU6IFR1 bm5lbCBDb25nZXN0aW9uIEZlZWRiYWNrOiAobm9uLSl1cGRhdGUgdG8gUkZDNjA0MA0KDQpXZWl4 aW5wZW5nLCBjby1hdXRob3JzLCAgYW5kIERhdmlkLA0KDQpJIGhhZCBwcm9taXNlZCBhIHJldmll dyBvZiB0aGUgbGF0ZXN0IFRDRiBkcmFmdCwgYnV0IGZhaWxlZCB0byBwcm92aWRlIGl0IHNvIGZh ci4NCkkgaGFsZiByZWFkIGl0IHRocm91Z2ggb24gRnJpZGF5LCBhbmQgSSB3aWxsIGZpbmlzaCBh bmQgd3JpdGUgdXAgbXkgcmV2aWV3IHRoaXMgd2Vlay4NCg0KSGVyZScgYSBxdWljayBzdW1tYXJ5 IG9mIHRoZSBtYWluIHBvaW50cyBzbyBmYXI6DQoNClMuMS4gSW50cm86IE1vdGl2YXRpb24NClRo ZSBtb3RpdmF0aW9uIHNob3VsZCBhbHNvIGluY2x1ZGUgYSBoZWF2eSBsb2FkIGZyb20gYSBtdWNo IGxhcmdlciB0aGFuIGV4cGVjdGVkIG51bWJlciBvZiByZXNwb25zaXZlIGZsb3dzDQpbV2VpXSBP aywgSSB3aWxsIGFkZCBpdC4NCg0KUy4xIEludHJvOiBTY29wZQ0KSSB0aGluayB0aGUgZHJhZnQg c2hvdWxkIHNheSB0aGF0DQoqIGl0IGdpdmVzIG5vIGFkdmljZSBvbiBob3cgdG8gc2VsZWN0IHdo aWNoIHR1bm5lbCBlbmRwb2ludHMgc2hvdWxkIGJlIHVzZWQgaW4gb3JkZXIgdG8gbWFuYWdlIHRy YWZmaWMgb3ZlciBhIG5ldHdvcmsgY3Jpc3MtY3Jvc3NlZCBieSBtdWx0aXBsZSB0dW5uZWxzLg0K KiBpZiBhIGNvbmdlc3RlZCBub2RlIGlzIHBhcnQgb2YgbXVsdGlwbGUgdHVubmVscywgYW5kIGl0 IGNhdXNlcyBjb25nZXN0aW9uIGZlZWRiYWNrIHRvIG11bHRpcGxlIHRyYWZmaWMgbWFuYWdlbWVu dCBmdW5jdGlvbnMgYXQgdGhlIGluZ3Jlc3NlcyBvZiBhbGwgdGhlIHR1bm5lbHMsIHRoZSBkcmFm dCBnaXZlcyBubyBhZHZpY2Ugb24gaG93IGFsbCB0aGUgdHJhZmZpYyBtYW5hZ2VtZW50IGZ1bmN0 aW9ucyBzaG91bGQgcmVzcG9uZC4NCiogZXRjLiAoaW4gbXkgZnVsbCByZXZpZXcsIEkgd2lsbCBw cm92aWRlIGEgZnVsbCBsaXN0IG9mIHN1YmplY3RzIHRoYXQgYXJlIG91dCBvZiBzY29wZSkuDQpb V2VpXSBPay4NCg0KUy4zLiBGZWVkYmFjayBNb2RlbHM6DQpUaGUgYXJjaGl0ZWN0dXJlIGRpYWdy YW1zIGFuZCB0ZXh0IG5lZWQgdG8gaW5jbHVkZSBjb21wb25lbnRzIHRoYXQgYXBwbHkgYSBjb25z aXN0ZW50IG1lYXN1cmVtZW50IHBvbGljeSAodGVtcGxhdGUgcmVjb3JkcyBpbiBJUEZJWC1zcGVh aykgYXQgYm90aCBpbmdyZXNzIGFuZCBlZ3Jlc3MuIFRoaXMgaXMgYSBrZXkgcGFydCBvZiBpbnRl cm9wZXJhYmlsaXR5LCB3aGljaCBpcyB3aGF0IHRoZSBJRVRGIHNob3VsZCBiZSBhbGwgYWJvdXQu IFRlbXBsYXRlIHJlY29yZHMgYXJlIGRlc2NyaWJlZCBsYXRlciB3aGVuIHRoZSBtZWNoYW5pc20g aXMgc3BlY2lmaWVkLCBidXQgdGhleSBhcmUgbm90IHNob3duIGluIHRoZSBsYXlvdXQgb2YgdGhl IGNvbXBvbmVudHMgaW4gUy4zLg0KW1dlaV0gSSB3aWxsIHByb3ZpZGUgYSBkZXNjcmlwdGlvbiBv ZiBUZW1wbGF0ZSByZWNvcmQgaW4gdGhpcyBzZWN0aW9uLiBCdXQgSSBhbSB3b25kZXJpbmcgd2hl dGhlciBhIGRldGFpbGVkIGRlc2NyaXB0aW9uIG9mIFRlbXBsYXRlIFJlY29yZCBhcyBzZWN0aW9u IDYuMSBpcyBuZWVkZWQgaGVyZSBvciBub3Q/DQpJIHN1Z2dlc3QgdGhhdCwgYXQgdGhpcyBzdGFn ZSBpbiB0aGUgZG9jLCBpdCB3b3VsZCBiZSBiZXN0IG5vdCB0byBiZSBzcGVjaWZpYyB0byBvbmUg dGVjaG5vbG9neSAoSVBGSVgpIGJ1dCBpbnN0ZWFkIHRvIHRhbGsgbW9yZSBnZW5lcmFsbHkgYWJv dXQgc2V0dGluZyBhbmQgc3RvcmluZyBtZWFzdXJlbWVudCBwb2xpY3kgKGF0IHRoZSBkZWNpc2lv biBwb2ludCBhbmQgdGhlIGVncmVzcyBtZXRlcikuDQoNCkJUVywgZGlkIHlvdSBpbnZlbnQgdGhl IHRlcm1pbm9sb2d5IGRlY2lzaW9uIHBvaW50IChEUCkgYW5kIGFjdGlvbiBwb2ludCAoQVApPyBC ZWNhdXNlIHRoZXJlIGlzIGFscmVhZHkgSUVURiB0ZXJtaW5vbG9neSBmb3IgdGhlc2U6DQoqIFBv bGljeSBEZWNpc2lvbiBQb2ludCAoUERQKQ0KKiBQb2xpY3kgRW5mb3JjZW1lbnQgUG9pbnQgKFBF UCkuDQoNClNlZSBDT1BTIChDb21tb24gT3BlbiBQb2xpY3kgU2VydmljZSkgUHJvdG9jb2wgW1JG QzI3NDhdIG9yIHRlcm1pbm9sb2d5IGZvciBwb2xpY3ktYmFzZWQgbWFuYWdlbWVudCBbUkZDMzE5 OF0NCg0KDQoNCg0KUy40LiBDb25nZXN0aW9uIExldmVsIE1lYXN1cmVtZW50Og0KTWVhc3VyZW1l bnQgb2YgRUNOIGhhcyBiZWVuIGNoYW5nZWQgd2l0aG91dCB0aGlua2luZyBjbGVhcmx5IHdoZXRo ZXIgaXQgbmVlZGVkIHRvIGNoYW5nZS4NCg0KICAgIGEpIEVhcmxpZXIgZHJhZnRzIGV4cGxvaXRl ZCB0aGUgZmFjdCB0aGF0IHRoZSBpbm5lciBob2xkcyBhICJmcm96ZW4iIHJlY29yZCBvZiB0aGUg RUNOIGZpZWxkIGF0IHRoZSBpbmdyZXNzLiBTbyBFQ04gbWVhc3VyZW1lbnRzIGNvdWxkIGJlIG1h ZGUgc29sZWx5IGF0IHRoZSBlZ3Jlc3MgKGNvbXBhcmluZyB0aGUgb3V0ZXIgd2l0aCB0aGUgaW5u ZXIpLiBJbiBkcmFmdC0wNCwgRUNOIGNvZGVwb2ludHMgYXJlIG1lYXN1cmVkIGF0IHRoZSBpbmdy ZXNzIGFuZCBhdCB0aGUgZWdyZXNzLCB3aXRoIHRoZSBpbmdyZXNzIHNlbmRpbmcgcmVndWxhciBt ZWFzdXJlbWVudCByZXBvcnRzIHRvIHRoZSBlZ3Jlc3MgZm9yIGNvbXBhcmlzb24uIEhvd2V2ZXIs IGl0IGlzIGFsd2F5cyBzYWZlciB0byBtZWFzdXJlIEVDTiBzb2xlbHkgYXQgdGhlIGVncmVzcywg ZXZlbiB0aG91Z2ggYSBkaWZmZXJlbnQgbWVjaGFuaXNtIGhhcyB0byBtZWFzdXJlIGRyb3BzIHdp dGhpbiB0aGUgdHVubmVsIChkdWUgdG8gbm9uLUVDTiBub2Rlcywgb3Igbm9kZXMgdGhhdCBoYXZl IHN3aXRjaGVkIG9mZiBFQ04gZHVlIHRvIG92ZXJsb2FkLCBvciBkdWUgdG8gY2F1c2VzIG9mIGxv c3Mgb3RoZXIgdGhhbiBjb25nZXN0aW9uLCBlLmcuIHRyYW5zbWlzc2lvbiBlcnJvcnMpLg0KICAg ICAtIEl0IGlzIGFsd2F5cyBzYWZlciB0byBzb2xlbHkgbWVhc3VyZSBFQ04gYXQgdGhlIGVncmVz cywgYmVjYXVzZSBpdCBpcyBub3QgdnVsbmVyYWJsZSB0byBpbmdyZXNzLWVncmVzcyBtZWFzdXJl bWVudCBwYWNrZXRzIGJlaW5nIGRyb3BwZWQuDQogICAgIC0gU29sZWx5IG1lYXN1cmluZyBFQ04g YXQgZWdyZXNzIGlzIG5vIGxlc3MgcHJlY2lzZSwgYmVjYXVzZSBvbmx5IHRoZSBwcm9wb3J0aW9u IG9mIHRoZSBkaWZmZXJlbnQgRUNOIGZpZWxkcyBpcyBuZWVkZWQsIGFuZCB0aGF0IHN0YXlzIGFw cHJveGltYXRlbHkgdGhlIHNhbWUgZXZlbiBpZiB0aGVyZSBpcyBkcm9wLCBhc3N1bWluZyBkcm9w IGlzIG5vdCBiaWFzZWQgdG93YXJkcyBjZXJ0YWluIEVDTiBjb2RlcG9pbnRzIChubyBrbm93biBt ZWNoYW5pc20gZG9lcyB0aGF0KS4NCg0KICAgIGIpIEluIGRyYWZ0LTA0IHRoZSBmYWtlZCBFQ1Qg YXBwcm9hY2ggaGFzIGJlZW4gbGVmdCB1bmNoYW5nZWQgYXQgdGhlIGluZ3Jlc3MsIGJ1dCBpdCBp cyBubyBsb25nZXIgdXNlZCBhdCB0aGUgZWdyZXNzIGZvciBkZXRlY3RpbmcgZGVmZXJyZWQgZHJv cHMgKGJ5IGxvb2tpbmcgZm9yIGEgTm90LUVDTiBpbm5lciBhbmQgYSBDRSBvdXRlcikuIEFnYWlu LCB0aGVyZSBpcyBub3RoaW5nIHdyb25nIHdpdGggbWVhc3VyaW5nIEVDTiBhbmQgZGV0ZWN0aW5n IGRlZmVycmVkIGRyb3BzIHNvbGVseSBhdCB0aGUgZWdyZXNzLCBldmVuIGlmIHRoZXJlIGFyZSBk cm9wcyB3aXRoaW4gdGhlIHR1bm5lbC4gVG8gbWVhc3VyZSBkcm9wcyB3aXRoaW4gdGhlIHR1bm5l bCwgaXQgaXMgbmVjZXNzYXJ5IHRvIGNvbXBhcmUgaW5ncmVzcyBhbmQgZWdyZXNzIGJ5dGVzLCBi dXQgdGhhdCBkb2VzIG5vdCBtYWtlIGl0IHdyb25nIHRvIHN0aWxsIG1lYXN1cmUgYW5kIGNvbXBh cmUgRUNOIHNvbGVseSBhdCB0aGUgZWdyZXNzLg0KW1dlaV0gSSBhZ3JlZSB0aGF0IHNvbGVseSBt ZWFzdXJpbmcgRUNOIGF0IGVncmVzcyBpcyBlbm91Z2ggdG8gZ2V0IHRoZSBwcm9wb3J0aW9uIG9m IGRpZmZlcmVudCBFQ04gZmllbGRzLCBidXQgdGhlIHJlYXNvbiB3aHkgRUNOIGNvZGVwb2ludHMg YXJlIG1lYXN1cmVkIGJvdGggYXQgaW5ncmVzcyBhbmQgZWdyZXNzIGlzIHRvIG1lYXN1cmUgdGhl IHBhY2tldHMgZHJvcHBlZCB3aXRoaW4gdGhlIHR1bm5lbCBieSBjb21wYXJpbmcgY291bnRzIGF0 IGluZ3Jlc3MgYW5kIGVncmVzcy4NCkkgYW0gbm90IHNheWluZyB5b3Ugc2hvdWxkIG5vdCBhbHNv IG1lYXN1cmUgZHJvcCBieSBtZWFzdXJpbmcgdG90YWwgYnl0ZXMgYXQgaW5ncmVzcyBhbmQgZWdy ZXNzLg0KDQpIb3dldmVyLCBJIGFtIHNheWluZyBpdCBpcyBsZXNzIHJvYnVzdCB0byBoYXZlIHRv IG1lYXN1cmUgYXQgYm90aCBpbmdyZXNzIGFuZCBlZ3Jlc3MsIGJlY2F1c2UgaXQgaW52b2x2ZXMg c2VuZGluZyBzeW5jaCAvIG1lYXN1cmVtZW50IG1lc3NhZ2VzIGZyb20gaW5ncmVzcyB0byBlZ3Jl c3MsIHdoaWNoIGNhbiBiZSBsb3N0L2RlbGF5ZWQuDQpTbywgSSB3b3VsZCByZWNvbW1lbmQgdGhl IG1vcmUgcm9idXN0IGVncmVzcy1vbmx5IG1ldGhvZCBmb3IgRUNOLCBhbmQgdGhlIGluZ3Jlc3Mt ZWdyZXNzIG1ldGhvZCBvbmx5IGZvciB0b3RhbCBkcm9wLg0KDQpUaGUgb25seSBleHRyYSB0aGlu ZyB5b3UgbGVhcm4gYnkgdGhlIGN1cnJlbnRseSBwcm9wb3NlZCBhcHByb2FjaCBpcyBob3cgbWFu eSBvZiBlYWNoIEVDTiBjb2RlcG9pbnQgd2VyZSBkcm9wcGVkLiBJZiB5b3UgdGhpbmsgdGhhdCdz IGltcG9ydGFudCwgYXJndWUgZm9yIGl0LiBJIGRvbid0IHNlZSBhbnkgbmVlZCBmb3IgaXQgdGhv Lg0KDQpJZiB5b3UgaW5zaXN0IG9uIGtlZXBpbmcgdGhlIGluZ3Jlc3MtZWdyZXNzIGFwcHJvYWNo LCB3aHkgZG8geW91IG5lZWQgdGhlIGZha2VkIEVDTiB0ZXh0Pw0KDQoNCg0KDQoNClMuNC4gQ29u Z2VzdGlvbiBMZXZlbCBNZWFzdXJlbWVudDogVW5pdHMNClRocm91Z2hvdXQgbWVhc3VyZW1lbnQg aW52b2x2ZXMgY291bnRpbmcgcGFja2V0cy4gSG93ZXZlciwgaXQgc2hvdWxkIGNvdW50IHRoZSBi eXRlcyBpbiBwYWNrZXRzIHdpdGggZWFjaCB0eXBlIG9mIG1hcmtpbmcsIG5vdCBqdXN0IHRoZSBu dW1iZXIgb2YgcGFja2V0cy4gU2VlIFJGQzcxNDEgc2VjdGlvbiAyLjM8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzcxNDEjc2VjdGlvbi0yLjM+LiBBbHRob3VnaCB0aGUgcmVjb21tZW5k YXRpb24gaW4gdGhhdCBSRkMgaXMgYWJvdXQgd2hhdCBhIC90cmFuc3BvcnQvIHNob3VsZCBtZWFz dXJlIHdoZW4gcmVzcG9uZGluZyB0byBjb25nZXN0aW9uLCBsb2dpY2FsbHkgaXQgc2hvdWxkIGFw cGx5IGluIHRoaXMgY2FzZSB3aGVuIGEgdHJhZmZpYyBtYW5hZ2VtZW50IGZ1bmN0aW9uIGlzIHJl c3BvbmRpbmcgaW4gcGxhY2Ugb2YgYSB0cmFuc3BvcnQuIFJGQzcxNDEgYWxzbyBnaXZlcyByZWNv bW1lbmRhdGlvbnMgb24gd2hpY2ggaGVhZGVycyB0byBjb3VudC4NCltXZWldIE9rLCBpdOKAmXMg YSBnb29kIHN1Z2dlc3Rpb24uDQoNCg0KDQpJIHNoYWxsIGFkZCB0byB0aGlzIHJldmlldyBsYXRl ciBpbiB0aGUgd2Vlay4NCg0KT25lIHF1ZXN0aW9uIGZvciBXZWl4aW5wZW5nOiBIYXZlIHlvdSBp bXBsZW1lbnRlZCB0aGlzIG1lY2hhbmlzbT8NCltXZWldIEN1cnJlbnRseSwgd2Ugb25seSBpbXBs ZW1lbnQgdGhpcyBtZWNoYW5pc20gaW4gYSBzaW11bGF0aW9uIGVudmlyb25tZW50Lg0KSSBzdXNw ZWN0ZWQgYXMgbXVjaCwgYmVjYXVzZSB0aGUgbGFjayBvZiBkZXRhaWwgaW4gc29tZSBwbGFjZXMg aW1wbGllcyBpdCBpcyBhIGJpdCB0aGVvcmV0aWNhbC4NCkkgd291bGQgZW5jb3VyYWdlIHlvdSB0 byBpbXBsZW1lbnQuDQoNCg0KDQpCb2INCg0KDQoNCg0KQm9iDQoNCg0KDQpPbiAwMS8xMS8xNiAw MTo0OSwgV2VpeGlucGVuZyAoSmFja2llKSB3cm90ZToNCkhpIEJvYiBhbmQgRGF2aWQsDQpCZWNh dXNlIHRoZSBkZWFkbGluZSBoYXMgcGFzc2VkLCBJIHdpbGwgdXBkYXRlIGl0IGFzIHBhcnQgb2Yg cG9zdC1XR0xDIHVwZGF0ZS4gVGhhbmtzLg0KDQpSZWdhcmRzLA0KLVhpbnBlbmcgKEphY2tpZSkN Cg0KRnJvbTogQmxhY2ssIERhdmlkIFttYWlsdG86RGF2aWQuQmxhY2tAZGVsbC5jb21dDQpTZW50 OiBUdWVzZGF5LCBOb3ZlbWJlciAwMSwgMjAxNiAxMjoxNCBBTQ0KVG86IEJvYiBCcmlzY29lOyBX ZWl4aW5wZW5nIChKYWNraWUpOyBkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZl ZWRiYWNrQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25n ZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmlldGYub3JnPg0KQ2M6IHRzdndnIElFVEYgbGlzdDsgQmxh Y2ssIERhdmlkDQpTdWJqZWN0OiBSRTogVHVubmVsIENvbmdlc3Rpb24gRmVlZGJhY2s6IChub24t KXVwZGF0ZSB0byBSRkM2MDQwDQoNCj4gSSBhc3N1bWUgeW91IHdpbGwgdXBkYXRlIHRoZSBUQ0Yg ZHJhZnQgdG9kYXkgYmVmb3JlIHRoZSBkZWFkbGluZS4NCg0KKEFzIGRyYWZ0IHNoZXBoZXJkKSBU aGF04oCZcyBub3QgcmVhbGx5IG5lY2Vzc2FyeSAtIHRoZSBUQ0YgZHJhZnQgaXMgaW4gV0dMQywg c28gdGhpcyBjaGFuZ2UgY2FuIGJlIGRvbmUgYXMgcGFydCBvZiBhIHBvc3QtV0dMQyB1cGRhdGUu DQoNClRoYW5rcywgLS1EYXZpZA0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmlldGZAYm9i YnJpc2NvZS5uZXRdDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMzEsIDIwMTYgMTE6MjIgQU0NClRv OiBXZWl4aW5wZW5nIChKYWNraWUpOyBCbGFjaywgRGF2aWQ7IGRyYWZ0LWlldGYtdHN2d2ctdHVu bmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt dHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmc+DQpDYzogdHN2 d2cgSUVURiBsaXN0DQpTdWJqZWN0OiBSZTogVHVubmVsIENvbmdlc3Rpb24gRmVlZGJhY2s6IChu b24tKXVwZGF0ZSB0byBSRkM2MDQwDQoNClhpbnBlbmcsDQoNCkkgYWdyZWUgdGhhdCBUQ0YgZG9l cyBub3QgdXBkYXRlIFJGQzYwNDAgKGFzIEkgc2FpZCkuDQoNCkJ1dCBEYXZpZCBpcyByaWdodCB0 aGF0IHRoZSBUQ0YgZHJhZnQgaXRzZWxmIG5lZWRzIHRvIGJlIHVwZGF0ZWQgdG8gc2F5IHRoYXQg aXQgbW9kaWZpZXMgdGhlIGJlaGF2aW91ciBvZiBhIFJGQzYwNDAgZWdyZXNzIHNvIGFzIHRvIGlz c3VlIG9yIGxvZyBhbnkgd2FybmluZ3Mgd2hlbiBpdCByZWNlaXZlcyBhbiBFQ1QoMCkgb3IgQ0Ug b3V0ZXIgd2l0aCBhIE5vdC1FQ1QgaW5uZXIuDQoNCkkgYXNzdW1lIHlvdSB3aWxsIHVwZGF0ZSB0 aGUgVENGIGRyYWZ0IHRvZGF5IGJlZm9yZSB0aGUgZGVhZGxpbmUuDQoNCkNoZWVycw0KDQpCb2IN Ck9uIDMxLzEwLzE2IDAyOjM4LCBXZWl4aW5wZW5nIChKYWNraWUpIHdyb3RlOg0KSGkgRGF2aWQs IEJvYiwNCkkgYWdyZWUgdGhhdCB0aGUgYmVoYXZpb3IgZGVmaW5lZCBpbiBSRkM2MDQwIGRvZXNu 4oCZdCB0byBiZSB1cGRhdGVkIGR1ZSB0byB0aGUgVENGIGRyYWZ0LCBiZWNhdXNlIHdoYXTigJlz IGRlZmluZWQgaW4gUkZDIDYwNDAgaGFzIGEgYnJvYWRlciB1c2FnZSBhbmQgbm90IGp1c3QgZm9y IFRDRi4NCkkgdGhpbmsgRGF2aWQgaGFzIHByb3ZpZGVkIGEgZ29vZCBzdWdnZXN0aW9uIGJlbG93 LiBUaGFua3MuDQoNClJlZ2FyZHMsDQotWGlucGVuZyAoSmFja2llKQ0KDQpGcm9tOiB0c3Z3ZyBb bWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCbGFjaywgRGF2aWQN ClNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDI5LCAyMDE2IDEwOjI4IEFNDQpUbzogQm9iIEJyaXNj b2U7IGRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tA dG9vbHMuaWV0Zi5vcmc+DQpDYzogdHN2d2cgSUVURiBsaXN0DQpTdWJqZWN0OiBSZTogW3Rzdndn XSBUdW5uZWwgQ29uZ2VzdGlvbiBGZWVkYmFjazogKG5vbi0pdXBkYXRlIHRvIFJGQzYwNDANCg0K Qm9iLA0KDQpJIHRoaW5rIHlvdeKAmXZlIGZvdW5kIHNvbWV0aGluZy4gIFRoZSBUQ0YgZHJhZnQg Y3VycmVudGx5IHVzZXMgUkZDIDYwNDAgYmVoYXZpb3IgYnkgcmVmZXJlbmNlOg0KDQogICB3aGVu IGRlY2Fwc3VsYXRpbmcgcGFja2V0cyBhdCBlZ3Jlc3MsDQogICBSRkM2MDQwIGRlZmluZWQgZGVj YXBzdWxhdGlvbiBiZWhhdmlvciBpcyB1c2VkLCBhbmQgYWNjb3JkaW5nIHRvDQogICBSRkM2MDQw LCB0aGUgcGFja2V0cyBtYXJrZWQgYXMgQ0V8Ti1FQ1Qgd2lsbCBiZSBkcm9wcGVkIGJ5IGVncmVz cy4NCg0KSSB0aGluayB0aGlzIG5lZWRzIHRvIGJlIHNsaWdodGx5IHJldmlzZWQgdG8gc2F5IHRo YXQgQ0V8Ti1FQ1QgaXMgZHJvcHBlZCB3aXRob3V0IGFueSBvdGhlcg0KYWN0aW9uLCBhbmQgYWxs IG90aGVyIGJlaGF2aW9yIGlzIGFzIHBlciBSRkMgNjA0MCwgYXMgQ0V8Ti1FQ1QgaXMgZXhwZWN0 ZWQgYXQgYSBUQ0YgZWdyZXNzIGFuZA0KaGVuY2UgdGhlIGxvZ2dpbmcgYW5kIGFsYXJtIGJlaGF2 aW9yIGZvciB0aGF0IGNvbWJpbmF0aW9uIGluIFJGQyA2MDQwIGlzIGluYXBwcm9wcmlhdGUuDQoN Ck9uY2UgdGhhdOKAmXMgZG9uZSwgSSB0aGluayB5b3VyIHJlYXNvbmluZyBpbiB0aGUgZm9sbG93 aW5nIHNlbnRlbmNlIGJlY29tZXMgY29ycmVjdDoNCg0KSWYgdGhlIG5ldHdvcmsgaXMgbm90IHZh bGlkLCB0aGVzZSBjb21iaW5hdGlvbiBjb3VsZCBiZWNvbWUgdmlzaWJsZSB0byBhIDYwNDAtZGVj YXAsDQp3aGljaCB3b3VsZCB0aGVuIChjb3JyZWN0bHkpIGxvZyB3YXJuaW5ncyB0aGF0IGl0IHdh cyBzZWVpbmcgaW52YWxpZCBjb2RlcG9pbnQgY29tYmluYXRpb25zLg0KDQpUaGFua3MsIC0tRGF2 aWQgKGFzIGRyYWZ0IHNoZXBoZXJkKQ0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmlldGZA Ym9iYnJpc2NvZS5uZXRdDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAxNiA0OjM5IFBN DQpUbzogZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0b29scy5p ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFj a0B0b29scy5pZXRmLm9yZz47IEJsYWNrLCBEYXZpZA0KQ2M6IHRzdndnIElFVEYgbGlzdA0KU3Vi amVjdDogVHVubmVsIENvbmdlc3Rpb24gRmVlZGJhY2s6IChub24tKXVwZGF0ZSB0byBSRkM2MDQw DQoNClR1bm5lbCBjb25nZXN0aW9uIGZlZWRiYWNrIGF1dGhvcnMsIERhdmlkIGFzIHNoZXBoZXJk LA0KDQpGWUkuIE5vIGFjdGlvbiBuZWVkZWQuDQoNClRoaXMgZW1haWwgZG9jdW1lbnRzIGFuIGFy Z3VtZW50IHdpdGggbXlzZWxmLiBBZnRlciBhIGZldyBzZWNvbmRzLCBJIGFncmVlZCB3aXRoIG15 c2VsZiB0aGF0IG9uZSBvZiBtZSB3YXMgd3JvbmcuIEkgdGhvdWdodCBJIGhhZCBiZXR0ZXIgcmFp c2UgdGhpcyBvbiB0aGUgbGlzdCwgdG8gY2hlY2sgdGhhdCBvdGhlcnMgYWdyZWUgd2l0aCBib3Ro IG9mIG1lLiBJZiB5b3Ugd2lzaCB0byBhcmd1ZSB3aXRoIGp1c3Qgb25lIG9mIG1lLCBwbGVhc2Ug YmVhciBpbiBtaW5kIHRoYXQgd2UgYm90aCBoYXZlIHRoZSBzYW1lIGVtYWlsIGFkZHJlc3MgKGFu ZCBhbnl3YXksIHdlIGJvdGggYWdyZWUgc28gYW4gYXJndW1lbnQgd2l0aCBvbmUgaXMgYW4gYXJn dW1lbnQgd2l0aCBhbGwpLg0KX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpGaWd1cmUgNCBv ZiBSRkM2MDQwIHNwZWNpZmllcyB3aGljaCBFQ04gY29kZXBvaW50IGEgZGVjYXAgbXVzdCBmb3J3 YXJkLCBmb3IgZWFjaCBjb21iaW5hdGlvbiBvZiBhcnJpdmluZyBpbm5lciAocm93KSBhbmQgb3V0 ZXIgKGNvbHVtbikuDQoNCiAgICAgICAgICAgICstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICAgICAgICAgICB8QXJyaXZpbmcg fCAgICAgICAgICAgIEFycml2aW5nIE91dGVyIEhlYWRlciAgICAgICAgICAgICAgIHwNCg0KICAg ICAgICAgICAgfCAgIElubmVyICstLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAgIHwgIEhlYWRlciB8IE5vdC1FQ1QgfCBFQ1QoMCkg ICAgIHwgRUNUKDEpICAgICB8ICAgICBDRSAgICAgfA0KDQogICAgICAgICAgICArLS0tLS0tLS0t Ky0tLS0tLS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCg0KICAg ICAgICAgICAgfCBOb3QtRUNUIHwgTm90LUVDVCB8Tm90LUVDVCghISEpfE5vdC1FQ1QoISEhKXwg PGRyb3A+KCEhISl8DQoNCiAgICAgICAgICAgIHwgIEVDVCgwKSB8ICBFQ1QoMCkgfCBFQ1QoMCkg ICAgIHwgRUNUKDEpICAgICB8ICAgICBDRSAgICAgfA0KDQogICAgICAgICAgICB8ICBFQ1QoMSkg fCAgRUNUKDEpIHwgRUNUKDEpICghKSB8IEVDVCgxKSAgICAgfCAgICAgQ0UgICAgIHwNCg0KICAg ICAgICAgICAgfCAgICBDRSAgIHwgICAgICBDRSB8ICAgICBDRSAgICAgfCAgICAgQ0UoISEhKXwg ICAgIENFICAgICB8DQoNCiAgICAgICAgICAgICstLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKw0KUkZDNjA0MCBnb2VzIG9uIHRvIHNheToN Cg0KICAgICAgICAgICAgICAgICAgICAgIFsuLi5dIFRoZXNlIGN1cnJlbnRseSB1bnVzZWQgKENV KSBjb21iaW5hdGlvbnMgYXJlDQoNCiAgICAgIGluZGljYXRlZCBpbiBGaWd1cmUgNCBieSAnKCEh ISknIG9yICcoISknLCB3aGVyZSAnKCEhISknIG1lYW5zIHRoZQ0KDQogICAgICBjb21iaW5hdGlv biBpcyBDVSBhbmQgYWx3YXlzIHBvdGVudGlhbGx5IGRhbmdlcm91cywgd2hpbGUgJyghKScNCg0K ICAgICAgbWVhbnMgaXQgaXMgQ1UgYW5kIHBvc3NpYmx5IGRhbmdlcm91cy4gIEluIHRoZXNlIGNh c2VzLA0KDQogICAgICBwYXJ0aWN1bGFybHkgdGhlIG1vcmUgZGFuZ2Vyb3VzIG9uZXMsIHRoZSBk ZWNhcHN1bGF0b3IgU0hPVUxEIGxvZw0KDQogICAgICB0aGUgZXZlbnQgYW5kIE1BWSBhbHNvIHJh aXNlIGFuIGFsYXJtLg0KDQoNClRDRiB1c2VzIHRoZSBmb2xsb3dpbmcgY29tYmluYXRpb25zIG9m IGlubmVyIDogb3V0ZXINCiAgICBOb3QtRUNUIDogRUNUKDApDQogICAgTm90LUVDVCA6IENFDQoN CkZvciBhIG1vbWVudCwgSSB0aG91Z2h0IHdlIHdvdWxkIGhhdmUgdG8gdXBkYXRlIFJGQzYwNDAg dG8gc2F5IHRoYXQgVENGIG1ha2VzIHRoZXNlIGNvbWJpbmF0aW9ucyBubyBsb25nZXIgQ1UsIHNv IHRoZXkgYXJlIG5vdyB2YWxpZCwgbm90IGRhbmdlcm91cywgYW5kIHRoZXkgbm8gbG9uZ2VyIG5l ZWQgdG8gYmUgbG9nZ2VkLiBUaGlzIHdvdWxkIGhhdmUgbWVhbnQgdGhhdCBUdW5uZWwgQ29uZ2Vz dGlvbiBGZWVkYmFjayAoVENGKSAoaW5mb3JtYXRpb25hbCkgd291bGQgaGF2ZSB0byB1cGRhdGUg UkZDNjA0MCAocHJvcG9zZWQgc3RhbmRhcmQpLg0KDQpIZXJlJ3Mgd2h5IEkgd2FzIHdyb25nLiBU aGVzZSB0d28gY29tYmluYXRpb25zIGFyZSBjZXJ0YWlubHkgdmFsaWQgYXQgYSBUQ0YgZGVjYXAu IEJ1dCB0aGVyZSBpcyBzdGlsbCBubyB3YXkgdGhhdCwgaW4gYSB2YWxpZCBuZXR3b3JrLCB0aGV5 IHdvdWxkIGFycml2ZSBhdCBhbnkgUkZDNjA0MCAobm9uLVRDRikgZGVjYXAuDQoNCk9uZSBtaWdo dCB0aGluayB0aGF0IHRoaXMgY29tYmluYXRpb24gY291bGQgYXJyaXZlIGF0IGEgNjA0MC1kZWNh cCBpZiB0aGVyZSB3YXMgYSB0dW5uZWwgaW5zaWRlIGEgdHVubmVsLCBhcyBmb2xsb3dzDQoNCiAg VENGLWVuY2FwICAgICAgICAgICAgICAgICAtLS0+IDYwNDAtZGVjYXAgLS0tPiBUQ0YtZGVjYXAN Cg0KSG93ZXZlciwgdGhhdCdzIG5vdCBhIHZhbGlkIGNvbmZpZ3VyYXRpb24uIFRoZSBmb2xsb3dp bmcgdHVubmVsLWluLXR1bm5lbCB3b3VsZCBiZSB2YWxpZDoNCg0KICBUQ0YtZW5jYXAgLS0tPiA2 MDQwLWVuY2FwIC0tLT4gNjA0MC1kZWNhcCAtLS0+IFRDRi1kZWNhcA0KDQouLi50aGVuLCB0aGUg YWJvdmUgdHdvICJDVSIgY29tYmluYXRpb25zIHdvdWxkIGJlIGJ1cmllZCB3aXRoaW4gYSBkb3Vi bGUgaW5uZXIsIHNvIG9ubHkgdGhlIFRDRiBkZWNhcCB3b3VsZCBzZWUgdGhlbSwgbm90IHRoZSA2 MDQwLWRlY2FwLg0KDQpTbywgVENGIGRvZXMgbm90IG5lZWQgdG8gdXBkYXRlIFJGQzYwNDAuIEJl Y2F1c2UsIGluIGEgdmFsaWQgbmV0d29yaywgVENGIHdpbGwgYmUgaGlkZGVuIGZyb20gYW55IDYw NDAtZGVjYXAuIElmIHRoZSBuZXR3b3JrIGlzIG5vdCB2YWxpZCwgdGhlc2UgY29tYmluYXRpb24g Y291bGQgYmVjb21lIHZpc2libGUgdG8gYSA2MDQwLWRlY2FwLCB3aGljaCB3b3VsZCB0aGVuIChj b3JyZWN0bHkpIGxvZyB3YXJuaW5ncyB0aGF0IGl0IHdhcyBzZWVpbmcgaW52YWxpZCBjb2RlcG9p bnQgY29tYmluYXRpb25zLg0KDQpJIGp1c3QgdGhvdWdodCB5b3UnZCBsaWtlIHRvIGtub3cuLi4g bm8gYWN0aW9uIHJlcXVpcmVkLg0KDQoNCg0KQm9iDQoNCi0tDQoNCi0tDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K Qm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNj b2UubmV0Lw0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KDQoNCg0KDQoNCi0tDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDov L2JvYmJyaXNjb2UubmV0Lw0KDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0KDQoN Ci0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0K --_000_C5C3BB522B1DDF478AA09545169155B48B3B4329nkgeml514mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IFwsIHNlcmlmIFwsc2VyaWYi Ow0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQp0dA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhU TUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQ2hhcg0K CXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6 5a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCnAuSFRNTFByZWZvcm1hdHRlZCwgbGkuSFRNTFByZWZv cm1hdHRlZCwgZGl2LkhUTUxQcmVmb3JtYXR0ZWQNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNr O30NCnAuQmFsbG9vblRleHQsIGxpLkJhbGxvb25UZXh0LCBkaXYuQmFsbG9vblRleHQNCgl7bXNv LXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDsN Cglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0 aW9uOm5vbmUgbm9uZTt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojOTkzMzY2Ow0KCWZvbnQt d2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9u ZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMyDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoYW5rcyBEYXZpZCBhbmQgQm9iLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSB0aGluayB3ZSBoYXZlIHJlYWNoIGEgY29uc2Vuc3VzIHRoYXQgYm90aCBm YWtlZCBFQ04gJiM0MzsgZWdyZXNz4oCTb25seSBhcHByb2FjaCBhbmQgaW5ncmVzcy1lZ3Jlc3Mg Y29tcGFyaXNvbiBhcHByb2FjaCBzaG91bGQgYmUgdXNlLCB0aGUgZmlyc3QgYXBwcm9hY2gNCiBp cyBmb3IgJm5ic3A7RUNOIG1lYXN1cmVtZW50IGFuZCB0aGUgc2Vjb25kIGFwcHJvYWNoIGlzIGZv ciBwYWNrZXQgbG9zcyBjb3VudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ LVhpbnBlbmcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgW21haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0K PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBBcHJpbCAwOCwgMjAxNyA1OjE2IFBNPGJyPg0K PGI+VG86PC9iPiBCbGFjaywgRGF2aWQ7IFdlaXhpbnBlbmcgKEphY2tpZSk7IGRyYWZ0LWlldGYt dHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5D Yzo8L2I+IHRzdndnIElFVEYgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVHVubmVsIENv bmdlc3Rpb24gRmVlZGJhY2s6IChub24tKXVwZGF0ZSB0byBSRkM2MDQwPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5EYXZpZCw8 YnI+DQo8YnI+DQpUaHggZm9yIGFsbCB5b3VyIHBvaW50cyAtIGFsbCB1bmRlcnN0b29kIGFuZCBJ IGFncmVlZCB3aXRoIHRoZW0gYWxsLjxicj4NCjxicj4NCkkgdGhpbmsgbm93IHRoYXQgV2VpeGlu cGVuZywgeW91IGFuZCBJIGFsbCBhZ3JlZSB0aGF0IHRoZSBkcmFmdCBzaG91bGQgc3BlY2lmeSBp bmdyZXNzLWVncmVzcyBjb21wYXJpc29uIGZvciBkcm9wIGFuZCB0aGUgZWdyZXNzLW9ubHkgYXBw cm9hY2ggZm9yIEVDTi4gU28gdGhlbiB0aGUgZmFrZWQgRUNOIGFwcHJvYWNoIGNhbiBzdGF5LCBi ZWNhdXNlIGl0IHNoaWZ0cyBzb21lL21vc3QgZHJvcHMgdG8gdGhlIG1vcmUgcm9idXN0IGVncmVz cy1vbmx5DQogbWVhc3VyZW1lbnQgbG9jYXRpb24uIEJ1dCBJIHN1Z2dlc3QgdGhlIGZha2VkIEVD TiB0ZXh0IGlzIG1vdmVkIHVwIGEgcGFyYWdyYXBoLCBiZWNhdXNlIHRoZSBwYXJhZ3JhcGggYmVm b3JlIGl0IGRvZXNuJ3QgbWFrZSBzZW5zZSB1bmxlc3MgdGhlIHJlYWRlcnMgYWxyZWFkeSBrbm93 cyBhYm91dCBmYWtlZCBFQ04uPGJyPg0KPGJyPg0KSSB3aWxsIHN0aWxsIHNlbmQgYSBmdWxsIHJl dmlldywgcG9zc2libHkgdGhpcyB3ZWVrZW5kLCBidXQgZWFybHkgbmV4dCB3ZWVrIGlzIGxvb2tp bmcgbW9yZSBsaWtlbHkgbm93Ljxicj4NCjxicj4NCjxicj4NCkJvYjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24g MDgvMDQvMTcgMDI6MjAsIEJsYWNrLCBEYXZpZCB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3Nl Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PknigJltIGFtb25nIHRob3NlIHJlc3BvbnNpYmxlIGZvciB0aGUgaW5ncmVzcy1lZ3Jlc3MgbWVh c3VyZW1lbnQgYWRkaXRpb24sIHNvIHdlaWdoaW5nIGluIGFzIGRyYWZ0IHNoZXBoZXJkOjwvc3Bh bj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBI b3dldmVyLCBJIGFtIHNheWluZyBpdCBpcyBsZXNzIHJvYnVzdCB0byBoYXZlIHRvIG1lYXN1cmUg YXQgYm90aCBpbmdyZXNzIGFuZCBlZ3Jlc3MsIGJlY2F1c2UgaXQgaW52b2x2ZXMgc2VuZGluZyBz eW5jaCAvIG1lYXN1cmVtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgbWVzc2FnZXMgZnJvbSBpbmdyZXNzIHRvIGVn cmVzcywgd2hpY2ggY2FuIGJlIGxvc3QvZGVsYXllZC4gJm5ic3A7U28sIEkgd291bGQgcmVjb21t ZW5kIHRoZSBtb3JlIHJvYnVzdCBlZ3Jlc3Mtb25seSBtZXRob2QgZm9yIEVDTiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyBhbmQgdGhlIGluZ3Jlc3MtZWdyZXNzIG1ldGhvZCBvbmx5IGZvciB0b3RhbCBkcm9wLjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhdCBzZWVtcyBmaW5lLCBob3dldmVyIHRoZSB0b3RhbCBkcm9wIGluZm8gZG9lcyBuZWVkIHRv IGJlIHJlcG9ydGVkIGluIGFkZGl0aW9uIHRvIEVDTiBpbmZvLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxicj4NCiZndDsgVGhlIG9ubHkgZXh0cmEgdGhpbmcgeW91IGxlYXJuIGJ5 IHRoZSBjdXJyZW50bHkgcHJvcG9zZWQgYXBwcm9hY2ggaXMgaG93IG1hbnkgb2YgZWFjaCBFQ04g Y29kZXBvaW50IHdlcmUgZHJvcHBlZC4gSWYgeW91IHRoaW5rIHRoYXQncyBpbXBvcnRhbnQsIGFy Z3VlIGZvciBpdC4gSSBkb24ndCBzZWUgYW55IG5lZWQgZm9yIGl0IHRoby48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIGFncmVl Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KJmd0OyBJZiB5b3UgaW5zaXN0 IG9uIGtlZXBpbmcgdGhlIGluZ3Jlc3MtZWdyZXNzIGFwcHJvYWNoLCB3aHkgZG8geW91IG5lZWQg dGhlIGZha2VkIEVDTiB0ZXh0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIG9uZSBpcyB0cnlpbmcgdG8gbWVhc3VyZSBjb25n ZXN0aW9uIGluIHRoZSB0dW5uZWwsIGRyb3BzIGhhdmUgdG8gYmUgY29uc2lkZXJlZCDigJMgZXZl biBpZiBhbGwgbm9kZXMgaW4gdGhlIHR1bm5lbCBzdXBwb3J0IEVDTiwgYW4gb3ZlcmxvYWRlZA0K IEVDTiBub2RlIHdpbGwgZHJvcCBwYWNrZXRzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgcmVhc29uIGZvciBm YWtlZC1FQ04gaXMgYnVyaWVkIGluIEJvYuKAmXMg4oCcbW9yZSByb2J1c3TigJ0gY29tbWVudCBh Ym91dCBlZ3Jlc3Mtb25seSBFQ04gbWVhc3VyZW1lbnQgYWJvdmUg4oCTIHVzZSBvZiBFQ04gc2hv dWxkIHJlc3VsdCBpbiBiZXR0ZXINCiBtZWFzdXJlbWVudHMgYnkgY29tcGFyaXNvbiB0byBub24t dXNlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgLS1EYXZp ZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndp bmRvd3RleHQiPiBCb2IgQnJpc2NvZSBbPGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5u ZXQiPm1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBG cmlkYXksIEFwcmlsIDcsIDIwMTcgMTA6NDggQU08YnI+DQo8Yj5Ubzo8L2I+IFdlaXhpbnBlbmcg KEphY2tpZSkgPGEgaHJlZj0ibWFpbHRvOndlaXhpbnBlbmdAaHVhd2VpLmNvbSI+Jmx0O3dlaXhp bnBlbmdAaHVhd2VpLmNvbSZndDs8L2E+OyBCbGFjaywgRGF2aWQNCjxhIGhyZWY9Im1haWx0bzpk YXZpZC5ibGFja0BlbWMuY29tIj4mbHQ7ZGF2aWQuYmxhY2tAZW1jLmNvbSZndDs8L2E+OyA8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0 b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRi YWNrQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gdHN2d2cgSUVURiBsaXN0IDxh IGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyI+Jmx0O3RzdndnQGlldGYub3JnJmd0OzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFR1bm5lbCBDb25nZXN0aW9uIEZlZWRiYWNrOiAobm9u LSl1cGRhdGUgdG8gUkZDNjA0MDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZWl4 aW5wZW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gMDUvMDQvMTcgMDM6NDUsIFdlaXhpbnBlbmcgKEphY2tp ZSkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SGkgQm9iLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMsIGFuZCBw bGVhc2Ugc2VlIGlubGluZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVhpbnBl bmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi PiBCb2IgQnJpc2NvZSBbPGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiPm1haWx0 bzppZXRmQGJvYmJyaXNjb2UubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFw cmlsIDAzLCAyMDE3IDU6MzQgQU08YnI+DQo8Yj5Ubzo8L2I+IFdlaXhpbnBlbmcgKEphY2tpZSk7 IEJsYWNrLCBEYXZpZDsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNv bmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi10c3Z3Zy10dW5u ZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+ IHRzdndnIElFVEYgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVHVubmVsIENvbmdlc3Rp b24gRmVlZGJhY2s6IChub24tKXVwZGF0ZSB0byBSRkM2MDQwPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPldlaXhpbnBlbmcsIGNvLWF1dGhvcnMsJm5ic3A7IGFuZCBEYXZpZCw8YnI+ DQo8YnI+DQpJIGhhZCBwcm9taXNlZCBhIHJldmlldyBvZiB0aGUgbGF0ZXN0IFRDRiBkcmFmdCwg YnV0IGZhaWxlZCB0byBwcm92aWRlIGl0IHNvIGZhci48YnI+DQpJIGhhbGYgcmVhZCBpdCB0aHJv dWdoIG9uIEZyaWRheSwgYW5kIEkgd2lsbCBmaW5pc2ggYW5kIHdyaXRlIHVwIG15IHJldmlldyB0 aGlzIHdlZWsuPGJyPg0KPGJyPg0KSGVyZScgYSBxdWljayBzdW1tYXJ5IG9mIHRoZSBtYWluIHBv aW50cyBzbyBmYXI6IDxicj4NCjxicj4NCjxiPlMuMS4gSW50cm86IE1vdGl2YXRpb248YnI+DQo8 L2I+VGhlIG1vdGl2YXRpb24gc2hvdWxkIGFsc28gaW5jbHVkZSBhIGhlYXZ5IGxvYWQgZnJvbSBh IG11Y2ggbGFyZ2VyIHRoYW4gZXhwZWN0ZWQgbnVtYmVyIG9mIHJlc3BvbnNpdmUgZmxvd3M8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+W1dlaV0gT2ssIEkgd2lsbCBhZGQgaXQuPC9zcGFuPjwvaT48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxiPlMuMSBJbnRybzogU2NvcGU8YnI+DQo8 L2I+SSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIHNheSB0aGF0PGJyPg0KKiBpdCBnaXZlcyBubyBh ZHZpY2Ugb24gaG93IHRvIHNlbGVjdCB3aGljaCB0dW5uZWwgZW5kcG9pbnRzIHNob3VsZCBiZSB1 c2VkIGluIG9yZGVyIHRvIG1hbmFnZSB0cmFmZmljIG92ZXIgYSBuZXR3b3JrIGNyaXNzLWNyb3Nz ZWQgYnkgbXVsdGlwbGUgdHVubmVscy4NCjxicj4NCiogaWYgYSBjb25nZXN0ZWQgbm9kZSBpcyBw YXJ0IG9mIG11bHRpcGxlIHR1bm5lbHMsIGFuZCBpdCBjYXVzZXMgY29uZ2VzdGlvbiBmZWVkYmFj ayB0byBtdWx0aXBsZSB0cmFmZmljIG1hbmFnZW1lbnQgZnVuY3Rpb25zIGF0IHRoZSBpbmdyZXNz ZXMgb2YgYWxsIHRoZSB0dW5uZWxzLCB0aGUgZHJhZnQgZ2l2ZXMgbm8gYWR2aWNlIG9uIGhvdyBh bGwgdGhlIHRyYWZmaWMgbWFuYWdlbWVudCBmdW5jdGlvbnMgc2hvdWxkIHJlc3BvbmQuPGJyPg0K KiBldGMuIChpbiBteSBmdWxsIHJldmlldywgSSB3aWxsIHByb3ZpZGUgYSBmdWxsIGxpc3Qgb2Yg c3ViamVjdHMgdGhhdCBhcmUgb3V0IG9mIHNjb3BlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxpPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1dl aV0gT2suPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxiPlMu My4gRmVlZGJhY2sgTW9kZWxzOiA8YnI+DQo8L2I+VGhlIGFyY2hpdGVjdHVyZSBkaWFncmFtcyBh bmQgdGV4dCBuZWVkIHRvIGluY2x1ZGUgY29tcG9uZW50cyB0aGF0IGFwcGx5IGEgY29uc2lzdGVu dCBtZWFzdXJlbWVudCBwb2xpY3kgKHRlbXBsYXRlIHJlY29yZHMgaW4gSVBGSVgtc3BlYWspIGF0 IGJvdGggaW5ncmVzcyBhbmQgZWdyZXNzLiBUaGlzIGlzIGEga2V5IHBhcnQgb2YgaW50ZXJvcGVy YWJpbGl0eSwgd2hpY2ggaXMgd2hhdCB0aGUgSUVURiBzaG91bGQgYmUgYWxsIGFib3V0LiBUZW1w bGF0ZQ0KIHJlY29yZHMgYXJlIGRlc2NyaWJlZCBsYXRlciB3aGVuIHRoZSBtZWNoYW5pc20gaXMg c3BlY2lmaWVkLCBidXQgdGhleSBhcmUgbm90IHNob3duIGluIHRoZSBsYXlvdXQgb2YgdGhlIGNv bXBvbmVudHMgaW4gUy4zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bV2VpXSBJIHdpbGwgcHJvdmlk ZSBhIGRlc2NyaXB0aW9uIG9mIFRlbXBsYXRlIHJlY29yZCBpbiB0aGlzIHNlY3Rpb24uIEJ1dCBJ IGFtIHdvbmRlcmluZyB3aGV0aGVyIGEgZGV0YWlsZWQNCiBkZXNjcmlwdGlvbiBvZiBUZW1wbGF0 ZSBSZWNvcmQgYXMgc2VjdGlvbiA2LjEgaXMgbmVlZGVkIGhlcmUgb3Igbm90Pzwvc3Bhbj48L2k+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHN1 Z2dlc3QgdGhhdCwgYXQgdGhpcyBzdGFnZSBpbiB0aGUgZG9jLCBpdCB3b3VsZCBiZSBiZXN0IG5v dCB0byBiZSBzcGVjaWZpYyB0byBvbmUgdGVjaG5vbG9neSAoSVBGSVgpIGJ1dCBpbnN0ZWFkIHRv IHRhbGsgbW9yZSBnZW5lcmFsbHkgYWJvdXQgc2V0dGluZyBhbmQgc3RvcmluZyBtZWFzdXJlbWVu dCBwb2xpY3kgKGF0IHRoZSBkZWNpc2lvbiBwb2ludCBhbmQgdGhlIGVncmVzcw0KIG1ldGVyKS48 YnI+DQo8YnI+DQpCVFcsIGRpZCB5b3UgaW52ZW50IHRoZSB0ZXJtaW5vbG9neSBkZWNpc2lvbiBw b2ludCAoRFApIGFuZCBhY3Rpb24gcG9pbnQgKEFQKT8gQmVjYXVzZSB0aGVyZSBpcyBhbHJlYWR5 IElFVEYgdGVybWlub2xvZ3kgZm9yIHRoZXNlOjxicj4NCiogUG9saWN5IERlY2lzaW9uIFBvaW50 IChQRFApPGJyPg0KKiBQb2xpY3kgRW5mb3JjZW1lbnQgUG9pbnQgKFBFUCkuPGJyPg0KPGJyPg0K U2VlIENPUFMgKENvbW1vbiBPcGVuIFBvbGljeSBTZXJ2aWNlKSBQcm90b2NvbCBbUkZDMjc0OF0g b3IgdGVybWlub2xvZ3kgZm9yIHBvbGljeS1iYXNlZCBtYW5hZ2VtZW50IFtSRkMzMTk4XTxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxiPlMuNC4gQ29uZ2VzdGlvbiBMZXZlbCBN ZWFzdXJlbWVudDo8YnI+DQo8L2I+TWVhc3VyZW1lbnQgb2YgRUNOIGhhcyBiZWVuIGNoYW5nZWQg d2l0aG91dCB0aGlua2luZyBjbGVhcmx5IHdoZXRoZXIgaXQgbmVlZGVkIHRvIGNoYW5nZS48YnI+ DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgYSkgRWFybGllciBkcmFmdHMgZXhwbG9pdGVkIHRo ZSBmYWN0IHRoYXQgdGhlIGlubmVyIGhvbGRzIGEgJnF1b3Q7ZnJvemVuJnF1b3Q7IHJlY29yZCBv ZiB0aGUgRUNOIGZpZWxkIGF0IHRoZSBpbmdyZXNzLiBTbyBFQ04gbWVhc3VyZW1lbnRzIGNvdWxk IGJlIG1hZGUgc29sZWx5IGF0IHRoZSBlZ3Jlc3MgKGNvbXBhcmluZyB0aGUgb3V0ZXIgd2l0aCB0 aGUgaW5uZXIpLiBJbiBkcmFmdC0wNCwgRUNOIGNvZGVwb2ludHMgYXJlIG1lYXN1cmVkIGF0IHRo ZSBpbmdyZXNzDQogYW5kIGF0IHRoZSBlZ3Jlc3MsIHdpdGggdGhlIGluZ3Jlc3Mgc2VuZGluZyBy ZWd1bGFyIG1lYXN1cmVtZW50IHJlcG9ydHMgdG8gdGhlIGVncmVzcyBmb3IgY29tcGFyaXNvbi4g SG93ZXZlciwgaXQgaXMgYWx3YXlzIHNhZmVyIHRvIG1lYXN1cmUgRUNOIHNvbGVseSBhdCB0aGUg ZWdyZXNzLCBldmVuIHRob3VnaCBhIGRpZmZlcmVudCBtZWNoYW5pc20gaGFzIHRvIG1lYXN1cmUg ZHJvcHMgd2l0aGluIHRoZSB0dW5uZWwgKGR1ZSB0byBub24tRUNODQogbm9kZXMsIG9yIG5vZGVz IHRoYXQgaGF2ZSBzd2l0Y2hlZCBvZmYgRUNOIGR1ZSB0byBvdmVybG9hZCwgb3IgZHVlIHRvIGNh dXNlcyBvZiBsb3NzIG90aGVyIHRoYW4gY29uZ2VzdGlvbiwgZS5nLiB0cmFuc21pc3Npb24gZXJy b3JzKS4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIEl0IGlzIGFsd2F5cyBzYWZl ciB0byBzb2xlbHkgbWVhc3VyZSBFQ04gYXQgdGhlIGVncmVzcywgYmVjYXVzZSBpdCBpcyBub3Qg dnVsbmVyYWJsZSB0byBpbmdyZXNzLWVncmVzcyBtZWFzdXJlbWVudCBwYWNrZXRzIGJlaW5nIGRy b3BwZWQuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gU29sZWx5IG1lYXN1cmluZyBF Q04gYXQgZWdyZXNzIGlzIG5vIGxlc3MgcHJlY2lzZSwgYmVjYXVzZSBvbmx5IHRoZSBwcm9wb3J0 aW9uIG9mIHRoZSBkaWZmZXJlbnQgRUNOIGZpZWxkcyBpcyBuZWVkZWQsIGFuZCB0aGF0IHN0YXlz IGFwcHJveGltYXRlbHkgdGhlIHNhbWUgZXZlbiBpZiB0aGVyZSBpcyBkcm9wLCBhc3N1bWluZyBk cm9wIGlzIG5vdCBiaWFzZWQgdG93YXJkcyBjZXJ0YWluIEVDTiBjb2RlcG9pbnRzIChubyBrbm93 biBtZWNoYW5pc20NCiBkb2VzIHRoYXQpLiA8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg YikgSW4gZHJhZnQtMDQgdGhlIGZha2VkIEVDVCBhcHByb2FjaCBoYXMgYmVlbiBsZWZ0IHVuY2hh bmdlZCBhdCB0aGUgaW5ncmVzcywgYnV0IGl0IGlzIG5vIGxvbmdlciB1c2VkIGF0IHRoZSBlZ3Jl c3MgZm9yIGRldGVjdGluZyBkZWZlcnJlZCBkcm9wcyAoYnkgbG9va2luZyBmb3IgYSBOb3QtRUNO IGlubmVyIGFuZCBhIENFIG91dGVyKS4gQWdhaW4sIHRoZXJlIGlzIG5vdGhpbmcgd3Jvbmcgd2l0 aCBtZWFzdXJpbmcgRUNOIGFuZCBkZXRlY3RpbmcNCiBkZWZlcnJlZCBkcm9wcyBzb2xlbHkgYXQg dGhlIGVncmVzcywgZXZlbiBpZiB0aGVyZSBhcmUgZHJvcHMgd2l0aGluIHRoZSB0dW5uZWwuIFRv IG1lYXN1cmUgZHJvcHMgd2l0aGluIHRoZSB0dW5uZWwsIGl0IGlzIG5lY2Vzc2FyeSB0byBjb21w YXJlIGluZ3Jlc3MgYW5kIGVncmVzcyBieXRlcywgYnV0IHRoYXQgZG9lcyBub3QgbWFrZSBpdCB3 cm9uZyB0byBzdGlsbCBtZWFzdXJlIGFuZCBjb21wYXJlIEVDTiBzb2xlbHkgYXQgdGhlIGVncmVz cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1dlaV0gSSBhZ3JlZSB0aGF0IHNvbGVseSBtZWFzdXJp bmcgRUNOIGF0IGVncmVzcyBpcyBlbm91Z2ggdG8gZ2V0IHRoZSBwcm9wb3J0aW9uIG9mIGRpZmZl cmVudCBFQ04gZmllbGRzLCBidXQNCiB0aGUgcmVhc29uIHdoeSBFQ04gY29kZXBvaW50cyBhcmUg bWVhc3VyZWQgYm90aCBhdCBpbmdyZXNzIGFuZCBlZ3Jlc3MgaXMgdG8gbWVhc3VyZSB0aGUgcGFj a2V0cyBkcm9wcGVkIHdpdGhpbiB0aGUgdHVubmVsIGJ5IGNvbXBhcmluZyBjb3VudHMgYXQgaW5n cmVzcyBhbmQgZWdyZXNzLg0KPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gbm90IHNheWluZyB5b3Ugc2hvdWxkIG5vdCBh bHNvIG1lYXN1cmUgZHJvcCBieSBtZWFzdXJpbmcgdG90YWwgYnl0ZXMgYXQgaW5ncmVzcyBhbmQg ZWdyZXNzLjxicj4NCjxicj4NCkhvd2V2ZXIsIEkgYW0gc2F5aW5nIGl0IGlzIGxlc3Mgcm9idXN0 IHRvIGhhdmUgdG8gbWVhc3VyZSBhdCBib3RoIGluZ3Jlc3MgYW5kIGVncmVzcywgYmVjYXVzZSBp dCBpbnZvbHZlcyBzZW5kaW5nIHN5bmNoIC8gbWVhc3VyZW1lbnQgbWVzc2FnZXMgZnJvbSBpbmdy ZXNzIHRvIGVncmVzcywgd2hpY2ggY2FuIGJlIGxvc3QvZGVsYXllZC4NCjxicj4NClNvLCBJIHdv dWxkIHJlY29tbWVuZCB0aGUgbW9yZSByb2J1c3QgZWdyZXNzLW9ubHkgbWV0aG9kIGZvciBFQ04s IGFuZCB0aGUgaW5ncmVzcy1lZ3Jlc3MgbWV0aG9kIG9ubHkgZm9yIHRvdGFsIGRyb3AuPGJyPg0K PGJyPg0KVGhlIG9ubHkgZXh0cmEgdGhpbmcgeW91IGxlYXJuIGJ5IHRoZSBjdXJyZW50bHkgcHJv cG9zZWQgYXBwcm9hY2ggaXMgaG93IG1hbnkgb2YgZWFjaCBFQ04gY29kZXBvaW50IHdlcmUgZHJv cHBlZC4gSWYgeW91IHRoaW5rIHRoYXQncyBpbXBvcnRhbnQsIGFyZ3VlIGZvciBpdC4gSSBkb24n dCBzZWUgYW55IG5lZWQgZm9yIGl0IHRoby48YnI+DQo8YnI+DQpJZiB5b3UgaW5zaXN0IG9uIGtl ZXBpbmcgdGhlIGluZ3Jlc3MtZWdyZXNzIGFwcHJvYWNoLCB3aHkgZG8geW91IG5lZWQgdGhlIGZh a2VkIEVDTiB0ZXh0Pzxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxi PlMuNC4gQ29uZ2VzdGlvbiBMZXZlbCBNZWFzdXJlbWVudDogVW5pdHM8YnI+DQo8L2I+VGhyb3Vn aG91dCBtZWFzdXJlbWVudCBpbnZvbHZlcyBjb3VudGluZyBwYWNrZXRzLiBIb3dldmVyLCBpdCBz aG91bGQgY291bnQgdGhlIGJ5dGVzIGluIHBhY2tldHMgd2l0aCBlYWNoIHR5cGUgb2YgbWFya2lu Zywgbm90IGp1c3QgdGhlIG51bWJlciBvZiBwYWNrZXRzLiBTZWUNCjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTQxI3NlY3Rpb24tMi4zIj5SRkM3MTQxIHNlY3Rpb24g Mi4zPC9hPi4gQWx0aG91Z2ggdGhlIHJlY29tbWVuZGF0aW9uIGluIHRoYXQgUkZDIGlzIGFib3V0 IHdoYXQgYSAvdHJhbnNwb3J0LyBzaG91bGQgbWVhc3VyZSB3aGVuIHJlc3BvbmRpbmcgdG8gY29u Z2VzdGlvbiwgbG9naWNhbGx5IGl0IHNob3VsZCBhcHBseSBpbiB0aGlzIGNhc2Ugd2hlbiBhIHRy YWZmaWMgbWFuYWdlbWVudA0KIGZ1bmN0aW9uIGlzIHJlc3BvbmRpbmcgaW4gcGxhY2Ugb2YgYSB0 cmFuc3BvcnQuIFJGQzcxNDEgYWxzbyBnaXZlcyByZWNvbW1lbmRhdGlvbnMgb24gd2hpY2ggaGVh ZGVycyB0byBjb3VudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1dlaV0gT2ssIGl04oCZcyBhIGdv b2Qgc3VnZ2VzdGlvbi48L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPGJyPg0KSSBzaGFsbCBhZGQg dG8gdGhpcyByZXZpZXcgbGF0ZXIgaW4gdGhlIHdlZWsuPGJyPg0KPGJyPg0KT25lIHF1ZXN0aW9u IGZvciBXZWl4aW5wZW5nOiBIYXZlIHlvdSBpbXBsZW1lbnRlZCB0aGlzIG1lY2hhbmlzbT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+W1dlaV0gQ3VycmVudGx5LCB3ZSBvbmx5IGltcGxlbWVudCB0aGlz IG1lY2hhbmlzbSBpbiBhIHNpbXVsYXRpb24gZW52aXJvbm1lbnQuPC9zcGFuPjwvaT48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgc3VzcGVjdGVk IGFzIG11Y2gsIGJlY2F1c2UgdGhlIGxhY2sgb2YgZGV0YWlsIGluIHNvbWUgcGxhY2VzIGltcGxp ZXMgaXQgaXMgYSBiaXQgdGhlb3JldGljYWwuPGJyPg0KSSB3b3VsZCBlbmNvdXJhZ2UgeW91IHRv IGltcGxlbWVudC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpCb2I8YnI+DQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQo8YnI+DQpCb2I8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9uIDAxLzExLzE2IDAxOjQ5LCBXZWl4aW5wZW5nIChKYWNraWUpIHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEJvYiBhbmQgRGF2 aWQsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJlY2F1c2UgdGhlIGRlYWRsaW5lIGhhcyBwYXNzZWQsIEkgd2lsbCB1 cGRhdGUgaXQgYXMgcGFydCBvZiBwb3N0LVdHTEMgdXBkYXRlLiBUaGFua3MuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tWGlucGVuZyAoSmFja2ll KTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ IEJsYWNrLCBEYXZpZCBbPGEgaHJlZj0ibWFpbHRvOkRhdmlkLkJsYWNrQGRlbGwuY29tIj5tYWls dG86RGF2aWQuQmxhY2tAZGVsbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IE5vdmVtYmVyIDAxLCAyMDE2IDEyOjE0IEFNPGJyPg0KPGI+VG86PC9iPiBCb2IgQnJpc2NvZTsg V2VpeGlucGVuZyAoSmFja2llKTsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdHN2d2ctdHVu bmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi10c3Z3 Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5D Yzo8L2I+IHRzdndnIElFVEYgbGlzdDsgQmxhY2ssIERhdmlkPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJFOiBUdW5uZWwgQ29uZ2VzdGlvbiBGZWVkYmFjazogKG5vbi0pdXBkYXRlIHRvIFJGQzYwNDA8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTkzMzY2Ij4mZ3Q7DQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPkkgYXNzdW1lIHlvdSB3aWxsIHVwZGF0ZSB0aGUgVENGIGRyYWZ0IHRv ZGF5IGJlZm9yZSB0aGUgZGVhZGxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Izk5MzM2NiI+KEFzIGRyYWZ0IHNoZXBoZXJkKSBUaGF04oCZcyBub3Qg cmVhbGx5IG5lY2Vzc2FyeSAtIHRoZSBUQ0YgZHJhZnQgaXMgaW4gV0dMQywgc28gdGhpcyBjaGFu Z2UgY2FuIGJlIGRvbmUgYXMgcGFydCBvZiBhIHBvc3QtV0dMQyB1cGRhdGUuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTMzNjYi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Izk5MzM2NiI+VGhhbmtzLCAtLURhdmlkPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk5 MzM2NiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBCb2IgQnJp c2NvZSBbPGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiPm1haWx0bzppZXRmQGJv YmJyaXNjb2UubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMzEs IDIwMTYgMTE6MjIgQU08YnI+DQo8Yj5Ubzo8L2I+IFdlaXhpbnBlbmcgKEphY2tpZSk7IEJsYWNr LCBEYXZpZDsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rp b24tZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29u Z2VzdGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IHRzdndn IElFVEYgbGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVHVubmVsIENvbmdlc3Rpb24gRmVl ZGJhY2s6IChub24tKXVwZGF0ZSB0byBSRkM2MDQwPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPlhpbnBlbmcsPGJyPg0KPGJyPg0KSSBhZ3JlZSB0aGF0IFRDRiBkb2VzIG5vdCB1cGRh dGUgUkZDNjA0MCAoYXMgSSBzYWlkKS48YnI+DQo8YnI+DQpCdXQgRGF2aWQgaXMgcmlnaHQgdGhh dCB0aGUgVENGIGRyYWZ0IGl0c2VsZiBuZWVkcyB0byBiZSB1cGRhdGVkIHRvIHNheSB0aGF0IGl0 IG1vZGlmaWVzIHRoZSBiZWhhdmlvdXIgb2YgYSBSRkM2MDQwIGVncmVzcyBzbyBhcyB0byBpc3N1 ZSBvciBsb2cgYW55IHdhcm5pbmdzIHdoZW4gaXQgcmVjZWl2ZXMgYW4gRUNUKDApIG9yIENFIG91 dGVyIHdpdGggYSBOb3QtRUNUIGlubmVyLjxicj4NCjxicj4NCkkgYXNzdW1lIHlvdSB3aWxsIHVw ZGF0ZSB0aGUgVENGIGRyYWZ0IHRvZGF5IGJlZm9yZSB0aGUgZGVhZGxpbmUuPGJyPg0KPGJyPg0K Q2hlZXJzPGJyPg0KPGJyPg0KQm9iPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAzMS8xMC8xNiAwMjozOCwgV2Vp eGlucGVuZyAoSmFja2llKSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSBEYXZpZCwgQm9iLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRo YXQgdGhlIGJlaGF2aW9yIGRlZmluZWQgaW4gUkZDNjA0MCBkb2VzbuKAmXQgdG8gYmUgdXBkYXRl ZCBkdWUgdG8gdGhlIFRDRiBkcmFmdCwgYmVjYXVzZSB3aGF04oCZcyBkZWZpbmVkIGluIFJGQyA2 MDQwIGhhcyBhIGJyb2FkZXIgdXNhZ2UNCiBhbmQgbm90IGp1c3QgZm9yIFRDRi48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSB0aGluayBEYXZpZCBoYXMgcHJvdmlkZWQgYSBnb29kIHN1Z2dlc3Rpb24gYmVsb3cuIFRo YW5rcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pi1YaW5wZW5nIChKYWNraWUpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij4gdHN2d2cgWzxhIGhyZWY9Im1haWx0bzp0c3Z3Zy1ib3VuY2VzQGll dGYub3JnIj5tYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkJsYWNrLCBEYXZpZDxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgT2N0b2JlciAy OSwgMjAxNiAxMDoyOCBBTTxicj4NCjxiPlRvOjwvYj4gQm9iIEJyaXNjb2U7IDxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrQHRvb2xzLmll dGYub3JnIj4NCmRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAdG9v bHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiB0c3Z3ZyBJRVRGIGxpc3Q8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10gVHVubmVsIENvbmdlc3Rpb24gRmVlZGJhY2s6IChub24t KXVwZGF0ZSB0byBSRkM2MDQwPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Qm9iLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB5b3XigJl2ZSBm b3VuZCBzb21ldGhpbmcuJm5ic3A7IFRoZSBUQ0YgZHJhZnQgY3VycmVudGx5IHVzZXMgUkZDIDYw NDAgYmVoYXZpb3IgYnkgcmVmZXJlbmNlOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHdoZW4gZGVjYXBzdWxhdGluZyBw YWNrZXRzIGF0IGVncmVzcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IFJGQzYwNDAgZGVmaW5lZCBkZWNhcHN1bGF0aW9uIGJlaGF2aW9yIGlzIHVzZWQs IGFuZCBhY2NvcmRpbmcgdG88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IFJGQzYwNDAsIHRoZSBwYWNrZXRzIG1hcmtlZCBhcyBDRXxOLUVDVCB3aWxsIGJl IGRyb3BwZWQgYnkgZWdyZXNzLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSB0aGluayB0aGlzIG5lZWRzIHRvIGJlIHNsaWdodGx5IHJldmlzZWQgdG8gc2F5IHRoYXQg Q0V8Ti1FQ1QgaXMgZHJvcHBlZCB3aXRob3V0IGFueSBvdGhlcjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hY3Rpb24s IGFuZCBhbGwgb3RoZXIgYmVoYXZpb3IgaXMgYXMgcGVyIFJGQyA2MDQwLCBhcyBDRXxOLUVDVCBp cyBleHBlY3RlZCBhdCBhIFRDRiBlZ3Jlc3MgYW5kPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmhlbmNlIHRoZSBsb2dn aW5nIGFuZCBhbGFybSBiZWhhdmlvciBmb3IgdGhhdCBjb21iaW5hdGlvbiBpbiBSRkMgNjA0MCBp cyBpbmFwcHJvcHJpYXRlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T25jZSB0aGF0 4oCZcyBkb25lLCBJIHRoaW5rIHlvdXIgcmVhc29uaW5nIGluIHRoZSBmb2xsb3dpbmcgc2VudGVu Y2UgYmVjb21lcyBjb3JyZWN0Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5JZiB0aGUgbmV0d29yayBpcyBub3QgdmFsaWQsIHRoZXNlIGNvbWJpbmF0aW9uIGNv dWxkIGJlY29tZSB2aXNpYmxlIHRvIGEgNjA0MC1kZWNhcCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+d2hpY2ggd291bGQgdGhl biAoY29ycmVjdGx5KSBsb2cgd2FybmluZ3MgdGhhdCBpdCB3YXMgc2VlaW5nIGludmFsaWQgY29k ZXBvaW50IGNvbWJpbmF0aW9ucy48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsIC0tRGF2aWQgKGFz IGRyYWZ0IHNoZXBoZXJkKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgWzxhIGhyZWY9Im1haWx0bzppZXRm QGJvYmJyaXNjb2UubmV0Ij5tYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldDwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIE9jdG9iZXIgMjcsIDIwMTYgNDozOSBQTTxicj4NCjxiPlRv OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdHN2d2ctdHVubmVsLWNvbmdlc3Rpb24t ZmVlZGJhY2tAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2Vz dGlvbi1mZWVkYmFja0B0b29scy5pZXRmLm9yZzwvYT47IEJsYWNrLCBEYXZpZDxicj4NCjxiPkNj OjwvYj4gdHN2d2cgSUVURiBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFR1bm5lbCBDb25nZXN0 aW9uIEZlZWRiYWNrOiAobm9uLSl1cGRhdGUgdG8gUkZDNjA0MDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VHVubmVsIGNvbmdlc3Rp b24gZmVlZGJhY2sgYXV0aG9ycywgRGF2aWQgYXMgc2hlcGhlcmQsPGJyPg0KPGJyPg0KRllJLiBO byBhY3Rpb24gbmVlZGVkLjxicj4NCjxicj4NClRoaXMgZW1haWwgZG9jdW1lbnRzIGFuIGFyZ3Vt ZW50IHdpdGggbXlzZWxmLiBBZnRlciBhIGZldyBzZWNvbmRzLCBJIGFncmVlZCB3aXRoIG15c2Vs ZiB0aGF0IG9uZSBvZiBtZSB3YXMgd3JvbmcuIEkgdGhvdWdodCBJIGhhZCBiZXR0ZXIgcmFpc2Ug dGhpcyBvbiB0aGUgbGlzdCwgdG8gY2hlY2sgdGhhdCBvdGhlcnMgYWdyZWUgd2l0aCBib3RoIG9m IG1lLiBJZiB5b3Ugd2lzaCB0byBhcmd1ZSB3aXRoIGp1c3Qgb25lIG9mIG1lLCBwbGVhc2UgYmVh cg0KIGluIG1pbmQgdGhhdCB3ZSBib3RoIGhhdmUgdGhlIHNhbWUgZW1haWwgYWRkcmVzcyAoYW5k IGFueXdheSwgd2UgYm90aCBhZ3JlZSBzbyBhbiBhcmd1bWVudCB3aXRoIG9uZSBpcyBhbiBhcmd1 bWVudCB3aXRoIGFsbCkuPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjxicj4N CkZpZ3VyZSA0IG9mIFJGQzYwNDAgc3BlY2lmaWVzIHdoaWNoIEVDTiBjb2RlcG9pbnQgYSBkZWNh cCBtdXN0IGZvcndhcmQsIGZvciBlYWNoIGNvbWJpbmF0aW9uIG9mIGFycml2aW5nIGlubmVyIChy b3cpIGFuZCBvdXRlciAoY29sdW1uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0MzstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxBcnJpdmluZyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFycml2aW5nIE91dGVyIEhl YWRlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyBJbm5lciAmIzQzOy0tLS0tLS0tLSYjNDM7LS0tLS0tLS0t LS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBIZWFkZXIgfCBOb3QtRUNUIHwgRUNUKDApJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRUNUKDEpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0MzstLS0tLS0tLS0mIzQz Oy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgTm90LUVDVCB8IE5vdC1FQ1QgfE5vdC1FQ1Qo ISEhKXxOb3QtRUNUKCEhISl8ICZsdDtkcm9wJmd0OyghISEpfDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgRUNUKDApIHwmbmJzcDsgRUNUKDApIHwgRUNUKDApJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRUNUKDEpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgRUNUKDEpIHwmbmJzcDsgRUNUKDEpIHwg RUNUKDEpICghKSB8IEVDVCgxKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IENFJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IENFJm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0UgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBD RSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENFKCEh ISl8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENFJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLSYjNDM7LS0tLS0t LS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0 Mzs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJGQzYwNDAgZ29lcyBvbiB0byBz YXk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBbLi4uXSBUaGVzZSBjdXJyZW50bHkgdW51c2VkIChDVSkgY29tYmluYXRpb25z IGFyZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGluZGljYXRlZCBpbiBGaWd1cmUgNCBieSAnKCEhISknIG9yICcoISknLCB3aGVyZSAnKCEhISkn IG1lYW5zIHRoZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwO2NvbWJpbmF0aW9uIGlzIENVIGFuZCBhbHdheXMgcG90ZW50aWFsbHkgZGFuZ2Vyb3Vz LCB3aGlsZSAnKCEpJzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG1lYW5zIGl0IGlzIENVIGFuZCBwb3NzaWJseSBkYW5nZXJvdXMuJm5ic3A7IElu IHRoZXNlIGNhc2VzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHBhcnRpY3VsYXJseSB0aGUgbW9yZSBkYW5nZXJvdXMgb25lcywgdGhlIGRlY2Fw c3VsYXRvciBTSE9VTEQgbG9nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGhlIGV2ZW50IGFuZCBNQVkgYWxzbyByYWlzZSBhbiBhbGFybS48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UQ0YgdXNlcyB0aGUgZm9sbG93aW5nIGNv bWJpbmF0aW9ucyBvZiBpbm5lciA6IG91dGVyDQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgTm90 LUVDVCA6IEVDVCgwKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBOb3QtRUNUIDogQ0U8YnI+DQo8 YnI+DQpGb3IgYSBtb21lbnQsIEkgdGhvdWdodCB3ZSB3b3VsZCBoYXZlIHRvIHVwZGF0ZSBSRkM2 MDQwIHRvIHNheSB0aGF0IFRDRiBtYWtlcyB0aGVzZSBjb21iaW5hdGlvbnMgbm8gbG9uZ2VyIENV LCBzbyB0aGV5IGFyZSBub3cgdmFsaWQsIG5vdCBkYW5nZXJvdXMsIGFuZCB0aGV5IG5vIGxvbmdl ciBuZWVkIHRvIGJlIGxvZ2dlZC4gVGhpcyB3b3VsZCBoYXZlIG1lYW50IHRoYXQgVHVubmVsIENv bmdlc3Rpb24gRmVlZGJhY2sgKFRDRikgKGluZm9ybWF0aW9uYWwpDQogd291bGQgaGF2ZSB0byB1 cGRhdGUgUkZDNjA0MCAocHJvcG9zZWQgc3RhbmRhcmQpLjxicj4NCjxicj4NCkhlcmUncyB3aHkg SSB3YXMgd3JvbmcuIFRoZXNlIHR3byBjb21iaW5hdGlvbnMgYXJlIGNlcnRhaW5seSB2YWxpZCBh dCBhIFRDRiBkZWNhcC4gQnV0IHRoZXJlIGlzIHN0aWxsIG5vIHdheSB0aGF0LCBpbiBhIHZhbGlk IG5ldHdvcmssIHRoZXkgd291bGQgYXJyaXZlIGF0IGFueSBSRkM2MDQwIChub24tVENGKSBkZWNh cC48YnI+DQo8YnI+DQpPbmUgbWlnaHQgdGhpbmsgdGhhdCB0aGlzIGNvbWJpbmF0aW9uIGNvdWxk IGFycml2ZSBhdCBhIDYwNDAtZGVjYXAgaWYgdGhlcmUgd2FzIGEgdHVubmVsIGluc2lkZSBhIHR1 bm5lbCwgYXMgZm9sbG93czxicj4NCjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsgVENGLWVuY2FwJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLSZndDsgNjA0MC1kZWNhcCAtLS0mZ3Q7IFRDRi1k ZWNhcDwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsIHNlcmlmICxzZXJpZiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpIb3dl dmVyLCB0aGF0J3Mgbm90IGEgdmFsaWQgY29uZmlndXJhdGlvbi4gVGhlIGZvbGxvd2luZyB0dW5u ZWwtaW4tdHVubmVsIHdvdWxkIGJlIHZhbGlkOjxicj4NCjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsgVENGLWVuY2FwIC0t LSZndDsgNjA0MC1lbmNhcCAtLS0mZ3Q7IDYwNDAtZGVjYXAgLS0tJmd0OyBUQ0YtZGVjYXA8L3Nw YW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiAsc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KLi4udGhlbiwgdGhl IGFib3ZlIHR3byAmcXVvdDtDVSZxdW90OyBjb21iaW5hdGlvbnMgd291bGQgYmUgYnVyaWVkIHdp dGhpbiBhIGRvdWJsZSBpbm5lciwgc28gb25seSB0aGUgVENGIGRlY2FwIHdvdWxkIHNlZSB0aGVt LCBub3QgdGhlIDYwNDAtZGVjYXAuPGJyPg0KPGJyPg0KU28sIFRDRiBkb2VzIG5vdCBuZWVkIHRv IHVwZGF0ZSBSRkM2MDQwLiBCZWNhdXNlLCBpbiBhIHZhbGlkIG5ldHdvcmssIFRDRiB3aWxsIGJl IGhpZGRlbiBmcm9tIGFueSA2MDQwLWRlY2FwLiBJZiB0aGUgbmV0d29yayBpcyBub3QgdmFsaWQs IHRoZXNlIGNvbWJpbmF0aW9uIGNvdWxkIGJlY29tZSB2aXNpYmxlIHRvIGEgNjA0MC1kZWNhcCwg d2hpY2ggd291bGQgdGhlbiAoY29ycmVjdGx5KSBsb2cgd2FybmluZ3MgdGhhdCBpdCB3YXMgc2Vl aW5nIGludmFsaWQNCiBjb2RlcG9pbnQgY29tYmluYXRpb25zLjxicj4NCjxicj4NCkkganVzdCB0 aG91Z2h0IHlvdSdkIGxpa2UgdG8ga25vdy4uLiBubyBhY3Rpb24gcmVxdWlyZWQuPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KQm9iPGJyPg0KPGJyPg0KLS0gPG86cD48L286cD48L3NwYW4+PC9wPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0i aHR0cDovL2JvYmJyaXNjb2UubmV0LyI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLSA8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9ib2Jicmlz Y29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2Ji cmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkJvYiBCcmlzY29lJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5l dC88L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_C5C3BB522B1DDF478AA09545169155B48B3B4329nkgeml514mbschi_-- From nobody Sun Apr 9 20:52:51 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D947127097 for ; Sun, 9 Apr 2017 20:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 z1hv27xZAHaj for ; Sun, 9 Apr 2017 20:52: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 25A54126B72 for ; Sun, 9 Apr 2017 20:52:48 -0700 (PDT) Received: from [192.168.1.28] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3A3q9DU007399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 9 Apr 2017 20:52:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Sun, 9 Apr 2017 20:52:09 -0700 Cc: tsvwg , Mark Townsley Content-Transfer-Encoding: quoted-printable Message-Id: <0ED486E5-44A7-46E4-AA5B-4041820076B8@isi.edu> References: <77bbceb7-d905-d4b0-a250-41450ee56645@isi.edu> To: "Weixinpeng (Jackie)" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] question about layered congestion issue - draft-ietf-tsvwg-tunnel-congestion-feedback X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 03:52:49 -0000 > On Apr 9, 2017, at 6:37 PM, Weixinpeng (Jackie) wr= ote: >=20 > The approach in this draft and the congestion control on end host should b= e considered as two kinds of separated methods. > The approach in this draft should be considered as a kind of traffic manag= ement approach, and we just try to avoid conflicting with e2e congestion con= trol. I understand that is a goal, but it is not achieved merely by assertion. You= need to clearly explain how you ensure decoupling, either by a specific pr= otocol mechanism or constraints on a plugin. The current text is insufficien= t to achieve your assertion.=20 Joe From nobody Mon Apr 10 10:48:05 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4D1129ACC for ; Mon, 10 Apr 2017 10:48:04 -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 6UaQNN3lbUZQ for ; Mon, 10 Apr 2017 10:48:01 -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 A190A129AD0 for ; Mon, 10 Apr 2017 10:47:42 -0700 (PDT) X-AuditID: c1b4fb25-837ff70000006af2-e1-58ebc53c6c81 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 55.A3.27378.C35CBE85; Mon, 10 Apr 2017 19:47:41 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.339.0; Mon, 10 Apr 2017 19:47: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=Q2UGIE7fwS4Sy0FzrcSc4GF9qy9JDmL1wSoHdTdVkVU=; b=Kl4V+qrKIe317wrWEXdB5j1Uq33qQGHYfgRwf3W/e5cTBARk3Wmc7xFwHk287trqA7dxv7GQzVh8wtS1/mQ+wndVKnKe8amzTYFZVUbgqztJA9ZbVxFF3pGuKx/u8vh8/ils9AsUSK1s+CSBhPw+d2XPMOwFP05B29PBptwCZGc= 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; Mon, 10 Apr 2017 17:47:39 +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.007; Mon, 10 Apr 2017 17:47:39 +0000 From: Ingemar Johansson S To: tsvwg IETF list Thread-Topic: 3GPP TS36.300 with updated ECN section Thread-Index: AdKyIcuQPH6y9IVOTeC0SpfOn8fZfg== Date: Mon, 10 Apr 2017 17:47: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: [213.113.27.92] x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 7:GhtGpNBNCtOcI8pa8e5ZX0mNrKSScnV6SM407jydAZp1vg+T0OpVewRGLrN2LnRzxtLzjIQZVJd8mwo8m7foEw87hk5gnXirBnj/nWP96GA0f/u4Hc2IjwNhIUWYafL0vA3IcVDf0MiJwsx1cyR3BM2gPpyQz4VXJKqpNlNndmYMokoc5jvreeKj8GUf3Q16BjloY9AxQYslmhMejOn5XJNjxlEBq7QBPPL6ineuVwaFaG6bRa0OdUOO4x7tVCWRT5CtTDAHWV9dWK+F/2jS58T1AIUODxHD7cWNgGEHEzGIeSvIEXEbtMxrF2PtuNOjbFerMKqvDFia5rx1CfHjCQ== x-ms-office365-filtering-correlation-id: 1c79078e-3523-474f-0740-08d48039ae47 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)(278428928389397)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB346; x-forefront-prvs: 027367F73D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39860400002)(39410400002)(39400400002)(39850400002)(39450400003)(110136004)(2420400007)(38730400002)(10710500007)(3846002)(102836003)(6116002)(790700001)(15650500001)(2906002)(33656002)(9326002)(7110500001)(3280700002)(2900100001)(8936002)(3660700001)(5660300001)(5250100002)(7736002)(25786009)(6506006)(7696004)(6436002)(8676002)(55016002)(99286003)(81166006)(86362001)(966004)(236005)(189998001)(53936002)(7906003)(9686003)(6306002)(19609705001)(8558605004)(50986999)(74316002)(6916009)(54356999)(66066001)(19623455009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3480CAFA41118F50C87F1F2C2010DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2017 17:47:38.9082 (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: H4sIAAAAAAAAA02SbUhTYRTHe+7d7q6jxdOmeTITGglROE2t/GCWRGCBYZ9a+sGWXnQ5p+ya pRQIzWib5tIp+VJaDvEFCyx0gVqulHKQgk4ttRdfwFdSSWUU0rbHwG+/8/+f/+EcOCwtrRMG sGptDqfTqjRyRiyoVHaEhZzuXVSGtXyho/qWJpmzKM5qdVEJKFEcncpp1LmcLjTmmjh9dmaD yV69fLtVb2AKkO2CEfmwgCPh2SMXY0RiVopfIlhfrhWR4iMC/ZMGylMIcDENhhUnTZwKChzr NiEpfiIY3ZgSeIYxOBqa7JvIw774MPxuMoo8LMOh0F5cyhA9EgacDoqwAoqq73mzAhwMC0Nr Xl2CE6FsvtvLCB+E75vfvD009oevM7UUWRyDtXOAJuwH89Nb3oUQNiFYeTribmLdxiH4YLnl 0QGbaHDVDiESiIe+/ofb4bswZZoWEVbDoOU9TbIaWB1LJ9kBCmY/O7b7A8HRukwTo1MIve29 NLkyACaHDYhwIMxNdAnJ1llgWTWLyGV74VPljIAMSgBrWxljRsFVO46r2hGp2hEhugLGyi0M 4WPQ8GyRJhwCj7fsgp16HRI1Iz+e469npoVHKDidOoXns7QKLZfThtx/0/P6T7ANDS3F2hFm kXy35EfJolIqVOXyeZl2BCwt95U4H7glSaoqL5/TZSXrbmo43o4OsAK5vyS2e1ApxWmqHC6D 47I53X+XYn0CCpDsl6nfvrZR3YVDKgP5UGvGq9HYxpqOwlOm+sZ8Zf7fF4Wa+Pb9J4dlPXWD ydbwuJHlPfusJcY583mnz9vyqa5d98v8UxKhpSdpsiJq3HBVpr+xYK4xm6lLZ7QXbS3niprv BLXVv0k6ciIiPkg40e0qjeyTT8es6Z+PX3knYx1yAZ+uOn6U1vGqf4iVlwwzAwAA Archived-At: Subject: [tsvwg] 3GPP TS36.300 with updated ECN section X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:48:04 -0000 --_000_DB4PR07MB3480CAFA41118F50C87F1F2C2010DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi In case it is of interest. Section 11.6 in 3GPP TS 36.300 was recently updated to reference RFC7567, h= opefully this should remove the ambiguities. http://www.3gpp.org/ftp//Specs/archive/36_series/36.300/36300-e20.zip The eNB and the UE support of the Explicit Congestion Notification (ECN) is= specified in Section 5 of [35] (i.e., the normative part of [35] that appl= ies to the end-to-end flow of IP packets), and below. ECN is beneficial es= pecially for latency sensitive interactived applications such as chat and g= aming as well as for real-time voice and video, this because loss as a cong= estion signal is avoided, losses that would otherwise necessitate retransmi= ssion of packets with additional application delay as a result. The eNB should set the Congestion Experienced (CE) codepoint ('11') in PDCP= SDUs in the downlink direction to indicate downlink (radio) congestion if = those PDCP SDUs have one of the two ECN-Capable Transport (ECT) codepoints = set. The eNB should set the Congestion Experienced (CE) codepoint ('11') in= PDCP SDUs in the uplink direction to indicate uplink (radio) congestion if= those PDCP SDUs have one of the two ECN-Capable Transport (ECT) codepoints= set. ECN marking should be per the recommendations in [73]. Regards 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_DB4PR07MB3480CAFA41118F50C87F1F2C2010DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

In case it is of interest.

Section 11.6 in 3GPP TS 36.300 was recently updated = to reference RFC7567, hopefully this should remove the ambiguities.

The eNB and the UE support of th= e Explicit Congestion Notification (ECN) is specified in Section 5 of [35] = (i.e., the normative part of [35] that applies to the end-to-end flow o= f IP packets), and below.  ECN is beneficial especially for latency sensitive intera= ctived applications such as chat and gaming as well as for real-time voice = and video, this because loss as a congestion signal is avoided, losses that= would otherwise necessitate retransmission of packets with additional application delay as a result.

The eNB should set the Congestio= n Experienced (CE) codepoint (‘11’) in PDCP SDUs in the downlin= k direction to indicate downlink (radio) congestion if those PDCP SDUs have one of the two ECN-Capable Transport (ECT) codepoints set. = The eNB should set the Congestion Experienced (CE) codepoint (‘11R= 17;) in PDCP SDUs in the uplink direction to indicate uplink (radio) conges= tion if those PDCP SDUs have one of the two ECN-Capable Transport (ECT) codepoints set. ECN marking should be per the = recommendations in [73].

 

 

Regards

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_DB4PR07MB3480CAFA41118F50C87F1F2C2010DB4PR07MB348eurprd_-- From nobody Tue Apr 11 02:38:56 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821251204DA for ; Tue, 11 Apr 2017 02:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_KAM_HTML_FONT_INVALID=0.01, 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 pT1xgKUBfp52 for ; Tue, 11 Apr 2017 02:38:50 -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 494B01201F2 for ; Tue, 11 Apr 2017 02:38:48 -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=0wV37uzZ6rfSyK91unyiOVaqn5DVd8OKS0J4VHA6mSg=; b=rPirH8WgKIT2+qpBBqNvsmWFe PWkBu0GsKZQBGu+85/NDXYMLHiHrsERXAI6pRhcKdmPpcnQMC2liBiFMBYy4i8WA+9gRVNaPybIbW BQRKaXBThRSNIYqRL8y70IIcnAFv4AnOViathGc1Nj6Mu5SLZ6wRCtyWxzRiELUci/yJ7jP7iAWIh JnavDmh6KGRJ2ADML29J6xCa+LzxokvYCXdjgcwq8B6fGCOoFz/0J3UakdahBABMtXPH63GAxEzAJ p2ofFvN+cSfE5MQkCDJQu8ui4S6MmOcuLB+GU+HCwiQAUFsLFkZz2AolFUTLwgYOMj/XvTdRjhtjq yAZx+RljQ==; Received: from host31-53-160-188.range31-53.btcentralplus.com ([31.53.160.188]:50902 helo=[192.168.1.82]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1cxsG4-0002Fn-FR; Tue, 11 Apr 2017 10:38:45 +0100 To: "Weixinpeng (Jackie)" , "Black, David" , "draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org" References: <712bfd85-39e5-bcae-f9b9-0035ef5cf654@bobbriscoe.net> Cc: tsvwg IETF list From: Bob Briscoe Message-ID: Date: Tue, 11 Apr 2017 10:38:43 +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: multipart/alternative; boundary="------------E906635C945E9594312CC6C0" 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: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 09:38:54 -0000 This is a multi-part message in MIME format. --------------E906635C945E9594312CC6C0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yup On 10/04/17 03:03, Weixinpeng (Jackie) wrote: > > Thanks David and Bob, > > I think we have reach a consensus that both faked ECN + egress–only > approach and ingress-egress comparison approach should be use, the > first approach is for ECN measurement and the second approach is for > packet loss count. > > -Xinpeng > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Saturday, April 08, 2017 5:16 PM > *To:* Black, David; Weixinpeng (Jackie); > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > *Cc:* tsvwg IETF list > *Subject:* Re: Tunnel Congestion Feedback: (non-)update to RFC6040 > > David, > > Thx for all your points - all understood and I agreed with them all. > > I think now that Weixinpeng, you and I all agree that the draft should > specify ingress-egress comparison for drop and the egress-only > approach for ECN. So then the faked ECN approach can stay, because it > shifts some/most drops to the more robust egress-only measurement > location. But I suggest the faked ECN text is moved up a paragraph, > because the paragraph before it doesn't make sense unless the readers > already knows about faked ECN. > > I will still send a full review, possibly this weekend, but early next > week is looking more likely now. > > > Bob > > On 08/04/17 02:20, Black, David wrote: > > I’m among those responsible for the ingress-egress measurement > addition, so weighing in as draft shepherd: > > > However, I am saying it is less robust to have to measure at both ingress and > egress, because it involves sending synch / measurement > > > messages from ingress to egress, which can be lost/delayed. So, I would > recommend the more robust egress-only method for ECN, > > > and the ingress-egress method only for total drop. > > > That seems fine, however the total drop info does need to be > reported in addition to ECN info. > > > > The only extra thing you learn by the currently proposed > approach is how many of each ECN codepoint were dropped. If you > think that's important, argue for it. I don't see any need for it tho. > > I would agree. > > > If you insist on keeping the ingress-egress approach, why do you > need the faked ECN text? > > If one is trying to measure congestion in the tunnel, drops have > to be considered – even if all nodes in the tunnel support ECN, an > overloaded ECN node will drop packets. > > The reason for faked-ECN is buried in Bob’s “more robust” comment > about egress-only ECN measurement above – use of ECN should result > in better measurements by comparison to non-use. > > Thanks, --David > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, April 7, 2017 10:48 AM > *To:* Weixinpeng (Jackie) > ; Black, David > ; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list > *Subject:* Re: Tunnel Congestion Feedback: (non-)update to RFC6040 > > Weixinpeng, > > On 05/04/17 03:45, Weixinpeng (Jackie) wrote: > > Hi Bob, > > Thanks for your comments, and please see inline. > > Regards, > > -Xinpeng > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Monday, April 03, 2017 5:34 AM > *To:* Weixinpeng (Jackie); Black, David; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list > *Subject:* Re: Tunnel Congestion Feedback: (non-)update to RFC6040 > > Weixinpeng, co-authors, and David, > > I had promised a review of the latest TCF draft, but failed to > provide it so far. > I half read it through on Friday, and I will finish and write > up my review this week. > > Here' a quick summary of the main points so far: > > *S.1. Intro: Motivation > *The motivation should also include a heavy load from a much > larger than expected number of responsive flows > > */[Wei] Ok, I will add it./* > > *S.1 Intro: Scope > *I think the draft should say that > * it gives no advice on how to select which tunnel endpoints > should be used in order to manage traffic over a network > criss-crossed by multiple tunnels. > * if a congested node is part of multiple tunnels, and it > causes congestion feedback to multiple traffic management > functions at the ingresses of all the tunnels, the draft gives > no advice on how all the traffic management functions should > respond. > * etc. (in my full review, I will provide a full list of > subjects that are out of scope). > > */[Wei] Ok./* > > *S.3. Feedback Models: > *The architecture diagrams and text need to include components > that apply a consistent measurement policy (template records > in IPFIX-speak) at both ingress and egress. This is a key part > of interoperability, which is what the IETF should be all > about. Template records are described later when the mechanism > is specified, but they are not shown in the layout of the > components in S.3. > > */[Wei] I will provide a description of Template record in > this section. But I am wondering whether a detailed > description of Template Record as section 6.1 is needed here > or not?/* > > I suggest that, at this stage in the doc, it would be best not to > be specific to one technology (IPFIX) but instead to talk more > generally about setting and storing measurement policy (at the > decision point and the egress meter). > > BTW, did you invent the terminology decision point (DP) and action > point (AP)? Because there is already IETF terminology for these: > * Policy Decision Point (PDP) > * Policy Enforcement Point (PEP). > > See COPS (Common Open Policy Service) Protocol [RFC2748] or > terminology for policy-based management [RFC3198] > > > > > *S.4. Congestion Level Measurement: > *Measurement of ECN has been changed without thinking clearly > whether it needed to change. > > a) Earlier drafts exploited the fact that the inner holds > a "frozen" record of the ECN field at the ingress. So ECN > measurements could be made solely at the egress (comparing the > outer with the inner). In draft-04, ECN codepoints are > measured at the ingress and at the egress, with the ingress > sending regular measurement reports to the egress for > comparison. However, it is always safer to measure ECN solely > at the egress, even though a different mechanism has to > measure drops within the tunnel (due to non-ECN nodes, or > nodes that have switched off ECN due to overload, or due to > causes of loss other than congestion, e.g. transmission errors). > - It is always safer to solely measure ECN at the egress, > because it is not vulnerable to ingress-egress measurement > packets being dropped. > - Solely measuring ECN at egress is no less precise, > because only the proportion of the different ECN fields is > needed, and that stays approximately the same even if there is > drop, assuming drop is not biased towards certain ECN > codepoints (no known mechanism does that). > > b) In draft-04 the faked ECT approach has been left > unchanged at the ingress, but it is no longer used at the > egress for detecting deferred drops (by looking for a Not-ECN > inner and a CE outer). Again, there is nothing wrong with > measuring ECN and detecting deferred drops solely at the > egress, even if there are drops within the tunnel. To measure > drops within the tunnel, it is necessary to compare ingress > and egress bytes, but that does not make it wrong to still > measure and compare ECN solely at the egress. > > */[Wei] I agree that solely measuring ECN at egress is enough > to get the proportion of different ECN fields, but the reason > why ECN codepoints are measured both at ingress and egress is > to measure the packets dropped within the tunnel by comparing > counts at ingress and egress. /* > > I am not saying you should not also measure drop by measuring > total bytes at ingress and egress. > > However, I am saying it is less robust to have to measure at both > ingress and egress, because it involves sending synch / > measurement messages from ingress to egress, which can be > lost/delayed. > So, I would recommend the more robust egress-only method for ECN, > and the ingress-egress method only for total drop. > > The only extra thing you learn by the currently proposed approach > is how many of each ECN codepoint were dropped. If you think > that's important, argue for it. I don't see any need for it tho. > > If you insist on keeping the ingress-egress approach, why do you > need the faked ECN text? > > > > > > *S.4. Congestion Level Measurement: Units > *Throughout measurement involves counting packets. However, it > should count the bytes in packets with each type of marking, > not just the number of packets. See RFC7141 section 2.3 > . Although > the recommendation in that RFC is about what a /transport/ > should measure when responding to congestion, logically it > should apply in this case when a traffic management function > is responding in place of a transport. RFC7141 also gives > recommendations on which headers to count. > > */[Wei] Ok, it’s a good suggestion./* > > > > > I shall add to this review later in the week. > > One question for Weixinpeng: Have you implemented this mechanism? > > */[Wei] Currently, we only implement this mechanism in a > simulation environment./* > > I suspected as much, because the lack of detail in some places > implies it is a bit theoretical. > I would encourage you to implement. > > > > Bob > > > > > Bob > > > > On 01/11/16 01:49, Weixinpeng (Jackie) wrote: > > Hi Bob and David, > > Because the deadline has passed, I will update it as part > of post-WGLC update. Thanks. > > Regards, > > -Xinpeng (Jackie) > > *From:*Black, David [mailto:David.Black@dell.com] > *Sent:* Tuesday, November 01, 2016 12:14 AM > *To:* Bob Briscoe; Weixinpeng (Jackie); > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list; Black, David > *Subject:* RE: Tunnel Congestion Feedback: (non-)update to > RFC6040 > > > I assume you will update the TCF draft today before the > deadline. > > (As draft shepherd) That’s not really necessary - the TCF > draft is in WGLC, so this change can be done as part of a > post-WGLC update. > > Thanks, --David > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Monday, October 31, 2016 11:22 AM > *To:* Weixinpeng (Jackie); Black, David; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list > *Subject:* Re: Tunnel Congestion Feedback: (non-)update to > RFC6040 > > Xinpeng, > > I agree that TCF does not update RFC6040 (as I said). > > But David is right that the TCF draft itself needs to be > updated to say that it modifies the behaviour of a RFC6040 > egress so as to issue or log any warnings when it receives > an ECT(0) or CE outer with a Not-ECT inner. > > I assume you will update the TCF draft today before the > deadline. > > Cheers > > Bob > > On 31/10/16 02:38, Weixinpeng (Jackie) wrote: > > Hi David, Bob, > > I agree that the behavior defined in RFC6040 doesn’t > to be updated due to the TCF draft, because what’s > defined in RFC 6040 has a broader usage and not just > for TCF. > > I think David has provided a good suggestion below. > Thanks. > > Regards, > > -Xinpeng (Jackie) > > *From:*tsvwg [mailto:tsvwg-bounces@ietf.org] *On > Behalf Of *Black, David > *Sent:* Saturday, October 29, 2016 10:28 AM > *To:* Bob Briscoe; > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > > *Cc:* tsvwg IETF list > *Subject:* Re: [tsvwg] Tunnel Congestion Feedback: > (non-)update to RFC6040 > > Bob, > > I think you’ve found something. The TCF draft > currently uses RFC 6040 behavior by reference: > > when decapsulating packets at egress, > > RFC6040 defined decapsulation behavior is used, and > according to > > RFC6040, the packets marked as CE|N-ECT will be > dropped by egress. > > I think this needs to be slightly revised to say that > CE|N-ECT is dropped without any other > > action, and all other behavior is as per RFC 6040, as > CE|N-ECT is expected at a TCF egress and > > hence the logging and alarm behavior for that > combination in RFC 6040 is inappropriate. > > Once that’s done, I think your reasoning in the > following sentence becomes correct: > > If the network is not valid, these combination could > become visible to a 6040-decap, > > which would then (correctly) log warnings that it was > seeing invalid codepoint combinations. > > Thanks, --David (as draft shepherd) > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Thursday, October 27, 2016 4:39 PM > *To:* > draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org > ; > Black, David > *Cc:* tsvwg IETF list > *Subject:* Tunnel Congestion Feedback: (non-)update to > RFC6040 > > Tunnel congestion feedback authors, David as shepherd, > > FYI. No action needed. > > This email documents an argument with myself. After a > few seconds, I agreed with myself that one of me was > wrong. I thought I had better raise this on the list, > to check that others agree with both of me. If you > wish to argue with just one of me, please bear in mind > that we both have the same email address (and anyway, > we both agree so an argument with one is an argument > with all). > _________________________ > > Figure 4 of RFC6040 specifies which ECN codepoint a > decap must forward, for each combination of arriving > inner (row) and outer (column). > > > +---------+------------------------------------------------+ > > |Arriving | Arriving Outer > Header | > > | Inner > +---------+------------+------------+------------+ > > | Header | Not-ECT | ECT(0) | > ECT(1) | CE | > > > +---------+---------+------------+------------+------------+ > > | Not-ECT | Not-ECT > |Not-ECT(!!!)|Not-ECT(!!!)| (!!!)| > > | ECT(0) | ECT(0) | ECT(0) | > ECT(1) | CE | > > | ECT(1) | ECT(1) | ECT(1) (!) | > ECT(1) | CE | > > | CE | CE | CE | > CE(!!!)| CE | > > > +---------+---------+------------+------------+------------+ > > RFC6040 goes on to say: > > [...] These currently unused > (CU) combinations are > > indicated in Figure 4 by '(!!!)' or '(!)', where > '(!!!)' means the > > combination is CU and always potentially > dangerous, while '(!)' > > means it is CU and possibly dangerous. In these > cases, > > particularly the more dangerous ones, the > decapsulator SHOULD log > > the event and MAY also raise an alarm. > > TCF uses the following combinations of inner : outer > Not-ECT : ECT(0) > Not-ECT : CE > > For a moment, I thought we would have to update > RFC6040 to say that TCF makes these combinations no > longer CU, so they are now valid, not dangerous, and > they no longer need to be logged. This would have > meant that Tunnel Congestion Feedback (TCF) > (informational) would have to update RFC6040 (proposed > standard). > > Here's why I was wrong. These two combinations are > certainly valid at a TCF decap. But there is still no > way that, in a valid network, they would arrive at any > RFC6040 (non-TCF) decap. > > One might think that this combination could arrive at > a 6040-decap if there was a tunnel inside a tunnel, as > follows > > TCF-encap ---> 6040-decap ---> TCF-decap > > However, that's not a valid configuration. The > following tunnel-in-tunnel would be valid: > > TCF-encap ---> 6040-encap ---> 6040-decap ---> TCF-decap > > ...then, the above two "CU" combinations would be > buried within a double inner, so only the TCF decap > would see them, not the 6040-decap. > > So, TCF does not need to update RFC6040. Because, in a > valid network, TCF will be hidden from any 6040-decap. > If the network is not valid, these combination could > become visible to a 6040-decap, which would then > (correctly) log warnings that it was seeing invalid > codepoint combinations. > > I just thought you'd like to know... no action required. > > > > Bob > > -- > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------E906635C945E9594312CC6C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Yup

On 10/04/17 03:03, Weixinpeng (Jackie) wrote:

Thanks David and Bob,

I think we have reach a consensus that both faked ECN + egress–only approach and ingress-egress comparison approach should be use, the first approach is for  ECN measurement and the second approach is for packet loss count.

 

-Xinpeng

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Saturday, April 08, 2017 5:16 PM
To: Black, David; Weixinpeng (Jackie); draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

 

David,

Thx for all your points - all understood and I agreed with them all.

I think now that Weixinpeng, you and I all agree that the draft should specify ingress-egress comparison for drop and the egress-only approach for ECN. So then the faked ECN approach can stay, because it shifts some/most drops to the more robust egress-only measurement location. But I suggest the faked ECN text is moved up a paragraph, because the paragraph before it doesn't make sense unless the readers already knows about faked ECN.

I will still send a full review, possibly this weekend, but early next week is looking more likely now.


Bob

On 08/04/17 02:20, Black, David wrote:

I’m among those responsible for the ingress-egress measurement addition, so weighing in as draft shepherd:

 

> However, I am saying it is less robust to have to measure at both ingress and egress, because it involves sending synch / measurement

> messages from ingress to egress, which can be lost/delayed.  So, I would recommend the more robust egress-only method for ECN,

> and the ingress-egress method only for total drop.


That seems fine, however the total drop info does need to be reported in addition to ECN info.


> The only extra thing you learn by the currently proposed approach is how many of each ECN codepoint were dropped. If you think that's important, argue for it. I don't see any need for it tho.

 

I would agree.

> If you insist on keeping the ingress-egress approach, why do you need the faked ECN text?

 

If one is trying to measure congestion in the tunnel, drops have to be considered – even if all nodes in the tunnel support ECN, an overloaded ECN node will drop packets.

The reason for faked-ECN is buried in Bob’s “more robust” comment about egress-only ECN measurement above – use of ECN should result in better measurements by comparison to non-use.

 

Thanks, --David

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Friday, April 7, 2017 10:48 AM
To: Weixinpeng (Jackie) <weixinpeng@huawei.com>; Black, David <david.black@emc.com>; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list <tsvwg@ietf.org>
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Weixinpeng,

On 05/04/17 03:45, Weixinpeng (Jackie) wrote:

Hi Bob,

Thanks for your comments, and please see inline.

Regards,

-Xinpeng

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Monday, April 03, 2017 5:34 AM
To: Weixinpeng (Jackie); Black, David; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Weixinpeng, co-authors,  and David,

I had promised a review of the latest TCF draft, but failed to provide it so far.
I half read it through on Friday, and I will finish and write up my review this week.

Here' a quick summary of the main points so far:

S.1. Intro: Motivation
The motivation should also include a heavy load from a much larger than expected number of responsive flows

[Wei] Ok, I will add it.

S.1 Intro: Scope
I think the draft should say that
* it gives no advice on how to select which tunnel endpoints should be used in order to manage traffic over a network criss-crossed by multiple tunnels.
* if a congested node is part of multiple tunnels, and it causes congestion feedback to multiple traffic management functions at the ingresses of all the tunnels, the draft gives no advice on how all the traffic management functions should respond.
* etc. (in my full review, I will provide a full list of subjects that are out of scope).

[Wei] Ok.

S.3. Feedback Models:
The architecture diagrams and text need to include components that apply a consistent measurement policy (template records in IPFIX-speak) at both ingress and egress. This is a key part of interoperability, which is what the IETF should be all about. Template records are described later when the mechanism is specified, but they are not shown in the layout of the components in S.3.

[Wei] I will provide a description of Template record in this section. But I am wondering whether a detailed description of Template Record as section 6.1 is needed here or not?

I suggest that, at this stage in the doc, it would be best not to be specific to one technology (IPFIX) but instead to talk more generally about setting and storing measurement policy (at the decision point and the egress meter).

BTW, did you invent the terminology decision point (DP) and action point (AP)? Because there is already IETF terminology for these:
* Policy Decision Point (PDP)
* Policy Enforcement Point (PEP).

See COPS (Common Open Policy Service) Protocol [RFC2748] or terminology for policy-based management [RFC3198]




S.4. Congestion Level Measurement:
Measurement of ECN has been changed without thinking clearly whether it needed to change.

    a) Earlier drafts exploited the fact that the inner holds a "frozen" record of the ECN field at the ingress. So ECN measurements could be made solely at the egress (comparing the outer with the inner). In draft-04, ECN codepoints are measured at the ingress and at the egress, with the ingress sending regular measurement reports to the egress for comparison. However, it is always safer to measure ECN solely at the egress, even though a different mechanism has to measure drops within the tunnel (due to non-ECN nodes, or nodes that have switched off ECN due to overload, or due to causes of loss other than congestion, e.g. transmission errors).
     - It is always safer to solely measure ECN at the egress, because it is not vulnerable to ingress-egress measurement packets being dropped.
     - Solely measuring ECN at egress is no less precise, because only the proportion of the different ECN fields is needed, and that stays approximately the same even if there is drop, assuming drop is not biased towards certain ECN codepoints (no known mechanism does that).

    b) In draft-04 the faked ECT approach has been left unchanged at the ingress, but it is no longer used at the egress for detecting deferred drops (by looking for a Not-ECN inner and a CE outer). Again, there is nothing wrong with measuring ECN and detecting deferred drops solely at the egress, even if there are drops within the tunnel. To measure drops within the tunnel, it is necessary to compare ingress and egress bytes, but that does not make it wrong to still measure and compare ECN solely at the egress.

[Wei] I agree that solely measuring ECN at egress is enough to get the proportion of different ECN fields, but the reason why ECN codepoints are measured both at ingress and egress is to measure the packets dropped within the tunnel by comparing counts at ingress and egress.

I am not saying you should not also measure drop by measuring total bytes at ingress and egress.

However, I am saying it is less robust to have to measure at both ingress and egress, because it involves sending synch / measurement messages from ingress to egress, which can be lost/delayed.
So, I would recommend the more robust egress-only method for ECN, and the ingress-egress method only for total drop.

The only extra thing you learn by the currently proposed approach is how many of each ECN codepoint were dropped. If you think that's important, argue for it. I don't see any need for it tho.

If you insist on keeping the ingress-egress approach, why do you need the faked ECN text?





S.4. Congestion Level Measurement: Units
Throughout measurement involves counting packets. However, it should count the bytes in packets with each type of marking, not just the number of packets. See RFC7141 section 2.3. Although the recommendation in that RFC is about what a /transport/ should measure when responding to congestion, logically it should apply in this case when a traffic management function is responding in place of a transport. RFC7141 also gives recommendations on which headers to count.

[Wei] Ok, it’s a good suggestion.




I shall add to this review later in the week.

One question for Weixinpeng: Have you implemented this mechanism?

[Wei] Currently, we only implement this mechanism in a simulation environment.

I suspected as much, because the lack of detail in some places implies it is a bit theoretical.
I would encourage you to implement.



Bob




Bob



On 01/11/16 01:49, Weixinpeng (Jackie) wrote:

Hi Bob and David,

Because the deadline has passed, I will update it as part of post-WGLC update. Thanks.

 

Regards,

-Xinpeng (Jackie)

 

From: Black, David [mailto:David.Black@dell.com]
Sent: Tuesday, November 01, 2016 12:14 AM
To: Bob Briscoe; Weixinpeng (Jackie); draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list; Black, David
Subject: RE: Tunnel Congestion Feedback: (non-)update to RFC6040

 

> I assume you will update the TCF draft today before the deadline.

 

(As draft shepherd) That’s not really necessary - the TCF draft is in WGLC, so this change can be done as part of a post-WGLC update.

 

Thanks, --David

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Monday, October 31, 2016 11:22 AM
To: Weixinpeng (Jackie); Black, David; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Xinpeng,

I agree that TCF does not update RFC6040 (as I said).

But David is right that the TCF draft itself needs to be updated to say that it modifies the behaviour of a RFC6040 egress so as to issue or log any warnings when it receives an ECT(0) or CE outer with a Not-ECT inner.

I assume you will update the TCF draft today before the deadline.

Cheers

Bob

On 31/10/16 02:38, Weixinpeng (Jackie) wrote:

Hi David, Bob,

I agree that the behavior defined in RFC6040 doesn’t to be updated due to the TCF draft, because what’s defined in RFC 6040 has a broader usage and not just for TCF.

I think David has provided a good suggestion below. Thanks.

 

Regards,

-Xinpeng (Jackie)

 

From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David
Sent: Saturday, October 29, 2016 10:28 AM
To: Bob Briscoe; draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org
Cc: tsvwg IETF list
Subject: Re: [tsvwg] Tunnel Congestion Feedback: (non-)update to RFC6040

 

Bob,

 

I think you’ve found something.  The TCF draft currently uses RFC 6040 behavior by reference:

 

   when decapsulating packets at egress,

   RFC6040 defined decapsulation behavior is used, and according to

   RFC6040, the packets marked as CE|N-ECT will be dropped by egress.

 

I think this needs to be slightly revised to say that CE|N-ECT is dropped without any other

action, and all other behavior is as per RFC 6040, as CE|N-ECT is expected at a TCF egress and

hence the logging and alarm behavior for that combination in RFC 6040 is inappropriate.

 

Once that’s done, I think your reasoning in the following sentence becomes correct:

 

If the network is not valid, these combination could become visible to a 6040-decap,

which would then (correctly) log warnings that it was seeing invalid codepoint combinations.

Thanks, --David (as draft shepherd)

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Thursday, October 27, 2016 4:39 PM
To: draft-ietf-tsvwg-tunnel-congestion-feedback@tools.ietf.org; Black, David
Cc: tsvwg IETF list
Subject: Tunnel Congestion Feedback: (non-)update to RFC6040

 

Tunnel congestion feedback authors, David as shepherd,

FYI. No action needed.

This email documents an argument with myself. After a few seconds, I agreed with myself that one of me was wrong. I thought I had better raise this on the list, to check that others agree with both of me. If you wish to argue with just one of me, please bear in mind that we both have the same email address (and anyway, we both agree so an argument with one is an argument with all).
_________________________

Figure 4 of RFC6040 specifies which ECN codepoint a decap must forward, for each combination of arriving inner (row) and outer (column).

            +---------+------------------------------------------------+
            |Arriving |            Arriving Outer Header               |
            |   Inner +---------+------------+------------+------------+
            |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
            +---------+---------+------------+------------+------------+
            | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
            |  ECT(0) |  ECT(0) | ECT(0)     | ECT(1)     |     CE     |
            |  ECT(1) |  ECT(1) | ECT(1) (!) | ECT(1)     |     CE     |
            |    CE   |      CE |     CE     |     CE(!!!)|     CE     |
            +---------+---------+------------+------------+------------+

RFC6040 goes on to say:

                      [...] These currently unused (CU) combinations are
      indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the
      combination is CU and always potentially dangerous, while '(!)'
      means it is CU and possibly dangerous.  In these cases,
      particularly the more dangerous ones, the decapsulator SHOULD log
      the event and MAY also raise an alarm.
 

TCF uses the following combinations of inner : outer
    Not-ECT : ECT(0)
    Not-ECT : CE

For a moment, I thought we would have to update RFC6040 to say that TCF makes these combinations no longer CU, so they are now valid, not dangerous, and they no longer need to be logged. This would have meant that Tunnel Congestion Feedback (TCF) (informational) would have to update RFC6040 (proposed standard).

Here's why I was wrong. These two combinations are certainly valid at a TCF decap. But there is still no way that, in a valid network, they would arrive at any RFC6040 (non-TCF) decap.

One might think that this combination could arrive at a 6040-decap if there was a tunnel inside a tunnel, as follows

  TCF-encap                 ---> 6040-decap ---> TCF-decap

However, that's not a valid configuration. The following tunnel-in-tunnel would be valid:

  TCF-encap ---> 6040-encap ---> 6040-decap ---> TCF-decap

...then, the above two "CU" combinations would be buried within a double inner, so only the TCF decap would see them, not the 6040-decap.

So, TCF does not need to update RFC6040. Because, in a valid network, TCF will be hidden from any 6040-decap. If the network is not valid, these combination could become visible to a 6040-decap, which would then (correctly) log warnings that it was seeing invalid codepoint combinations.

I just thought you'd like to know... no action required.



Bob

-- 

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

 

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





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




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



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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------E906635C945E9594312CC6C0-- From nobody Tue Apr 11 14:44:32 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34738129AD5 for ; Tue, 11 Apr 2017 14:44:18 -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 6IkCbgN-sMTz for ; Tue, 11 Apr 2017 14:44:17 -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 CA68712EBDA for ; Tue, 11 Apr 2017 14:44:16 -0700 (PDT) Received: from [128.9.184.20] ([128.9.184.20]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3BLhu2P001682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Apr 2017 14:43:56 -0700 (PDT) To: tsvwg From: Joe Touch Message-ID: Date: Tue, 11 Apr 2017 14:43:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3BLhu2P001682 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [tsvwg] of possible interest - DOE Network2025 report X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:44:18 -0000 Hi, all, The US Department of Energy (DOE) recently issued its Network2025 report from its Feb 2016 workshop; both the report and workshop are linked here: https://science.energy.gov/ascr/community-resources/program-documents/ This report provides a roadmap of key networking issues for the short (1-3 yrs), medium (4-6 yrs), and long term (10-12 yrs), and includes links to white papers presented at the meeting. Of particular interest to TSVWG are its comments on the need for high throughput bulk transfer, especially involving multiple parallel (possibly heterogeneous) links. FYI. Joe NB: I was a member of the organizing and authoring committee. From nobody Fri Apr 14 16:57:18 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBEA129B1E for ; Fri, 14 Apr 2017 16:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 huAs0ein-6F6 for ; Fri, 14 Apr 2017 16:57:16 -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 0EEE812702E for ; Fri, 14 Apr 2017 16:57:16 -0700 (PDT) Received: from [128.9.184.165] ([128.9.184.165]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3ENufZ7020161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Apr 2017 16:56:42 -0700 (PDT) References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> To: tsvwg From: Joe Touch Message-ID: <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> Date: Fri, 14 Apr 2017 16:56:41 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 23:57:17 -0000 Hi, all, Christian Huitema a question about the interaction between DTLS and UDP options during my remote presentation at IETF 98. I took a closer look and consulted with Eric Rescorla (DTLS author). He and I agreed as follows: - DTLS would currently not cover UDP options; DTLS protects only the UDP payload - the situation is analogous to TCP options, which are not covered by TLS I.e., both TLS and DTLS are transport *payload* security only, despite their names. Christian noted that this may be a reason QUIC prefers UDP (to avoid the need to protection transport options), however QUIC does not (and cannot) deprecate UDP payloads that are smaller than the IP payload. That would require a change to RFC 768. I'll add a clarification on this point to the next rev of the UDP options document. Joe From nobody Mon Apr 17 02:00:17 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D86129B10 for ; Mon, 17 Apr 2017 02:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 PETxiAVfOTdz for ; Mon, 17 Apr 2017 02:00:13 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 21C09129AF4 for ; Mon, 17 Apr 2017 02:00:12 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 769381B0174B; Mon, 17 Apr 2017 11:55:30 +0100 (BST) Message-ID: <58F48403.8080302@erg.abdn.ac.uk> Date: Mon, 17 Apr 2017 09:59:47 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Joe Touch CC: tsvwg References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> In-Reply-To: <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 09:00:16 -0000 Thanks Joe, That seems to be exactly the question the WG asked to explore. I agree your next update should add a small susbsection on how DTLS should be handled. Gorry On 15/04/2017, 00:56, Joe Touch wrote: > Hi, all, > > Christian Huitema a question about the interaction between DTLS and UDP > options during my remote presentation at IETF 98. > > I took a closer look and consulted with Eric Rescorla (DTLS author). He > and I agreed as follows: > - DTLS would currently not cover UDP options; DTLS protects only the UDP > payload > - the situation is analogous to TCP options, which are not covered by TLS > I.e., both TLS and DTLS are transport *payload* security only, despite > their names. > > Christian noted that this may be a reason QUIC prefers UDP (to avoid the > need to protection transport options), however QUIC does not (and > cannot) deprecate UDP payloads that are smaller than the IP payload. > That would require a change to RFC 768. > > I'll add a clarification on this point to the next rev of the UDP > options document. > > Joe From nobody Mon Apr 17 09:00:23 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6879313152D; Mon, 17 Apr 2017 09:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 Ey2Skk0pfTEz; Mon, 17 Apr 2017 09:00:08 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FFD131513; Mon, 17 Apr 2017 09:00:07 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id F0AA56D255; Mon, 17 Apr 2017 12:00:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; s=sasl; bh=smLpLB3Tc/v2yCxAPJPJsoKdA NE=; b=kNt/Fpls9opoy5qJeciLolca1TuwRBWD7hEWP9dPwkFL+UrJXe9JYU24H in0n/HXK5mxIPdlWXFBGc34yzm7UHc7pzlgfDJ09Dk+EL7jso/jrwth3K0hz0+XE hzL/fm1hkDhHbvDYgbDX9+lo0Oc7+HbqJKEaJq7VxIlvzHmZHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; q=dns; s=sasl; b=bZkCmrhDgcAUqxQNC96 RbI5fbOR3ZcHKVHLBEZaFjlLpdXTmHJAEwJ+39y6d6p6OJDX4zaD4Za8Ht+He/Pt NqyZ+fF5110NzgRJ2PDg79kHl4jhDkOyynBqmW7ClNT59dK2gxbq7kTjr0gUDNiG BUKc+qUAl/xWebenw0rIrFkE= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id C54356D254; Mon, 17 Apr 2017 12:00:05 -0400 (EDT) Received: from mail-qk0-f170.google.com (unknown [209.85.220.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 57AB76D23A; Mon, 17 Apr 2017 12:00:03 -0400 (EDT) Received: by mail-qk0-f170.google.com with SMTP id d131so108020882qkc.3; Mon, 17 Apr 2017 09:00:03 -0700 (PDT) X-Gm-Message-State: AN3rC/5DPj4vXL96chSWATsRwxKJm0ZmNmJZaNAb5HVja4tqr2zyUslM Cpt8NLcHN7bxhjNnUmafdnDxeFCGfw== X-Received: by 10.55.82.68 with SMTP id g65mr8978041qkb.116.1492444801437; Mon, 17 Apr 2017 09:00:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Mon, 17 Apr 2017 08:59:41 -0700 (PDT) From: "C. M. Heard" Date: Mon, 17 Apr 2017 08:59:41 -0700 X-Gmail-Original-Message-ID: Message-ID: To: 6MAN <6man@ietf.org>, tsvwg Cc: Bob Hinden , Brian Carpenter , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: EB069A54-2386-11E7-93C6-E680B56B9B0B-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 16:00:10 -0000 [ TSVWG added to solicit advice on implementation of RFC 3186 Section 5.3 ] On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: > On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>> ... >>>>>>>> ------------------------------------------------------------------= ---- >>>>>>>> COMMENT: >>>>>>>> ------------------------------------------------------------------= ---- >>>>>>>> >>>>>>>> One question because I'm not sure if I interpret this correct to m= ake it >>>>>>>> part of my discuss: >>>>>>>> Section 4.5: "The number and content of the headers preceding the >>>>>>>> Fragment >>>>>>>> header of different fragments of the same original packet may >>>>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>>>> header in each fragment packet, are processed when the packets >>>>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>>>> those headers in the Offset zero fragment packet are retained in >>>>>>>> the reassembled packet." >>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class field)= is >>>>>>>> copied from the first fragment? This doesn't seem to be correct, h= owever, >>>>>>>> also not sure what the correct answer is. I know this was not chan= ged in >>>>>>>> this revision but maybe we can still get this right. >>>>>>> >>>>>>> When fragments are created most of the fields are copied from the I= Pv6 >>>>>>> headers (e.g., Source Address, Destination address, flow label, tra= ffic >>>>>>> class, hop limit). Some like payload length, next header, and hop = limi >>>>>>> t are modified. >>>>>>> >>>>>>> If I understand your question, the answer is yes, the ECN code poin= t is >>>>>>> copied from the first fragment, but should be the same from all of = the >>>>>>> fragments. >> >> That is inconsistent with the following guidance in RFC 3168 (see >> https://tools.ietf.org/html/rfc3168#section-5.3): >> >> 5.3. Fragmentation >> >> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >> Reassembly of a fragmented packet MUST NOT lose indications of >> congestion. In other words, if any fragment of an IP packet to be >> reassembled has the CE codepoint set, then one of two actions MUST be >> taken: >> >> * Set the CE codepoint on the reassembled packet. However, this >> MUST NOT occur if any of the other fragments contributing to >> this reassembly carries the Not-ECT codepoint. >> >> * The packet is dropped, instead of being reassembled, for any >> other reason. >> >> If both actions are applicable, either MAY be chosen. Reassembly of >> a fragmented packet MUST NOT change the ECN codepoint when all of the >> fragments carry the same codepoint. >> >>>>>> My concern is that the ECN code point could be changed on one of the >>>>>> fragmented packets to signal congestion of a intermediate node and >>>>>> then when you reassemble this information gets lost. That seems wron= g. >>>>> >>>>> That is an interesting idea, but I think out of scope for advancing t= his >>>>> document to Internet Standard. Then there is the question of how to >>>>> encode n of m fragments experienced congestion. Interesting future w= ork. >>>> >>>> Yes there might be some more further work needed but that still makes = the >>>> guidance in this text wrong. Maybe we can add some text that the Traff= ic >>>> Class may be handled differently because it could be changed on the pa= th. >>> >>> Good point. It's not only ECN that can change; the DSCP can change too. >>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical >>> for 2460bis to note this issue. >> >> It seems that we (6man WG) missed this because RFC 3168 was not marked >> as updating RFC 2460. But in effect it did so for IPv6 implementations >> of ECN, even though it was not written in an IP version-agnostic manner. >> >> At the very least text should be added to the description of the >> reassembly process that points the reader to RFC 3168 or its >> successor document. > > Do we have any evidence that the guidance in RFC 3168 regarding reassembl= ing > IPv6 fragments is implemented? I don=E2=80=99t know, but think if it the= re is > evidence I agree some text should be added to rfc2460bis, if not, then > maybe not. Since I lack the expertise to answer that question, I'm hoping that someone in TSVWG will see this message and do so. Regardless of the answer to that question, my position would be that since 2460bis already defers to RFC 2474 and RFC 3168 regarding the handling of the Traffic Class field, the following modification to 2460bis Section 4.5 would be an appropriate way to deal with Mirja's comment: OLD: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. NEW: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet; however, nodes that support Explicit Congestion Notification [RFC3168] may use information in the Traffic Class field from all fragment packets to reconstruct the Traffic Class field in the reassembled packet. Note that this would not cause 2460bis itself to levy an additional requirement on how IPv6 nodes reassemble fragmented packets. It would simply be making note of a requirement that is already levied by RFC 3168. Thanks and regards, Mike Heard From nobody Mon Apr 17 10:45:14 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B5A1316FF; Mon, 17 Apr 2017 10:44:50 -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=OEL0cik0; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=ooWZq514 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 B7PiCUKOTR0L; Mon, 17 Apr 2017 10:44:48 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 39896131713; Mon, 17 Apr 2017 10:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1492451085; x=1523987085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uYWI23RK3DpCBDjflwXGY2aOi+55N8MO7BJZbWrSclM=; b=OEL0cik0sdi2hyjmPWm6Dk1rzDpq4frcZydeBEobOUZzJJU9pheRY2W2 cjNMQXx7UHOGa1UGrbnNoKJaN2M0hYf5ZF+Z3Wju7Lg8JoF8ahU6w+EWi n20M2JObg7WJ07R5G2IsvTWo6/hffWW7cfEHebzpBna3Gf4wlGrO3la7i 8=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2017 12:44:44 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2017 23:44:43 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3HHibst028986 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Apr 2017 13:44:42 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v3HHibst028986 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1492451082; bh=eDfEiRSzraZ+wDE7pnTumlIlW1Y=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ooWZq514aIRbeWx7h8uyV0TIYYfC4v83ypV95fZaypxUyEQLAsUVK4sBE3ai4OWwX Vp7TshuotovddFh4I3ZH2QuU8eLNk9p0I5r3To/21eDiOPnF5168W4lVT+y6Si9DRc jrmiHQ/NpQu/9yaMACl7r5FTZFdH68vnJKqzePR0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v3HHibst028986 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 17 Apr 2017 13:44:24 -0400 Received: from MXHUB320.corp.emc.com (MXHUB320.corp.emc.com [10.146.3.98]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3HHiMf6030754 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 17 Apr 2017 13:44:23 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB320.corp.emc.com ([10.146.3.98]) with mapi id 14.03.0266.001; Mon, 17 Apr 2017 13:44:22 -0400 To: "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg CC: "draft-ietf-6man-rfc2460bis@ietf.org" , Bob Hinden , "Mirja Kuehlewind (IETF)" , IESG , "6man Chairs" <6man-chairs@ietf.org> Thread-Topic: =?utf-8?B?W3RzdndnXSAgTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi02bWFuLXJmYzI0NjBiaXMtMDk6ICh3aXRoIERJU0NVU1MgYW5kIENP?= =?utf-8?Q?MMENT)?= Thread-Index: AQHSt5O2XmG3ecLMEEGFzIpNOX7b0KHJ0i7Q Date: Mon, 17 Apr 2017 17:44:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:44:51 -0000 RXh0cmFjdGluZyB0aGUga2V5IHBvcnRpb25zIG9mIHRleHQ6DQoNCj4+VGhhdCBpcyBpbmNvbnNp c3RlbnQgd2l0aCB0aGUgZm9sbG93aW5nIGd1aWRhbmNlIGluIFJGQyAzMTY4IChzZWUNCj4+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMxNjgjc2VjdGlvbi01LjMpOg0KPj4NCj4+IDUu My4gIEZyYWdtZW50YXRpb24NCj4+DQo+PiAgIEVDTi1jYXBhYmxlIHBhY2tldHMgTUFZIGhhdmUg dGhlIERGIChEb24ndCBGcmFnbWVudCkgYml0IHNldC4NCj4+ICAgUmVhc3NlbWJseSBvZiBhIGZy YWdtZW50ZWQgcGFja2V0IE1VU1QgTk9UIGxvc2UgaW5kaWNhdGlvbnMgb2YNCj4+ICAgY29uZ2Vz dGlvbi4gIEluIG90aGVyIHdvcmRzLCBpZiBhbnkgZnJhZ21lbnQgb2YgYW4gSVAgcGFja2V0IHRv IGJlDQo+PiAgIHJlYXNzZW1ibGVkIGhhcyB0aGUgQ0UgY29kZXBvaW50IHNldCwgdGhlbiBvbmUg b2YgdHdvIGFjdGlvbnMgTVVTVCBiZQ0KPj4gICB0YWtlbjoNCj4+DQo+PiAgICAgICogU2V0IHRo ZSBDRSBjb2RlcG9pbnQgb24gdGhlIHJlYXNzZW1ibGVkIHBhY2tldC4gIEhvd2V2ZXIsIHRoaXMN Cj4+ICAgICAgICBNVVNUIE5PVCBvY2N1ciBpZiBhbnkgb2YgdGhlIG90aGVyIGZyYWdtZW50cyBj b250cmlidXRpbmcgdG8NCj4+ICAgICAgICB0aGlzIHJlYXNzZW1ibHkgY2FycmllcyB0aGUgTm90 LUVDVCBjb2RlcG9pbnQuDQo+Pg0KPj4gICAgICAqIFRoZSBwYWNrZXQgaXMgZHJvcHBlZCwgaW5z dGVhZCBvZiBiZWluZyByZWFzc2VtYmxlZCwgZm9yIGFueQ0KPj4gICAgICAgIG90aGVyIHJlYXNv bi4NCj4+DQo+PiAgIElmIGJvdGggYWN0aW9ucyBhcmUgYXBwbGljYWJsZSwgZWl0aGVyIE1BWSBi ZSBjaG9zZW4uICBSZWFzc2VtYmx5IG9mDQo+PiAgIGEgZnJhZ21lbnRlZCBwYWNrZXQgTVVTVCBO T1QgY2hhbmdlIHRoZSBFQ04gY29kZXBvaW50IHdoZW4gYWxsIG9mIHRoZQ0KPj4gICBmcmFnbWVu dHMgY2FycnkgdGhlIHNhbWUgY29kZXBvaW50Lg0KDQo+IFJlZ2FyZGxlc3Mgb2YgdGhlIGFuc3dl ciB0byB0aGF0IHF1ZXN0aW9uLCBteSBwb3NpdGlvbiB3b3VsZCBiZSB0aGF0IHNpbmNlDQo+IDI0 NjBiaXMgYWxyZWFkeSBkZWZlcnMgdG8gUkZDIDI0NzQgYW5kIFJGQyAzMTY4IHJlZ2FyZGluZyB0 aGUgaGFuZGxpbmcgb2YNCj4gdGhlIFRyYWZmaWMgQ2xhc3MgZmllbGQsIHRoZSBmb2xsb3dpbmcg bW9kaWZpY2F0aW9uIHRvIDI0NjBiaXMgU2VjdGlvbiA0LjUNCj4gd291bGQgYmUgYW4gYXBwcm9w cmlhdGUgd2F5IHRvIGRlYWwgd2l0aCBNaXJqYSdzIGNvbW1lbnQ6DQo+IA0KPiBPTEQ6DQo+ICAg ICAgIFRoZSBudW1iZXIgYW5kIGNvbnRlbnQgb2YgdGhlIGhlYWRlcnMgcHJlY2VkaW5nIHRoZSBG cmFnbWVudA0KPiAgICAgICBoZWFkZXIgb2YgZGlmZmVyZW50IGZyYWdtZW50cyBvZiB0aGUgc2Ft ZSBvcmlnaW5hbCBwYWNrZXQgbWF5DQo+ICAgICAgIGRpZmZlci4gIFdoYXRldmVyIGhlYWRlcnMg YXJlIHByZXNlbnQsIHByZWNlZGluZyB0aGUgRnJhZ21lbnQNCj4gICAgICAgaGVhZGVyIGluIGVh Y2ggZnJhZ21lbnQgcGFja2V0LCBhcmUgcHJvY2Vzc2VkIHdoZW4gdGhlIHBhY2tldHMNCj4gICAg ICAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWluZyB0aGUgZnJhZ21lbnRzIGZvciByZWFzc2VtYmx5 LiAgT25seQ0KPiAgICAgICB0aG9zZSBoZWFkZXJzIGluIHRoZSBPZmZzZXQgemVybyBmcmFnbWVu dCBwYWNrZXQgYXJlIHJldGFpbmVkIGluDQo+ICAgICAgIHRoZSByZWFzc2VtYmxlZCBwYWNrZXQu DQo+IE5FVzoNCj4gICAgICAgVGhlIG51bWJlciBhbmQgY29udGVudCBvZiB0aGUgaGVhZGVycyBw cmVjZWRpbmcgdGhlIEZyYWdtZW50DQo+ICAgICAgIGhlYWRlciBvZiBkaWZmZXJlbnQgZnJhZ21l bnRzIG9mIHRoZSBzYW1lIG9yaWdpbmFsIHBhY2tldCBtYXkNCj4gICAgICAgZGlmZmVyLiAgV2hh dGV2ZXIgaGVhZGVycyBhcmUgcHJlc2VudCwgcHJlY2VkaW5nIHRoZSBGcmFnbWVudA0KPiAgICAg ICBoZWFkZXIgaW4gZWFjaCBmcmFnbWVudCBwYWNrZXQsIGFyZSBwcm9jZXNzZWQgd2hlbiB0aGUg cGFja2V0cw0KPiAgICAgICBhcnJpdmUsIHByaW9yIHRvIHF1ZXVlaW5nIHRoZSBmcmFnbWVudHMg Zm9yIHJlYXNzZW1ibHkuICBPbmx5DQo+ICAgICAgIHRob3NlIGhlYWRlcnMgaW4gdGhlIE9mZnNl dCB6ZXJvIGZyYWdtZW50IHBhY2tldCBhcmUgcmV0YWluZWQgaW4NCj4gICAgICAgdGhlIHJlYXNz ZW1ibGVkIHBhY2tldDsgaG93ZXZlciwgbm9kZXMgdGhhdCBzdXBwb3J0IEV4cGxpY2l0DQo+ICAg ICAgIENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFtSRkMzMTY4XSBtYXkgdXNlIGluZm9ybWF0aW9u IGluIHRoZQ0KPiAgICAgICBUcmFmZmljIENsYXNzIGZpZWxkIGZyb20gYWxsIGZyYWdtZW50IHBh Y2tldHMgdG8gcmVjb25zdHJ1Y3QgdGhlDQo+ICAgICAgIFRyYWZmaWMgQ2xhc3MgZmllbGQgaW4g dGhlIHJlYXNzZW1ibGVkIHBhY2tldC4NCj4gDQo+IE5vdGUgdGhhdCB0aGlzIHdvdWxkIG5vdCBj YXVzZSAyNDYwYmlzIGl0c2VsZiB0byBsZXZ5IGFuIGFkZGl0aW9uYWwNCj4gcmVxdWlyZW1lbnQg b24gaG93IElQdjYgbm9kZXMgcmVhc3NlbWJsZSBmcmFnbWVudGVkIHBhY2tldHMuIEl0IHdvdWxk DQo+IHNpbXBseSBiZSBtYWtpbmcgbm90ZSBvZiBhIHJlcXVpcmVtZW50IHRoYXQgaXMgYWxyZWFk eSBsZXZpZWQgYnkNCj4gUkZDIDMxNjguDQoNCkluIHdoaWNoIGNhc2UsIHRoZSBSRkMgMzE2OCBy ZXF1aXJlbWVudCBzaG91bGQgYmUgc3RhdGVkIGUuZy46DQoNCk9MRDoNCiAgICAgIFRoZSBudW1i ZXIgYW5kIGNvbnRlbnQgb2YgdGhlIGhlYWRlcnMgcHJlY2VkaW5nIHRoZSBGcmFnbWVudA0KICAg ICAgaGVhZGVyIG9mIGRpZmZlcmVudCBmcmFnbWVudHMgb2YgdGhlIHNhbWUgb3JpZ2luYWwgcGFj a2V0IG1heQ0KICAgICAgZGlmZmVyLiAgV2hhdGV2ZXIgaGVhZGVycyBhcmUgcHJlc2VudCwgcHJl Y2VkaW5nIHRoZSBGcmFnbWVudA0KICAgICAgaGVhZGVyIGluIGVhY2ggZnJhZ21lbnQgcGFja2V0 LCBhcmUgcHJvY2Vzc2VkIHdoZW4gdGhlIHBhY2tldHMNCiAgICAgIGFycml2ZSwgcHJpb3IgdG8g cXVldWVpbmcgdGhlIGZyYWdtZW50cyBmb3IgcmVhc3NlbWJseS4gIE9ubHkNCiAgICAgIHRob3Nl IGhlYWRlcnMgaW4gdGhlIE9mZnNldCB6ZXJvIGZyYWdtZW50IHBhY2tldCBhcmUgcmV0YWluZWQg aW4NCiAgICAgIHRoZSByZWFzc2VtYmxlZCBwYWNrZXQuDQpORVc6DQogICAgICBUaGUgbnVtYmVy IGFuZCBjb250ZW50IG9mIHRoZSBoZWFkZXJzIHByZWNlZGluZyB0aGUgRnJhZ21lbnQNCiAgICAg IGhlYWRlciBvZiBkaWZmZXJlbnQgZnJhZ21lbnRzIG9mIHRoZSBzYW1lIG9yaWdpbmFsIHBhY2tl dCBtYXkNCiAgICAgIGRpZmZlci4gIFdoYXRldmVyIGhlYWRlcnMgYXJlIHByZXNlbnQsIHByZWNl ZGluZyB0aGUgRnJhZ21lbnQNCiAgICAgIGhlYWRlciBpbiBlYWNoIGZyYWdtZW50IHBhY2tldCwg YXJlIHByb2Nlc3NlZCB3aGVuIHRoZSBwYWNrZXRzDQogICAgICBhcnJpdmUsIHByaW9yIHRvIHF1 ZXVlaW5nIHRoZSBmcmFnbWVudHMgZm9yIHJlYXNzZW1ibHkuICBPbmx5DQogICAgICB0aG9zZSBo ZWFkZXJzIGluIHRoZSBPZmZzZXQgemVybyBmcmFnbWVudCBwYWNrZXQgYXJlIHJldGFpbmVkIGlu DQogICAgICB0aGUgcmVhc3NlbWJsZWQgcGFja2V0OyBob3dldmVyLCBub2RlcyB0aGF0IHN1cHBv cnQgRXhwbGljaXQNCiAgICAgIENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFtSRkMzMTY4XSBtYXkg dXNlIGluZm9ybWF0aW9uIGluIHRoZQ0KICAgICAgVHJhZmZpYyBDbGFzcyBmaWVsZCBmcm9tIGFu eSBvciBhbGwgZnJhZ21lbnQgcGFja2V0cyB0byByZWNvbnN0cnVjdA0KICAgICAgdGhlIFRyYWZm aWMgQ2xhc3MgZmllbGQgaW4gdGhlIHJlYXNzZW1ibGVkIHBhY2tldCBpbiBvcmRlciB0byBtZWV0 DQogICAgICBSRkMgMzE2OCdzIHJlcXVpcmVtZW50cywgZS5nLiwgdGhhdCByZWFzc2VtYmx5IG5v dCBsb3NlIGluZGljYXRpb25zDQogICAgICBvZiBjb25nZXN0aW9uLCBzZWUgU2VjdGlvbiA1LjMg b2YgUkZDIDMxNjggZm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uDQoNClBvaW50aW5nIHRoZSBp bXBsZW1lbnRlciBhdCBTZWN0aW9uIDUuMyBvZiBSRkMgMzE2OCBpcyBiZXR0ZXIgdGhhbg0KaG9w aW5nIHNoZSBmaWd1cmVzIG91dCBvbiBoZXIgb3duIHRoYXQgc2hlIG91Z2h0IHRvIHRha2UgYSBs b29rIGF0IGl0IC4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQy4gTS4gSGVhcmQNCj4gU2VudDogTW9uZGF5LCBBcHJpbCAxNywgMjAxNyAxMjow MCBQTQ0KPiBUbzogNk1BTiA8Nm1hbkBpZXRmLm9yZz47IHRzdndnIDx0c3Z3Z0BpZXRmLm9yZz4N Cj4gQ2M6IGRyYWZ0LWlldGYtNm1hbi1yZmMyNDYwYmlzQGlldGYub3JnOyBCb2IgSGluZGVuDQo+ IDxib2IuaGluZGVuQGdtYWlsLmNvbT47IE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpIDxpZXRmQGt1 ZWhsZXdpbmQubmV0PjsNCj4gSUVTRyA8aWVzZ0BpZXRmLm9yZz47IDZtYW4gQ2hhaXJzIDw2bWFu LWNoYWlyc0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFt0c3Z3Z10gTWlyamEgS8O8aGxld2lu ZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi02bWFuLXJmYzI0NjBiaXMtDQo+IDA5OiAod2l0aCBE SVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gWyBUU1ZXRyBhZGRlZCB0byBzb2xpY2l0IGFkdmlj ZSBvbiBpbXBsZW1lbnRhdGlvbiBvZiBSRkMgMzE4NiBTZWN0aW9uIDUuMyBdDQo+IA0KPiBPbiBT YXQsIEFwciAxNSwgMjAxNyBhdCAxMTo1MCBBTSwgQm9iIEhpbmRlbiB3cm90ZToNCj4gPiBPbiBB cHIgMTUsIDIwMTcsIGF0IDQ6NTMgQU0sIEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20+IHdy b3RlOg0KPiA+PiBPbiBGcmksIDE0IEFwciAyMDE3IDE0OjI4OjQ0ICsxMjAwIEJyaWFuIEUgQ2Fy cGVudGVyIHdyb3RlOg0KPiA+Pj4gT24gMTMvMDQvMjAxNyAyMzozNiwgTWlyamEgS3VlaGxld2lu ZCAoSUVURikgd3JvdGU6DQo+ID4+PiAuLi4NCj4gPj4+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ Pj4+Pj4+PiBDT01NRU5UOg0KPiA+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+IE9uZSBxdWVzdGlvbiBiZWNhdXNlIEknbSBub3Qgc3VyZSBpZiBJIGludGVycHJl dCB0aGlzIGNvcnJlY3QgdG8NCj4gbWFrZSBpdA0KPiA+Pj4+Pj4+PiBwYXJ0IG9mIG15IGRpc2N1 c3M6DQo+ID4+Pj4+Pj4+IFNlY3Rpb24gNC41OiAiVGhlIG51bWJlciBhbmQgY29udGVudCBvZiB0 aGUgaGVhZGVycyBwcmVjZWRpbmcNCj4gdGhlDQo+ID4+Pj4+Pj4+IEZyYWdtZW50DQo+ID4+Pj4+ Pj4+ICBoZWFkZXIgb2YgZGlmZmVyZW50IGZyYWdtZW50cyBvZiB0aGUgc2FtZSBvcmlnaW5hbCBw YWNrZXQgbWF5DQo+ID4+Pj4+Pj4+ICBkaWZmZXIuICBXaGF0ZXZlciBoZWFkZXJzIGFyZSBwcmVz ZW50LCBwcmVjZWRpbmcgdGhlIEZyYWdtZW50DQo+ID4+Pj4+Pj4+ICBoZWFkZXIgaW4gZWFjaCBm cmFnbWVudCBwYWNrZXQsIGFyZSBwcm9jZXNzZWQgd2hlbiB0aGUgcGFja2V0cw0KPiA+Pj4+Pj4+ PiAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWluZyB0aGUgZnJhZ21lbnRzIGZvciByZWFzc2VtYmx5 LiAgT25seQ0KPiA+Pj4+Pj4+PiAgdGhvc2UgaGVhZGVycyBpbiB0aGUgT2Zmc2V0IHplcm8gZnJh Z21lbnQgcGFja2V0IGFyZSByZXRhaW5lZCBpbg0KPiA+Pj4+Pj4+PiAgdGhlIHJlYXNzZW1ibGVk IHBhY2tldC4iDQo+ID4+Pj4+Pj4+IERvZXMgdGhpcyBtZWFuIHRoZSBFQ04gY29kZXBvaW50IChw YXJ0IG9mIHRoZSBUcmFmZmljIENsYXNzIGZpZWxkKQ0KPiBpcw0KPiA+Pj4+Pj4+PiBjb3BpZWQg ZnJvbSB0aGUgZmlyc3QgZnJhZ21lbnQ/IFRoaXMgZG9lc24ndCBzZWVtIHRvIGJlIGNvcnJlY3Qs DQo+IGhvd2V2ZXIsDQo+ID4+Pj4+Pj4+IGFsc28gbm90IHN1cmUgd2hhdCB0aGUgY29ycmVjdCBh bnN3ZXIgaXMuIEkga25vdyB0aGlzIHdhcyBub3QNCj4gY2hhbmdlZCBpbg0KPiA+Pj4+Pj4+PiB0 aGlzIHJldmlzaW9uIGJ1dCBtYXliZSB3ZSBjYW4gc3RpbGwgZ2V0IHRoaXMgcmlnaHQuDQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+PiBXaGVuIGZyYWdtZW50cyBhcmUgY3JlYXRlZCBtb3N0IG9mIHRoZSBm aWVsZHMgYXJlIGNvcGllZCBmcm9tIHRoZQ0KPiBJUHY2DQo+ID4+Pj4+Pj4gaGVhZGVycyAoZS5n LiwgU291cmNlIEFkZHJlc3MsIERlc3RpbmF0aW9uIGFkZHJlc3MsIGZsb3cgbGFiZWwsDQo+IHRy YWZmaWMNCj4gPj4+Pj4+PiBjbGFzcywgaG9wIGxpbWl0KS4gIFNvbWUgbGlrZSBwYXlsb2FkIGxl bmd0aCwgbmV4dCBoZWFkZXIsIGFuZCBob3ANCj4gbGltaQ0KPiA+Pj4+Pj4+IHQgYXJlIG1vZGlm aWVkLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSWYgSSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24s IHRoZSBhbnN3ZXIgaXMgeWVzLCB0aGUgRUNOIGNvZGUNCj4gcG9pbnQgaXMNCj4gPj4+Pj4+PiBj b3BpZWQgZnJvbSB0aGUgZmlyc3QgZnJhZ21lbnQsIGJ1dCBzaG91bGQgYmUgdGhlIHNhbWUgZnJv bSBhbGwgb2YNCj4gdGhlDQo+ID4+Pj4+Pj4gZnJhZ21lbnRzLg0KPiA+Pg0KPiA+PiBUaGF0IGlz IGluY29uc2lzdGVudCB3aXRoIHRoZSBmb2xsb3dpbmcgZ3VpZGFuY2UgaW4gUkZDIDMxNjggKHNl ZQ0KPiA+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzE2OCNzZWN0aW9uLTUuMyk6 DQo+ID4+DQo+ID4+IDUuMy4gIEZyYWdtZW50YXRpb24NCj4gPj4NCj4gPj4gICBFQ04tY2FwYWJs ZSBwYWNrZXRzIE1BWSBoYXZlIHRoZSBERiAoRG9uJ3QgRnJhZ21lbnQpIGJpdCBzZXQuDQo+ID4+ ICAgUmVhc3NlbWJseSBvZiBhIGZyYWdtZW50ZWQgcGFja2V0IE1VU1QgTk9UIGxvc2UgaW5kaWNh dGlvbnMgb2YNCj4gPj4gICBjb25nZXN0aW9uLiAgSW4gb3RoZXIgd29yZHMsIGlmIGFueSBmcmFn bWVudCBvZiBhbiBJUCBwYWNrZXQgdG8gYmUNCj4gPj4gICByZWFzc2VtYmxlZCBoYXMgdGhlIENF IGNvZGVwb2ludCBzZXQsIHRoZW4gb25lIG9mIHR3byBhY3Rpb25zIE1VU1QgYmUNCj4gPj4gICB0 YWtlbjoNCj4gPj4NCj4gPj4gICAgICAqIFNldCB0aGUgQ0UgY29kZXBvaW50IG9uIHRoZSByZWFz c2VtYmxlZCBwYWNrZXQuICBIb3dldmVyLCB0aGlzDQo+ID4+ICAgICAgICBNVVNUIE5PVCBvY2N1 ciBpZiBhbnkgb2YgdGhlIG90aGVyIGZyYWdtZW50cyBjb250cmlidXRpbmcgdG8NCj4gPj4gICAg ICAgIHRoaXMgcmVhc3NlbWJseSBjYXJyaWVzIHRoZSBOb3QtRUNUIGNvZGVwb2ludC4NCj4gPj4N Cj4gPj4gICAgICAqIFRoZSBwYWNrZXQgaXMgZHJvcHBlZCwgaW5zdGVhZCBvZiBiZWluZyByZWFz c2VtYmxlZCwgZm9yIGFueQ0KPiA+PiAgICAgICAgb3RoZXIgcmVhc29uLg0KPiA+Pg0KPiA+PiAg IElmIGJvdGggYWN0aW9ucyBhcmUgYXBwbGljYWJsZSwgZWl0aGVyIE1BWSBiZSBjaG9zZW4uICBS ZWFzc2VtYmx5IG9mDQo+ID4+ICAgYSBmcmFnbWVudGVkIHBhY2tldCBNVVNUIE5PVCBjaGFuZ2Ug dGhlIEVDTiBjb2RlcG9pbnQgd2hlbiBhbGwgb2YNCj4gdGhlDQo+ID4+ICAgZnJhZ21lbnRzIGNh cnJ5IHRoZSBzYW1lIGNvZGVwb2ludC4NCj4gPj4NCj4gPj4+Pj4+IE15IGNvbmNlcm4gaXMgdGhh dCB0aGUgRUNOIGNvZGUgcG9pbnQgY291bGQgYmUgY2hhbmdlZCBvbiBvbmUgb2YNCj4gdGhlDQo+ ID4+Pj4+PiBmcmFnbWVudGVkIHBhY2tldHMgdG8gc2lnbmFsIGNvbmdlc3Rpb24gb2YgYSBpbnRl cm1lZGlhdGUgbm9kZSBhbmQNCj4gPj4+Pj4+IHRoZW4gd2hlbiB5b3UgcmVhc3NlbWJsZSB0aGlz IGluZm9ybWF0aW9uIGdldHMgbG9zdC4gVGhhdCBzZWVtcw0KPiB3cm9uZy4NCj4gPj4+Pj4NCj4g Pj4+Pj4gVGhhdCBpcyBhbiBpbnRlcmVzdGluZyBpZGVhLCBidXQgSSB0aGluayBvdXQgb2Ygc2Nv cGUgZm9yIGFkdmFuY2luZyB0aGlzDQo+ID4+Pj4+IGRvY3VtZW50IHRvIEludGVybmV0IFN0YW5k YXJkLiAgVGhlbiB0aGVyZSBpcyB0aGUgcXVlc3Rpb24gb2YgaG93IHRvDQo+ID4+Pj4+IGVuY29k ZSBuIG9mIG0gZnJhZ21lbnRzIGV4cGVyaWVuY2VkIGNvbmdlc3Rpb24uICBJbnRlcmVzdGluZyBm dXR1cmUNCj4gd29yay4NCj4gPj4+Pg0KPiA+Pj4+IFllcyB0aGVyZSBtaWdodCBiZSBzb21lIG1v cmUgZnVydGhlciB3b3JrIG5lZWRlZCBidXQgdGhhdCBzdGlsbA0KPiBtYWtlcyB0aGUNCj4gPj4+ PiBndWlkYW5jZSBpbiB0aGlzIHRleHQgd3JvbmcuIE1heWJlIHdlIGNhbiBhZGQgc29tZSB0ZXh0 IHRoYXQgdGhlDQo+IFRyYWZmaWMNCj4gPj4+PiBDbGFzcyBtYXkgYmUgaGFuZGxlZCBkaWZmZXJl bnRseSBiZWNhdXNlIGl0IGNvdWxkIGJlIGNoYW5nZWQgb24gdGhlDQo+IHBhdGguDQo+ID4+Pg0K PiA+Pj4gR29vZCBwb2ludC4gSXQncyBub3Qgb25seSBFQ04gdGhhdCBjYW4gY2hhbmdlOyB0aGUg RFNDUCBjYW4gY2hhbmdlIHRvby4NCj4gPj4+IEJvdGggUkZDMjQ3NCAoZGlmZnNlcnYpIGFuZCBF Q04gY2FtZSBhZnRlciBSRkMyNDYwLCBzbyBpdCdzIGxvZ2ljYWwNCj4gPj4+IGZvciAyNDYwYmlz IHRvIG5vdGUgdGhpcyBpc3N1ZS4NCj4gPj4NCj4gPj4gSXQgc2VlbXMgdGhhdCB3ZSAoNm1hbiBX RykgbWlzc2VkIHRoaXMgYmVjYXVzZSBSRkMgMzE2OCB3YXMgbm90DQo+IG1hcmtlZA0KPiA+PiBh cyB1cGRhdGluZyBSRkMgMjQ2MC4gQnV0IGluIGVmZmVjdCBpdCBkaWQgc28gZm9yIElQdjYgaW1w bGVtZW50YXRpb25zDQo+ID4+IG9mIEVDTiwgZXZlbiB0aG91Z2ggaXQgd2FzIG5vdCB3cml0dGVu IGluIGFuIElQIHZlcnNpb24tYWdub3N0aWMgbWFubmVyLg0KPiA+Pg0KPiA+PiBBdCB0aGUgdmVy eSBsZWFzdCB0ZXh0IHNob3VsZCBiZSBhZGRlZCB0byB0aGUgZGVzY3JpcHRpb24gb2YgdGhlDQo+ ID4+IHJlYXNzZW1ibHkgcHJvY2VzcyB0aGF0IHBvaW50cyB0aGUgcmVhZGVyIHRvIFJGQyAzMTY4 IG9yIGl0cw0KPiA+PiBzdWNjZXNzb3IgZG9jdW1lbnQuDQo+ID4NCj4gPiBEbyB3ZSBoYXZlIGFu eSBldmlkZW5jZSB0aGF0IHRoZSBndWlkYW5jZSBpbiBSRkMgMzE2OCByZWdhcmRpbmcNCj4gcmVh c3NlbWJsaW5nDQo+ID4gSVB2NiBmcmFnbWVudHMgaXMgaW1wbGVtZW50ZWQ/ICBJIGRvbuKAmXQg a25vdywgYnV0IHRoaW5rIGlmIGl0IHRoZXJlIGlzDQo+ID4gZXZpZGVuY2UgSSBhZ3JlZSBzb21l IHRleHQgc2hvdWxkIGJlIGFkZGVkIHRvIHJmYzI0NjBiaXMsIGlmIG5vdCwgdGhlbg0KPiA+IG1h eWJlIG5vdC4NCj4gDQo+IFNpbmNlIEkgbGFjayB0aGUgZXhwZXJ0aXNlIHRvIGFuc3dlciB0aGF0 IHF1ZXN0aW9uLCBJJ20gaG9waW5nIHRoYXQgc29tZW9uZQ0KPiBpbiBUU1ZXRyB3aWxsIHNlZSB0 aGlzIG1lc3NhZ2UgYW5kIGRvIHNvLg0KPiANCj4gUmVnYXJkbGVzcyBvZiB0aGUgYW5zd2VyIHRv IHRoYXQgcXVlc3Rpb24sIG15IHBvc2l0aW9uIHdvdWxkIGJlIHRoYXQgc2luY2UNCj4gMjQ2MGJp cyBhbHJlYWR5IGRlZmVycyB0byBSRkMgMjQ3NCBhbmQgUkZDIDMxNjggcmVnYXJkaW5nIHRoZSBo YW5kbGluZyBvZg0KPiB0aGUgVHJhZmZpYyBDbGFzcyBmaWVsZCwgdGhlIGZvbGxvd2luZyBtb2Rp ZmljYXRpb24gdG8gMjQ2MGJpcyBTZWN0aW9uIDQuNQ0KPiB3b3VsZCBiZSBhbiBhcHByb3ByaWF0 ZSB3YXkgdG8gZGVhbCB3aXRoIE1pcmphJ3MgY29tbWVudDoNCj4gDQo+IE9MRDoNCj4gICAgICAg VGhlIG51bWJlciBhbmQgY29udGVudCBvZiB0aGUgaGVhZGVycyBwcmVjZWRpbmcgdGhlIEZyYWdt ZW50DQo+ICAgICAgIGhlYWRlciBvZiBkaWZmZXJlbnQgZnJhZ21lbnRzIG9mIHRoZSBzYW1lIG9y aWdpbmFsIHBhY2tldCBtYXkNCj4gICAgICAgZGlmZmVyLiAgV2hhdGV2ZXIgaGVhZGVycyBhcmUg cHJlc2VudCwgcHJlY2VkaW5nIHRoZSBGcmFnbWVudA0KPiAgICAgICBoZWFkZXIgaW4gZWFjaCBm cmFnbWVudCBwYWNrZXQsIGFyZSBwcm9jZXNzZWQgd2hlbiB0aGUgcGFja2V0cw0KPiAgICAgICBh cnJpdmUsIHByaW9yIHRvIHF1ZXVlaW5nIHRoZSBmcmFnbWVudHMgZm9yIHJlYXNzZW1ibHkuICBP bmx5DQo+ICAgICAgIHRob3NlIGhlYWRlcnMgaW4gdGhlIE9mZnNldCB6ZXJvIGZyYWdtZW50IHBh Y2tldCBhcmUgcmV0YWluZWQgaW4NCj4gICAgICAgdGhlIHJlYXNzZW1ibGVkIHBhY2tldC4NCj4g TkVXOg0KPiAgICAgICBUaGUgbnVtYmVyIGFuZCBjb250ZW50IG9mIHRoZSBoZWFkZXJzIHByZWNl ZGluZyB0aGUgRnJhZ21lbnQNCj4gICAgICAgaGVhZGVyIG9mIGRpZmZlcmVudCBmcmFnbWVudHMg b2YgdGhlIHNhbWUgb3JpZ2luYWwgcGFja2V0IG1heQ0KPiAgICAgICBkaWZmZXIuICBXaGF0ZXZl ciBoZWFkZXJzIGFyZSBwcmVzZW50LCBwcmVjZWRpbmcgdGhlIEZyYWdtZW50DQo+ICAgICAgIGhl YWRlciBpbiBlYWNoIGZyYWdtZW50IHBhY2tldCwgYXJlIHByb2Nlc3NlZCB3aGVuIHRoZSBwYWNr ZXRzDQo+ICAgICAgIGFycml2ZSwgcHJpb3IgdG8gcXVldWVpbmcgdGhlIGZyYWdtZW50cyBmb3Ig cmVhc3NlbWJseS4gIE9ubHkNCj4gICAgICAgdGhvc2UgaGVhZGVycyBpbiB0aGUgT2Zmc2V0IHpl cm8gZnJhZ21lbnQgcGFja2V0IGFyZSByZXRhaW5lZCBpbg0KPiAgICAgICB0aGUgcmVhc3NlbWJs ZWQgcGFja2V0OyBob3dldmVyLCBub2RlcyB0aGF0IHN1cHBvcnQgRXhwbGljaXQNCj4gICAgICAg Q29uZ2VzdGlvbiBOb3RpZmljYXRpb24gW1JGQzMxNjhdIG1heSB1c2UgaW5mb3JtYXRpb24gaW4g dGhlDQo+ICAgICAgIFRyYWZmaWMgQ2xhc3MgZmllbGQgZnJvbSBhbGwgZnJhZ21lbnQgcGFja2V0 cyB0byByZWNvbnN0cnVjdCB0aGUNCj4gICAgICAgVHJhZmZpYyBDbGFzcyBmaWVsZCBpbiB0aGUg cmVhc3NlbWJsZWQgcGFja2V0Lg0KPiANCj4gTm90ZSB0aGF0IHRoaXMgd291bGQgbm90IGNhdXNl IDI0NjBiaXMgaXRzZWxmIHRvIGxldnkgYW4gYWRkaXRpb25hbA0KPiByZXF1aXJlbWVudCBvbiBo b3cgSVB2NiBub2RlcyByZWFzc2VtYmxlIGZyYWdtZW50ZWQgcGFja2V0cy4gSXQgd291bGQNCj4g c2ltcGx5IGJlIG1ha2luZyBub3RlIG9mIGEgcmVxdWlyZW1lbnQgdGhhdCBpcyBhbHJlYWR5IGxl dmllZCBieQ0KPiBSRkMgMzE2OC4NCj4gDQo+IFRoYW5rcyBhbmQgcmVnYXJkcywNCj4gDQo+IE1p a2UgSGVhcmQNCg0K From nobody Mon Apr 17 10:56:14 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639BC13172E; Mon, 17 Apr 2017 10:56:03 -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 o4Sfp6imhYcp; Mon, 17 Apr 2017 10:55:59 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB8313172B; Mon, 17 Apr 2017 10:55:59 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 88F531B016FC; Mon, 17 Apr 2017 20:50:58 +0100 (BST) Message-ID: <58F50184.5010408@erg.abdn.ac.uk> Date: Mon, 17 Apr 2017 18:55:16 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "C. M. Heard" CC: 6MAN <6man@ietf.org>, tsvwg , draft-ietf-6man-rfc2460bis@ietf.org, Bob Hinden , "Mirja Kuehlewind (IETF)" , IESG , 6man Chairs <6man-chairs@ietf.org> References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:56:03 -0000 It is good to include text. The offered text seems to step back from the current normative text in RFC3168 (which I think does apply to RFC2460). The key requirement from secton 5.3, is that "Reassembly of a fragmented packet MUST NOT lose indications of congestion." i.e., the network layer does not ignore CE marks in fragments. AT the very least, I think the text needs to explicitly point to that section. Gorry On 17/04/2017, 16:59, C. M. Heard wrote: > [ TSVWG added to solicit advice on implementation of RFC 3186 Section 5.3 ] > > On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>> ... >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> COMMENT: >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> One question because I'm not sure if I interpret this correct to make it >>>>>>>>> part of my discuss: >>>>>>>>> Section 4.5: "The number and content of the headers preceding the >>>>>>>>> Fragment >>>>>>>>> header of different fragments of the same original packet may >>>>>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>>>>> header in each fragment packet, are processed when the packets >>>>>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>>>>> those headers in the Offset zero fragment packet are retained in >>>>>>>>> the reassembled packet." >>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class field) is >>>>>>>>> copied from the first fragment? This doesn't seem to be correct, however, >>>>>>>>> also not sure what the correct answer is. I know this was not changed in >>>>>>>>> this revision but maybe we can still get this right. >>>>>>>> When fragments are created most of the fields are copied from the IPv6 >>>>>>>> headers (e.g., Source Address, Destination address, flow label, traffic >>>>>>>> class, hop limit). Some like payload length, next header, and hop limi >>>>>>>> t are modified. >>>>>>>> >>>>>>>> If I understand your question, the answer is yes, the ECN code point is >>>>>>>> copied from the first fragment, but should be the same from all of the >>>>>>>> fragments. >>> That is inconsistent with the following guidance in RFC 3168 (see >>> https://tools.ietf.org/html/rfc3168#section-5.3): >>> >>> 5.3. Fragmentation >>> >>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>> Reassembly of a fragmented packet MUST NOT lose indications of >>> congestion. In other words, if any fragment of an IP packet to be >>> reassembled has the CE codepoint set, then one of two actions MUST be >>> taken: >>> >>> * Set the CE codepoint on the reassembled packet. However, this >>> MUST NOT occur if any of the other fragments contributing to >>> this reassembly carries the Not-ECT codepoint. >>> >>> * The packet is dropped, instead of being reassembled, for any >>> other reason. >>> >>> If both actions are applicable, either MAY be chosen. Reassembly of >>> a fragmented packet MUST NOT change the ECN codepoint when all of the >>> fragments carry the same codepoint. >>> >>>>>>> My concern is that the ECN code point could be changed on one of the >>>>>>> fragmented packets to signal congestion of a intermediate node and >>>>>>> then when you reassemble this information gets lost. That seems wrong. >>>>>> That is an interesting idea, but I think out of scope for advancing this >>>>>> document to Internet Standard. Then there is the question of how to >>>>>> encode n of m fragments experienced congestion. Interesting future work. >>>>> Yes there might be some more further work needed but that still makes the >>>>> guidance in this text wrong. Maybe we can add some text that the Traffic >>>>> Class may be handled differently because it could be changed on the path. >>>> Good point. It's not only ECN that can change; the DSCP can change too. >>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical >>>> for 2460bis to note this issue. >>> It seems that we (6man WG) missed this because RFC 3168 was not marked >>> as updating RFC 2460. But in effect it did so for IPv6 implementations >>> of ECN, even though it was not written in an IP version-agnostic manner. >>> >>> At the very least text should be added to the description of the >>> reassembly process that points the reader to RFC 3168 or its >>> successor document. >> Do we have any evidence that the guidance in RFC 3168 regarding reassembling >> IPv6 fragments is implemented? I don’t know, but think if it there is >> evidence I agree some text should be added to rfc2460bis, if not, then >> maybe not. > Since I lack the expertise to answer that question, I'm hoping that someone > in TSVWG will see this message and do so. > > Regardless of the answer to that question, my position would be that since > 2460bis already defers to RFC 2474 and RFC 3168 regarding the handling of > the Traffic Class field, the following modification to 2460bis Section 4.5 > would be an appropriate way to deal with Mirja's comment: > > OLD: > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet. > NEW: > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet; however, nodes that support Explicit > Congestion Notification [RFC3168] may use information in the > Traffic Class field from all fragment packets to reconstruct the > Traffic Class field in the reassembled packet. > > Note that this would not cause 2460bis itself to levy an additional > requirement on how IPv6 nodes reassemble fragmented packets. It would > simply be making note of a requirement that is already levied by > RFC 3168. > > Thanks and regards, > > Mike Heard From nobody Mon Apr 17 12:12:37 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00366131770 for ; Mon, 17 Apr 2017 12:12:36 -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 fw0mETNFRdm7 for ; Mon, 17 Apr 2017 12:12:34 -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 6484C1315AE for ; Mon, 17 Apr 2017 12:12:34 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3HJBpV3011540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Apr 2017 12:11:51 -0700 (PDT) To: gorry@erg.abdn.ac.uk References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> Cc: tsvwg From: Joe Touch Message-ID: Date: Mon, 17 Apr 2017 12:11:51 -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: <58F48403.8080302@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3HJBpV3011540 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 19:12:36 -0000 FYI - draft 08 has just been uploaded to address this issue in the security considerations section. I would like to ask that the chairs to ask the WG to consider adopting this as a standards track doc. Joe A new version of I-D, draft-touch-tsvwg-udp-options-08.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 08 Title: Transport Options for UDP Document date: 2017-04-17 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-08.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-08 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-08 On 4/17/2017 1:59 AM, Gorry Fairhurst wrote: > Thanks Joe, > > That seems to be exactly the question the WG asked to explore. I agree > your next update should add a small susbsection on how DTLS should be > handled. > > Gorry > > On 15/04/2017, 00:56, Joe Touch wrote: >> Hi, all, >> >> Christian Huitema a question about the interaction between DTLS and UDP >> options during my remote presentation at IETF 98. >> >> I took a closer look and consulted with Eric Rescorla (DTLS author). He >> and I agreed as follows: >> - DTLS would currently not cover UDP options; DTLS protects only the UDP >> payload >> - the situation is analogous to TCP options, which are not covered by >> TLS >> I.e., both TLS and DTLS are transport *payload* security only, despite >> their names. >> >> Christian noted that this may be a reason QUIC prefers UDP (to avoid the >> need to protection transport options), however QUIC does not (and >> cannot) deprecate UDP payloads that are smaller than the IP payload. >> That would require a change to RFC 768. >> >> I'll add a clarification on this point to the next rev of the UDP >> options document. >> >> Joe From nobody Mon Apr 17 12:58:25 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E6A129416; Mon, 17 Apr 2017 12:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3f-1jPuRwEDb; Mon, 17 Apr 2017 12:58:20 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 489B61200FC; Mon, 17 Apr 2017 12:58:20 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id a188so26788323pfa.2; Mon, 17 Apr 2017 12:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Z/2p11JWnzMFIVSteRg8QXbvfOGOrrueYLEgDbqfWH8=; b=l+3P7tPsxgc6k7xLuTGCEEEP9ZrK/Xhi0puMHTQIcp0r+1AXc4/kzAPyMDq/0Vczzj UT0TbD0ZAjxaB2FZbgk23P6R7veryTNnzH1tTJKgDP0h7wdJ4go2G37894BCCGsbPF0m AWcTrCCEa1tFPR8KMcl8y+k9MagSHlgH1hrDDh51gfYCYxqHpZ+fUVObogk6N8vcEXle L8E915/FvrC7AkbqYCHatrzld2VSqQCtKtaHv/OPzIIwXiCvAOKP+gc1AwIHMn2AroP1 M1xtpUe5WIz+CR66Pya0K90QWIAhDv5j9hrJHXZKAD6cIi9UYr3bYUcMfQuClrx7eX58 6sVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Z/2p11JWnzMFIVSteRg8QXbvfOGOrrueYLEgDbqfWH8=; b=fpUQocJOcUJ9sPbHTTgItevKUWUYtJ5c/C0+wYrFVzPrwpgvpGAk2PT3Jua6t1z4IE G/vsWq/wzSttchH/TEcEAD7Rv5LfvMSr4z8ZOQ2TrvgxjK6tI+otlLFmbbGdfXeDetTV JRtsgcDg6sf2noSi6dEYWTxEqeBW2YXlmEL+XCa7S2lZS4eEhD1uLhJHOC8ElnBMOK3a RBCHCUMBYBLX03pGmMswUU4AUCbw9lI5cU4x87o9ye8VqkRNrI1twoqMhURmU+TANBAA gzCapEKxhFisnx/5FG+GXlji3vaBM2hO+Nxp7QhShD44Kxg2vWMqt1qjuyckFNVP00Ca LGYg== X-Gm-Message-State: AN3rC/4AqSnkiZgUm195a70sAyz1A/I9gmyY/IsMTIu+edtFzzGsAAy6 4TtAbNE7yic6bF8SlQw= X-Received: by 10.98.12.72 with SMTP id u69mr13534924pfi.47.1492459099557; Mon, 17 Apr 2017 12:58:19 -0700 (PDT) Received: from ?IPv6:2406:e001:3f9b:1:28cc:dc4c:9703:6781? ([2406:e001:3f9b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f5sm19637763pgn.50.2017.04.17.12.58.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 12:58:18 -0700 (PDT) To: "Black, David" , "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg References: Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , "Mirja Kuehlewind (IETF)" , Bob Hinden , IESG , 6man Chairs <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> Date: Tue, 18 Apr 2017 07:58:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 19:58:23 -0000 In line... On 18/04/2017 05:44, Black, David wrote: > Extracting the key portions of text: >=20 >>> That is inconsistent with the following guidance in RFC 3168 (see >>> https://tools.ietf.org/html/rfc3168#section-5.3): >>> >>> 5.3. Fragmentation >>> >>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>> Reassembly of a fragmented packet MUST NOT lose indications of >>> congestion. In other words, if any fragment of an IP packet to be >>> reassembled has the CE codepoint set, then one of two actions MUST = be >>> taken: >>> >>> * Set the CE codepoint on the reassembled packet. However, this= >>> MUST NOT occur if any of the other fragments contributing to >>> this reassembly carries the Not-ECT codepoint. >>> >>> * The packet is dropped, instead of being reassembled, for any >>> other reason. >>> >>> If both actions are applicable, either MAY be chosen. Reassembly o= f >>> a fragmented packet MUST NOT change the ECN codepoint when all of t= he >>> fragments carry the same codepoint. >=20 >> Regardless of the answer to that question, my position would be that s= ince >> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handling= of >> the Traffic Class field, the following modification to 2460bis Section= 4.5 >> would be an appropriate way to deal with Mirja's comment: >> >> OLD: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in= >> the reassembled packet. >> NEW: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in= >> the reassembled packet; however, nodes that support Explicit >> Congestion Notification [RFC3168] may use information in the >> Traffic Class field from all fragment packets to reconstruct the= >> Traffic Class field in the reassembled packet. >> >> Note that this would not cause 2460bis itself to levy an additional >> requirement on how IPv6 nodes reassemble fragmented packets. It would >> simply be making note of a requirement that is already levied by >> RFC 3168. >=20 > In which case, the RFC 3168 requirement should be stated e.g.: >=20 > OLD: > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet. > NEW: > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet; however, nodes that support Explicit > Congestion Notification [RFC3168] may use information in the > Traffic Class field from any or all fragment packets to reconstru= ct > the Traffic Class field in the reassembled packet in order to mee= t > RFC 3168's requirements, e.g., that reassembly not lose indicatio= ns > of congestion, see Section 5.3 of RFC 3168 for additional informa= tion. >=20 > Pointing the implementer at Section 5.3 of RFC 3168 is better than > hoping she figures out on her own that she ought to take a look at it .= Yes. This is correct. Brian >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. Heard >> Sent: Monday, April 17, 2017 12:00 PM >> To: 6MAN <6man@ietf.org>; tsvwg >> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden >> ; Mirja Kuehlewind (IETF) ;= >> IESG ; 6man Chairs <6man-chairs@ietf.org> >> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on draft-ietf-6man= -rfc2460bis- >> 09: (with DISCUSS and COMMENT) >> >> [ TSVWG added to solicit advice on implementation of RFC 3186 Section = 5.3 ] >> >> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >>> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>>> ... >>>>>>>>>> --------------------------------------------------------------= -------- >>>>>>>>>> COMMENT: >>>>>>>>>> --------------------------------------------------------------= -------- >>>>>>>>>> >>>>>>>>>> One question because I'm not sure if I interpret this correct = to >> make it >>>>>>>>>> part of my discuss: >>>>>>>>>> Section 4.5: "The number and content of the headers preceding >> the >>>>>>>>>> Fragment >>>>>>>>>> header of different fragments of the same original packet may= >>>>>>>>>> differ. Whatever headers are present, preceding the Fragment= >>>>>>>>>> header in each fragment packet, are processed when the packet= s >>>>>>>>>> arrive, prior to queueing the fragments for reassembly. Only= >>>>>>>>>> those headers in the Offset zero fragment packet are retained= in >>>>>>>>>> the reassembled packet." >>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class fi= eld) >> is >>>>>>>>>> copied from the first fragment? This doesn't seem to be correc= t, >> however, >>>>>>>>>> also not sure what the correct answer is. I know this was not >> changed in >>>>>>>>>> this revision but maybe we can still get this right. >>>>>>>>> >>>>>>>>> When fragments are created most of the fields are copied from t= he >> IPv6 >>>>>>>>> headers (e.g., Source Address, Destination address, flow label,= >> traffic >>>>>>>>> class, hop limit). Some like payload length, next header, and = hop >> limi >>>>>>>>> t are modified. >>>>>>>>> >>>>>>>>> If I understand your question, the answer is yes, the ECN code >> point is >>>>>>>>> copied from the first fragment, but should be the same from all= of >> the >>>>>>>>> fragments. >>>> >>>> That is inconsistent with the following guidance in RFC 3168 (see >>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>> >>>> 5.3. Fragmentation >>>> >>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>> congestion. In other words, if any fragment of an IP packet to be= >>>> reassembled has the CE codepoint set, then one of two actions MUST= be >>>> taken: >>>> >>>> * Set the CE codepoint on the reassembled packet. However, thi= s >>>> MUST NOT occur if any of the other fragments contributing to >>>> this reassembly carries the Not-ECT codepoint. >>>> >>>> * The packet is dropped, instead of being reassembled, for any >>>> other reason. >>>> >>>> If both actions are applicable, either MAY be chosen. Reassembly = of >>>> a fragmented packet MUST NOT change the ECN codepoint when all of >> the >>>> fragments carry the same codepoint. >>>> >>>>>>>> My concern is that the ECN code point could be changed on one of= >> the >>>>>>>> fragmented packets to signal congestion of a intermediate node a= nd >>>>>>>> then when you reassemble this information gets lost. That seems >> wrong. >>>>>>> >>>>>>> That is an interesting idea, but I think out of scope for advanci= ng this >>>>>>> document to Internet Standard. Then there is the question of how= to >>>>>>> encode n of m fragments experienced congestion. Interesting futu= re >> work. >>>>>> >>>>>> Yes there might be some more further work needed but that still >> makes the >>>>>> guidance in this text wrong. Maybe we can add some text that the >> Traffic >>>>>> Class may be handled differently because it could be changed on th= e >> path. >>>>> >>>>> Good point. It's not only ECN that can change; the DSCP can change = too. >>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical= >>>>> for 2460bis to note this issue. >>>> >>>> It seems that we (6man WG) missed this because RFC 3168 was not >> marked >>>> as updating RFC 2460. But in effect it did so for IPv6 implementatio= ns >>>> of ECN, even though it was not written in an IP version-agnostic man= ner. >>>> >>>> At the very least text should be added to the description of the >>>> reassembly process that points the reader to RFC 3168 or its >>>> successor document. >>> >>> Do we have any evidence that the guidance in RFC 3168 regarding >> reassembling >>> IPv6 fragments is implemented? I don=E2=80=99t know, but think if it= there is >>> evidence I agree some text should be added to rfc2460bis, if not, the= n >>> maybe not. >> >> Since I lack the expertise to answer that question, I'm hoping that so= meone >> in TSVWG will see this message and do so. >> >> Regardless of the answer to that question, my position would be that s= ince >> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handling= of >> the Traffic Class field, the following modification to 2460bis Section= 4.5 >> would be an appropriate way to deal with Mirja's comment: >> >> OLD: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in= >> the reassembled packet. >> NEW: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in= >> the reassembled packet; however, nodes that support Explicit >> Congestion Notification [RFC3168] may use information in the >> Traffic Class field from all fragment packets to reconstruct the= >> Traffic Class field in the reassembled packet. >> >> Note that this would not cause 2460bis itself to levy an additional >> requirement on how IPv6 nodes reassemble fragmented packets. It would >> simply be making note of a requirement that is already levied by >> RFC 3168. >> >> Thanks and regards, >> >> Mike Heard >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Mon Apr 17 13:29:33 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B56129462 for ; Mon, 17 Apr 2017 13:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBGD959aRfnO for ; Mon, 17 Apr 2017 13:29:30 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B8F128C82 for ; Mon, 17 Apr 2017 13:29:30 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id f133so114265843qke.2 for ; Mon, 17 Apr 2017 13:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sZ1s4CrxgxYh6iPR/EmOoABcoldrgVs+FVzUSkBaT60=; b=bZmndVb7X4j7j9h1TfFYRNL3L+uj1DfqIJbG1cA93fvB/69C5OxQiym7hJKtV/9Uxv 14B07hekAi41HhzEImoBFmXPnTfPMGk1Dr36Ygo38NxLr8ZogPxAREguLf5c+Sxvyb4u vePGZ4PzHXYeCDt8oujihpNwKW+yFx/ZWCbw1B2hu0FE6kpEFW+gDIlaKJOZZXzy8B+D J68GUFcNNeEK3zXyq7doLZFpP7K3gdzP2TgS0P8G9Gck3zM8Qu4yfR3zlLX9KXfzwqV/ zm8o38xwnq583dYsyvkOjuDQudF0QdWAEFEuhKRSGJ6Cp8RuIfwsB2YcZEXxfdX9dxZM q6LA== 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=sZ1s4CrxgxYh6iPR/EmOoABcoldrgVs+FVzUSkBaT60=; b=ju7j1JYS0TdpnywQ79VJlGLF7OsSlQ5O3D2lhW0xMvnOaBJ8I65CuWt5wgYY2Fy6qk V2jq+BUstw1J2/OAc8/hnOk7LyO6bRxEfSroPw/P3lLMgQAuAGbz9bMGGFcyluRCpYBO X7DA2N2n/GaI4arKv4JCbWwCeWL1+/SRsvedadwd4lJbRtpgXO7xr7jGcwYlVC59uGeZ lngyomKbawCPyxddzp08tvsJDfEq66vUW3LCImE0mliMWXGAT6pWTDmsxKtMd9mOqKQF KNevd7NSMZrE01X9Jh0w6eKPZCqTUOPRJmmYzkazEGfECQYX/k5wf+rrSj7nAx8TP9jQ RCOg== X-Gm-Message-State: AN3rC/6fLQQk1w00mJcbZITDAdw7yzfHDNu7TVF1mBE+qEM7BRpjroIX UZvLPFEmLOUTHdoEqkpUicUIPXG8fg== X-Received: by 10.55.20.145 with SMTP id 17mr9826626qku.244.1492460969139; Mon, 17 Apr 2017 13:29:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 17 Apr 2017 13:29:28 -0700 (PDT) In-Reply-To: References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> From: Tom Herbert Date: Mon, 17 Apr 2017 13:29:28 -0700 Message-ID: To: Joe Touch Cc: "gorry@erg.abdn.ac.uk" , tsvwg Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 20:29:32 -0000 On Mon, Apr 17, 2017 at 12:11 PM, Joe Touch wrote: > FYI - draft 08 has just been uploaded to address this issue in the > security considerations section. > > I would like to ask that the chairs to ask the WG to consider adopting > this as a standards track doc. > Joe, The draft lists intended status as experimental, but above you're asking for adoption for standard track? I would be worried about making this standard if it retroactively defines all cases where IP length is greater than UDP length as now containing UDP options. One thing that might be missing from the draft is middle box handling. I suspect your intent is that options are meant only for end to end consumption and so middleboxes must pass packets with UDP options, should not attempt to parse the UDP options, and must not modify options. Tom > Joe > > A new version of I-D, draft-touch-tsvwg-udp-options-08.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. > > Name: draft-touch-tsvwg-udp-options > Revision: 08 > Title: Transport Options for UDP > Document date: 2017-04-17 > Group: Individual Submission > Pages: 25 > URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-08.txt > Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ > Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-08 > Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-08 > Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-08 > > > On 4/17/2017 1:59 AM, Gorry Fairhurst wrote: >> Thanks Joe, >> >> That seems to be exactly the question the WG asked to explore. I agree >> your next update should add a small susbsection on how DTLS should be >> handled. >> >> Gorry >> >> On 15/04/2017, 00:56, Joe Touch wrote: >>> Hi, all, >>> >>> Christian Huitema a question about the interaction between DTLS and UDP >>> options during my remote presentation at IETF 98. >>> >>> I took a closer look and consulted with Eric Rescorla (DTLS author). He >>> and I agreed as follows: >>> - DTLS would currently not cover UDP options; DTLS protects only the UDP >>> payload >>> - the situation is analogous to TCP options, which are not covered by >>> TLS >>> I.e., both TLS and DTLS are transport *payload* security only, despite >>> their names. >>> >>> Christian noted that this may be a reason QUIC prefers UDP (to avoid the >>> need to protection transport options), however QUIC does not (and >>> cannot) deprecate UDP payloads that are smaller than the IP payload. >>> That would require a change to RFC 768. >>> >>> I'll add a clarification on this point to the next rev of the UDP >>> options document. >>> >>> Joe > From nobody Mon Apr 17 13:35:06 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5419F12945D for ; Mon, 17 Apr 2017 13:35:04 -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 6Y0Njo93FBKB for ; Mon, 17 Apr 2017 13:35:02 -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 6E4BD12785F for ; Mon, 17 Apr 2017 13:35:02 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3HKYJ3v008412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Apr 2017 13:34:20 -0700 (PDT) To: Tom Herbert References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> Cc: "gorry@erg.abdn.ac.uk" , tsvwg From: Joe Touch Message-ID: <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> Date: Mon, 17 Apr 2017 13:34:18 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3HKYJ3v008412 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 20:35:04 -0000 On 4/17/2017 1:29 PM, Tom Herbert wrote: > On Mon, Apr 17, 2017 at 12:11 PM, Joe Touch wrote: >> FYI - draft 08 has just been uploaded to address this issue in the >> security considerations section. >> >> I would like to ask that the chairs to ask the WG to consider adopting >> this as a standards track doc. >> > Joe, > > The draft lists intended status as experimental, but above you're > asking for adoption for standard track? That's correct. > I would be worried about > making this standard if it retroactively defines all cases where IP > length is greater than UDP length as now containing UDP options. It does exactly that, but has checksums to validate when that happens. > > One thing that might be missing from the draft is middle box handling. This is already discussed extensively in the document, including in response to previous TSVWG discussion. That's why we now default to using the OCS and a length validation. Do you have specific concerns? > I suspect your intent is that options are meant only for end to end > consumption That's frankly true of all transport options, not just these in UDP. > and so middleboxes must pass packets with UDP options, > should not attempt to parse the UDP options, and must not modify > options. We already addressed that in the doc. Joe > > Tom > >> Joe >> >> A new version of I-D, draft-touch-tsvwg-udp-options-08.txt >> has been successfully submitted by Joe Touch and posted to the >> IETF repository. >> >> Name: draft-touch-tsvwg-udp-options >> Revision: 08 >> Title: Transport Options for UDP >> Document date: 2017-04-17 >> Group: Individual Submission >> Pages: 25 >> URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-08.txt >> Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ >> Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-08 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-08 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-08 >> >> >> On 4/17/2017 1:59 AM, Gorry Fairhurst wrote: >>> Thanks Joe, >>> >>> That seems to be exactly the question the WG asked to explore. I agree >>> your next update should add a small susbsection on how DTLS should be >>> handled. >>> >>> Gorry >>> >>> On 15/04/2017, 00:56, Joe Touch wrote: >>>> Hi, all, >>>> >>>> Christian Huitema a question about the interaction between DTLS and UDP >>>> options during my remote presentation at IETF 98. >>>> >>>> I took a closer look and consulted with Eric Rescorla (DTLS author). He >>>> and I agreed as follows: >>>> - DTLS would currently not cover UDP options; DTLS protects only the UDP >>>> payload >>>> - the situation is analogous to TCP options, which are not covered by >>>> TLS >>>> I.e., both TLS and DTLS are transport *payload* security only, despite >>>> their names. >>>> >>>> Christian noted that this may be a reason QUIC prefers UDP (to avoid the >>>> need to protection transport options), however QUIC does not (and >>>> cannot) deprecate UDP payloads that are smaller than the IP payload. >>>> That would require a change to RFC 768. >>>> >>>> I'll add a clarification on this point to the next rev of the UDP >>>> options document. >>>> >>>> Joe From nobody Mon Apr 17 13:48:03 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2F3129449 for ; Mon, 17 Apr 2017 13:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lolTsv8tFIdV for ; Mon, 17 Apr 2017 13:48:01 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 00CEB127977 for ; Mon, 17 Apr 2017 13:48:00 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id h67so114776380qke.0 for ; Mon, 17 Apr 2017 13:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GkFaw8jrCrnAuSUbT5LImPRvobS2b07fqm+ArPfDYy0=; b=Bd5SezoBav7SJEKf32CZ7fxgwOXhb70c9IlzqKFhi4hEkhxWu34VQkrJ8fJzkezLkq o67MVSWUUZpNdM6NAu8IfZ7ZvQ86WEFE8XOc3Rd39ONtW3FnPLOrtUvw8AOI89Mrv47p lZwh6ZuCtEGZrx6iRtMOvCE6ksPmlAuAK3lSeAtpfiaFD8BgNsR58FoNhZacGVm33gqI ywdInQiOJdqImteqVXhsjnGsPZuK9ewdg0B7DB+tdtCoXIykY75WCZlOOln2x+oYPZcH X/8HJbVTMWV9K9nmKMpgqw9JAht3/6y/YDHcZ5Js7EF1GjOwW08XtSonNQ/doOM+f+nq xIfQ== 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=GkFaw8jrCrnAuSUbT5LImPRvobS2b07fqm+ArPfDYy0=; b=njwj5vT8hfaaDvt2xY4Ic0bB6eEtEQ7DJNw44GOLmTuGQI6LLFgCYqkVf3xos8KET0 jJHFync5New/uSfVz2zGEZihdQAYS9grbH3sEab08MQnZ/S4hc7286k2sOQ+MnKB1vhg 7DFjuEIfCaQdJ5flMvAuu6FHj1qosXrckhZe9bKhmI5cttD0OnkjzDgbc8an5vi8wnpH 0QmYfSVZapZaYoYTSGaJp0uNDWVHucigOoTVC489u5LY0UT6Id1SR+iSe8i0gS57TvZ1 lhc7R5rQPZgCS+Q35dT2QHfDApH2Abr/tuKPcjk1LxCx5rUulUwUVedYtFJPu+23MUZL zGVw== X-Gm-Message-State: AN3rC/4Lw5IOA+RtTSAcZOzeQCayIs+YgK3qmjSjUQyDNwuOZ/npUZAK 0o2Oe738PHbp3YILck1ufVj/GDyqKg== X-Received: by 10.55.140.65 with SMTP id o62mr10998672qkd.270.1492462080013; Mon, 17 Apr 2017 13:48:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 17 Apr 2017 13:47:59 -0700 (PDT) In-Reply-To: <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> From: Tom Herbert Date: Mon, 17 Apr 2017 13:47:59 -0700 Message-ID: To: Joe Touch Cc: "gorry@erg.abdn.ac.uk" , tsvwg Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 20:48:02 -0000 On Mon, Apr 17, 2017 at 1:34 PM, Joe Touch wrote: > > > On 4/17/2017 1:29 PM, Tom Herbert wrote: >> On Mon, Apr 17, 2017 at 12:11 PM, Joe Touch wrote: >>> FYI - draft 08 has just been uploaded to address this issue in the >>> security considerations section. >>> >>> I would like to ask that the chairs to ask the WG to consider adopting >>> this as a standards track doc. >>> >> Joe, >> >> The draft lists intended status as experimental, but above you're >> asking for adoption for standard track? > > That's correct. > >> I would be worried about >> making this standard if it retroactively defines all cases where IP >> length is greater than UDP length as now containing UDP options. > > It does exactly that, but has checksums to validate when that happens. > >> >> One thing that might be missing from the draft is middle box handling. > This is already discussed extensively in the document, including in > response to previous TSVWG discussion. That's why we now default to > using the OCS and a length validation. Do you have specific concerns? > >> I suspect your intent is that options are meant only for end to end >> consumption > > That's frankly true of all transport options, not just these in UDP. > >> and so middleboxes must pass packets with UDP options, >> should not attempt to parse the UDP options, and must not modify >> options. > We already addressed that in the doc. I'm sorry, which section is this info in? Thanks, Tom > > Joe > >> >> Tom >> >>> Joe >>> >>> A new version of I-D, draft-touch-tsvwg-udp-options-08.txt >>> has been successfully submitted by Joe Touch and posted to the >>> IETF repository. >>> >>> Name: draft-touch-tsvwg-udp-options >>> Revision: 08 >>> Title: Transport Options for UDP >>> Document date: 2017-04-17 >>> Group: Individual Submission >>> Pages: 25 >>> URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-08.txt >>> Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ >>> Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-08 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-08 >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-08 >>> >>> >>> On 4/17/2017 1:59 AM, Gorry Fairhurst wrote: >>>> Thanks Joe, >>>> >>>> That seems to be exactly the question the WG asked to explore. I agree >>>> your next update should add a small susbsection on how DTLS should be >>>> handled. >>>> >>>> Gorry >>>> >>>> On 15/04/2017, 00:56, Joe Touch wrote: >>>>> Hi, all, >>>>> >>>>> Christian Huitema a question about the interaction between DTLS and UDP >>>>> options during my remote presentation at IETF 98. >>>>> >>>>> I took a closer look and consulted with Eric Rescorla (DTLS author). He >>>>> and I agreed as follows: >>>>> - DTLS would currently not cover UDP options; DTLS protects only the UDP >>>>> payload >>>>> - the situation is analogous to TCP options, which are not covered by >>>>> TLS >>>>> I.e., both TLS and DTLS are transport *payload* security only, despite >>>>> their names. >>>>> >>>>> Christian noted that this may be a reason QUIC prefers UDP (to avoid the >>>>> need to protection transport options), however QUIC does not (and >>>>> cannot) deprecate UDP payloads that are smaller than the IP payload. >>>>> That would require a change to RFC 768. >>>>> >>>>> I'll add a clarification on this point to the next rev of the UDP >>>>> options document. >>>>> >>>>> Joe > From nobody Mon Apr 17 14:06:19 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7241C128C82 for ; Mon, 17 Apr 2017 14:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R3HMm15w_LM for ; Mon, 17 Apr 2017 14:06:16 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2A11286CA for ; Mon, 17 Apr 2017 14:06:16 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id g60so44773021qtd.3 for ; Mon, 17 Apr 2017 14:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x/nzY+ONh51QtTfv7QQRr1z9fxl4szavx0iA4zwfAoU=; b=Tm641DD09dl/47mS/MucVsQSzr2dODsy7NK6uCzv6sqVqfT+IRh4YN7pewLF1h1juJ bWWMqXoqAEWmjxe2e5Qydvr87BBqelMiMblZnO4LeY8/Q8qrliTu6OgxvGFm5mwhoQ0L Z4/Qxi5VSJRBpeNwIecuIuw+zdZepmywnat9QJPN4GK7Iw5lEfVr4fqY4zRUx5DKH4wr PR0swfJnXmj494vsfnXAK5/PP8XyhDzK+Sx7BAT57e7AwO7aUabWnIZsWzUVTzsrP+96 doy0sGjFmbVYZSeokJieSD5avM8hk3RTLLFrVCPK11DlPp0BdNZiDwI61zcOZEyfqeKj NZuQ== 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=x/nzY+ONh51QtTfv7QQRr1z9fxl4szavx0iA4zwfAoU=; b=tdl7WYxxljM0Ker4JlKKDwTdurv+xRJSWoPozR2RPawFk8XiJXs/Zdz4RoRSKKVcp4 qT3Omcq75gqIdJI+oPM/fTZ0xt0u9IBeHD9SFrNWxbw3mGhQlKuE3Z17YULLzmiJIGAL 1wWn3+SzfuLxNTHPODIM75XSKygiRMFG2wZRzg20MQTuurEoVFXdmIbF0nDp6OSYBOKZ 3+vNiOuXb6Fb27/lHfdAntZ5f49t9ex/T5oWtVomZbPMq3D9LmaIuFW0MVm4LGiQFTt9 SluiWUFD/sauQDDSlZm/IoM4xPmjwB/ngOHrqCXjy2cVp0+4gdGnQQaIOT2b6PHVe0lV 9Uxg== X-Gm-Message-State: AN3rC/5UEne0K1AO7Q5MdTbheJg268H1gyZ1T9Dt9s0ljTVU7aJHEoKG ktzhW7H+Xf+tttIyDf2cFo7bRAjdQA== X-Received: by 10.200.34.144 with SMTP id f16mr11612899qta.186.1492463175197; Mon, 17 Apr 2017 14:06:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 17 Apr 2017 14:06:14 -0700 (PDT) In-Reply-To: <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> From: Tom Herbert Date: Mon, 17 Apr 2017 14:06:14 -0700 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:06:17 -0000 On Fri, Apr 14, 2017 at 4:56 PM, Joe Touch wrote: > Hi, all, > > Christian Huitema a question about the interaction between DTLS and UDP > options during my remote presentation at IETF 98. > > I took a closer look and consulted with Eric Rescorla (DTLS author). He > and I agreed as follows: > - DTLS would currently not cover UDP options; DTLS protects only the UDP > payload > - the situation is analogous to TCP options, which are not covered by TLS > I.e., both TLS and DTLS are transport *payload* security only, despite > their names. > > Christian noted that this may be a reason QUIC prefers UDP (to avoid the > need to protection transport options), however QUIC does not (and > cannot) deprecate UDP payloads that are smaller than the IP payload. > That would require a change to RFC 768. > > I'll add a clarification on this point to the next rev of the UDP > options document. > Since the UDP options are not covered by DTLS couldn't that allow a middleman attacker to add arbitrary UDP options to a packet thereby potentially circumventing the security provided DTLS? Maybe if DTLS is in use then AE option should be required also? Note that this case differs from TCP options since the sender in my example my not even have a clue as to what UDP options are. Tom > Joe > From nobody Mon Apr 17 14:08:47 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76392129480 for ; Mon, 17 Apr 2017 14:08:46 -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 YQyLsDi-_Csc for ; Mon, 17 Apr 2017 14:08:45 -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 8D3EE12947E for ; Mon, 17 Apr 2017 14:08:45 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3HL7xmA017152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Apr 2017 14:07:59 -0700 (PDT) To: Tom Herbert References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> Cc: "gorry@erg.abdn.ac.uk" , tsvwg From: Joe Touch Message-ID: <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> Date: Mon, 17 Apr 2017 14:07:59 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3HL7xmA017152 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:08:46 -0000 On 4/17/2017 1:47 PM, Tom Herbert wrote: > ... >> >>> One thing that might be missing from the draft is middle box handling. >> This is already discussed extensively in the document, including in >> response to previous TSVWG discussion. That's why we now default to >> using the OCS and a length validation. Do you have specific concerns? ... >> >>> and so middleboxes must pass packets with UDP options, >>> should not attempt to parse the UDP options, and must not modify >>> options. >> We already addressed that in the doc. > I'm sorry, which section is this info in? The doc talks about legacy issues throughout. Sec 5.3 talks about the option checksum and Sec 9 talks about interactions with legacy devices in general. Section 7 explicitly indicates that these are for transport endpoint use only. I don't think we should be writing rules to indicate who should NOT be changing them, if we already have rules indicating the only parties that can. (granted, the requirement in 7 needs to be revised in 2119-speak). Joe From nobody Mon Apr 17 14:09:11 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D6812EB34; Mon, 17 Apr 2017 14:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Cs_9vJXCSVYo; Mon, 17 Apr 2017 14:08:59 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A43A129449; Mon, 17 Apr 2017 14:08:53 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id o22so46319671iod.3; Mon, 17 Apr 2017 14:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4lIxCMWlELmRBkU9ZUJxS6vckUg7Ev4UdhkR3eA8n4k=; b=lDX06CRT1yApQj0oXlIJTW+GBcrIuW+FPEBP1cj01VRXqdFPZcMY5+e5aa/NHhJ0IH lA4xnkUZyl5pfvdeGy7uxUcgwunVqHYWgoRVDvXG2kmOSKynT0SCWteG/8VURHBDy5xd UTvfZdL0PSe9GmAkP9tt3HZpju/N1KgD+a4ornLbzr3jbGwtSl9U9lP6G4ONIGOqBNY+ 2lpPv+caG+/QU0ldr0WdspxigvmDPOOhuGnTfxuRek8Yn4FzSoDUcXuMPIPFwD6MTN+N h6I9c0kBRQXWXqQmtE8C14cluvTmtI11khqA7UTMxDm2eIn91x9akH4QOI0RIiSTONWH cGzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4lIxCMWlELmRBkU9ZUJxS6vckUg7Ev4UdhkR3eA8n4k=; b=BEHfG5xrfCO+Sg1kTqaBEKFiNjDWzq2RFlcL3U2XXuWsAucvMBB0H0hMdsj5Fc06ie 0j0etPAAJiiuCHrl7212qZNyK++Wawp9vv2brjePAufoIPHGIcjM46UVXXLjCawY8VCz 3HTAkQj1esCIu3kemvtM9Bn8dqfU8CV89L+oBCrg7OWB6gayOoaYPCrV2GO1vF4gMudg kmGUjGWs6JGngLoafTtO+upzF3S57Szx/t4IWb+JRIBEPgpDDitDOF9hnVi23HrvCcGE seHfNudVI0JmXZWAgsMmc+F5JDD5dw7LYqMU/mrAKWs1qRSziS1/slq2EtR8U22FjnCJ q1HQ== X-Gm-Message-State: AN3rC/73Ghv+IpN5IHTNlN97RqRV6BCU3ZDQhrVHwj3HZ6JWbLGajhBq +oGqmr1hszp05ZCTok4= X-Received: by 10.107.9.73 with SMTP id j70mr11818590ioi.211.1492463332401; Mon, 17 Apr 2017 14:08:52 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id r197sm3885268ita.11.2017.04.17.14.08.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 14:08:51 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7BBF44EB-21A1-4E8E-AC1A-CFACAE8F93E2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Apr 2017 14:08:48 -0700 In-Reply-To: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> Cc: Bob Hinden , "Black, David" , "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg , "draft-ietf-6man-rfc2460bis@ietf.org" , "Mirja Kuehlewind (IETF)" , IESG , 6man Chairs <6man-chairs@ietf.org> To: Brian Carpenter References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:09:03 -0000 --Apple-Mail=_7BBF44EB-21A1-4E8E-AC1A-CFACAE8F93E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, After reading through the discussion, I think a new paragraph (after the = text that says how to construct a reassembled packet) like the following = would be appropriate. Nodes that support Explicit Congestion Notification [RFC3168] should use information in the Traffic Class field from all fragment packets to reconstruct the Traffic Class field in the reassembled packet. See Section 5.3 of RFC3168 for more information. I don=E2=80=99t think we need to quote what RFC3168 says, just point the = the correct section. This also doesn=E2=80=99t effect nodes that don=E2=80=99t support ECN, = so it shouldn't be making any new requirements. Comments? Bob > On Apr 17, 2017, at 12:58 PM, Brian E Carpenter = wrote: >=20 > In line... >=20 > On 18/04/2017 05:44, Black, David wrote: >> Extracting the key portions of text: >>=20 >>>> That is inconsistent with the following guidance in RFC 3168 (see >>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>=20 >>>> 5.3. Fragmentation >>>>=20 >>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>> congestion. In other words, if any fragment of an IP packet to be >>>> reassembled has the CE codepoint set, then one of two actions MUST = be >>>> taken: >>>>=20 >>>> * Set the CE codepoint on the reassembled packet. However, = this >>>> MUST NOT occur if any of the other fragments contributing to >>>> this reassembly carries the Not-ECT codepoint. >>>>=20 >>>> * The packet is dropped, instead of being reassembled, for any >>>> other reason. >>>>=20 >>>> If both actions are applicable, either MAY be chosen. Reassembly = of >>>> a fragmented packet MUST NOT change the ECN codepoint when all of = the >>>> fragments carry the same codepoint. >>=20 >>> Regardless of the answer to that question, my position would be that = since >>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of >>> the Traffic Class field, the following modification to 2460bis = Section 4.5 >>> would be an appropriate way to deal with Mirja's comment: >>>=20 >>> OLD: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained = in >>> the reassembled packet. >>> NEW: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained = in >>> the reassembled packet; however, nodes that support Explicit >>> Congestion Notification [RFC3168] may use information in the >>> Traffic Class field from all fragment packets to reconstruct = the >>> Traffic Class field in the reassembled packet. >>>=20 >>> Note that this would not cause 2460bis itself to levy an additional >>> requirement on how IPv6 nodes reassemble fragmented packets. It = would >>> simply be making note of a requirement that is already levied by >>> RFC 3168. >>=20 >> In which case, the RFC 3168 requirement should be stated e.g.: >>=20 >> OLD: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in >> the reassembled packet. >> NEW: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in >> the reassembled packet; however, nodes that support Explicit >> Congestion Notification [RFC3168] may use information in the >> Traffic Class field from any or all fragment packets to = reconstruct >> the Traffic Class field in the reassembled packet in order to = meet >> RFC 3168's requirements, e.g., that reassembly not lose = indications >> of congestion, see Section 5.3 of RFC 3168 for additional = information. >>=20 >> Pointing the implementer at Section 5.3 of RFC 3168 is better than >> hoping she figures out on her own that she ought to take a look at it = . >=20 > Yes. This is correct. >=20 > Brian >=20 >>=20 >> Thanks, --David >>=20 >>> -----Original Message----- >>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. Heard >>> Sent: Monday, April 17, 2017 12:00 PM >>> To: 6MAN <6man@ietf.org>; tsvwg >>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden >>> ; Mirja Kuehlewind (IETF) = ; >>> IESG ; 6man Chairs <6man-chairs@ietf.org> >>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on = draft-ietf-6man-rfc2460bis- >>> 09: (with DISCUSS and COMMENT) >>>=20 >>> [ TSVWG added to solicit advice on implementation of RFC 3186 = Section 5.3 ] >>>=20 >>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>>>> ... >>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>> COMMENT: >>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>=20 >>>>>>>>>>> One question because I'm not sure if I interpret this = correct to >>> make it >>>>>>>>>>> part of my discuss: >>>>>>>>>>> Section 4.5: "The number and content of the headers = preceding >>> the >>>>>>>>>>> Fragment >>>>>>>>>>> header of different fragments of the same original packet = may >>>>>>>>>>> differ. Whatever headers are present, preceding the = Fragment >>>>>>>>>>> header in each fragment packet, are processed when the = packets >>>>>>>>>>> arrive, prior to queueing the fragments for reassembly. = Only >>>>>>>>>>> those headers in the Offset zero fragment packet are = retained in >>>>>>>>>>> the reassembled packet." >>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class = field) >>> is >>>>>>>>>>> copied from the first fragment? This doesn't seem to be = correct, >>> however, >>>>>>>>>>> also not sure what the correct answer is. I know this was = not >>> changed in >>>>>>>>>>> this revision but maybe we can still get this right. >>>>>>>>>>=20 >>>>>>>>>> When fragments are created most of the fields are copied from = the >>> IPv6 >>>>>>>>>> headers (e.g., Source Address, Destination address, flow = label, >>> traffic >>>>>>>>>> class, hop limit). Some like payload length, next header, = and hop >>> limi >>>>>>>>>> t are modified. >>>>>>>>>>=20 >>>>>>>>>> If I understand your question, the answer is yes, the ECN = code >>> point is >>>>>>>>>> copied from the first fragment, but should be the same from = all of >>> the >>>>>>>>>> fragments. >>>>>=20 >>>>> That is inconsistent with the following guidance in RFC 3168 (see >>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>=20 >>>>> 5.3. Fragmentation >>>>>=20 >>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>> congestion. In other words, if any fragment of an IP packet to = be >>>>> reassembled has the CE codepoint set, then one of two actions = MUST be >>>>> taken: >>>>>=20 >>>>> * Set the CE codepoint on the reassembled packet. However, = this >>>>> MUST NOT occur if any of the other fragments contributing to >>>>> this reassembly carries the Not-ECT codepoint. >>>>>=20 >>>>> * The packet is dropped, instead of being reassembled, for any >>>>> other reason. >>>>>=20 >>>>> If both actions are applicable, either MAY be chosen. Reassembly = of >>>>> a fragmented packet MUST NOT change the ECN codepoint when all of >>> the >>>>> fragments carry the same codepoint. >>>>>=20 >>>>>>>>> My concern is that the ECN code point could be changed on one = of >>> the >>>>>>>>> fragmented packets to signal congestion of a intermediate node = and >>>>>>>>> then when you reassemble this information gets lost. That = seems >>> wrong. >>>>>>>>=20 >>>>>>>> That is an interesting idea, but I think out of scope for = advancing this >>>>>>>> document to Internet Standard. Then there is the question of = how to >>>>>>>> encode n of m fragments experienced congestion. Interesting = future >>> work. >>>>>>>=20 >>>>>>> Yes there might be some more further work needed but that still >>> makes the >>>>>>> guidance in this text wrong. Maybe we can add some text that the >>> Traffic >>>>>>> Class may be handled differently because it could be changed on = the >>> path. >>>>>>=20 >>>>>> Good point. It's not only ECN that can change; the DSCP can = change too. >>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's = logical >>>>>> for 2460bis to note this issue. >>>>>=20 >>>>> It seems that we (6man WG) missed this because RFC 3168 was not >>> marked >>>>> as updating RFC 2460. But in effect it did so for IPv6 = implementations >>>>> of ECN, even though it was not written in an IP version-agnostic = manner. >>>>>=20 >>>>> At the very least text should be added to the description of the >>>>> reassembly process that points the reader to RFC 3168 or its >>>>> successor document. >>>>=20 >>>> Do we have any evidence that the guidance in RFC 3168 regarding >>> reassembling >>>> IPv6 fragments is implemented? I don=E2=80=99t know, but think if = it there is >>>> evidence I agree some text should be added to rfc2460bis, if not, = then >>>> maybe not. >>>=20 >>> Since I lack the expertise to answer that question, I'm hoping that = someone >>> in TSVWG will see this message and do so. >>>=20 >>> Regardless of the answer to that question, my position would be that = since >>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of >>> the Traffic Class field, the following modification to 2460bis = Section 4.5 >>> would be an appropriate way to deal with Mirja's comment: >>>=20 >>> OLD: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained = in >>> the reassembled packet. >>> NEW: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained = in >>> the reassembled packet; however, nodes that support Explicit >>> Congestion Notification [RFC3168] may use information in the >>> Traffic Class field from all fragment packets to reconstruct = the >>> Traffic Class field in the reassembled packet. >>>=20 >>> Note that this would not cause 2460bis itself to levy an additional >>> requirement on how IPv6 nodes reassemble fragmented packets. It = would >>> simply be making note of a requirement that is already levied by >>> RFC 3168. >>>=20 >>> Thanks and regards, >>>=20 >>> Mike Heard >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 --Apple-Mail=_7BBF44EB-21A1-4E8E-AC1A-CFACAE8F93E2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY9S7hAAoJEK7rdBF357uomFwH/3N51BqKi/gqGoGSywcBUVgQ dIrCFcjVS7Gw79KBqCQP7aDD2WL38wtrxpnwQnvHH4xwrrgsRKAGRED91N+XJMyZ rrBhdpfpY3BGkvR+Kc3urUG/3wM4pa4oaMcZ2v07IXv8RnNFt75pCQCD9SLiMDHK vZwjIcKQNuBIbV1zRrrgCw2Uw2aPXcMO2F2HOiPlaK6Jf7GFj9TXVZsa63QsTAlS BgzC/5DbzSfz8LfRtw53ZMJoczNV7OaLPs4Pjs6IrDkmftHsQ7kTUS/lpvfZOOsP 5X6SUzc7tAuNLJRexFXLO59US0WVHSzsdkdmp0G1ENZAPlgKYLLAv2BfR5+5hew= =G1He -----END PGP SIGNATURE----- --Apple-Mail=_7BBF44EB-21A1-4E8E-AC1A-CFACAE8F93E2-- From nobody Mon Apr 17 14:12:33 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A402129449 for ; Mon, 17 Apr 2017 14:12:32 -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 6ahPHHmVHsMD for ; Mon, 17 Apr 2017 14:12:31 -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 EFD1D128BA2 for ; Mon, 17 Apr 2017 14:12:30 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3HLC9sS018361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Apr 2017 14:12:09 -0700 (PDT) To: Tom Herbert References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> Cc: tsvwg From: Joe Touch Message-ID: <435a9efb-1958-4e10-866b-deb1e15fb418@isi.edu> Date: Mon, 17 Apr 2017 14:12:09 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3HLC9sS018361 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:12:32 -0000 On 4/17/2017 2:06 PM, Tom Herbert wrote: > On Fri, Apr 14, 2017 at 4:56 PM, Joe Touch wrote: >> Hi, all, >> >> Christian Huitema a question about the interaction between DTLS and UDP >> options during my remote presentation at IETF 98. >> >> I took a closer look and consulted with Eric Rescorla (DTLS author). He >> and I agreed as follows: >> - DTLS would currently not cover UDP options; DTLS protects only the UDP >> payload >> - the situation is analogous to TCP options, which are not covered by TLS >> I.e., both TLS and DTLS are transport *payload* security only, despite >> their names. >> >> Christian noted that this may be a reason QUIC prefers UDP (to avoid the >> need to protection transport options), however QUIC does not (and >> cannot) deprecate UDP payloads that are smaller than the IP payload. >> That would require a change to RFC 768. >> >> I'll add a clarification on this point to the next rev of the UDP >> options document. >> > Since the UDP options are not covered by DTLS couldn't that allow a > middleman attacker to add arbitrary UDP options to a packet thereby > potentially circumventing the security provided DTLS? Everything you just said is already true for TCP and TLS. The "TL" in TLS and DTLS is a misnomer; neither one provides transport-layer protection. > Maybe if DTLS is > in use then AE option should be required also? That's no more appropriate than it would be to require TCP-AO whenever TLS is in use. > Note that this case > differs from TCP options since the sender in my example my not even > have a clue as to what UDP options are. That's irrelevant. In both cases, a MITM can add an option that the sender might not know about. If you want to protect the transport header, you have to use true transport-layer protection (TCP-AO, UDO AE) or IPsec. Joe From nobody Mon Apr 17 14:19:08 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CE2127698 for ; Mon, 17 Apr 2017 14:19:06 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2ZRwBYXFjfr for ; Mon, 17 Apr 2017 14:19:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A5D129449 for ; Mon, 17 Apr 2017 14:19:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C3968B81069; Mon, 17 Apr 2017 14:18:52 -0700 (PDT) To: kk@teraoptic.com, floyd@aciri.org, black_david@emc.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, david.black@emc.com, gorry@erg.abdn.ac.uk, wes@mti-systems.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: heard@pobox.com, tsvwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170417211852.C3968B81069@rfc-editor.org> Date: Mon, 17 Apr 2017 14:18:52 -0700 (PDT) Archived-At: Subject: [tsvwg] [Editorial Errata Reported] RFC3168 (4997) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:19:06 -0000 The following errata report has been submitted for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=4997 -------------------------------------- Type: Editorial Reported by: C. M. Heard Section: Header Original Text ------------- Updates: 2474, 2401, 793 Corrected Text -------------- Updates: 2474, 2460, 2401, 793 Notes ----- RFC 3168 updates RFC 2460 but does not indicate this in its header block. Specifically, Section 5.3 of RFC 3168 requires that the ECN field of a reassembled IPv6 datagram be calculated from the ECN fields of all of the fragments, rather than simply copying it from the initial fragment as specified in RFC 2460. There are other missing Updates: fields; see e.g. Erratum 2660. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3168 (draft-ietf-tsvwg-ecn-04) -------------------------------------- Title : The Addition of Explicit Congestion Notification (ECN) to IP Publication Date : September 2001 Author(s) : K. Ramakrishnan, S. Floyd, D. Black Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Apr 17 14:20:12 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B915512F255 for ; Mon, 17 Apr 2017 14:20:10 -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 iNHRkxGgvR5d for ; Mon, 17 Apr 2017 14:20:09 -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 B89EF129449 for ; Mon, 17 Apr 2017 14:20:09 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3HLJSRm019702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Apr 2017 14:19:28 -0700 (PDT) To: Tom Herbert References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> Cc: "gorry@erg.abdn.ac.uk" , tsvwg From: Joe Touch Message-ID: Date: Mon, 17 Apr 2017 14:19:28 -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: <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3HLJSRm019702 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:20:11 -0000 On 4/17/2017 2:07 PM, Joe Touch wrote: > I don't think we should be writing rules to indicate who should NOT be > changing them, if we already have rules indicating the only parties that > can. (granted, the requirement in 7 needs to be revised in 2119-speak). FWIW, the doc currently says that the options are intended for use by the endpoints. However, just as NATs already change transport headers and options (e.g., TCP), they could do so here as well. In both cases, the same caveats apply: - if the endpoints don't want to allow changes, they must use (true) transport or network protections - if the middlebox (or any other mechanism, e.g., offloading) changes them, they need to know what they're doing and do it right Again, none of this is news. Joe From nobody Mon Apr 17 14:36:46 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7939124D68; Mon, 17 Apr 2017 14:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 V3oyVnqsWNsB; Mon, 17 Apr 2017 14:36:33 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFC8129B16; Mon, 17 Apr 2017 14:36:33 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 7325972389; Mon, 17 Apr 2017 17:36:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=21bWDqpIUiIwzPAfO1I6P4aER0Y=; b=doajVx kP2NwMZ+m5t9LX6h+i68DGcbDj+8y6WxcnaKMT15ZaeNUbedzbcOBZUqFfNpdZOd +047EY+y7GaVn7w2FGdqfUDFThxBp7qItgPXcHAyKC+JTmNcdXsF2ivAw6TFBRT3 G04fX+myX/R/vuSqCFAk4Onpd/YwGyXM1Tols= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=Dapz9qhzdkYrG2scIIhf+rp9NHDoinQh dgYtsODI34tftzeyQMIEUy3ES+rtx6TAdfzXbmGt8t3p4rKAfobXOokOgsc1xyQ3 CsRDB6orGsvGRjThByVH6WgPNe1RGjn36Y48/j5ZvHSdgTfM+8SqDHSBDPjtNoxS 67P6f+DhmEQ= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 6A74572388; Mon, 17 Apr 2017 17:36:32 -0400 (EDT) Received: from mail-qt0-f182.google.com (unknown [209.85.216.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id DB56472386; Mon, 17 Apr 2017 17:36:31 -0400 (EDT) Received: by mail-qt0-f182.google.com with SMTP id y33so28236272qta.2; Mon, 17 Apr 2017 14:36:31 -0700 (PDT) X-Gm-Message-State: AN3rC/64CPstvwDfXXoBk4GNvXTLfJ7P22ewGX2L15FqWMURitUqdI73 SrPp5qYgII/MNjb0RrDHmzP/aGBneg== X-Received: by 10.237.60.77 with SMTP id u13mr10527574qte.267.1492464991469; Mon, 17 Apr 2017 14:36:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Mon, 17 Apr 2017 14:36:11 -0700 (PDT) In-Reply-To: References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> From: "C. M. Heard" Date: Mon, 17 Apr 2017 14:36:11 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bob Hinden Cc: Brian Carpenter , "Black, David" , "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg , "draft-ietf-6man-rfc2460bis@ietf.org" , "Mirja Kuehlewind (IETF)" , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary=94eb2c190326a8055a054d639558 X-Pobox-Relay-ID: EC549A9E-23B5-11E7-A6D2-C260AE2156B6-06080547!pb-smtp2.pobox.com Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:36:37 -0000 --94eb2c190326a8055a054d639558 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bob, I agree with you on all points. This is a good solution. Mike Heard On Mon, Apr 17, 2017 at 2:08 PM, Bob Hinden wrote: > Hi, > > After reading through the discussion, I think a new paragraph (after the > text that says how to construct a reassembled packet) like the following > would be appropriate. > > Nodes that support Explicit Congestion Notification [RFC3168] > should use information in the Traffic Class field from all > fragment packets to reconstruct the Traffic Class field in the > reassembled packet. See Section 5.3 of RFC3168 for more > information. > > I don=E2=80=99t think we need to quote what RFC3168 says, just point the = the > correct section. > > This also doesn=E2=80=99t effect nodes that don=E2=80=99t support ECN, so= it shouldn't be > making any new requirements. > > Comments? > > Bob > > > On Apr 17, 2017, at 12:58 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > > In line... > > > > On 18/04/2017 05:44, Black, David wrote: > >> Extracting the key portions of text: > >> > >>>> That is inconsistent with the following guidance in RFC 3168 (see > >>>> https://tools.ietf.org/html/rfc3168#section-5.3): > >>>> > >>>> 5.3. Fragmentation > >>>> > >>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. > >>>> Reassembly of a fragmented packet MUST NOT lose indications of > >>>> congestion. In other words, if any fragment of an IP packet to be > >>>> reassembled has the CE codepoint set, then one of two actions MUST = be > >>>> taken: > >>>> > >>>> * Set the CE codepoint on the reassembled packet. However, this > >>>> MUST NOT occur if any of the other fragments contributing to > >>>> this reassembly carries the Not-ECT codepoint. > >>>> > >>>> * The packet is dropped, instead of being reassembled, for any > >>>> other reason. > >>>> > >>>> If both actions are applicable, either MAY be chosen. Reassembly o= f > >>>> a fragmented packet MUST NOT change the ECN codepoint when all of t= he > >>>> fragments carry the same codepoint. > >> > >>> Regardless of the answer to that question, my position would be that > since > >>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handlin= g > of > >>> the Traffic Class field, the following modification to 2460bis Sectio= n > 4.5 > >>> would be an appropriate way to deal with Mirja's comment: > >>> > >>> OLD: > >>> The number and content of the headers preceding the Fragment > >>> header of different fragments of the same original packet may > >>> differ. Whatever headers are present, preceding the Fragment > >>> header in each fragment packet, are processed when the packets > >>> arrive, prior to queueing the fragments for reassembly. Only > >>> those headers in the Offset zero fragment packet are retained in > >>> the reassembled packet. > >>> NEW: > >>> The number and content of the headers preceding the Fragment > >>> header of different fragments of the same original packet may > >>> differ. Whatever headers are present, preceding the Fragment > >>> header in each fragment packet, are processed when the packets > >>> arrive, prior to queueing the fragments for reassembly. Only > >>> those headers in the Offset zero fragment packet are retained in > >>> the reassembled packet; however, nodes that support Explicit > >>> Congestion Notification [RFC3168] may use information in the > >>> Traffic Class field from all fragment packets to reconstruct the > >>> Traffic Class field in the reassembled packet. > >>> > >>> Note that this would not cause 2460bis itself to levy an additional > >>> requirement on how IPv6 nodes reassemble fragmented packets. It would > >>> simply be making note of a requirement that is already levied by > >>> RFC 3168. > >> > >> In which case, the RFC 3168 requirement should be stated e.g.: > >> > >> OLD: > >> The number and content of the headers preceding the Fragment > >> header of different fragments of the same original packet may > >> differ. Whatever headers are present, preceding the Fragment > >> header in each fragment packet, are processed when the packets > >> arrive, prior to queueing the fragments for reassembly. Only > >> those headers in the Offset zero fragment packet are retained in > >> the reassembled packet. > >> NEW: > >> The number and content of the headers preceding the Fragment > >> header of different fragments of the same original packet may > >> differ. Whatever headers are present, preceding the Fragment > >> header in each fragment packet, are processed when the packets > >> arrive, prior to queueing the fragments for reassembly. Only > >> those headers in the Offset zero fragment packet are retained in > >> the reassembled packet; however, nodes that support Explicit > >> Congestion Notification [RFC3168] may use information in the > >> Traffic Class field from any or all fragment packets to reconstru= ct > >> the Traffic Class field in the reassembled packet in order to mee= t > >> RFC 3168's requirements, e.g., that reassembly not lose indicatio= ns > >> of congestion, see Section 5.3 of RFC 3168 for additional > information. > >> > >> Pointing the implementer at Section 5.3 of RFC 3168 is better than > >> hoping she figures out on her own that she ought to take a look at it = . > > > > Yes. This is correct. > > > > Brian > > > >> > >> Thanks, --David > >> > >>> -----Original Message----- > >>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. Heard > >>> Sent: Monday, April 17, 2017 12:00 PM > >>> To: 6MAN <6man@ietf.org>; tsvwg > >>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden > >>> ; Mirja Kuehlewind (IETF) = ; > >>> IESG ; 6man Chairs <6man-chairs@ietf.org> > >>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on > draft-ietf-6man-rfc2460bis- > >>> 09: (with DISCUSS and COMMENT) > >>> > >>> [ TSVWG added to solicit advice on implementation of RFC 3186 Section > 5.3 ] > >>> > >>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: > >>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: > >>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: > >>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: > >>>>>> ... > >>>>>>>>>>> ------------------------------------------------------------ > ---------- > >>>>>>>>>>> COMMENT: > >>>>>>>>>>> ------------------------------------------------------------ > ---------- > >>>>>>>>>>> > >>>>>>>>>>> One question because I'm not sure if I interpret this correct > to > >>> make it > >>>>>>>>>>> part of my discuss: > >>>>>>>>>>> Section 4.5: "The number and content of the headers preceding > >>> the > >>>>>>>>>>> Fragment > >>>>>>>>>>> header of different fragments of the same original packet may > >>>>>>>>>>> differ. Whatever headers are present, preceding the Fragment > >>>>>>>>>>> header in each fragment packet, are processed when the packet= s > >>>>>>>>>>> arrive, prior to queueing the fragments for reassembly. Only > >>>>>>>>>>> those headers in the Offset zero fragment packet are retained > in > >>>>>>>>>>> the reassembled packet." > >>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class > field) > >>> is > >>>>>>>>>>> copied from the first fragment? This doesn't seem to be > correct, > >>> however, > >>>>>>>>>>> also not sure what the correct answer is. I know this was not > >>> changed in > >>>>>>>>>>> this revision but maybe we can still get this right. > >>>>>>>>>> > >>>>>>>>>> When fragments are created most of the fields are copied from > the > >>> IPv6 > >>>>>>>>>> headers (e.g., Source Address, Destination address, flow label= , > >>> traffic > >>>>>>>>>> class, hop limit). Some like payload length, next header, and > hop > >>> limi > >>>>>>>>>> t are modified. > >>>>>>>>>> > >>>>>>>>>> If I understand your question, the answer is yes, the ECN code > >>> point is > >>>>>>>>>> copied from the first fragment, but should be the same from al= l > of > >>> the > >>>>>>>>>> fragments. > >>>>> > >>>>> That is inconsistent with the following guidance in RFC 3168 (see > >>>>> https://tools.ietf.org/html/rfc3168#section-5.3): > >>>>> > >>>>> 5.3. Fragmentation > >>>>> > >>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. > >>>>> Reassembly of a fragmented packet MUST NOT lose indications of > >>>>> congestion. In other words, if any fragment of an IP packet to be > >>>>> reassembled has the CE codepoint set, then one of two actions MUST > be > >>>>> taken: > >>>>> > >>>>> * Set the CE codepoint on the reassembled packet. However, thi= s > >>>>> MUST NOT occur if any of the other fragments contributing to > >>>>> this reassembly carries the Not-ECT codepoint. > >>>>> > >>>>> * The packet is dropped, instead of being reassembled, for any > >>>>> other reason. > >>>>> > >>>>> If both actions are applicable, either MAY be chosen. Reassembly = of > >>>>> a fragmented packet MUST NOT change the ECN codepoint when all of > >>> the > >>>>> fragments carry the same codepoint. > >>>>> > >>>>>>>>> My concern is that the ECN code point could be changed on one o= f > >>> the > >>>>>>>>> fragmented packets to signal congestion of a intermediate node > and > >>>>>>>>> then when you reassemble this information gets lost. That seems > >>> wrong. > >>>>>>>> > >>>>>>>> That is an interesting idea, but I think out of scope for > advancing this > >>>>>>>> document to Internet Standard. Then there is the question of ho= w > to > >>>>>>>> encode n of m fragments experienced congestion. Interesting > future > >>> work. > >>>>>>> > >>>>>>> Yes there might be some more further work needed but that still > >>> makes the > >>>>>>> guidance in this text wrong. Maybe we can add some text that the > >>> Traffic > >>>>>>> Class may be handled differently because it could be changed on t= he > >>> path. > >>>>>> > >>>>>> Good point. It's not only ECN that can change; the DSCP can change > too. > >>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logica= l > >>>>>> for 2460bis to note this issue. > >>>>> > >>>>> It seems that we (6man WG) missed this because RFC 3168 was not > >>> marked > >>>>> as updating RFC 2460. But in effect it did so for IPv6 > implementations > >>>>> of ECN, even though it was not written in an IP version-agnostic > manner. > >>>>> > >>>>> At the very least text should be added to the description of the > >>>>> reassembly process that points the reader to RFC 3168 or its > >>>>> successor document. > >>>> > >>>> Do we have any evidence that the guidance in RFC 3168 regarding > >>> reassembling > >>>> IPv6 fragments is implemented? I don=E2=80=99t know, but think if i= t there is > >>>> evidence I agree some text should be added to rfc2460bis, if not, th= en > >>>> maybe not. > >>> > >>> Since I lack the expertise to answer that question, I'm hoping that > someone > >>> in TSVWG will see this message and do so. > >>> > >>> Regardless of the answer to that question, my position would be that > since > >>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handlin= g > of > >>> the Traffic Class field, the following modification to 2460bis Sectio= n > 4.5 > >>> would be an appropriate way to deal with Mirja's comment: > >>> > >>> OLD: > >>> The number and content of the headers preceding the Fragment > >>> header of different fragments of the same original packet may > >>> differ. Whatever headers are present, preceding the Fragment > >>> header in each fragment packet, are processed when the packets > >>> arrive, prior to queueing the fragments for reassembly. Only > >>> those headers in the Offset zero fragment packet are retained in > >>> the reassembled packet. > >>> NEW: > >>> The number and content of the headers preceding the Fragment > >>> header of different fragments of the same original packet may > >>> differ. Whatever headers are present, preceding the Fragment > >>> header in each fragment packet, are processed when the packets > >>> arrive, prior to queueing the fragments for reassembly. Only > >>> those headers in the Offset zero fragment packet are retained in > >>> the reassembled packet; however, nodes that support Explicit > >>> Congestion Notification [RFC3168] may use information in the > >>> Traffic Class field from all fragment packets to reconstruct the > >>> Traffic Class field in the reassembled packet. > >>> > >>> Note that this would not cause 2460bis itself to levy an additional > >>> requirement on how IPv6 nodes reassemble fragmented packets. It would > >>> simply be making note of a requirement that is already levied by > >>> RFC 3168. > >>> > >>> Thanks and regards, > >>> > >>> Mike Heard > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > > > > --94eb2c190326a8055a054d639558 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bob,

I agree with you on all points. Th= is is a good solution.

Mike Heard

On Mon, Apr 17, 2017 at 2:08 PM, Bob Hinden <bob.= hinden@gmail.com> wrote:
Hi= ,

After reading through the discussion, I think a new paragraph (after the te= xt that says how to construct a reassembled packet) like the following woul= d be appropriate.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nodes that support Explicit Congestion No= tification [RFC3168]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should use information in the Traffic Cla= ss field from all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fragment packets to reco= nstruct the Traffic Class field in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reassembled packet.=C2=A0 See Sect= ion 5.3 of RFC3168 for more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information.

I don=E2=80=99t think we need to quote what RFC3168 says, just point the th= e correct section.

This also doesn=E2=80=99t effect nodes that don=E2=80=99t support ECN, so i= t shouldn't be making any new requirements.

Comments?

Bob

> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> In line...
>
> On 18/04/2017 05:44, Black, David wrote:
>> Extracting the key portions of text:
>>
>>>> That is inconsistent with the following guidance in RFC 31= 68 (see
>>>> https://tools.ietf.org/html/rfc= 3168#section-5.3):
>>>>
>>>> 5.3.=C2=A0 Fragmentation
>>>>
>>>>=C2=A0 ECN-capable packets MAY have the DF (Don't Fragm= ent) bit set.
>>>>=C2=A0 Reassembly of a fragmented packet MUST NOT lose indi= cations of
>>>>=C2=A0 congestion.=C2=A0 In other words, if any fragment of= an IP packet to be
>>>>=C2=A0 reassembled has the CE codepoint set, then one of tw= o actions MUST be
>>>>=C2=A0 taken:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0* Set the CE codepoint on the reassembl= ed packet.=C2=A0 However, this
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT occur if any of the oth= er fragments contributing to
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0this reassembly carries the Not-= ECT codepoint.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0* The packet is dropped, instead of bei= ng reassembled, for any
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0other reason.
>>>>
>>>>=C2=A0 If both actions are applicable, either MAY be chosen= .=C2=A0 Reassembly of
>>>>=C2=A0 a fragmented packet MUST NOT change the ECN codepoin= t when all of the
>>>>=C2=A0 fragments carry the same codepoint.
>>
>>> Regardless of the answer to that question, my position would b= e that since
>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of
>>> the Traffic Class field, the following modification to 2460bis= Section 4.5
>>> would be an appropriate way to deal with Mirja's comment:<= br> >>>
>>> OLD:
>>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers prec= eding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same = original packet may
>>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present= , preceding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are proces= sed when the packets
>>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments fo= r reassembly.=C2=A0 Only
>>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment = packet are retained in
>>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet.
>>> NEW:
>>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers prec= eding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same = original packet may
>>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present= , preceding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are proces= sed when the packets
>>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments fo= r reassembly.=C2=A0 Only
>>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment = packet are retained in
>>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet; however, nodes tha= t support Explicit
>>>=C2=A0 =C2=A0 =C2=A0 Congestion Notification [RFC3168] may use = information in the
>>>=C2=A0 =C2=A0 =C2=A0 Traffic Class field from all fragment pack= ets to reconstruct the
>>>=C2=A0 =C2=A0 =C2=A0 Traffic Class field in the reassembled pac= ket.
>>>
>>> Note that this would not cause 2460bis itself to levy an addit= ional
>>> requirement on how IPv6 nodes reassemble fragmented packets. I= t would
>>> simply be making note of a requirement that is already levied = by
>>> RFC 3168.
>>
>> In which case, the RFC 3168 requirement should be stated e.g.:
>>
>> OLD:
>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers precedin= g the Fragment
>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same orig= inal packet may
>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present, pr= eceding the Fragment
>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are processed = when the packets
>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments for re= assembly.=C2=A0 Only
>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment pack= et are retained in
>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet.
>> NEW:
>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers precedin= g the Fragment
>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same orig= inal packet may
>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present, pr= eceding the Fragment
>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are processed = when the packets
>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments for re= assembly.=C2=A0 Only
>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment pack= et are retained in
>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet; however, nodes that su= pport Explicit
>>=C2=A0 =C2=A0 =C2=A0 Congestion Notification [RFC3168] may use info= rmation in the
>>=C2=A0 =C2=A0 =C2=A0 Traffic Class field from any or all fragment p= ackets to reconstruct
>>=C2=A0 =C2=A0 =C2=A0 the Traffic Class field in the reassembled pac= ket in order to meet
>>=C2=A0 =C2=A0 =C2=A0 RFC 3168's requirements, e.g., that reasse= mbly not lose indications
>>=C2=A0 =C2=A0 =C2=A0 of congestion, see Section 5.3 of RFC 3168 for= additional information.
>>
>> Pointing the implementer at Section 5.3 of RFC 3168 is better than=
>> hoping she figures out on her own that she ought to take a look at= it .
>
> Yes. This is correct.
>
>=C2=A0 =C2=A0Brian
>
>>
>> Thanks, --David
>>
>>> -----Original Message-----
>>> From: tsvwg [mailto:= tsvwg-bounces@ietf.org] On Behalf Of C. M. Heard
>>> Sent: Monday, April 17, 2017 12:00 PM
>>> To: 6MAN <6man@ietf.org>; tsvwg <tsvwg@ietf.org> >>> Cc: dra= ft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden
>>> <bob.hinden@gmail.c= om>; Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>;
>>> IESG <iesg@ietf.org>= ;; 6man Chairs <6man-chairs@ietf= .org>
>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on dra= ft-ietf-6man-rfc2460bis-
>>> 09: (with DISCUSS and COMMENT)
>>>
>>> [ TSVWG added to solicit advice on implementation of RFC 3186 = Section 5.3 ]
>>>
>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote:
>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard <heard@pobox.com> wrote:
>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter w= rote:
>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote= :
>>>>>> ...
>>>>>>>>>>> ------------------------------= ----------------------------------------
>>>>>>>>>>> COMMENT:
>>>>>>>>>>> ------------------------------= ----------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> One question because I'm n= ot sure if I interpret this correct to
>>> make it
>>>>>>>>>>> part of my discuss:
>>>>>>>>>>> Section 4.5: "The number = and content of the headers preceding
>>> the
>>>>>>>>>>> Fragment
>>>>>>>>>>> header of different fragments = of the same original packet may
>>>>>>>>>>> differ.=C2=A0 Whatever headers= are present, preceding the Fragment
>>>>>>>>>>> header in each fragment packet= , are processed when the packets
>>>>>>>>>>> arrive, prior to queueing the = fragments for reassembly.=C2=A0 Only
>>>>>>>>>>> those headers in the Offset ze= ro fragment packet are retained in
>>>>>>>>>>> the reassembled packet."<= br> >>>>>>>>>>> Does this mean the ECN codepoi= nt (part of the Traffic Class field)
>>> is
>>>>>>>>>>> copied from the first fragment= ? This doesn't seem to be correct,
>>> however,
>>>>>>>>>>> also not sure what the correct= answer is. I know this was not
>>> changed in
>>>>>>>>>>> this revision but maybe we can= still get this right.
>>>>>>>>>>
>>>>>>>>>> When fragments are created most of= the fields are copied from the
>>> IPv6
>>>>>>>>>> headers (e.g., Source Address, Des= tination address, flow label,
>>> traffic
>>>>>>>>>> class, hop limit).=C2=A0 Some like= payload length, next header, and hop
>>> limi
>>>>>>>>>> t are modified.
>>>>>>>>>>
>>>>>>>>>> If I understand your question, the= answer is yes, the ECN code
>>> point is
>>>>>>>>>> copied from the first fragment, bu= t should be the same from all of
>>> the
>>>>>>>>>> fragments.
>>>>>
>>>>> That is inconsistent with the following guidance in RF= C 3168 (see
>>>>> https://tools.ietf.org/html/rfc3168#section-5.3):
>>>>>
>>>>> 5.3.=C2=A0 Fragmentation
>>>>>
>>>>>=C2=A0 ECN-capable packets MAY have the DF (Don't F= ragment) bit set.
>>>>>=C2=A0 Reassembly of a fragmented packet MUST NOT lose = indications of
>>>>>=C2=A0 congestion.=C2=A0 In other words, if any fragmen= t of an IP packet to be
>>>>>=C2=A0 reassembled has the CE codepoint set, then one o= f two actions MUST be
>>>>>=C2=A0 taken:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0* Set the CE codepoint on the reass= embled packet.=C2=A0 However, this
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT occur if any of the= other fragments contributing to
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0this reassembly carries the = Not-ECT codepoint.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0* The packet is dropped, instead of= being reassembled, for any
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0other reason.
>>>>>
>>>>>=C2=A0 If both actions are applicable, either MAY be ch= osen.=C2=A0 Reassembly of
>>>>>=C2=A0 a fragmented packet MUST NOT change the ECN code= point when all of
>>> the
>>>>>=C2=A0 fragments carry the same codepoint.
>>>>>
>>>>>>>>> My concern is that the ECN code point = could be changed on one of
>>> the
>>>>>>>>> fragmented packets to signal congestio= n of a intermediate node and
>>>>>>>>> then when you reassemble this informat= ion gets lost. That seems
>>> wrong.
>>>>>>>>
>>>>>>>> That is an interesting idea, but I think o= ut of scope for advancing this
>>>>>>>> document to Internet Standard.=C2=A0 Then = there is the question of how to
>>>>>>>> encode n of m fragments experienced conges= tion.=C2=A0 Interesting future
>>> work.
>>>>>>>
>>>>>>> Yes there might be some more further work need= ed but that still
>>> makes the
>>>>>>> guidance in this text wrong. Maybe we can add = some text that the
>>> Traffic
>>>>>>> Class may be handled differently because it co= uld be changed on the
>>> path.
>>>>>>
>>>>>> Good point. It's not only ECN that can change;= the DSCP can change too.
>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460= , so it's logical
>>>>>> for 2460bis to note this issue.
>>>>>
>>>>> It seems that we (6man WG) missed this because RFC 316= 8 was not
>>> marked
>>>>> as updating RFC 2460. But in effect it did so for IPv6= implementations
>>>>> of ECN, even though it was not written in an IP versio= n-agnostic manner.
>>>>>
>>>>> At the very least text should be added to the descript= ion of the
>>>>> reassembly process that points the reader to RFC 3168 = or its
>>>>> successor document.
>>>>
>>>> Do we have any evidence that the guidance in RFC 3168 rega= rding
>>> reassembling
>>>> IPv6 fragments is implemented?=C2=A0 I don=E2=80=99t know,= but think if it there is
>>>> evidence I agree some text should be added to rfc2460bis, = if not, then
>>>> maybe not.
>>>
>>> Since I lack the expertise to answer that question, I'm ho= ping that someone
>>> in TSVWG will see this message and do so.
>>>
>>> Regardless of the answer to that question, my position would b= e that since
>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of
>>> the Traffic Class field, the following modification to 2460bis= Section 4.5
>>> would be an appropriate way to deal with Mirja's comment:<= br> >>>
>>> OLD:
>>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers prec= eding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same = original packet may
>>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present= , preceding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are proces= sed when the packets
>>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments fo= r reassembly.=C2=A0 Only
>>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment = packet are retained in
>>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet.
>>> NEW:
>>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers prec= eding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same = original packet may
>>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present= , preceding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are proces= sed when the packets
>>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments fo= r reassembly.=C2=A0 Only
>>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment = packet are retained in
>>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet; however, nodes tha= t support Explicit
>>>=C2=A0 =C2=A0 =C2=A0 Congestion Notification [RFC3168] may use = information in the
>>>=C2=A0 =C2=A0 =C2=A0 Traffic Class field from all fragment pack= ets to reconstruct the
>>>=C2=A0 =C2=A0 =C2=A0 Traffic Class field in the reassembled pac= ket.
>>>
>>> Note that this would not cause 2460bis itself to levy an addit= ional
>>> requirement on how IPv6 nodes reassemble fragmented packets. I= t would
>>> simply be making note of a requirement that is already levied = by
>>> RFC 3168.
>>>
>>> Thanks and regards,
>>>
>>> Mike Heard
>>
>> ------------------------------------------------------------<= wbr>--------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mai= lman/listinfo/ipv6
>> ------------------------------------------------------------<= wbr>--------
>>
>


--94eb2c190326a8055a054d639558-- From nobody Mon Apr 17 15:00:43 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C73313157A for ; Mon, 17 Apr 2017 15:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8UFMyIuUiIj for ; Mon, 17 Apr 2017 15:00:40 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A9F1292D0 for ; Mon, 17 Apr 2017 15:00:40 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id h67so116090823qke.0 for ; Mon, 17 Apr 2017 15:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NtBZ/8H8pF6TEnQDRC05IzAcwvdYFz7elIzcDSTDxYc=; b=g1J9LTIJFEXadoLDa+wEyS8uO/2gb9iw59xju5IbXywpvfhddJq4wZ1yOP6LWlWbk2 w/DipSe1UaPGnjzdpKT1snU4bA3TkPMu6MBgGPN8jRzHh1RKaVzJ3onFDZadEktW1r2T DE8SCfTCfi9IWzKSUV1wVElCQrUDOJcx8kB5PidYDfnx/UzqpzKJTdOOkNNJe83TMpIs ISXrGTOWRVwvw1RqR2SmGaDOLMD1Ye0MRndwGFgapGa1WPGYw7N7mPxo7QYd6idi6N9D zzl9IfiQHXJHTHmCaxk+qcelq38WkfqM+nzrEP0ZgFuInxNhVLic1//oVqxlvmj/VpEF H8CA== 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=NtBZ/8H8pF6TEnQDRC05IzAcwvdYFz7elIzcDSTDxYc=; b=aVK6+HEEGE2rrq91yVjFW6ocHtY4uuXqV+ft6+jVkLEWVXWBblSUPVSFoy7Zs1dmrX djI//Gc3COZjtWKNJzDC8nwmArzUq8Ru07H3UIocIA2NUP38VMKlLFa9QXNTPQ+gjwRh 52xnwQb2q4R4vL1okjddV5yxcPpCHhIIpTRKIONvAh+wZllMRL8lJUJOBrgcRZy74hrm RnjX1OCAZt2f4YIg+2SLfvFiLQfm/kDc6M2Khg8HHeGwXWdiOscBEtKlZA8JAA3v1Vfx 5ahL8tdRwkFg6X/qLkjaxxPgDqd7jfJH2HY5gnS6O3j/0KJX7VtxbkY/NlMxBR9vWgVO CbRQ== X-Gm-Message-State: AN3rC/7jdSC6w/0jfIViu2Q2BiomuRQ4KS/cT/QRW0iHEc506HJstWD9 ii9H5QHPkIhALuLboRpBWHch1DGUPg== X-Received: by 10.55.191.69 with SMTP id p66mr10388868qkf.77.1492466439534; Mon, 17 Apr 2017 15:00:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 17 Apr 2017 15:00:38 -0700 (PDT) In-Reply-To: <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> From: Tom Herbert Date: Mon, 17 Apr 2017 15:00:38 -0700 Message-ID: To: Joe Touch Cc: "gorry@erg.abdn.ac.uk" , tsvwg Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:00:42 -0000 On Mon, Apr 17, 2017 at 2:07 PM, Joe Touch wrote: > > > On 4/17/2017 1:47 PM, Tom Herbert wrote: >> ... >>> >>>> One thing that might be missing from the draft is middle box handling. >>> This is already discussed extensively in the document, including in >>> response to previous TSVWG discussion. That's why we now default to >>> using the OCS and a length validation. Do you have specific concerns? > ... > >>> >>>> and so middleboxes must pass packets with UDP options, >>>> should not attempt to parse the UDP options, and must not modify >>>> options. >>> We already addressed that in the doc. >> I'm sorry, which section is this info in? > The doc talks about legacy issues throughout. > > Sec 5.3 talks about the option checksum and Sec 9 talks about > interactions with legacy devices in general. > > Section 7 explicitly indicates that these are for transport endpoint use > only. > > I don't think we should be writing rules to indicate who should NOT be > changing them, if we already have rules indicating the only parties that > can. (granted, the requirement in 7 needs to be revised in 2119-speak). > Joe, You may want to look at IPv6 EH description for guidance. Even with all the words about how extension headers can't be examined or processed with the exception of HBH options, there still has been considerable discussion on what intermediate devices can or can't do. Clarifying the exact requirements upfront is beneficial. In the absence of such clarity, we need to assume that anything in clear text is subject to inspection and possible modification so that the end result is often ossification of what might have otherwise been a useful feature (although even with clear requirements abuse and ossification is still a possibility). Neither can we expect middleboxes to always know what they're doing. Fundamentally, if I, as an application developer, can't trust the network not do mess with my UDP options, it's likely I simply wouldn't use them (hence ossification even before deployment). Tom > Joe > > > > > > From nobody Mon Apr 17 15:10:22 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45C0131597 for ; Mon, 17 Apr 2017 15:10:19 -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 gQD_vMj5GUXs for ; Mon, 17 Apr 2017 15:10:18 -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 A2D4413158A for ; Mon, 17 Apr 2017 15:10:18 -0700 (PDT) Received: from [128.9.184.37] ([128.9.184.37]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3HM9WSE001773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Apr 2017 15:09:33 -0700 (PDT) To: Tom Herbert References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> Cc: "gorry@erg.abdn.ac.uk" , tsvwg From: Joe Touch Message-ID: Date: Mon, 17 Apr 2017 15:09:31 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3HM9WSE001773 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:10:20 -0000 Hi, Tom, On 4/17/2017 3:00 PM, Tom Herbert wrote: > On Mon, Apr 17, 2017 at 2:07 PM, Joe Touch wrote: >> ... >> I don't think we should be writing rules to indicate who should NOT be >> changing them, if we already have rules indicating the only parties that >> can. (granted, the requirement in 7 needs to be revised in 2119-speak). >> > Joe, > > You may want to look at IPv6 EH description for guidance. Even with > all the words about how extension headers can't be examined or > processed with the exception of HBH options, there still has been > considerable discussion on what intermediate devices can or can't do. The situation is completely different. IP is intended for inspection - and HBH headers for modification - by network devices other than the endpoints. Transport headers have no such role. Any device that tampers with transport headers already needs to be (effectively) an endpoint or acting on the behalf of an endpoint. > Clarifying the exact requirements upfront is beneficial. Yes, which has already been done. These are declared as owned by and for the use of the endpoints, just like the transport header. We don't have documents that declare that TCP headers or options MUST NOT be modified by middleboxes, even though that's always been effectively the case. The only way a middlebox gets around that rule is by assuming the behavior of an endpoint, essentially. > In the > absence of such clarity, we need to assume that anything in clear text > is subject to inspection and possible modification We already have docs describing (true) transport and network layer security. If you don't want data inspected or modified, that's the only solution. I see no reason to declare anything special about middleboxes here. Frankly, they can modify these options just like they modify the UDP header - at their own risk. > so that the end > result is often ossification of what might have otherwise been a > useful feature (although even with clear requirements abuse and > ossification is still a possibility). Neither can we expect > middleboxes to always know what they're doing. Fundamentally, if I, as > an application developer, can't trust the network not do mess with my > UDP options, it's likely I simply wouldn't use them (hence > ossification even before deployment). Do you use TCP options? How and why should these be different? Joe From nobody Mon Apr 17 15:26:32 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAECE1315A7 for ; Mon, 17 Apr 2017 15:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 r4c2Rr7QbQso for ; Mon, 17 Apr 2017 15:26:29 -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 CD00A13159A for ; Mon, 17 Apr 2017 15:26:29 -0700 (PDT) Received: from [128.9.184.37] ([128.9.184.37]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3HMQ0rr008404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Apr 2017 15:26:00 -0700 (PDT) To: Tom Herbert References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> Cc: "gorry@erg.abdn.ac.uk" , tsvwg From: Joe Touch Message-ID: Date: Mon, 17 Apr 2017 15:25:59 -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: Content-Type: multipart/alternative; boundary="------------0E5ADB72A8EF5AD3556C21C9" X-MailScanner-ID: v3HMQ0rr008404 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:26:31 -0000 This is a multi-part message in MIME format. --------------0E5ADB72A8EF5AD3556C21C9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/17/2017 3:09 PM, Joe Touch wrote: > Hi, Tom, > > > On 4/17/2017 3:00 PM, Tom Herbert wrote: >> On Mon, Apr 17, 2017 at 2:07 PM, Joe Touch wrote: >>> ... >>> I don't think we should be writing rules to indicate who should NOT be >>> changing them, if we already have rules indicating the only parties that >>> can. (granted, the requirement in 7 needs to be revised in 2119-speak). >>> >> Joe, >> >> You may want to look at IPv6 EH description for guidance. Even with >> all the words about how extension headers can't be examined or >> processed with the exception of HBH options, there still has been >> considerable discussion on what intermediate devices can or can't do. For the benefit of others on this list who might not have followed this issue, FWIW, this discussion happened during the revision of RFC2460 on the v6ops and main IETF list. RFC 2460 said the following: With one exception, extension headers are not examined or processed by any node along a packet's delivery path The one exception was HBH headers. Discussion centered around a few issues: - 2460 said "not examined or processed" - did that include inserting or deleting new EHs, which might arguably require neither examining nor processing? - what does "processing" mean? (does it include altering? does it include making a header longer or shorter?) - would not adding new EHs ossify IPv6? It took a while to converge on the following: - that text now explicitly excludes inserting or deleting EHs - there are still arguments about what "processing" means, but that term was accepted, given the clarification of inserting/deleting as distinct operations - it was clarified (at least on the mailing lists) that the HBH itself is already extensible, so disabling new EHs that change en-route wasn't ossifying ------ For IPv6, this might have been important because it already did specify cases where some EHs were modified in transit while others were not. That's not the case for transport options, which is why I believe it is unnecessary to provide detail on what devices en-route shouldn't be doing. Joe --------------0E5ADB72A8EF5AD3556C21C9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 4/17/2017 3:09 PM, Joe Touch wrote:
Hi, Tom,


On 4/17/2017 3:00 PM, Tom Herbert wrote:

On Mon, Apr 17, 2017 at 2:07 PM, Joe Touch <touch@isi.edu> wrote:

...
I don't think we should be writing rules to indicate who should NOT be
changing them, if we already have rules indicating the only parties that
can. (granted, the requirement in 7 needs to be revised in 2119-speak).


Joe,

You may want to look at IPv6 EH description for guidance. Even with
all the words about how extension headers can't be examined or
processed with the exception of HBH options, there still has been
considerable discussion on what intermediate devices can or can't do.

For the benefit of others on this list who might not have followed this issue, FWIW, this discussion happened during the revision of RFC2460 on the v6ops and main IETF list.

RFC 2460 said the following:
   With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path
The one exception was HBH headers.

Discussion centered around a few issues:
    - 2460 said "not examined or processed" - did that include inserting or deleting new EHs, which might arguably require neither examining nor processing?
    - what does "processing" mean? (does it include altering? does it include making a header longer or shorter?)
    - would not adding new EHs ossify IPv6?

It took a while to converge on the following:
    - that text now explicitly excludes inserting or deleting EHs
    - there are still arguments about what "processing" means, but that term was accepted, given the clarification of inserting/deleting as distinct operations
    - it was clarified (at least on the mailing lists) that the HBH itself is already extensible, so disabling new EHs that change en-route wasn't ossifying

------
For IPv6, this might have been important because it already did specify cases where some EHs were modified in transit while others were not.

That's not the case for transport options, which is why I believe it is unnecessary to provide detail on what devices en-route shouldn't be doing.

Joe


--------------0E5ADB72A8EF5AD3556C21C9-- From nobody Mon Apr 17 15:31:43 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE4C1242F7 for ; Mon, 17 Apr 2017 15:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bseEH0MhJIw for ; Mon, 17 Apr 2017 15:31:39 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B275B1315AB for ; Mon, 17 Apr 2017 15:31:39 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id m36so112160357qtb.0 for ; Mon, 17 Apr 2017 15:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MyD2ng+lL/zLXDZzL6UV1nxcxilyQTi/57cPGhXlFjA=; b=ERUTrmERrWd1gTQrMh0uNylvwpsIgxuWkqf52dFWkIdczQdbRMiuSe+QMSMZ9DVK6D 5ENer2iRfB9KahyRCAiM2xzAQvj9QbI2ltViYhRUeEhVVb/dtVUfo9L5cPy8RoEip1Im 1jI08rukclXo6OWKbVIiDvuNwlSeRqpiTji3jSwxS23ld3Ri+ppsjo1Ysw/qVt4KfuY+ v1qVZidDJY7Y43jxkZYPd3uKPsmlWGaUFm0jUPPr6pWjZKMF8XvqoKAxX1Hgm/6Vu52r mo9x8O0vJxETbGnkZsSAAGC155O/gOyx+rymbPxEa69pRyqRJQUb6kPIQ7y0Xlibjikq cqeg== 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=MyD2ng+lL/zLXDZzL6UV1nxcxilyQTi/57cPGhXlFjA=; b=DaVN0Y32RhfPzDlWvTXSwy36u9MxgCiGEvQTfBEbJPUwYP7xxt6PyYZunQA2NIhIiq jkXYLRztUgc1Gf59BCLfYbRDPow80jlymv6QngZBVkBiIsM0xv87Q7qlIL0URK1f4msw 6Ibcp51G1H1gBzb8ap5ruBPCEZHBcY3qbOu+Cg1eyXbadJ4H7IRJWBDYeUj+1kK8QcD2 /DTMTfB8e0DoiyyKxCygAcRiq4Bz5kntr+HqveN/3yG4NZZDpQwCRn6McLOslGMvOsmP rNBk5tio+h9byIFpjd6urCoRMIOzTJ5QTvN3Utly7iZyVcOgYjia15tv5QAOXVbtB2LW q+1A== X-Gm-Message-State: AN3rC/4+CdAeQvIehYJwNt9zaJein25seMrEhvhvObds399iuV1xv/2B 4lWiIJ2mAOivehFg5JJq8WCu2gDOGQ== X-Received: by 10.200.45.122 with SMTP id o55mr11188479qta.203.1492468298748; Mon, 17 Apr 2017 15:31:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 17 Apr 2017 15:31:38 -0700 (PDT) In-Reply-To: References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> From: Tom Herbert Date: Mon, 17 Apr 2017 15:31:38 -0700 Message-ID: To: Joe Touch Cc: "gorry@erg.abdn.ac.uk" , tsvwg Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:31:41 -0000 On Mon, Apr 17, 2017 at 3:09 PM, Joe Touch wrote: > Hi, Tom, > > > On 4/17/2017 3:00 PM, Tom Herbert wrote: >> On Mon, Apr 17, 2017 at 2:07 PM, Joe Touch wrote: >>> ... >>> I don't think we should be writing rules to indicate who should NOT be >>> changing them, if we already have rules indicating the only parties that >>> can. (granted, the requirement in 7 needs to be revised in 2119-speak). >>> >> Joe, >> >> You may want to look at IPv6 EH description for guidance. Even with >> all the words about how extension headers can't be examined or >> processed with the exception of HBH options, there still has been >> considerable discussion on what intermediate devices can or can't do. > The situation is completely different. > > IP is intended for inspection - and HBH headers for modification - by > network devices other than the endpoints. > > Transport headers have no such role. Any device that tampers with > transport headers already needs to be (effectively) an endpoint or > acting on the behalf of an endpoint. > >> Clarifying the exact requirements upfront is beneficial. > Yes, which has already been done. These are declared as owned by and for > the use of the endpoints, just like the transport header. > > We don't have documents that declare that TCP headers or options MUST > NOT be modified by middleboxes, even though that's always been > effectively the case. The only way a middlebox gets around that rule is > by assuming the behavior of an endpoint, essentially. > >> In the >> absence of such clarity, we need to assume that anything in clear text >> is subject to inspection and possible modification > > We already have docs describing (true) transport and network layer > security. If you don't want data inspected or modified, that's the only > solution. > > I see no reason to declare anything special about middleboxes here. > Frankly, they can modify these options just like they modify the UDP > header - at their own risk. > >> so that the end >> result is often ossification of what might have otherwise been a >> useful feature (although even with clear requirements abuse and >> ossification is still a possibility). Neither can we expect >> middleboxes to always know what they're doing. Fundamentally, if I, as >> an application developer, can't trust the network not do mess with my >> UDP options, it's likely I simply wouldn't use them (hence >> ossification even before deployment). > Do you use TCP options? > > How and why should these be different? > TCP options are pretty much required for operation of the TCP protocol, this is why they will never be ossified and why it's one of the few methods of protocol extensibility that is viable on the Internet. IP options on the other hand were never required for IP to operate hence they were quickly ossified. In this context, UDP options are more like IP options since they are not required for use with UDP. So there is a possibility that some vendors (e.g. a firewall) may just decide that to start dropping packets or throwing packets that might have them into a slow path similar to IP options. If something like this is not consistently supported in the Internet, then applications are unlikely to use it. I wish this wasn't reality and that the end to end model was actually adhered to, but when writing Internet applications we have to stick with what is known to work... ie. plain TCP/IP or UDP/IP (where support for the latter is still a little shaky since some network operators refer to think of UDP as nothing more than a DOS vector). Tom > Joe From nobody Mon Apr 17 15:43:33 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442C3126DD9 for ; Mon, 17 Apr 2017 15:43:32 -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, HTML_MESSAGE=0.001, 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 W_1VQUjmRFDK for ; Mon, 17 Apr 2017 15:43:30 -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 AEE761242F7 for ; Mon, 17 Apr 2017 15:43:30 -0700 (PDT) Received: from [128.9.184.37] ([128.9.184.37]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3HMgp5K012774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Apr 2017 15:42:51 -0700 (PDT) To: Tom Herbert References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> Cc: "gorry@erg.abdn.ac.uk" , tsvwg From: Joe Touch Message-ID: <8aa5b87d-62bb-eba5-5ef4-67d107cb10e0@isi.edu> Date: Mon, 17 Apr 2017 15:42:50 -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: Content-Type: multipart/alternative; boundary="------------12D70393AD2D8ED7862AF556" X-MailScanner-ID: v3HMgp5K012774 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 22:43:32 -0000 This is a multi-part message in MIME format. --------------12D70393AD2D8ED7862AF556 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/17/2017 3:31 PM, Tom Herbert wrote: >> Do you use TCP options? >> >> How and why should these be different? >> > TCP options are pretty much required for operation of the TCP > protocol, You can run TCP with no options just fine - but not efficiently. > this is why they will never be ossified and why it's one of > the few methods of protocol extensibility that is viable on the > Internet. They are somewhat ossified in that there are offload devices and middleboxes that work only with known subsets of options. In some cases, those features have work-arounds when unknown or unsupported options are seen - but not always. > IP options on the other hand were never required for IP to > operate hence they were quickly ossified. I'm not sure you're using the term 'ossified' the way others do. For IPv4, options were not so much "turned to stone" as they were deprecated because fast-path processing never supported them. For IPv6, that's not as true because of the way the options are layered rather than tacked-on. > In this context, UDP options > are more like IP options since they are not required for use with UDP. Just like TCP, option support is determined by which options are activated and the semantics of the options and user (application) preferences. Whether they're required or not depends on the endpoint's decision of how they use the options. An endpoint could require particular options and backoff to TCP where the options are not supported, e.g., DNSSEC might require FRAG or backoff to TCP. > So there is a possibility that some vendors (e.g. a firewall) may just > decide that to start dropping packets or throwing packets that might > have them into a slow path similar to IP options. If something like > this is not consistently supported in the Internet, then applications > are unlikely to use it. I wish this wasn't reality and that the end to > end model was actually adhered to, but when writing Internet > applications we have to stick with what is known to work... ie. plain > TCP/IP or UDP/IP (where support for the latter is still a little shaky > since some network operators refer to think of UDP as nothing more > than a DOS vector). Certainly, but so far all we have evidence of are over-eager firewalls that incorrectly think that UDP packets whose transport portion are smaller than the IP payload are an error. That's just as incorrect as thinking that it's "safer" to drop all TCP packets that support MPTCP. So yes, like any extension, it works only where the Internet lets it. It can be useful where needed or preferred, but like any extension, there's always the possibility that some ignorant party will try to block it in the name of security. Again, not new and just like TCP. Joe --------------12D70393AD2D8ED7862AF556 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 4/17/2017 3:31 PM, Tom Herbert wrote:
Do you use TCP options?

How and why should these be different?


TCP options are pretty much required for operation of the TCP
protocol,

You can run TCP with no options just fine - but not efficiently.

this is why they will never be ossified and why it's one of
the few methods of protocol extensibility that is viable on the
Internet.
They are somewhat ossified in that there are offload devices and middleboxes that work only with known subsets of options. In some cases, those features have work-arounds when unknown or unsupported options are seen - but not always.

 IP options on the other hand were never required for IP to
operate hence they were quickly ossified.
I'm not sure you're using the term 'ossified' the way others do.

For IPv4, options were not so much "turned to stone" as they were deprecated because fast-path processing never supported them.

For IPv6, that's not as true because of the way the options are layered rather than tacked-on.

 In this context, UDP options
are more like IP options since they are not required for use with UDP.
Just like TCP, option support is determined by which options are activated and the semantics of the options and user (application) preferences. Whether they're required or not depends on the endpoint's decision of how they use the options. An endpoint could require particular options and backoff to TCP where the options are not supported, e.g., DNSSEC might require FRAG or backoff to TCP.

So there is a possibility that some vendors (e.g. a firewall) may just
decide that to start dropping packets or throwing packets that might
have them into a slow path similar to IP options. If something like
this is not consistently supported in the Internet, then applications
are unlikely to use it. I wish this wasn't reality and that the end to
end model was actually adhered to, but when writing Internet
applications we have to stick with what is known to work... ie. plain
TCP/IP or UDP/IP (where support for the latter is still a little shaky
since some network operators refer to think of UDP as nothing more
than a DOS vector).
Certainly, but so far all we have evidence of are over-eager firewalls that incorrectly think that UDP packets whose transport portion are smaller than the IP payload are an error. That's just as incorrect as thinking that it's "safer" to drop all TCP packets that support MPTCP.

So yes, like any extension, it works only where the Internet lets it. It can be useful where needed or preferred, but like any extension, there's always the possibility that some ignorant party will try to block it in the name of security.

Again, not new and just like TCP.

Joe
--------------12D70393AD2D8ED7862AF556-- From nobody Mon Apr 17 17:39:14 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963B2129401; Mon, 17 Apr 2017 17:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rFNbR36LiqyA; Mon, 17 Apr 2017 17:38:53 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 1CA5B126C2F; Mon, 17 Apr 2017 17:38:53 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id a188so27687228pfa.2; Mon, 17 Apr 2017 17:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=oPu5m61HwrvsKOIhI5E0aP+tuxuDW2SNltPFe76dH0U=; b=qW/Moe3FKmS34YqU2Fso3ps4fNLJVTFLq5UQhueOfM93NT/Qh8DIq+74/S/K0evWRd hxXg+Zoh4ytM6sSzXCdTbA23Dggg5JcbuBDCjMOMa3cLGmPcyk1QPqUSVjVyBtjFUyo8 bbtd6QQQfyRkLygNzqjV5ccahapqrJuJPF6a1VPmqiva8SUGqnzmdKJpMgP7tbgc5g3K xfafUOgUUxPG8FUVpxV5Hyhm6NvfHjc/pVFZ7TQid7NZF3eoMbzan7+Kw30gVaXVhhdd iHhPqsQKZWcJ6UixsoXNCMIXr14qxoalpXUpIbODW21/VQtCKlcUH2BtNN5G+JO3jYCM kccA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=oPu5m61HwrvsKOIhI5E0aP+tuxuDW2SNltPFe76dH0U=; b=VlKGi7VtX2VO74ov32d9NRRycQLB1zER0DypONfm1BWvkJiGTSb8aiD0/aP0n6pjdf JJk1EXVrnf22dHUitPxXH/AZnm9AkLDBiTTqnnaIsIzfpJpUXNR6GTE0jvWDcJBupOxS ggqouguk7o3emlNWlmv4f32dwYDUE5vvVYsiM9qdECZ1+R1tRHEjsLzTmNVFEU1K2q7y 1IUHJcWrbUWKSchfU4T4gYSj/vTHvRTzulEiE9ZBYWFtOyAHG3+L0XAWGriZWy1TXBZA +3y6wIFA9exXAWY84CQhfXIbhCmDzRVcm/vEC29i3r/2voCdWtVveSAIs4qGkOYmi3EM V6+w== X-Gm-Message-State: AN3rC/4zAGx2n8PRafTEzZ43MNRzSpIqp16IVMY1bYvu8goHJ4Qt19xi c1jd3wuwf1U1Bg== X-Received: by 10.99.109.75 with SMTP id i72mr12306200pgc.215.1492475932613; Mon, 17 Apr 2017 17:38:52 -0700 (PDT) Received: from ?IPv6:2406:e001:3f9b:1:28cc:dc4c:9703:6781? ([2406:e001:3f9b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l22sm17218141pfi.2.2017.04.17.17.38.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 17:38:52 -0700 (PDT) To: Bob Hinden References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> Cc: "Black, David" , "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg , "draft-ietf-6man-rfc2460bis@ietf.org" , "Mirja Kuehlewind (IETF)" , IESG , 6man Chairs <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> Date: Tue, 18 Apr 2017 12:38:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 00:38:56 -0000 wfm=20 On 18/04/2017 09:08, Bob Hinden wrote: > Hi, >=20 > After reading through the discussion, I think a new paragraph (after th= e text that says how to construct a reassembled packet) like the followin= g would be appropriate. >=20 > Nodes that support Explicit Congestion Notification [RFC3168] > should use information in the Traffic Class field from all > fragment packets to reconstruct the Traffic Class field in the= > reassembled packet. See Section 5.3 of RFC3168 for more > information. >=20 > I don=E2=80=99t think we need to quote what RFC3168 says, just point th= e the correct section. >=20 > This also doesn=E2=80=99t effect nodes that don=E2=80=99t support ECN, = so it shouldn't be making any new requirements. >=20 > Comments? >=20 > Bob >=20 >> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter wrote: >> >> In line... >> >> On 18/04/2017 05:44, Black, David wrote: >>> Extracting the key portions of text: >>> >>>>> That is inconsistent with the following guidance in RFC 3168 (see >>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>> >>>>> 5.3. Fragmentation >>>>> >>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>> congestion. In other words, if any fragment of an IP packet to be= >>>>> reassembled has the CE codepoint set, then one of two actions MUST= be >>>>> taken: >>>>> >>>>> * Set the CE codepoint on the reassembled packet. However, thi= s >>>>> MUST NOT occur if any of the other fragments contributing to >>>>> this reassembly carries the Not-ECT codepoint. >>>>> >>>>> * The packet is dropped, instead of being reassembled, for any >>>>> other reason. >>>>> >>>>> If both actions are applicable, either MAY be chosen. Reassembly = of >>>>> a fragmented packet MUST NOT change the ECN codepoint when all of = the >>>>> fragments carry the same codepoint. >>> >>>> Regardless of the answer to that question, my position would be that= since >>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handli= ng of >>>> the Traffic Class field, the following modification to 2460bis Secti= on 4.5 >>>> would be an appropriate way to deal with Mirja's comment: >>>> >>>> OLD: >>>> The number and content of the headers preceding the Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained i= n >>>> the reassembled packet. >>>> NEW: >>>> The number and content of the headers preceding the Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained i= n >>>> the reassembled packet; however, nodes that support Explicit >>>> Congestion Notification [RFC3168] may use information in the >>>> Traffic Class field from all fragment packets to reconstruct th= e >>>> Traffic Class field in the reassembled packet. >>>> >>>> Note that this would not cause 2460bis itself to levy an additional >>>> requirement on how IPv6 nodes reassemble fragmented packets. It woul= d >>>> simply be making note of a requirement that is already levied by >>>> RFC 3168. >>> >>> In which case, the RFC 3168 requirement should be stated e.g.: >>> >>> OLD: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained in= >>> the reassembled packet. >>> NEW: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained in= >>> the reassembled packet; however, nodes that support Explicit >>> Congestion Notification [RFC3168] may use information in the >>> Traffic Class field from any or all fragment packets to reconstr= uct >>> the Traffic Class field in the reassembled packet in order to me= et >>> RFC 3168's requirements, e.g., that reassembly not lose indicati= ons >>> of congestion, see Section 5.3 of RFC 3168 for additional inform= ation. >>> >>> Pointing the implementer at Section 5.3 of RFC 3168 is better than >>> hoping she figures out on her own that she ought to take a look at it= . >> >> Yes. This is correct. >> >> Brian >> >>> >>> Thanks, --David >>> >>>> -----Original Message----- >>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. Heard= >>>> Sent: Monday, April 17, 2017 12:00 PM >>>> To: 6MAN <6man@ietf.org>; tsvwg >>>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden >>>> ; Mirja Kuehlewind (IETF) ; >>>> IESG ; 6man Chairs <6man-chairs@ietf.org> >>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on draft-ietf-6m= an-rfc2460bis- >>>> 09: (with DISCUSS and COMMENT) >>>> >>>> [ TSVWG added to solicit advice on implementation of RFC 3186 Sectio= n 5.3 ] >>>> >>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>>>>> ... >>>>>>>>>>>> ------------------------------------------------------------= ---------- >>>>>>>>>>>> COMMENT: >>>>>>>>>>>> ------------------------------------------------------------= ---------- >>>>>>>>>>>> >>>>>>>>>>>> One question because I'm not sure if I interpret this correc= t to >>>> make it >>>>>>>>>>>> part of my discuss: >>>>>>>>>>>> Section 4.5: "The number and content of the headers precedin= g >>>> the >>>>>>>>>>>> Fragment >>>>>>>>>>>> header of different fragments of the same original packet ma= y >>>>>>>>>>>> differ. Whatever headers are present, preceding the Fragmen= t >>>>>>>>>>>> header in each fragment packet, are processed when the packe= ts >>>>>>>>>>>> arrive, prior to queueing the fragments for reassembly. Onl= y >>>>>>>>>>>> those headers in the Offset zero fragment packet are retaine= d in >>>>>>>>>>>> the reassembled packet." >>>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class = field) >>>> is >>>>>>>>>>>> copied from the first fragment? This doesn't seem to be corr= ect, >>>> however, >>>>>>>>>>>> also not sure what the correct answer is. I know this was no= t >>>> changed in >>>>>>>>>>>> this revision but maybe we can still get this right. >>>>>>>>>>> >>>>>>>>>>> When fragments are created most of the fields are copied from= the >>>> IPv6 >>>>>>>>>>> headers (e.g., Source Address, Destination address, flow labe= l, >>>> traffic >>>>>>>>>>> class, hop limit). Some like payload length, next header, an= d hop >>>> limi >>>>>>>>>>> t are modified. >>>>>>>>>>> >>>>>>>>>>> If I understand your question, the answer is yes, the ECN cod= e >>>> point is >>>>>>>>>>> copied from the first fragment, but should be the same from a= ll of >>>> the >>>>>>>>>>> fragments. >>>>>> >>>>>> That is inconsistent with the following guidance in RFC 3168 (see >>>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>> >>>>>> 5.3. Fragmentation >>>>>> >>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>>> congestion. In other words, if any fragment of an IP packet to b= e >>>>>> reassembled has the CE codepoint set, then one of two actions MUS= T be >>>>>> taken: >>>>>> >>>>>> * Set the CE codepoint on the reassembled packet. However, th= is >>>>>> MUST NOT occur if any of the other fragments contributing to= >>>>>> this reassembly carries the Not-ECT codepoint. >>>>>> >>>>>> * The packet is dropped, instead of being reassembled, for any= >>>>>> other reason. >>>>>> >>>>>> If both actions are applicable, either MAY be chosen. Reassembly= of >>>>>> a fragmented packet MUST NOT change the ECN codepoint when all of= >>>> the >>>>>> fragments carry the same codepoint. >>>>>> >>>>>>>>>> My concern is that the ECN code point could be changed on one = of >>>> the >>>>>>>>>> fragmented packets to signal congestion of a intermediate node= and >>>>>>>>>> then when you reassemble this information gets lost. That seem= s >>>> wrong. >>>>>>>>> >>>>>>>>> That is an interesting idea, but I think out of scope for advan= cing this >>>>>>>>> document to Internet Standard. Then there is the question of h= ow to >>>>>>>>> encode n of m fragments experienced congestion. Interesting fu= ture >>>> work. >>>>>>>> >>>>>>>> Yes there might be some more further work needed but that still >>>> makes the >>>>>>>> guidance in this text wrong. Maybe we can add some text that the= >>>> Traffic >>>>>>>> Class may be handled differently because it could be changed on = the >>>> path. >>>>>>> >>>>>>> Good point. It's not only ECN that can change; the DSCP can chang= e too. >>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logic= al >>>>>>> for 2460bis to note this issue. >>>>>> >>>>>> It seems that we (6man WG) missed this because RFC 3168 was not >>>> marked >>>>>> as updating RFC 2460. But in effect it did so for IPv6 implementat= ions >>>>>> of ECN, even though it was not written in an IP version-agnostic m= anner. >>>>>> >>>>>> At the very least text should be added to the description of the >>>>>> reassembly process that points the reader to RFC 3168 or its >>>>>> successor document. >>>>> >>>>> Do we have any evidence that the guidance in RFC 3168 regarding >>>> reassembling >>>>> IPv6 fragments is implemented? I don=E2=80=99t know, but think if = it there is >>>>> evidence I agree some text should be added to rfc2460bis, if not, t= hen >>>>> maybe not. >>>> >>>> Since I lack the expertise to answer that question, I'm hoping that = someone >>>> in TSVWG will see this message and do so. >>>> >>>> Regardless of the answer to that question, my position would be that= since >>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handli= ng of >>>> the Traffic Class field, the following modification to 2460bis Secti= on 4.5 >>>> would be an appropriate way to deal with Mirja's comment: >>>> >>>> OLD: >>>> The number and content of the headers preceding the Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained i= n >>>> the reassembled packet. >>>> NEW: >>>> The number and content of the headers preceding the Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained i= n >>>> the reassembled packet; however, nodes that support Explicit >>>> Congestion Notification [RFC3168] may use information in the >>>> Traffic Class field from all fragment packets to reconstruct th= e >>>> Traffic Class field in the reassembled packet. >>>> >>>> Note that this would not cause 2460bis itself to levy an additional >>>> requirement on how IPv6 nodes reassemble fragmented packets. It woul= d >>>> simply be making note of a requirement that is already levied by >>>> RFC 3168. >>>> >>>> Thanks and regards, >>>> >>>> Mike Heard >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >=20 From nobody Tue Apr 18 00:30:15 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8306013178B for ; Tue, 18 Apr 2017 00:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 79HC6gQRk4Eo for ; Tue, 18 Apr 2017 00:30:10 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDF3131769 for ; Tue, 18 Apr 2017 00:30:10 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id E43291B01452; Tue, 18 Apr 2017 10:25:45 +0100 (BST) Message-ID: <58F5C07C.4000707@erg.abdn.ac.uk> Date: Tue, 18 Apr 2017 08:30:04 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tom Herbert CC: Joe Touch , tsvwg References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:30:13 -0000 On 17/04/2017, 23:31, Tom Herbert wrote: Joe: How and why should these be different? > Tom: > TCP options are pretty much required for operation of the TCP > protocol, this is why they will never be ossified and why it's one of > the few methods of protocol extensibility that is viable on the > Internet. IP options on the other hand were never required for IP to > operate hence they were quickly ossified. In this context, UDP options > are more like IP options since they are not required for use with UDP. > So there is a possibility that some vendors (e.g. a firewall) may just > decide that to start dropping packets or throwing packets that might > have them into a slow path similar to IP options. If something like > this is not consistently supported in the Internet, then applications > are unlikely to use it. I wish this wasn't reality and that the end to > end model was actually adhered to, but when writing Internet > applications we have to stick with what is known to work... ie. plain > TCP/IP or UDP/IP (where support for the latter is still a little shaky > since some network operators refer to think of UDP as nothing more > than a DOS vector). > > Tom > I have opinions on this para, in that I think options in TCP can be selected by the TCP stack, they do not explicitly need to be turned on or off by applications. A simple example: Timestamp or MSS. If we had similar options for UDP, this could also be automated by the stack (e.g., MSS to know the maximum receive datagram size). I have ideas of a number of such things that could be automatable, and plan to try these as soon as we have a stack that supports this. Sure, options may not be supported by specific paths - although I suspect that enough paths already do support to make it worth trying in many cases. The UDP (plus options) transport stack can then include mechanisms to decide how to handle loss of options, just as TCP stacks do this today. Applications do not need to be involved - perhaps other than to "enable" the sender stack to do the correct thing. Gorry From nobody Tue Apr 18 09:37:26 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC0F127286 for ; Tue, 18 Apr 2017 09:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXTTJFRt0sdA for ; Tue, 18 Apr 2017 09:37:23 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9CB12441E for ; Tue, 18 Apr 2017 09:37:23 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id p68so135103128qke.1 for ; Tue, 18 Apr 2017 09:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XHEEdX+8vtKxyKwRzRgD4ZR3Gg8WiaJxbb23Oh2tghQ=; b=sG44+0+cxH0jzWoO/HQnZWMMqJ3TL5jgC/9GZ84Ww9igUDUQ20FCjJJ4qdLnj+vmLH K1uqzyFRo+s9WYxtVRH6ZftQaZRoLDbZudbfx283BcBnA+/6oZ2UZrLPuI+BpfUIj5CH KoSIVVs483R1IjmomxVaBUFC4gLvnFzIS3KvWa4Xx/LlXWNJOypjhQiteGtFmn1UESnr Sqay/XoCCzdw70626SxZ75jwCeSqS67JFWd3X4YcCt7DQFRULhBxCF9jwmJfciuITpuk yDgujn4o5gE3cNi6RFVg1NbUyyX+S+e9iegT49gOBbtl1kuG1yqz/fiXJesrwLGIACtC y6xg== 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=XHEEdX+8vtKxyKwRzRgD4ZR3Gg8WiaJxbb23Oh2tghQ=; b=QBGFj8sEzJhDFH33X1DBFYFbecPY01yAdSaENhOGlxEm3fdpR77KMLqw9zys5pK8pd tNdqSi+amzQYDZQLm0Ws9dHmcTT5Q5QudL6wfdbww6bAEG/dJg+cTPWBKW52gWtwa+yQ 37Bg02aRmv1kpL0Iudaldj+pOuwxwRCjHvgI3G8njBQaIyQcDwubWaJBK6d5XbfRtZzz 4y+ROQUIi6eOCohDHHwnAxTR8GJqipFL3GHHoivkSm4zh4lOC6sIvZsheqf6pHIG9hga kXIiGU1DQj8qupkLQQgKrvyct/KIADzYplDWn7/e+KhOXtNLF5pCFIpwbYCMYau0o+2G qoWw== X-Gm-Message-State: AN3rC/4WWligEx3y9aPqV5/7bJepPmoY363fFE56TaxRq0igYNaT5N1l /9UND8YzD5C92rVJaElqYH2LOUnD6w== X-Received: by 10.55.89.196 with SMTP id n187mr13470985qkb.322.1492533442177; Tue, 18 Apr 2017 09:37:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 18 Apr 2017 09:37:21 -0700 (PDT) In-Reply-To: <58F5C07C.4000707@erg.abdn.ac.uk> References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> <58F5C07C.4000707@erg.abdn.ac.uk> From: Tom Herbert Date: Tue, 18 Apr 2017 09:37:21 -0700 Message-ID: To: "gorry@erg.abdn.ac.uk" Cc: Joe Touch , tsvwg Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 16:37:25 -0000 On Tue, Apr 18, 2017 at 12:30 AM, Gorry Fairhurst wrote: > On 17/04/2017, 23:31, Tom Herbert wrote: > > Joe: How and why should these be different? >> >> > Tom: > >> TCP options are pretty much required for operation of the TCP >> protocol, this is why they will never be ossified and why it's one of >> the few methods of protocol extensibility that is viable on the >> Internet. IP options on the other hand were never required for IP to >> operate hence they were quickly ossified. In this context, UDP options >> are more like IP options since they are not required for use with UDP. >> So there is a possibility that some vendors (e.g. a firewall) may just >> decide that to start dropping packets or throwing packets that might >> have them into a slow path similar to IP options. If something like >> this is not consistently supported in the Internet, then applications >> are unlikely to use it. I wish this wasn't reality and that the end to >> end model was actually adhered to, but when writing Internet >> applications we have to stick with what is known to work... ie. plain >> TCP/IP or UDP/IP (where support for the latter is still a little shaky >> since some network operators refer to think of UDP as nothing more >> than a DOS vector). >> >> Tom >> > I have opinions on this para, in that I think options in TCP can be selected > by the TCP stack, they do not explicitly need to be turned on or off by > applications. A simple example: Timestamp or MSS. If we had similar options > for UDP, this could also be automated by the stack (e.g., MSS to know the > maximum receive datagram size). I have ideas of a number of such things that > could be automatable, and plan to try these as soon as we have a stack that > supports this. > Gorry, UDP is a connectionless and unreliable protocol, so if the stack were to on its own accord add an MSS to a packet how and no response was seen how would it know the difference between a one way communication and the packet was dropped because some intermediate device enforces IP len == UDP len? My concern with retrofitting UDP is that I don't think it can be done so that all ambiguities are eliminated and hence it will never be completely robust. For instance, in TCP any part of the TCP header after the first twenty bytes must be TCP options-- there is no other possible interpretation of these bits allowed by the protocol. But, correct interpretation of UDP options in the surplus space is inherently probabilistic. Even if we put in checksums and magic numbers and get the probability of misinterpretation very low it will not be zero. If some existing device happens to be adding random bits beyond the UDP header (as the draft points out it was never a requirement that lengths need to match) and this is subsequently misinterpreted as UDP options causing insidious effects, even if this happens just once, it is a problem with the protocol not the implementation. I think ambiguity is manageable if it is only the communicating hosts that process the options and the use of options is expressly enabled for both transmit and receive. If some intermediate device wereto start parsing and possibly modifying options on its own accord this would be exceedingly dangerous in my opinion. Such a problem would potentially be a nightmare to debug in real networks since we don't even have tools that can would analyze trailers. Fortunately, trailers are unlikely to be considered by intermediate devices so this problem is unlikely today. Nevertheless, I think the draft should say up from that intermediate devices MUST NOT process, examine, or modify UDP options. A related concern I have is around security and whether ambiguity can be exploited. For instance, someone could easily forge a UDP fragment using the UDP option. If a device supports UDP options they will interpret this as fragment, if they don't they will see this as plain UDP packet. This are very different interpretations of the same bits however both devices could claim protocol conformance-- that's a potential problem. This becomes a real problem if the ambiguity can be somehow exploited to bypass security. The draft should probably include some more consideration for use with NAT. For instance: "A host SHOULD indicate FRAG support by transmitting an unfragmented datagram using the Fragmentation option" If the host lives behind a NAT this would effectively indicate support for FRAG for all the hosts sitting behind the NAT. I doubt that's the intent! FRAG should probably be based on UDP 4-tuple, but even packets on that flow might not always be going to the same host (an IP anycast destination for example). Also, the draft should mention multicast and whether or not UDP options are allowed with that. Thanks, Tom > Sure, options may not be supported by specific paths - although I suspect > that enough paths already do support to make it worth trying in many cases. > The UDP (plus options) transport stack can then include mechanisms to decide > how to handle loss of options, just as TCP stacks do this today. > Applications do not need to be involved - perhaps other than to "enable" the > sender stack to do the correct thing. > > Gorry > > > > From nobody Tue Apr 18 10:07:09 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F0712706D for ; Tue, 18 Apr 2017 10:07:08 -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 tf4GTh-FoGAm for ; Tue, 18 Apr 2017 10:07:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 A5388128BB6 for ; Tue, 18 Apr 2017 10:07:06 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3IH65RA023251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 10:06:06 -0700 (PDT) To: Tom Herbert , "gorry@erg.abdn.ac.uk" References: <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> <58F5C07C.4000707@erg.abdn.ac.uk> Cc: tsvwg From: Joe Touch Message-ID: Date: Tue, 18 Apr 2017 10:06:05 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 17:07:08 -0000 Tom, On 4/18/2017 9:37 AM, Tom Herbert wrote: > ... > Gorry, > > UDP is a connectionless and unreliable protocol, so if the stack were > to on its own accord add an MSS to a packet how and no response was > seen how would it know the difference between a one way communication > and the packet was dropped because some intermediate device enforces > IP len == UDP len? IP len is the whole packet; UDP len is the length of the UDP segment, typically the IPlen - IPhdrsize. RFC768 permits UDP len to be smaller than IPlen - IPhdrsize, so the first point is that such an intermediate device isn't "enforcing" anything other than its own peculiar idea of what it expects, rather than what the protocol allows. It's no different than a device that drops TCP segments with unknown options - both are bugs. UDP has a large number of ways of silently failing, including this. Others include sending packets too large for the PMTU with DF=1 (or just using IPv6) or sending to the wrong port - where ICMPs might not be received in response. (note that there's no ICMP that justifies the intermediate device "enforcing" the length match either). Applications already account for this behavior by trying variations when communication fails - that includes resending, changing packet sizes, and (in this case) changing which options are used. > My concern with retrofitting UDP is that I don't think it can be done > so that all ambiguities are eliminated and hence it will never be > completely robust. I see that as a thread in your responses. The logical conclusion is that we all should use IPv4, TCP with no options, and UDP. Oh, and no new services - ever. Because *any* new capability, even within the bounds of existing extensions, can be deemed "incompletely robust" if you accept intermediate devices that block such valid services as legitimate. So if that's your conclusion, can we also conclude that you're also withdrawing your proposal in NVO3 for GUE and releasing port 6080? > For instance, in TCP any part of the TCP header > after the first twenty bytes must be TCP options-- there is no other > possible interpretation of these bits allowed by the protocol. But, > correct interpretation of UDP options in the surplus space is > inherently probabilistic. That's true for all new uses of any existing values - even GUE's use of port 6080 is inherently probabilistic because you don't know that someone isn't now squatting on that port for a different service (or won't in the future). > Even if we put in checksums and magic > numbers and get the probability of misinterpretation very low it will > not be zero. If some existing device happens to be adding random bits > beyond the UDP header (as the draft points out it was never a > requirement that lengths need to match) and this is subsequently > misinterpreted as UDP options causing insidious effects, even if this > happens just once, it is a problem with the protocol not the > implementation. There are no currently defined uses for that space, even though it is not prohibited. The issues you have here apply to any use of any undefined field, e.g., any reserved bits, new options, etc. There's always the risk of a squatter using the space other than as specified by a protocol. For that matter, you have exactly the same risk if a user decides to issue IP packets with protocol 17 and happens to not use the UDP format. Ultimately, protocols either follow specs or they do not. The UDP spec *allows* for use of this space *but does not define that use*. All current uses are identical to squatting, just like any other code space. Any new assignment or definition of that space runs the risk of running into squatters who use that value in other ways. > I think ambiguity is manageable if it is only the communicating hosts > that process the options and the use of options is expressly enabled > for both transmit and receive. That's already noted in the doc in Section 10. > If some intermediate device wereto > start parsing and possibly modifying options on its own accord this > would be exceedingly dangerous in my opinion. Such a problem would > potentially be a nightmare to debug in real networks since we don't > even have tools that can would analyze trailers. Fortunately, trailers > are unlikely to be considered by intermediate devices so this problem > is unlikely today. Nevertheless, I think the draft should say up from > that intermediate devices MUST NOT process, examine, or modify UDP > options. Everything you say about modifying UDP options is true for UDP headers, TCP headers, and TCP options too, but we already have devices that process, examine, and modify them. As long as we understand that these are headers for UDP - not for other protocols, e.g., IP - we know who should and should not be modifying them already and the associated risks. As to the issue of tools - we don't have tools to analyze port 6080 either. Again, your argument there would prevent any new feature from being deployed. > A related concern I have is around security and whether ambiguity can > be exploited. For instance, someone could easily forge a UDP fragment > using the UDP option. If a device supports UDP options they will > interpret this as fragment, if they don't they will see this as plain > UDP packet. This are very different interpretations of the same bits > however both devices could claim protocol conformance-- that's a > potential problem. This becomes a real problem if the ambiguity can be > somehow exploited to bypass security. UDP packets and TCP packets can already be forged. If that's your concern, you need to use true transport-layer or network layer security. And endpoints can claim conformance all they want; forged packets are already noncompliant. No protocol is robust to forged packets except those that support authentication or encryption. > The draft should probably include some more consideration for use with > NAT. For instance: > > "A host SHOULD indicate FRAG support by transmitting an unfragmented > datagram using the Fragmentation option" > > If the host lives behind a NAT this would effectively indicate support > for FRAG for all the hosts sitting behind the NAT. I doubt that's the > intent! FRAG should probably be based on UDP 4-tuple, but even packets > on that flow might not always be going to the same host (an IP anycast > destination for example). Section 10 already addresses this - the assumption is that discovery is done on a socketpair basis. I can mention socketpair as the assumed level of soft-state sharing earlier in that section if useful. > Also, the draft should mention multicast and whether or not UDP > options are allowed with that. Yes, that's a good point and I'll add that in the next rev. Joe From nobody Tue Apr 18 11:16:58 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E922A1292F4 for ; Tue, 18 Apr 2017 11:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leJsBScYDg9u for ; Tue, 18 Apr 2017 11:16:55 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 68989126E01 for ; Tue, 18 Apr 2017 11:16:55 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id g60so815014qtd.3 for ; Tue, 18 Apr 2017 11:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=grGYfphP6kb7Wj5CPRHsyS8Hg4SSNQCMI8+34fanYSQ=; b=NaXolWL66IkIpT33iRk32xuvmXLfU9wvYShUqBFEHtXEl9svh5DFB9eISdS2fYjeCi GvpBaMcwh+u4OnNEM+haOYmdoc4bbxKTYKs1iGIydgIUtD/uyI2lSlhF/LaEf7A/zAkX eyIlNJNVtP7P63iAqlpFuCXsMZTev/HuG8zWBR7KDwaBUnzbTtcShM8krb2uto4Bxqbo TW5OGB1ubKDceHYDQJdvguWQEJSOkoAFdABJZhYkJJCFWQemtKEp2xm9fqeRi6bl4Y1R n+xfAv6xbAWjE60DM6jJpK2RzG3XgpwXqfZ/iGKyuXoGTSkiHLZc+Zo4KL6Q+l+Cmiss REJg== 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=grGYfphP6kb7Wj5CPRHsyS8Hg4SSNQCMI8+34fanYSQ=; b=UArf4DM42L7AIjFkO0Fa8QFKNAIhzYOOuxeOt3MdVdvzyuY9vBo6lGDmPe+c8en5jq x0tiY6DfsVVMWgG8DihgH7JVl9J5O72T28No+HI/NDvT7WIIXtxIbwBmhnw3Vb1e3kBD pWsvtRRYDdeRbpHl45gQBAgNiOWPVhkyQktTi6Rz5k4rlLT7nuVJ60Bp9KFfFRHHIE8A 9b7b7kmTC3uhIU1zGLf5MgY4PX/CYPJkboBsnyTfrRKUu+QuqL3LUZbz/jFwnX5z+Dyb WXJciSuthU9VGHetM2odkJWZ5Y8kd+yP+qGGLdaIwXbcPQRRloUz/IxI9BzXb3SIYxC1 XeJQ== X-Gm-Message-State: AN3rC/4NYRghX8cUcQCLeqkWly+2QFb5pNitgiiIavQlRy9ukd43+bAL X5im7NTlbNpt40nZV/Q5YBN3OMLpiw== X-Received: by 10.200.45.122 with SMTP id o55mr15211677qta.203.1492539414537; Tue, 18 Apr 2017 11:16:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 18 Apr 2017 11:16:53 -0700 (PDT) In-Reply-To: References: <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> <58F5C07C.4000707@erg.abdn.ac.uk> From: Tom Herbert Date: Tue, 18 Apr 2017 11:16:53 -0700 Message-ID: To: Joe Touch Cc: "gorry@erg.abdn.ac.uk" , tsvwg Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:16:57 -0000 >> A related concern I have is around security and whether ambiguity can >> be exploited. For instance, someone could easily forge a UDP fragment >> using the UDP option. If a device supports UDP options they will >> interpret this as fragment, if they don't they will see this as plain >> UDP packet. This are very different interpretations of the same bits >> however both devices could claim protocol conformance-- that's a >> potential problem. This becomes a real problem if the ambiguity can be >> somehow exploited to bypass security. > UDP packets and TCP packets can already be forged. > > If that's your concern, you need to use true transport-layer or network > layer security. > 1) Yes, that is my concern. UDP is already dicey in terms of security, the risks introduced with these extensions needs to be thoroughly vetted before I'd ever deploy in my network 2) It can't be a requirement to turn up security everywhere just to use UDP options 3) My example is a contrived attack against the new protocol that might be deployed, the mitigations to defend such an attack should be part of the protocol not deferred to some other layer > And endpoints can claim conformance all they want; forged packets are > already noncompliant. No protocol is robust to forged packets except > those that support authentication or encryption. > That's misses the crux of my argument. In my example, an attacker forged a packet with can be "correctly" interpreted as either fragment or a non-fragment. Which interpretation depends on the node that processes it (sort of a Copenhagen Interpretation for network protocols I suppose :-) ). But a packet cannot simultaneously be a fragment and a not fragment, that is nonsensical (packets don't have duality in this instance). This must be considered an error condition. This ambiguity does not occur in IP or IPv6 and has been introduced by the protocol specification not incorrect implementation. It's unlikely in practice that this would cause problems, however, as I mentioned above, if this can be exploited as a security vulnerability that will be a concern of mine. I thought a one point there was the idea that the UDP checksum would be incorrect so that in the case I describe above a fragment would be dropped and not misinterpreted by a node that doesn't support fragments. Is there a reason that wouldn't work? Tom From nobody Tue Apr 18 11:36:59 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56D81293DA for ; Tue, 18 Apr 2017 11:36:57 -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 dAOZoraa0KhN for ; Tue, 18 Apr 2017 11:36:56 -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 C514312FC17 for ; Tue, 18 Apr 2017 11:36:56 -0700 (PDT) Received: from [128.9.184.37] ([128.9.184.37]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3IIaFBr005513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 11:36:15 -0700 (PDT) To: Tom Herbert References: <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> <58F5C07C.4000707@erg.abdn.ac.uk> Cc: "gorry@erg.abdn.ac.uk" , tsvwg From: Joe Touch Message-ID: Date: Tue, 18 Apr 2017 11:36:15 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3IIaFBr005513 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:36:58 -0000 On 4/18/2017 11:16 AM, Tom Herbert wrote: >> UDP packets and TCP packets can already be forged. >> >> If that's your concern, you need to use true transport-layer or network >> layer security. >> > 1) Yes, that is my concern. UDP is already dicey in terms of security, > the risks introduced with these extensions needs to be thoroughly > vetted before I'd ever deploy in my network Do you feel the same about new TCP options? > 2) It can't be a requirement to turn up security everywhere just to > use UDP options It isn't for new TCP options either, though. > 3) My example is a contrived attack against the new protocol that > might be deployed, the mitigations to defend such an attack should be > part of the protocol not deferred to some other layer The protocol extension already includes OCS and AE for that reason, though there's no way that UDP can protect the entire IP header too (that's what IPsec is designed for). > >> And endpoints can claim conformance all they want; forged packets are >> already noncompliant. No protocol is robust to forged packets except >> those that support authentication or encryption. >> > That's misses the crux of my argument. In my example, an attacker > forged a packet with can be "correctly" interpreted as either fragment > or a non-fragment. Which interpretation depends on the node that > processes it (sort of a Copenhagen Interpretation for network > protocols I suppose :-) ). But a packet cannot simultaneously be a > fragment and a not fragment, that is nonsensical (packets don't have > duality in this instance). This must be considered an error condition. The solution to your example would be for the protocol to allow only the hidden FRAG mechanism. Right now that's optional. However, note that forged packet can add a new extension that has two effects - one for upgraded endpoints, one for legacy - already. In TCP. The solution to *that* ambiguity is to confirm new options before using them and use them only when confirmed - as noted in Section 10. > This ambiguity does not occur in IP or IPv6 and has been introduced by > the protocol specification not incorrect implementation. It occurs the same way you could forge a new IP option that is accepted or ignored, depending on the endpoint support. > It's unlikely > in practice that this would cause problems, however, as I mentioned > above, if this can be exploited as a security vulnerability that will > be a concern of mine. > > I thought a one point there was the idea that the UDP checksum would > be incorrect so that in the case I describe above a fragment would be > dropped and not misinterpreted by a node that doesn't support > fragments. Is there a reason that wouldn't work? I'm not sure - again, I think your concerns about misinterpreting the data are addressed by allowing only FRAG as LITE. But I'm not sure I understand the example. Consider that if I can forge a FRAG, I can forge an entire UDP packet. I don't need anything new to have this vulnerability. Joe From nobody Tue Apr 18 12:33:32 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB5E129C31 for ; Tue, 18 Apr 2017 12:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoG5mD1_vwwN for ; Tue, 18 Apr 2017 12:33:28 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962331293D9 for ; Tue, 18 Apr 2017 12:33:28 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id g60so2638683qtd.3 for ; Tue, 18 Apr 2017 12:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8vrpnZcEaKP5IFyM1r01wmKUluGd7D1OxpCoMFr9+98=; b=u4+UefpDLs8pqjFxWWptTJ2aZ1RxR5NJz/B7IkJvYXTUnPPQAjWuM5PTlTPT0acGqm bVu473XBO5CFkIqFjujVqVdSt4F0Vtpy+UJH6VgCcM3j3IzZEF/1yAK7dWRSIrgQip+y /chGjBZcpr2bTlXiNRQa//5/U7tIUSlNT2Pgm25xkQn8UszX1rAfX20vtmgTXU4vRc7d U9+vLPRCoWw2FvVHfnKAkuJSEXw8SMWVe2wB8wWSXdK/k53EdfimvbfLtommRWAgdxTC 3VOY3JHW0rJr0/0PvhrRgscagfFRSiKYVIWxLra7i8mL3shh9n+9j66NDM6gBytjOYqC U0Ew== 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=8vrpnZcEaKP5IFyM1r01wmKUluGd7D1OxpCoMFr9+98=; b=EzqE9boW04fEHQvv8aZHXYtVJb6s0VD0y1eweuAfQgx9Y1Z5Y8HxvwIywj03mx7Z6V 0D2Fisa2ykWyOjT/EF3+/FvUZGT9v6/QqBt154R0EN1kiGOXyeJHsHccNfORAEcICQTH 3KS0MGUlnRSEboX7+RaYFrC2lm+bUV869Pp2hcmEqrN9InqU/OS5oiJvgCf2sIfhLyau lJVpjJ5xcKEzzcTZYXZ3xn3ajEKAPjGzHl4qPNGY1UBShJxDdgTgwqF7b5AxZwdjxPyN MFX3BGERE4sBW0NJlGWmX4qwGBNKepm0/o+rIyvvvPuJSCXYiic3Woau+QJyr8vwor1J n0ew== X-Gm-Message-State: AN3rC/5rS6sIUO77uKe1Vrz8JHWOTNMyjilm3NLztExcZyFToBqHy64G A14Dc4h5HUUyc7Ur4t+cN2htuC48iA== X-Received: by 10.200.34.144 with SMTP id f16mr16471537qta.186.1492544007680; Tue, 18 Apr 2017 12:33:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 18 Apr 2017 12:33:26 -0700 (PDT) In-Reply-To: References: <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> <58F5C07C.4000707@erg.abdn.ac.uk> From: Tom Herbert Date: Tue, 18 Apr 2017 12:33:26 -0700 Message-ID: To: Joe Touch Cc: "gorry@erg.abdn.ac.uk" , tsvwg Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 19:33:30 -0000 On Tue, Apr 18, 2017 at 11:36 AM, Joe Touch wrote: > > > On 4/18/2017 11:16 AM, Tom Herbert wrote: >>> UDP packets and TCP packets can already be forged. >>> >>> If that's your concern, you need to use true transport-layer or network >>> layer security. >>> >> 1) Yes, that is my concern. UDP is already dicey in terms of security, >> the risks introduced with these extensions needs to be thoroughly >> vetted before I'd ever deploy in my network > Do you feel the same about new TCP options? > >> 2) It can't be a requirement to turn up security everywhere just to >> use UDP options > It isn't for new TCP options either, though. > >> 3) My example is a contrived attack against the new protocol that >> might be deployed, the mitigations to defend such an attack should be >> part of the protocol not deferred to some other layer > The protocol extension already includes OCS and AE for that reason, > though there's no way that UDP can protect the entire IP header too > (that's what IPsec is designed for). > >> >>> And endpoints can claim conformance all they want; forged packets are >>> already noncompliant. No protocol is robust to forged packets except >>> those that support authentication or encryption. >>> >> That's misses the crux of my argument. In my example, an attacker >> forged a packet with can be "correctly" interpreted as either fragment >> or a non-fragment. Which interpretation depends on the node that >> processes it (sort of a Copenhagen Interpretation for network >> protocols I suppose :-) ). But a packet cannot simultaneously be a >> fragment and a not fragment, that is nonsensical (packets don't have >> duality in this instance). This must be considered an error condition. > The solution to your example would be for the protocol to allow only > the hidden FRAG mechanism. Right now that's optional. > > However, note that forged packet can add a new extension that has two > effects - one for upgraded endpoints, one for legacy - already. In TCP. > > The solution to *that* ambiguity is to confirm new options before using > them and use them only when confirmed - as noted in Section 10. > >> This ambiguity does not occur in IP or IPv6 and has been introduced by >> the protocol specification not incorrect implementation. > It occurs the same way you could forge a new IP option that is accepted > or ignored, depending on the endpoint support. > >> It's unlikely >> in practice that this would cause problems, however, as I mentioned >> above, if this can be exploited as a security vulnerability that will >> be a concern of mine. >> >> I thought a one point there was the idea that the UDP checksum would >> be incorrect so that in the case I describe above a fragment would be >> dropped and not misinterpreted by a node that doesn't support >> fragments. Is there a reason that wouldn't work? > > I'm not sure - again, I think your concerns about misinterpreting the > data are addressed by allowing only FRAG as LITE. > > But I'm not sure I understand the example. > My example is should be simple packet: IP|UDP|UDP_payload|FRAG_option I think if a legacy host receives this they accept it as a regular UDP packet, if a host with support received it they see a UDP fragment packet. (This is UDP, not UDP LITE) My suggestion to use UDP checksum in combination with length to eliminate this ambiguity: Sender host: - Length includes UDP options - UDP checksum covers everything up to IP length - Checksum over UDP options is nonzero (add an option if necessary to force this) - Protocol agnostics HW checksum offload should just work Receiver that support options: - Note IP length != UDP length so options may be present - Validate checksum that covers everything up to IP length (sum to zero with pseudo header included) - Check IP options sum to non-zero - Requirements for validating UDP checksum have been met, UDP options are valid and checksummed Receive that does not support options: - Since IP options part summed to non-zero, UDP checksum will be bad, packet is simply dropped - This is equivalent to packet dropped because options not supported Now our attacker can either forge fragment or forge a normal packet, but not both at the same time. UDP checksum will only be valid for one of two interpretations. In other words the combination of length and UDP checksum can be used to identify UDP options with high probability and disallows misinterpretation scenario above. This also will work with HW checksum offload and obviates the need to have separate checksum in the UDP options. Tom > Consider that if I can forge a FRAG, I can forge an entire UDP packet. I > don't need anything new to have this vulnerability. > > Joe > From nobody Tue Apr 18 13:01:23 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27261201F2 for ; Tue, 18 Apr 2017 13:01:22 -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, HTML_MESSAGE=0.001, 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 Yx00_YABXXAQ for ; Tue, 18 Apr 2017 13:01:21 -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 0CB6F129442 for ; Tue, 18 Apr 2017 13:01:19 -0700 (PDT) Received: from [128.9.184.37] ([128.9.184.37]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3IK0Q1B003901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Apr 2017 13:00:27 -0700 (PDT) To: Tom Herbert References: <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu> <58F48403.8080302@erg.abdn.ac.uk> <8b1829ba-4e8d-5ee1-e24c-f42962f47dde@isi.edu> <8378ae17-c023-25a2-76e7-07b858916849@isi.edu> <58F5C07C.4000707@erg.abdn.ac.uk> Cc: "gorry@erg.abdn.ac.uk" , tsvwg From: Joe Touch Message-ID: <9ac26200-fec0-25b0-164a-fc1271c26219@isi.edu> Date: Tue, 18 Apr 2017 13:00:26 -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: Content-Type: multipart/alternative; boundary="------------DE9805A03260DE38BE67A2AA" X-MailScanner-ID: v3IK0Q1B003901 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Regarding DTLS and UDP options X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:01:23 -0000 This is a multi-part message in MIME format. --------------DE9805A03260DE38BE67A2AA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Tom, On 4/18/2017 12:33 PM, Tom Herbert wrote: >> But I'm not sure I understand the example. >> > My example is should be simple packet: > > IP|UDP|UDP_payload|FRAG_option > > I think if a legacy host receives this they accept it as a regular UDP > packet, if a host with support received it they see a UDP fragment > packet. (This is UDP, not UDP LITE) We already discuss this as a bad idea until you confirm FRAG support with the other end of the socketpair. Another solution is to only use FRAG with LITE, but that adds overhead you might not need - which is why I think the protocol spec should say "SHOULD use FRAG with LITE" and "MAY use FRAG without LITE but only where confirmed". > My suggestion to use UDP checksum in combination with length to > eliminate this ambiguity: > > Sender host: > - Length includes UDP options I'm guessing you mean IP length (which would have to); UDP length cannot (we can't find the options and they'd be misinterpreted as user data by legacy hosts). > - UDP checksum covers everything up to IP length But that's not the current definition, which means you'll break any UDP checksum software/hardware (NATs, offload). > - Checksum over UDP options is nonzero (add an option if necessary to > force this) > - Protocol agnostics HW checksum offload should just work > Receiver that support options: > - Note IP length != UDP length so options may be present > - Validate checksum that covers everything up to IP length (sum to > zero with pseudo header included) > - Check IP options sum to non-zero > - Requirements for validating UDP checksum have been met, UDP options > are valid and checksummed > > Receive that does not support options: > - Since IP options part summed to non-zero, UDP checksum will be bad, > packet is simply dropped That means you'll be dropped by NATs too... which is something the current approach avoids. > - This is equivalent to packet dropped because options not supported > > Now our attacker can either forge fragment or forge a normal packet, > but not both at the same time. UDP checksum will only be valid for one > of two interpretations. Attackers can forge anything. Why would they bother with this sort of stuff? Why wouldn't they just forge real content that all endpoints would think is valid? > In other words the combination of length and UDP checksum can be used > to identify UDP options with high probability and disallows > misinterpretation scenario above. This also will work with HW checksum > offload and obviates the need to have separate checksum in the UDP > options. I'm still missing something here. A forger can forge anything it wants (again, presuming no UDP AE or IPsec). It can forge both a fragment and a normal packet and send them both in - thus interfering with either receiver variant. I don't see what's magic about a single packet that both endpoints interpret - but if that's the concern, the FRAG/LITE already avoids that and can be used. Joe --------------DE9805A03260DE38BE67A2AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Tom,


On 4/18/2017 12:33 PM, Tom Herbert wrote:
But I'm not sure I understand the example.


My example is should be simple packet:

IP|UDP|UDP_payload|FRAG_option

I think if a legacy host receives this they accept it as a regular UDP
packet, if a host with support received it they see a UDP fragment
packet. (This is UDP, not UDP LITE)
We already discuss this as a bad idea until you confirm FRAG support with the other end of the socketpair.

Another solution is to only use FRAG with LITE, but that adds overhead you might not need  - which is why I think the protocol spec should say "SHOULD use FRAG with LITE" and "MAY use FRAG without LITE but only where confirmed".

My suggestion to use UDP checksum in combination with length to
eliminate this ambiguity:

Sender host:
- Length includes UDP options
I'm guessing you mean IP length (which would have to); UDP length cannot (we can't find the options and they'd be misinterpreted as user data by legacy hosts).

- UDP checksum covers everything up to IP length
But that's not the current definition, which means you'll break any UDP checksum software/hardware (NATs, offload).
- Checksum over UDP options is nonzero (add an option if necessary to
force this)
- Protocol agnostics HW checksum offload should just work


Receiver that support options:
- Note IP length != UDP length so options may be present
- Validate checksum that covers everything up to IP length (sum to
zero with pseudo header included)
- Check IP options sum to non-zero
- Requirements for validating UDP checksum have been met, UDP options
are valid and checksummed

Receive that does not support options:
- Since IP options part summed to non-zero, UDP checksum will be bad,
packet is simply dropped
That means you'll be dropped by NATs too... which is something the current approach avoids.

- This is equivalent to packet dropped because options not supported

Now our attacker can either forge fragment or forge a normal packet,
but not both at the same time. UDP checksum will only be valid for one
of two interpretations.
Attackers can forge anything. Why would they bother with this sort of stuff? Why wouldn't they just forge real content that all endpoints would think is valid?

In other words the combination of length and UDP checksum can be used
to identify UDP options with high probability and disallows
misinterpretation scenario above. This also will work with HW checksum
offload and obviates the need to have separate checksum in the UDP
options.
I'm still missing something here.

A forger can forge anything it wants (again, presuming no UDP AE or IPsec). It can forge both a fragment and a normal packet and send them both in - thus interfering with either receiver variant. I don't see what's magic about a single packet that both endpoints interpret - but if that's the concern, the FRAG/LITE already avoids that and can be used.

Joe

    

  


--------------DE9805A03260DE38BE67A2AA--


From nobody Tue Apr 18 13:09:21 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A600F129405 for ; Tue, 18 Apr 2017 13:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 hMnLrxwIZ8J2 for ; Tue, 18 Apr 2017 13:09:17 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A3B127876 for ; Tue, 18 Apr 2017 13:09:16 -0700 (PDT)
Received: (qmail 6070 invoked from network); 18 Apr 2017 21:42:34 +0200
Received: from p5dec25a2.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.162) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated);  18 Apr 2017 21:42:33 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com>
Date: Tue, 18 Apr 2017 21:42:32 +0200
Cc: Bob Hinden , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net>
References:   <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com>  <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Apr 2017 20:09:20 -0000

Hi all,

sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN =
support, the reassembled packet should also do that correctly, no matter =
if the nodes support ECN or not. Handling these fields correctly with =
fragmentation does not mean that the nodes supports ECN. So this is not =
optional=E2=80=A6

Mirja


> Am 18.04.2017 um 02:38 schrieb Brian E Carpenter =
:
>=20
> wfm=20
> On 18/04/2017 09:08, Bob Hinden wrote:
>> Hi,
>>=20
>> After reading through the discussion, I think a new paragraph (after =
the text that says how to construct a reassembled packet) like the =
following would be appropriate.
>>=20
>>         Nodes that support Explicit Congestion Notification [RFC3168]
>>         should use information in the Traffic Class field from all
>>         fragment packets to reconstruct the Traffic Class field in =
the
>>         reassembled packet.  See Section 5.3 of RFC3168 for more
>>         information.
>>=20
>> I don=E2=80=99t think we need to quote what RFC3168 says, just point =
the the correct section.
>>=20
>> This also doesn=E2=80=99t effect nodes that don=E2=80=99t support =
ECN, so it shouldn't be making any new requirements.
>>=20
>> Comments?
>>=20
>> Bob
>>=20
>>> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter =
 wrote:
>>>=20
>>> In line...
>>>=20
>>> On 18/04/2017 05:44, Black, David wrote:
>>>> Extracting the key portions of text:
>>>>=20
>>>>>> That is inconsistent with the following guidance in RFC 3168 (see
>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3):
>>>>>>=20
>>>>>> 5.3.  Fragmentation
>>>>>>=20
>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set.
>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of
>>>>>> congestion.  In other words, if any fragment of an IP packet to =
be
>>>>>> reassembled has the CE codepoint set, then one of two actions =
MUST be
>>>>>> taken:
>>>>>>=20
>>>>>>    * Set the CE codepoint on the reassembled packet.  However, =
this
>>>>>>      MUST NOT occur if any of the other fragments contributing to
>>>>>>      this reassembly carries the Not-ECT codepoint.
>>>>>>=20
>>>>>>    * The packet is dropped, instead of being reassembled, for any
>>>>>>      other reason.
>>>>>>=20
>>>>>> If both actions are applicable, either MAY be chosen.  Reassembly =
of
>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all of =
the
>>>>>> fragments carry the same codepoint.
>>>>=20
>>>>> Regardless of the answer to that question, my position would be =
that since
>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the =
handling of
>>>>> the Traffic Class field, the following modification to 2460bis =
Section 4.5
>>>>> would be an appropriate way to deal with Mirja's comment:
>>>>>=20
>>>>> OLD:
>>>>>     The number and content of the headers preceding the Fragment
>>>>>     header of different fragments of the same original packet may
>>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>>     header in each fragment packet, are processed when the packets
>>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>>     those headers in the Offset zero fragment packet are retained =
in
>>>>>     the reassembled packet.
>>>>> NEW:
>>>>>     The number and content of the headers preceding the Fragment
>>>>>     header of different fragments of the same original packet may
>>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>>     header in each fragment packet, are processed when the packets
>>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>>     those headers in the Offset zero fragment packet are retained =
in
>>>>>     the reassembled packet; however, nodes that support Explicit
>>>>>     Congestion Notification [RFC3168] may use information in the
>>>>>     Traffic Class field from all fragment packets to reconstruct =
the
>>>>>     Traffic Class field in the reassembled packet.
>>>>>=20
>>>>> Note that this would not cause 2460bis itself to levy an =
additional
>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It =
would
>>>>> simply be making note of a requirement that is already levied by
>>>>> RFC 3168.
>>>>=20
>>>> In which case, the RFC 3168 requirement should be stated e.g.:
>>>>=20
>>>> OLD:
>>>>     The number and content of the headers preceding the Fragment
>>>>     header of different fragments of the same original packet may
>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>     header in each fragment packet, are processed when the packets
>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>     those headers in the Offset zero fragment packet are retained =
in
>>>>     the reassembled packet.
>>>> NEW:
>>>>     The number and content of the headers preceding the Fragment
>>>>     header of different fragments of the same original packet may
>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>     header in each fragment packet, are processed when the packets
>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>     those headers in the Offset zero fragment packet are retained =
in
>>>>     the reassembled packet; however, nodes that support Explicit
>>>>     Congestion Notification [RFC3168] may use information in the
>>>>     Traffic Class field from any or all fragment packets to =
reconstruct
>>>>     the Traffic Class field in the reassembled packet in order to =
meet
>>>>     RFC 3168's requirements, e.g., that reassembly not lose =
indications
>>>>     of congestion, see Section 5.3 of RFC 3168 for additional =
information.
>>>>=20
>>>> Pointing the implementer at Section 5.3 of RFC 3168 is better than
>>>> hoping she figures out on her own that she ought to take a look at =
it .
>>>=20
>>> Yes. This is correct.
>>>=20
>>>  Brian
>>>=20
>>>>=20
>>>> Thanks, --David
>>>>=20
>>>>> -----Original Message-----
>>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. =
Heard
>>>>> Sent: Monday, April 17, 2017 12:00 PM
>>>>> To: 6MAN <6man@ietf.org>; tsvwg 
>>>>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden
>>>>> ; Mirja Kuehlewind (IETF) =
;
>>>>> IESG ; 6man Chairs <6man-chairs@ietf.org>
>>>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on =
draft-ietf-6man-rfc2460bis-
>>>>> 09: (with DISCUSS and COMMENT)
>>>>>=20
>>>>> [ TSVWG added to solicit advice on implementation of RFC 3186 =
Section 5.3 ]
>>>>>=20
>>>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote:
>>>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard  wrote:
>>>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote:
>>>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote:
>>>>>>>> ...
>>>>>>>>>>>>> =
----------------------------------------------------------------------
>>>>>>>>>>>>> COMMENT:
>>>>>>>>>>>>> =
----------------------------------------------------------------------
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> One question because I'm not sure if I interpret this =
correct to
>>>>> make it
>>>>>>>>>>>>> part of my discuss:
>>>>>>>>>>>>> Section 4.5: "The number and content of the headers =
preceding
>>>>> the
>>>>>>>>>>>>> Fragment
>>>>>>>>>>>>> header of different fragments of the same original packet =
may
>>>>>>>>>>>>> differ.  Whatever headers are present, preceding the =
Fragment
>>>>>>>>>>>>> header in each fragment packet, are processed when the =
packets
>>>>>>>>>>>>> arrive, prior to queueing the fragments for reassembly.  =
Only
>>>>>>>>>>>>> those headers in the Offset zero fragment packet are =
retained in
>>>>>>>>>>>>> the reassembled packet."
>>>>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic =
Class field)
>>>>> is
>>>>>>>>>>>>> copied from the first fragment? This doesn't seem to be =
correct,
>>>>> however,
>>>>>>>>>>>>> also not sure what the correct answer is. I know this was =
not
>>>>> changed in
>>>>>>>>>>>>> this revision but maybe we can still get this right.
>>>>>>>>>>>>=20
>>>>>>>>>>>> When fragments are created most of the fields are copied =
from the
>>>>> IPv6
>>>>>>>>>>>> headers (e.g., Source Address, Destination address, flow =
label,
>>>>> traffic
>>>>>>>>>>>> class, hop limit).  Some like payload length, next header, =
and hop
>>>>> limi
>>>>>>>>>>>> t are modified.
>>>>>>>>>>>>=20
>>>>>>>>>>>> If I understand your question, the answer is yes, the ECN =
code
>>>>> point is
>>>>>>>>>>>> copied from the first fragment, but should be the same from =
all of
>>>>> the
>>>>>>>>>>>> fragments.
>>>>>>>=20
>>>>>>> That is inconsistent with the following guidance in RFC 3168 =
(see
>>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3):
>>>>>>>=20
>>>>>>> 5.3.  Fragmentation
>>>>>>>=20
>>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set.
>>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of
>>>>>>> congestion.  In other words, if any fragment of an IP packet to =
be
>>>>>>> reassembled has the CE codepoint set, then one of two actions =
MUST be
>>>>>>> taken:
>>>>>>>=20
>>>>>>>    * Set the CE codepoint on the reassembled packet.  However, =
this
>>>>>>>      MUST NOT occur if any of the other fragments contributing =
to
>>>>>>>      this reassembly carries the Not-ECT codepoint.
>>>>>>>=20
>>>>>>>    * The packet is dropped, instead of being reassembled, for =
any
>>>>>>>      other reason.
>>>>>>>=20
>>>>>>> If both actions are applicable, either MAY be chosen.  =
Reassembly of
>>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all =
of
>>>>> the
>>>>>>> fragments carry the same codepoint.
>>>>>>>=20
>>>>>>>>>>> My concern is that the ECN code point could be changed on =
one of
>>>>> the
>>>>>>>>>>> fragmented packets to signal congestion of a intermediate =
node and
>>>>>>>>>>> then when you reassemble this information gets lost. That =
seems
>>>>> wrong.
>>>>>>>>>>=20
>>>>>>>>>> That is an interesting idea, but I think out of scope for =
advancing this
>>>>>>>>>> document to Internet Standard.  Then there is the question of =
how to
>>>>>>>>>> encode n of m fragments experienced congestion.  Interesting =
future
>>>>> work.
>>>>>>>>>=20
>>>>>>>>> Yes there might be some more further work needed but that =
still
>>>>> makes the
>>>>>>>>> guidance in this text wrong. Maybe we can add some text that =
the
>>>>> Traffic
>>>>>>>>> Class may be handled differently because it could be changed =
on the
>>>>> path.
>>>>>>>>=20
>>>>>>>> Good point. It's not only ECN that can change; the DSCP can =
change too.
>>>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's =
logical
>>>>>>>> for 2460bis to note this issue.
>>>>>>>=20
>>>>>>> It seems that we (6man WG) missed this because RFC 3168 was not
>>>>> marked
>>>>>>> as updating RFC 2460. But in effect it did so for IPv6 =
implementations
>>>>>>> of ECN, even though it was not written in an IP version-agnostic =
manner.
>>>>>>>=20
>>>>>>> At the very least text should be added to the description of the
>>>>>>> reassembly process that points the reader to RFC 3168 or its
>>>>>>> successor document.
>>>>>>=20
>>>>>> Do we have any evidence that the guidance in RFC 3168 regarding
>>>>> reassembling
>>>>>> IPv6 fragments is implemented?  I don=E2=80=99t know, but think =
if it there is
>>>>>> evidence I agree some text should be added to rfc2460bis, if not, =
then
>>>>>> maybe not.
>>>>>=20
>>>>> Since I lack the expertise to answer that question, I'm hoping =
that someone
>>>>> in TSVWG will see this message and do so.
>>>>>=20
>>>>> Regardless of the answer to that question, my position would be =
that since
>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the =
handling of
>>>>> the Traffic Class field, the following modification to 2460bis =
Section 4.5
>>>>> would be an appropriate way to deal with Mirja's comment:
>>>>>=20
>>>>> OLD:
>>>>>     The number and content of the headers preceding the Fragment
>>>>>     header of different fragments of the same original packet may
>>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>>     header in each fragment packet, are processed when the packets
>>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>>     those headers in the Offset zero fragment packet are retained =
in
>>>>>     the reassembled packet.
>>>>> NEW:
>>>>>     The number and content of the headers preceding the Fragment
>>>>>     header of different fragments of the same original packet may
>>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>>     header in each fragment packet, are processed when the packets
>>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>>     those headers in the Offset zero fragment packet are retained =
in
>>>>>     the reassembled packet; however, nodes that support Explicit
>>>>>     Congestion Notification [RFC3168] may use information in the
>>>>>     Traffic Class field from all fragment packets to reconstruct =
the
>>>>>     Traffic Class field in the reassembled packet.
>>>>>=20
>>>>> Note that this would not cause 2460bis itself to levy an =
additional
>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It =
would
>>>>> simply be making note of a requirement that is already levied by
>>>>> RFC 3168.
>>>>>=20
>>>>> Thanks and regards,
>>>>>=20
>>>>> Mike Heard
>>>>=20
>>>> =
--------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> =
--------------------------------------------------------------------
>>>>=20
>>>=20
>>=20
>=20


From nobody Tue Apr 18 14:17:56 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B568512944A; Tue, 18 Apr 2017 14:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.501
X-Spam-Level: 
X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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=c+4lhMJb; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=RqsrY5yR
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 hyG-qi2Kq_AL; Tue, 18 Apr 2017 14:17:44 -0700 (PDT)
Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 7DCD912778E; Tue, 18 Apr 2017 14:17:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1492550264; x=1524086264; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y3r7d5cA7Id+Vwd9cNs6BkO9XPTPEUy1ZPL3olwu+ug=; b=c+4lhMJbknPapImMCfyGrDrwYr1rjpCcgomPfZy1XBGqGCKE1fKRdtP+ dquU+wkJW9GCReGa/zhNviPq7neqtPTdNGsKGA8lX9Ahv3b/wic47IF31 L9D+IvEk3jBvqU7UVWyoUP7Nk8ARA3XOK+iU7TgBfTHfaLA30Yf9OdlzU 0=;
Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 16:17:43 -0500
From: "Black, David" 
Cc: "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg , "draft-ietf-6man-rfc2460bis@ietf.org" , "Mirja Kuehlewind (IETF)" , IESG , 6man Chairs <6man-chairs@ietf.org>, "Black, David" 
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 03:11:40 +0600
Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3ILHdt1020212 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Apr 2017 17:17:40 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v3ILHdt1020212
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1492550262; bh=3VKTc2DkqmeWZ72fa4PnnZXxZRU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=RqsrY5yRMGYK7A4uS+Q8H95aMTBfLOYJiZEMmCqBE1oJPVFzUQWwAABfeO8zrwtxJ Ws/txxPWuPN1wlMVry9BMc2hBOSaE/eu7BB7o5r9N0qtnhsYyHpGLX58rIql3G8vHZ ZQ0wdcvzNf8jenBacYCmPMC1QEwpMY4lUQ4ev1LE=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v3ILHdt1020212
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd01.lss.emc.com (RSA Interceptor); Tue, 18 Apr 2017 17:16:51 -0400
Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3ILHGJH023943 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 18 Apr 2017 17:17:16 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Tue, 18 Apr 2017 17:17:16 -0400
To: Brian E Carpenter , Bob Hinden 
Thread-Topic: =?utf-8?B?W3RzdndnXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1p?= =?utf-8?B?ZXRmLTZtYW4tcmZjMjQ2MGJpcy0wOTogKHdpdGggRElTQ1VTUyBhbmQgQ09N?= =?utf-8?Q?MENT)?=
Thread-Index: AQHSt7T6ZLGWXOT01k+EpGAdOQo8CqHKUUAAgAA6rQCAARXb0A==
Date: Tue, 18 Apr 2017 21:17:16 +0000
Message-ID: 
References:   <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com>  <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com>
In-Reply-To: <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: public
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Apr 2017 21:17:48 -0000

VGhlIGxvd2VyIGNhc2UgInNob3VsZCIgaW4gdGhlIHByb3Bvc2VkIG5ldyBwYXJhZ3JhcGggY291
bGQgYmUgbWlzLXJlYWQgYXMgd2Vha2VuaW5nIFJGQyAzMTY4J3MgIk1VU1QgTk9UIGxvc2UgaW5k
aWNhdGlvbnMgb2YgY29uZ2VzdGlvbiIgcmVxdWlyZW1lbnQuDQoNCkkgd291bGQgcmVtb3ZlIHRo
YXQgb25lIHdvcmQgKCJzaG91bGQiKSBmcm9tIHRoZSBwcm9wb3NlZCBuZXcgcGFyYWdyYXBoIHRv
IGF2b2lkIHRoYXQgcG9zc2libGUgY29uZnVzaW9uLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0KPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFp
bHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAx
NywgMjAxNyA4OjM5IFBNDQo+IFRvOiBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWlsLmNvbT4N
Cj4gQ2M6IEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT47IEMuIE0uIEhlYXJkIDxo
ZWFyZEBwb2JveC5jb20+Ow0KPiA2TUFOIDw2bWFuQGlldGYub3JnPjsgdHN2d2cgPHRzdndnQGll
dGYub3JnPjsgZHJhZnQtaWV0Zi02bWFuLQ0KPiByZmMyNDYwYmlzQGlldGYub3JnOyBNaXJqYSBL
dWVobGV3aW5kIChJRVRGKSA8aWV0ZkBrdWVobGV3aW5kLm5ldD47IElFU0cNCj4gPGllc2dAaWV0
Zi5vcmc+OyA2bWFuIENoYWlycyA8Nm1hbi1jaGFpcnNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJl
OiBbdHN2d2ddIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtNm1hbi1y
ZmMyNDYwYmlzLQ0KPiAwOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IHdmbQ0K
PiBPbiAxOC8wNC8yMDE3IDA5OjA4LCBCb2IgSGluZGVuIHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+
ID4gQWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHRoZSBkaXNjdXNzaW9uLCBJIHRoaW5rIGEgbmV3IHBh
cmFncmFwaCAoYWZ0ZXIgdGhlDQo+IHRleHQgdGhhdCBzYXlzIGhvdyB0byBjb25zdHJ1Y3QgYSBy
ZWFzc2VtYmxlZCBwYWNrZXQpIGxpa2UgdGhlIGZvbGxvd2luZw0KPiB3b3VsZCBiZSBhcHByb3By
aWF0ZS4NCj4gPg0KPiA+ICAgICAgICAgIE5vZGVzIHRoYXQgc3VwcG9ydCBFeHBsaWNpdCBDb25n
ZXN0aW9uIE5vdGlmaWNhdGlvbiBbUkZDMzE2OF0NCj4gPiAgICAgICAgICBzaG91bGQgdXNlIGlu
Zm9ybWF0aW9uIGluIHRoZSBUcmFmZmljIENsYXNzIGZpZWxkIGZyb20gYWxsDQo+ID4gICAgICAg
ICAgZnJhZ21lbnQgcGFja2V0cyB0byByZWNvbnN0cnVjdCB0aGUgVHJhZmZpYyBDbGFzcyBmaWVs
ZCBpbiB0aGUNCj4gPiAgICAgICAgICByZWFzc2VtYmxlZCBwYWNrZXQuICBTZWUgU2VjdGlvbiA1
LjMgb2YgUkZDMzE2OCBmb3IgbW9yZQ0KPiA+ICAgICAgICAgIGluZm9ybWF0aW9uLg0KPiA+DQo+
ID4gSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgdG8gcXVvdGUgd2hhdCBSRkMzMTY4IHNheXMsIGp1
c3QgcG9pbnQgdGhlIHRoZQ0KPiBjb3JyZWN0IHNlY3Rpb24uDQo+ID4NCj4gPiBUaGlzIGFsc28g
ZG9lc27igJl0IGVmZmVjdCBub2RlcyB0aGF0IGRvbuKAmXQgc3VwcG9ydCBFQ04sIHNvIGl0IHNo
b3VsZG4ndCBiZQ0KPiBtYWtpbmcgYW55IG5ldyByZXF1aXJlbWVudHMuDQo+ID4NCj4gPiBDb21t
ZW50cz8NCj4gPg0KPiA+IEJvYg0KPiA+DQo+ID4+IE9uIEFwciAxNywgMjAxNywgYXQgMTI6NTgg
UE0sIEJyaWFuIEUgQ2FycGVudGVyDQo+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdy
b3RlOg0KPiA+Pg0KPiA+PiBJbiBsaW5lLi4uDQo+ID4+DQo+ID4+IE9uIDE4LzA0LzIwMTcgMDU6
NDQsIEJsYWNrLCBEYXZpZCB3cm90ZToNCj4gPj4+IEV4dHJhY3RpbmcgdGhlIGtleSBwb3J0aW9u
cyBvZiB0ZXh0Og0KPiA+Pj4NCj4gPj4+Pj4gVGhhdCBpcyBpbmNvbnNpc3RlbnQgd2l0aCB0aGUg
Zm9sbG93aW5nIGd1aWRhbmNlIGluIFJGQyAzMTY4IChzZWUNCj4gPj4+Pj4gaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL3JmYzMxNjgjc2VjdGlvbi01LjMpOg0KPiA+Pj4+Pg0KPiA+Pj4+PiA1
LjMuICBGcmFnbWVudGF0aW9uDQo+ID4+Pj4+DQo+ID4+Pj4+ICBFQ04tY2FwYWJsZSBwYWNrZXRz
IE1BWSBoYXZlIHRoZSBERiAoRG9uJ3QgRnJhZ21lbnQpIGJpdCBzZXQuDQo+ID4+Pj4+ICBSZWFz
c2VtYmx5IG9mIGEgZnJhZ21lbnRlZCBwYWNrZXQgTVVTVCBOT1QgbG9zZSBpbmRpY2F0aW9ucyBv
Zg0KPiA+Pj4+PiAgY29uZ2VzdGlvbi4gIEluIG90aGVyIHdvcmRzLCBpZiBhbnkgZnJhZ21lbnQg
b2YgYW4gSVAgcGFja2V0IHRvIGJlDQo+ID4+Pj4+ICByZWFzc2VtYmxlZCBoYXMgdGhlIENFIGNv
ZGVwb2ludCBzZXQsIHRoZW4gb25lIG9mIHR3byBhY3Rpb25zIE1VU1QNCj4gYmUNCj4gPj4+Pj4g
IHRha2VuOg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgKiBTZXQgdGhlIENFIGNvZGVwb2ludCBvbiB0
aGUgcmVhc3NlbWJsZWQgcGFja2V0LiAgSG93ZXZlciwgdGhpcw0KPiA+Pj4+PiAgICAgICBNVVNU
IE5PVCBvY2N1ciBpZiBhbnkgb2YgdGhlIG90aGVyIGZyYWdtZW50cyBjb250cmlidXRpbmcgdG8N
Cj4gPj4+Pj4gICAgICAgdGhpcyByZWFzc2VtYmx5IGNhcnJpZXMgdGhlIE5vdC1FQ1QgY29kZXBv
aW50Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgKiBUaGUgcGFja2V0IGlzIGRyb3BwZWQsIGluc3Rl
YWQgb2YgYmVpbmcgcmVhc3NlbWJsZWQsIGZvciBhbnkNCj4gPj4+Pj4gICAgICAgb3RoZXIgcmVh
c29uLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgSWYgYm90aCBhY3Rpb25zIGFyZSBhcHBsaWNhYmxlLCBl
aXRoZXIgTUFZIGJlIGNob3Nlbi4gIFJlYXNzZW1ibHkgb2YNCj4gPj4+Pj4gIGEgZnJhZ21lbnRl
ZCBwYWNrZXQgTVVTVCBOT1QgY2hhbmdlIHRoZSBFQ04gY29kZXBvaW50IHdoZW4gYWxsDQo+IG9m
IHRoZQ0KPiA+Pj4+PiAgZnJhZ21lbnRzIGNhcnJ5IHRoZSBzYW1lIGNvZGVwb2ludC4NCj4gPj4+
DQo+ID4+Pj4gUmVnYXJkbGVzcyBvZiB0aGUgYW5zd2VyIHRvIHRoYXQgcXVlc3Rpb24sIG15IHBv
c2l0aW9uIHdvdWxkIGJlIHRoYXQNCj4gc2luY2UNCj4gPj4+PiAyNDYwYmlzIGFscmVhZHkgZGVm
ZXJzIHRvIFJGQyAyNDc0IGFuZCBSRkMgMzE2OCByZWdhcmRpbmcgdGhlIGhhbmRsaW5nDQo+IG9m
DQo+ID4+Pj4gdGhlIFRyYWZmaWMgQ2xhc3MgZmllbGQsIHRoZSBmb2xsb3dpbmcgbW9kaWZpY2F0
aW9uIHRvIDI0NjBiaXMgU2VjdGlvbiA0LjUNCj4gPj4+PiB3b3VsZCBiZSBhbiBhcHByb3ByaWF0
ZSB3YXkgdG8gZGVhbCB3aXRoIE1pcmphJ3MgY29tbWVudDoNCj4gPj4+Pg0KPiA+Pj4+IE9MRDoN
Cj4gPj4+PiAgICAgIFRoZSBudW1iZXIgYW5kIGNvbnRlbnQgb2YgdGhlIGhlYWRlcnMgcHJlY2Vk
aW5nIHRoZSBGcmFnbWVudA0KPiA+Pj4+ICAgICAgaGVhZGVyIG9mIGRpZmZlcmVudCBmcmFnbWVu
dHMgb2YgdGhlIHNhbWUgb3JpZ2luYWwgcGFja2V0IG1heQ0KPiA+Pj4+ICAgICAgZGlmZmVyLiAg
V2hhdGV2ZXIgaGVhZGVycyBhcmUgcHJlc2VudCwgcHJlY2VkaW5nIHRoZSBGcmFnbWVudA0KPiA+
Pj4+ICAgICAgaGVhZGVyIGluIGVhY2ggZnJhZ21lbnQgcGFja2V0LCBhcmUgcHJvY2Vzc2VkIHdo
ZW4gdGhlIHBhY2tldHMNCj4gPj4+PiAgICAgIGFycml2ZSwgcHJpb3IgdG8gcXVldWVpbmcgdGhl
IGZyYWdtZW50cyBmb3IgcmVhc3NlbWJseS4gIE9ubHkNCj4gPj4+PiAgICAgIHRob3NlIGhlYWRl
cnMgaW4gdGhlIE9mZnNldCB6ZXJvIGZyYWdtZW50IHBhY2tldCBhcmUgcmV0YWluZWQgaW4NCj4g
Pj4+PiAgICAgIHRoZSByZWFzc2VtYmxlZCBwYWNrZXQuDQo+ID4+Pj4gTkVXOg0KPiA+Pj4+ICAg
ICAgVGhlIG51bWJlciBhbmQgY29udGVudCBvZiB0aGUgaGVhZGVycyBwcmVjZWRpbmcgdGhlIEZy
YWdtZW50DQo+ID4+Pj4gICAgICBoZWFkZXIgb2YgZGlmZmVyZW50IGZyYWdtZW50cyBvZiB0aGUg
c2FtZSBvcmlnaW5hbCBwYWNrZXQgbWF5DQo+ID4+Pj4gICAgICBkaWZmZXIuICBXaGF0ZXZlciBo
ZWFkZXJzIGFyZSBwcmVzZW50LCBwcmVjZWRpbmcgdGhlIEZyYWdtZW50DQo+ID4+Pj4gICAgICBo
ZWFkZXIgaW4gZWFjaCBmcmFnbWVudCBwYWNrZXQsIGFyZSBwcm9jZXNzZWQgd2hlbiB0aGUgcGFj
a2V0cw0KPiA+Pj4+ICAgICAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWluZyB0aGUgZnJhZ21lbnRz
IGZvciByZWFzc2VtYmx5LiAgT25seQ0KPiA+Pj4+ICAgICAgdGhvc2UgaGVhZGVycyBpbiB0aGUg
T2Zmc2V0IHplcm8gZnJhZ21lbnQgcGFja2V0IGFyZSByZXRhaW5lZCBpbg0KPiA+Pj4+ICAgICAg
dGhlIHJlYXNzZW1ibGVkIHBhY2tldDsgaG93ZXZlciwgbm9kZXMgdGhhdCBzdXBwb3J0IEV4cGxp
Y2l0DQo+ID4+Pj4gICAgICBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiBbUkZDMzE2OF0gbWF5IHVz
ZSBpbmZvcm1hdGlvbiBpbiB0aGUNCj4gPj4+PiAgICAgIFRyYWZmaWMgQ2xhc3MgZmllbGQgZnJv
bSBhbGwgZnJhZ21lbnQgcGFja2V0cyB0byByZWNvbnN0cnVjdCB0aGUNCj4gPj4+PiAgICAgIFRy
YWZmaWMgQ2xhc3MgZmllbGQgaW4gdGhlIHJlYXNzZW1ibGVkIHBhY2tldC4NCj4gPj4+Pg0KPiA+
Pj4+IE5vdGUgdGhhdCB0aGlzIHdvdWxkIG5vdCBjYXVzZSAyNDYwYmlzIGl0c2VsZiB0byBsZXZ5
IGFuIGFkZGl0aW9uYWwNCj4gPj4+PiByZXF1aXJlbWVudCBvbiBob3cgSVB2NiBub2RlcyByZWFz
c2VtYmxlIGZyYWdtZW50ZWQgcGFja2V0cy4gSXQNCj4gd291bGQNCj4gPj4+PiBzaW1wbHkgYmUg
bWFraW5nIG5vdGUgb2YgYSByZXF1aXJlbWVudCB0aGF0IGlzIGFscmVhZHkgbGV2aWVkIGJ5DQo+
ID4+Pj4gUkZDIDMxNjguDQo+ID4+Pg0KPiA+Pj4gSW4gd2hpY2ggY2FzZSwgdGhlIFJGQyAzMTY4
IHJlcXVpcmVtZW50IHNob3VsZCBiZSBzdGF0ZWQgZS5nLjoNCj4gPj4+DQo+ID4+PiBPTEQ6DQo+
ID4+PiAgICAgIFRoZSBudW1iZXIgYW5kIGNvbnRlbnQgb2YgdGhlIGhlYWRlcnMgcHJlY2VkaW5n
IHRoZSBGcmFnbWVudA0KPiA+Pj4gICAgICBoZWFkZXIgb2YgZGlmZmVyZW50IGZyYWdtZW50cyBv
ZiB0aGUgc2FtZSBvcmlnaW5hbCBwYWNrZXQgbWF5DQo+ID4+PiAgICAgIGRpZmZlci4gIFdoYXRl
dmVyIGhlYWRlcnMgYXJlIHByZXNlbnQsIHByZWNlZGluZyB0aGUgRnJhZ21lbnQNCj4gPj4+ICAg
ICAgaGVhZGVyIGluIGVhY2ggZnJhZ21lbnQgcGFja2V0LCBhcmUgcHJvY2Vzc2VkIHdoZW4gdGhl
IHBhY2tldHMNCj4gPj4+ICAgICAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWluZyB0aGUgZnJhZ21l
bnRzIGZvciByZWFzc2VtYmx5LiAgT25seQ0KPiA+Pj4gICAgICB0aG9zZSBoZWFkZXJzIGluIHRo
ZSBPZmZzZXQgemVybyBmcmFnbWVudCBwYWNrZXQgYXJlIHJldGFpbmVkIGluDQo+ID4+PiAgICAg
IHRoZSByZWFzc2VtYmxlZCBwYWNrZXQuDQo+ID4+PiBORVc6DQo+ID4+PiAgICAgIFRoZSBudW1i
ZXIgYW5kIGNvbnRlbnQgb2YgdGhlIGhlYWRlcnMgcHJlY2VkaW5nIHRoZSBGcmFnbWVudA0KPiA+
Pj4gICAgICBoZWFkZXIgb2YgZGlmZmVyZW50IGZyYWdtZW50cyBvZiB0aGUgc2FtZSBvcmlnaW5h
bCBwYWNrZXQgbWF5DQo+ID4+PiAgICAgIGRpZmZlci4gIFdoYXRldmVyIGhlYWRlcnMgYXJlIHBy
ZXNlbnQsIHByZWNlZGluZyB0aGUgRnJhZ21lbnQNCj4gPj4+ICAgICAgaGVhZGVyIGluIGVhY2gg
ZnJhZ21lbnQgcGFja2V0LCBhcmUgcHJvY2Vzc2VkIHdoZW4gdGhlIHBhY2tldHMNCj4gPj4+ICAg
ICAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWluZyB0aGUgZnJhZ21lbnRzIGZvciByZWFzc2VtYmx5
LiAgT25seQ0KPiA+Pj4gICAgICB0aG9zZSBoZWFkZXJzIGluIHRoZSBPZmZzZXQgemVybyBmcmFn
bWVudCBwYWNrZXQgYXJlIHJldGFpbmVkIGluDQo+ID4+PiAgICAgIHRoZSByZWFzc2VtYmxlZCBw
YWNrZXQ7IGhvd2V2ZXIsIG5vZGVzIHRoYXQgc3VwcG9ydCBFeHBsaWNpdA0KPiA+Pj4gICAgICBD
b25nZXN0aW9uIE5vdGlmaWNhdGlvbiBbUkZDMzE2OF0gbWF5IHVzZSBpbmZvcm1hdGlvbiBpbiB0
aGUNCj4gPj4+ICAgICAgVHJhZmZpYyBDbGFzcyBmaWVsZCBmcm9tIGFueSBvciBhbGwgZnJhZ21l
bnQgcGFja2V0cyB0byByZWNvbnN0cnVjdA0KPiA+Pj4gICAgICB0aGUgVHJhZmZpYyBDbGFzcyBm
aWVsZCBpbiB0aGUgcmVhc3NlbWJsZWQgcGFja2V0IGluIG9yZGVyIHRvIG1lZXQNCj4gPj4+ICAg
ICAgUkZDIDMxNjgncyByZXF1aXJlbWVudHMsIGUuZy4sIHRoYXQgcmVhc3NlbWJseSBub3QgbG9z
ZSBpbmRpY2F0aW9ucw0KPiA+Pj4gICAgICBvZiBjb25nZXN0aW9uLCBzZWUgU2VjdGlvbiA1LjMg
b2YgUkZDIDMxNjggZm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uDQo+ID4+Pg0KPiA+Pj4gUG9p
bnRpbmcgdGhlIGltcGxlbWVudGVyIGF0IFNlY3Rpb24gNS4zIG9mIFJGQyAzMTY4IGlzIGJldHRl
ciB0aGFuDQo+ID4+PiBob3Bpbmcgc2hlIGZpZ3VyZXMgb3V0IG9uIGhlciBvd24gdGhhdCBzaGUg
b3VnaHQgdG8gdGFrZSBhIGxvb2sgYXQgaXQgLg0KPiA+Pg0KPiA+PiBZZXMuIFRoaXMgaXMgY29y
cmVjdC4NCj4gPj4NCj4gPj4gICBCcmlhbg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFRoYW5rcywgLS1E
YXZpZA0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZy
b206IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEMu
IE0uDQo+IEhlYXJkDQo+ID4+Pj4gU2VudDogTW9uZGF5LCBBcHJpbCAxNywgMjAxNyAxMjowMCBQ
TQ0KPiA+Pj4+IFRvOiA2TUFOIDw2bWFuQGlldGYub3JnPjsgdHN2d2cgPHRzdndnQGlldGYub3Jn
Pg0KPiA+Pj4+IENjOiBkcmFmdC1pZXRmLTZtYW4tcmZjMjQ2MGJpc0BpZXRmLm9yZzsgQm9iIEhp
bmRlbg0KPiA+Pj4+IDxib2IuaGluZGVuQGdtYWlsLmNvbT47IE1pcmphIEt1ZWhsZXdpbmQgKElF
VEYpDQo+IDxpZXRmQGt1ZWhsZXdpbmQubmV0PjsNCj4gPj4+PiBJRVNHIDxpZXNnQGlldGYub3Jn
PjsgNm1hbiBDaGFpcnMgPDZtYW4tY2hhaXJzQGlldGYub3JnPg0KPiA+Pj4+IFN1YmplY3Q6IFJl
OiBbdHN2d2ddIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtNm1hbi0N
Cj4gcmZjMjQ2MGJpcy0NCj4gPj4+PiAwOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4g
Pj4+Pg0KPiA+Pj4+IFsgVFNWV0cgYWRkZWQgdG8gc29saWNpdCBhZHZpY2Ugb24gaW1wbGVtZW50
YXRpb24gb2YgUkZDIDMxODYgU2VjdGlvbg0KPiA1LjMgXQ0KPiA+Pj4+DQo+ID4+Pj4gT24gU2F0
LCBBcHIgMTUsIDIwMTcgYXQgMTE6NTAgQU0sIEJvYiBIaW5kZW4gd3JvdGU6DQo+ID4+Pj4+IE9u
IEFwciAxNSwgMjAxNywgYXQgNDo1MyBBTSwgQy4gTS4gSGVhcmQgPGhlYXJkQHBvYm94LmNvbT4g
d3JvdGU6DQo+ID4+Pj4+PiBPbiBGcmksIDE0IEFwciAyMDE3IDE0OjI4OjQ0ICsxMjAwIEJyaWFu
IEUgQ2FycGVudGVyIHdyb3RlOg0KPiA+Pj4+Pj4+IE9uIDEzLzA0LzIwMTcgMjM6MzYsIE1pcmph
IEt1ZWhsZXdpbmQgKElFVEYpIHdyb3RlOg0KPiA+Pj4+Pj4+IC4uLg0KPiA+Pj4+Pj4+Pj4+Pj4g
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KPiA+Pj4+Pj4+Pj4+Pj4gQ09NTUVOVDoNCj4gPj4+Pj4+Pj4+Pj4+IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBPbmUgcXVlc3Rpb24g
YmVjYXVzZSBJJ20gbm90IHN1cmUgaWYgSSBpbnRlcnByZXQgdGhpcyBjb3JyZWN0DQo+IHRvDQo+
ID4+Pj4gbWFrZSBpdA0KPiA+Pj4+Pj4+Pj4+Pj4gcGFydCBvZiBteSBkaXNjdXNzOg0KPiA+Pj4+
Pj4+Pj4+Pj4gU2VjdGlvbiA0LjU6ICJUaGUgbnVtYmVyIGFuZCBjb250ZW50IG9mIHRoZSBoZWFk
ZXJzDQo+IHByZWNlZGluZw0KPiA+Pj4+IHRoZQ0KPiA+Pj4+Pj4+Pj4+Pj4gRnJhZ21lbnQNCj4g
Pj4+Pj4+Pj4+Pj4+IGhlYWRlciBvZiBkaWZmZXJlbnQgZnJhZ21lbnRzIG9mIHRoZSBzYW1lIG9y
aWdpbmFsIHBhY2tldA0KPiBtYXkNCj4gPj4+Pj4+Pj4+Pj4+IGRpZmZlci4gIFdoYXRldmVyIGhl
YWRlcnMgYXJlIHByZXNlbnQsIHByZWNlZGluZyB0aGUNCj4gRnJhZ21lbnQNCj4gPj4+Pj4+Pj4+
Pj4+IGhlYWRlciBpbiBlYWNoIGZyYWdtZW50IHBhY2tldCwgYXJlIHByb2Nlc3NlZCB3aGVuIHRo
ZQ0KPiBwYWNrZXRzDQo+ID4+Pj4+Pj4+Pj4+PiBhcnJpdmUsIHByaW9yIHRvIHF1ZXVlaW5nIHRo
ZSBmcmFnbWVudHMgZm9yIHJlYXNzZW1ibHkuICBPbmx5DQo+ID4+Pj4+Pj4+Pj4+PiB0aG9zZSBo
ZWFkZXJzIGluIHRoZSBPZmZzZXQgemVybyBmcmFnbWVudCBwYWNrZXQgYXJlDQo+IHJldGFpbmVk
IGluDQo+ID4+Pj4+Pj4+Pj4+PiB0aGUgcmVhc3NlbWJsZWQgcGFja2V0LiINCj4gPj4+Pj4+Pj4+
Pj4+IERvZXMgdGhpcyBtZWFuIHRoZSBFQ04gY29kZXBvaW50IChwYXJ0IG9mIHRoZSBUcmFmZmlj
IENsYXNzDQo+IGZpZWxkKQ0KPiA+Pj4+IGlzDQo+ID4+Pj4+Pj4+Pj4+PiBjb3BpZWQgZnJvbSB0
aGUgZmlyc3QgZnJhZ21lbnQ/IFRoaXMgZG9lc24ndCBzZWVtIHRvIGJlDQo+IGNvcnJlY3QsDQo+
ID4+Pj4gaG93ZXZlciwNCj4gPj4+Pj4+Pj4+Pj4+IGFsc28gbm90IHN1cmUgd2hhdCB0aGUgY29y
cmVjdCBhbnN3ZXIgaXMuIEkga25vdyB0aGlzIHdhcyBub3QNCj4gPj4+PiBjaGFuZ2VkIGluDQo+
ID4+Pj4+Pj4+Pj4+PiB0aGlzIHJldmlzaW9uIGJ1dCBtYXliZSB3ZSBjYW4gc3RpbGwgZ2V0IHRo
aXMgcmlnaHQuDQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IFdoZW4gZnJhZ21lbnRzIGFy
ZSBjcmVhdGVkIG1vc3Qgb2YgdGhlIGZpZWxkcyBhcmUgY29waWVkDQo+IGZyb20gdGhlDQo+ID4+
Pj4gSVB2Ng0KPiA+Pj4+Pj4+Pj4+PiBoZWFkZXJzIChlLmcuLCBTb3VyY2UgQWRkcmVzcywgRGVz
dGluYXRpb24gYWRkcmVzcywgZmxvdw0KPiBsYWJlbCwNCj4gPj4+PiB0cmFmZmljDQo+ID4+Pj4+
Pj4+Pj4+IGNsYXNzLCBob3AgbGltaXQpLiAgU29tZSBsaWtlIHBheWxvYWQgbGVuZ3RoLCBuZXh0
IGhlYWRlciwgYW5kDQo+IGhvcA0KPiA+Pj4+IGxpbWkNCj4gPj4+Pj4+Pj4+Pj4gdCBhcmUgbW9k
aWZpZWQuDQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IElmIEkgdW5kZXJzdGFuZCB5b3Vy
IHF1ZXN0aW9uLCB0aGUgYW5zd2VyIGlzIHllcywgdGhlIEVDTiBjb2RlDQo+ID4+Pj4gcG9pbnQg
aXMNCj4gPj4+Pj4+Pj4+Pj4gY29waWVkIGZyb20gdGhlIGZpcnN0IGZyYWdtZW50LCBidXQgc2hv
dWxkIGJlIHRoZSBzYW1lIGZyb20NCj4gYWxsIG9mDQo+ID4+Pj4gdGhlDQo+ID4+Pj4+Pj4+Pj4+
IGZyYWdtZW50cy4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGF0IGlzIGluY29uc2lzdGVudCB3aXRo
IHRoZSBmb2xsb3dpbmcgZ3VpZGFuY2UgaW4gUkZDIDMxNjggKHNlZQ0KPiA+Pj4+Pj4gaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMxNjgjc2VjdGlvbi01LjMpOg0KPiA+Pj4+Pj4NCj4g
Pj4+Pj4+IDUuMy4gIEZyYWdtZW50YXRpb24NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgRUNOLWNhcGFi
bGUgcGFja2V0cyBNQVkgaGF2ZSB0aGUgREYgKERvbid0IEZyYWdtZW50KSBiaXQgc2V0Lg0KPiA+
Pj4+Pj4gIFJlYXNzZW1ibHkgb2YgYSBmcmFnbWVudGVkIHBhY2tldCBNVVNUIE5PVCBsb3NlIGlu
ZGljYXRpb25zIG9mDQo+ID4+Pj4+PiAgY29uZ2VzdGlvbi4gIEluIG90aGVyIHdvcmRzLCBpZiBh
bnkgZnJhZ21lbnQgb2YgYW4gSVAgcGFja2V0IHRvIGJlDQo+ID4+Pj4+PiAgcmVhc3NlbWJsZWQg
aGFzIHRoZSBDRSBjb2RlcG9pbnQgc2V0LCB0aGVuIG9uZSBvZiB0d28gYWN0aW9ucw0KPiBNVVNU
IGJlDQo+ID4+Pj4+PiAgdGFrZW46DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgICogU2V0IHRoZSBD
RSBjb2RlcG9pbnQgb24gdGhlIHJlYXNzZW1ibGVkIHBhY2tldC4gIEhvd2V2ZXIsIHRoaXMNCj4g
Pj4+Pj4+ICAgICAgIE1VU1QgTk9UIG9jY3VyIGlmIGFueSBvZiB0aGUgb3RoZXIgZnJhZ21lbnRz
IGNvbnRyaWJ1dGluZyB0bw0KPiA+Pj4+Pj4gICAgICAgdGhpcyByZWFzc2VtYmx5IGNhcnJpZXMg
dGhlIE5vdC1FQ1QgY29kZXBvaW50Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgICAqIFRoZSBwYWNr
ZXQgaXMgZHJvcHBlZCwgaW5zdGVhZCBvZiBiZWluZyByZWFzc2VtYmxlZCwgZm9yIGFueQ0KPiA+
Pj4+Pj4gICAgICAgb3RoZXIgcmVhc29uLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICBJZiBib3RoIGFj
dGlvbnMgYXJlIGFwcGxpY2FibGUsIGVpdGhlciBNQVkgYmUgY2hvc2VuLiAgUmVhc3NlbWJseSBv
Zg0KPiA+Pj4+Pj4gIGEgZnJhZ21lbnRlZCBwYWNrZXQgTVVTVCBOT1QgY2hhbmdlIHRoZSBFQ04g
Y29kZXBvaW50IHdoZW4gYWxsDQo+IG9mDQo+ID4+Pj4gdGhlDQo+ID4+Pj4+PiAgZnJhZ21lbnRz
IGNhcnJ5IHRoZSBzYW1lIGNvZGVwb2ludC4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gTXkgY29u
Y2VybiBpcyB0aGF0IHRoZSBFQ04gY29kZSBwb2ludCBjb3VsZCBiZSBjaGFuZ2VkIG9uDQo+IG9u
ZSBvZg0KPiA+Pj4+IHRoZQ0KPiA+Pj4+Pj4+Pj4+IGZyYWdtZW50ZWQgcGFja2V0cyB0byBzaWdu
YWwgY29uZ2VzdGlvbiBvZiBhIGludGVybWVkaWF0ZQ0KPiBub2RlIGFuZA0KPiA+Pj4+Pj4+Pj4+
IHRoZW4gd2hlbiB5b3UgcmVhc3NlbWJsZSB0aGlzIGluZm9ybWF0aW9uIGdldHMgbG9zdC4gVGhh
dA0KPiBzZWVtcw0KPiA+Pj4+IHdyb25nLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFRoYXQg
aXMgYW4gaW50ZXJlc3RpbmcgaWRlYSwgYnV0IEkgdGhpbmsgb3V0IG9mIHNjb3BlIGZvciBhZHZh
bmNpbmcNCj4gdGhpcw0KPiA+Pj4+Pj4+Pj4gZG9jdW1lbnQgdG8gSW50ZXJuZXQgU3RhbmRhcmQu
ICBUaGVuIHRoZXJlIGlzIHRoZSBxdWVzdGlvbiBvZg0KPiBob3cgdG8NCj4gPj4+Pj4+Pj4+IGVu
Y29kZSBuIG9mIG0gZnJhZ21lbnRzIGV4cGVyaWVuY2VkIGNvbmdlc3Rpb24uICBJbnRlcmVzdGlu
Zw0KPiBmdXR1cmUNCj4gPj4+PiB3b3JrLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBZZXMgdGhl
cmUgbWlnaHQgYmUgc29tZSBtb3JlIGZ1cnRoZXIgd29yayBuZWVkZWQgYnV0IHRoYXQgc3RpbGwN
Cj4gPj4+PiBtYWtlcyB0aGUNCj4gPj4+Pj4+Pj4gZ3VpZGFuY2UgaW4gdGhpcyB0ZXh0IHdyb25n
LiBNYXliZSB3ZSBjYW4gYWRkIHNvbWUgdGV4dCB0aGF0IHRoZQ0KPiA+Pj4+IFRyYWZmaWMNCj4g
Pj4+Pj4+Pj4gQ2xhc3MgbWF5IGJlIGhhbmRsZWQgZGlmZmVyZW50bHkgYmVjYXVzZSBpdCBjb3Vs
ZCBiZSBjaGFuZ2VkIG9uDQo+IHRoZQ0KPiA+Pj4+IHBhdGguDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+
PiBHb29kIHBvaW50LiBJdCdzIG5vdCBvbmx5IEVDTiB0aGF0IGNhbiBjaGFuZ2U7IHRoZSBEU0NQ
IGNhbiBjaGFuZ2UNCj4gdG9vLg0KPiA+Pj4+Pj4+IEJvdGggUkZDMjQ3NCAoZGlmZnNlcnYpIGFu
ZCBFQ04gY2FtZSBhZnRlciBSRkMyNDYwLCBzbyBpdCdzIGxvZ2ljYWwNCj4gPj4+Pj4+PiBmb3Ig
MjQ2MGJpcyB0byBub3RlIHRoaXMgaXNzdWUuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSXQgc2VlbXMg
dGhhdCB3ZSAoNm1hbiBXRykgbWlzc2VkIHRoaXMgYmVjYXVzZSBSRkMgMzE2OCB3YXMgbm90DQo+
ID4+Pj4gbWFya2VkDQo+ID4+Pj4+PiBhcyB1cGRhdGluZyBSRkMgMjQ2MC4gQnV0IGluIGVmZmVj
dCBpdCBkaWQgc28gZm9yIElQdjYgaW1wbGVtZW50YXRpb25zDQo+ID4+Pj4+PiBvZiBFQ04sIGV2
ZW4gdGhvdWdoIGl0IHdhcyBub3Qgd3JpdHRlbiBpbiBhbiBJUCB2ZXJzaW9uLWFnbm9zdGljDQo+
IG1hbm5lci4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBBdCB0aGUgdmVyeSBsZWFzdCB0ZXh0IHNob3Vs
ZCBiZSBhZGRlZCB0byB0aGUgZGVzY3JpcHRpb24gb2YgdGhlDQo+ID4+Pj4+PiByZWFzc2VtYmx5
IHByb2Nlc3MgdGhhdCBwb2ludHMgdGhlIHJlYWRlciB0byBSRkMgMzE2OCBvciBpdHMNCj4gPj4+
Pj4+IHN1Y2Nlc3NvciBkb2N1bWVudC4NCj4gPj4+Pj4NCj4gPj4+Pj4gRG8gd2UgaGF2ZSBhbnkg
ZXZpZGVuY2UgdGhhdCB0aGUgZ3VpZGFuY2UgaW4gUkZDIDMxNjggcmVnYXJkaW5nDQo+ID4+Pj4g
cmVhc3NlbWJsaW5nDQo+ID4+Pj4+IElQdjYgZnJhZ21lbnRzIGlzIGltcGxlbWVudGVkPyAgSSBk
b27igJl0IGtub3csIGJ1dCB0aGluayBpZiBpdCB0aGVyZSBpcw0KPiA+Pj4+PiBldmlkZW5jZSBJ
IGFncmVlIHNvbWUgdGV4dCBzaG91bGQgYmUgYWRkZWQgdG8gcmZjMjQ2MGJpcywgaWYgbm90LCB0
aGVuDQo+ID4+Pj4+IG1heWJlIG5vdC4NCj4gPj4+Pg0KPiA+Pj4+IFNpbmNlIEkgbGFjayB0aGUg
ZXhwZXJ0aXNlIHRvIGFuc3dlciB0aGF0IHF1ZXN0aW9uLCBJJ20gaG9waW5nIHRoYXQNCj4gc29t
ZW9uZQ0KPiA+Pj4+IGluIFRTVldHIHdpbGwgc2VlIHRoaXMgbWVzc2FnZSBhbmQgZG8gc28uDQo+
ID4+Pj4NCj4gPj4+PiBSZWdhcmRsZXNzIG9mIHRoZSBhbnN3ZXIgdG8gdGhhdCBxdWVzdGlvbiwg
bXkgcG9zaXRpb24gd291bGQgYmUgdGhhdA0KPiBzaW5jZQ0KPiA+Pj4+IDI0NjBiaXMgYWxyZWFk
eSBkZWZlcnMgdG8gUkZDIDI0NzQgYW5kIFJGQyAzMTY4IHJlZ2FyZGluZyB0aGUgaGFuZGxpbmcN
Cj4gb2YNCj4gPj4+PiB0aGUgVHJhZmZpYyBDbGFzcyBmaWVsZCwgdGhlIGZvbGxvd2luZyBtb2Rp
ZmljYXRpb24gdG8gMjQ2MGJpcyBTZWN0aW9uIDQuNQ0KPiA+Pj4+IHdvdWxkIGJlIGFuIGFwcHJv
cHJpYXRlIHdheSB0byBkZWFsIHdpdGggTWlyamEncyBjb21tZW50Og0KPiA+Pj4+DQo+ID4+Pj4g
T0xEOg0KPiA+Pj4+ICAgICAgVGhlIG51bWJlciBhbmQgY29udGVudCBvZiB0aGUgaGVhZGVycyBw
cmVjZWRpbmcgdGhlIEZyYWdtZW50DQo+ID4+Pj4gICAgICBoZWFkZXIgb2YgZGlmZmVyZW50IGZy
YWdtZW50cyBvZiB0aGUgc2FtZSBvcmlnaW5hbCBwYWNrZXQgbWF5DQo+ID4+Pj4gICAgICBkaWZm
ZXIuICBXaGF0ZXZlciBoZWFkZXJzIGFyZSBwcmVzZW50LCBwcmVjZWRpbmcgdGhlIEZyYWdtZW50
DQo+ID4+Pj4gICAgICBoZWFkZXIgaW4gZWFjaCBmcmFnbWVudCBwYWNrZXQsIGFyZSBwcm9jZXNz
ZWQgd2hlbiB0aGUgcGFja2V0cw0KPiA+Pj4+ICAgICAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWlu
ZyB0aGUgZnJhZ21lbnRzIGZvciByZWFzc2VtYmx5LiAgT25seQ0KPiA+Pj4+ICAgICAgdGhvc2Ug
aGVhZGVycyBpbiB0aGUgT2Zmc2V0IHplcm8gZnJhZ21lbnQgcGFja2V0IGFyZSByZXRhaW5lZCBp
bg0KPiA+Pj4+ICAgICAgdGhlIHJlYXNzZW1ibGVkIHBhY2tldC4NCj4gPj4+PiBORVc6DQo+ID4+
Pj4gICAgICBUaGUgbnVtYmVyIGFuZCBjb250ZW50IG9mIHRoZSBoZWFkZXJzIHByZWNlZGluZyB0
aGUgRnJhZ21lbnQNCj4gPj4+PiAgICAgIGhlYWRlciBvZiBkaWZmZXJlbnQgZnJhZ21lbnRzIG9m
IHRoZSBzYW1lIG9yaWdpbmFsIHBhY2tldCBtYXkNCj4gPj4+PiAgICAgIGRpZmZlci4gIFdoYXRl
dmVyIGhlYWRlcnMgYXJlIHByZXNlbnQsIHByZWNlZGluZyB0aGUgRnJhZ21lbnQNCj4gPj4+PiAg
ICAgIGhlYWRlciBpbiBlYWNoIGZyYWdtZW50IHBhY2tldCwgYXJlIHByb2Nlc3NlZCB3aGVuIHRo
ZSBwYWNrZXRzDQo+ID4+Pj4gICAgICBhcnJpdmUsIHByaW9yIHRvIHF1ZXVlaW5nIHRoZSBmcmFn
bWVudHMgZm9yIHJlYXNzZW1ibHkuICBPbmx5DQo+ID4+Pj4gICAgICB0aG9zZSBoZWFkZXJzIGlu
IHRoZSBPZmZzZXQgemVybyBmcmFnbWVudCBwYWNrZXQgYXJlIHJldGFpbmVkIGluDQo+ID4+Pj4g
ICAgICB0aGUgcmVhc3NlbWJsZWQgcGFja2V0OyBob3dldmVyLCBub2RlcyB0aGF0IHN1cHBvcnQg
RXhwbGljaXQNCj4gPj4+PiAgICAgIENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFtSRkMzMTY4XSBt
YXkgdXNlIGluZm9ybWF0aW9uIGluIHRoZQ0KPiA+Pj4+ICAgICAgVHJhZmZpYyBDbGFzcyBmaWVs
ZCBmcm9tIGFsbCBmcmFnbWVudCBwYWNrZXRzIHRvIHJlY29uc3RydWN0IHRoZQ0KPiA+Pj4+ICAg
ICAgVHJhZmZpYyBDbGFzcyBmaWVsZCBpbiB0aGUgcmVhc3NlbWJsZWQgcGFja2V0Lg0KPiA+Pj4+
DQo+ID4+Pj4gTm90ZSB0aGF0IHRoaXMgd291bGQgbm90IGNhdXNlIDI0NjBiaXMgaXRzZWxmIHRv
IGxldnkgYW4gYWRkaXRpb25hbA0KPiA+Pj4+IHJlcXVpcmVtZW50IG9uIGhvdyBJUHY2IG5vZGVz
IHJlYXNzZW1ibGUgZnJhZ21lbnRlZCBwYWNrZXRzLiBJdA0KPiB3b3VsZA0KPiA+Pj4+IHNpbXBs
eSBiZSBtYWtpbmcgbm90ZSBvZiBhIHJlcXVpcmVtZW50IHRoYXQgaXMgYWxyZWFkeSBsZXZpZWQg
YnkNCj4gPj4+PiBSRkMgMzE2OC4NCj4gPj4+Pg0KPiA+Pj4+IFRoYW5rcyBhbmQgcmVnYXJkcywN
Cj4gPj4+Pg0KPiA+Pj4+IE1pa2UgSGVhcmQNCj4gPj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+
Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ID4+PiBpcHY2QGlldGYu
b3JnDQo+ID4+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4NCj4gPj4NCj4g
Pg0KDQo=


From nobody Tue Apr 18 17:51:45 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784EC12945B for ; Tue, 18 Apr 2017 17:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UIQIceHTNvU for ; Tue, 18 Apr 2017 17:51:41 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2E7126D74 for ; Tue, 18 Apr 2017 17:51:40 -0700 (PDT)
Received: (qmail 13716 invoked from network); 19 Apr 2017 02:51:38 +0200
Received: from p5dec224d.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.77) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated);  19 Apr 2017 02:51:38 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net>
Date: Wed, 19 Apr 2017 02:51:36 +0200
Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , Bob Hinden , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com>  <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 00:51:43 -0000

Hi again,

I should probably have been more constructive here. I=E2=80=99d like to =
propose the following text:

The number and content of the headers preceding the Fragment
header of different fragments of the same original packet may
differ.  Whatever headers are present, preceding the Fragment
header in each fragment packet, are processed when the packets
arrive, prior to queueing the fragments for reassembly.  Only
those headers in the Offset zero fragment packet are retained in
the reassembled packet; however, the Traffic Class field from=20
any or all fragments may differ. Handling of Explicit
Congestion Notification [RFC3168] is described in Section 5.3 of=20
RFC 3168, ensuring that reassembly does not lose indications
of congestion.

Do we also need to say something about DiffServ?

Mirja




> Am 18.04.2017 um 21:42 schrieb Mirja Kuehlewind (IETF) =
:
>=20
> Hi all,
>=20
> sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN =
support, the reassembled packet should also do that correctly, no matter =
if the nodes support ECN or not. Handling these fields correctly with =
fragmentation does not mean that the nodes supports ECN. So this is not =
optional=E2=80=A6
>=20
> Mirja
>=20
>=20
>> Am 18.04.2017 um 02:38 schrieb Brian E Carpenter =
:
>>=20
>> wfm=20
>> On 18/04/2017 09:08, Bob Hinden wrote:
>>> Hi,
>>>=20
>>> After reading through the discussion, I think a new paragraph (after =
the text that says how to construct a reassembled packet) like the =
following would be appropriate.
>>>=20
>>>        Nodes that support Explicit Congestion Notification [RFC3168]
>>>        should use information in the Traffic Class field from all
>>>        fragment packets to reconstruct the Traffic Class field in =
the
>>>        reassembled packet.  See Section 5.3 of RFC3168 for more
>>>        information.
>>>=20
>>> I don=E2=80=99t think we need to quote what RFC3168 says, just point =
the the correct section.
>>>=20
>>> This also doesn=E2=80=99t effect nodes that don=E2=80=99t support =
ECN, so it shouldn't be making any new requirements.
>>>=20
>>> Comments?
>>>=20
>>> Bob
>>>=20
>>>> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter =
 wrote:
>>>>=20
>>>> In line...
>>>>=20
>>>> On 18/04/2017 05:44, Black, David wrote:
>>>>> Extracting the key portions of text:
>>>>>=20
>>>>>>> That is inconsistent with the following guidance in RFC 3168 =
(see
>>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3):
>>>>>>>=20
>>>>>>> 5.3.  Fragmentation
>>>>>>>=20
>>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set.
>>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of
>>>>>>> congestion.  In other words, if any fragment of an IP packet to =
be
>>>>>>> reassembled has the CE codepoint set, then one of two actions =
MUST be
>>>>>>> taken:
>>>>>>>=20
>>>>>>>   * Set the CE codepoint on the reassembled packet.  However, =
this
>>>>>>>     MUST NOT occur if any of the other fragments contributing to
>>>>>>>     this reassembly carries the Not-ECT codepoint.
>>>>>>>=20
>>>>>>>   * The packet is dropped, instead of being reassembled, for any
>>>>>>>     other reason.
>>>>>>>=20
>>>>>>> If both actions are applicable, either MAY be chosen.  =
Reassembly of
>>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all =
of the
>>>>>>> fragments carry the same codepoint.
>>>>>=20
>>>>>> Regardless of the answer to that question, my position would be =
that since
>>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the =
handling of
>>>>>> the Traffic Class field, the following modification to 2460bis =
Section 4.5
>>>>>> would be an appropriate way to deal with Mirja's comment:
>>>>>>=20
>>>>>> OLD:
>>>>>>    The number and content of the headers preceding the Fragment
>>>>>>    header of different fragments of the same original packet may
>>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>>    header in each fragment packet, are processed when the packets
>>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>    those headers in the Offset zero fragment packet are retained =
in
>>>>>>    the reassembled packet.
>>>>>> NEW:
>>>>>>    The number and content of the headers preceding the Fragment
>>>>>>    header of different fragments of the same original packet may
>>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>>    header in each fragment packet, are processed when the packets
>>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>    those headers in the Offset zero fragment packet are retained =
in
>>>>>>    the reassembled packet; however, nodes that support Explicit
>>>>>>    Congestion Notification [RFC3168] may use information in the
>>>>>>    Traffic Class field from all fragment packets to reconstruct =
the
>>>>>>    Traffic Class field in the reassembled packet.
>>>>>>=20
>>>>>> Note that this would not cause 2460bis itself to levy an =
additional
>>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It =
would
>>>>>> simply be making note of a requirement that is already levied by
>>>>>> RFC 3168.
>>>>>=20
>>>>> In which case, the RFC 3168 requirement should be stated e.g.:
>>>>>=20
>>>>> OLD:
>>>>>    The number and content of the headers preceding the Fragment
>>>>>    header of different fragments of the same original packet may
>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>    header in each fragment packet, are processed when the packets
>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>    those headers in the Offset zero fragment packet are retained =
in
>>>>>    the reassembled packet.
>>>>> NEW:
>>>>>    The number and content of the headers preceding the Fragment
>>>>>    header of different fragments of the same original packet may
>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>    header in each fragment packet, are processed when the packets
>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>    those headers in the Offset zero fragment packet are retained =
in
>>>>>    the reassembled packet; however, nodes that support Explicit
>>>>>    Congestion Notification [RFC3168] may use information in the
>>>>>    Traffic Class field from any or all fragment packets to =
reconstruct
>>>>>    the Traffic Class field in the reassembled packet in order to =
meet
>>>>>    RFC 3168's requirements, e.g., that reassembly not lose =
indications
>>>>>    of congestion, see Section 5.3 of RFC 3168 for additional =
information.
>>>>>=20
>>>>> Pointing the implementer at Section 5.3 of RFC 3168 is better than
>>>>> hoping she figures out on her own that she ought to take a look at =
it .
>>>>=20
>>>> Yes. This is correct.
>>>>=20
>>>> Brian
>>>>=20
>>>>>=20
>>>>> Thanks, --David
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. =
Heard
>>>>>> Sent: Monday, April 17, 2017 12:00 PM
>>>>>> To: 6MAN <6man@ietf.org>; tsvwg 
>>>>>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden
>>>>>> ; Mirja Kuehlewind (IETF) =
;
>>>>>> IESG ; 6man Chairs <6man-chairs@ietf.org>
>>>>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on =
draft-ietf-6man-rfc2460bis-
>>>>>> 09: (with DISCUSS and COMMENT)
>>>>>>=20
>>>>>> [ TSVWG added to solicit advice on implementation of RFC 3186 =
Section 5.3 ]
>>>>>>=20
>>>>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote:
>>>>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard  =
wrote:
>>>>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote:
>>>>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote:
>>>>>>>>> ...
>>>>>>>>>>>>>> =
----------------------------------------------------------------------
>>>>>>>>>>>>>> COMMENT:
>>>>>>>>>>>>>> =
----------------------------------------------------------------------
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> One question because I'm not sure if I interpret this =
correct to
>>>>>> make it
>>>>>>>>>>>>>> part of my discuss:
>>>>>>>>>>>>>> Section 4.5: "The number and content of the headers =
preceding
>>>>>> the
>>>>>>>>>>>>>> Fragment
>>>>>>>>>>>>>> header of different fragments of the same original packet =
may
>>>>>>>>>>>>>> differ.  Whatever headers are present, preceding the =
Fragment
>>>>>>>>>>>>>> header in each fragment packet, are processed when the =
packets
>>>>>>>>>>>>>> arrive, prior to queueing the fragments for reassembly.  =
Only
>>>>>>>>>>>>>> those headers in the Offset zero fragment packet are =
retained in
>>>>>>>>>>>>>> the reassembled packet."
>>>>>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic =
Class field)
>>>>>> is
>>>>>>>>>>>>>> copied from the first fragment? This doesn't seem to be =
correct,
>>>>>> however,
>>>>>>>>>>>>>> also not sure what the correct answer is. I know this was =
not
>>>>>> changed in
>>>>>>>>>>>>>> this revision but maybe we can still get this right.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> When fragments are created most of the fields are copied =
from the
>>>>>> IPv6
>>>>>>>>>>>>> headers (e.g., Source Address, Destination address, flow =
label,
>>>>>> traffic
>>>>>>>>>>>>> class, hop limit).  Some like payload length, next header, =
and hop
>>>>>> limi
>>>>>>>>>>>>> t are modified.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> If I understand your question, the answer is yes, the ECN =
code
>>>>>> point is
>>>>>>>>>>>>> copied from the first fragment, but should be the same =
from all of
>>>>>> the
>>>>>>>>>>>>> fragments.
>>>>>>>>=20
>>>>>>>> That is inconsistent with the following guidance in RFC 3168 =
(see
>>>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3):
>>>>>>>>=20
>>>>>>>> 5.3.  Fragmentation
>>>>>>>>=20
>>>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set.
>>>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of
>>>>>>>> congestion.  In other words, if any fragment of an IP packet to =
be
>>>>>>>> reassembled has the CE codepoint set, then one of two actions =
MUST be
>>>>>>>> taken:
>>>>>>>>=20
>>>>>>>>   * Set the CE codepoint on the reassembled packet.  However, =
this
>>>>>>>>     MUST NOT occur if any of the other fragments contributing =
to
>>>>>>>>     this reassembly carries the Not-ECT codepoint.
>>>>>>>>=20
>>>>>>>>   * The packet is dropped, instead of being reassembled, for =
any
>>>>>>>>     other reason.
>>>>>>>>=20
>>>>>>>> If both actions are applicable, either MAY be chosen.  =
Reassembly of
>>>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all =
of
>>>>>> the
>>>>>>>> fragments carry the same codepoint.
>>>>>>>>=20
>>>>>>>>>>>> My concern is that the ECN code point could be changed on =
one of
>>>>>> the
>>>>>>>>>>>> fragmented packets to signal congestion of a intermediate =
node and
>>>>>>>>>>>> then when you reassemble this information gets lost. That =
seems
>>>>>> wrong.
>>>>>>>>>>>=20
>>>>>>>>>>> That is an interesting idea, but I think out of scope for =
advancing this
>>>>>>>>>>> document to Internet Standard.  Then there is the question =
of how to
>>>>>>>>>>> encode n of m fragments experienced congestion.  Interesting =
future
>>>>>> work.
>>>>>>>>>>=20
>>>>>>>>>> Yes there might be some more further work needed but that =
still
>>>>>> makes the
>>>>>>>>>> guidance in this text wrong. Maybe we can add some text that =
the
>>>>>> Traffic
>>>>>>>>>> Class may be handled differently because it could be changed =
on the
>>>>>> path.
>>>>>>>>>=20
>>>>>>>>> Good point. It's not only ECN that can change; the DSCP can =
change too.
>>>>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's =
logical
>>>>>>>>> for 2460bis to note this issue.
>>>>>>>>=20
>>>>>>>> It seems that we (6man WG) missed this because RFC 3168 was not
>>>>>> marked
>>>>>>>> as updating RFC 2460. But in effect it did so for IPv6 =
implementations
>>>>>>>> of ECN, even though it was not written in an IP =
version-agnostic manner.
>>>>>>>>=20
>>>>>>>> At the very least text should be added to the description of =
the
>>>>>>>> reassembly process that points the reader to RFC 3168 or its
>>>>>>>> successor document.
>>>>>>>=20
>>>>>>> Do we have any evidence that the guidance in RFC 3168 regarding
>>>>>> reassembling
>>>>>>> IPv6 fragments is implemented?  I don=E2=80=99t know, but think =
if it there is
>>>>>>> evidence I agree some text should be added to rfc2460bis, if =
not, then
>>>>>>> maybe not.
>>>>>>=20
>>>>>> Since I lack the expertise to answer that question, I'm hoping =
that someone
>>>>>> in TSVWG will see this message and do so.
>>>>>>=20
>>>>>> Regardless of the answer to that question, my position would be =
that since
>>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the =
handling of
>>>>>> the Traffic Class field, the following modification to 2460bis =
Section 4.5
>>>>>> would be an appropriate way to deal with Mirja's comment:
>>>>>>=20
>>>>>> OLD:
>>>>>>    The number and content of the headers preceding the Fragment
>>>>>>    header of different fragments of the same original packet may
>>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>>    header in each fragment packet, are processed when the packets
>>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>    those headers in the Offset zero fragment packet are retained =
in
>>>>>>    the reassembled packet.
>>>>>> NEW:
>>>>>>    The number and content of the headers preceding the Fragment
>>>>>>    header of different fragments of the same original packet may
>>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>>    header in each fragment packet, are processed when the packets
>>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>    those headers in the Offset zero fragment packet are retained =
in
>>>>>>    the reassembled packet; however, nodes that support Explicit
>>>>>>    Congestion Notification [RFC3168] may use information in the
>>>>>>    Traffic Class field from all fragment packets to reconstruct =
the
>>>>>>    Traffic Class field in the reassembled packet.
>>>>>>=20
>>>>>> Note that this would not cause 2460bis itself to levy an =
additional
>>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It =
would
>>>>>> simply be making note of a requirement that is already levied by
>>>>>> RFC 3168.
>>>>>>=20
>>>>>> Thanks and regards,
>>>>>>=20
>>>>>> Mike Heard
>>>>>=20
>>>>> =
--------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> ipv6@ietf.org
>>>>> Administrative Requests: =
https://www.ietf.org/mailman/listinfo/ipv6
>>>>> =
--------------------------------------------------------------------
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


From nobody Tue Apr 18 20:05:17 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023BD129417; Tue, 18 Apr 2017 20:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level: 
X-Spam-Status: No, score=-2.202 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 Myu86OTQ_C_V; Tue, 18 Apr 2017 20:05:01 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B4E128D44; Tue, 18 Apr 2017 20:05:01 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 9FE4983E47; Tue, 18 Apr 2017 23:04:56 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sasl; bh=MyDKDwG0p436 RwhI1et0dvU7Ejk=; b=JZYS3xWJU2w0WQxiuBNoQf1yj2ZFRPcN6oSQziqTo2uA 6Lnhfi9qqzm7dYzDSF1i3t6f1F6TvLJ2qFgnxy7XGS/Q/74Q+4HiDtsOQ8ZmAZ5Q 7gPiGoGPFlfugSgXLzT7dMBDrTvrWNDoMmMZK2a9YmNmJV8sK0V9uyoGrvKoI/I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; q=dns; s=sasl; b=sUD5xY l3lHWt9yoIsAv8q+X3XnPKSA7F9R3yF6gBAy9+G6979qeTU0PIHnbczX769D5LQy c+r5ymjJFricPZxOo6ZoAd+vHZPxXsMLU99HtYYur04ptDHnnj7u+/aLqPqGmYhp v0vCTAxyp5F2zFjW6L9Uvi7CJtEDW8H6vbte0=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 963FD83E45; Tue, 18 Apr 2017 23:04:56 -0400 (EDT)
Received: from mail-qt0-f170.google.com (unknown [209.85.216.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id E4A8A83E41; Tue, 18 Apr 2017 23:04:55 -0400 (EDT)
Received: by mail-qt0-f170.google.com with SMTP id m36so9535043qtb.0; Tue, 18 Apr 2017 20:04:55 -0700 (PDT)
X-Gm-Message-State: AN3rC/5mtibui+WlSqm4FOb2Z9rzDLS9+ZLVNQ9LkeR1sM9uORgbwg8H Vkgm6//lcF7TWQrooE/OrLPhsYvJWg==
X-Received: by 10.200.45.167 with SMTP id p36mr571229qta.265.1492571095588; Tue, 18 Apr 2017 20:04:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.40.180 with HTTP; Tue, 18 Apr 2017 20:04:35 -0700 (PDT)
In-Reply-To: <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net>
References:   <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com>  <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net>
From: "C. M. Heard" 
Date: Tue, 18 Apr 2017 20:04:35 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "Mirja Kuehlewind (IETF)" 
Cc: Brian E Carpenter , Bob Hinden ,  "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>,  tsvwg , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Pobox-Relay-ID: F7441072-24AC-11E7-8E3D-C260AE2156B6-06080547!pb-smtp2.pobox.com
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 03:05:03 -0000

On Tue, Apr 18, 2017 at 12:42 PM, Mirja Kuehlewind (IETF) wrote:
> sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN sup=
port,
> the reassembled packet should also do that correctly, no matter if
> the nodes support ECN or not. Handling these fields correctly with
> fragmentation does not mean that the nodes supports ECN. So this is
> not optional=E2=80=A6

This seems confused (or else I am confused). We are discussing issues
related to reassembly of fragmented packets, and that is a process that
takes place in end systems only, not in forwarding nodes.

It is true that if an end system (aka host) supports ECN per RFC 3168,
then received packets that it reassembles must have the CE bit pattern
set if any fragment has the CE bit pattern set, provided that all
fragments contain either CE or ECT(0)/ECT(1). The text that we are
working on is intended to say that -- indirectly, by referring to the
Section 5.3 of RFC 3168.

But, unless ECN is mandatory-to-implement for all IPv6 nodes, end
systems are not obliged to support it -- and I see no such mandate
in the IPv6 node requirements document. In that case ECN indications
will simply be ignored. No purpose is served by levying a requirement
on the IPv6 module to preserve an indication that will not be used.

Mike Heard


From nobody Tue Apr 18 20:19:23 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EBC12940F; Tue, 18 Apr 2017 20:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 X21iF-J3n-Pc; Tue, 18 Apr 2017 20:18:58 -0700 (PDT)
Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 4FD7412708C; Tue, 18 Apr 2017 20:18:58 -0700 (PDT)
Received: by mail-pg0-x243.google.com with SMTP id 63so1964686pgh.0; Tue, 18 Apr 2017 20:18:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=kpQ7Or5Vj2VpeaHkIzmhJoiOnQ/sUajL7XBdsEbZS7I=; b=tfHkcp0bGcUzp6fgCiF4Du5ATrMdeHHIjKDrKtcu64tsdbzCXvg9WySbuYu8rglSn2 ItO9xIb6Bvlf2igh+juLet7Bf6aVWkgnwwU021wrpWi6gPNATLMRfGjCQobDcQwKoMq+ ooUvhblesMuZ46R7lPohCfN3N4cwen6qDSbj0gVWcgJWXRVf7szK2Inu4ppVnupqBA/1 GJOzfNXjLIl9Hu4G306hRTMXLBdp++PNO2jwGWGuCBovB18+Pa8rvAaze6pjbqZXsKY7 x6VQ8haZqJUgL4DGymwWC7qZBApJLA10mu2xE4k7qGUalGrl0GH7wkt7kEMR6SxjYTlw 9v1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=kpQ7Or5Vj2VpeaHkIzmhJoiOnQ/sUajL7XBdsEbZS7I=; b=BfwFDGm3WM1tMtlcEwP8aoSg6ObBksfGGBFVU+tZrpZ9DXI7AOrOD5pEZiqG2XGeA1 afuuZnnbfRJn56uMiyqkdPH1ZwQV+MJ4bsyaBbKA97SYl1Nm0UBaYb1d8w5ZKUtphGOW IQp6QtaTKApdr+mtoNUrL3C9LBgXNTXI36cZeMKxtw4Pp6sP7wjmRwBLTgTymvKUpfjM VUwavSFYESxZYNaXeYfhOgjV0YL2KdTxHAEwQr+KuqgzlQnHLoc/H1KIbXw0dF3Nomtm k0THyk2O5fi+TLlmqZMem9O/cQDQbdq9bmiRaQI19aSlYk8U6iiw1pTAvHjIu3TWZ9UN wyQw==
X-Gm-Message-State: AN3rC/7UbhENWO4h6lx9lcKNdH6hyRTX+ZtcsDQTxWg2dHZTD14F0W4i 9wsuBbVKmV8znw==
X-Received: by 10.84.205.70 with SMTP id o6mr976633plh.63.1492571937861; Tue, 18 Apr 2017 20:18:57 -0700 (PDT)
Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x6sm1003558pge.47.2017.04.18.20.18.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 20:18:57 -0700 (PDT)
To: "Mirja Kuehlewind (IETF)" 
References:   <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com>  <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net>
Cc: Bob Hinden , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <15e15419-67ca-5033-c53e-a5919079959e@gmail.com>
Date: Wed, 19 Apr 2017 15:18:56 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 03:19:01 -0000

Mirja,

Reassembly takes place in the destination node, which either does or does=
n't support ECN.
So I don't see your issue: if the node doesn't support ECN, the bits are =
ignored anyway.

    Brian

On 19/04/2017 07:42, Mirja Kuehlewind (IETF) wrote:
> Hi all,
>=20
> sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN s=
upport, the reassembled packet should also do that correctly, no matter i=
f the nodes support ECN or not. Handling these fields correctly with frag=
mentation does not mean that the nodes supports ECN. So this is not optio=
nal=E2=80=A6
>=20
> Mirja
>=20
>=20
>> Am 18.04.2017 um 02:38 schrieb Brian E Carpenter :
>>
>> wfm=20
>> On 18/04/2017 09:08, Bob Hinden wrote:
>>> Hi,
>>>
>>> After reading through the discussion, I think a new paragraph (after =
the text that says how to construct a reassembled packet) like the follow=
ing would be appropriate.
>>>
>>>         Nodes that support Explicit Congestion Notification [RFC3168]=

>>>         should use information in the Traffic Class field from all
>>>         fragment packets to reconstruct the Traffic Class field in th=
e
>>>         reassembled packet.  See Section 5.3 of RFC3168 for more
>>>         information.
>>>
>>> I don=E2=80=99t think we need to quote what RFC3168 says, just point =
the the correct section.
>>>
>>> This also doesn=E2=80=99t effect nodes that don=E2=80=99t support ECN=
, so it shouldn't be making any new requirements.
>>>
>>> Comments?
>>>
>>> Bob
>>>
>>>> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter  wrote:
>>>>
>>>> In line...
>>>>
>>>> On 18/04/2017 05:44, Black, David wrote:
>>>>> Extracting the key portions of text:
>>>>>
>>>>>>> That is inconsistent with the following guidance in RFC 3168 (see=

>>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3):
>>>>>>>
>>>>>>> 5.3.  Fragmentation
>>>>>>>
>>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set.
>>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of
>>>>>>> congestion.  In other words, if any fragment of an IP packet to b=
e
>>>>>>> reassembled has the CE codepoint set, then one of two actions MUS=
T be
>>>>>>> taken:
>>>>>>>
>>>>>>>    * Set the CE codepoint on the reassembled packet.  However, th=
is
>>>>>>>      MUST NOT occur if any of the other fragments contributing to=

>>>>>>>      this reassembly carries the Not-ECT codepoint.
>>>>>>>
>>>>>>>    * The packet is dropped, instead of being reassembled, for any=

>>>>>>>      other reason.
>>>>>>>
>>>>>>> If both actions are applicable, either MAY be chosen.  Reassembly=
 of
>>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all of=
 the
>>>>>>> fragments carry the same codepoint.
>>>>>
>>>>>> Regardless of the answer to that question, my position would be th=
at since
>>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the hand=
ling of
>>>>>> the Traffic Class field, the following modification to 2460bis Sec=
tion 4.5
>>>>>> would be an appropriate way to deal with Mirja's comment:
>>>>>>
>>>>>> OLD:
>>>>>>     The number and content of the headers preceding the Fragment
>>>>>>     header of different fragments of the same original packet may
>>>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>>>     header in each fragment packet, are processed when the packets=

>>>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>     those headers in the Offset zero fragment packet are retained =
in
>>>>>>     the reassembled packet.
>>>>>> NEW:
>>>>>>     The number and content of the headers preceding the Fragment
>>>>>>     header of different fragments of the same original packet may
>>>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>>>     header in each fragment packet, are processed when the packets=

>>>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>     those headers in the Offset zero fragment packet are retained =
in
>>>>>>     the reassembled packet; however, nodes that support Explicit
>>>>>>     Congestion Notification [RFC3168] may use information in the
>>>>>>     Traffic Class field from all fragment packets to reconstruct t=
he
>>>>>>     Traffic Class field in the reassembled packet.
>>>>>>
>>>>>> Note that this would not cause 2460bis itself to levy an additiona=
l
>>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It wo=
uld
>>>>>> simply be making note of a requirement that is already levied by
>>>>>> RFC 3168.
>>>>>
>>>>> In which case, the RFC 3168 requirement should be stated e.g.:
>>>>>
>>>>> OLD:
>>>>>     The number and content of the headers preceding the Fragment
>>>>>     header of different fragments of the same original packet may
>>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>>     header in each fragment packet, are processed when the packets
>>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>>     those headers in the Offset zero fragment packet are retained i=
n
>>>>>     the reassembled packet.
>>>>> NEW:
>>>>>     The number and content of the headers preceding the Fragment
>>>>>     header of different fragments of the same original packet may
>>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>>     header in each fragment packet, are processed when the packets
>>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>>     those headers in the Offset zero fragment packet are retained i=
n
>>>>>     the reassembled packet; however, nodes that support Explicit
>>>>>     Congestion Notification [RFC3168] may use information in the
>>>>>     Traffic Class field from any or all fragment packets to reconst=
ruct
>>>>>     the Traffic Class field in the reassembled packet in order to m=
eet
>>>>>     RFC 3168's requirements, e.g., that reassembly not lose indicat=
ions
>>>>>     of congestion, see Section 5.3 of RFC 3168 for additional infor=
mation.
>>>>>
>>>>> Pointing the implementer at Section 5.3 of RFC 3168 is better than
>>>>> hoping she figures out on her own that she ought to take a look at =
it .
>>>>
>>>> Yes. This is correct.
>>>>
>>>>  Brian
>>>>
>>>>>
>>>>> Thanks, --David
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. Hea=
rd
>>>>>> Sent: Monday, April 17, 2017 12:00 PM
>>>>>> To: 6MAN <6man@ietf.org>; tsvwg 
>>>>>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden
>>>>>> ; Mirja Kuehlewind (IETF) ;
>>>>>> IESG ; 6man Chairs <6man-chairs@ietf.org>
>>>>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on draft-ietf-=
6man-rfc2460bis-
>>>>>> 09: (with DISCUSS and COMMENT)
>>>>>>
>>>>>> [ TSVWG added to solicit advice on implementation of RFC 3186 Sect=
ion 5.3 ]
>>>>>>
>>>>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote:
>>>>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard  wrote:=

>>>>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote:
>>>>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote:
>>>>>>>>> ...
>>>>>>>>>>>>>> ----------------------------------------------------------=
------------
>>>>>>>>>>>>>> COMMENT:
>>>>>>>>>>>>>> ----------------------------------------------------------=
------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> One question because I'm not sure if I interpret this corr=
ect to
>>>>>> make it
>>>>>>>>>>>>>> part of my discuss:
>>>>>>>>>>>>>> Section 4.5: "The number and content of the headers preced=
ing
>>>>>> the
>>>>>>>>>>>>>> Fragment
>>>>>>>>>>>>>> header of different fragments of the same original packet =
may
>>>>>>>>>>>>>> differ.  Whatever headers are present, preceding the Fragm=
ent
>>>>>>>>>>>>>> header in each fragment packet, are processed when the pac=
kets
>>>>>>>>>>>>>> arrive, prior to queueing the fragments for reassembly.  O=
nly
>>>>>>>>>>>>>> those headers in the Offset zero fragment packet are retai=
ned in
>>>>>>>>>>>>>> the reassembled packet."
>>>>>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Clas=
s field)
>>>>>> is
>>>>>>>>>>>>>> copied from the first fragment? This doesn't seem to be co=
rrect,
>>>>>> however,
>>>>>>>>>>>>>> also not sure what the correct answer is. I know this was =
not
>>>>>> changed in
>>>>>>>>>>>>>> this revision but maybe we can still get this right.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When fragments are created most of the fields are copied fr=
om the
>>>>>> IPv6
>>>>>>>>>>>>> headers (e.g., Source Address, Destination address, flow la=
bel,
>>>>>> traffic
>>>>>>>>>>>>> class, hop limit).  Some like payload length, next header, =
and hop
>>>>>> limi
>>>>>>>>>>>>> t are modified.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If I understand your question, the answer is yes, the ECN c=
ode
>>>>>> point is
>>>>>>>>>>>>> copied from the first fragment, but should be the same from=
 all of
>>>>>> the
>>>>>>>>>>>>> fragments.
>>>>>>>>
>>>>>>>> That is inconsistent with the following guidance in RFC 3168 (se=
e
>>>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3):
>>>>>>>>
>>>>>>>> 5.3.  Fragmentation
>>>>>>>>
>>>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set.
>>>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of
>>>>>>>> congestion.  In other words, if any fragment of an IP packet to =
be
>>>>>>>> reassembled has the CE codepoint set, then one of two actions MU=
ST be
>>>>>>>> taken:
>>>>>>>>
>>>>>>>>    * Set the CE codepoint on the reassembled packet.  However, t=
his
>>>>>>>>      MUST NOT occur if any of the other fragments contributing t=
o
>>>>>>>>      this reassembly carries the Not-ECT codepoint.
>>>>>>>>
>>>>>>>>    * The packet is dropped, instead of being reassembled, for an=
y
>>>>>>>>      other reason.
>>>>>>>>
>>>>>>>> If both actions are applicable, either MAY be chosen.  Reassembl=
y of
>>>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all o=
f
>>>>>> the
>>>>>>>> fragments carry the same codepoint.
>>>>>>>>
>>>>>>>>>>>> My concern is that the ECN code point could be changed on on=
e of
>>>>>> the
>>>>>>>>>>>> fragmented packets to signal congestion of a intermediate no=
de and
>>>>>>>>>>>> then when you reassemble this information gets lost. That se=
ems
>>>>>> wrong.
>>>>>>>>>>>
>>>>>>>>>>> That is an interesting idea, but I think out of scope for adv=
ancing this
>>>>>>>>>>> document to Internet Standard.  Then there is the question of=
 how to
>>>>>>>>>>> encode n of m fragments experienced congestion.  Interesting =
future
>>>>>> work.
>>>>>>>>>>
>>>>>>>>>> Yes there might be some more further work needed but that stil=
l
>>>>>> makes the
>>>>>>>>>> guidance in this text wrong. Maybe we can add some text that t=
he
>>>>>> Traffic
>>>>>>>>>> Class may be handled differently because it could be changed o=
n the
>>>>>> path.
>>>>>>>>>
>>>>>>>>> Good point. It's not only ECN that can change; the DSCP can cha=
nge too.
>>>>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's log=
ical
>>>>>>>>> for 2460bis to note this issue.
>>>>>>>>
>>>>>>>> It seems that we (6man WG) missed this because RFC 3168 was not
>>>>>> marked
>>>>>>>> as updating RFC 2460. But in effect it did so for IPv6 implement=
ations
>>>>>>>> of ECN, even though it was not written in an IP version-agnostic=
 manner.
>>>>>>>>
>>>>>>>> At the very least text should be added to the description of the=

>>>>>>>> reassembly process that points the reader to RFC 3168 or its
>>>>>>>> successor document.
>>>>>>>
>>>>>>> Do we have any evidence that the guidance in RFC 3168 regarding
>>>>>> reassembling
>>>>>>> IPv6 fragments is implemented?  I don=E2=80=99t know, but think i=
f it there is
>>>>>>> evidence I agree some text should be added to rfc2460bis, if not,=
 then
>>>>>>> maybe not.
>>>>>>
>>>>>> Since I lack the expertise to answer that question, I'm hoping tha=
t someone
>>>>>> in TSVWG will see this message and do so.
>>>>>>
>>>>>> Regardless of the answer to that question, my position would be th=
at since
>>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the hand=
ling of
>>>>>> the Traffic Class field, the following modification to 2460bis Sec=
tion 4.5
>>>>>> would be an appropriate way to deal with Mirja's comment:
>>>>>>
>>>>>> OLD:
>>>>>>     The number and content of the headers preceding the Fragment
>>>>>>     header of different fragments of the same original packet may
>>>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>>>     header in each fragment packet, are processed when the packets=

>>>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>     those headers in the Offset zero fragment packet are retained =
in
>>>>>>     the reassembled packet.
>>>>>> NEW:
>>>>>>     The number and content of the headers preceding the Fragment
>>>>>>     header of different fragments of the same original packet may
>>>>>>     differ.  Whatever headers are present, preceding the Fragment
>>>>>>     header in each fragment packet, are processed when the packets=

>>>>>>     arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>     those headers in the Offset zero fragment packet are retained =
in
>>>>>>     the reassembled packet; however, nodes that support Explicit
>>>>>>     Congestion Notification [RFC3168] may use information in the
>>>>>>     Traffic Class field from all fragment packets to reconstruct t=
he
>>>>>>     Traffic Class field in the reassembled packet.
>>>>>>
>>>>>> Note that this would not cause 2460bis itself to levy an additiona=
l
>>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It wo=
uld
>>>>>> simply be making note of a requirement that is already levied by
>>>>>> RFC 3168.
>>>>>>
>>>>>> Thanks and regards,
>>>>>>
>>>>>> Mike Heard
>>>>>
>>>>> -------------------------------------------------------------------=
-
>>>>> IETF IPv6 working group mailing list
>>>>> ipv6@ietf.org
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=

>>>>> -------------------------------------------------------------------=
-
>>>>>
>>>>
>>>
>>
>=20
>=20


From nobody Tue Apr 18 21:17:46 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A971279E5; Tue, 18 Apr 2017 21:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aPKfj2O7rzvz; Tue, 18 Apr 2017 21:17:25 -0700 (PDT)
Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 1193E1200DF; Tue, 18 Apr 2017 21:17:25 -0700 (PDT)
Received: by mail-pg0-x242.google.com with SMTP id o123so2148494pga.1; Tue, 18 Apr 2017 21:17:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cMdLbycZG6F7GqLkh3PumTofjsZDPp86gwy2Fp3LJvw=; b=K3y/c08QWRgNObaVXTVUK3jzTWtkVKDAK3+7bOHax2wR9HwLRQOeCkM87muZcuUF21 gJXMYvJwFWii/1YJaGPs7RTL8llWn0zzuo1Pnpm5UhKWRA9bVcQqD1Bo0U4QrjwCx8No fKGlgzr7IkqN3SMCyh31TLhkHGPsRr2gr2Uqr+RNKW/TZ6vmbVgNyWD98ZG0mWbArwbA ZN4xfDFANSL20rPIHQikXC7nxay5tYu0NxG/weQoSMEwciRpOQ2iAOExkSP+HMzgvu7U XYOCqfUo2hJ1emO4nFYSGv3DT2QbARueqM99DapDzPwqZuEv28cE9fW43BNCg1kyQIYy OB+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cMdLbycZG6F7GqLkh3PumTofjsZDPp86gwy2Fp3LJvw=; b=EE1Fg/VC18oF0Mjjelgv399fCFSdbctwhziGp72tglry4nQbJItQJeOJ+vrWSCPDQ5 HYludqrlf277URXozj8idyI3f2LkxoFVb1LZvzxOnISMML7Pmngfr8BPmCTInjXVNJ2Q hXeeB21k1tSd8TJmKVu6pvpXxXyPNwak8/MajHyOQyUbHQdDWMjaCSP5mASnALsNaUBx 0pON5CX5RcdFaeFbjBbYAvUOCdmS1e/qZd6C0axILjY6so50dGB/iKi7qHbyFWZ/7lhA HnUOFktZPKHPh41xiu+MhWLxUlcdnnMqnFXy46fq+mB32cllYwyYaHG2P22XQFf9SFTk D9hQ==
X-Gm-Message-State: AN3rC/4jP3BB7l0S+Zibwhlp7yCSWbItvdFNvkQ2lScTPbFHhL9QTKLT BSFU1i3Rix0YHpF/
X-Received: by 10.84.236.8 with SMTP id q8mr1241444plk.104.1492575444428; Tue, 18 Apr 2017 21:17:24 -0700 (PDT)
Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n67sm1232069pfk.44.2017.04.18.21.17.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 21:17:23 -0700 (PDT)
To: "Mirja Kuehlewind (IETF)" 
References:   <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com>  <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> 
Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , Bob Hinden , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <4123b311-7dbb-0d17-9534-388a4477d280@gmail.com>
Date: Wed, 19 Apr 2017 16:17:22 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 04:17:28 -0000

On 19/04/2017 12:51, Mirja Kuehlewind (IETF) wrote:
> Hi again,
>=20
> I should probably have been more constructive here. I=E2=80=99d like to=
 propose the following text:
>=20
> The number and content of the headers preceding the Fragment
> header of different fragments of the same original packet may
> differ.  Whatever headers are present, preceding the Fragment
> header in each fragment packet, are processed when the packets
> arrive, prior to queueing the fragments for reassembly.  Only
> those headers in the Offset zero fragment packet are retained in
> the reassembled packet; however, the Traffic Class field from=20
> any or all fragments may differ. Handling of Explicit
> Congestion Notification [RFC3168] is described in Section 5.3 of=20
> RFC 3168, ensuring that reassembly does not lose indications
> of congestion.
>=20
> Do we also need to say something about DiffServ?

I think not. The existing text says that the DSCP bits in the first
fragment, win and that's fine. If one of the later fragments has been
re-marked for some reason, there is no reason to take any notice.

(Specifically: we can assume that the transport header is in the first
fragment, and any meaningful re-marking would be based on the transport
header. Any re-marking of the later fragments is bogus.)

    Brian

> Mirja
>=20
>=20
>=20
>=20
>> Am 18.04.2017 um 21:42 schrieb Mirja Kuehlewind (IETF) :
>>
>> Hi all,
>>
>> sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN =
support, the reassembled packet should also do that correctly, no matter =
if the nodes support ECN or not. Handling these fields correctly with fra=
gmentation does not mean that the nodes supports ECN. So this is not opti=
onal=E2=80=A6
>>
>> Mirja
>>
>>
>>> Am 18.04.2017 um 02:38 schrieb Brian E Carpenter :
>>>
>>> wfm=20
>>> On 18/04/2017 09:08, Bob Hinden wrote:
>>>> Hi,
>>>>
>>>> After reading through the discussion, I think a new paragraph (after=
 the text that says how to construct a reassembled packet) like the follo=
wing would be appropriate.
>>>>
>>>>        Nodes that support Explicit Congestion Notification [RFC3168]=

>>>>        should use information in the Traffic Class field from all
>>>>        fragment packets to reconstruct the Traffic Class field in th=
e
>>>>        reassembled packet.  See Section 5.3 of RFC3168 for more
>>>>        information.
>>>>
>>>> I don=E2=80=99t think we need to quote what RFC3168 says, just point=
 the the correct section.
>>>>
>>>> This also doesn=E2=80=99t effect nodes that don=E2=80=99t support EC=
N, so it shouldn't be making any new requirements.
>>>>
>>>> Comments?
>>>>
>>>> Bob
>>>>
>>>>> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter  wrote:
>>>>>
>>>>> In line...
>>>>>
>>>>> On 18/04/2017 05:44, Black, David wrote:
>>>>>> Extracting the key portions of text:
>>>>>>
>>>>>>>> That is inconsistent with the following guidance in RFC 3168 (se=
e
>>>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3):
>>>>>>>>
>>>>>>>> 5.3.  Fragmentation
>>>>>>>>
>>>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set.
>>>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of
>>>>>>>> congestion.  In other words, if any fragment of an IP packet to =
be
>>>>>>>> reassembled has the CE codepoint set, then one of two actions MU=
ST be
>>>>>>>> taken:
>>>>>>>>
>>>>>>>>   * Set the CE codepoint on the reassembled packet.  However, th=
is
>>>>>>>>     MUST NOT occur if any of the other fragments contributing to=

>>>>>>>>     this reassembly carries the Not-ECT codepoint.
>>>>>>>>
>>>>>>>>   * The packet is dropped, instead of being reassembled, for any=

>>>>>>>>     other reason.
>>>>>>>>
>>>>>>>> If both actions are applicable, either MAY be chosen.  Reassembl=
y of
>>>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all o=
f the
>>>>>>>> fragments carry the same codepoint.
>>>>>>
>>>>>>> Regardless of the answer to that question, my position would be t=
hat since
>>>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the han=
dling of
>>>>>>> the Traffic Class field, the following modification to 2460bis Se=
ction 4.5
>>>>>>> would be an appropriate way to deal with Mirja's comment:
>>>>>>>
>>>>>>> OLD:
>>>>>>>    The number and content of the headers preceding the Fragment
>>>>>>>    header of different fragments of the same original packet may
>>>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>>>    header in each fragment packet, are processed when the packets=

>>>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>>    those headers in the Offset zero fragment packet are retained =
in
>>>>>>>    the reassembled packet.
>>>>>>> NEW:
>>>>>>>    The number and content of the headers preceding the Fragment
>>>>>>>    header of different fragments of the same original packet may
>>>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>>>    header in each fragment packet, are processed when the packets=

>>>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>>    those headers in the Offset zero fragment packet are retained =
in
>>>>>>>    the reassembled packet; however, nodes that support Explicit
>>>>>>>    Congestion Notification [RFC3168] may use information in the
>>>>>>>    Traffic Class field from all fragment packets to reconstruct t=
he
>>>>>>>    Traffic Class field in the reassembled packet.
>>>>>>>
>>>>>>> Note that this would not cause 2460bis itself to levy an addition=
al
>>>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It w=
ould
>>>>>>> simply be making note of a requirement that is already levied by
>>>>>>> RFC 3168.
>>>>>>
>>>>>> In which case, the RFC 3168 requirement should be stated e.g.:
>>>>>>
>>>>>> OLD:
>>>>>>    The number and content of the headers preceding the Fragment
>>>>>>    header of different fragments of the same original packet may
>>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>>    header in each fragment packet, are processed when the packets
>>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>    those headers in the Offset zero fragment packet are retained i=
n
>>>>>>    the reassembled packet.
>>>>>> NEW:
>>>>>>    The number and content of the headers preceding the Fragment
>>>>>>    header of different fragments of the same original packet may
>>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>>    header in each fragment packet, are processed when the packets
>>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>    those headers in the Offset zero fragment packet are retained i=
n
>>>>>>    the reassembled packet; however, nodes that support Explicit
>>>>>>    Congestion Notification [RFC3168] may use information in the
>>>>>>    Traffic Class field from any or all fragment packets to reconst=
ruct
>>>>>>    the Traffic Class field in the reassembled packet in order to m=
eet
>>>>>>    RFC 3168's requirements, e.g., that reassembly not lose indicat=
ions
>>>>>>    of congestion, see Section 5.3 of RFC 3168 for additional infor=
mation.
>>>>>>
>>>>>> Pointing the implementer at Section 5.3 of RFC 3168 is better than=

>>>>>> hoping she figures out on her own that she ought to take a look at=
 it .
>>>>>
>>>>> Yes. This is correct.
>>>>>
>>>>> Brian
>>>>>
>>>>>>
>>>>>> Thanks, --David
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. He=
ard
>>>>>>> Sent: Monday, April 17, 2017 12:00 PM
>>>>>>> To: 6MAN <6man@ietf.org>; tsvwg 
>>>>>>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden
>>>>>>> ; Mirja Kuehlewind (IETF) ;
>>>>>>> IESG ; 6man Chairs <6man-chairs@ietf.org>
>>>>>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on draft-ietf=
-6man-rfc2460bis-
>>>>>>> 09: (with DISCUSS and COMMENT)
>>>>>>>
>>>>>>> [ TSVWG added to solicit advice on implementation of RFC 3186 Sec=
tion 5.3 ]
>>>>>>>
>>>>>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote:
>>>>>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard  wrote=
:
>>>>>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote:
>>>>>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote:
>>>>>>>>>> ...
>>>>>>>>>>>>>>> ---------------------------------------------------------=
-------------
>>>>>>>>>>>>>>> COMMENT:
>>>>>>>>>>>>>>> ---------------------------------------------------------=
-------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> One question because I'm not sure if I interpret this cor=
rect to
>>>>>>> make it
>>>>>>>>>>>>>>> part of my discuss:
>>>>>>>>>>>>>>> Section 4.5: "The number and content of the headers prece=
ding
>>>>>>> the
>>>>>>>>>>>>>>> Fragment
>>>>>>>>>>>>>>> header of different fragments of the same original packet=
 may
>>>>>>>>>>>>>>> differ.  Whatever headers are present, preceding the Frag=
ment
>>>>>>>>>>>>>>> header in each fragment packet, are processed when the pa=
ckets
>>>>>>>>>>>>>>> arrive, prior to queueing the fragments for reassembly.  =
Only
>>>>>>>>>>>>>>> those headers in the Offset zero fragment packet are reta=
ined in
>>>>>>>>>>>>>>> the reassembled packet."
>>>>>>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Cla=
ss field)
>>>>>>> is
>>>>>>>>>>>>>>> copied from the first fragment? This doesn't seem to be c=
orrect,
>>>>>>> however,
>>>>>>>>>>>>>>> also not sure what the correct answer is. I know this was=
 not
>>>>>>> changed in
>>>>>>>>>>>>>>> this revision but maybe we can still get this right.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When fragments are created most of the fields are copied f=
rom the
>>>>>>> IPv6
>>>>>>>>>>>>>> headers (e.g., Source Address, Destination address, flow l=
abel,
>>>>>>> traffic
>>>>>>>>>>>>>> class, hop limit).  Some like payload length, next header,=
 and hop
>>>>>>> limi
>>>>>>>>>>>>>> t are modified.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If I understand your question, the answer is yes, the ECN =
code
>>>>>>> point is
>>>>>>>>>>>>>> copied from the first fragment, but should be the same fro=
m all of
>>>>>>> the
>>>>>>>>>>>>>> fragments.
>>>>>>>>>
>>>>>>>>> That is inconsistent with the following guidance in RFC 3168 (s=
ee
>>>>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3):
>>>>>>>>>
>>>>>>>>> 5.3.  Fragmentation
>>>>>>>>>
>>>>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set.
>>>>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of
>>>>>>>>> congestion.  In other words, if any fragment of an IP packet to=
 be
>>>>>>>>> reassembled has the CE codepoint set, then one of two actions M=
UST be
>>>>>>>>> taken:
>>>>>>>>>
>>>>>>>>>   * Set the CE codepoint on the reassembled packet.  However, t=
his
>>>>>>>>>     MUST NOT occur if any of the other fragments contributing t=
o
>>>>>>>>>     this reassembly carries the Not-ECT codepoint.
>>>>>>>>>
>>>>>>>>>   * The packet is dropped, instead of being reassembled, for an=
y
>>>>>>>>>     other reason.
>>>>>>>>>
>>>>>>>>> If both actions are applicable, either MAY be chosen.  Reassemb=
ly of
>>>>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all =
of
>>>>>>> the
>>>>>>>>> fragments carry the same codepoint.
>>>>>>>>>
>>>>>>>>>>>>> My concern is that the ECN code point could be changed on o=
ne of
>>>>>>> the
>>>>>>>>>>>>> fragmented packets to signal congestion of a intermediate n=
ode and
>>>>>>>>>>>>> then when you reassemble this information gets lost. That s=
eems
>>>>>>> wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> That is an interesting idea, but I think out of scope for ad=
vancing this
>>>>>>>>>>>> document to Internet Standard.  Then there is the question o=
f how to
>>>>>>>>>>>> encode n of m fragments experienced congestion.  Interesting=
 future
>>>>>>> work.
>>>>>>>>>>>
>>>>>>>>>>> Yes there might be some more further work needed but that sti=
ll
>>>>>>> makes the
>>>>>>>>>>> guidance in this text wrong. Maybe we can add some text that =
the
>>>>>>> Traffic
>>>>>>>>>>> Class may be handled differently because it could be changed =
on the
>>>>>>> path.
>>>>>>>>>>
>>>>>>>>>> Good point. It's not only ECN that can change; the DSCP can ch=
ange too.
>>>>>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's lo=
gical
>>>>>>>>>> for 2460bis to note this issue.
>>>>>>>>>
>>>>>>>>> It seems that we (6man WG) missed this because RFC 3168 was not=

>>>>>>> marked
>>>>>>>>> as updating RFC 2460. But in effect it did so for IPv6 implemen=
tations
>>>>>>>>> of ECN, even though it was not written in an IP version-agnosti=
c manner.
>>>>>>>>>
>>>>>>>>> At the very least text should be added to the description of th=
e
>>>>>>>>> reassembly process that points the reader to RFC 3168 or its
>>>>>>>>> successor document.
>>>>>>>>
>>>>>>>> Do we have any evidence that the guidance in RFC 3168 regarding
>>>>>>> reassembling
>>>>>>>> IPv6 fragments is implemented?  I don=E2=80=99t know, but think =
if it there is
>>>>>>>> evidence I agree some text should be added to rfc2460bis, if not=
, then
>>>>>>>> maybe not.
>>>>>>>
>>>>>>> Since I lack the expertise to answer that question, I'm hoping th=
at someone
>>>>>>> in TSVWG will see this message and do so.
>>>>>>>
>>>>>>> Regardless of the answer to that question, my position would be t=
hat since
>>>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the han=
dling of
>>>>>>> the Traffic Class field, the following modification to 2460bis Se=
ction 4.5
>>>>>>> would be an appropriate way to deal with Mirja's comment:
>>>>>>>
>>>>>>> OLD:
>>>>>>>    The number and content of the headers preceding the Fragment
>>>>>>>    header of different fragments of the same original packet may
>>>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>>>    header in each fragment packet, are processed when the packets=

>>>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>>    those headers in the Offset zero fragment packet are retained =
in
>>>>>>>    the reassembled packet.
>>>>>>> NEW:
>>>>>>>    The number and content of the headers preceding the Fragment
>>>>>>>    header of different fragments of the same original packet may
>>>>>>>    differ.  Whatever headers are present, preceding the Fragment
>>>>>>>    header in each fragment packet, are processed when the packets=

>>>>>>>    arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>>    those headers in the Offset zero fragment packet are retained =
in
>>>>>>>    the reassembled packet; however, nodes that support Explicit
>>>>>>>    Congestion Notification [RFC3168] may use information in the
>>>>>>>    Traffic Class field from all fragment packets to reconstruct t=
he
>>>>>>>    Traffic Class field in the reassembled packet.
>>>>>>>
>>>>>>> Note that this would not cause 2460bis itself to levy an addition=
al
>>>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It w=
ould
>>>>>>> simply be making note of a requirement that is already levied by
>>>>>>> RFC 3168.
>>>>>>>
>>>>>>> Thanks and regards,
>>>>>>>
>>>>>>> Mike Heard
>>>>>>
>>>>>> ------------------------------------------------------------------=
--
>>>>>> IETF IPv6 working group mailing list
>>>>>> ipv6@ietf.org
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv=
6
>>>>>> ------------------------------------------------------------------=
--
>>>>>>
>>>>>
>>>>
>>>
>>
>=20
>=20


From nobody Tue Apr 18 21:29:44 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033C0127B73; Tue, 18 Apr 2017 21:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level: 
X-Spam-Status: No, score=-2.202 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 W3F6rgDnnLWn; Tue, 18 Apr 2017 21:29:35 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9137126579; Tue, 18 Apr 2017 21:29:34 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3079082E5E; Wed, 19 Apr 2017 00:29:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sasl; bh=mWE8mv1Zj6Hc Bz0EVednVFgyVDc=; b=JOhEKvaTq7cU1ndX4+IPGYkoS0FI87alGqOHzpiZKPGn jqBNmMiWpeZCxGSsHoXug5ksRH1ybfvkQHdNpCHGD+p2YRNB0L41/aLB6ySU5WsV c6djpNYANZ7qSC5viqPX4tATd94sYE8OrnVKZSQHNhCPOPnlcxeCoIZPnfQ7Fx4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; q=dns; s=sasl; b=EF0nZN KGN8yM5yzQRgg8z6P0jgUStKSP8lTsSVd3zdkv88YomdF4SYU0X19ZCFI57WlaSV /yIwLoi5E3ymlobf+9fCqLXBXlOawaitkz6qo9KiLDucKbIYcoO14d2js2FyiV5U toz3m/RNQ3eTilp624mIBYqLAopvehuaQghHk=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 217F382E5D; Wed, 19 Apr 2017 00:29:33 -0400 (EDT)
Received: from mail-qt0-f173.google.com (unknown [209.85.216.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 9136B82E59; Wed, 19 Apr 2017 00:29:32 -0400 (EDT)
Received: by mail-qt0-f173.google.com with SMTP id c45so10352029qtb.1; Tue, 18 Apr 2017 21:29:32 -0700 (PDT)
X-Gm-Message-State: AN3rC/6VGujNdz/v1uAzWoBKI7hYx14AUc6LRsHbO84aFFHG4NvNA6xR iwVNURg2HN3b3smxxTV9PFMjx3+RFg==
X-Received: by 10.200.47.91 with SMTP id k27mr676220qta.11.1492576172151; Tue, 18 Apr 2017 21:29:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.40.180 with HTTP; Tue, 18 Apr 2017 21:29:11 -0700 (PDT)
In-Reply-To: <4123b311-7dbb-0d17-9534-388a4477d280@gmail.com>
References:   <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com>  <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net>  <4123b311-7dbb-0d17-9534-388a4477d280@gmail.com>
From: "C. M. Heard" 
Date: Tue, 18 Apr 2017 21:29:11 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Brian E Carpenter 
Cc: "Mirja Kuehlewind (IETF)" ,  "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>,  tsvwg , Bob Hinden ,  "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Pobox-Relay-ID: C9311084-24B8-11E7-AFBF-E680B56B9B0B-06080547!pb-smtp1.pobox.com
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 04:29:36 -0000

On Tue, Apr 18, 2017 at 9:17 PM, Brian E Carpenter wrote:
> On 19/04/2017 12:51, Mirja Kuehlewind (IETF) wrote:
>> Hi again,
>>
>> I should probably have been more constructive here. I=E2=80=99d like to =
propose the following text:
>>
>> The number and content of the headers preceding the Fragment
>> header of different fragments of the same original packet may
>> differ.  Whatever headers are present, preceding the Fragment
>> header in each fragment packet, are processed when the packets
>> arrive, prior to queueing the fragments for reassembly.  Only
>> those headers in the Offset zero fragment packet are retained in
>> the reassembled packet; however, the Traffic Class field from
>> any or all fragments may differ. Handling of Explicit
>> Congestion Notification [RFC3168] is described in Section 5.3 of
>> RFC 3168, ensuring that reassembly does not lose indications
>> of congestion.
>>
>> Do we also need to say something about DiffServ?
>
> I think not. The existing text says that the DSCP bits in the first
> fragment, win and that's fine. If one of the later fragments has been
> re-marked for some reason, there is no reason to take any notice.
>
> (Specifically: we can assume that the transport header is in the first
> fragment, and any meaningful re-marking would be based on the transport
> header. Any re-marking of the later fragments is bogus.)

Do end systems even care what the DSCP bits are?

//cmh


From nobody Tue Apr 18 21:34:23 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E445D12943F; Tue, 18 Apr 2017 21:34: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, FREEMAIL_FROM=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=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 sQ57vRX1O0X2; Tue, 18 Apr 2017 21:34:07 -0700 (PDT)
Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 5E3AD127B73; Tue, 18 Apr 2017 21:34:07 -0700 (PDT)
Received: by mail-pg0-x241.google.com with SMTP id g2so2199728pge.2; Tue, 18 Apr 2017 21:34:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=EkX5B6tX6R4q65+UkDL/ysQOrZV3MRQRQnHMleRXoXA=; b=W4vnZ2/NBWhKb9+WQ9IoplIkYOVc7i6pcF+Anjr1RLt3kGRGsHpzk0Bh1J5QuYnOlr LCQ0wFCoP8tbasDBLBDkK5O8Zp/yRpOkhq3R+X7qYXMtcsrwqOXXVgRWEb4fPDL9rO9t lqU3gIHv1mMQWQidbxzQbXK9LQNqiXZ6YBh9Z484X5n3U21H2RiPZ8pQZFlj1HJPSr9D 9hviIIyjuaXa71TKKNYuH/A5gBg6Pq92IpUROMejSEZAB7JsOkqzQ3YO5qpeEgeHYfwv HEV4xdJdabuxt6Fw2wv3Woz3h0H/MYQjHMsqVAsFtB3pDnunP4SRO30V7di/5Xzn11JS tlBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=EkX5B6tX6R4q65+UkDL/ysQOrZV3MRQRQnHMleRXoXA=; b=dGxt0/CWsNV9xGJ8VHCn1IJYIHbZ75CHzwsa5oZAZqdCULHu38BYFERWpYZ7UzoNKN PIWVSSsgiCcZPEMOxGLtevGSes2/+8HMV5etWIKXzJ+oLFgxFkKaU2tiEcCjShGTHDRt 1u8UEaiImrroiQdDGhjkLUff1WgKTMng8PxLbSsiPHibR+Ujt/AgNopSU3m4x+rOfu61 snhI+6d8w22kHuvYZlZp+uLceO7oxeA9H6n8yyNCuBeCGtmAO++i0e+z0Pkk0KgTCFyB Bd3ZNOUKBSGixvj3df+ZDX6/znCxdZJDFmn8OO6CnXbP4FM+E26MFTZVC5t1jSfdm62B ICsw==
X-Gm-Message-State: AN3rC/7Zp3TsPFuMWpMydX0JFqcReyMdmI6dXdV9m03IBhd9OLFZgGL0 WLk1ppg2B9YRJg==
X-Received: by 10.99.99.2 with SMTP id x2mr987469pgb.46.1492576447012; Tue, 18 Apr 2017 21:34:07 -0700 (PDT)
Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x9sm1296525pff.98.2017.04.18.21.34.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 21:34:06 -0700 (PDT)
To: "C. M. Heard" 
References:   <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com>  <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net>  <4123b311-7dbb-0d17-9534-388a4477d280@gmail.com> 
Cc: "Mirja Kuehlewind (IETF)" , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , Bob Hinden , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <21ac4ad4-5858-7cc8-4b21-808c292f72c5@gmail.com>
Date: Wed, 19 Apr 2017 16:34:05 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 04:34:09 -0000

On 19/04/2017 16:29, C. M. Heard wrote:
> On Tue, Apr 18, 2017 at 9:17 PM, Brian E Carpenter wrote:
>> On 19/04/2017 12:51, Mirja Kuehlewind (IETF) wrote:
>>> Hi again,
>>>
>>> I should probably have been more constructive here. I=E2=80=99d like =
to propose the following text:
>>>
>>> The number and content of the headers preceding the Fragment
>>> header of different fragments of the same original packet may
>>> differ.  Whatever headers are present, preceding the Fragment
>>> header in each fragment packet, are processed when the packets
>>> arrive, prior to queueing the fragments for reassembly.  Only
>>> those headers in the Offset zero fragment packet are retained in
>>> the reassembled packet; however, the Traffic Class field from
>>> any or all fragments may differ. Handling of Explicit
>>> Congestion Notification [RFC3168] is described in Section 5.3 of
>>> RFC 3168, ensuring that reassembly does not lose indications
>>> of congestion.
>>>
>>> Do we also need to say something about DiffServ?
>>
>> I think not. The existing text says that the DSCP bits in the first
>> fragment, win and that's fine. If one of the later fragments has been
>> re-marked for some reason, there is no reason to take any notice.
>>
>> (Specifically: we can assume that the transport header is in the first=

>> fragment, and any meaningful re-marking would be based on the transpor=
t
>> header. Any re-marking of the later fragments is bogus.)
>=20
> Do end systems even care what the DSCP bits are?

Yes, definitely if they're a tunnel end point (RFC 2983), and possibly
if they want to do some sort of input-buffer queue management for real
time traffic.

    Brian


From nobody Tue Apr 18 23:40:39 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585E613150E for ; Tue, 18 Apr 2017 23:40:37 -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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIr0Y5CMHuw0 for ; Tue, 18 Apr 2017 23:40:36 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0411113151E for ; Tue, 18 Apr 2017 23:40:36 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 20762B80E78; Tue, 18 Apr 2017 23:40:22 -0700 (PDT)
To: michelle.cotton@icann.org, lars.eggert@nokia.com, touch@isi.edu, magnus.westerlund@ericsson.com, cheshire@apple.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, david.black@emc.com, gorry@erg.abdn.ac.uk, wes@mti-systems.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: mnot@mnot.net, tsvwg@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170419064022.20762B80E78@rfc-editor.org>
Date: Tue, 18 Apr 2017 23:40:22 -0700 (PDT)
Archived-At: 
Subject: [tsvwg] [Technical Errata Reported] RFC6335 (4999)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 06:40:37 -0000

The following errata report has been submitted for RFC6335,
"Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6335&eid=4999

--------------------------------------
Type: Technical
Reported by: Mark Nottingham 

Section: GLOBAL

Original Text
-------------


Corrected Text
--------------


Notes
-----
HOLD FOR UPDATE

Many port number assignments are to individuals, but the document does not
contemplate how they should be handled when the assignee is dead or
otherwise can't be contacted. 

The most obvious procedure to follow is a transfer (8.5), but that requires 
de-assignment (8.2), and that doesn't cover the case above.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6335 (draft-ietf-tsvwg-iana-ports-10)
--------------------------------------
Title               : Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
Publication Date    : August 2011
Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire
Category            : BEST CURRENT PRACTICE
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG


From nobody Tue Apr 18 23:55:52 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C10131529 for ; Tue, 18 Apr 2017 23:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kwV6NEjcTkt6 for ; Tue, 18 Apr 2017 23:55:49 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CBF12EC67 for ; Tue, 18 Apr 2017 23:55:48 -0700 (PDT)
Received: (qmail 5774 invoked from network); 19 Apr 2017 08:49:05 +0200
Received: from p5dec224d.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.77) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated);  19 Apr 2017 08:49:05 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: 
Date: Wed, 19 Apr 2017 08:49:04 +0200
Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , Bob Hinden , IESG , 6man Chairs <6man-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <754272E0-1DF9-4821-9111-A3AC7F691B7A@kuehlewind.net>
References:   <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com>  <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> 
To: "C. M. Heard" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 06:55:51 -0000

Yes and no. Of course if ECN is not supported, packet should not be ECN =
marked. However, the IP layer might actually not know if is supported or =
not (e.g. a UDP based protocol that is implemented in user-spaces that =
uses ECN) and therefore my thinking is that it should reassemble the ECN =
field correctly if ECN was set not matter what.=20

Mirja


> Am 19.04.2017 um 05:04 schrieb C. M. Heard :
>=20
> On Tue, Apr 18, 2017 at 12:42 PM, Mirja Kuehlewind (IETF) wrote:
>> sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN =
support,
>> the reassembled packet should also do that correctly, no matter if
>> the nodes support ECN or not. Handling these fields correctly with
>> fragmentation does not mean that the nodes supports ECN. So this is
>> not optional=E2=80=A6
>=20
> This seems confused (or else I am confused). We are discussing issues
> related to reassembly of fragmented packets, and that is a process =
that
> takes place in end systems only, not in forwarding nodes.
>=20
> It is true that if an end system (aka host) supports ECN per RFC 3168,
> then received packets that it reassembles must have the CE bit pattern
> set if any fragment has the CE bit pattern set, provided that all
> fragments contain either CE or ECT(0)/ECT(1). The text that we are
> working on is intended to say that -- indirectly, by referring to the
> Section 5.3 of RFC 3168.
>=20
> But, unless ECN is mandatory-to-implement for all IPv6 nodes, end
> systems are not obliged to support it -- and I see no such mandate
> in the IPv6 node requirements document. In that case ECN indications
> will simply be ignored. No purpose is served by levying a requirement
> on the IPv6 module to preserve an indication that will not be used.
>=20
> Mike Heard
>=20


From nobody Wed Apr 19 05:54:55 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F75F127201 for ; Wed, 19 Apr 2017 05:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3LSgIi2ZGiKB for ; Wed, 19 Apr 2017 05:54:52 -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 F387112704B for ; Wed, 19 Apr 2017 05:54:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID: Subject:From:Cc:To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LzOBF4r7jSmZcQ4xlm5Uf9XmWLuV5SXL8ZRxX0U8FPw=; b=djBfFWnLcjhrEGzjV1kvfOL90u Zh/1uNya8e7bXyjFd7E+ATtZTy1839fsTwLC9lfSi6NQGfgs+L218k3DMa2uvd0L6hkIsGT11xsij OxuYBTeukjcJ2N7p5HRTXIj+MyKXSyQVNRVKx3DwErtZvf+kJR0ywKOE7NgRd8dyIvDdRxi+GtDXT G7p4kLw4MnNx5t6gf4OSNop02raKKXSprzVaeaGvmcoVl9Tpaz6RuzZISQDLk+hMrY0enrkvS0PGM YwXr2Fe+nNsjbx3KzgPkiKBsTl4NbFxGhGJgOLuhcE7Bul/1FANYBT0g0YMWbMvxo4x67dVBkgHsg J2Fe5GoA==;
Received: from 188.6.208.46.dyn.plus.net ([46.208.6.188]:51544 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 1d0p8D-0006Go-Tx; Wed, 19 Apr 2017 13:54:50 +0100
To: "Black, David" 
Cc: tsvwg IETF list 
From: Bob Briscoe 
Message-ID: <10704375-9ae0-d34a-c773-3fa61188b411@bobbriscoe.net>
Date: Wed, 19 Apr 2017 13:54:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------E2C9F44A93CB23F535BC2EF9"
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: [tsvwg] One more edit for draft-ietf-tsvwg-ecn-experimentation-01
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 12:54:54 -0000

This is a multi-part message in MIME format.
--------------E2C9F44A93CB23F535BC2EF9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

David,

At the end of Section 4.3 
, 
there ought to be a reason for why there's a SHOULD NOT rather than a 
MUST NOT:

CURRENT:
    therefore RFC 3168 is updated by adding the following text to the end
    of Section 6.1.1.1 on Middlebox Issues:

       Unless otherwise specified by an Experimental RFC, middleboxes
       SHOULD NOT discard TCP control packets and retransmitted TCP
       packets solely because the ECN field in the IP header does not
       contain Not-ECT.
ADD:
    The previous sentence says "SHOULD NOT" rather than "MUST NOT"
    because one potential exception is envisaged.  A security function
    that has detected an ongoing attack MAY drop more ECT marked SYNs
    than not-ECT marked SYNs.  Such a policy MUST NOT be applied
    routinely.  It can only be applied if an attack is detected, and
    preferably only if it is determined that the ECT capability is
    intensifying the attack.
REASONING:
The "SHOULD NOT" is not meant to be an open invitation for middleboxes 
to do what they choose. It would have been a "MUST NOT" were it not for 
the possibility of middleboxes having to deal with ECN-specific attacks.


We had these two paras in draft-bagnulo-tcmp-generalized-ecn, but now 
that you have the first para in ecn-experimentation, we have taken them 
out. However, we're hoping you'll include something like the 2nd para too.

Regards


Bob


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


--------------E2C9F44A93CB23F535BC2EF9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    David,

    

    At the end of Section
      4.3, there ought to be a reason for why there's a SHOULD NOT
    rather than a MUST NOT:

    

    CURRENT:

       therefore RFC 3168 is updated by adding the following text to
      the end

       of Section 6.1.1.1 on Middlebox Issues:

    

          Unless otherwise specified by an Experimental RFC,
      middleboxes

          SHOULD NOT discard TCP control packets and
      retransmitted TCP

          packets solely because the ECN field in the IP header
      does not

          contain Not-ECT.

    ADD:

       The previous sentence says "SHOULD NOT" rather than "MUST
      NOT"

       because one potential exception is envisaged.  A
      security function

       that has detected an ongoing attack MAY drop more ECT
      marked SYNs

       than not-ECT marked SYNs.  Such a policy MUST NOT be
      applied

       routinely.  It can only be applied if an attack is
      detected, and

       preferably only if it is determined that the ECT
      capability is

       intensifying the attack.

    REASONING:

    The "SHOULD NOT" is not meant to be an open invitation for
    middleboxes to do what they choose. It would have been a "MUST NOT"
    were it not for the possibility of middleboxes having to deal with
    ECN-specific attacks.

    

    

    We had these two paras in draft-bagnulo-tcmp-generalized-ecn, but
    now that you have the first para in ecn-experimentation, we have
    taken them out. However, we're hoping you'll include something like
    the 2nd para too.

    

    Regards

    

    

    Bob

    

    

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

  


--------------E2C9F44A93CB23F535BC2EF9--


From nobody Wed Apr 19 08:13:23 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BF31201FA for ; Wed, 19 Apr 2017 08:13:22 -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 7tZPdEkfyoqO for ; Wed, 19 Apr 2017 08:13:20 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 BED9E129513 for ; Wed, 19 Apr 2017 08:13:19 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.37,221,1488841200";  d="scan'208,217";a="220860079"
Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 17:13:18 +0200
From: Vincent Roca 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D8C7DA4F-435A-411B-8E1E-6B9A7F8AAB74"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <3EC511DE-0237-444A-807D-F9AED59E2C5C@inria.fr>
Date: Wed, 19 Apr 2017 17:13:17 +0200
To: tsvwg@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [tsvwg] Feedbacks on FECFRAME-extended and RLC I-Ds
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 15:13:22 -0000

--Apple-Mail=_D8C7DA4F-435A-411B-8E1E-6B9A7F8AAB74
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello everybody,

I=E2=80=99ve received useful comments (privately) from Marie-Jos=C3=A9 =
M. for both I-Ds (FECFRAME-extended and
RLC). Here are the conclusions we=E2=80=99ve reached that could be =
implemented in next version.


Concerning the FECFRAME-extended I-D:

1- there=E2=80=99s a lot of historical notions both WRT terminology and =
architecture, so understanding current I-D
	without going back to RFC 6363 (i.e., FECFRAME specifications) =
is impossible. This is a side effect
	of providing only the delta WRT RFC 6363, i.e. the 10% specific =
to sliding window codes.
	Several misunderstandings derived from this lack of introductory =
material.

    Proposal: in Section 1, add an introduction to FECFRAME. Current =
introduction only motivates this
		extension which does not help understanding the =
background.

2- references to =C2=AB convolutional codes =C2=BB can be confusing, =
this term being too close to physical layer codes.

    Proposal: prefer =C2=AB sliding window codes =C2=BB (also in the =
title).


Concerning the RLC I-D:

1- the RLC name is confusing (too close to Network Coding).

    Proposal: "Sliding Linear Codes" (SLIC) seems more appropriate =
(thanks to MJM who suggested it).

2- references to =C2=AB convolutional codes =C2=BB can be confusing =
(same as above).

    Proposal: remove most of them.

3- question on the elastic or fixed size nature of the coding window. =
Not clear.

    Proposal: update text to clarify that this is left to the =
application/protocol relying on this FEC Scheme.
		The SLIC FEC Scheme addresses both situations. Also =
clarify that real-time aspects are the
		responsibility of the application, not the FEC Scheme.


Beyond these two TSVWG I-Ds, related works will be carried out in the =
context of NWCRG on a generic
protocol for robust and low latency tunnelling. Many open research =
points are raised, hence the =C2=AB RG =C2=BB
nature.

Cheers,

  Vincent


--Apple-Mail=_D8C7DA4F-435A-411B-8E1E-6B9A7F8AAB74
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hello everybody,

I=E2=80=99ve received =
useful comments (privately) from Marie-Jos=C3=A9 M. for both I-Ds =
(FECFRAME-extended and
RLC). Here are the =
conclusions we=E2=80=99ve reached that could be implemented in next =
version.


Concerning the FECFRAME-extended I-D:

1- there=E2=80=99s a lot =
of historical notions both WRT terminology and architecture, so =
understanding current I-D
	without =
going back to RFC 6363 (i.e., FECFRAME specifications) is impossible. =
This is a side effect
	of providing only the delta WRT =
RFC 6363, i.e. the 10% specific to sliding window codes.
	=
Several misunderstandings derived from this lack of introductory =
material.

 =
   Proposal: in Section 1, add an introduction to FECFRAME. Current =
introduction only motivates this
		=
extension which does not help understanding the =
background.

2- references to =C2=AB convolutional codes =C2=BB can =
be confusing, this term being too close to physical layer =
codes.

  =
  Proposal: prefer =C2=AB sliding window codes =C2=BB =
(also in the title).


Concerning =
the RLC I-D:

1- the RLC name is confusing (too close to Network =
Coding).

    Proposal: "Sliding Linear Codes" (SLIC) seems =
more appropriate (thanks to MJM who suggested it).

2- references to =
=C2=AB convolutional codes =C2=BB can be confusing (same as =
above).

  =
  Proposal: remove most of them.

3- question on the elastic or fixed =
size nature of the coding window. Not clear.

    Proposal: update text to =
clarify that this is left to the application/protocol relying =
on this FEC Scheme.
		The SLIC FEC Scheme =
addresses both situations. Also clarify that real-time aspects are =
the
		responsibility of the =
application, not the FEC Scheme.


Beyond these two TSVWG I-Ds, related works will be carried =
out in the context of NWCRG on a generic
protocol =
for robust and low latency tunnelling. Many open research points are =
raised, hence the =C2=AB RG =C2=BB
nature.

Cheers,

  Vincent

=

--Apple-Mail=_D8C7DA4F-435A-411B-8E1E-6B9A7F8AAB74--


From nobody Wed Apr 19 09:39:16 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610CA129B30; Wed, 19 Apr 2017 09:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 bwAu8lBY1_Hr; Wed, 19 Apr 2017 09:38:53 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1FB129B2F; Wed, 19 Apr 2017 09:38:53 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 46D5889BA3; Wed, 19 Apr 2017 12:38:52 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; s=sasl; bh=YzmTiRoDSL1wIFJ4LedBV7oiA pU=; b=yWl3Z+DXFym9ns3hMPQfEAHEIAYD5bwvFlYs/uPB9Vj55/7g40+QdKKae PK75rmDN2IO55bga76O2FoeIokDZcjWd9c4OrM2zm++4urHoeT93SzPe/d6OOdUC uUjvXYlLvtkyVAKjbzKWk2oeA9TKQkRtGJh5+VmrDybIIJlZAg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; q=dns; s=sasl; b=P39bvhx4N6gsREnFPHR 3FHLRhnqdPKPSjBf9dzjjVtRnZwvBhtqEnwnYyype/i5nVp4NbIO/Ub4Y3OAcZb+ aeA4GuCkfHf/ElslIYSsQLT7uCHggjS9PDoIfVdTeYHjuZsGJXDrE4FMLmh+CiAa WVAF+sGHqqU9DgcHmcBqKNEw=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3CC1B89BA2; Wed, 19 Apr 2017 12:38:52 -0400 (EDT)
Received: from mail-qk0-f176.google.com (unknown [209.85.220.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id B61DB89B9F; Wed, 19 Apr 2017 12:38:51 -0400 (EDT)
Received: by mail-qk0-f176.google.com with SMTP id p68so24920922qke.1; Wed, 19 Apr 2017 09:38:51 -0700 (PDT)
X-Gm-Message-State: AN3rC/5Q6b8doNt3BiPbKkY1Sd0+qXXKjYIOY2M1w4JS6gtY7tirGW0E js9BzC0a8MDkkFqTuep7xm/SRAXIgw==
X-Received: by 10.55.78.201 with SMTP id c192mr3642885qkb.81.1492619931222; Wed, 19 Apr 2017 09:38:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.40.180 with HTTP; Wed, 19 Apr 2017 09:38:30 -0700 (PDT)
From: "C. M. Heard" 
Date: Wed, 19 Apr 2017 09:38:30 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "Mirja Kuehlewind (IETF)" 
Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>,  tsvwg , Bob Hinden , IESG , 6man Chairs <6man-chairs@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Pobox-Relay-ID: ABAD80CC-251E-11E7-9406-E680B56B9B0B-06080547!pb-smtp1.pobox.com
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 16:38:55 -0000

On Tue, Apr 18, 2017 at 11:49 PM, Mirja Kuehlewind (IETF) wrote:
> Yes and no. Of course if ECN is not supported, packet should not be
> ECN marked. However, the IP layer might actually not know if is
> supported or not (e.g. a UDP based protocol that is implemented in
> user-spaces that uses ECN) and therefore my thinking is that it should
> reassemble the ECN field correctly if ECN was set not matter what.

A packet will not be ECN marked (i.e., will contain the not-ECT
codepoint) if the **source flow** does not support ECN. That has
nothing to do with whether the **destination node** supports ECN.

If any of the transport protocols in the destination node are to
support ECN in conformance with RFC 3168 -- including, of course,
UDP-based protocols implemented in user space -- then of course the
IPv6 module in that node must implement fragment reassembly in
accordance with RFC 3168. No argument there. In that case the node
would "support Explicit Congestion Notification [RFC3168]" and,
under the text proposed by Bob Hinden (as modified by David Black),
would "use information in the Traffic Class field from all fragment
packets to reconstruct the Traffic Class field in the reassembled
packet" as specified in RFC 3168 Section 5.3.

You seem to want the requirements of RFC 3168 Section 5.3 to apply
to **all** IPv6 stacks, even those in nodes that have no ECN-capable
transport modules. That might be a good thing for implementors to do
in order to to ensure future extensibility, but those requirements are
not part of RFC 2460 and so are out of scope for 2460bis, if it is to
be eligible for Internet Standard status. In order to insist that those
requirements go into 2460bis you would need to prove that there is an
essential technical omission without them, and I don't think you can
make that case. If you are able to make that case, the implication
would be that 2460 does not meet the requirements for promotion to IS.

Mike Heard

>> Am 19.04.2017 um 05:04 schrieb C. M. Heard :
>>
>> On Tue, Apr 18, 2017 at 12:42 PM, Mirja Kuehlewind (IETF) wrote:
>>> sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN s=
upport,
>>> the reassembled packet should also do that correctly, no matter if
>>> the nodes support ECN or not. Handling these fields correctly with
>>> fragmentation does not mean that the nodes supports ECN. So this is
>>> not optional=E2=80=A6
>>
>> This seems confused (or else I am confused). We are discussing issues
>> related to reassembly of fragmented packets, and that is a process that
>> takes place in end systems only, not in forwarding nodes.
>>
>> It is true that if an end system (aka host) supports ECN per RFC 3168,
>> then received packets that it reassembles must have the CE bit pattern
>> set if any fragment has the CE bit pattern set, provided that all
>> fragments contain either CE or ECT(0)/ECT(1). The text that we are
>> working on is intended to say that -- indirectly, by referring to the
>> Section 5.3 of RFC 3168.
>>
>> But, unless ECN is mandatory-to-implement for all IPv6 nodes, end
>> systems are not obliged to support it -- and I see no such mandate
>> in the IPv6 node requirements document. In that case ECN indications
>> will simply be ignored. No purpose is served by levying a requirement
>> on the IPv6 module to preserve an indication that will not be used.
>>
>> Mike Heard
>>
>


From nobody Wed Apr 19 10:25:14 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB3F129B5A for ; Wed, 19 Apr 2017 10:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 xBPNcWZnqNU6 for ; Wed, 19 Apr 2017 10:25:10 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6372C129B52 for ; Wed, 19 Apr 2017 10:25:09 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=JOZnOa24E3HLuq1x0ZenSxbI/Ls5NH2D/6VVxu2tMnD9BnfoaT7L17Z+n5cxCWGri0naHz4Dwh9OWhY7t+X7u1iMA8Oq6HCgmHFImeIELIg9/oyW0kSkai+7doBYloc4kPeF4WvGRGi5OZlULxQJwnnzI1+JVmPBxfjsmqHHZOY=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 20105 invoked from network); 19 Apr 2017 19:25:07 +0200
Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 19 Apr 2017 19:25:07 +0200
To: "C. M. Heard" 
References: 
Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , Bob Hinden , IESG , 6man Chairs <6man-chairs@ietf.org>
From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= 
Message-ID: 
Date: Wed, 19 Apr 2017 19:25:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-PPP-Message-ID: <20170419172507.20094.45662@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 17:25:12 -0000

Hi Mike,

I think we use the word 'support' differently and that's were the confusion 
comes from. However, see below.


On 19.04.2017 18:38, C. M. Heard wrote:
 > On Tue, Apr 18, 2017 at 11:49 PM, Mirja Kuehlewind (IETF) wrote:
 >> Yes and no. Of course if ECN is not supported, packet should not be
 >> ECN marked. However, the IP layer might actually not know if is
 >> supported or not (e.g. a UDP based protocol that is implemented in
 >> user-spaces that uses ECN) and therefore my thinking is that it should
 >> reassemble the ECN field correctly if ECN was set not matter what.
 >
 > A packet will not be ECN marked (i.e., will contain the not-ECT
 > codepoint) if the **source flow** does not support ECN. That has
 > nothing to do with whether the **destination node** supports ECN.
 >
 > If any of the transport protocols in the destination node are to
 > support ECN in conformance with RFC 3168 -- including, of course,
 > UDP-based protocols implemented in user space -- then of course the
 > IPv6 module in that node must implement fragment reassembly in
 > accordance with RFC 3168. No argument there. In that case the node
 > would "support Explicit Congestion Notification [RFC3168]" and,
 > under the text proposed by Bob Hinden (as modified by David Black),
 > would "use information in the Traffic Class field from all fragment
 > packets to reconstruct the Traffic Class field in the reassembled
 > packet" as specified in RFC 3168 Section 5.3.
 >
 > You seem to want the requirements of RFC 3168 Section 5.3 to apply
 > to **all** IPv6 stacks, even those in nodes that have no ECN-capable
 > transport modules.

Actually yes, because the IPv6 stack might not know anything about 
ECN-capable transport modules. So the only thing you can do is require it for 
all. But please see further below.


That might be a good thing for implementors to do
 > in order to to ensure future extensibility,

Yes :-)

but those requirements are
 > not part of RFC 2460 and so are out of scope for 2460bis, if it is to
 > be eligible for Internet Standard status.

So, yes this is not part of RFC2460 but as you noted correctly RFC3168 should 
have updated RFC2460 and as such this could be incorporated into 2460bis (as 
done with other updates as well). But please see further below.


  In order to insist that those
 > requirements go into 2460bis you would need to prove that there is an
 > essential technical omission without them, and I don't think you can
 > make that case.

Not sure. Losing a congestion notification is a real problem. RFC3168 is 
standards track as well, and as you noted, probably should have updated 
RFC2460. But please see further below.

If you are able to make that case, the implication
 > would be that 2460 does not meet the requirements for promotion to IS.

I guess what we really need to check would be if most IPV6 stacks have 
implemented this behavior. If so it should be fine to add this to 2460bis, if 
not maybe not. But I just don't know...

And now the big BUT...

This is the text I proposed:

"The number and content of the headers preceding the Fragment
header of different fragments of the same original packet may
differ.  Whatever headers are present, preceding the Fragment
header in each fragment packet, are processed when the packets
arrive, prior to queueing the fragments for reassembly.  Only
those headers in the Offset zero fragment packet are retained in
the reassembled packet; however, the Traffic Class field from
any or all fragments may differ. Handling of Explicit
Congestion Notification [RFC3168] is described in Section 5.3 of
RFC 3168, ensuring that reassembly does not lose indications
of congestion."

This text does not make any normative statement on the question if the 
behavior specified in RFC3168 should be implemented or not. It only says 
please look at RFC3168 and make an informed decision if you want to confirm 
to the behavior that is specified in RFC3168 in addition to implementing the 
spec in this document. However, yes, this statement is true for all IPv6 
implementation. I don't see a problem here...

Mirja


 >
 > Mike Heard
 >
 >>> Am 19.04.2017 um 05:04 schrieb C. M. Heard :
 >>>
 >>> On Tue, Apr 18, 2017 at 12:42 PM, Mirja Kuehlewind (IETF) wrote:
 >>>> sorry but this is wrong… if the actually sender indicates ECN support,
 >>>> the reassembled packet should also do that correctly, no matter if
 >>>> the nodes support ECN or not. Handling these fields correctly with
 >>>> fragmentation does not mean that the nodes supports ECN. So this is
 >>>> not optional…
 >>>
 >>> This seems confused (or else I am confused). We are discussing issues
 >>> related to reassembly of fragmented packets, and that is a process that
 >>> takes place in end systems only, not in forwarding nodes.
 >>>
 >>> It is true that if an end system (aka host) supports ECN per RFC 3168,
 >>> then received packets that it reassembles must have the CE bit pattern
 >>> set if any fragment has the CE bit pattern set, provided that all
 >>> fragments contain either CE or ECT(0)/ECT(1). The text that we are
 >>> working on is intended to say that -- indirectly, by referring to the
 >>> Section 5.3 of RFC 3168.
 >>>
 >>> But, unless ECN is mandatory-to-implement for all IPv6 nodes, end
 >>> systems are not obliged to support it -- and I see no such mandate
 >>> in the IPv6 node requirements document. In that case ECN indications
 >>> will simply be ignored. No purpose is served by levying a requirement
 >>> on the IPv6 module to preserve an indication that will not be used.
 >>>
 >>> Mike Heard
 >>>
 >>
 >


From nobody Wed Apr 19 10:55:08 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850A3129B8D; Wed, 19 Apr 2017 10:55:06 -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 (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 3Y05YonJpEJc; Wed, 19 Apr 2017 10:55:05 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFF6129B89; Wed, 19 Apr 2017 10:55:05 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 2C6918A886; Wed, 19 Apr 2017 13:55:04 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sasl; bh=6JU2f/Gs0td8 gkKvMOQ8qw6sOsk=; b=TtSmwyVzEZI18TYLuVg4I8Rj3xo7NWgrzcKJVqO79+NY C2MDZ1qpDIDovmK0P2qMaQFxupaSViyYWOYRZAihl1AzECN7pTcYZqGMZCl2BhnY zrp9IvE8+xFq58sWbz9CJRZ8jfuuvRAl8891KmftDj4Iy0aON04mvCnHUBid4k4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; q=dns; s=sasl; b=etujrn GpsRg7g4QpTUEMrxzsgO9GxKLMI9L2cF3tAELUQXnYKTqSN1JjdlASgkf7DGkr9m jfm0qnteGmzQ4x2z70fB+CwNS74MHjHFP0/U2CrrTi8oq4Lr4YercOBStri3Zi6T YqxAcOhfShJqOJYWlEfAw0VcN3mvEoEBWfuws=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 210A88A885; Wed, 19 Apr 2017 13:55:04 -0400 (EDT)
Received: from mail-qt0-f178.google.com (unknown [209.85.216.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 3A0B08A87C; Wed, 19 Apr 2017 13:55:03 -0400 (EDT)
Received: by mail-qt0-f178.google.com with SMTP id m36so26193368qtb.0; Wed, 19 Apr 2017 10:55:03 -0700 (PDT)
X-Gm-Message-State: AN3rC/6b4kzOrKug4b9psypFlMcs6k2ZD52t4o5Gl/0kyAsSnJySayMh KE3E63AU7gvATt2yTkbbzOYGY+9bQg==
X-Received: by 10.237.37.142 with SMTP id x14mr3792360qtc.160.1492624502739; Wed, 19 Apr 2017 10:55:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.40.180 with HTTP; Wed, 19 Apr 2017 10:54:42 -0700 (PDT)
In-Reply-To: 
References:  
From: "C. M. Heard" 
Date: Wed, 19 Apr 2017 10:54:42 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= 
Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>,  tsvwg , Bob Hinden , IESG , 6man Chairs <6man-chairs@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Pobox-Relay-ID: 50801A38-2529-11E7-9E61-E680B56B9B0B-06080547!pb-smtp1.pobox.com
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 17:55:07 -0000

On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote:
> This text does not make any normative statement on the question if the
> behavior specified in RFC3168 should be implemented or not. It only says
> please look at RFC3168 and make an informed decision if you want to confi=
rm
> to the behavior that is specified in RFC3168 in addition to implementing =
the
> spec in this document. However, yes, this statement is true for all IPv6
> implementation. I don't see a problem here...

Nor do I. As it happens I prefer the text proposed by Bob Hinden (with
David Black's modification) but I believe that the effect is essentially th=
e
same as the text you proposed. So it seems that the discussion is boiling
down to editorial issues, and I am happy to leave that between you,
the shepherd, and the document editor.

Thanks

Mike Heard


From nobody Wed Apr 19 13:09:51 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446C3126DCA for ; Wed, 19 Apr 2017 13:09:49 -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 6dbQIMt0CAxz for ; Wed, 19 Apr 2017 13:09:47 -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 AAA671294EE for ; Wed, 19 Apr 2017 13:09:47 -0700 (PDT)
Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3JK8fjT014262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Apr 2017 13:08:41 -0700 (PDT)
To: RFC Errata System , michelle.cotton@icann.org,  lars.eggert@nokia.com, magnus.westerlund@ericsson.com, cheshire@apple.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, david.black@emc.com, gorry@erg.abdn.ac.uk, wes@mti-systems.com
References: <20170419064022.20762B80E78@rfc-editor.org>
Cc: mnot@mnot.net, tsvwg@ietf.org
From: Joe Touch 
Message-ID: 
Date: Wed, 19 Apr 2017 13:08:40 -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: <20170419064022.20762B80E78@rfc-editor.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: v3JK8fjT014262
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Subject: Re: [tsvwg] [Technical Errata Reported] RFC6335 (4999)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 20:09:49 -0000

Hi, all,

While I agree that we didn't explicitly cover this case - or the case
where a company serves as the assignee and has gone out of business -
the doc IMO already covers what would happen here. IANA steps in to
represent the past owner and ensure proper transition, if appropriate,
as per rervocation in Sec 8.4.

I doubt we need to hold this for update, for that reason. I.e., at best,
we would only confirm that the assignee reverts to IANA in such cases,
as shepherd.

Joe


On 4/18/2017 11:40 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC6335,
> "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6335&eid=4999
>
> --------------------------------------
> Type: Technical
> Reported by: Mark Nottingham 
>
> Section: GLOBAL
>
> Original Text
> -------------
>
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> HOLD FOR UPDATE
>
> Many port number assignments are to individuals, but the document does not
> contemplate how they should be handled when the assignee is dead or
> otherwise can't be contacted. 
>
> The most obvious procedure to follow is a transfer (8.5), but that requires 
> de-assignment (8.2), and that doesn't cover the case above.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
>
> --------------------------------------
> RFC6335 (draft-ietf-tsvwg-iana-ports-10)
> --------------------------------------
> Title               : Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
> Publication Date    : August 2011
> Author(s)           : M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire
> Category            : BEST CURRENT PRACTICE
> Source              : Transport Area Working Group
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG


From nobody Wed Apr 19 14:16:49 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA46124B0A; Wed, 19 Apr 2017 14:16:47 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dOaJGEWoSOo4; Wed, 19 Apr 2017 14:16:45 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4297129ABE; Wed, 19 Apr 2017 14:16:44 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id w64so89933377wma.0; Wed, 19 Apr 2017 14:16:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bYKy9N0z3bcxHbbp30OXUT067+znJVFZzAf/HL/+DLo=; b=oLUBhg8RX+HoD/I3igPYRfG57Ne1eb00/aHAVuGl5/TD/M/LQrmj3V1kQIk1HHzZ7m QKEw0/odwxSQPJWAqGAMQfkHSSBlmDdEcq40Ia7j/tBKrNAXWqmQ03RVBPS4Z2P0Jqjx fNgjlPe84yswv7MYxN/MiuKoQL16ATxGZnpS4hnk0oGgQQfRgOdWbzsI3M9AFOH9Da08 BqrRKanX7Yjfg/qDDYm6bs8/WVCWyEBKd3eGDLZSIfFEbW+AxuxTswwzA4NgBqXtx0yC bskULb6TMJhnkOLIVrKSvi8BK9d5tOHR0w1spsb77TNf+OqXHokLlyP3pfOX/QRPwHrR Rpvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bYKy9N0z3bcxHbbp30OXUT067+znJVFZzAf/HL/+DLo=; b=q0EGrLPZbSY66GNLEIao+skCMGKUl+zy32U2pNUHAlc06eQw8CDwlVALtcXubprKkI XNx8nNlEC7e3cPdOjasMJhiqCIjlRo2hxsox0BIVQVQH/zhhDRZDvdFnWbTQujoYl4JB y89GFwBUjIZXrXYl8sONGpEA3z901yk4BEmDZDJeWlDDxzXKYFQeCwQlNPL+oAZnRuQW 5KMV+fYAM1Kdpem70JAZwKdUmzFAxCio3ihmPhMcPC8RY3Eu0GlJ/QOln/iAa88UaRSL 5/XWq9691y6LpaoVcCVm6k7lhzkLoM5WwnMn1gDhfNJxWpPeguyXOJnjCq6rKk/Kgo7u 8b9w==
X-Gm-Message-State: AN3rC/5C7UTIdYfzLXkv8Hg14rQQBpptvA4x99/qaNSTjPUf6C0hpydv 1FwkfsvYrSls13GM9MY=
X-Received: by 10.28.135.130 with SMTP id j124mr3759wmd.125.1492636603400; Wed, 19 Apr 2017 14:16:43 -0700 (PDT)
Received: from [192.168.160.247] ([209.97.127.10]) by smtp.gmail.com with ESMTPSA id w76sm4816708wrb.49.2017.04.19.14.16.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 14:16:41 -0700 (PDT)
From: Bob Hinden 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_D93F7A0A-3151-4DE2-A2A1-71FEFCE16F93"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 19 Apr 2017 14:16:34 -0700
In-Reply-To: 
Cc: Bob Hinden , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , IESG , 6man Chairs <6man-chairs@ietf.org>
To: "C. M. Heard" 
References:   
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 21:16:47 -0000

--Apple-Mail=_D93F7A0A-3151-4DE2-A2A1-71FEFCE16F93
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Mike,

> On Apr 19, 2017, at 10:54 AM, C. M. Heard  wrote:
>=20
> On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote:
>> This text does not make any normative statement on the question if =
the
>> behavior specified in RFC3168 should be implemented or not. It only =
says
>> please look at RFC3168 and make an informed decision if you want to =
confirm
>> to the behavior that is specified in RFC3168 in addition to =
implementing the
>> spec in this document. However, yes, this statement is true for all =
IPv6
>> implementation. I don't see a problem here...
>=20
> Nor do I. As it happens I prefer the text proposed by Bob Hinden (with
> David Black's modification) but I believe that the effect is =
essentially the
> same as the text you proposed. So it seems that the discussion is =
boiling
> down to editorial issues, and I am happy to leave that between you,
> the shepherd, and the document editor.

The current text I have is:

         Nodes that support Explicit Congestion Notification [RFC3168]
         use information in the Traffic Class field from all fragment
         packets to reconstruct the Traffic Class field in the
         reassembled packet.  See Section 5.3 of RFC3168 for more
         information.

I continue to think this is clear and is unlikely to create any =
confusion if ECN is a new requirement in IPv6 implementations.  I think =
it=E2=80=99s the appropriate change for moving to Internet Standard.

It does resolve the issue that Mirja=E2=80=99s raised about there not =
being any mention of ECN in the reassembly text.

Thanks,
Bob





--Apple-Mail=_D93F7A0A-3151-4DE2-A2A1-71FEFCE16F93
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJY99OzAAoJEK7rdBF357uoiloH/jWKjkmqJCJhM+Th3zrMbA7W
VvBr2FANhgQR1CED/Yv2TwlpYRdRGsJKwoMIIbJXQ2GJevoCfOx9ANTT8sfdD7Ty
6J25DZp1dx/Nqy593ENyl9Sz+o1yIUtcxfkgYz14fIjrT+HcFMUxXUMGqG0M3efB
Q8Iu8W1C2Zp/N7pXmuAbYvvKUAfIokC5ZE22RPFofdRJ+HoeXYPlTEWfRleS3iMp
6zoOlPjvokf6ZuNNbMNh2GyB9p1j4GN4Zr7FziX1wSWJ32SwjOnPcyMEoHaCf+Iy
unJP1mcTtdfND1F5o6s1CsMluqsLiYvQemh0ExTKv9QSpvpQM5a4MiCvNRbVL8I=
=Y8s4
-----END PGP SIGNATURE-----

--Apple-Mail=_D93F7A0A-3151-4DE2-A2A1-71FEFCE16F93--


From nobody Wed Apr 19 14:48:09 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAF51243FE; Wed, 19 Apr 2017 14:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_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=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 sQT_IyZK_RnZ; Wed, 19 Apr 2017 14:47:52 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6391D120046; Wed, 19 Apr 2017 14:47:52 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id f10so31421992uaa.2; Wed, 19 Apr 2017 14:47:52 -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=bHJ4EQSJxY3xNkJCPdttesOF4l7vwsYbjac0cVrl4Tc=; b=qp87PV2NbAjGp3X+S4P1ghI+4xCvsr/cIgmJNE4OU2alXu+MFBZ0kqpbJ2kVP/8pdO blg/XSdXKbEpCcfaFJ216aGRe3x5D1DxHaubdj6R2IHC7/Gu6JVvWa8/Z+X9tjxTmVlw XXqZWQ8yEwfKoRz30mkblz4gn6upbk++sarCjTMlyINs1prx1PzNTa9iIgrDMBS5DhFf jKeGElhgPABLtBHDOhy/8kS0N/ZP0+ZqpVYbSnQxWNKxIKmqnlOezh9KoanNykcsX+iy n/GMEwkyUVZs4q5JMXOAfNRW4d+ifpoyRPmhjIAUOHfRwRZbweX77y91Kd4t9vzn4fg3 OJNQ==
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=bHJ4EQSJxY3xNkJCPdttesOF4l7vwsYbjac0cVrl4Tc=; b=lsnZFlE1pyEyMIsiYHQrnNyqHhB9MF9pypv23H5ccTJfoIgiNAux06S0yUiDUbGg1e Gd+UUgP/JVDhZIQFCDv3+4s1V+emT/bXI+VDcwMHbFZv6L+tLc+uTeKRmAG/XJ2EmNia Q9K8ExMgaNYLDcg2fsSdV0aNYI4RPZGjh1NXOffo7UsaCuJpOExD+CYR6gMv84aciEGU eBtG72zukDU/ZlXVpdX37waS6M5jiG1z1eAE+4ECHw8mvG+CG7gXNCwSqGL5FKzkAtZ4 C7dh3F0lc32nAvQSOMBExB9aGTTZhDjZEYEzT/QJVGnkkyZlUSo/qP76MKWrqML1NPch QvoQ==
X-Gm-Message-State: AN3rC/4nPfZ06FEnDJRVKVyVPp6ggRmvFhJtx+0KrSKko7nEGGWIrtxZ abe96ircln3LxKiPzgS16nZ/vB3o1w==
X-Received: by 10.176.91.94 with SMTP id v30mr1933643uae.37.1492638471329; Wed, 19 Apr 2017 14:47:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.123.214 with HTTP; Wed, 19 Apr 2017 14:47:50 -0700 (PDT)
Received: by 10.103.123.214 with HTTP; Wed, 19 Apr 2017 14:47:50 -0700 (PDT)
In-Reply-To: 
References:      
From: Suresh Krishnan 
Date: Wed, 19 Apr 2017 17:47:50 -0400
Message-ID: 
To: Bob Hinden 
Cc: "Mirja Kuehlewind (IETF)" , 6man-chairs@ietf.org, IESG , 6MAN <6man@ietf.org>,  "draft-ietf-6man-rfc2460bis@ietf.org" , tsvwg , "C. M. Heard" 
Content-Type: multipart/alternative; boundary=f403045f907edc9c2d054d8bf935
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 21:47:54 -0000

--f403045f907edc9c2d054d8bf935
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Bob,

On Apr 19, 2017 5:16 PM, "Bob Hinden"  wrote:

Mike,

> On Apr 19, 2017, at 10:54 AM, C. M. Heard  wrote:
>
> On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote:
>> This text does not make any normative statement on the question if the
>> behavior specified in RFC3168 should be implemented or not. It only says
>> please look at RFC3168 and make an informed decision if you want to
confirm
>> to the behavior that is specified in RFC3168 in addition to implementing
the
>> spec in this document. However, yes, this statement is true for all IPv6
>> implementation. I don't see a problem here...
>
> Nor do I. As it happens I prefer the text proposed by Bob Hinden (with
> David Black's modification) but I believe that the effect is essentially
the
> same as the text you proposed. So it seems that the discussion is boiling
> down to editorial issues, and I am happy to leave that between you,
> the shepherd, and the document editor.

The current text I have is:

         Nodes that support Explicit Congestion Notification [RFC3168]
         use information in the Traffic Class field from all fragment
         packets to reconstruct the Traffic Class field in the
         reassembled packet.  See Section 5.3 of RFC3168 for more
         information.



This looks good to me as well. My only concern with the previous version
was that it sounded normative.

Regards
Suresh

--f403045f907edc9c2d054d8bf935
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Bob,=C2=A0

On Apr 19, 2017 5:16 PM, "Bob Hinden" <=
bob.hinden@gmail.com> wrote:=

Mike,




> On Apr 19, 2017, at 10:54 AM, C. M. Heard <heard@pobox.com> wrote:

>

> On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote:

>> This text does not make any normative statement on the question if=
 the

>> behavior specified in RFC3168 should be implemented or not. It onl=
y says

>> please look at RFC3168 and make an informed decision if you want t=
o confirm

>> to the behavior that is specified in RFC3168 in addition to implem=
enting the

>> spec in this document. However, yes, this statement is true for al=
l IPv6

>> implementation. I don't see a problem here...

>

> Nor do I. As it happens I prefer the text proposed by Bob Hinden (with=


> David Black's modification) but I believe that the effect is essen=
tially the

> same as the text you proposed. So it seems that the discussion is boil=
ing

> down to editorial issues, and I am happy to leave that between you,
> the shepherd, and the document editor.




The current text I have is:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nodes that support Explicit Congestion No=
tification [RFC3168]


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use informatio=
n in the Traffic Class field from all fragment

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets to reconstruct the Traffic Class =
field in the


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reassemb=
led packet.=C2=A0 See Section 5.3 of RFC3168 for more

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information.
=



This looks good to me as well. My only concern with the previous=
 version was that it sounded normative.=C2=A0

Regards=C2=A0
Suresh=C2=A0



--f403045f907edc9c2d054d8bf935--


From nobody Wed Apr 19 15:44:31 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF0B1293FD for ; Wed, 19 Apr 2017 15:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 s7aVWNxT2K2Q for ; Wed, 19 Apr 2017 15:44:27 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F69124282 for ; Wed, 19 Apr 2017 15:44:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=WxrCB7MVbiIlSPSBhrEzmFuazYmKG1F+BhCQgyWM2RHljkKJSTEyl925Rbqnfgoa4c70Vyln7LJ8rsbkj12ewLDYLiHVtsG5I+XkIGIZQ0wdhHtPOCHGkldd7C/mGSGNfzYGZBcp0464kvN9M8N5tnO/Vy3uQ4bSE8ozlqTY+AE=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 7349 invoked from network); 20 Apr 2017 00:44:25 +0200
Received: from 178-83-155-34.dynamic.hispeed.ch (HELO ?192.168.220.145?) (178.83.155.34) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Apr 2017 00:44:24 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: 
Date: Thu, 20 Apr 2017 00:44:05 +0200
Cc: Bob Hinden , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , IESG , 6man-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2EEDA924-5DD8-4B2A-B682-BA0F603F3126@kuehlewind.net>
References:       
To: Suresh Krishnan 
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170419224425.7338.7651@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Apr 2017 22:44:29 -0000

Hi,

I really don=E2=80=99t like the term "Nodes that support Explicit =
Congestion Notification=E2=80=9C. I guess we understand something =
different under =E2=80=9Esupport=E2=80=9C but maybe can just avoid that =
word to avoid any confusion.

Thanks,
Mirja


> Am 19.04.2017 um 23:47 schrieb Suresh Krishnan =
:
>=20
> Hi Bob,=20
>=20
> On Apr 19, 2017 5:16 PM, "Bob Hinden"  wrote:
> Mike,
>=20
> > On Apr 19, 2017, at 10:54 AM, C. M. Heard  wrote:
> >
> > On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote:
> >> This text does not make any normative statement on the question if =
the
> >> behavior specified in RFC3168 should be implemented or not. It only =
says
> >> please look at RFC3168 and make an informed decision if you want to =
confirm
> >> to the behavior that is specified in RFC3168 in addition to =
implementing the
> >> spec in this document. However, yes, this statement is true for all =
IPv6
> >> implementation. I don't see a problem here...
> >
> > Nor do I. As it happens I prefer the text proposed by Bob Hinden =
(with
> > David Black's modification) but I believe that the effect is =
essentially the
> > same as the text you proposed. So it seems that the discussion is =
boiling
> > down to editorial issues, and I am happy to leave that between you,
> > the shepherd, and the document editor.
>=20
> The current text I have is:
>=20
>          Nodes that support Explicit Congestion Notification [RFC3168]
>          use information in the Traffic Class field from all fragment
>          packets to reconstruct the Traffic Class field in the
>          reassembled packet.  See Section 5.3 of RFC3168 for more
>          information.
>=20
>=20
> This looks good to me as well. My only concern with the previous =
version was that it sounded normative.=20
>=20
> Regards=20
> Suresh=20
>=20


From nobody Wed Apr 19 17:51:31 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B43E1293EC; Wed, 19 Apr 2017 17:51:23 -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=WbBLvaLe; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=M2SjlXJp
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 qZlVJinCb0Lz; Wed, 19 Apr 2017 17:51:21 -0700 (PDT)
Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 3F91C126557; Wed, 19 Apr 2017 17:51:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1492649481; x=1524185481; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cRHzvUdushcIvz5qR8+4dbqYi2Cu03Ttxk8xRSJfYBU=; b=WbBLvaLeji6wzixzseR/jSWF7Q1q+LDJIc/DhjUzfzoiniAEVigjgVqP TZoUcBV0/hSxQCSXYfuPTBfN/v6yn6auMFLlrYkPPMKlFTGe3S+evy2zO n/3x5+3oFIac+Hmn37xXPxgZJY09fh+nmSM2DGpRsGCXR+DZoCNwK6/ag 8=;
Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 19:51:20 -0500
From: "Black, David" 
Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , Bob Hinden , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "Black, David" 
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2017 06:51:19 +0600
Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3K0pFGx025773 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Apr 2017 20:51:18 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v3K0pFGx025773
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1492649479; bh=XmuOI+/iqRsZeyVpqmwUqO9Zyj0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=M2SjlXJpRSfHN7zTfrR+2w6XmvnEcBHnN3OAU3oXci6MTa86LF/JaFegMXIDHtJoN fueWIaq2ePskCnm9luQdCiYM6ugEnaSlxo3k+gK03D/Z++BULbvV856CbC1P0mIpUR o09uW9mlWK30FLBBpYDfwpWghhKbbtx8TlqTJR/g=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v3K0pFGx025773
Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 19 Apr 2017 20:50:49 -0400
Received: from MXHUB321.corp.emc.com (MXHUB321.corp.emc.com [10.146.3.99]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3K0ow5C006950 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 19 Apr 2017 20:50:58 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB321.corp.emc.com ([10.146.3.99]) with mapi id 14.03.0266.001; Wed, 19 Apr 2017 20:50:53 -0400
To: "Mirja Kuehlewind (IETF)" , Suresh Krishnan 
Thread-Topic: =?utf-8?B?W3RzdndnXSAgTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi02bWFuLXJmYzI0NjBiaXMtMDk6ICh3aXRoIERJU0NVU1MgYW5kIENP?= =?utf-8?Q?MMENT)?=
Thread-Index: AQHSuStgZu6NHGLLOU+TvYwkOtjBVaHNNH0AgAAIRQCAADhnAP//xdbdgABSnYD//9MTIA==
Date: Thu, 20 Apr 2017 00:50:53 +0000
Message-ID: 
References:        <2EEDA924-5DD8-4B2A-B682-BA0F603F3126@kuehlewind.net>
In-Reply-To: <2EEDA924-5DD8-4B2A-B682-BA0F603F3126@kuehlewind.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com
X-RSA-Classifications: public, GIS Solicitation
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Apr 2017 00:51:23 -0000

QmFzZWQgb24gQnJpYW4ncyBjb21tZW50IG9uIERTQ1AsIG9ubHkgdGhlIEVDTiBwb3J0aW9uIG9m
IHRoZSB0cmFmZmljIGNsYXNzIGZpZWxkIGlzIGludm9sdmVkLg0KDQpJIGFncmVlLCBidXQgb2Zm
ZXIgc29tZSBtb3JlIGV4cGxhbmF0aW9uIGFib3V0IGFub3RoZXIgc2NlbmFyaW8uICBJIGNvdWxk
IHNlZSBhIHRyYWZmaWMgc2hhcGVyIGNoYW5naW5nIEFGIGRyb3AgcHJlY2VkZW5jZSBvbiBzb21l
IGZyYWdtZW50cyBidXQgbm90IG90aGVycyB3aXRob3V0IGxvb2tpbmcgdG8gc2VlIHdoZXRoZXIg
b3Igbm90IGFueSBmcmFnbWVudCBjb250YWlucyBhIHRyYW5zcG9ydCBwcm90b2NvbCBoZWFkZXIu
ICBPVE9ILCB0byBhIGZpcnN0IGFwcHJveGltYXRpb24sIGJlY2F1c2UgdGhhdCBzaGFwZXIncyBu
b3QgbG9va2luZyBiZXlvbmQgdGhlIElQIGhlYWRlcnMsIHRoZSBsaWtlbGlob29kIG9mIGl0IHJl
bWFya2luZyBhIGZpcnN0IGZyYWdtZW50IHNob3VsZCBiZSB0aGUgc2FtZSBhcyBpdHMgb3ZlcmFs
bCByZW1hcmtpbmcgbGlrZWxpaG9vZCwgaGVuY2UgcmVhc3NlbWJseSBiYXNlZCBvbiB0aGUgRFND
UCBpbiB0aGUgZmlyc3QgZnJhZ21lbnQgKGUuZy4sIGF0IGEgdHVubmVsIGVncmVzcykgc2hvdWxk
IG9uIGF2ZXJhZ2UgcmVzdWx0IGluIHRoZSBzYW1lIGRlZ3JlZSBvZiByZW1hcmtpbmcgaW4gdGhl
IHJlYXNzZW1ibGVkIHBhY2tldCBzdHJlYW0gYXMgd2FzIGluIHRoZSBmcmFnbWVudGVkIHBhY2tl
dCBzdHJlYW0uICAgVGhlIHNoYXBlciBoYXMgY29uc2lzdGVudCBsb25nLXRlcm0gYmVoYXZpb3Is
IHdoZXJlIGxvbmcgdGVybSBtZWFucyBtYW55LCBtYW55IFJUVHMgZm9yIHRoZSBmbG93cyBpbnZv
bHZlZCwgc28gYW4gYXBwZWFsIHRvIHRoaW5ncyBhdmVyYWdpbmcgb3V0IGlzIHBsYXVzaWJsZS4g
IEluIGNvbnRyYXN0LCBFQ04gb3BlcmF0ZXMgb24gUlRUIHRpbWVzY2FsZSwgbWFraW5nIHRoaXMg
YXZlcmFnaW5nIHJhdGlvbmFsZSBpbmFwcGxpY2FibGUgdG8gRUNOLg0KDQpJIHdvdWxkIGNhbGwg
RUNOIG91dCBleHBsaWNpdGx5Og0KDQogICAgICAgICAgTm9kZXMgdGhhdCBzdXBwb3J0IEV4cGxp
Y2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIFtSRkMzMTY4XQ0KICAgICAgICAgIHVz
ZSBFQ04gIGluZm9ybWF0aW9uIGluIHRoZSBUcmFmZmljIENsYXNzIGZpZWxkIGZyb20gYWxsIGZy
YWdtZW50DQogICAgICAgICAgcGFja2V0cyB0byByZWNvbnN0cnVjdCB0aGUgRUNOIHBvcnRpb24g
b2YgdGhlIFRyYWZmaWMgQ2xhc3MgZmllbGQgaW4NCiAgICAgICAgICB0aGUgcmVhc3NlbWJsZWQg
cGFja2V0LiAgU2VlIFNlY3Rpb24gNS4zIG9mIFJGQzMxNjggZm9yIG1vcmUNCiAgICAgICAgICBp
bmZvcm1hdGlvbi4NCg0KQmV5b25kIHRoYXQsIEkgaGF2ZSB0byBjb25jdXIgd2l0aCBzb21lIHBh
cnQgb2YgTWlyamEncyB1bmRlcmx5aW5nIGNvbmNlcm4gYWJvdXQgd2hhdCAiTm9kZXMgdGhhdCBz
dXBwb3J0IiBtZWFucy4gICBTdXBwb3NlIEkgaGF2ZSBhIHVzZXItbW9kZSBTQ1RQIGltcGxlbWVu
dGF0aW9uIHRoYXQgdXNlcyBFQ04gaW4gdGhlIFVEUCBlbmNhcHN1bGF0aW9uICh0aGluayBXZWIg
UlRDKSBhbmQgYW4gSVB2NiBrZXJuZWwtbW9kZSBpbXBsZW1lbnRhdGlvbiB0aGF0IHVzZXMgb25s
eSB0aGUgZmlyc3QgZnJhZ21lbnQncyBFQ04gY29kZXBvaW50IGluIGRvaW5nIEVDTiByZWFzc2Vt
Ymx5LiAgIENvbmdlc3Rpb24gaW5kaWNhdGlvbnMgaW4gb3RoZXIgdGhhbiB0aGUgZmlyc3QgZnJh
Z21lbnQgYXJlIGxvc3QsIHdoaWNoIGlzIGJhZC4gIFRoZSBvcHRpb25zIGZvciBicmluZ2luZyBz
dWNoIGFuIElQdjYgaW1wbGVtZW50YXRpb24gaW50byBjb21wbGlhbmNlIHdpdGggUkZDIDMxNjgg
d2l0aG91dCBkb2luZyBhbGwtZnJhZ21lbnQgRUNOIHJlYXNzZW1ibHkgYXJlIG5vdCBwcmV0dHk6
DQoJLSBBbHdheXMgY2xlYXIgdGhlIEVDTiBmaWVsZCB0byBub3QtRUNUIChpLmUuLCAwMCkgb24g
b3V0Ym91bmQgdHJhZmZpYy4gVGhpcyBzaG91bGQgYmxvY2sgYW55IG5lZ290aWF0aW9uIG9mIEVD
TiBieSBoaWdoZXItbGV2ZWwgcHJvdG9jb2xzLg0KCS0gRHJvcCBhbnkgaW5ib3VuZCBmcmFnbWVu
dGVkIHBhY2tldC4NClRoZSAiY29tcGxldGVseSBjb3JyZWN0IiBkZWZpbml0aW9uIG9mICJOb2Rl
cyB0aGF0IGRvIG5vdCBzdXBwb3J0IEVDTiIgcHJvYmFibHkgaW5jbHVkZXMgY2xlYXJpbmcgdGhl
IEVDTiBmaWVsZCB0byBub3QtRUNUIG9uIG91dGJvdW5kIHRyYWZmaWMgLSBpcyB0aGUgY29uY2Vy
biB0aGF0IHdlJ3JlIGxvb2tpbmcgYXQgSVB2NiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhbGxvdyBF
Q04gdXNhZ2UgaW4gb3V0Ym91bmQgdHJhZmZpYyBidXQgZG9uJ3QgZ2V0IEVDTiBjb3JyZWN0IGlu
IGZyYWdtZW50IHJlYXNzZW1ibHkgZm9yIGluYm91bmQgdHJhZmZpYz8NCg0KVGhhbmtzLCAtLURh
dmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdHN2d2cgW21haWx0
bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlyamENCj4gS3VlaGxld2lu
ZCAoSUVURikNCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOSwgMjAxNyA2OjQ0IFBNDQo+IFRv
OiBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+DQo+IENjOiBkcmFm
dC1pZXRmLTZtYW4tcmZjMjQ2MGJpc0BpZXRmLm9yZzsgNk1BTiA8Nm1hbkBpZXRmLm9yZz47IHRz
dndnDQo+IDx0c3Z3Z0BpZXRmLm9yZz47IEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20+OyBC
b2IgSGluZGVuDQo+IDxib2IuaGluZGVuQGdtYWlsLmNvbT47IElFU0cgPGllc2dAaWV0Zi5vcmc+
OyA2bWFuLWNoYWlyc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3RzdndnXSBNaXJqYSBLw7xo
bGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLTZtYW4tcmZjMjQ2MGJpcy0NCj4gMDk6ICh3
aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSwNCj4gDQo+IEkgcmVhbGx5IGRvbuKA
mXQgbGlrZSB0aGUgdGVybSAiTm9kZXMgdGhhdCBzdXBwb3J0IEV4cGxpY2l0IENvbmdlc3Rpb24N
Cj4gTm90aWZpY2F0aW9u4oCcLiBJIGd1ZXNzIHdlIHVuZGVyc3RhbmQgc29tZXRoaW5nIGRpZmZl
cmVudCB1bmRlciDigJ5zdXBwb3J04oCcDQo+IGJ1dCBtYXliZSBjYW4ganVzdCBhdm9pZCB0aGF0
IHdvcmQgdG8gYXZvaWQgYW55IGNvbmZ1c2lvbi4NCj4gDQo+IFRoYW5rcywNCj4gTWlyamENCj4g
DQo+IA0KPiA+IEFtIDE5LjA0LjIwMTcgdW0gMjM6NDcgc2NocmllYiBTdXJlc2ggS3Jpc2huYW4N
Cj4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+Og0KPiA+DQo+ID4gSGkgQm9iLA0KPiA+DQo+
ID4gT24gQXByIDE5LCAyMDE3IDU6MTYgUE0sICJCb2IgSGluZGVuIiA8Ym9iLmhpbmRlbkBnbWFp
bC5jb20+IHdyb3RlOg0KPiA+IE1pa2UsDQo+ID4NCj4gPiA+IE9uIEFwciAxOSwgMjAxNywgYXQg
MTA6NTQgQU0sIEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20+IHdyb3RlOg0KPiA+ID4NCj4g
PiA+IE9uIFdlZCwgQXByIDE5LCAyMDE3IGF0IDEwOjI1IEFNLCBNaXJqYSBLw7xobGV3aW5kIHdy
b3RlOg0KPiA+ID4+IFRoaXMgdGV4dCBkb2VzIG5vdCBtYWtlIGFueSBub3JtYXRpdmUgc3RhdGVt
ZW50IG9uIHRoZSBxdWVzdGlvbiBpZiB0aGUNCj4gPiA+PiBiZWhhdmlvciBzcGVjaWZpZWQgaW4g
UkZDMzE2OCBzaG91bGQgYmUgaW1wbGVtZW50ZWQgb3Igbm90LiBJdCBvbmx5DQo+IHNheXMNCj4g
PiA+PiBwbGVhc2UgbG9vayBhdCBSRkMzMTY4IGFuZCBtYWtlIGFuIGluZm9ybWVkIGRlY2lzaW9u
IGlmIHlvdSB3YW50IHRvDQo+IGNvbmZpcm0NCj4gPiA+PiB0byB0aGUgYmVoYXZpb3IgdGhhdCBp
cyBzcGVjaWZpZWQgaW4gUkZDMzE2OCBpbiBhZGRpdGlvbiB0byBpbXBsZW1lbnRpbmcNCj4gdGhl
DQo+ID4gPj4gc3BlYyBpbiB0aGlzIGRvY3VtZW50LiBIb3dldmVyLCB5ZXMsIHRoaXMgc3RhdGVt
ZW50IGlzIHRydWUgZm9yIGFsbCBJUHY2DQo+ID4gPj4gaW1wbGVtZW50YXRpb24uIEkgZG9uJ3Qg
c2VlIGEgcHJvYmxlbSBoZXJlLi4uDQo+ID4gPg0KPiA+ID4gTm9yIGRvIEkuIEFzIGl0IGhhcHBl
bnMgSSBwcmVmZXIgdGhlIHRleHQgcHJvcG9zZWQgYnkgQm9iIEhpbmRlbiAod2l0aA0KPiA+ID4g
RGF2aWQgQmxhY2sncyBtb2RpZmljYXRpb24pIGJ1dCBJIGJlbGlldmUgdGhhdCB0aGUgZWZmZWN0
IGlzIGVzc2VudGlhbGx5IHRoZQ0KPiA+ID4gc2FtZSBhcyB0aGUgdGV4dCB5b3UgcHJvcG9zZWQu
IFNvIGl0IHNlZW1zIHRoYXQgdGhlIGRpc2N1c3Npb24gaXMgYm9pbGluZw0KPiA+ID4gZG93biB0
byBlZGl0b3JpYWwgaXNzdWVzLCBhbmQgSSBhbSBoYXBweSB0byBsZWF2ZSB0aGF0IGJldHdlZW4g
eW91LA0KPiA+ID4gdGhlIHNoZXBoZXJkLCBhbmQgdGhlIGRvY3VtZW50IGVkaXRvci4NCj4gPg0K
PiA+IFRoZSBjdXJyZW50IHRleHQgSSBoYXZlIGlzOg0KPiA+DQo+ID4gICAgICAgICAgTm9kZXMg
dGhhdCBzdXBwb3J0IEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFtSRkMzMTY4XQ0K
PiA+ICAgICAgICAgIHVzZSBpbmZvcm1hdGlvbiBpbiB0aGUgVHJhZmZpYyBDbGFzcyBmaWVsZCBm
cm9tIGFsbCBmcmFnbWVudA0KPiA+ICAgICAgICAgIHBhY2tldHMgdG8gcmVjb25zdHJ1Y3QgdGhl
IFRyYWZmaWMgQ2xhc3MgZmllbGQgaW4gdGhlDQo+ID4gICAgICAgICAgcmVhc3NlbWJsZWQgcGFj
a2V0LiAgU2VlIFNlY3Rpb24gNS4zIG9mIFJGQzMxNjggZm9yIG1vcmUNCj4gPiAgICAgICAgICBp
bmZvcm1hdGlvbi4NCj4gPg0KPiA+DQo+ID4gVGhpcyBsb29rcyBnb29kIHRvIG1lIGFzIHdlbGwu
IE15IG9ubHkgY29uY2VybiB3aXRoIHRoZSBwcmV2aW91cyB2ZXJzaW9uDQo+IHdhcyB0aGF0IGl0
IHNvdW5kZWQgbm9ybWF0aXZlLg0KPiA+DQo+ID4gUmVnYXJkcw0KPiA+IFN1cmVzaA0KPiA+DQoN
Cg==


From nobody Wed Apr 19 19:19:57 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F558129B30; Wed, 19 Apr 2017 19:19: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, FREEMAIL_FROM=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=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 YXmmmJkHnyFW; Wed, 19 Apr 2017 19:19:38 -0700 (PDT)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 40E15129470; Wed, 19 Apr 2017 19:19:38 -0700 (PDT)
Received: by mail-wm0-x243.google.com with SMTP id z129so8107798wmb.1; Wed, 19 Apr 2017 19:19:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=43/iu3Ve8lKY25pyW6Me+3So5lFgEKTLhd3CEsRCMvY=; b=RUAXEV1Ti5hPZItjgw4p6KHX3t5v0mgN5+QQ4i67HVEyxlCPREGYzhAytfddbZmj1Z Msiy2hEIP6K928rTML2z+uk2bpngfCgtKRnmXwziL0Sp4UMkzYGdSzZ5InkyQXppmHl0 rDOS9eyKxHtxuvENOTbjirOfsfeIQp9aXdwY5FYTPp5u0LyoMSl9kYUysahXuYa0mtTb aMtn5x0763P1TjjidvsyFL5dPRICpfcXWuoaSYU9cj+RnrVXv6McsPTN6lDlsndkSEs6 01yoNjg+ujS6cqpvIgqV9+V+8F8uu+aTPVmvvvqw6N873kz7qxovpi2WhYDnWCpkxd2z t6DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=43/iu3Ve8lKY25pyW6Me+3So5lFgEKTLhd3CEsRCMvY=; b=KjATi+yGm9P0CsM4EXnWwc/8HhDx7+BfZPtrfNu1n/OaoyoicCSPqv0W0FW8cWpviU zyKFRF8OzaDtoLMKzaQIW6alm1oExMMvj6jXdcQLyKDs0qirQhZLPVDy1nH+Xi5CKBS7 rQMSJsIcTNQ204CLB8gJhIDkcrOsad9jdj0u7goBRo4WsuBn8m4DS6GBbICS72QViaS9 81UBf6OZo0zq3tW7P1zsex1M3RET8r3WQc6miEFt8dk++co1rcCCnpqXx+qjL6w6+Hwj 0zntpoFJWoz0hlEG6itbRIP/MSz27vWzdUJTgnYUMTfjIFXwctGXWQrxUBWYfYdit4dn mbYw==
X-Gm-Message-State: AN3rC/6W8q/Azco1OUm0fnuwERG+BN0hu/eO/1YlbW//2a6Wf7RL2agB 3nOzCHExtJPiBpTVVxc=
X-Received: by 10.28.57.138 with SMTP id g132mr697697wma.92.1492654776701; Wed, 19 Apr 2017 19:19:36 -0700 (PDT)
Received: from ?IPv6:2601:647:4d01:db10:9cf5:b82e:11d6:5b43? ([2601:647:4d01:db10:9cf5:b82e:11d6:5b43]) by smtp.gmail.com with ESMTPSA id v23sm5015683wra.65.2017.04.19.19.19.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 19:19:34 -0700 (PDT)
From: Bob Hinden 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_E6CB7AD2-2D83-4A30-AF46-9FDFF2B8F8FD"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 19 Apr 2017 19:19:28 -0700
In-Reply-To: <2EEDA924-5DD8-4B2A-B682-BA0F603F3126@kuehlewind.net>
Cc: Bob Hinden , Suresh Krishnan , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , IESG , 6man-chairs@ietf.org
To: "Mirja Kuehlewind (IETF)" 
References:        <2EEDA924-5DD8-4B2A-B682-BA0F603F3126@kuehlewind.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Apr 2017 02:19:40 -0000

--Apple-Mail=_E6CB7AD2-2D83-4A30-AF46-9FDFF2B8F8FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Mirja,

> On Apr 19, 2017, at 3:44 PM, Mirja Kuehlewind (IETF) =
 wrote:
>=20
> Hi,
>=20
> I really don=E2=80=99t like the term "Nodes that support Explicit =
Congestion Notification=E2=80=9C. I guess we understand something =
different under =E2=80=9Esupport=E2=80=9C but maybe can just avoid that =
word to avoid any confusion.

While I think it=E2=80=99s clear, alternatives might be =E2=80=9Cimplement=
=E2=80=9D, =E2=80=9Cperform=E2=80=9D, =E2=80=9Cpractice=E2=80=9D, =
=E2=80=9Ceffect=E2=80=9D, etc.

Bob

>=20
> Thanks,
> Mirja
>=20
>=20
>> Am 19.04.2017 um 23:47 schrieb Suresh Krishnan =
:
>>=20
>> Hi Bob,
>>=20
>> On Apr 19, 2017 5:16 PM, "Bob Hinden"  wrote:
>> Mike,
>>=20
>>> On Apr 19, 2017, at 10:54 AM, C. M. Heard  wrote:
>>>=20
>>> On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote:
>>>> This text does not make any normative statement on the question if =
the
>>>> behavior specified in RFC3168 should be implemented or not. It only =
says
>>>> please look at RFC3168 and make an informed decision if you want to =
confirm
>>>> to the behavior that is specified in RFC3168 in addition to =
implementing the
>>>> spec in this document. However, yes, this statement is true for all =
IPv6
>>>> implementation. I don't see a problem here...
>>>=20
>>> Nor do I. As it happens I prefer the text proposed by Bob Hinden =
(with
>>> David Black's modification) but I believe that the effect is =
essentially the
>>> same as the text you proposed. So it seems that the discussion is =
boiling
>>> down to editorial issues, and I am happy to leave that between you,
>>> the shepherd, and the document editor.
>>=20
>> The current text I have is:
>>=20
>>         Nodes that support Explicit Congestion Notification [RFC3168]
>>         use information in the Traffic Class field from all fragment
>>         packets to reconstruct the Traffic Class field in the
>>         reassembled packet.  See Section 5.3 of RFC3168 for more
>>         information.
>>=20
>>=20
>> This looks good to me as well. My only concern with the previous =
version was that it sounded normative.
>>=20
>> Regards
>> Suresh
>>=20
>=20


--Apple-Mail=_E6CB7AD2-2D83-4A30-AF46-9FDFF2B8F8FD
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJY+BqxAAoJEK7rdBF357uoFFgH/j/GqFXj09R0obBciYx/+rUm
fKdOsEh7HYoIYlMNoQxxDyp2RVJcC5Ozh9ue0B1D3LTuobJJrQwfawcziLuvLLwP
FaNNGByAFMzjRQWfhPxIdoGefLGUFnuc2VZnggw6ZFb9/KC81n/LdBNgWSWmbVJ9
2i9sjc5S7fuhU3LU1L3PV/rds6KSHb6vdBSIGy/sAnn7pVwTDUXEZwUFq/DEwZ8F
SkTxhea3fBHPKdV4RNZ5iYfuOAIEtrNfpWnj4AgoCAlUyMq79KXhUg5uIifAKGlb
CSAIr5+MhkKPE/VZAIDxSonUUYGk5nM4tP8kzDpnqEu3HFENW5ZYrNimQxKYSVs=
=R9aq
-----END PGP SIGNATURE-----

--Apple-Mail=_E6CB7AD2-2D83-4A30-AF46-9FDFF2B8F8FD--


From nobody Thu Apr 20 10:14:47 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CF4129B26 for ; Thu, 20 Apr 2017 10:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iTgVskk_kUn for ; Thu, 20 Apr 2017 10:14:44 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1207B129AD4 for ; Thu, 20 Apr 2017 10:14:44 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id h67so52341189qke.0 for ; Thu, 20 Apr 2017 10:14:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=dE0S+DqHUBEy+yZiku1rVm40Yx/B0a4ZWbzsZcSbXj0=; b=JNmFtTLAiFW0txxklqKzY6AUHgKCDBRsBdaX5c0uEbz1L4rg2L9DtF0i1/ufy8lnPi Q8uKieyEYwpicgNDrswByElNVU1vPR3zJ+7WBu1UXwlpQV/gLjyU1+07tv/R5D3QyQnO m0DhTE0aUNw3A1lqBc83eiZ+ZY3wo1pOVLJBBQcAP6JMy2P9GbhaNBIvR8YieNrQtyDl kRzrqtUlSMyDLj/Auo4M28qjsAUqUI1W0iO0vdTTBDnFK91fd/ml9YVHFhpJ1TonZ0H6 wgPpW55bkx1OEtpZCxjsfRAkWeIkmBkb/duZLNtbmWlNaxwOeuOKhmhS+gkdvgCN2u9U KPkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dE0S+DqHUBEy+yZiku1rVm40Yx/B0a4ZWbzsZcSbXj0=; b=emQMMlo+9S3dPYychnDVzIOAX51mI3iPzI9PimG7cDg/hehc/Urng2oBo+BqQYzWul mMfvsVBv3udt3MaNSSerPJPAZKMRpIL44SWzz+NyJQAZFKlf/kwgUPy5Zl4tpSa6ih+Q OS52axM/EiKqEsWHwanBDupqw223Oc1LXv92wqiD+AjCbMVO3Qm69AYLaN9AlQUDzvoA dugXiQzTzyjrhvPAYVI6q/f1HP0Nle48pPfrXQBpnzvYBL30jrLOjRtLgcsVN2gjUhp2 nJ9agFdkMReilDnRmh61x7rll6AWmmMnk1HQuBWAdUnwUPC2S1hkAmdOvwEdt5LFzTEg 56rg==
X-Gm-Message-State: AN3rC/7b/jhHcw5nQ5nL5g9Ph48AOPE37qmcTfuKaMBQbHmtE4EVHWR7 zmOO/Uhv33BkoxLK+lyFWAJKSXML5e5i
X-Received: by 10.55.89.196 with SMTP id n187mr8484861qkb.322.1492708482898; Thu, 20 Apr 2017 10:14:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Thu, 20 Apr 2017 10:14:42 -0700 (PDT)
From: Tom Herbert 
Date: Thu, 20 Apr 2017 10:14:42 -0700
Message-ID: 
To: tsvwg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Apr 2017 17:14:46 -0000

Hi,

Here are some more comments on UDP options...

There are many possible error conditions that need to be considered
and for each of these the action to be taken by a receiver needs to be
specified. I highlighted some of these error conditions, there may be
more.

Is there a limit to the number of options, or size of option space?.
For instance, could someone send a 64K IP packet with 20 byte IP
header, 8 byte UDP header with zero length, and 65000 worth of
timestamp options or NOP (aka a DOS attack).

I suggest the following requirements to a reasonable limits:
* With the exception of NOP, no options can appear more than once
* Four or more more consecutive NOPs is not allowed
*  At the first instance of either of the above conditions the
violating options as well as any subsequent ones are ignored and not
processed

In LITE the UDP length needs to be restored to the original value
before handing packet to application.

>From the draft:

"When present, the option checksum SHOULD occur as early as possible,
preferably preceded by only NOP options for alignment and the LITE
option if present."

Ordering requirements options are in various places in the draft. It
might be clearer to consolidate all these requirements in one section.

What about options 9-127, I assume these are reserved in the draft also?

What is handling if an option with unknown kind is received?

What if an the length of an option is incorrect for the kind of received option?

Why doesn't OCS use the normal Internet checksum? Is this just to save
one byte in the options?

What if the length of an option would make that option go beyond IP length?

What is the action if ACS fails, same as OCS?

What is the action if AE fails to authenticate? If the action is same
as OCS it would be somewhat odd to me to accept a packet with a field
we failed to authenticate...

What if there is a checksum option but the kind has been corrupted
such that it no longer indicates a checksum? Should checksum always be
in a fixed header to avoid this case?

How would the UDP MSS option be used for path MTU discovery? Does this
expect that routers will be putting their MTU in the field?

What happens if a host receives a well formed FRAG option but has not
sent the initial one? 1) Is the packet accepted as a non-fragment, 2)
Is it reassembled? 3) Is the packet dropped? This can happen in the
NAT eviction scenario (see below).

>From the draft: "The reassembly checksum SHOULD be used, but MAY be
ignored in the same situations when the UDP checksum is ignored" --
this wording is imprecise. A non-zero UDP checksum is never ignored by
a receiver. It may be set to zero on transmit (no checksum) for
UDP/IPv4, but is required for UDP/IPv6 (except for an allowance with
tunnels described in RFC6935 and RFC6936). I'm pretty sure the draft
means that the fragmentation checksum may be set zero to indicate no
checksum. Also, it should be specified what the fragmentation checksum
covers. Presumably, it covers the reassembled UDP payload and the
checksum value in the option. Since there is no pseudo header, the
checksum can always safely be zero (like an IPv4 UDP checksum). In
practice, I doubt a fragmentation checksum would be used, we already
get the UDP checksum computation for free in NICs and the
fragmentation checksum would be mostly redundant to that and costly to
perform the calculation.

What is the normative requirement for using FRAG + LITE?

"UDP options MUST NOT follow the FRAG header in non-terminal
fragments." If a host receives a packet that violates this what is the
action to take?

>From the draft: "It has been reported that Alcatel-Lucent's "Brick"
Intrusion Detection System has a default configuration that interprets
inconsistencies between UDP Length and IP Length as an attack to be
reported. Note that other firewall systems, e.g., CheckPoint, use a
default "relaxed UDP length verification" to avoid falsely
interpreting this inconsistency as an attack."

It's subjective to say that inconsistency in lengths should not be
considered attack. I can easily imagine an DOS attack against
bandwidth in a network where tiny UDP packets are placed in full MTU
sized packets. Blocking packets with inconsistent lengths is a
reasonable mitigation. Maybe in addition the limits I suggested above,
there should also be a limit on IP_length - UDP_length as guidance to
firewall vendors. (maybe 40 bytes just to be consistent with TCP?)

NAT eviction might be challenging. Consider that in TCP, if a NAT
state is evicted the connection will be broken and both sides will
(eventually) close the connection. But with a UDP eviction, then next
time a packet behind the NAT sends a packet on the evicted flow the
NAT can create a new flow state. This new flow state may use different
source port or address than previous one. To the device behind the NAT
nothing has changed, it still uses the same tuple. But for it's peer
it now sees a completely new flow, if has no way of knowing about the
change. This is one reason that QUIC has a connection identifier to
keep its own persistence across a NAT state change. This might break
the option negotiation described in the draft. For instance, the
device behind the NAT might send a FRAG option since it had seen the
initial FRAG from the peer in its tuple, but the from the peer's point
of view it never sent the FRAG option on its tuple. To make matters
worse, if the peer lives behind an L4 load balancer (common) the new
flow may wind up on a completely different machine that might not even
support UDP options (for instance it happens to run an old OS).

>From the draft: "The UDP OCS provides protection against such events
and is stronger than a static "magic number"."

I don't understand why this would be true on two accounts:
1) OCS has very little entropy. It is only 8 bits and the whole option
size is 16 bits. A static magic number, like that considered for SPUD,
was at least 64 bits.
2) It's not required AFAICT


From nobody Thu Apr 20 11:17:49 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258251201F8 for ; Thu, 20 Apr 2017 11:17: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 wrYpkKAIFLj3 for ; Thu, 20 Apr 2017 11:17:47 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 49863126C25 for ; Thu, 20 Apr 2017 11:17:47 -0700 (PDT)
Received: from [128.9.184.96] ([128.9.184.96]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v3KIGD2q011022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Apr 2017 11:16:14 -0700 (PDT)
To: Tom Herbert , tsvwg 
References: 
From: Joe Touch 
Message-ID: <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>
Date: Thu, 20 Apr 2017 11:16:11 -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: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Subject: Re: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Apr 2017 18:17:49 -0000

Hi, Tom,

On 4/20/2017 10:14 AM, Tom Herbert wrote:
> Hi,
>
> Here are some more comments on UDP options...
>
> There are many possible error conditions that need to be considered
> and for each of these the action to be taken by a receiver needs to be
> specified. I highlighted some of these error conditions, there may be
> more.
>
> Is there a limit to the number of options, or size of option space?.
Only the size of the IP payload.

> For instance, could someone send a 64K IP packet with 20 byte IP
> header, 8 byte UDP header with zero length, and 65000 worth of
> timestamp options or NOP (aka a DOS attack).
>
> I suggest the following requirements to a reasonable limits:
> * With the exception of NOP, no options can appear more than once
> * Four or more more consecutive NOPs is not allowed
It might be easier to say that NOPs should occur no more than 3 times
between other options.

> *  At the first instance of either of the above conditions the
> violating options as well as any subsequent ones are ignored and not
> processed
Sure.

> In LITE the UDP length needs to be restored to the original value
> before handing packet to application.
I'm not sure what "original value" means.

If a user sends a UDP LITE-option message (whether by the UDP option
method or UDP-LITE), they are indicating two parts: checksummed and not.
Just like UDP-LITE, the UDP length field only ever indicates the amount
of data that is covered by the checksum. There's nothing to "restore".

The exception would be the LITE/FRAG case, which we do need to restore,
but it ought to be restored by reassembly already. I'll double-check
that and see if we need a special case for LITE+FRAG processing.

> >From the draft:
>
> "When present, the option checksum SHOULD occur as early as possible,
> preferably preceded by only NOP options for alignment and the LITE
> option if present."
>
> Ordering requirements options are in various places in the draft. It
> might be clearer to consolidate all these requirements in one section.

Sure.

> What about options 9-127, I assume these are reserved in the draft also?
They'll be added as "unassigned". I'm not sure whether we really need to
reserve 128-253 (that was in case we wanted to try to use the high bit
as a flag, but I'm not sure that's a good idea).

> What is handling if an option with unknown kind is received?
Silently ignore - I'll add that text.

> What if an the length of an option is incorrect for the kind of received option?
Treat the packet as corrupt and silently drop. I'll add that too.

> Why doesn't OCS use the normal Internet checksum? Is this just to save
> one byte in the options?
And keep things half-word aligned.

> What if the length of an option would make that option go beyond IP length?
Same thing as above - treat as corrupt and silently drop.

> What is the action if ACS fails, same as OCS?
Silently drop (possibly log in aggregate for diagnostics, though I would
suggest doing that only for checksum failures, not semantic errors as
above).

> What is the action if AE fails to authenticate? If the action is same
> as OCS it would be somewhat odd to me to accept a packet with a field
> we failed to authenticate...
A packet would have to pass all the authentications and checksums to pass.

AE works like AO, though - things silently pass until you turn it on for
a given socketpair. That's worth nothing explicitly in the AE section
and I'll add.

> What if there is a checksum option but the kind has been corrupted
> such that it no longer indicates a checksum? 
Then it's not a checksum option anymore.

> Should checksum always be
> in a fixed header to avoid this case?
The user can set the socketpair as "OCS required if options used" if
they want. IMO, that's a system configuration issue.

> How would the UDP MSS option be used for path MTU discovery?
The same way the TCP MSS option is - not at all. MSS indicates the max
receiver reassembly size.

>  Does this
> expect that routers will be putting their MTU in the field?
Same as TCP MSS - no. This is information to be used on the return path
as a hint about reassembly limits.

> What happens if a host receives a well formed FRAG option but has not
> sent the initial one? 1) Is the packet accepted as a non-fragment, 2)
> Is it reassembled? 3) Is the packet dropped? This can happen in the
> NAT eviction scenario (see below).
FRAG, like other soft-state options - must be confirm-before-use. That
means it would be silently dropped.

If NAT eviction is a concern, then we need to ensure that soft state is
refreshed. I can add that to the discussion of soft state.

> >From the draft: "The reassembly checksum SHOULD be used, but MAY be
> ignored in the same situations when the UDP checksum is ignored" --
> this wording is imprecise. A non-zero UDP checksum is never ignored by
> a receiver. It may be set to zero on transmit (no checksum) for
> UDP/IPv4, but is required for UDP/IPv6 (except for an allowance with
> tunnels described in RFC6935 and RFC6936). I'm pretty sure the draft
> means that the fragmentation checksum may be set zero to indicate no
> checksum.
Yes - that can be clarified.

>  Also, it should be specified what the fragmentation checksum
> covers. Presumably, it covers the reassembled UDP payload and the
> checksum value in the option.

Coverage is already indicated in 5.8:

   ...the terminal FRAG option
   is indicated as a longer, 12-byte variant, which includes an
   Internet checksum over the reassembled payload (omitting the IP
   pseudoheader and UDP header, as well as UDP options)

No, it does not include the checksum value in the option (that's
recursive!).
> Since there is no pseudo header, the
> checksum can always safely be zero (like an IPv4 UDP checksum). In
> practice, I doubt a fragmentation checksum would be used, we already
> get the UDP checksum computation for free in NICs and the
> fragmentation checksum would be mostly redundant to that and costly to
> perform the calculation.
The fragmentation reassembly checksum ensures that the reassembly is not
corrupt. No amount of component checksums ensures that.

I.e., FRAG might be a case where the UDP checksum of each FRAG is zero
but the FRAG checksum is used. I think that's better advice to users.
> What is the normative requirement for using FRAG + LITE?
Not sure what you mean... can you explain?

> "UDP options MUST NOT follow the FRAG header in non-terminal
> fragments." If a host receives a packet that violates this what is the
> action to take?
Silently drop.

> >From the draft: "It has been reported that Alcatel-Lucent's "Brick"
> Intrusion Detection System has a default configuration that interprets
> inconsistencies between UDP Length and IP Length as an attack to be
> reported. Note that other firewall systems, e.g., CheckPoint, use a
> default "relaxed UDP length verification" to avoid falsely
> interpreting this inconsistency as an attack."
>
> It's subjective to say that inconsistency in lengths should not be
> considered attack.
No, it isn't. You can say that inconsistencies are errors, but the
Postel Principle says that anything allowed by the spec should be
accepted by the receiver. Inferring an attack from what could be
legitimate behavior is simply wrong.

> I can easily imagine an DOS attack against
> bandwidth in a network where tiny UDP packets are placed in full MTU
> sized packets. 
Why on earth would anyone bother? Why not just send large packets -
wouldn't they create more damage?

> Blocking packets with inconsistent lengths is a
> reasonable mitigation. Maybe in addition the limits I suggested above,
> there should also be a limit on IP_length - UDP_length as guidance to
> firewall vendors. (maybe 40 bytes just to be consistent with TCP?)
Please see draft-ietf-tcpm-tcp-edo. No, 40 bytes isn't enough and won't
be enough.

> NAT eviction might be challenging. Consider that in TCP, if a NAT
> state is evicted the connection will be broken and both sides will
> (eventually) close the connection. But with a UDP eviction, then next
> time a packet behind the NAT sends a packet on the evicted flow the
> NAT can create a new flow state. This new flow state may use different
> source port or address than previous one. To the device behind the NAT
> nothing has changed, it still uses the same tuple. But for it's peer
> it now sees a completely new flow, if has no way of knowing about the
> change. This is one reason that QUIC has a connection identifier to
> keep its own persistence across a NAT state change. This might break
> the option negotiation described in the draft. For instance, the
> device behind the NAT might send a FRAG option since it had seen the
> initial FRAG from the peer in its tuple, but the from the peer's point
> of view it never sent the FRAG option on its tuple. To make matters
> worse, if the peer lives behind an L4 load balancer (common) the new
> flow may wind up on a completely different machine that might not even
> support UDP options (for instance it happens to run an old OS).
That's a good reason for the soft-state to be refreshed - on both sides.

> >From the draft: "The UDP OCS provides protection against such events
> and is stronger than a static "magic number"."
>
> I don't understand why this would be true on two accounts:
> 1) OCS has very little entropy. It is only 8 bits and the whole option
> size is 16 bits. A static magic number, like that considered for SPUD,
> was at least 64 bits.
Magic numbers don't protect against errors except within the space of
the magic number itself.

> 2) It's not required AFAICT
We haven't decided that as a WG, but it is on the table.

Joe


From nobody Thu Apr 20 19:43:57 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E1112940D; Thu, 20 Apr 2017 19:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 sdHzhTZTXT8W; Thu, 20 Apr 2017 19:43:54 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B431293FC; Thu, 20 Apr 2017 19:43:54 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id j59so26979432uad.0; Thu, 20 Apr 2017 19:43:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=ZboL0j/mchREVtfwikKVwTlRBTmVj8GClXhSXdCYJDc=; b=irwLn1UZr/gq/QU3ivn/ulPIIzwun7EGfD6VYlzmBl437gNJ36f9WfokFs7SMmdfhC cdtDX4QwIk2KI/J/ToQIJ2rcWo3z/csQTNsrYhMtwC3BkXbVEPkbOzuDNHDgRdNii1E/ cQ004X+wVKTHtE9uLygSE6pZPIEQw6dbTCio81SsGrmnaR2j+FMIrv621gq5ae3icj5l oHreiN2UahbFhbGQb9LcpFRcZdbo6bDzlyhFq6333n/IqLazfW/YnsKIFGidxJhCSfVt kVA4rg/1spKK5awsmlmroRACQKlnLkWD4kdC/yUgdBImYEuhua7tLCKbtbOLRaCbBsWL dHIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=ZboL0j/mchREVtfwikKVwTlRBTmVj8GClXhSXdCYJDc=; b=VXRz4SP0denPi2PaSUgHDlTubcpxShbOh3kzYJhYIV+oIFFBdwz71CMMxWxAJKng0Q MjnITz4jslJJ+RFlA9DuP9kRklS0wq4V0yh0aFNqZDHvEY5bagQyhCgjCVY0ppJwrP6F bmNs7U8LZ0xDTu7F4WbBoUxbkzv1Sin+1cT3iT8T9lZIoyCd6uq6ZFtaEEjaBeq76SAo b2cQKq6RIRAOcXxqjESQd6ZpBlUHmYg62/R+RWEjzMsEBglSTntLzfA6aIc5b85BLS8g xPjk0yqp4oyGNCD5PheQgwFhM2XXvHoY6245IzjxDOXOGzNcjuU3bectctOlRJhDlCOj rWUA==
X-Gm-Message-State: AN3rC/4K9seGjrmCrOL8w44P83wZPyEaCO2/G+f2qlueTZ6bEfaZyQxH l9eQX8tsZsBTohxED5h8AhUYD0/wQQ==
X-Received: by 10.31.61.11 with SMTP id k11mr4800561vka.141.1492742632976; Thu, 20 Apr 2017 19:43:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.123.214 with HTTP; Thu, 20 Apr 2017 19:43:52 -0700 (PDT)
From: Suresh Krishnan 
Date: Thu, 20 Apr 2017 22:43:52 -0400
Message-ID: 
To: "Mirja Kuehlewind (IETF)" 
Cc: Bob Hinden ,  "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>,  tsvwg , "C. M. Heard" , IESG ,  6man-chairs@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [tsvwg] =?utf-8?q?ECN_and_fragments_=28was_Re=3A__Mirja_K=C3=BChl?= =?utf-8?q?ewind=27s_Discuss_on_draft-ietf-6man-rfc2460bis-09=3A_=28with_D?= =?utf-8?q?ISCUSS_and_COMMENT=29=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Apr 2017 02:43:56 -0000

Hi Mirja/all,
  Even though I like Bob's suggested text (with David's suggested
change), I would like to suggest an alternate formulation that is
generic (with ECN as an example) to see if it works.

OLD:
      Only those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

NEW:

      Only those headers in the Offset zero fragment packet are retained in
      the reassembled packet. Other fields in the IPv6 header may also
      vary across the fragments being reassembled. Specifications that
      use these fields may provide alternate instructions if this basic
      mechanism of using the values from the Offset zero fragment is not
      sufficient. e.g. Section 5.3 of [RFC3168] describes how to combine
      the ECN bits from the different fragments to derive the ECN bits of
      the reassembled packet.

I realize it is a bit verbose but I couldn't shorten it further.
Thoughts/suggestions?

Thanks
Suresh

On Wed, Apr 19, 2017 at 6:44 PM, Mirja Kuehlewind (IETF)
 wrote:
> Hi,
>
> I really don=E2=80=99t like the term "Nodes that support Explicit Congest=
ion Notification=E2=80=9C. I guess we understand something different under =
=E2=80=9Esupport=E2=80=9C but maybe can just avoid that word to avoid any c=
onfusion.
>
> Thanks,
> Mirja
>
>
>> Am 19.04.2017 um 23:47 schrieb Suresh Krishnan :
>>
>> Hi Bob,
>>
>> On Apr 19, 2017 5:16 PM, "Bob Hinden"  wrote:
>> Mike,
>>
>> > On Apr 19, 2017, at 10:54 AM, C. M. Heard  wrote:
>> >
>> > On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote:
>> >> This text does not make any normative statement on the question if th=
e
>> >> behavior specified in RFC3168 should be implemented or not. It only s=
ays
>> >> please look at RFC3168 and make an informed decision if you want to c=
onfirm
>> >> to the behavior that is specified in RFC3168 in addition to implement=
ing the
>> >> spec in this document. However, yes, this statement is true for all I=
Pv6
>> >> implementation. I don't see a problem here...
>> >
>> > Nor do I. As it happens I prefer the text proposed by Bob Hinden (with
>> > David Black's modification) but I believe that the effect is essential=
ly the
>> > same as the text you proposed. So it seems that the discussion is boil=
ing
>> > down to editorial issues, and I am happy to leave that between you,
>> > the shepherd, and the document editor.
>>
>> The current text I have is:
>>
>>          Nodes that support Explicit Congestion Notification [RFC3168]
>>          use information in the Traffic Class field from all fragment
>>          packets to reconstruct the Traffic Class field in the
>>          reassembled packet.  See Section 5.3 of RFC3168 for more
>>          information.
>>
>>
>> This looks good to me as well. My only concern with the previous version=
 was that it sounded normative.
>>
>> Regards
>> Suresh
>>
>


From nobody Thu Apr 20 20:32:33 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDADB129467; Thu, 20 Apr 2017 20:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 yAkfhYHD3Zie; Thu, 20 Apr 2017 20:32:29 -0700 (PDT)
Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 CA2BF129401; Thu, 20 Apr 2017 20:32:29 -0700 (PDT)
Received: by mail-oi0-x243.google.com with SMTP id m34so6753306oik.2; Thu, 20 Apr 2017 20:32:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LE56A6l+ouyMsXvkVDE6hkDQlo7gtpxThwrT/Dj5oeA=; b=RapzBfz2PTwfXa5V/jAyZR8rtGa0f3yNI/Lhq1ntQBGSmOIBvS2aPllCgSVVCLqsU1 o4v2+uG3sy945aMTmc6AZHPrF4J8i8dgaHq8OlQqu7sd1q2VN4DfBeX88/t08rH7+zU5 HSpNzG5w3kwsmywNCz5CPdMhSHy69sgAIjLWTbeIvs8HGIhtHMyH308S9NvnY4a4tBKS Y2uR8I1LqhfNyy0FlGB6+DYzS2+JYpltFmSuROSqysZa7en1VnJ1imuqCj8TtBRgof7Z arSZTKoqugXiTK106RHgTC+14iyT0wi0D5nWl19Xel0WI4Wqwd3F4ibV9zvnCFHCXfdi SihQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LE56A6l+ouyMsXvkVDE6hkDQlo7gtpxThwrT/Dj5oeA=; b=iSaxKiS6GOjRWgKR3041KIKLE2L+GKaqql74NRQ9tuR47r3ljqVD212Piawtaotfvq EdKy/b3B2/HxP32uvZY3Ch3nOQBwNV0M8xFzZmCOq1z2uN4wCI5OaRWyWuP8SMwF2yz6 vy9OxNV0roZnbA6E/BDBD4QOHh0jxNB5bosXEEFHeovyCFx+RFfKEfyUjBaOGc98dPa2 5+A6u/CB+of/V8C6GLZ91T/cy9iKAqXZQQRzA+pFf4jGohNE7CvLriqNMsv/NCaEYLdd oaxlALsprA51fO2G/UwjoXOh5TpjJFVA7lpdBcswywrdI7R6ld6RHEnEvZfdQpoaFbPP zpYA==
X-Gm-Message-State: AN3rC/52zs4BzfyNNpg1JLDk9YksntFCn9sahDYP3hGCLJ6023CgN2ig bnNYIqIIiJt7+Q==
X-Received: by 10.84.222.12 with SMTP id w12mr13631605pls.115.1492745549129; Thu, 20 Apr 2017 20:32:29 -0700 (PDT)
Received: from [192.168.1.32] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id p68sm12782541pfp.104.2017.04.20.20.32.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 20:32:27 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura 
X-Mailer: iPhone Mail (14E304)
In-Reply-To: 
Date: Thu, 20 Apr 2017 20:32:26 -0700
Cc: "Mirja Kuehlewind (IETF)" , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , Bob Hinden , IESG , 6man-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E5E1E14-2AA8-485B-9ABD-9B3559A93835@gmail.com>
References: 
To: Suresh Krishnan 
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?ECN_and_fragments_=28was_Re=3A__Mirja_K=C3=BCh?= =?utf-8?q?lewind=27s_Discuss_on_draft-ietf-6man-rfc2460bis-09=3A_=28with_?= =?utf-8?q?DISCUSS_and_COMMENT=29=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Apr 2017 03:32:32 -0000

Sounds good!
Verbosity in this case a positive factor.

Regards,
Jeff

> On Apr 20, 2017, at 19:43, Suresh Krishnan  wro=
te:
>=20
> Hi Mirja/all,
>  Even though I like Bob's suggested text (with David's suggested
> change), I would like to suggest an alternate formulation that is
> generic (with ECN as an example) to see if it works.
>=20
> OLD:
>      Only those headers in the Offset zero fragment packet are retained in=

>      the reassembled packet.
>=20
> NEW:
>=20
>      Only those headers in the Offset zero fragment packet are retained in=

>      the reassembled packet. Other fields in the IPv6 header may also
>      vary across the fragments being reassembled. Specifications that
>      use these fields may provide alternate instructions if this basic
>      mechanism of using the values from the Offset zero fragment is not
>      sufficient. e.g. Section 5.3 of [RFC3168] describes how to combine
>      the ECN bits from the different fragments to derive the ECN bits of
>      the reassembled packet.
>=20
> I realize it is a bit verbose but I couldn't shorten it further.
> Thoughts/suggestions?
>=20
> Thanks
> Suresh
>=20
> On Wed, Apr 19, 2017 at 6:44 PM, Mirja Kuehlewind (IETF)
>  wrote:
>> Hi,
>>=20
>> I really don=E2=80=99t like the term "Nodes that support Explicit Congest=
ion Notification=E2=80=9C. I guess we understand something different under =E2=
=80=9Esupport=E2=80=9C but maybe can just avoid that word to avoid any confu=
sion.
>>=20
>> Thanks,
>> Mirja
>>=20
>>=20
>>> Am 19.04.2017 um 23:47 schrieb Suresh Krishnan :
>>>=20
>>> Hi Bob,
>>>=20
>>> On Apr 19, 2017 5:16 PM, "Bob Hinden"  wrote:
>>> Mike,
>>>=20
>>>> On Apr 19, 2017, at 10:54 AM, C. M. Heard  wrote:
>>>>=20
>>>> On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote:
>>>>> This text does not make any normative statement on the question if the=

>>>>> behavior specified in RFC3168 should be implemented or not. It only sa=
ys
>>>>> please look at RFC3168 and make an informed decision if you want to co=
nfirm
>>>>> to the behavior that is specified in RFC3168 in addition to implementi=
ng the
>>>>> spec in this document. However, yes, this statement is true for all IP=
v6
>>>>> implementation. I don't see a problem here...
>>>>=20
>>>> Nor do I. As it happens I prefer the text proposed by Bob Hinden (with
>>>> David Black's modification) but I believe that the effect is essentiall=
y the
>>>> same as the text you proposed. So it seems that the discussion is boili=
ng
>>>> down to editorial issues, and I am happy to leave that between you,
>>>> the shepherd, and the document editor.
>>>=20
>>> The current text I have is:
>>>=20
>>>         Nodes that support Explicit Congestion Notification [RFC3168]
>>>         use information in the Traffic Class field from all fragment
>>>         packets to reconstruct the Traffic Class field in the
>>>         reassembled packet.  See Section 5.3 of RFC3168 for more
>>>         information.
>>>=20
>>>=20
>>> This looks good to me as well. My only concern with the previous version=
 was that it sounded normative.
>>>=20
>>> Regards
>>> Suresh
>>>=20
>>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Sat Apr 22 05:04:46 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2011294CD for ; Sat, 22 Apr 2017 05:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 pQP-xWwpzuTv for ; Sat, 22 Apr 2017 05:04:37 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEE7129420 for ; Sat, 22 Apr 2017 05:04:37 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=Xx5y//Tuk/bA7f9rkPOYXWkEVOwtSlq+NuJCi5bq4EgJhio+fadaI+dw2/vGYHq1yzQpaAHCk9EmdNUcWdDXomyyseXp1f7rANeCZsfIuxiaaTgeUg815/GSQ5+4Pgg4W7VT9GXrXZDywKO3Pgse/KmoyIs2gY3TdGvdD4vo+Qo=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 25885 invoked from network); 22 Apr 2017 13:57:54 +0200
Received: from p5dec23d1.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.35.209) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 Apr 2017 13:57:54 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: 
Date: Sat, 22 Apr 2017 13:57:54 +0200
Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , Bob Hinden , IESG , 6man-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4DA7A0B2-AA3C-4E98-95FC-45A3CA5FC1F2@kuehlewind.net>
References: 
To: Suresh Krishnan 
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170422115754.25874.92735@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?ECN_and_fragments_=28was_Re=3A__Mirja_K=C3=BCh?= =?utf-8?q?lewind=27s_Discuss_on_draft-ietf-6man-rfc2460bis-09=3A_=28with_?= =?utf-8?q?DISCUSS_and_COMMENT=29=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Apr 2017 12:04:39 -0000

Hi Suresh,

thanks this text is fine for me.=20

I=E2=80=99d like propose three tiny editorial only changes/nits:=20
s/Other/Further,/
s/this basic/the basic/
s/sufficient. e.g./sufficient, e.g./

     Only those headers in the Offset zero fragment packet are retained =
in
     the reassembled packet. Further, fields in the IPv6 header may also
     vary across the fragments being reassembled. Specifications that
     use these fields may provide alternate instructions if the basic
     mechanism of using the values from the Offset zero fragment is not
     sufficient, e.g. Section 5.3 of [RFC3168] describes how to combine
     the ECN bits from the different fragments to derive the ECN bits of
     the reassembled packet.

And I would be even more happier if we could add a few more words to the =
last sentence:

     ... e.g. Section 5.3 of [RFC3168] describes how to combine
     the ECN bits from the different fragments to derive the ECN bits of
     the reassembled packet such that no congestion indications are =
lost.

Thanks!
Mirja


> Am 21.04.2017 um 04:43 schrieb Suresh Krishnan =
:
>=20
> Hi Mirja/all,
>  Even though I like Bob's suggested text (with David's suggested
> change), I would like to suggest an alternate formulation that is
> generic (with ECN as an example) to see if it works.
>=20
> OLD:
>      Only those headers in the Offset zero fragment packet are =
retained in
>      the reassembled packet.
>=20
> NEW:
>=20
>      Only those headers in the Offset zero fragment packet are =
retained in
>      the reassembled packet. Other fields in the IPv6 header may also
>      vary across the fragments being reassembled. Specifications that
>      use these fields may provide alternate instructions if this basic
>      mechanism of using the values from the Offset zero fragment is =
not
>      sufficient. e.g. Section 5.3 of [RFC3168] describes how to =
combine
>      the ECN bits from the different fragments to derive the ECN bits =
of
>      the reassembled packet.
>=20
> I realize it is a bit verbose but I couldn't shorten it further.
> Thoughts/suggestions?
>=20
> Thanks
> Suresh
>=20
> On Wed, Apr 19, 2017 at 6:44 PM, Mirja Kuehlewind (IETF)
>  wrote:
>> Hi,
>>=20
>> I really don=E2=80=99t like the term "Nodes that support Explicit =
Congestion Notification=E2=80=9C. I guess we understand something =
different under =E2=80=9Esupport=E2=80=9C but maybe can just avoid that =
word to avoid any confusion.
>>=20
>> Thanks,
>> Mirja
>>=20
>>=20
>>> Am 19.04.2017 um 23:47 schrieb Suresh Krishnan =
:
>>>=20
>>> Hi Bob,
>>>=20
>>> On Apr 19, 2017 5:16 PM, "Bob Hinden"  wrote:
>>> Mike,
>>>=20
>>>> On Apr 19, 2017, at 10:54 AM, C. M. Heard  wrote:
>>>>=20
>>>> On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote:
>>>>> This text does not make any normative statement on the question if =
the
>>>>> behavior specified in RFC3168 should be implemented or not. It =
only says
>>>>> please look at RFC3168 and make an informed decision if you want =
to confirm
>>>>> to the behavior that is specified in RFC3168 in addition to =
implementing the
>>>>> spec in this document. However, yes, this statement is true for =
all IPv6
>>>>> implementation. I don't see a problem here...
>>>>=20
>>>> Nor do I. As it happens I prefer the text proposed by Bob Hinden =
(with
>>>> David Black's modification) but I believe that the effect is =
essentially the
>>>> same as the text you proposed. So it seems that the discussion is =
boiling
>>>> down to editorial issues, and I am happy to leave that between you,
>>>> the shepherd, and the document editor.
>>>=20
>>> The current text I have is:
>>>=20
>>>         Nodes that support Explicit Congestion Notification =
[RFC3168]
>>>         use information in the Traffic Class field from all fragment
>>>         packets to reconstruct the Traffic Class field in the
>>>         reassembled packet.  See Section 5.3 of RFC3168 for more
>>>         information.
>>>=20
>>>=20
>>> This looks good to me as well. My only concern with the previous =
version was that it sounded normative.
>>>=20
>>> Regards
>>> Suresh
>>>=20
>>=20
>=20


From nobody Sun Apr 23 14:40:28 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CB4127B31 for ; Sun, 23 Apr 2017 14:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJyD6zfH1euT for ; Sun, 23 Apr 2017 14:40:23 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2453127076 for ; Sun, 23 Apr 2017 14:40:22 -0700 (PDT)
Received: from [192.168.1.121] (p57BB436E.dip0.t-ipconnect.de [87.187.67.110]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 8569F721E280C; Sun, 23 Apr 2017 23:40:18 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Michael Tuexen 
In-Reply-To: <57b16e1e50ec42a0ab23281ddfb8fdf7@mera.ru>
Date: Sun, 23 Apr 2017 23:40:17 +0200
Cc: "tsvwg@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <753E759D-5C3C-426D-9E29-42AB2658EDDB@lurchi.franken.de>
References:    <2831A259-D6D7-4293-ACC7-41433AF7F72F@lurchi.franken.de> <57b16e1e50ec42a0ab23281ddfb8fdf7@mera.ru>
To: "Proshin, Maksim" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Apr 2017 21:40:26 -0000

> On 21. Mar 2017, at 07:16, Proshin, Maksim  wrote:
>=20
> Hi Michael,
>=20
> Basically I'm ok with all your answers and updates.=20
> I don't have any major comments but I have a few proposals below =
inline (by [Maksim] tag).
Hi Maksim,

see my comments below.

Best regards
Michael
>=20
> BR, Maksim
>=20
>=20
> -----Original Message-----
> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20
> Sent: Monday, March 13, 2017 14:00
> To: Proshin, Maksim 
> Cc: tsvwg@ietf.org
> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, =
closes 22 Dec 2016
>=20
>> On 19 Dec 2016, at 17:16, Proshin, Maksim  wrote:
>>=20
>> Hi,
>>=20
>> Thanks for the document! Please find below some comments. Only major =
comments are included while editorial/minor comments have been sent =
directly to Michael.
> Hi Maxim,
>=20
> thanks a lot for the review. I addresses the minor comments and =
responded to your mail.
> See my comments in-line.
>=20
> Best regards
> Michael
>>=20
>> 1. Section 1.1: "DATA chunks are not
>>  permitted when I-DATA support has been negotiated."
>> What exactly does it mean for implementation (both sending and=20
>> receiving sides)? I think to avoid any problems with the sending side=20=

>> it should be "MUST NOT" in the sentence. For the receiving side I=20
>> suppose it means stop processing of the packet and silently discard=20=

>> all further chunks in the packet, right? I think this should be=20
>> clearly stated. It could also be good to clearly state that after=20
>> association
> I think it is clearly stated in 2.2.1:
>=20
> If I-DATA support has been negotiated for an association, I-DATA =
chunks MUST be used for all user messages and DATA-chunks MUST NOT be =
used. If I-DATA support has not been negotiated for an association, DATA =
chunks MUST be used for all user messages and I-DATA chunks MUST NOT be =
used.
>=20
> [Maksim] Ok, I agree that Section 2.2.1 clearly explains it for the =
sender. Can the same be explained for the receiver?
>=20
> So if these rules are violated, I think sending an ABORT with protocol =
violation might be appropriate.
> [Maksim] Ok. Can it be clearly stated (e.g. in 2.2.1)? I mean it would =
be good to state that such case should be
OK. I added to the 'Receiver Side Considerations' the following text:
If I-DATA support has been negotiated for an association, the =
reception of
a DATA chunk is a violation of the above rules and therefore the =
receiver
of the DATA chunk MUST abort the association by sending an ABORT chunk.
The ABORT chunk MAY include the 'Protocol Violation' error cause.
The same applies if I-DATA support has not be negotiated for an =
association
and an I-DATA chunk is received.
> treated as a protocol violation. I also wonder that it should be =
mentioned that the restart case is different and should not be treated =
as a violation.=20
In the restart case the rules apply based on what has been negotiated =
during the restart.
I think this is the general behaviour and is not handled in a special =
way. So I don't we
need to describe this is detail.
>=20
>> restart which was with DATA previously but became with I-DATA after =
the restart, SCTP still may receive packets with DATA and they should be =
silently discarded due to VTag mismatch following the rules of Section =
8.5. from RFC4960 (I suppose this is important to avoid any "protocol =
violation" reaction).=20
> Sure. But this is normal restart behavior.
> [Maksim] The reason I've asked it is because the statement is that =
this is "permitted" while in the restart case it is still possible to =
receive DATA while I-DATA was already negotiated.
So if originally I-DATA support was not negotiated and during the =
restart it was negotiated,
no DATA should be received after the restart. Am I missing something?
>>=20
>> 2. Section 2.1:=20
>> The only differences between the I-DATA chunk in Figure 3 and the
>>  DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the
>>  new Message Identifier (MID) and Fragment Sequence Number (FSN) and
>>  the removal of the Stream Sequence Number (SSN).
>> The B bit now has a different (extended) purpose and also specifies =
if PPID or FSN is used. I think it should be stated.
> OK. I added:
> The Payload Protocol Identifier (PPID) and the FSN are stored at the =
same location of the packet using the B-bit to determine which value is =
stored at the location.
>>=20
>> 3. I suppose the draft assumes that SCTP still MAY (i.e. not =
SHOULD/MUST) support fragmentation even with I-DATA and MUST (i.e. not =
MAY/SHOULD) support re-assembling. If so, I suggest to clearly state it.
> Yes, this hasn't changed. I think we don't need to repeat this point. =
Especially since I have not see an implementation not supporting =
fragmentation...
>>=20
>> 4. Is RFC6096 impacted by new chunks?
> No. It only deals with old chunks. When defining a new chunk, you have =
to define the corresponding flags registry as we do in this document.
>>=20
>> 5. Section 2.3.1: Support for the I-FORWARD-TSN chunk is negotiated =
during the SCTP
>>  association setup via the Supported Extensions Parameter as defined
>>  in [RFC5061].  Only if both end points support the I-DATA chunk and
>>  the I-FORWARD-TSN chunk, the partial reliability extension can be
>>  used in combination with user message interleaving.
>> Not sure how implementation should behave if either of these chunks =
is unsupported. I think it should be clearly stated.
>> Namely if I-DATA is supported but not I-FORWARD-TSN, I believe the =
partial reliability functionality should be completely off, i.e. not =
fallback to FORWARD-TSN.=20
>> If I-DATA is not supported but I-FORWARD-TSN is supported (strange =
implementation but still according to the draft as it does not prohibit =
the opposite), it seems both functionalities message interleaving and =
partial reliability should be off, i.e. there is no way to fallback to =
FORWARD-TSN, right? =20
> Right.
>> Should the draft state something like "If I-DATA chunk is not used, =
I-FORWARD-TSN chunk MUST NOT be used."?
> There is already text there:
>=20
> The FORWARD-TSN chunk MUST be used in combination with the DATA chunk =
and MUST NOT be used in combination with the I-DATA chunk.  The I- =
FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk and =
MUST NOT be used in combination with the DATA chunk.
>>=20
>> 6. Section 4.1:=20
>> MID is 32 bits while SSN is 16 bits so why a new SCTP Receive =
Information Structure cannot be introduced instead of using the existing =
one?
> One could add such a structure, but is it needed? I don't see a =
use-case...
> [Maksim] Isn't the drawback of the current approach is that 16 bits =
are lost?
I don't see why this would be critical...=20
>> If the new SCTP Receive Information Structure is introduced then a =
new message receive function should also be introduced (instead of =
recv_msg() ). Is that the main problem?
> recvmsg() is generic. It doesn't need to be changed. You would add =
another CMSG.
>> Of course, it would also be a problem if the interleaving =
functionality requires enabling only on the sender side (see the next =
comment).
> No, it is required to be enabled on both sides.
>>=20
>>=20
>> 7. Section 4.3.1:
>>  User message interleaving is disabled per default.
>> I'm not sure about it. First of all I think it should be clearly =
stated what does it mean for the sender and for the receiver.
>> If the intention was that I-DATA is included to INIT and INIT ACK =
only when the user enabled this functionality then I think this is not a =
good way because then it impacts not only the sender but also the =
receiver.=20
>> In other words, if the feature is disabled by default on both sides =
while SCTP on both sides support it then it is not enough to just enable =
it on one side, it requires enabling it on the other side. =20
> Exactly. I think this is stated in the first sentence of 2.2.1.
> [Maksim] I think it is not clearly stated in the document. "Supported" =
does not really mean "enabled". I would clearly state that this =
functionality should be enabled on both sides and only in this case it =
could be successfully negotiated. Especially it is important to state =
for the receiver side because Section 2.2.1 has the following statement =
"A sender MUST NOT use the I-DATA chunk unless the user has requested =
its use (e.g. via the socket API, see Section 4.3)."=20
I can change the wording to make sure that I-DATA support is negotiated =
only if both
sides indicated its support. And for each side user consent is required =
to indicate its support
(in case the socket API is used). Would that address your issue?
>>=20
>> 7. Section 4.3.1:  Why don't specify exactly value 1 for the enabled =
feature? Otherwise, in the future it will be difficult to use another =
value of this parameter for a different purpose as it will be =
non-backward compatible (old application and new SCTP may work =
improperly).
> Since it is the standard way of encoding a flag in an int...
>>=20
>> 8. Section 5 does not cover I-FORWARD-TSN.
> Good point. I added corresponding text.
>>=20
>> 9. Section 6: In case of DTLS over SCTP support of the message =
interleaving functionality may increase the risk of receiving messages =
with new epoch after ChangeCipherSpec message and before Finished =
message.
> Possibly. But implementations have to deal with it anyway. So what is =
the point?
> [Maksim] Mainly my point was that it could be clarified so that future =
SCTP implementations of this draft/RFC supporting DTLS could consider =
it.=20
Thinking about it... Why do you think that using I-DATA would increase =
the risk?
Both messages are small and sent back to back. Other messages can =
already be sent
on other streams. So the situation stays the same. Implementations have =
to deal with
this scenario.

Best regards
Michael
>>=20
>>=20
>> BR, Maksim
>>=20
>>> Am 08.12.2016 um 08:36 schrieb gorry@erg.abdn.ac.uk:
>>>=20
>>>=20
>>> This mail announces a TSVWG Working Group Last Call (WGLC) on:
>>>=20
>>>           Stream Schedulers and User Message Interleaving forSCTP
>>>           draft-ietf-tsvwg-sctp-ndata=20
>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata
>>>=20
>>> This WGLC will last for 2 weeks weeks.
>>>=20
>>> Comments should be sent to the tsvwg@ietf.org list, although purely=20=

>>> editorial comments may be sent directly to the authors. Please cc:=20=

>>> the WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs=20=

>>> to track such editorial comments as part of the WGLC process.
>>>=20
>>> No IPR disclosures have been submitted directly on=20
>>> draft-ietf-tsvwg-sctp-ndata.
>>>=20
>>> Thanks,
>>> Gorry
>>> (TSVWG Co-Chair)
>=20


From nobody Sun Apr 23 20:31:14 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B98D126557; Sun, 23 Apr 2017 20:30:58 -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, FREEMAIL_FROM=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=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 EEay_E0tOj_O; Sun, 23 Apr 2017 20:30:57 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70EB126DD9; Sun, 23 Apr 2017 20:30:56 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id c45so103954130qtb.1; Sun, 23 Apr 2017 20:30:56 -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:content-transfer-encoding; bh=NMZ0R8BiOLkgJFIA2GeWAnAxmRbXZ4slGvzf04j3ZIs=; b=bT+E/s19CPyuRtAoS2KAfGc8VaebMGn/xy/H23H062Fky2jBLINpcWGStq+ANHUF9p mhIJ0nrdgRfBsH7urstmb+i3G10Gi75fd8oNV8VvNEF25MVKGth3WiywWGCGsSb+/g/L SQrSoGCjxkqYscOME8XwAXLyGBiT/G332wJ29Seu5Hxq5WA8ciM/DO0yktB1AICBoJrx FQpO5DyCGsy0vC4+ZwyyxvxKk56KhYrox6r2gmt8g56Spxn8GPAnjAN+O1rp7L7Zc7VX 7TlLhvQuzXG2sAx4cWRZryEnD/PxNF+3rAp4oexSeurFQ4B6Lv6OJJUKBLD7wzYo7YKB 3hug==
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=NMZ0R8BiOLkgJFIA2GeWAnAxmRbXZ4slGvzf04j3ZIs=; b=sfnyiPpnVydRdfPsDiIo5c2G9kGyag9VyxtBMgaGmGIVMJveDfb5m0+k90IQ0MyJ8D /02AzpVaYD9yTZ5cWY1VS6/+AJZ5poHbOrV/XoT/sK60ZMMWafI7up1qtUwJHvDEUG/D ixA+N1WhgInh0m6DxRGAunJ3gOBGeNCp4y45TpiTuNnzLWrLJ+PwFNTFiJVLunfQvxw4 F/IjsDo2XXS0DYlUB8Mg9ELGasorV1Z+t1eHnZBtRuNvpx2/dm349m00/VYZXq/TSjii H9XPpV3cKkjaVhwmKrTPriAeoSL23TqHYCmyWHlYM5rlNtpC/K27pyNNYSItOKmiScLP ZaLw==
X-Gm-Message-State: AN3rC/7YlkmmSEl3dtaONMgZ7jDzW50y8zgMajiM0NBIWkh1kR50Mbjm IEDIDW4b4IcbCUfogTi65KmZeCo7Hw==
X-Received: by 10.200.37.16 with SMTP id 16mr25654315qtm.293.1493004655904; Sun, 23 Apr 2017 20:30:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.166.130 with HTTP; Sun, 23 Apr 2017 20:30:55 -0700 (PDT)
In-Reply-To: <4DA7A0B2-AA3C-4E98-95FC-45A3CA5FC1F2@kuehlewind.net>
References:  <4DA7A0B2-AA3C-4E98-95FC-45A3CA5FC1F2@kuehlewind.net>
From: Suresh Krishnan 
Date: Sun, 23 Apr 2017 23:30:55 -0400
Message-ID: 
To: "Mirja Kuehlewind (IETF)" 
Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>,  tsvwg , "C. M. Heard" , Bob Hinden ,  IESG , 6man-chairs@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?ECN_and_fragments_=28was_Re=3A__Mirja_K=C3=BCh?= =?utf-8?q?lewind=27s_Discuss_on_draft-ietf-6man-rfc2460bis-09=3A_=28with_?= =?utf-8?q?DISCUSS_and_COMMENT=29=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Apr 2017 03:30:58 -0000

On Sat, Apr 22, 2017 at 7:57 AM, Mirja Kuehlewind (IETF)
 wrote:
> Hi Suresh,
>
> thanks this text is fine for me.
>
> I=E2=80=99d like propose three tiny editorial only changes/nits:
> s/Other/Further,/
> s/this basic/the basic/
> s/sufficient. e.g./sufficient, e.g./

Thanks Mirja. These edits all seem fine.

>
>      Only those headers in the Offset zero fragment packet are retained i=
n
>      the reassembled packet. Further, fields in the IPv6 header may also
>      vary across the fragments being reassembled. Specifications that
>      use these fields may provide alternate instructions if the basic
>      mechanism of using the values from the Offset zero fragment is not
>      sufficient, e.g. Section 5.3 of [RFC3168] describes how to combine
>      the ECN bits from the different fragments to derive the ECN bits of
>      the reassembled packet.
>
> And I would be even more happier if we could add a few more words to the =
last sentence:
>
>      ... e.g. Section 5.3 of [RFC3168] describes how to combine
>      the ECN bits from the different fragments to derive the ECN bits of
>      the reassembled packet such that no congestion indications are lost.

This is not strictly true. If any of the fragments carries the not-ECT
codepoint, congestion indications will be lost (according to RFC3168),
but my earlier proposed text still works. So if you don't care
strongly about it, I would prefer keeping the old text.

Regards
Suresh


From nobody Mon Apr 24 05:05:49 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3878D1314DA for ; Mon, 24 Apr 2017 05:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 Bn9iQjvvMb_m for ; Mon, 24 Apr 2017 05:05:45 -0700 (PDT)
Received: from mail.mera.ru (mail.mera.ru [195.98.57.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0871314D7 for ; Mon, 24 Apr 2017 05:05:44 -0700 (PDT)
Received: from mbx03.merann.ru ([192.168.50.73]) by mail.mera.ru with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1d2ci0-000Fyj-37; Mon, 24 Apr 2017 15:03:12 +0300
Received: from e16srv03.merann.ru (192.168.50.33) by mbx03.merann.ru (192.168.50.73) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 24 Apr 2017 15:05:41 +0300
Received: from e16srv03.merann.ru (2001:67c:2344:50:38b3:8b2:2b76:7a66) by e16srv03.merann.ru (2001:67c:2344:50:38b3:8b2:2b76:7a66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Mon, 24 Apr 2017 15:05:41 +0300
Received: from e16srv03.merann.ru ([fe80::38b3:8b2:2b76:7a66]) by e16srv03.merann.ru ([fe80::38b3:8b2:2b76:7a66%12]) with mapi id 15.01.0845.034; Mon, 24 Apr 2017 15:05:41 +0300
From: "Proshin, Maksim" 
To: Michael Tuexen 
CC: "tsvwg@ietf.org" 
Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016
Thread-Index: AQHSWgChCkg2HCaxb0Ww0RyyFOJkOaEPTU0BgIOeMwCAC2VfkIA1vTqAgAEe/MA=
Date: Mon, 24 Apr 2017 12:05:41 +0000
Message-ID: 
References:    <2831A259-D6D7-4293-ACC7-41433AF7F72F@lurchi.franken.de> <57b16e1e50ec42a0ab23281ddfb8fdf7@mera.ru> <753E759D-5C3C-426D-9E29-42AB2658EDDB@lurchi.franken.de>
In-Reply-To: <753E759D-5C3C-426D-9E29-42AB2658EDDB@lurchi.franken.de>
Accept-Language: en-US, ru-RU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.201.113]
x-inside-org: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Apr 2017 12:05:48 -0000

Hi Michael,

I'm ok with your proposals. I've answered your questions below inline.

Best regards,
Maksim

-----Original Message-----
From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20
Sent: Monday, April 24, 2017 00:40
To: Proshin, Maksim 
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 =
Dec 2016

> On 21. Mar 2017, at 07:16, Proshin, Maksim  wrote:
>=20
> Hi Michael,
>=20
> Basically I'm ok with all your answers and updates.=20
> I don't have any major comments but I have a few proposals below inline (=
by [Maksim] tag).
Hi Maksim,

see my comments below.

Best regards
Michael
>=20
> BR, Maksim
>=20
>=20
> -----Original Message-----
> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
> Sent: Monday, March 13, 2017 14:00
> To: Proshin, Maksim 
> Cc: tsvwg@ietf.org
> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS,=20
> closes 22 Dec 2016
>=20
>> On 19 Dec 2016, at 17:16, Proshin, Maksim  wrote:
>>=20
>> Hi,
>>=20
>> Thanks for the document! Please find below some comments. Only major com=
ments are included while editorial/minor comments have been sent directly t=
o Michael.
> Hi Maxim,
>=20
> thanks a lot for the review. I addresses the minor comments and responded=
 to your mail.
> See my comments in-line.
>=20
> Best regards
> Michael
>>=20
>> 1. Section 1.1: "DATA chunks are not
>>  permitted when I-DATA support has been negotiated."
>> What exactly does it mean for implementation (both sending and=20
>> receiving sides)? I think to avoid any problems with the sending side=20
>> it should be "MUST NOT" in the sentence. For the receiving side I=20
>> suppose it means stop processing of the packet and silently discard=20
>> all further chunks in the packet, right? I think this should be=20
>> clearly stated. It could also be good to clearly state that after=20
>> association
> I think it is clearly stated in 2.2.1:
>=20
> If I-DATA support has been negotiated for an association, I-DATA chunks M=
UST be used for all user messages and DATA-chunks MUST NOT be used. If I-DA=
TA support has not been negotiated for an association, DATA chunks MUST be =
used for all user messages and I-DATA chunks MUST NOT be used.
>=20
> [Maksim] Ok, I agree that Section 2.2.1 clearly explains it for the sende=
r. Can the same be explained for the receiver?
>=20
> So if these rules are violated, I think sending an ABORT with protocol vi=
olation might be appropriate.
> [Maksim] Ok. Can it be clearly stated (e.g. in 2.2.1)? I mean it would=20
> be good to state that such case should be
OK. I added to the 'Receiver Side Considerations' the following text:
If I-DATA support has been negotiated for an association, the reception =
of a DATA chunk is a violation of the above rules and therefore the receive=
r of the DATA chunk MUST abort the association by sending an ABORT chunk.
The ABORT chunk MAY include the 'Protocol Violation' error cause.
The same applies if I-DATA support has not be negotiated for an association=
 and an I-DATA chunk is received.
[Maksim] Ok with me!

> treated as a protocol violation. I also wonder that it should be mentione=
d that the restart case is different and should not be treated as a violati=
on.=20
In the restart case the rules apply based on what has been negotiated durin=
g the restart.
I think this is the general behaviour and is not handled in a special way. =
So I don't we need to describe this is detail.
[Maksim] Ok, keep it as it is. Please also see below.

>=20
>> restart which was with DATA previously but became with I-DATA after the =
restart, SCTP still may receive packets with DATA and they should be silent=
ly discarded due to VTag mismatch following the rules of Section 8.5. from =
RFC4960 (I suppose this is important to avoid any "protocol violation" reac=
tion).=20
> Sure. But this is normal restart behavior.
> [Maksim] The reason I've asked it is because the statement is that this i=
s "permitted" while in the restart case it is still possible to receive DAT=
A while I-DATA was already negotiated.
So if originally I-DATA support was not negotiated and during the restart i=
t was negotiated, no DATA should be received after the restart. Am I missin=
g something?
[Maksim] I meant the case when stale DATA is received, e.g. due to reorderi=
ng. In this case it will be still the same association but with I-DATA supp=
ort and new VTags and such DATA should be silently discarded according to V=
Tag rules and not treated as protocol violation. This is what I proposed to=
 be clarified but I don't really insist.

>>=20
>> 2. Section 2.1:=20
>> The only differences between the I-DATA chunk in Figure 3 and the =20
>> DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the =20
>> new Message Identifier (MID) and Fragment Sequence Number (FSN) and =20
>> the removal of the Stream Sequence Number (SSN).
>> The B bit now has a different (extended) purpose and also specifies if P=
PID or FSN is used. I think it should be stated.
> OK. I added:
> The Payload Protocol Identifier (PPID) and the FSN are stored at the same=
 location of the packet using the B-bit to determine which value is stored =
at the location.
>>=20
>> 3. I suppose the draft assumes that SCTP still MAY (i.e. not SHOULD/MUST=
) support fragmentation even with I-DATA and MUST (i.e. not MAY/SHOULD) sup=
port re-assembling. If so, I suggest to clearly state it.
> Yes, this hasn't changed. I think we don't need to repeat this point. Esp=
ecially since I have not see an implementation not supporting fragmentation=
...
>>=20
>> 4. Is RFC6096 impacted by new chunks?
> No. It only deals with old chunks. When defining a new chunk, you have to=
 define the corresponding flags registry as we do in this document.
>>=20
>> 5. Section 2.3.1: Support for the I-FORWARD-TSN chunk is negotiated=20
>> during the SCTP  association setup via the Supported Extensions=20
>> Parameter as defined  in [RFC5061].  Only if both end points support=20
>> the I-DATA chunk and  the I-FORWARD-TSN chunk, the partial=20
>> reliability extension can be  used in combination with user message inte=
rleaving.
>> Not sure how implementation should behave if either of these chunks is u=
nsupported. I think it should be clearly stated.
>> Namely if I-DATA is supported but not I-FORWARD-TSN, I believe the parti=
al reliability functionality should be completely off, i.e. not fallback to=
 FORWARD-TSN.=20
>> If I-DATA is not supported but I-FORWARD-TSN is supported (strange imple=
mentation but still according to the draft as it does not prohibit the oppo=
site), it seems both functionalities message interleaving and partial relia=
bility should be off, i.e. there is no way to fallback to FORWARD-TSN, righ=
t? =20
> Right.
>> Should the draft state something like "If I-DATA chunk is not used, I-FO=
RWARD-TSN chunk MUST NOT be used."?
> There is already text there:
>=20
> The FORWARD-TSN chunk MUST be used in combination with the DATA chunk and=
 MUST NOT be used in combination with the I-DATA chunk.  The I- FORWARD-TSN=
 chunk MUST be used in combination with the I-DATA chunk and MUST NOT be us=
ed in combination with the DATA chunk.
>>=20
>> 6. Section 4.1:=20
>> MID is 32 bits while SSN is 16 bits so why a new SCTP Receive Informatio=
n Structure cannot be introduced instead of using the existing one?
> One could add such a structure, but is it needed? I don't see a use-case.=
..
> [Maksim] Isn't the drawback of the current approach is that 16 bits are l=
ost?
I don't see why this would be critical...=20
[Maksim] Perhaps it depends on how the MID value is used by the application=
. When SCTP implementation reports just a half of MID, it actually means th=
at another value is reported, isn't it? Then it means that we have two diff=
erent values: one on the application level and the other one on the SCTP le=
vel which might be a problem for e.g. troubleshooting. I understand that it=
 is too late to change the concept but I wonder if the drawback (if there i=
s really a drawback) is mentioned in the draft.

>> If the new SCTP Receive Information Structure is introduced then a new m=
essage receive function should also be introduced (instead of recv_msg() ).=
 Is that the main problem?
> recvmsg() is generic. It doesn't need to be changed. You would add anothe=
r CMSG.
>> Of course, it would also be a problem if the interleaving functionality =
requires enabling only on the sender side (see the next comment).
> No, it is required to be enabled on both sides.
>>=20
>>=20
>> 7. Section 4.3.1:
>>  User message interleaving is disabled per default.
>> I'm not sure about it. First of all I think it should be clearly stated =
what does it mean for the sender and for the receiver.
>> If the intention was that I-DATA is included to INIT and INIT ACK only w=
hen the user enabled this functionality then I think this is not a good way=
 because then it impacts not only the sender but also the receiver.=20
>> In other words, if the feature is disabled by default on both sides whil=
e SCTP on both sides support it then it is not enough to just enable it on =
one side, it requires enabling it on the other side. =20
> Exactly. I think this is stated in the first sentence of 2.2.1.
> [Maksim] I think it is not clearly stated in the document. "Supported" do=
es not really mean "enabled". I would clearly state that this functionality=
 should be enabled on both sides and only in this case it could be successf=
ully negotiated. Especially it is important to state for the receiver side =
because Section 2.2.1 has the following statement "A sender MUST NOT use th=
e I-DATA chunk unless the user has requested its use (e.g. via the socket A=
PI, see Section 4.3)."=20
I can change the wording to make sure that I-DATA support is negotiated onl=
y if both sides indicated its support. And for each side user consent is re=
quired to indicate its support (in case the socket API is used). Would that=
 address your issue?
[Maksim] Yes!

>>=20
>> 7. Section 4.3.1:  Why don't specify exactly value 1 for the enabled fea=
ture? Otherwise, in the future it will be difficult to use another value of=
 this parameter for a different purpose as it will be non-backward compatib=
le (old application and new SCTP may work improperly).
> Since it is the standard way of encoding a flag in an int...
>>=20
>> 8. Section 5 does not cover I-FORWARD-TSN.
> Good point. I added corresponding text.
>>=20
>> 9. Section 6: In case of DTLS over SCTP support of the message interleav=
ing functionality may increase the risk of receiving messages with new epoc=
h after ChangeCipherSpec message and before Finished message.
> Possibly. But implementations have to deal with it anyway. So what is the=
 point?
> [Maksim] Mainly my point was that it could be clarified so that future SC=
TP implementations of this draft/RFC supporting DTLS could consider it.=20
Thinking about it... Why do you think that using I-DATA would increase the =
risk?
Both messages are small and sent back to back. Other messages can already b=
e sent on other streams. So the situation stays the same. Implementations h=
ave to deal with this scenario.
[Maksim] Ok, I don't insist to clarify it.=20

Best regards
Michael
>>=20
>>=20
>> BR, Maksim
>>=20
>>> Am 08.12.2016 um 08:36 schrieb gorry@erg.abdn.ac.uk:
>>>=20
>>>=20
>>> This mail announces a TSVWG Working Group Last Call (WGLC) on:
>>>=20
>>>           Stream Schedulers and User Message Interleaving forSCTP
>>>           draft-ietf-tsvwg-sctp-ndata=20
>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata
>>>=20
>>> This WGLC will last for 2 weeks weeks.
>>>=20
>>> Comments should be sent to the tsvwg@ietf.org list, although purely=20
>>> editorial comments may be sent directly to the authors. Please cc:
>>> the WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs=20
>>> to track such editorial comments as part of the WGLC process.
>>>=20
>>> No IPR disclosures have been submitted directly on=20
>>> draft-ietf-tsvwg-sctp-ndata.
>>>=20
>>> Thanks,
>>> Gorry
>>> (TSVWG Co-Chair)
>=20


From nobody Mon Apr 24 07:53:06 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2DC13160A for ; Mon, 24 Apr 2017 07:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level: 
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 bOkvqLFiZMlC for ; Mon, 24 Apr 2017 07:53:02 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175A8131631 for ; Mon, 24 Apr 2017 07:51:20 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 5CE4BB80DF9; Mon, 24 Apr 2017 07:50:59 -0700 (PDT)
To: randall@lakerest.net, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net,  david.black@emc.com, gorry@erg.abdn.ac.uk, wes@mti-systems.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: maxbot1539@gmail.com, tsvwg@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170424145059.5CE4BB80DF9@rfc-editor.org>
Date: Mon, 24 Apr 2017 07:50:59 -0700 (PDT)
Archived-At: 
Subject: [tsvwg] [Editorial Errata Reported] RFC4960 (5003)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Apr 2017 14:53:04 -0000

The following errata report has been submitted for RFC4960,
"Stream Control Transmission Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4960&eid=5003

--------------------------------------
Type: Editorial
Reported by: Max Mattes 

Section: 10.1

Original Text
-------------
   o  Receive Unacknowledged Message

      Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
              size, [,stream id] [, stream sequence number] [,partial
              flag] [,payload protocol-id])

Corrected Text
--------------
   O) Receive Unacknowledged Message

      Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
              size, [,stream id] [, stream sequence number] [,partial
              flag] [,payload protocol-id])

Notes
-----
This is part of a lettered list of items, and surrounding sublists use lowercase "o" as a bullet. This item appears to have been mis-corrected to an "o" sublist item when it should be item "O)" of the primary list, as evidenced by the preceding item "N)" and following "P)"

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4960 (draft-ietf-tsvwg-2960bis-05)
--------------------------------------
Title               : Stream Control Transmission Protocol
Publication Date    : September 2007
Author(s)           : R. Stewart, Ed.
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG


From nobody Mon Apr 24 11:01:09 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBAB131905 for ; Mon, 24 Apr 2017 11:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 6v-6P58kBTkp for ; Mon, 24 Apr 2017 11:01:05 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F75131901 for ; Mon, 24 Apr 2017 11:01:05 -0700 (PDT)
Received: from [IPv6:2003:cd:6bd7:7400:889:75a1:d2a0:758f] (p200300CD6BD77400088975A1D2A0758F.dip0.t-ipconnect.de [IPv6:2003:cd:6bd7:7400:889:75a1:d2a0:758f]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id C35B6721E281E; Mon, 24 Apr 2017 20:01:00 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Michael Tuexen 
In-Reply-To: <20170424145059.5CE4BB80DF9@rfc-editor.org>
Date: Mon, 24 Apr 2017 20:00:59 +0200
Cc: randall , Spencer Dawkins at IETF , "Mirja Kuehlewind (IETF)" , "Black, David" , Gorry Fairhurst , wes@mti-systems.com, maxbot1539@gmail.com, tsvwg IETF list 
Content-Transfer-Encoding: quoted-printable
Message-Id: <53E2F4A6-DE41-451A-98D3-C9B5659DF87E@lurchi.franken.de>
References: <20170424145059.5CE4BB80DF9@rfc-editor.org>
To: RFC Errata System 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [tsvwg] [Editorial Errata Reported] RFC4960 (5003)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Apr 2017 18:01:08 -0000

> On 24. Apr 2017, at 16:50, RFC Errata System =
 wrote:
>=20
> The following errata report has been submitted for RFC4960,
> "Stream Control Transmission Protocol".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D4960&eid=3D5003
>=20
> --------------------------------------
> Type: Editorial
> Reported by: Max Mattes 
>=20
> Section: 10.1
>=20
> Original Text
> -------------
>   o  Receive Unacknowledged Message
>=20
>      Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
>              size, [,stream id] [, stream sequence number] [,partial
>              flag] [,payload protocol-id])
>=20
> Corrected Text
> --------------
>   O) Receive Unacknowledged Message
>=20
>      Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
>              size, [,stream id] [, stream sequence number] [,partial
>              flag] [,payload protocol-id])
>=20
> Notes
> -----
> This is part of a lettered list of items, and surrounding sublists use =
lowercase "o" as a bullet. This item appears to have been mis-corrected =
to an "o" sublist item when it should be item "O)" of the primary list, =
as evidenced by the preceding item "N)" and following "P)"
This is correct and already covered in
=
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-01#section-3.9=


Best regards
Michael
>=20
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party =20
> can log in to change the status and edit the report, if necessary.=20
>=20
> --------------------------------------
> RFC4960 (draft-ietf-tsvwg-2960bis-05)
> --------------------------------------
> Title               : Stream Control Transmission Protocol
> Publication Date    : September 2007
> Author(s)           : R. Stewart, Ed.
> Category            : PROPOSED STANDARD
> Source              : Transport Area Working Group
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG
>=20


From nobody Mon Apr 24 12:19:08 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131A8128B88 for ; Mon, 24 Apr 2017 12:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 sCqhIjYC1R1r for ; Mon, 24 Apr 2017 12:19:01 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BD3129466 for ; Mon, 24 Apr 2017 12:18:59 -0700 (PDT)
Received: from [IPv6:2003:cd:6bd7:7400:889:75a1:d2a0:758f] (p200300CD6BD77400088975A1D2A0758F.dip0.t-ipconnect.de [IPv6:2003:cd:6bd7:7400:889:75a1:d2a0:758f]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 7B184721E281A; Mon, 24 Apr 2017 21:18:56 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Michael Tuexen 
In-Reply-To: 
Date: Mon, 24 Apr 2017 21:18:55 +0200
Cc: "tsvwg@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <2831A259-D6D7-4293-ACC7-41433AF7F72F@lurchi.franken.de> <57b16e1e50ec42a0ab23281ddfb8fdf7@mera.ru> <753E759D-5C3C-426D-9E29-42AB2658EDDB@lurchi.franken.de> 
To: "Proshin, Maksim" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Apr 2017 19:19:05 -0000

> On 24. Apr 2017, at 14:05, Proshin, Maksim  wrote:
>=20
> Hi Michael,
>=20
> I'm ok with your proposals. I've answered your questions below inline.
Comments in-line.

Best regards
Michael
>=20
> Best regards,
> Maksim
>=20
> -----Original Message-----
> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20
> Sent: Monday, April 24, 2017 00:40
> To: Proshin, Maksim 
> Cc: tsvwg@ietf.org
> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, =
closes 22 Dec 2016
>=20
>> On 21. Mar 2017, at 07:16, Proshin, Maksim  wrote:
>>=20
>> Hi Michael,
>>=20
>> Basically I'm ok with all your answers and updates.=20
>> I don't have any major comments but I have a few proposals below =
inline (by [Maksim] tag).
> Hi Maksim,
>=20
> see my comments below.
>=20
> Best regards
> Michael
>>=20
>> BR, Maksim
>>=20
>>=20
>> -----Original Message-----
>> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>> Sent: Monday, March 13, 2017 14:00
>> To: Proshin, Maksim 
>> Cc: tsvwg@ietf.org
>> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS,=20
>> closes 22 Dec 2016
>>=20
>>> On 19 Dec 2016, at 17:16, Proshin, Maksim  wrote:
>>>=20
>>> Hi,
>>>=20
>>> Thanks for the document! Please find below some comments. Only major =
comments are included while editorial/minor comments have been sent =
directly to Michael.
>> Hi Maxim,
>>=20
>> thanks a lot for the review. I addresses the minor comments and =
responded to your mail.
>> See my comments in-line.
>>=20
>> Best regards
>> Michael
>>>=20
>>> 1. Section 1.1: "DATA chunks are not
>>> permitted when I-DATA support has been negotiated."
>>> What exactly does it mean for implementation (both sending and=20
>>> receiving sides)? I think to avoid any problems with the sending =
side=20
>>> it should be "MUST NOT" in the sentence. For the receiving side I=20
>>> suppose it means stop processing of the packet and silently discard=20=

>>> all further chunks in the packet, right? I think this should be=20
>>> clearly stated. It could also be good to clearly state that after=20
>>> association
>> I think it is clearly stated in 2.2.1:
>>=20
>> If I-DATA support has been negotiated for an association, I-DATA =
chunks MUST be used for all user messages and DATA-chunks MUST NOT be =
used. If I-DATA support has not been negotiated for an association, DATA =
chunks MUST be used for all user messages and I-DATA chunks MUST NOT be =
used.
>>=20
>> [Maksim] Ok, I agree that Section 2.2.1 clearly explains it for the =
sender. Can the same be explained for the receiver?
>>=20
>> So if these rules are violated, I think sending an ABORT with =
protocol violation might be appropriate.
>> [Maksim] Ok. Can it be clearly stated (e.g. in 2.2.1)? I mean it =
would=20
>> be good to state that such case should be
> OK. I added to the 'Receiver Side Considerations' the following text:
> If I-DATA support has been negotiated for an association, the =
reception of a DATA chunk is a violation of the above rules and =
therefore the receiver of the DATA chunk MUST abort the association by =
sending an ABORT chunk.
> The ABORT chunk MAY include the 'Protocol Violation' error cause.
> The same applies if I-DATA support has not be negotiated for an =
association and an I-DATA chunk is received.
> [Maksim] Ok with me!
>=20
>> treated as a protocol violation. I also wonder that it should be =
mentioned that the restart case is different and should not be treated =
as a violation.=20
> In the restart case the rules apply based on what has been negotiated =
during the restart.
> I think this is the general behaviour and is not handled in a special =
way. So I don't we need to describe this is detail.
> [Maksim] Ok, keep it as it is. Please also see below.
>=20
>>=20
>>> restart which was with DATA previously but became with I-DATA after =
the restart, SCTP still may receive packets with DATA and they should be =
silently discarded due to VTag mismatch following the rules of Section =
8.5. from RFC4960 (I suppose this is important to avoid any "protocol =
violation" reaction).=20
>> Sure. But this is normal restart behavior.
>> [Maksim] The reason I've asked it is because the statement is that =
this is "permitted" while in the restart case it is still possible to =
receive DATA while I-DATA was already negotiated.
> So if originally I-DATA support was not negotiated and during the =
restart it was negotiated, no DATA should be received after the restart. =
Am I missing something?
> [Maksim] I meant the case when stale DATA is received, e.g. due to =
reordering. In this case it will be still the same association but with =
I-DATA support and new VTags and such DATA should be silently discarded =
according to VTag rules and not treated as protocol violation. This is =
what I proposed to be clarified but I don't really insist.
OK I see. But I think this is covered. The rules for association lookup =
and checking the verification tag are done
before the chunk processing. So I think we don't need to cover that.
>=20
>>>=20
>>> 2. Section 2.1:=20
>>> The only differences between the I-DATA chunk in Figure 3 and the =20=

>>> DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the =
=20
>>> new Message Identifier (MID) and Fragment Sequence Number (FSN) and =20=

>>> the removal of the Stream Sequence Number (SSN).
>>> The B bit now has a different (extended) purpose and also specifies =
if PPID or FSN is used. I think it should be stated.
>> OK. I added:
>> The Payload Protocol Identifier (PPID) and the FSN are stored at the =
same location of the packet using the B-bit to determine which value is =
stored at the location.
>>>=20
>>> 3. I suppose the draft assumes that SCTP still MAY (i.e. not =
SHOULD/MUST) support fragmentation even with I-DATA and MUST (i.e. not =
MAY/SHOULD) support re-assembling. If so, I suggest to clearly state it.
>> Yes, this hasn't changed. I think we don't need to repeat this point. =
Especially since I have not see an implementation not supporting =
fragmentation...
>>>=20
>>> 4. Is RFC6096 impacted by new chunks?
>> No. It only deals with old chunks. When defining a new chunk, you =
have to define the corresponding flags registry as we do in this =
document.
>>>=20
>>> 5. Section 2.3.1: Support for the I-FORWARD-TSN chunk is negotiated=20=

>>> during the SCTP  association setup via the Supported Extensions=20
>>> Parameter as defined  in [RFC5061].  Only if both end points support=20=

>>> the I-DATA chunk and  the I-FORWARD-TSN chunk, the partial=20
>>> reliability extension can be  used in combination with user message =
interleaving.
>>> Not sure how implementation should behave if either of these chunks =
is unsupported. I think it should be clearly stated.
>>> Namely if I-DATA is supported but not I-FORWARD-TSN, I believe the =
partial reliability functionality should be completely off, i.e. not =
fallback to FORWARD-TSN.=20
>>> If I-DATA is not supported but I-FORWARD-TSN is supported (strange =
implementation but still according to the draft as it does not prohibit =
the opposite), it seems both functionalities message interleaving and =
partial reliability should be off, i.e. there is no way to fallback to =
FORWARD-TSN, right? =20
>> Right.
>>> Should the draft state something like "If I-DATA chunk is not used, =
I-FORWARD-TSN chunk MUST NOT be used."?
>> There is already text there:
>>=20
>> The FORWARD-TSN chunk MUST be used in combination with the DATA chunk =
and MUST NOT be used in combination with the I-DATA chunk.  The I- =
FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk and =
MUST NOT be used in combination with the DATA chunk.
>>>=20
>>> 6. Section 4.1:=20
>>> MID is 32 bits while SSN is 16 bits so why a new SCTP Receive =
Information Structure cannot be introduced instead of using the existing =
one?
>> One could add such a structure, but is it needed? I don't see a =
use-case...
>> [Maksim] Isn't the drawback of the current approach is that 16 bits =
are lost?
> I don't see why this would be critical...=20
> [Maksim] Perhaps it depends on how the MID value is used by the =
application. When SCTP implementation reports just a half of MID, it =
actually means that another value is reported, isn't it? Then it means =
that we have two different=20
Yes, the lower 16 bits. It is easy to get from the MID the value being =
reported.
Just as if DATA chunk would be used.
> values: one on the application level and the other one on the SCTP =
level which might be a problem for e.g. troubleshooting. I understand =
that it is too late to change the concept but I wonder if the drawback =
(if there is really a drawback) is mentioned in the draft.
I don't see a problem...
>=20
>>> If the new SCTP Receive Information Structure is introduced then a =
new message receive function should also be introduced (instead of =
recv_msg() ). Is that the main problem?
>> recvmsg() is generic. It doesn't need to be changed. You would add =
another CMSG.
>>> Of course, it would also be a problem if the interleaving =
functionality requires enabling only on the sender side (see the next =
comment).
>> No, it is required to be enabled on both sides.
>>>=20
>>>=20
>>> 7. Section 4.3.1:
>>> User message interleaving is disabled per default.
>>> I'm not sure about it. First of all I think it should be clearly =
stated what does it mean for the sender and for the receiver.
>>> If the intention was that I-DATA is included to INIT and INIT ACK =
only when the user enabled this functionality then I think this is not a =
good way because then it impacts not only the sender but also the =
receiver.=20
>>> In other words, if the feature is disabled by default on both sides =
while SCTP on both sides support it then it is not enough to just enable =
it on one side, it requires enabling it on the other side. =20
>> Exactly. I think this is stated in the first sentence of 2.2.1.
>> [Maksim] I think it is not clearly stated in the document. =
"Supported" does not really mean "enabled". I would clearly state that =
this functionality should be enabled on both sides and only in this case =
it could be successfully negotiated. Especially it is important to state =
for the receiver side because Section 2.2.1 has the following statement =
"A sender MUST NOT use the I-DATA chunk unless the user has requested =
its use (e.g. via the socket API, see Section 4.3)."=20
> I can change the wording to make sure that I-DATA support is =
negotiated only if both sides indicated its support. And for each side =
user consent is required to indicate its support (in case the socket API =
is used). Would that address your issue?
> [Maksim] Yes!
OK. Will do.
>=20
>>>=20
>>> 7. Section 4.3.1:  Why don't specify exactly value 1 for the enabled =
feature? Otherwise, in the future it will be difficult to use another =
value of this parameter for a different purpose as it will be =
non-backward compatible (old application and new SCTP may work =
improperly).
>> Since it is the standard way of encoding a flag in an int...
>>>=20
>>> 8. Section 5 does not cover I-FORWARD-TSN.
>> Good point. I added corresponding text.
>>>=20
>>> 9. Section 6: In case of DTLS over SCTP support of the message =
interleaving functionality may increase the risk of receiving messages =
with new epoch after ChangeCipherSpec message and before Finished =
message.
>> Possibly. But implementations have to deal with it anyway. So what is =
the point?
>> [Maksim] Mainly my point was that it could be clarified so that =
future SCTP implementations of this draft/RFC supporting DTLS could =
consider it.=20
> Thinking about it... Why do you think that using I-DATA would increase =
the risk?
> Both messages are small and sent back to back. Other messages can =
already be sent on other streams. So the situation stays the same. =
Implementations have to deal with this scenario.
> [Maksim] Ok, I don't insist to clarify it.=20
OK. I'll submit a new revision.

Thanks for the feedback.

Best regards
Michael
>=20
> Best regards
> Michael
>>>=20
>>>=20
>>> BR, Maksim
>>>=20
>>>> Am 08.12.2016 um 08:36 schrieb gorry@erg.abdn.ac.uk:
>>>>=20
>>>>=20
>>>> This mail announces a TSVWG Working Group Last Call (WGLC) on:
>>>>=20
>>>>          Stream Schedulers and User Message Interleaving forSCTP
>>>>          draft-ietf-tsvwg-sctp-ndata=20
>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata
>>>>=20
>>>> This WGLC will last for 2 weeks weeks.
>>>>=20
>>>> Comments should be sent to the tsvwg@ietf.org list, although purely=20=

>>>> editorial comments may be sent directly to the authors. Please cc:
>>>> the WG chairs at tsvwg-chairs@ietf.org  if you would like the =
chairs=20
>>>> to track such editorial comments as part of the WGLC process.
>>>>=20
>>>> No IPR disclosures have been submitted directly on=20
>>>> draft-ietf-tsvwg-sctp-ndata.
>>>>=20
>>>> Thanks,
>>>> Gorry
>>>> (TSVWG Co-Chair)
>>=20
>=20


From nobody Mon Apr 24 22:55:33 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91771319C8 for ; Mon, 24 Apr 2017 22:55:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0NItKk9BRY0 for ; Mon, 24 Apr 2017 22:55:28 -0700 (PDT)
Received: from mail.mera.ru (mail.mera.ru [195.98.57.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC011319C4 for ; Mon, 24 Apr 2017 22:55:26 -0700 (PDT)
Received: from mbx03.merann.ru ([192.168.50.73]) by mail.mera.ru with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1d2tP6-000G43-0f; Tue, 25 Apr 2017 08:52:48 +0300
Received: from e16srv03.merann.ru (192.168.50.33) by mbx03.merann.ru (192.168.50.73) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 25 Apr 2017 08:55:19 +0300
Received: from e16srv03.merann.ru (2001:67c:2344:50:38b3:8b2:2b76:7a66) by e16srv03.merann.ru (2001:67c:2344:50:38b3:8b2:2b76:7a66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Tue, 25 Apr 2017 08:55:18 +0300
Received: from e16srv03.merann.ru ([fe80::38b3:8b2:2b76:7a66]) by e16srv03.merann.ru ([fe80::38b3:8b2:2b76:7a66%12]) with mapi id 15.01.0845.034; Tue, 25 Apr 2017 08:55:18 +0300
From: "Proshin, Maksim" 
To: Michael Tuexen 
CC: "tsvwg@ietf.org" 
Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016
Thread-Index: AQHSWgChCkg2HCaxb0Ww0RyyFOJkOaEPTU0BgIOeMwCAC2VfkIA1vTqAgAEe/MCAAEvagIAA49vA
Date: Tue, 25 Apr 2017 05:55:18 +0000
Message-ID: <1acd4841db5d4a69a2c90e0838f67d10@mera.ru>
References:    <2831A259-D6D7-4293-ACC7-41433AF7F72F@lurchi.franken.de> <57b16e1e50ec42a0ab23281ddfb8fdf7@mera.ru> <753E759D-5C3C-426D-9E29-42AB2658EDDB@lurchi.franken.de>  
In-Reply-To: 
Accept-Language: en-US, ru-RU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.201.113]
x-inside-org: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 Dec 2016
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 05:55:32 -0000

Thanks Michael! No more comments from me.

BR, Maksim


-----Original Message-----
From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20
Sent: Monday, April 24, 2017 22:19
To: Proshin, Maksim 
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS, closes 22 =
Dec 2016

> On 24. Apr 2017, at 14:05, Proshin, Maksim  wrote:
>=20
> Hi Michael,
>=20
> I'm ok with your proposals. I've answered your questions below inline.
Comments in-line.

Best regards
Michael
>=20
> Best regards,
> Maksim
>=20
> -----Original Message-----
> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
> Sent: Monday, April 24, 2017 00:40
> To: Proshin, Maksim 
> Cc: tsvwg@ietf.org
> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS,=20
> closes 22 Dec 2016
>=20
>> On 21. Mar 2017, at 07:16, Proshin, Maksim  wrote:
>>=20
>> Hi Michael,
>>=20
>> Basically I'm ok with all your answers and updates.=20
>> I don't have any major comments but I have a few proposals below inline =
(by [Maksim] tag).
> Hi Maksim,
>=20
> see my comments below.
>=20
> Best regards
> Michael
>>=20
>> BR, Maksim
>>=20
>>=20
>> -----Original Message-----
>> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>> Sent: Monday, March 13, 2017 14:00
>> To: Proshin, Maksim 
>> Cc: tsvwg@ietf.org
>> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata as PS,=20
>> closes 22 Dec 2016
>>=20
>>> On 19 Dec 2016, at 17:16, Proshin, Maksim  wrote:
>>>=20
>>> Hi,
>>>=20
>>> Thanks for the document! Please find below some comments. Only major co=
mments are included while editorial/minor comments have been sent directly =
to Michael.
>> Hi Maxim,
>>=20
>> thanks a lot for the review. I addresses the minor comments and responde=
d to your mail.
>> See my comments in-line.
>>=20
>> Best regards
>> Michael
>>>=20
>>> 1. Section 1.1: "DATA chunks are not permitted when I-DATA support=20
>>> has been negotiated."
>>> What exactly does it mean for implementation (both sending and=20
>>> receiving sides)? I think to avoid any problems with the sending=20
>>> side it should be "MUST NOT" in the sentence. For the receiving side=20
>>> I suppose it means stop processing of the packet and silently=20
>>> discard all further chunks in the packet, right? I think this should=20
>>> be clearly stated. It could also be good to clearly state that after=20
>>> association
>> I think it is clearly stated in 2.2.1:
>>=20
>> If I-DATA support has been negotiated for an association, I-DATA chunks =
MUST be used for all user messages and DATA-chunks MUST NOT be used. If I-D=
ATA support has not been negotiated for an association, DATA chunks MUST be=
 used for all user messages and I-DATA chunks MUST NOT be used.
>>=20
>> [Maksim] Ok, I agree that Section 2.2.1 clearly explains it for the send=
er. Can the same be explained for the receiver?
>>=20
>> So if these rules are violated, I think sending an ABORT with protocol v=
iolation might be appropriate.
>> [Maksim] Ok. Can it be clearly stated (e.g. in 2.2.1)? I mean it=20
>> would be good to state that such case should be
> OK. I added to the 'Receiver Side Considerations' the following text:
> If I-DATA support has been negotiated for an association, the receptio=
n of a DATA chunk is a violation of the above rules and therefore the recei=
ver of the DATA chunk MUST abort the association by sending an ABORT chunk.
> The ABORT chunk MAY include the 'Protocol Violation' error cause.
> The same applies if I-DATA support has not be negotiated for an=20
> association and an I-DATA chunk is received. [Maksim] Ok with me!
>=20
>> treated as a protocol violation. I also wonder that it should be mention=
ed that the restart case is different and should not be treated as a violat=
ion.=20
> In the restart case the rules apply based on what has been negotiated dur=
ing the restart.
> I think this is the general behaviour and is not handled in a special way=
. So I don't we need to describe this is detail.
> [Maksim] Ok, keep it as it is. Please also see below.
>=20
>>=20
>>> restart which was with DATA previously but became with I-DATA after the=
 restart, SCTP still may receive packets with DATA and they should be silen=
tly discarded due to VTag mismatch following the rules of Section 8.5. from=
 RFC4960 (I suppose this is important to avoid any "protocol violation" rea=
ction).=20
>> Sure. But this is normal restart behavior.
>> [Maksim] The reason I've asked it is because the statement is that this =
is "permitted" while in the restart case it is still possible to receive DA=
TA while I-DATA was already negotiated.
> So if originally I-DATA support was not negotiated and during the restart=
 it was negotiated, no DATA should be received after the restart. Am I miss=
ing something?
> [Maksim] I meant the case when stale DATA is received, e.g. due to reorde=
ring. In this case it will be still the same association but with I-DATA su=
pport and new VTags and such DATA should be silently discarded according to=
 VTag rules and not treated as protocol violation. This is what I proposed =
to be clarified but I don't really insist.
OK I see. But I think this is covered. The rules for association lookup and=
 checking the verification tag are done before the chunk processing. So I t=
hink we don't need to cover that.
>=20
>>>=20
>>> 2. Section 2.1:=20
>>> The only differences between the I-DATA chunk in Figure 3 and the=20
>>> DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the=20
>>> new Message Identifier (MID) and Fragment Sequence Number (FSN) and=20
>>> the removal of the Stream Sequence Number (SSN).
>>> The B bit now has a different (extended) purpose and also specifies if =
PPID or FSN is used. I think it should be stated.
>> OK. I added:
>> The Payload Protocol Identifier (PPID) and the FSN are stored at the sam=
e location of the packet using the B-bit to determine which value is stored=
 at the location.
>>>=20
>>> 3. I suppose the draft assumes that SCTP still MAY (i.e. not SHOULD/MUS=
T) support fragmentation even with I-DATA and MUST (i.e. not MAY/SHOULD) su=
pport re-assembling. If so, I suggest to clearly state it.
>> Yes, this hasn't changed. I think we don't need to repeat this point. Es=
pecially since I have not see an implementation not supporting fragmentatio=
n...
>>>=20
>>> 4. Is RFC6096 impacted by new chunks?
>> No. It only deals with old chunks. When defining a new chunk, you have t=
o define the corresponding flags registry as we do in this document.
>>>=20
>>> 5. Section 2.3.1: Support for the I-FORWARD-TSN chunk is negotiated=20
>>> during the SCTP  association setup via the Supported Extensions=20
>>> Parameter as defined  in [RFC5061].  Only if both end points support=20
>>> the I-DATA chunk and  the I-FORWARD-TSN chunk, the partial=20
>>> reliability extension can be  used in combination with user message int=
erleaving.
>>> Not sure how implementation should behave if either of these chunks is =
unsupported. I think it should be clearly stated.
>>> Namely if I-DATA is supported but not I-FORWARD-TSN, I believe the part=
ial reliability functionality should be completely off, i.e. not fallback t=
o FORWARD-TSN.=20
>>> If I-DATA is not supported but I-FORWARD-TSN is supported (strange impl=
ementation but still according to the draft as it does not prohibit the opp=
osite), it seems both functionalities message interleaving and partial reli=
ability should be off, i.e. there is no way to fallback to FORWARD-TSN, rig=
ht? =20
>> Right.
>>> Should the draft state something like "If I-DATA chunk is not used, I-F=
ORWARD-TSN chunk MUST NOT be used."?
>> There is already text there:
>>=20
>> The FORWARD-TSN chunk MUST be used in combination with the DATA chunk an=
d MUST NOT be used in combination with the I-DATA chunk.  The I- FORWARD-TS=
N chunk MUST be used in combination with the I-DATA chunk and MUST NOT be u=
sed in combination with the DATA chunk.
>>>=20
>>> 6. Section 4.1:=20
>>> MID is 32 bits while SSN is 16 bits so why a new SCTP Receive Informati=
on Structure cannot be introduced instead of using the existing one?
>> One could add such a structure, but is it needed? I don't see a use-case=
...
>> [Maksim] Isn't the drawback of the current approach is that 16 bits are =
lost?
> I don't see why this would be critical...=20
> [Maksim] Perhaps it depends on how the MID value is used by the=20
> application. When SCTP implementation reports just a half of MID, it=20
> actually means that another value is reported, isn't it? Then it means=20
> that we have two different
Yes, the lower 16 bits. It is easy to get from the MID the value being repo=
rted.
Just as if DATA chunk would be used.
> values: one on the application level and the other one on the SCTP level =
which might be a problem for e.g. troubleshooting. I understand that it is =
too late to change the concept but I wonder if the drawback (if there is re=
ally a drawback) is mentioned in the draft.
I don't see a problem...
>=20
>>> If the new SCTP Receive Information Structure is introduced then a new =
message receive function should also be introduced (instead of recv_msg() )=
. Is that the main problem?
>> recvmsg() is generic. It doesn't need to be changed. You would add anoth=
er CMSG.
>>> Of course, it would also be a problem if the interleaving functionality=
 requires enabling only on the sender side (see the next comment).
>> No, it is required to be enabled on both sides.
>>>=20
>>>=20
>>> 7. Section 4.3.1:
>>> User message interleaving is disabled per default.
>>> I'm not sure about it. First of all I think it should be clearly stated=
 what does it mean for the sender and for the receiver.
>>> If the intention was that I-DATA is included to INIT and INIT ACK only =
when the user enabled this functionality then I think this is not a good wa=
y because then it impacts not only the sender but also the receiver.=20
>>> In other words, if the feature is disabled by default on both sides whi=
le SCTP on both sides support it then it is not enough to just enable it on=
 one side, it requires enabling it on the other side. =20
>> Exactly. I think this is stated in the first sentence of 2.2.1.
>> [Maksim] I think it is not clearly stated in the document. "Supported" d=
oes not really mean "enabled". I would clearly state that this functionalit=
y should be enabled on both sides and only in this case it could be success=
fully negotiated. Especially it is important to state for the receiver side=
 because Section 2.2.1 has the following statement "A sender MUST NOT use t=
he I-DATA chunk unless the user has requested its use (e.g. via the socket =
API, see Section 4.3)."=20
> I can change the wording to make sure that I-DATA support is negotiated o=
nly if both sides indicated its support. And for each side user consent is =
required to indicate its support (in case the socket API is used). Would th=
at address your issue?
> [Maksim] Yes!
OK. Will do.
>=20
>>>=20
>>> 7. Section 4.3.1:  Why don't specify exactly value 1 for the enabled fe=
ature? Otherwise, in the future it will be difficult to use another value o=
f this parameter for a different purpose as it will be non-backward compati=
ble (old application and new SCTP may work improperly).
>> Since it is the standard way of encoding a flag in an int...
>>>=20
>>> 8. Section 5 does not cover I-FORWARD-TSN.
>> Good point. I added corresponding text.
>>>=20
>>> 9. Section 6: In case of DTLS over SCTP support of the message interlea=
ving functionality may increase the risk of receiving messages with new epo=
ch after ChangeCipherSpec message and before Finished message.
>> Possibly. But implementations have to deal with it anyway. So what is th=
e point?
>> [Maksim] Mainly my point was that it could be clarified so that future S=
CTP implementations of this draft/RFC supporting DTLS could consider it.=20
> Thinking about it... Why do you think that using I-DATA would increase th=
e risk?
> Both messages are small and sent back to back. Other messages can already=
 be sent on other streams. So the situation stays the same. Implementations=
 have to deal with this scenario.
> [Maksim] Ok, I don't insist to clarify it.=20
OK. I'll submit a new revision.

Thanks for the feedback.

Best regards
Michael
>=20
> Best regards
> Michael
>>>=20
>>>=20
>>> BR, Maksim
>>>=20
>>>> Am 08.12.2016 um 08:36 schrieb gorry@erg.abdn.ac.uk:
>>>>=20
>>>>=20
>>>> This mail announces a TSVWG Working Group Last Call (WGLC) on:
>>>>=20
>>>>          Stream Schedulers and User Message Interleaving forSCTP
>>>>          draft-ietf-tsvwg-sctp-ndata=20
>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata
>>>>=20
>>>> This WGLC will last for 2 weeks weeks.
>>>>=20
>>>> Comments should be sent to the tsvwg@ietf.org list, although purely=20
>>>> editorial comments may be sent directly to the authors. Please cc:
>>>> the WG chairs at tsvwg-chairs@ietf.org  if you would like the=20
>>>> chairs to track such editorial comments as part of the WGLC process.
>>>>=20
>>>> No IPR disclosures have been submitted directly on=20
>>>> draft-ietf-tsvwg-sctp-ndata.
>>>>=20
>>>> Thanks,
>>>> Gorry
>>>> (TSVWG Co-Chair)
>>=20
>=20


From nobody Tue Apr 25 03:30:05 2017
Return-Path: 
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A1C12EB24; Tue, 25 Apr 2017 03:29:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tsvwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149311619599.7493.10114060847835354434@ietfa.amsl.com>
Date: Tue, 25 Apr 2017 03:29:56 -0700
Archived-At: 
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-10.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 10:29:56 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group of the IETF.

        Title           : Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol
        Authors         : Randall R. Stewart
                          Michael Tuexen
                          Salvatore Loreto
                          Robin Seggelmann
	Filename        : draft-ietf-tsvwg-sctp-ndata-10.txt
	Pages           : 21
	Date            : 2017-04-25

Abstract:
   The Stream Control Transmission Protocol (SCTP) is a message oriented
   transport protocol supporting arbitrarily large user messages.  This
   document adds a new chunk to SCTP for carrying payload data.  This
   allows a sender to interleave different user messages that would
   otherwise result in head of line blocking at the sender.

   Whenever an SCTP sender is allowed to send user data, it may choose
   from multiple outgoing SCTP streams.  Multiple ways for performing
   this selection, called stream schedulers, are defined.  A stream
   scheduler can choose to either implement, or not implement, user
   message interleaving.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-10
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-sctp-ndata-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-10


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Apr 25 03:39:20 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E5C12EB75 for ; Tue, 25 Apr 2017 03:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdBR52EaUiSm for ; Tue, 25 Apr 2017 03:39:17 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0ED12EB72 for ; Tue, 25 Apr 2017 03:39:17 -0700 (PDT)
Received: from [IPv6:2003:cd:6bd7:7400:889:75a1:d2a0:758f] (p200300CD6BD77400088975A1D2A0758F.dip0.t-ipconnect.de [IPv6:2003:cd:6bd7:7400:889:75a1:d2a0:758f]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 7B6D4721E281A; Tue, 25 Apr 2017 12:39:14 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Michael Tuexen 
In-Reply-To: 
Date: Tue, 25 Apr 2017 12:39:13 +0200
Cc: "randall@lakerest.net" , "tuexen@C-muenster.de" , Salvatore Loreto , Robin Seggelmann , "weinrank@C-muenster.de" , tsvwg IETF list 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Ingemar Johansson S 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-sctp-ndata-09 regarding SCTP_SS_WFQ
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 10:39:20 -0000

> On 30. Mar 2017, at 20:29, Ingemar Johansson S =
 wrote:
>=20
> Hi
> =20
> I have been experimenting a little with the stream scheduler in the =
SCReAM implementation (https://github.com/EricssonResearch/scream), =
which is something close to a weighted fair scheduler. Not sure if these =
findings are of interest but anyway=E2=80=A6
> =20
> While it is quite straightforward to allocate bandwidth in a weighted =
manner if the sources are of the type =E2=80=9Cinfinite bandwidth=E2=80=9D=
 i.e. large enough objects, things get more tricky when sources like =
video is used.
> =20
> SCReAM congestion control has the requirement that a minimum of delay =
is allowed on the sending side, this means that the source bitrate must =
match the available (weighted) share of the bandwidth relatively =
closely. The end effect is that if we run two video sources through the =
SCReAM congestion controller with different weights , we will still get =
the same bitrate..
For the data channels we don't have this constraint.
In SCReAM I implemented a correction to this, perhaps there are better =
alternatives that I don=E2=80=99t know of.
> =20
> The bottomline is that the results with WFQ may differ depending of if =
the sources are of infinite bitrate or if they are bandwidth limited.
Understood. But I think the data channels do not make any assumptions =
about bandwidth requirements
if the application flows.

Best regards
Michael
> =20
> /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
> =20
> 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
> =20
> 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


From nobody Tue Apr 25 08:12:59 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664F613158F; Tue, 25 Apr 2017 08:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 x1FS24w9SmLv; Tue, 25 Apr 2017 08:12:49 -0700 (PDT)
Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 187FA13147B; Tue, 25 Apr 2017 08:12:05 -0700 (PDT)
Received: by mail-wr0-x241.google.com with SMTP id g12so7406401wrg.2; Tue, 25 Apr 2017 08:12:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WiRGkg1A6frDxFLGnVJIyDiYX8+UqDxRyfaRf6ZzZEA=; b=mHEH7bBO4JCqKNElea8Hjs0Aq5BpY6LYru0bmWZYsA4dXFXMO3ITUOtCKgdq6IMZoS cc2KC/FjbHiPsoObWvu22BX0l/K7kRaomzbCTWkRe4xXSFUqdYJbIrZM7P8KoUMOR8gD RsNCfLgHnLUYKh/T9IBEA+wxM08QMKnnjByiyRO01+HV5HgPkDU2KgKfnrtCHNEq4nwg SFjoIG6iuZJWcFoSZ1kJFgG+DsbzE61Bzygv8xejGqNYFJ4i82PYaIHJbyiGhhk46J3x cpC+rN+xYRBFZRKL4Tcn+xo0y61W3Si1kuI+Yif1mLZNZI9m9MgR5Ljdsevznla0sCaH vpCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WiRGkg1A6frDxFLGnVJIyDiYX8+UqDxRyfaRf6ZzZEA=; b=EWUnQN9royMUr67FrpljsdklIz5iQFWo6XHnkUgW4fIBUBFUN4o7PI6SVQ6k9WdNFT 0xEFNug3DEufF3bg85uQOTP+1uMpI0b8CYi2MTUN5EYjl73/quWY8h9xBISv8p1DvEeg HvLmZsYOdOjKGkVa9FHXeoXd7jMrTSnKJpZ+p0sZCo+afHmk1iYTofjk9pBGwrYxxB5F VfRI2sIGJyulQEylC1PPiRYTm+dbPse1ypbSWxeEE0IptcE/zre6S+64DId9EXXhmhZu sf8l+hMgkRW7my75HTyy4zj6nKmy+LFAfZw8FdvQue+ftwmqGzdvTUOgOtHHywMuehqf yNxg==
X-Gm-Message-State: AN3rC/78iID/2+cExT3/D1g6Jle6gzGbR2mcdLbhVAMK75jEVOC9xw1V Woiihuyt+aCCDw==
X-Received: by 10.223.164.148 with SMTP id g20mr10386879wrb.89.1493133123536;  Tue, 25 Apr 2017 08:12:03 -0700 (PDT)
Received: from ?IPv6:2601:647:4d01:db10:151d:eb0d:55d9:8e8b? ([2601:647:4d01:db10:151d:eb0d:55d9:8e8b]) by smtp.gmail.com with ESMTPSA id 31sm26561173wrt.35.2017.04.25.08.12.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 08:12:02 -0700 (PDT)
From: Bob Hinden 
Message-Id: <7F6C9FD6-BB14-4348-A870-93CD5E3CABBA@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_50B16128-4744-4F1A-8106-E560C4FEB551"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 25 Apr 2017 08:11:57 -0700
In-Reply-To: 
Cc: Bob Hinden , "Mirja Kuehlewind (IETF)" , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , IESG , 6man-chairs@ietf.org
To: Suresh Krishnan 
References:  <4DA7A0B2-AA3C-4E98-95FC-45A3CA5FC1F2@kuehlewind.net> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?ECN_and_fragments_=28was_Re=3A__Mirja_K=C3=BCh?= =?utf-8?q?lewind=27s_Discuss_on_draft-ietf-6man-rfc2460bis-09=3A_=28with_?= =?utf-8?q?DISCUSS_and_COMMENT=29=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 15:12:51 -0000

--Apple-Mail=_50B16128-4744-4F1A-8106-E560C4FEB551
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Suresh,

> On Apr 23, 2017, at 8:30 PM, Suresh Krishnan =
 wrote:
>=20
> On Sat, Apr 22, 2017 at 7:57 AM, Mirja Kuehlewind (IETF)
>  wrote:
>> Hi Suresh,
>>=20
>> thanks this text is fine for me.
>>=20
>> I=E2=80=99d like propose three tiny editorial only changes/nits:
>> s/Other/Further,/
>> s/this basic/the basic/
>> s/sufficient. e.g./sufficient, e.g./
>=20
> Thanks Mirja. These edits all seem fine.
>=20
>>=20
>>     Only those headers in the Offset zero fragment packet are =
retained in
>>     the reassembled packet. Further, fields in the IPv6 header may =
also
>>     vary across the fragments being reassembled. Specifications that
>>     use these fields may provide alternate instructions if the basic
>>     mechanism of using the values from the Offset zero fragment is =
not
>>     sufficient, e.g. Section 5.3 of [RFC3168] describes how to =
combine
>>     the ECN bits from the different fragments to derive the ECN bits =
of
>>     the reassembled packet.
>>=20
>> And I would be even more happier if we could add a few more words to =
the last sentence:
>>=20
>>     ... e.g. Section 5.3 of [RFC3168] describes how to combine
>>     the ECN bits from the different fragments to derive the ECN bits =
of
>>     the reassembled packet such that no congestion indications are =
lost.
>=20
> This is not strictly true. If any of the fragments carries the not-ECT
> codepoint, congestion indications will be lost (according to RFC3168),
> but my earlier proposed text still works. So if you don't care
> strongly about it, I would prefer keeping the old text.
>=20

I looked at the proposed text and came up with the following (including =
the text before and after):

   The following conditions are not expected to occur frequently, but
   are not considered errors if they do:

      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

      The Next Header values in the Fragment headers of different
      fragments of the same original packet may differ.  Only the value
      from the Offset zero fragment packet is used for reassembly.

      Other fields in the IPv6 header may also vary across the fragments
      being reassembled.  Specifications that use these fields may
      provide additional instructions if the basic mechanism of using
      the values from the Offset zero fragment is not sufficient.  For
      example, Section 5.3 of [RFC3168] describes how to combine the
      Explicit Congestion Notification (ECN) bits from different
      fragments to derive the ECN bits of the reassembled packet.

The biggest change was to split it into two paragraphs and put the new =
text after the paragraph about Next Header values.  Otherwise it =
doesn=E2=80=99t read well.

I also did a few editorial changes including spelling out ECN as it was =
the first time in the document that was used.  The text about Traffic =
Class comes later in document.  Changed =E2=80=9Calternate=E2=80=9D to =
=E2=80=9Cadditional=E2=80=9D because the ECN spec does not respecify the =
whole reassembly algorithm, just the ENC parts.

Comments?

Bob



--Apple-Mail=_50B16128-4744-4F1A-8106-E560C4FEB551
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJY/2c+AAoJEK7rdBF357uo+TkH/2HHLSvmDr6OcNebed5vSiXG
miQoX5wqoJ8gUzPmNFHbUveM6XFpDiNWLny9GmiF9FON/ftah6hyQzbEmeUqjCGD
x373Flr4g4kiBJRW/ysl9BJm48xnu1TugDMcGqvzmJjfyIiu0WxyTDO80kmRk8MO
WqOad3EwzF6b0j/auAqKep9S2gEWOcOdMApD+lkBMTYmeipfmhbpS1V6+ZfEaMWk
VftgGt3J3phpwdwVUxF8SBpobW0xA5WbrB7H7XBdK0Pv/9iS5fF4wFIFoTDsmBmf
QAsr5MGs60b2ecFsnHyIIvP+cQtgfTjSx2Wp8VXhclgmFPEeGRjqHSitpJjz8rQ=
=z1bx
-----END PGP SIGNATURE-----

--Apple-Mail=_50B16128-4744-4F1A-8106-E560C4FEB551--


From nobody Tue Apr 25 08:40:02 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0227A131623; Tue, 25 Apr 2017 08:40:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.2
X-Spam-Level: 
X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 xPswMMn2X12u; Tue, 25 Apr 2017 08:39:59 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF1B131622; Tue, 25 Apr 2017 08:39:58 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id D8F486BB48; Tue, 25 Apr 2017 11:39:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=as9Lu7eoIVm6UccjSbvyfcY8k/A=; b=eJig// 3i3EtH3Njsaz3N3j9pHlTmhD/augFfZnR/+bOEACZkfEygbeEvHrhMyjBBaU5hIM 5Fa/iBEeHecvCgzGAPrAiVsyGrqJqAAPjqf6NxtfkSGeHD84YIBxjnOuIu2GcEpL 5eV4nN91l+TehZmJ6q55z2sKcQj5umgZuj0dM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=J7CY/+3II1Jmwuo06DH2FIjXkkR1gr9p NSuws9GWZJRqFqAfOGgwfX8adCv3qCRqzmPKy24fhU17OisW21qE12l12x85pL1I HJWbln38o8dUv6h1DTbK2KIx8Cn8SlABJ6GkSThI1WRZABuW8z9jqNsDOlmO9YKE 7XQvsG8Rho0=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id CECED6BB47; Tue, 25 Apr 2017 11:39:57 -0400 (EDT)
Received: from mail-qk0-f180.google.com (unknown [209.85.220.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 582496BB45; Tue, 25 Apr 2017 11:39:57 -0400 (EDT)
Received: by mail-qk0-f180.google.com with SMTP id y63so118545951qkd.1; Tue, 25 Apr 2017 08:39:57 -0700 (PDT)
X-Gm-Message-State: AN3rC/4NvxHyBpYOkP7sqCuOH69aMCxPNihBdFdT5mfU6EV6DlsTzUkR Bx9mDBtkPAa0djBkVWdRQn6CMDrGRQ==
X-Received: by 10.55.20.2 with SMTP id e2mr26752001qkh.15.1493134796926; Tue, 25 Apr 2017 08:39:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.40.180 with HTTP; Tue, 25 Apr 2017 08:39:36 -0700 (PDT)
In-Reply-To: <7F6C9FD6-BB14-4348-A870-93CD5E3CABBA@gmail.com>
References:  <4DA7A0B2-AA3C-4E98-95FC-45A3CA5FC1F2@kuehlewind.net>  <7F6C9FD6-BB14-4348-A870-93CD5E3CABBA@gmail.com>
From: "C. M. Heard" 
Date: Tue, 25 Apr 2017 08:39:36 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Bob Hinden 
Cc: Suresh Krishnan ,  "Mirja Kuehlewind (IETF)" ,  "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , IESG , 6man Chairs <6man-chairs@ietf.org>
Content-Type: multipart/alternative; boundary=001a1144d6bc2c5208054dff894b
X-Pobox-Relay-ID: 6F7FBEAE-29CD-11E7-B043-E680B56B9B0B-06080547!pb-smtp1.pobox.com
Archived-At: 
Subject: Re: [tsvwg]  =?utf-8?q?ECN_and_fragments_=28was_Re=3A__Mirja_K=C3=BCh?= =?utf-8?q?lewind=27s_Discuss_on_draft-ietf-6man-rfc2460bis-09=3A_=28with_?= =?utf-8?q?DISCUSS_and_COMMENT=29=29?=
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 15:40:01 -0000

--001a1144d6bc2c5208054dff894b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think that this text does the job very well. It reads well, does not levy
any requirements on the reassembly process that were not in RFC 2460,
clearly states that that other specs such as ECN may levy additional
requirements, and points the reader to the relevant section of RFC 3168 for
more information. Thanks for putting this together.

//cmh

On Tue, Apr 25, 2017 at 8:11 AM, Bob Hinden  wrote:

> Suresh,
>
> > On Apr 23, 2017, at 8:30 PM, Suresh Krishnan 
> wrote:
> >
> > On Sat, Apr 22, 2017 at 7:57 AM, Mirja Kuehlewind (IETF)
> >  wrote:
> >> Hi Suresh,
> >>
> >> thanks this text is fine for me.
> >>
> >> I=E2=80=99d like propose three tiny editorial only changes/nits:
> >> s/Other/Further,/
> >> s/this basic/the basic/
> >> s/sufficient. e.g./sufficient, e.g./
> >
> > Thanks Mirja. These edits all seem fine.
> >
> >>
> >>     Only those headers in the Offset zero fragment packet are retained
> in
> >>     the reassembled packet. Further, fields in the IPv6 header may als=
o
> >>     vary across the fragments being reassembled. Specifications that
> >>     use these fields may provide alternate instructions if the basic
> >>     mechanism of using the values from the Offset zero fragment is not
> >>     sufficient, e.g. Section 5.3 of [RFC3168] describes how to combine
> >>     the ECN bits from the different fragments to derive the ECN bits o=
f
> >>     the reassembled packet.
> >>
> >> And I would be even more happier if we could add a few more words to
> the last sentence:
> >>
> >>     ... e.g. Section 5.3 of [RFC3168] describes how to combine
> >>     the ECN bits from the different fragments to derive the ECN bits o=
f
> >>     the reassembled packet such that no congestion indications are los=
t.
> >
> > This is not strictly true. If any of the fragments carries the not-ECT
> > codepoint, congestion indications will be lost (according to RFC3168),
> > but my earlier proposed text still works. So if you don't care
> > strongly about it, I would prefer keeping the old text.
> >
>
> I looked at the proposed text and came up with the following (including
> the text before and after):
>
>    The following conditions are not expected to occur frequently, but
>    are not considered errors if they do:
>
>       The number and content of the headers preceding the Fragment
>       header of different fragments of the same original packet may
>       differ.  Whatever headers are present, preceding the Fragment
>       header in each fragment packet, are processed when the packets
>       arrive, prior to queueing the fragments for reassembly.  Only
>       those headers in the Offset zero fragment packet are retained in
>       the reassembled packet.
>
>       The Next Header values in the Fragment headers of different
>       fragments of the same original packet may differ.  Only the value
>       from the Offset zero fragment packet is used for reassembly.
>
>       Other fields in the IPv6 header may also vary across the fragments
>       being reassembled.  Specifications that use these fields may
>       provide additional instructions if the basic mechanism of using
>       the values from the Offset zero fragment is not sufficient.  For
>       example, Section 5.3 of [RFC3168] describes how to combine the
>       Explicit Congestion Notification (ECN) bits from different
>       fragments to derive the ECN bits of the reassembled packet.
>
> The biggest change was to split it into two paragraphs and put the new
> text after the paragraph about Next Header values.  Otherwise it doesn=E2=
=80=99t
> read well.
>
> I also did a few editorial changes including spelling out ECN as it was
> the first time in the document that was used.  The text about Traffic Cla=
ss
> comes later in document.  Changed =E2=80=9Calternate=E2=80=9D to =E2=80=
=9Cadditional=E2=80=9D because the
> ECN spec does not respecify the whole reassembly algorithm, just the ENC
> parts.
>
> Comments?
>
> Bob
>
>
>

--001a1144d6bc2c5208054dff894b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I think that this text does the job very well. It reads we=
ll, does not levy any requirements on the reassembly process that were not =
in RFC 2460, clearly states that that other specs such as ECN may levy addi=
tional requirements, and points the reader to the relevant section of RFC 3=
168 for more information. Thanks for putting this together.

<=
div>//cmh

On Tue, Apr 25, 2017 at 8:11 AM, Bob Hinden <bob.hinden@gmail.com=
> wrote:
Suresh,




> On Apr 23, 2017, at 8:30 PM, Suresh Krishnan <suresh.krishnan@gmail.com> wrote:

>

> On Sat, Apr 22, 2017 at 7:57 AM, Mirja Kuehlewind (IETF)

> <ietf@kuehlewind.net>=
 wrote:

>> Hi Suresh,

>>

>> thanks this text is fine for me.

>>

>> I=E2=80=99d like propose three tiny editorial only changes/nits:
>> s/Other/Further,/

>> s/this basic/the basic/

>> s/sufficient. e.g./sufficient, e.g./

>

> Thanks Mirja. These edits all seem fine.

>

>>

>>=C2=A0 =C2=A0 =C2=A0Only those headers in the Offset zero fragment =
packet are retained in

>>=C2=A0 =C2=A0 =C2=A0the reassembled packet. Further, fields in the =
IPv6 header may also

>>=C2=A0 =C2=A0 =C2=A0vary across the fragments being reassembled. Sp=
ecifications that

>>=C2=A0 =C2=A0 =C2=A0use these fields may provide alternate instruct=
ions if the basic

>>=C2=A0 =C2=A0 =C2=A0mechanism of using the values from the Offset z=
ero fragment is not

>>=C2=A0 =C2=A0 =C2=A0sufficient, e.g. Section 5.3 of [RFC3168] descr=
ibes how to combine

>>=C2=A0 =C2=A0 =C2=A0the ECN bits from the different fragments to de=
rive the ECN bits of

>>=C2=A0 =C2=A0 =C2=A0the reassembled packet.

>>

>> And I would be even more happier if we could add a few more words =
to the last sentence:

>>

>>=C2=A0 =C2=A0 =C2=A0... e.g. Section 5.3 of [RFC3168] describes how=
 to combine

>>=C2=A0 =C2=A0 =C2=A0the ECN bits from the different fragments to de=
rive the ECN bits of

>>=C2=A0 =C2=A0 =C2=A0the reassembled packet such that no congestion =
indications are lost.

>

> This is not strictly true. If any of the fragments carries the not-ECT=


> codepoint, congestion indications will be lost (according to RFC3168),=


> but my earlier proposed text still works. So if you don't care

> strongly about it, I would prefer keeping the old text.

>




I looked at the proposed text and came up with the following (i=
ncluding the text before and after):



=C2=A0 =C2=A0The following conditions are not expected to occur frequently,=
 but

=C2=A0 =C2=A0are not considered errors if they do:



=C2=A0 =C2=A0 =C2=A0 The number and content of the headers preceding the Fr=
agment

=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same original pac=
ket may

=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present, preceding =
the Fragment

=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are processed when the=
 packets

=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments for reassembly=
.=C2=A0 Only

=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero frag=
ment packet are retained in

=C2=A0 =C2=A0 =C2=A0 the reassembled packet.



=C2=A0 =C2=A0 =C2=A0 The Next Header values in the Fragment headers =
of different

=C2=A0 =C2=A0 =C2=A0 fragments of the same original packet may differ.=C2=
=A0 Only the value

=C2=A0 =C2=A0 =C2=A0 from the Offset zero fragment packet is used for reass=
embly.



=C2=A0 =C2=A0 =C2=A0 Other fields in the IPv6 header may also vary across t=
he fragments

=C2=A0 =C2=A0 =C2=A0 being reassembled.=C2=A0 Specificatio=
ns that use these fields may

=C2=A0 =C2=A0 =C2=A0 provide additional instructions if the basic me=
chanism of using

=C2=A0 =C2=A0 =C2=A0 the values from the Offset zero fragment is not suffic=
ient.=C2=A0 For

=C2=A0 =C2=A0 =C2=A0 example, Section 5.3 of [RFC3168] describes how to com=
bine the

=C2=A0 =C2=A0 =C2=A0 Explicit Congestion Notification (ECN) bits from diffe=
rent

=C2=A0 =C2=A0 =C2=A0 fragments to derive the ECN bits of t=
he reassembled packet.



The biggest change was to split it into two paragraphs and put the n=
ew text after the paragraph about Next Header values.=C2=A0 Otherwise it do=
esn=E2=80=99t read well.



I also did a few editorial changes including spelling out ECN as it was the=
 first time in the document that was used.=C2=A0 The text about Traffic Cla=
ss comes later in document.=C2=A0 Changed =E2=80=9Calternate=E2=80=9D to =
=E2=80=9Cadditional=E2=80=9D because the ECN spec does not respecify the wh=
ole reassembly algorithm, just the ENC parts.



Comments?



Bob









--001a1144d6bc2c5208054dff894b--


From nobody Tue Apr 25 09:11:55 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6408131665 for ; Tue, 25 Apr 2017 09:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPYuyQzGUgxP for ; Tue, 25 Apr 2017 09:11:52 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 0F2A8131606 for ; Tue, 25 Apr 2017 09:11:52 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id m36so143894467qtb.0 for ; Tue, 25 Apr 2017 09:11:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ri3Si8n8duKW0KIxNVcM433Iw3tZPyoVc165k8g/6Ic=; b=pnCVO3hY0LnK/QAMBhLTb+1J8v5GDCKyQA7+F3cW7de9vT6UyYot+WWdHP9ZSQhgM3 o//062C+e5Qo5R5iHGGXw3FMvRhAsD1T0omHx07LaUZNhf7G53KveYhedlLVHyoDvRJn xAIeaO+vyAAcoKD50bh1KzmbGhCSbHYHUhnYGpBm74pC37uYqFNBH306ZtQcvVktH+KT wkeTlvTyPU75xTXxLk6RxokzvEs1aMgLlAkj1f8jKbtgWR9Qe4sGkYoNvQZRz2DXqNn4 YrTqvhggB9DM19KSB8NdpY4NPW4w987F3nT6surYE+8acyCSxxvBAbMrYKStJo9pv6my kpWA==
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=ri3Si8n8duKW0KIxNVcM433Iw3tZPyoVc165k8g/6Ic=; b=AolWDw+JTaJS3h9H2ezHTnEV/AtUNUcqhxhFnG8roQCACqvTJgMlUScMWzl7lKTtk6 4iCWdcXzmXY+rFiUAj8MHHzUxuWPDIAW53E4SdPwnwWlO0SJjVzZUisnxE0fnXWTiJvE FNqp1VKNk/ps5tTc1B11lQlTuRc17mNORX6PK1fyHh0lyEG1sC9cthk9+EKZ07ldmauB H61zyqn6g4hVu7G4QK7zmsKvu4XCiI2PMiN9O+eNuo+5MRh52iK9CqNOsAdvQA72NyVz 3CiTh0MzvpiVFMrfUpZ+nipwzMrxJXWmky/IjwK9wTQNQ6btzmsWQj2kVBb52THes9eG LcIw==
X-Gm-Message-State: AN3rC/7j2etrt8IOZEu0ND0FsjvAVyQ2UMAD+IAeq4HtPP0CIWyuNJ27 /Vm/uREh0Q7ybSAzAsVjiQldwxgc3A==
X-Received: by 10.237.58.103 with SMTP id n94mr34135511qte.42.1493136710897; Tue, 25 Apr 2017 09:11:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Tue, 25 Apr 2017 09:11:49 -0700 (PDT)
In-Reply-To: <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>
From: Tom Herbert 
Date: Tue, 25 Apr 2017 09:11:49 -0700
Message-ID: 
To: Joe Touch 
Cc: tsvwg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 16:11:54 -0000

>> What is handling if an option with unknown kind is received?
> Silently ignore - I'll add that text.
>
IMO, a protocol that includes optional data that must be sequentially
processed (parsed) but can otherwise be ignored is an invitation for a
DOS attack. All that an attacker needs to do is fill up a packet with
nothing but bogus options. Even with the rules above that would still
allow an attacker to fill an Ethernet MTU size packet with tiny UDP
options that will be ignored. The processing required to walk UDP
options could kill very well kill a server (e.g. a public DNS server
that happens to support UDP options). I know of two ways to avoid this
issue. Either don't allow options that can be ignored (as we do in
GUE) or artificially limit the amount of option space (as in IP
options). Since UDP options are intended to work on the Internet
without parameter negotiation, I tend to think limiting option space
is the right approach in this case.

>> Why doesn't OCS use the normal Internet checksum? Is this just to save
>> one byte in the options?
> And keep things half-word aligned.
>
8-bit checksum is significantly weaker than 16-bit checksum, saving
just a couple bytes here does not seem like much of a win. Also, I'm
not sure half word alignment helps all that much. IP protocols tend to
maintain word alignment and we have exploited that fact in
implementation. There are still architectures that have issues with
misalignment of 32-bit words (e.g. Sparc). Sending a bunch of
misaligned options with 4-byte data fields could be another form of
DOS attack. To avoid these issues it may be better to require all
options to be a multiple of 4 bytes in size and have the options start
at a four byte offset relative to the UDP header.

>> What if there is a checksum option but the kind has been corrupted
>> such that it no longer indicates a checksum?
> Then it's not a checksum option anymore.
>
But the purpose of the checksum is to protect the header against
corruption such that the data is not misinterpreted. In my example the
checksum has failed to do it's job. This is probably why checksums are
not in the options for UDP or TCP...

> Coverage is already indicated in 5.8:
>
>    ...the terminal FRAG option
>    is indicated as a longer, 12-byte variant, which includes an
>    Internet checksum over the reassembled payload (omitting the IP
>    pseudoheader and UDP header, as well as UDP options)
>
A checksum over reassembled payload is going to be costly. We might be
able to use HW offload if we have the checksum computed over each
segment. But, if we use LITE option that presents another problem
since in that case we'd only get checksum offload over UDP header and
not much larger payload. I think that problem is solvable if there
were a checksum field in LITE option that optional covers the LITE
data. Assuming that NICs properly implement protocol agnostic checksum
offload if should be possible to compute and set the UDP checksum
(over hdr and pseudo headr) in the host CPU, and then arrange for
device to compute checksum of LITE data and set checksum field in
that. A receiver that gets checksum complete should be able to verify
and compute checksum over UDP header and LITE without significant
computation. If you have someone implementing this I could probably
help them with the implementation details.

>> It's subjective to say that inconsistency in lengths should not be
>> considered attack.
> No, it isn't. You can say that inconsistencies are errors, but the
> Postel Principle says that anything allowed by the spec should be
> accepted by the receiver. Inferring an attack from what could be
> legitimate behavior is simply wrong.
>
Neither attackers nor firewalls adhere to the Postel principle.
Attackers are always trying to masquerade their attack as legitimate
behavior, and firewalls are trying to identify when they are doing
that. A consequence of this is that firewalls will sometimes drop
packets that match an attack profile but still might be legitimate.
Note that firewalls already routinely drop packets with EHs that they
don't understand; that is wrong per the Robustness principle, but
nevertheless a reality we need to deal with in protocol deployment on
the Internet.

>> I can easily imagine an DOS attack against
>> bandwidth in a network where tiny UDP packets are placed in full MTU
>> sized packets.
> Why on earth would anyone bother? Why not just send large packets -
> wouldn't they create more damage?

Because the surplus data may be transparent to a firewall and thus
could possibly be used to circumvent the firewall. This might not very
different from the way that ICMP data has been used as a trojan to
ship sensitive data out of a network. The danger is that if there is
an ever attack or event the perception of a security hole, then some
network operators could start blocking packets like this
indiscriminately. If that happens the wide-scale deployment of a
potentially useful feature like this might never happen. We've seen
this many times before (new EHs for instance). IMO the best way to
avoid is to provide reasonable limits and assume up front that
firewalls and other intermediate boxes will parse and make decisions
(that we may not always agree with) on any plain text in a packet.

Tom


From nobody Tue Apr 25 10:21:47 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7446012420B for ; Tue, 25 Apr 2017 10:21:45 -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 Vd169IOvQyN4 for ; Tue, 25 Apr 2017 10:21:43 -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 BDA90131709 for ; Tue, 25 Apr 2017 10:21:10 -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 v3PHKeDT015424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 10:20:40 -0700 (PDT)
To: Tom Herbert 
Cc: tsvwg 
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu> 
From: Joe Touch 
Message-ID: 
Date: Tue, 25 Apr 2017 10:20:39 -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: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 17:21:45 -0000

On 4/25/2017 9:11 AM, Tom Herbert wrote:
>>> What is handling if an option with unknown kind is received?
>> Silently ignore - I'll add that text.
>>
> IMO, a protocol that includes optional data that must be sequentially
> processed (parsed) but can otherwise be ignored is an invitation for a
> DOS attack.
That's already true for TCP headers and for any extensible protocol that
allows new extensions to be ignored (including IPv4 and IPv6).

> All that an attacker needs to do is fill up a packet with
> nothing but bogus options. Even with the rules above that would still
> allow an attacker to fill an Ethernet MTU size packet with tiny UDP
> options that will be ignored. The processing required to walk UDP
> options could kill very well kill a server (e.g. a public DNS server
> that happens to support UDP options). I know of two ways to avoid this
> issue. Either don't allow options that can be ignored (as we do in
> GUE) or artificially limit the amount of option space (as in IP
> options).
IPv4 options have limited space. IPv6 has no such limit because of
similar chaining.

However, you're ignoring the fact that critical servers could easily
decide that they would parse messages with unknown options only given
available capacity. We include text warning protocol designers to use
these options sparingly and note that servers MAY ignore any subset
(including all) options, as long as they do so consistently on a per
socketpair basis.

>  Since UDP options are intended to work on the Internet
> without parameter negotiation, I tend to think limiting option space
> is the right approach in this case.
We've been down this road too many times to think it will end well.
Whatever limit you put will need to be exceeded at some point, whether
it's a pure length limit or a limit on the number of options.

We can say that each option can occur only at most once (except for
NOP), which would limit the number of non-experimential options in a
given packet to roughly 250. But we can't limit the length of any option
- to do so undermines the use of the paired LITE/FRAG solution.

>
>>> Why doesn't OCS use the normal Internet checksum? Is this just to save
>>> one byte in the options?
>> And keep things half-word aligned.
>>
> 8-bit checksum is significantly weaker than 16-bit checksum, saving
> just a couple bytes here does not seem like much of a win
We can debate and adjust that if/when this becomes a WG item.

> . Also, I'm
> not sure half word alignment helps all that much. IP protocols tend to
> maintain word alignment and we have exploited that fact in
> implementation. There are still architectures that have issues with
> misalignment of 32-bit words (e.g. Sparc). Sending a bunch of
> misaligned options with 4-byte data fields could be another form of
> DOS attack. To avoid these issues it may be better to require all
> options to be a multiple of 4 bytes in size and have the options start
> at a four byte offset relative to the UDP header.
That's not how TCP, IPv4, or IPv6 options work, and it isn't how UDP
options should work either.

And it's not tenable for many of the proposed options (notably FRAG).

>
>>> What if there is a checksum option but the kind has been corrupted
>>> such that it no longer indicates a checksum?
>> Then it's not a checksum option anymore.
>>
> But the purpose of the checksum is to protect the header against
> corruption such that the data is not misinterpreted. In my example the
> checksum has failed to do it's job. This is probably why checksums are
> not in the options for UDP or TCP...

There have been checksum options (and other integrity checks, such as
TCP MD5 and AO) for TCP.

However, what you're asking is like "how does a TCP checksum protect
against errors in the IP proto field?". It can't. If that field changes,
the packet isn't interpreted as TCP.
>> Coverage is already indicated in 5.8:
>>
>>    ...the terminal FRAG option
>>    is indicated as a longer, 12-byte variant, which includes an
>>    Internet checksum over the reassembled payload (omitting the IP
>>    pseudoheader and UDP header, as well as UDP options)
>>
> A checksum over reassembled payload is going to be costly. 
It depends on where the reassembly happens. It can easily occur during
any copy (e.g., to user space) - nearly for free.

> We might be
> able to use HW offload if we have the checksum computed over each
> segment. 
That doesn't protect against reassembly errors.

> But, if we use LITE option that presents another problem
> since in that case we'd only get checksum offload over UDP header and
> not much larger payload. I think that problem is solvable if there
> were a checksum field in LITE option that optional covers the LITE
> data.
Most uses of LITE would never want it, and it won't help FRAG as per above.

>  Assuming that NICs properly implement protocol agnostic checksum
> offload if should be possible to compute and set the UDP checksum
> (over hdr and pseudo headr) in the host CPU, and then arrange for
> device to compute checksum of LITE data and set checksum field in
> that. A receiver that gets checksum complete should be able to verify
> and compute checksum over UDP header and LITE without significant
> computation. If you have someone implementing this I could probably
> help them with the implementation details.
The checksum of the FRAG components could easily be done incrementally
(over each fragment) and summed later, accomplishing the same thing.

The only change would be that we would need to limit the fragments to
16-bit boundaries, which means making the offset 14 bits instead of 16.

>
>>> It's subjective to say that inconsistency in lengths should not be
>>> considered attack.
>> No, it isn't. You can say that inconsistencies are errors, but the
>> Postel Principle says that anything allowed by the spec should be
>> accepted by the receiver. Inferring an attack from what could be
>> legitimate behavior is simply wrong.
>>
> Neither attackers nor firewalls adhere to the Postel principle.
We don't care if they do.

> Attackers are always trying to masquerade their attack as legitimate
> behavior, and firewalls are trying to identify when they are doing
> that. A consequence of this is that firewalls will sometimes drop
> packets that match an attack profile but still might be legitimate.

A device that infers an attack from legitimate behavior has a false
positive, and I'd send that back and demand a refund.

However, it may be possible for such a device to drop those packets if
it can claim that even legitimate behavior is causing problems - but
then that's claiming that standards-compliant behavior can cause an
attack. That's always been true (e.g., SYN flooding).

> Note that firewalls already routinely drop packets with EHs that they
> don't understand; that is wrong per the Robustness principle, but
> nevertheless a reality we need to deal with in protocol deployment on
> the Internet.
It is pointless to design laws for the lawless.

The best we can do is design laws for those who follow them.

>
>>> I can easily imagine an DOS attack against
>>> bandwidth in a network where tiny UDP packets are placed in full MTU
>>> sized packets.
>> Why on earth would anyone bother? Why not just send large packets -
>> wouldn't they create more damage?
> Because the surplus data may be transparent to a firewall and thus
> could possibly be used to circumvent the firewall.
That's true for every area that is currently undefined.

Sure, if I'm running a highly secure facility, I allow only the
capabilities I know I support and need, and drop all others.

But again, that rule already applies to IPv4, IPv6, and TCP - and IPv6
in an unfettered way.

> This might not very
> different from the way that ICMP data has been used as a trojan to
> ship sensitive data out of a network. 

Sure, and then that ends up breaking PMTUD to and from your own hosts.

> The danger is that if there is
> an ever attack or event the perception of a security hole, then some
> network operators could start blocking packets like this
> indiscriminately. 
They already block lots of things - e.g., some ISPs block email to force
you to use their web interfaces. Some hotel nets block VPN access.

That doesn't cause the IETF to deprecate these protocols.

> If that happens the wide-scale deployment of a
> potentially useful feature like this might never happen. We've seen
> this many times before (new EHs for instance). IMO the best way to
> avoid is to provide reasonable limits and assume up front that
> firewalls and other intermediate boxes will parse and make decisions
> (that we may not always agree with) on any plain text in a packet.

UDP options are a case where the operator decides what's reasonable, and
either helps or hurts their customers/clients.

The rest is for the market to decide.

Joe


From nobody Tue Apr 25 10:59:49 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66160131736 for ; Tue, 25 Apr 2017 10:59:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drfw-EuMLPlr for ; Tue, 25 Apr 2017 10:59:45 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA271274D0 for ; Tue, 25 Apr 2017 10:59:45 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id m36so146630369qtb.0 for ; Tue, 25 Apr 2017 10:59:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PQXViUwmzBXMxQGdGveuCLATz2vI9Gi5Y3Dj7AzVjEk=; b=uEKE6p5ahJ23H10seI23rjsxNNapwYfGlBxw3Z602aKORuPv6sVTkV/m6+OcSltDpJ GhcZulgyPqNgAIJ23sSJWkNEpmOUl/I4Ml590EtdxJcWdEjQEPWUfYSwnGUy9FEtiA0a UdJ9AWgznrayh6bMg5jmdBWT0daNLrP8YIb4MzZhsEkq+J0vqpV5/0gRCwOEnBV54nvW O73U/DHquruHCYyD0FDchL30JE5zYysy+bI6zfdmsJRYpo9ttiZJhTI6/KaQZTlFvPTs /CKUJ+/mJsg291a1AbwYfGIQmBBPGGAFga03slTVnylXIqhJpzOw5PW3D0Iy10ILvSZb X+6Q==
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=PQXViUwmzBXMxQGdGveuCLATz2vI9Gi5Y3Dj7AzVjEk=; b=oq2TWYoCyYN5cdek++ZoJmcsVCGlu/9YC7FKejsl2b7eS3XZIpEJbxl8ONvpxJ8swY 9zqGA8p42XnAoz3KSGMXyX1MOkE1NLaagcRu1hGoG9xLsS7xZgSZv6LIw5bHq5wMWntg EBbh5U/WolgoismNId6MZ419GEIwOp0odfy6ZqKMDIcyn7A3t66MjleWQ7mIukPRUbhM KJ+u3Pv4xBJzixcvv/TfvkOQ3sFcp8hI0kf/QWu4ktuIDkirIpL7ico9pRPH4NdQmG7U AxLe29GM2oYbV1Idd6vn/ybOQ3V5Sx0FpduKHg4bRV/ldwzu+8a45GAFjoQ5biD91Nnw XZ0w==
X-Gm-Message-State: AN3rC/7YN2ffoVsGngK/+fJV7lt9ObqcEPjknsXnwkMGn4mpQxKOVan7 8p2HgGP+azLUAP6dmFTsSG6fS++6Ng==
X-Received: by 10.200.43.146 with SMTP id m18mr31728267qtm.210.1493143184822;  Tue, 25 Apr 2017 10:59:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Tue, 25 Apr 2017 10:59:44 -0700 (PDT)
In-Reply-To: 
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>  
From: Tom Herbert 
Date: Tue, 25 Apr 2017 10:59:44 -0700
Message-ID: 
To: Joe Touch 
Cc: tsvwg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 17:59:47 -0000

On Tue, Apr 25, 2017 at 10:20 AM, Joe Touch  wrote:
>
>
> On 4/25/2017 9:11 AM, Tom Herbert wrote:
>>>> What is handling if an option with unknown kind is received?
>>> Silently ignore - I'll add that text.
>>>
>> IMO, a protocol that includes optional data that must be sequentially
>> processed (parsed) but can otherwise be ignored is an invitation for a
>> DOS attack.
> That's already true for TCP headers and for any extensible protocol that
> allows new extensions to be ignored (including IPv4 and IPv6).
>
>> All that an attacker needs to do is fill up a packet with
>> nothing but bogus options. Even with the rules above that would still
>> allow an attacker to fill an Ethernet MTU size packet with tiny UDP
>> options that will be ignored. The processing required to walk UDP
>> options could kill very well kill a server (e.g. a public DNS server
>> that happens to support UDP options). I know of two ways to avoid this
>> issue. Either don't allow options that can be ignored (as we do in
>> GUE) or artificially limit the amount of option space (as in IP
>> options).
> IPv4 options have limited space. IPv6 has no such limit because of
> similar chaining.
>
> However, you're ignoring the fact that critical servers could easily
> decide that they would parse messages with unknown options only given

Servers would not know a priori which message contain unknown options
and which don't. To find out, they have to parse the options and
there's no guarantee that known options won't follow unknown ones so
they need to walk the whole list (that could be resolved by enforcing
order of options). The only relevant decision I currently see here is
whether a server is going to implement UDP options or not. If there's
another viable option then the rules for that should be specified in
the protocol, otherwise implementations will make their own rules to
address the DOS threat which quickly breaks interoperability.

> available capacity. We include text warning protocol designers to use
> these options sparingly and note that servers MAY ignore any subset
> (including all) options, as long as they do so consistently on a per
> socketpair basis.

>>  Since UDP options are intended to work on the Internet
>> without parameter negotiation, I tend to think limiting option space
>> is the right approach in this case.
> We've been down this road too many times to think it will end well.
> Whatever limit you put will need to be exceeded at some point, whether
> it's a pure length limit or a limit on the number of options.
>
> We can say that each option can occur only at most once (except for
> NOP), which would limit the number of non-experimential options in a
> given packet to roughly 250. But we can't limit the length of any option

Please make sure that whoever implements this protocol tests the
analyzes this worst scenario for performance and susceptibility for
DOS attack. I'm pretty certain we will require this analysis before
ever accepting mechanism like this into Linux.

Tom


From nobody Tue Apr 25 11:10:16 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CBF13174A for ; Tue, 25 Apr 2017 11:10:15 -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 3abQOExll7Ab for ; Tue, 25 Apr 2017 11:10:13 -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 B703D131746 for ; Tue, 25 Apr 2017 11:10:13 -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 v3PI9Utw023391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 11:09:32 -0700 (PDT)
To: Tom Herbert 
Cc: tsvwg 
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>   
From: Joe Touch 
Message-ID: <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu>
Date: Tue, 25 Apr 2017 11:09:29 -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: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 18:10:15 -0000

Hi, Tom,


On 4/25/2017 10:59 AM, Tom Herbert wrote:
> ...
>> However, you're ignoring the fact that critical servers could easily
>> decide that they would parse messages with unknown options only given
> Servers would not know a priori which message contain unknown options
> and which don't.

Whatever rule you're thinking of (e.g., "only 100B of options", no more
than 3 unknown options, no unknown options, etc. ) is what they could
implement. We don't need to build that into the protocol.

> To find out, they have to parse the options and
> there's no guarantee that known options won't follow unknown ones so
> they need to walk the whole list (that could be resolved by enforcing
> order of options). 
They either will see options they support (which is fine) or ones they
won't. If the limit how many unknown options they allow for that
connection or server, they should be just as fine as they would be if
the protocol forced that for everyone.
> The only relevant decision I currently see here is
> whether a server is going to implement UDP options or not. If there's
> another viable option then the rules for that should be specified in
> the protocol, otherwise implementations will make their own rules to
> address the DOS threat which quickly breaks interoperability.
So does limiting the option space. If we allow the space to be used as
endpoints see fit, we allow the endpoints to decide by mutual consent.
That's what transport protocols are for.

> ...
>>>  Since UDP options are intended to work on the Internet
>>> without parameter negotiation, I tend to think limiting option space
>>> is the right approach in this case.
>> We've been down this road too many times to think it will end well.
>> Whatever limit you put will need to be exceeded at some point, whether
>> it's a pure length limit or a limit on the number of options.
>>
>> We can say that each option can occur only at most once (except for
>> NOP), which would limit the number of non-experimential options in a
>> given packet to roughly 250. But we can't limit the length of any option
> Please make sure that whoever implements this protocol tests the
> analyzes this worst scenario for performance and susceptibility for
> DOS attack.
That is not uniquely required for this protocol.

>  I'm pretty certain we will require this analysis before
> ever accepting mechanism like this into Linux.

You're kidding, right? The OS that is the poster child for taking
everything? (you don't want to know how many errors we've already found
the TCP stack along these lines).

Joe


From nobody Tue Apr 25 11:29:17 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29221131766 for ; Tue, 25 Apr 2017 11:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpgUtwf3v7ZG for ; Tue, 25 Apr 2017 11:29:14 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE1E12946A for ; Tue, 25 Apr 2017 11:29:14 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id g60so147692314qtd.3 for ; Tue, 25 Apr 2017 11:29:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fYJRn0XoOP7F2oVgReNk9N29AYtMqycKEgwtMmZ6qGc=; b=gDjHDaD3K8iMujpX8VeVOFedLGatvBmW6acmcENnJ+tUkSva7Bl5ZH01F/yUgBQRjO XE4383BYxtKy3jTP0LD9MtOMnRSrjKyLUmyn7kDyWnLnSsk5E/JEQsByMKF2ALCCrktF I3uKVTAiJenWgSIuYfF8eDjTGuSDa9eSB31tbBpXSxS2Wz8DqjCw5rF9RLFHYwlAizL+ fRePAsaOn8a/FkwDK7teAMBj9pBiNyWR7k5acPvNiHlVnyjlRIxY3TytZR9vw4V4YSfl eYqlLbcKCqKCPsLTbjh/1gHqSWnWLyRiB6cAVkPw6FUDIDlQq0HT9pL/RIa0dCVDCeFE uPCA==
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=fYJRn0XoOP7F2oVgReNk9N29AYtMqycKEgwtMmZ6qGc=; b=pODCjrOk2TNKwu/2y+ooyzHi4bCbO++jUaasUV/7bpoanRretHAfh75U3w3rnJvv2o nIZxnYKggNw8H1oLMTtaf6h1kC8Qikk9nQYnQFzX7rexZlqqlKrdZYrfRpabV3wSgCY/ Y370XXUDxf2gLGLTmfInDLDZ/LxI8rT077ZmZcDOWQUGO91HhyA7mr4fuhQk+lmX4AoU GUwx6ir/ffcyx3nHqG+n2QKmdFpIv+B5gd2XZclKEhq0Rm1ZmU8b950J8n6PqP/1ZHrH RK2HSgXAe+YFps+CtqVQI0a0o/8k1AClqtloKx55bX6QuxcazBCv9bEEPfrkAC54SvsM h2qg==
X-Gm-Message-State: AN3rC/4DiEguTezclwynsYrwRyuuwcwoMZT0p0fmBlLN/v8HuTKjdr+O fesW2F+Y7XTbiNka5Y6Qy3mQ25X9wA==
X-Received: by 10.237.58.103 with SMTP id n94mr34884274qte.42.1493144953876; Tue, 25 Apr 2017 11:29:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Tue, 25 Apr 2017 11:29:13 -0700 (PDT)
In-Reply-To: <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu>
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>    <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu>
From: Tom Herbert 
Date: Tue, 25 Apr 2017 11:29:13 -0700
Message-ID: 
To: Joe Touch 
Cc: tsvwg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 18:29:16 -0000

On Tue, Apr 25, 2017 at 11:09 AM, Joe Touch  wrote:
> Hi, Tom,
>
>
> On 4/25/2017 10:59 AM, Tom Herbert wrote:
>> ...
>>> However, you're ignoring the fact that critical servers could easily
>>> decide that they would parse messages with unknown options only given
>> Servers would not know a priori which message contain unknown options
>> and which don't.
>
> Whatever rule you're thinking of (e.g., "only 100B of options", no more
> than 3 unknown options, no unknown options, etc. ) is what they could
> implement. We don't need to build that into the protocol.
>
>> To find out, they have to parse the options and
>> there's no guarantee that known options won't follow unknown ones so
>> they need to walk the whole list (that could be resolved by enforcing
>> order of options).
> They either will see options they support (which is fine) or ones they
> won't. If the limit how many unknown options they allow for that
> connection or server, they should be just as fine as they would be if
> the protocol forced that for everyone.
>> The only relevant decision I currently see here is
>> whether a server is going to implement UDP options or not. If there's
>> another viable option then the rules for that should be specified in
>> the protocol, otherwise implementations will make their own rules to
>> address the DOS threat which quickly breaks interoperability.
> So does limiting the option space. If we allow the space to be used as
> endpoints see fit, we allow the endpoints to decide by mutual consent.
> That's what transport protocols are for.
>
>> ...
>>>>  Since UDP options are intended to work on the Internet
>>>> without parameter negotiation, I tend to think limiting option space
>>>> is the right approach in this case.
>>> We've been down this road too many times to think it will end well.
>>> Whatever limit you put will need to be exceeded at some point, whether
>>> it's a pure length limit or a limit on the number of options.
>>>
>>> We can say that each option can occur only at most once (except for
>>> NOP), which would limit the number of non-experimential options in a
>>> given packet to roughly 250. But we can't limit the length of any option
>> Please make sure that whoever implements this protocol tests the
>> analyzes this worst scenario for performance and susceptibility for
>> DOS attack.
> That is not uniquely required for this protocol.
>
>>  I'm pretty certain we will require this analysis before
>> ever accepting mechanism like this into Linux.
>
> You're kidding, right? The OS that is the poster child for taking
> everything? (you don't want to know how many errors we've already found
> the TCP stack along these lines).
>
No, I'm not kidding. We are not going to blindly take protocol code
that has possible new DOS vector which is going to be deployed on
billions of devices! Really, testing this case is not rocket science.
(you don't want to know how many errors and inadequacies in standard
protocols we've already found because protocol developers failed to
test their protocol :-) ).

> Joe


From nobody Tue Apr 25 11:49:18 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BF8131768 for ; Tue, 25 Apr 2017 11:49:16 -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 pg2P7Y_55cPQ for ; Tue, 25 Apr 2017 11:49:15 -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 91F28131767 for ; Tue, 25 Apr 2017 11:49:15 -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 v3PIhCgY029417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 11:43:14 -0700 (PDT)
To: Tom Herbert 
Cc: tsvwg 
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>    <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu> 
From: Joe Touch 
Message-ID: 
Date: Tue, 25 Apr 2017 11:43:11 -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: multipart/alternative; boundary="------------5A1E895D58A4D6EEB2BFBD59"
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
Subject: Re: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 18:49:17 -0000

This is a multi-part message in MIME format.
--------------5A1E895D58A4D6EEB2BFBD59
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit



On 4/25/2017 11:29 AM, Tom Herbert wrote:
>>>  I'm pretty certain we will require this analysis before
>>> ever accepting mechanism like this into Linux.
>> You're kidding, right? The OS that is the poster child for taking
>> everything? (you don't want to know how many errors we've already found
>> the TCP stack along these lines).
>>
> No, I'm not kidding. We are not going to blindly take protocol code
> that has possible new DOS vector which is going to be deployed on
> billions of devices! 
You'll have to start by explaining all the code you've already taken,
some of which (e.g., TCP use of experimental ports) is prohibited by
existing RFCs.

> Really, testing this case is not rocket science.
> (you don't want to know how many errors and inadequacies in standard
> protocols we've already found because protocol developers failed to
> test their protocol :-) ).
>
Check out Linux processing of TCP option 253 and 254 and tell me you
have a leg to stand on.

Joe

--------------5A1E895D58A4D6EEB2BFBD59
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    


    

    

    
On 4/25/2017 11:29 AM, Tom Herbert
      wrote:

    

    

      

        

          
 I'm pretty certain we will require this analysis before
ever accepting mechanism like this into Linux.


        

        
You're kidding, right? The OS that is the poster child for taking
everything? (you don't want to know how many errors we've already found
the TCP stack along these lines).



      

      
No, I'm not kidding. We are not going to blindly take protocol code
that has possible new DOS vector which is going to be deployed on
billions of devices! 

    

    You'll have to start by explaining all the code you've already
    taken, some of which (e.g., TCP use of experimental ports) is
    prohibited by existing RFCs.

    

    

      
Really, testing this case is not rocket science.
(you don't want to know how many errors and inadequacies in standard
protocols we've already found because protocol developers failed to
test their protocol :-) ).



    

    Check out Linux processing of TCP option 253 and 254 and tell me you
    have a leg to stand on.

    

    Joe

  


--------------5A1E895D58A4D6EEB2BFBD59--


From nobody Tue Apr 25 12:19:27 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D63131790 for ; Tue, 25 Apr 2017 12:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3Q42Enb8izV for ; Tue, 25 Apr 2017 12:19:25 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5090912EB44 for ; Tue, 25 Apr 2017 12:19:25 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id m36so148616202qtb.0 for ; Tue, 25 Apr 2017 12:19:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=f+pq+rwo+8HQKxEjoiPwEaOfyg5jdK9oAYTj3DuZa74=; b=QeXNXGFoVJhpRnebrcmjIqRs4lSco/5EIcCpn16B6lZlHyyc1eCn3SloLPb86D4/m2 ntlDzuGQl4mLXwGWWopx/5zsvtNAejw2Oveu2vxPElv0O0cKcLgbMBfgiKNvwYh00tel P5m10mxXLjx7dPR1bZCOAMw6rAYPaG5ob4+iqncooSiqkOwexZ8Y0Y36z2Ql7vj9Ndc4 J8j88GnRcYvZIyDs8Gj81H1DYLYDRulxplJ6m/W/FuXmRMh8UhGAl8x/cV8maJIw5I1q z/3ftpyROe9PVwoU5rwuyjixlrnGavgmcIFXA/HewqcFwyWxDeXp13DXVI0gQgJEikbn GMqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=f+pq+rwo+8HQKxEjoiPwEaOfyg5jdK9oAYTj3DuZa74=; b=kzAc/tZ5nDo7glfEItyE9oBi7usAj/TYpCWTR1ILL5zhjuqEtMTk+nupiQBA5f6tQP EFkBh22/akRm/LfojjZc6Byoz/7LECo6EP4X5LaO7hyghbqcKoKozFOgIZ3lt3ITaxkz g53DhrN8TsuMEwjnKDyt/bEA77vLAoL4BGJqRjMtoCyGHfWvx0TLc0NspAuv7b+c2/0U gFnkPIhpq4rHo/CLNYK0fAL8ilykUDPbqx4G/yGqxtNEXycPTBIFWvB4YiAnrbL3SN/1 nnhAeXf5pZTkAKeoAQYWw8Zsl74ITj3Btm81ya3N6CdWKb3MmlL15hJD1yDOOhMGWeoD iJcA==
X-Gm-Message-State: AN3rC/6tdeTpcM5+1h6hIiSG+AlTaFBd6FQpad0oidGUFB/+/jBRQx1D v987jsLrDz5j32h8peOf79EHeNWHcg==
X-Received: by 10.200.55.15 with SMTP id o15mr32064110qtb.279.1493147964248; Tue, 25 Apr 2017 12:19:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Tue, 25 Apr 2017 12:19:23 -0700 (PDT)
From: Tom Herbert 
Date: Tue, 25 Apr 2017 12:19:23 -0700
Message-ID: 
To: Joe Touch 
Cc: tsvwg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [tsvwg] Inconsistencies between TCP RFCs and Linux implementation (was Re: Comments on draft-touch-tsvwg-udp-option)s-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 19:19:27 -0000

> You'll have to start by explaining all the code you've already taken, some
> of which (e.g., TCP use of experimental ports) is prohibited by existing
> RFCs.
>
Which experimental ports are being abused?

> Check out Linux processing of TCP option 253 and 254 and tell me you have a
> leg to stand on.
>
Linux code use option 254 for TCP fast open along with a magic number
to distinguish it from other use cases. Given that there is now
assigned option for fast open this use of the experimental option can
be removed.

Are there other inconsistencies that need investigation?

Tom


From nobody Tue Apr 25 12:40:35 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D13B131792 for ; Tue, 25 Apr 2017 12:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BilAAdRIcwnI for ; Tue, 25 Apr 2017 12:40:32 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 92A4B12762F for ; Tue, 25 Apr 2017 12:40:32 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id g66so25903234ite.1 for ; Tue, 25 Apr 2017 12:40:32 -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=hiQLf6UQcsZWwL+JmDtCIGCXwa/MVtXRT1sdJneqV4U=; b=YNoUw9QbT+1ZBZVXL1pCI4u49eGBHgUCMpTiapv/LYgQhmEXME7F3no6jYlhp+S4G0 nwbHE/Og2Ulz9YPiJi/kW4UChMaKXmTsFcRhjDtxkPw9mVM1HoF9XXJmKu/dFXqzjHij BEDdCop4PX90WBj9ot3zVQrpDgeZE6st0TQFmeXkhL0WBlVNY5hbgdc/QL0SHNt5/G50 jepWsCMKnrCWzJ4JiVhs45eFYH/n7b9xMZLhBfjvh5Up3V7oURGna4uHNlsg8hMKo31z z3LVPMWKXwEGMMhSDVU7Da5ocb4qmC5qdDNitajkZjaOX7RBsvMYvFB8sk78VJnB6478 MwQw==
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=hiQLf6UQcsZWwL+JmDtCIGCXwa/MVtXRT1sdJneqV4U=; b=nlLFsoFfWvnAg+IZ2BSDyEIqw2dofOS0VkTxcwBKY5u3riEizofDnd5NuNFrgAB78m uwIXezgn5mKls2J03IPrt8fyyw+wvgHeDWVhUuBYtMUN6LtoIDywxU794fhMzVxWyJBt oLalGGg3X6nlPbkJbUtuMvO1oyFMQDHStCfpSl+EfOl4RJgCku2i3Abvsdq9w9Tr+LE2 0kzyqiJ1T/iyDgs1j4eQnXQzSjf85C2gRKNv8e8eocIeSqZPhlCp3mVAaWpSsJzSUM3w PHc1Nsy/8Dtv+qAzAEC8Entn+8TDqAjW94GMq+7egzM5kfq8PLxVZOK3+XVJs419eeku 5sDg==
X-Gm-Message-State: AN3rC/6yZTeYVLadngVMEfa41l/EYSGkUJnUGdm482jKBBjR0j6Q3eRA jik3mF8F+9FAt2nUMmPos9dx3i6P2gviR/E=
X-Received: by 10.36.58.9 with SMTP id m9mr6909774itm.2.1493149231803; Tue, 25 Apr 2017 12:40:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.192.71 with HTTP; Tue, 25 Apr 2017 12:39:51 -0700 (PDT)
In-Reply-To: 
References: 
From: Yuchung Cheng 
Date: Tue, 25 Apr 2017 12:39:51 -0700
Message-ID: 
To: Tom Herbert 
Cc: Joe Touch , tsvwg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [tsvwg] Inconsistencies between TCP RFCs and Linux implementation (was Re: Comments on draft-touch-tsvwg-udp-option)s-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 19:40:34 -0000

On Tue, Apr 25, 2017 at 12:19 PM, Tom Herbert  wrote:
>> You'll have to start by explaining all the code you've already taken, some
>> of which (e.g., TCP use of experimental ports) is prohibited by existing
>> RFCs.
>>
> Which experimental ports are being abused?
>
>> Check out Linux processing of TCP option 253 and 254 and tell me you have a
>> leg to stand on.
>>
> Linux code use option 254 for TCP fast open along with a magic number
> to distinguish it from other use cases. Given that there is now
> assigned option for fast open this use of the experimental option can
> be removed.
Linux TFO implementation faithfully follows
https://tools.ietf.org/html/rfc7413#page-22

>
> Are there other inconsistencies that need investigation?
>
> Tom
>


From nobody Tue Apr 25 13:11:58 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3005E1294E1 for ; Tue, 25 Apr 2017 13:11:57 -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 GyeE0xlKeLU9 for ; Tue, 25 Apr 2017 13:11:56 -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 260C31294BD for ; Tue, 25 Apr 2017 13:11:56 -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 v3PKBToE015548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 13:11:31 -0700 (PDT)
To: Tom Herbert 
Cc: tsvwg 
References: 
From: Joe Touch 
Message-ID: <6e301f3d-0ec3-2ef3-eafa-6facdea0053d@isi.edu>
Date: Tue, 25 Apr 2017 13:11:28 -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: [tsvwg] Inconsistencies between TCP RFCs and Linux implementation (was Re: Comments on draft-touch-tsvwg-udp-option)s-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 20:11:57 -0000

On 4/25/2017 12:19 PM, Tom Herbert wrote:
>> You'll have to start by explaining all the code you've already taken, some
>> of which (e.g., TCP use of experimental ports) is prohibited by existing
>> RFCs.
>>
> Which experimental ports are being abused?

The code I saw last summer had implementations that didn't use ExIDs.
That might have been corrected by now.

Joe


From nobody Tue Apr 25 13:23:23 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC381294F6 for ; Tue, 25 Apr 2017 13:23:21 -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 8ZQmWFPOP96h for ; Tue, 25 Apr 2017 13:23:20 -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 65CDF1294B8 for ; Tue, 25 Apr 2017 13:23:20 -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 v3PKMaYu017417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 13:22:37 -0700 (PDT)
From: Joe Touch 
To: Tom Herbert 
Cc: tsvwg 
References:  <6e301f3d-0ec3-2ef3-eafa-6facdea0053d@isi.edu>
Message-ID: 
Date: Tue, 25 Apr 2017 13:22:35 -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: <6e301f3d-0ec3-2ef3-eafa-6facdea0053d@isi.edu>
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: [tsvwg] Inconsistencies between TCP RFCs and Linux implementation (was Re: Comments on draft-touch-tsvwg-udp-option)s-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 20:23:21 -0000

I found the details:

    - there are two experimental ports, not one (253 and 254)

    - RFC 6994 defines ExIDs as valid for both experimental ports (even
if a given RFC uses examples of only one)

    -  an Experimental RFC (TFO) is deployed as default enabled in the
wild beyond those actively involved in the experiment (see RFC2026)

Joe


On 4/25/2017 1:11 PM, Joe Touch wrote:
>
> On 4/25/2017 12:19 PM, Tom Herbert wrote:
>>> You'll have to start by explaining all the code you've already taken, some
>>> of which (e.g., TCP use of experimental ports) is prohibited by existing
>>> RFCs.
>>>
>> Which experimental ports are being abused?
> The code I saw last summer had implementations that didn't use ExIDs.
> That might have been corrected by now.
>
> Joe


From nobody Tue Apr 25 13:26:28 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1881294F6 for ; Tue, 25 Apr 2017 13:26:26 -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 okaRkUwzaaEo for ; Tue, 25 Apr 2017 13:26:20 -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 CE0F5129511 for ; Tue, 25 Apr 2017 13:26:20 -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 v3PKPDiI018032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 13:25:14 -0700 (PDT)
To: Tom Herbert 
Cc: tsvwg 
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>    <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu> 
From: Joe Touch 
Message-ID: 
Date: Tue, 25 Apr 2017 13:25:12 -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: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 20:26:27 -0000

On 4/25/2017 11:29 AM, Tom Herbert wrote:
> Really, testing this case is not rocket science.
FWIW, I do agree that the doc does need some advice on how designers who
are concerned with potential vulnerabilities MAY or even SHOULD
constrain use of UDP options, e.g., enforcing some limits on how many
and how large options should be skipped over before "giving up".

AFAICT, we can decide the details by consensus once the doc is accepted
as a WG item, IMO.

However, I don't see a good reason to limit the mechanism by fiat any
more than IPv6 limits header chaining at the endpoint.

Joe


From nobody Tue Apr 25 13:34:58 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@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: [tsvwg] Inconsistencies between TCP RFCs and Linux implementation (was Re: Comments on draft-touch-tsvwg-udp-option)s-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area 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 13:50:39 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599BB1294B2 for ; Tue, 25 Apr 2017 13:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iyy_e2L3oOwb for ; Tue, 25 Apr 2017 13:50:36 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 0430E1294AC for ; Tue, 25 Apr 2017 13:50:35 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id m36so150771744qtb.0 for ; Tue, 25 Apr 2017 13:50:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EDFTIpTM/yz8NJsCPQ536eEJylttrayp7g8jRssb2kM=; b=GgxH+jBaxjekpPick2+L8zbyFvL8ZgX64LxxjEb6hQXqJVXP1ml/frdTQFyy9lV+me rzOyWWGLTOkqDG9jlHowRTPr3RQnBOGgDAYOqduf4VFpfWjIxacFPseApHdgGN7D1z1D vsojjJg3lWTMtNu5YByOzSa4xPe9gSvGBQ+Mc6Gz83dSoZ0yhe1w3MQ5xnwQRs4FDuPc mv7OGCmcRgSH5glDw4P7Vds+PP+qFT5dRJSZpqXKt97HkmtIaOZ2/3a2ymdayJAYTCfU 2PjY6K0sYELZkGH1gjMf6w2m3ExfhH21aH5M46MO/gS4UXaiwGdk+3xpXrW1aScqIBni G3pw==
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=EDFTIpTM/yz8NJsCPQ536eEJylttrayp7g8jRssb2kM=; b=Rl6GWn7ZszqtUqdV/vMX22lRtzn267PqkdlTPmOhPZA/xu83YHxRp8Tg2V0CWxgLfP 1yN9tmRpk+Xjo+DuTs65/Bx+xIu2bA/p4+xlXQPwUie6lMJcXnkGTRNAcNEQqeLKr9K1 J/2ROvVaIp6Y5QPwhsOEXXK3mnYqz8gwNqfUt3Hqp1t5MAf9Uv3s+Gbn2yf3YMRO9Dj6 2SO8SItC/ML1OJ9h2tU79XOXo2zlI+kvwr7UNv53oQCYgKqQfVYDkx2H/UxXYHmFIp7U vDpNWrAMbPvj0jdCHEpR0yd8ZXKOuQNn9MTgHJCrrcaVhaZA7gLEM4xLWE22sY1Hl+5E iE5Q==
X-Gm-Message-State: AN3rC/6S38Ryi/rRJh1X7LVEh8nd0LkFAOvluUlnQAPfAlCGEtWdN9+k +on/c4H2ebc/YTtc44mEr2WIFOi+pw==
X-Received: by 10.200.55.15 with SMTP id o15mr32431800qtb.279.1493153435056; Tue, 25 Apr 2017 13:50:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Tue, 25 Apr 2017 13:50:34 -0700 (PDT)
In-Reply-To: 
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>    <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu>  
From: Tom Herbert 
Date: Tue, 25 Apr 2017 13:50:34 -0700
Message-ID: 
To: Joe Touch 
Cc: tsvwg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 20:50:37 -0000

On Tue, Apr 25, 2017 at 1:25 PM, Joe Touch  wrote:
>
>
> On 4/25/2017 11:29 AM, Tom Herbert wrote:
>> Really, testing this case is not rocket science.
> FWIW, I do agree that the doc does need some advice on how designers who
> are concerned with potential vulnerabilities MAY or even SHOULD
> constrain use of UDP options, e.g., enforcing some limits on how many
> and how large options should be skipped over before "giving up".
>
> AFAICT, we can decide the details by consensus once the doc is accepted
> as a WG item, IMO.
>
That's reasonable, potential vulnerabilities should be discussed and
address in WG item.

> However, I don't see a good reason to limit the mechanism by fiat any
> more than IPv6 limits header chaining at the endpoint.
>
I'm not sure IPv6 header chaining is a good example of successful
protocol extensibility. The limit issue with EH has come up on the
IPv6 lists before. IIRC, originally, there was no limit and that has
since been changed so that the EH chain must fit into one MTU. It
would certainly be an interesting experiment for some on to load up a
packet with a bunch of unknown options in an EH (DO maybe) to see what
the impact is. Fortunately, or unfortunately depending on your point
of view, many intermediate devices drop EH anyway so a DOS attack
using long list of IPv6 extension headers and options might not be
very effective.

Thanks,
Tom

> Joe


From nobody Tue Apr 25 14:03:49 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92654128B8F for ; Tue, 25 Apr 2017 14:03:47 -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 bITNGNPN4zXD for ; Tue, 25 Apr 2017 14:03:46 -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 7F0FC1252BA for ; Tue, 25 Apr 2017 14:03:46 -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 v3PL3O9J026611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 14:03:25 -0700 (PDT)
To: Tom Herbert 
Cc: tsvwg 
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>    <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu>   
From: Joe Touch 
Message-ID: <17b8b437-880e-53ad-2462-0465b112c224@isi.edu>
Date: Tue, 25 Apr 2017 14:03:23 -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: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 21:03:48 -0000

On 4/25/2017 1:50 PM, Tom Herbert wrote:
> I'm not sure IPv6 header chaining is a good example of successful
> protocol extensibility. The limit issue with EH has come up on the
> IPv6 lists before. 
yes, but this is for a different set of reasons:

1) network relay devices (routers) have different capabilities than end
systems
2) it may not be possible to relay a message without having the context

But we should have different expectations of end system services, with a
very small set of exceptions (e.g., DNS is one). Ultimately, the OS
already has to limit how much it invests in processing messages for
different streams (no stream should be able to trigger the OS to hog
resources), and if that's true, then the only penalty is to the
individual connection.

Preventing DOS attacks at that point means rejecting load based on
utility; certainly connections that make progress, regardless of how
complex, should get priority over those that don't (regardless of how
simple). That's why I prefer advice that allows the implementer to
decide what progress means and how to shed load, rather than locking up
a protocol to ensure that.

Joe


From nobody Tue Apr 25 14:06:50 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@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: [tsvwg] Inconsistencies between TCP RFCs and Linux implementation (was Re: Comments on draft-touch-tsvwg-udp-option)s-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area 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 14:26:36 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D498B129443 for ; Tue, 25 Apr 2017 14:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sszuyzue0xyF for ; Tue, 25 Apr 2017 14:26:33 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F66129436 for ; Tue, 25 Apr 2017 14:26:33 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id y33so151593997qta.2 for ; Tue, 25 Apr 2017 14:26:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=80gWa8tZh+cZkK9IfgGHhX+yiKVtn6fwuOPi2Bzv/Oo=; b=qvnQPvFKod4NQ/8ColqmPrizz/pVkfJj6eAIvXMDW7SeSTp1nQFOjWMCYq5s1NQJVd NEi+1G3bIcryqe/vvd8wI+6TpikvqncpU6dyyM59keAVKCEqiCnqrCK53XTMbLLVaxYz Ms/AmiLO1elOWJ2TAmHGO5CahBfJCHOQHoElNnhyi375ybgk+m/d0iUalxi3uhZN5073 IRg3M51kfSSLxWdSyE8UDP0vcH+ySleFWOqFN/esASPbI7iLgZcXHS601JqDs5xn4kiD ZCYpaCTo9YfJhoGqd4nFnrIIGRVRawKQDxTPFq2teZfXus3i7uKuF7yE2V5eyviqlIi1 85QQ==
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=80gWa8tZh+cZkK9IfgGHhX+yiKVtn6fwuOPi2Bzv/Oo=; b=nd1mQYufUn2uUopMNyFtYZQMU1XnAgxWXqb5yLGGS2rL6AsFVWStBdAtOatQAW6HUq Y/bhU1bb0tdcR/mzBkiQVBlR2yROwmk1j1FIBFagV3YyPB31QUngIrbchArdtFD5fkuw /kX1MSwDrjAhZygLLJvh/Z/uwKJOIiBlx10tNEr8vIQDfTD/hCb60ZCs6jv350WRktjb B2ahOI7yPl8sE/xoGw42P5hAt+uiNY2cMHRFgDtc25SE82tJjD3LMNBQ3yBK/BXziYTy N9g8gt2KPTISW5QFciWa00Fn2CxJ9vXw0VLlk/z4wMLfaWGc78Vc1agxvixEsiAhZya+ ONKQ==
X-Gm-Message-State: AN3rC/7Fe1o1qTmS5Gv3epbOnESfLXsrAi3gTTJdyfIWQGdo62HvLTYK iVhEuXRGU/yAOWT+Cr6ntEvE3WKO5g==
X-Received: by 10.200.49.1 with SMTP id g1mr34790709qtb.200.1493155592835; Tue, 25 Apr 2017 14:26:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Tue, 25 Apr 2017 14:26:32 -0700 (PDT)
In-Reply-To: <17b8b437-880e-53ad-2462-0465b112c224@isi.edu>
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>    <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu>    <17b8b437-880e-53ad-2462-0465b112c224@isi.edu>
From: Tom Herbert 
Date: Tue, 25 Apr 2017 14:26:32 -0700
Message-ID: 
To: Joe Touch 
Cc: tsvwg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 21:26:35 -0000

On Tue, Apr 25, 2017 at 2:03 PM, Joe Touch  wrote:
>
>
> On 4/25/2017 1:50 PM, Tom Herbert wrote:
>> I'm not sure IPv6 header chaining is a good example of successful
>> protocol extensibility. The limit issue with EH has come up on the
>> IPv6 lists before.
> yes, but this is for a different set of reasons:
>
> 1) network relay devices (routers) have different capabilities than end
> systems
> 2) it may not be possible to relay a message without having the context
>
> But we should have different expectations of end system services, with a
> very small set of exceptions (e.g., DNS is one). Ultimately, the OS
> already has to limit how much it invests in processing messages for
> different streams (no stream should be able to trigger the OS to hog
> resources), and if that's true, then the only penalty is to the
> individual connection.
>
Syn attacks, attacks on UDP, or IP are all connectionless-- every
packet would have a random source address and port. These attack the
stack processing so as to cause collateral damage to unrelated flows.
There are attacks trying to hit a specific connection or flow queue
(like a tuple attack); for these we do have good mitigations to
isolate the bad traffic to some degree.

> Preventing DOS attacks at that point means rejecting load based on
> utility; certainly connections that make progress, regardless of how
> complex, should get priority over those that don't (regardless of how
> simple). That's why I prefer advice that allows the implementer to
> decide what progress means and how to shed load, rather than locking up
> a protocol to ensure that.

Consider, that some OS that could unilaterally define a limit on UDP
options that are processed in the receive path (say 40 bytes). The
draft seems to allow since it is a limit applied at the
implementator's discretion. If we were to happen to do this in Linux
then MS and IOS might follow. So essentially this limit becomes an ad
hoc standard for the protocol. Another implementation that attempts to
use more bytes than this limit is now interoperable. I don't think
this is your desired outcome.

Tom


>
> Joe


From nobody Tue Apr 25 14:59:54 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3F112EBFB for ; Tue, 25 Apr 2017 14:59:52 -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, RCVD_IN_DNSWL_HI=-5, 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 5SelnptNsT32 for ; Tue, 25 Apr 2017 14:59:51 -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 4A8DE1294D3 for ; Tue, 25 Apr 2017 14:59:51 -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 v3PLxFC0011299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 14:59:16 -0700 (PDT)
To: Tom Herbert 
Cc: tsvwg 
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>    <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu>    <17b8b437-880e-53ad-2462-0465b112c224@isi.edu> 
From: Joe Touch 
Message-ID: <0edf550b-9d5c-596c-d0cb-de2c5297e5c6@isi.edu>
Date: Tue, 25 Apr 2017 14:59:14 -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: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 21:59:53 -0000

On 4/25/2017 2:26 PM, Tom Herbert wrote:
> On Tue, Apr 25, 2017 at 2:03 PM, Joe Touch  wrote:
>>
>> On 4/25/2017 1:50 PM, Tom Herbert wrote:
>>> I'm not sure IPv6 header chaining is a good example of successful
>>> protocol extensibility. The limit issue with EH has come up on the
>>> IPv6 lists before.
>> yes, but this is for a different set of reasons:
>>
>> 1) network relay devices (routers) have different capabilities than end
>> systems
>> 2) it may not be possible to relay a message without having the context
>>
>> But we should have different expectations of end system services, with a
>> very small set of exceptions (e.g., DNS is one). Ultimately, the OS
>> already has to limit how much it invests in processing messages for
>> different streams (no stream should be able to trigger the OS to hog
>> resources), and if that's true, then the only penalty is to the
>> individual connection.
>>
> Syn attacks, attacks on UDP, or IP are all connectionless-- every
> packet would have a random source address and port. These attack the
> stack processing so as to cause collateral damage to unrelated flows.
> There are attacks trying to hit a specific connection or flow queue
> (like a tuple attack); for these we do have good mitigations to
> isolate the bad traffic to some degree.
The impact of SYN floods - even across a set of ports  - on other
connections is mitigated by limiting the rate of processing SYNs.

The same rule can apply here - if option processing becomes overloaded,
then deprioritize packets that are causing the overload (with many
unknown options in long chains), e.g., by "giving up" on those earlier
(sort of like the circuit breaker approach for UDP flows in RFC8085).

>
>> Preventing DOS attacks at that point means rejecting load based on
>> utility; certainly connections that make progress, regardless of how
>> complex, should get priority over those that don't (regardless of how
>> simple). That's why I prefer advice that allows the implementer to
>> decide what progress means and how to shed load, rather than locking up
>> a protocol to ensure that.
> Consider, that some OS that could unilaterally define a limit on UDP
> options that are processed in the receive path (say 40 bytes). 
It could do the same for TCP and limit the options to 10 bytes...

> The
> draft seems to allow since it is a limit applied at the
> implementator's discretion. If we were to happen to do this in Linux
> then MS and IOS might follow. So essentially this limit becomes an ad
> hoc standard for the protocol. Another implementation that attempts to
> use more bytes than this limit is now interoperable. I don't think
> this is your desired outcome.

That might be true, right up until we define a new, known option that is
100 bytes long. At that point, a box that understand the option isn't
constrained by boxes that don't. That *is* (at least partly) the desired
outcome.

Joe


From nobody Tue Apr 25 16:14:55 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BDC126CD8 for ; Tue, 25 Apr 2017 16:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiZ1E4OkUxiP for ; Tue, 25 Apr 2017 16:14:51 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87AB01286AB for ; Tue, 25 Apr 2017 16:14:51 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id c45so153116548qtb.1 for ; Tue, 25 Apr 2017 16:14:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=beLQgI+G1w/95iHMiIvGqdZuiclsh/A8LRB8UQgQYDc=; b=fZCedpa7FMfHAFwTZqsdIMimS7+G70s5j4pZwzeQ5OlF/Mqwplp/CJlFqC6L3ypYf0 vgA3Tqhuu8mXAIYg0QahwUpZ3ZpiEklUCnMcX1fK6hOABiunoYYYXFa0sEZ9G5ZM1X/f mzZqNhoEjIMY+Xx4I383MvqHXFp1tPg5M/Ar74TeSmT04bNYPn0oXOP+1twu/84tRU56 mgyt8WAmrYmvwY+ldA/6UlOCVh6Kb/PCa3qDhfZbyzpUqIiw7NklojfOlsRvKweJD7w2 1/WQkO2XNPdB8YPUCFhymkMxc8L5U7k2EVqOrGKrFYS4leDMYvuBA4zhuNkp0uKKEtfq aDsA==
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=beLQgI+G1w/95iHMiIvGqdZuiclsh/A8LRB8UQgQYDc=; b=pX8lz7bp7ULtxrnylHuBmLGid+F7pskWoC1RnAoPeHveoITMpGwxj2r9pSf/eiMvjo jl6vSK25ZWKF8NMuHGhQfURonfOMY+cSmei9tHFTAdIxc/dAKjrr1ncpVb6qvWf9ah0J aNp3zbqmu7yFcVQNp4S1Fbf508a9F089cwY4BDb0hZtD8Am5ypwAC+s0pPEMUdYBVjea 71atuoQWmF+MAQCtPxIPpCo4rc2rkdcDVh1pejSg27FuSfg6VgicPyrNQ9Z1JKP0HLts W8wj57ZWPvKsSPyiWjCjlmTb/YqCWH6kUmn+FXMeAPMsQEvFQyAjnJcEFngfnOm1t/QV nvGA==
X-Gm-Message-State: AN3rC/5CKTxhiBNq6+3Dbn3u+3hooBQVSOcI3cgDjkDpm1kaOWdx7YFL 1IzyHhP2FcS+i8byakXx0O392IKNiQ==
X-Received: by 10.237.58.103 with SMTP id n94mr36066780qte.42.1493162090504; Tue, 25 Apr 2017 16:14:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Tue, 25 Apr 2017 16:14:49 -0700 (PDT)
In-Reply-To: <0edf550b-9d5c-596c-d0cb-de2c5297e5c6@isi.edu>
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>    <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu>    <17b8b437-880e-53ad-2462-0465b112c224@isi.edu>  <0edf550b-9d5c-596c-d0cb-de2c5297e5c6@isi.edu>
From: Tom Herbert 
Date: Tue, 25 Apr 2017 16:14:49 -0700
Message-ID: 
To: Joe Touch 
Cc: tsvwg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 23:14:53 -0000

>> Consider, that some OS that could unilaterally define a limit on UDP
>> options that are processed in the receive path (say 40 bytes).
> It could do the same for TCP and limit the options to 10 bytes...
>

I don't think it could do this without violating the spec. This
definitely can't be done for IP options. Per RFC1122:

"All IP options (except NOP or END-OF-LIST) received in datagrams MUST
be passed to the transport layer (or to ICMP processing when the
datagram is an ICMP message).  The IP and transport layer MUST each
interpret those IP options that they understand and silently ignore
the others."

The requirements in RFC1122 for TCP options are not quite as precise,
but I think the spirit is that same: hosts are not permitted to ignore
known options which means all options up to the maximum limit must be
examined.

Tom


From nobody Tue Apr 25 16:22:14 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FF612945C for ; Tue, 25 Apr 2017 16:22:13 -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 hmJOEXijtvgo for ; Tue, 25 Apr 2017 16:22:12 -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 41CF6120227 for ; Tue, 25 Apr 2017 16:22:12 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3PNLeIm024997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 16:21:40 -0700 (PDT)
To: Tom Herbert 
Cc: tsvwg 
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>    <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu>    <17b8b437-880e-53ad-2462-0465b112c224@isi.edu>  <0edf550b-9d5c-596c-d0cb-de2c5297e5c6@isi.edu> 
From: Joe Touch 
Message-ID: 
Date: Tue, 25 Apr 2017 16:21:40 -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: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 23:22:13 -0000

On 4/25/2017 4:14 PM, Tom Herbert wrote:
>>> Consider, that some OS that could unilaterally define a limit on UDP
>>> options that are processed in the receive path (say 40 bytes).
>> It could do the same for TCP and limit the options to 10 bytes...
>>
> I don't think it could do this without violating the spec. This
> definitely can't be done for IP options.
But it is exactly what happens when we limit EHs in IPv6.

The net effect is the same - both are violations of the spec.

Never mind the fact that routers that drop fragments or packets with any
options are absolutely violating spec.

When a device is under overload, there are lots of things that can be
done. That's my point here - we might provide some guidance as to how
this can be done in general, but we shouldn't be forcing a hard limit on
the protocol design.

Joe


From nobody Tue Apr 25 17:33:31 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C17A127871 for ; Tue, 25 Apr 2017 17:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij9negdjGhBt for ; Tue, 25 Apr 2017 17:33:28 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 9D8CC1243F3 for ; Tue, 25 Apr 2017 17:33:28 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id m36so154253564qtb.0 for ; Tue, 25 Apr 2017 17:33:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=npdQrO51VbkQdePZfL1txlrY6zSesn/xlIFRXYurQmA=; b=1JYNg9bOaTOqmDsmvBMABg4nz+mlAh0VEeOBv+LTCwqdBuhRKLu77vlIOhBvxuUiuq KcaAnHg5jFyiKFAmF5tDO6022mFEhoTSFqaXkBbHDp6ZzUMPdc3CKFE9tzJvylJwDdGm 7xfRFpOO0nA2cHIG34fTCpFunQpx/8UnaKt0Rof8FJin3AJ4FoOcTh5t8bs2dkIUcCsh zKtXXHlIiGKD/tIxaq0lb3Fb0WBOhwHhXuoQ7Td1chNifeOqMhaqXqjZ4L3U1tDiRNxp bEKovKVx7BIdbWNZoDDgkDUHIJse/yLZtVQIOU5zmoJZPNO+Nu8Ig/zvJPfvUi3ODRVj RNmA==
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=npdQrO51VbkQdePZfL1txlrY6zSesn/xlIFRXYurQmA=; b=NpstmDFRzFbb2bO5t5vnEETLcbRH/OWmMgHs0wRoeE6orA0oYNNDunTsev4q8/JSwd eQuXtjeTjGC7aKyaHTTTB+08hVKlSv8OzPmjibT6DevBZ/jX8/s2ZnHEkrCPGa0+l11N ELqL11s8BbaNBICkEws0hj9vE8ts6t9X8StYcTcOhpN1ElNSyklTXjYoDiQMShiqLtKj 4Yy06mMbcSbMyiPfHYqrF2vLq5leeHKimTJOy4tGLC9QLwo1FPBauohMU9XsktdjbH3R +Sp76gJGW8aB593oPWheLhoDlFb/3oOGcwDrKDfknwBQNgVK6iPVvtgPl1OTSJ+GQLHp osDg==
X-Gm-Message-State: AN3rC/7zOh2ibpqWJiwXgE9+3YdddTD9XZqpK/2WUoi+L0lpOvE/qjNU +EQ1DsU3XrxgtIgHGC8rl5bCgWpdSw==
X-Received: by 10.237.62.150 with SMTP id n22mr33661046qtf.70.1493166807620; Tue, 25 Apr 2017 17:33:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Tue, 25 Apr 2017 17:33:26 -0700 (PDT)
In-Reply-To: 
References:  <77680ac1-c8b8-4cf2-a0e5-edfb1cc98469@isi.edu>    <227902ec-5e3a-3e91-c655-4b29c7e21322@isi.edu>    <17b8b437-880e-53ad-2462-0465b112c224@isi.edu>  <0edf550b-9d5c-596c-d0cb-de2c5297e5c6@isi.edu>  
From: Tom Herbert 
Date: Tue, 25 Apr 2017 17:33:26 -0700
Message-ID: 
To: Joe Touch 
Cc: tsvwg 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [tsvwg] Comments on draft-touch-tsvwg-udp-options-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 00:33:30 -0000

On Tue, Apr 25, 2017 at 4:21 PM, Joe Touch  wrote:
>
>
> On 4/25/2017 4:14 PM, Tom Herbert wrote:
>>>> Consider, that some OS that could unilaterally define a limit on UDP
>>>> options that are processed in the receive path (say 40 bytes).
>>> It could do the same for TCP and limit the options to 10 bytes...
>>>
>> I don't think it could do this without violating the spec. This
>> definitely can't be done for IP options.
> But it is exactly what happens when we limit EHs in IPv6.
>
> The net effect is the same - both are violations of the spec.
>
> Never mind the fact that routers that drop fragments or packets with any
> options are absolutely violating spec.
>
> When a device is under overload, there are lots of things that can be
> done. That's my point here - we might provide some guidance as to how
> this can be done in general, but we shouldn't be forcing a hard limit on
> the protocol design.
>
FWIW, here's what the Christmas tree packet with IPv6 EH might look like.

IPv6 header: 40 bytes, next header is DO
DO header: 2 bytes. length is 181 (times 8 gives 1448), next header is UDP
160 * [ 7 * PAD1 (1 byte each), Ignored dest option (2 bytes) ]
2 * PAD1
UDP header with zero length

Each ignored dest option is some unknown type beginning with 00 to
indicate that the option if unknown is to be ignored. Linux only
support Home Address destination option so any type number less than
64 and greater than one should work for this. Length field is zero so
ignored option is two bytes.

This gives packet length of 1498 bytes and results in 1282 iterations
through the TLV parsing loop. If PAD1 is easier process than a TLV
with a length field then we could use those instead to have 724 two
byte destination options in the packet. Either way, this is a whole
bunch of conditionals, cache misses on the packet, and code that must
be done but results in no useful work. .i.e. unbounded lists of TLVs
that can be ignored are a DOS attack waiting to happen IMO. :-(

Tom

> Joe


From nobody Fri Apr 28 13:34:13 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27D0120454 for ; Fri, 28 Apr 2017 13:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level: 
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 YM_I2PMyBaWp for ; Fri, 28 Apr 2017 13:34:10 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BAA129B79 for ; Fri, 28 Apr 2017 13:32:03 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 16708B80CEF; Fri, 28 Apr 2017 13:31:22 -0700 (PDT)
To: lucy.yong@huawei.com, edward.crabbe@gmail.com, xuxiaohu@huawei.com, tom@herbertland.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, david.black@emc.com, gorry@erg.abdn.ac.uk, wes@mti-systems.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: d3e3e3@gmail.com, tsvwg@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170428203122.16708B80CEF@rfc-editor.org>
Date: Fri, 28 Apr 2017 13:31:22 -0700 (PDT)
Archived-At: 
Subject: [tsvwg] [Editorial Errata Reported] RFC8086 (5006)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 20:34:12 -0000

The following errata report has been submitted for RFC8086,
"GRE-in-UDP Encapsulation".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=8086&eid=5006

--------------------------------------
Type: Editorial
Reported by: Donald Eastlake 

Section: 8

Original Text
-------------
   Section 3.1.9 of [RFC8085] discusses the congestion considerations
   for design and use of UDP tunnels;

Corrected Text
--------------
   Section 3.1.11 of [RFC8085] discusses the congestion considerations
   for design and use of UDP tunnels;

Notes
-----
There appears to be an incorrect reference to 3.1.9 that should refer to 3.1.11.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8086 (draft-ietf-tsvwg-gre-in-udp-encap-19)
--------------------------------------
Title               : GRE-in-UDP Encapsulation
Publication Date    : March 2017
Author(s)           : L. Yong, Ed., E. Crabbe, X. Xu, T. Herbert
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG


From nobody Fri Apr 28 20:31:10 2017
Return-Path: 
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AAA129B79; Fri, 28 Apr 2017 20:31:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tsvwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149343666210.3040.17095874197515065064@ietfa.amsl.com>
Date: Fri, 28 Apr 2017 20:31:02 -0700
Archived-At: 
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-02.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Apr 2017 03:31:02 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group of the IETF.

        Title           : Explicit Congestion Notification (ECN) Experimentation
        Author          : David Black
	Filename        : draft-ietf-tsvwg-ecn-experimentation-02.txt
	Pages           : 18
	Date            : 2017-04-28

Abstract:
   This memo updates RFC 3168, which specifies Explicit Congestion
   Notification (ECN) as a replacement for packet drops as indicators of
   network congestion.  It relaxes restrictions in RFC 3168 that would
   otherwise hinder experimentation towards benefits beyond just removal
   of loss.  This memo summarizes the anticipated areas of
   experimentation and updates RFC 3168 to enable experimentation in
   these areas.  An Experimental RFC is required to take advantage of
   any of these enabling updates.  In addition, this memo makes related
   updates to the ECN specifications for RTP in RFC 6679 and for DCCP in
   RFC 4341, RFC 4342 and RFC 5622.  This memo also records the
   conclusion of the ECN Nonce experiment in RFC 3540, and provides the
   rationale for reclassification of RFC 3540 as Historic; this
   reclassification enables new experimental use of the ECT(1)
   codepoint.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-02
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimentation-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-experimentation-02


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Apr 30 09:13:25 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59165127342 for ; Sun, 30 Apr 2017 09:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level: 
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Xdat_cGYByBj for ; Sun, 30 Apr 2017 09:13:21 -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 0F03C1200F3 for ; Sun, 30 Apr 2017 09:11:04 -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:To:Cc:References: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=Z5/6LA4U/Lu40VWfibMGC2gMoLPI0GXQxSYHHRzjhXo=; b=r/XsuKo+jqHbDuiUtKePaaz0ra pj3f14GInpJcqzgDdtkFcD2p+184x6c0qXq6KwxYf70TZd8vjlpT0RSuT8B8tfzSv5ppjpJWGO+TR 3Q40frzR1ob7Lcqos88NXxzU8CgD5rqeK1OyRXJyvmQIlLnVs+8jWgi8/ABzhdMItlSZslht1Hx6z fVTt1ujiCmR2aKLkxEiThP+VQKD663k3T4PBjhzh1x6kb8W+aEalNG3hkUzEXiLIzBBw8Z49AsVAM x3xbv/SqBWCiV3740DzxRWFoMZyG0uGwEitgVRIAoC4WpGS/r9V8tf3qrmQsgBX3Tbn3WiIIFiLhL HEVn49QA==;
Received: from 188.6.208.46.dyn.plus.net ([46.208.6.188]:53704 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 1d4rR8-000662-B2; Sun, 30 Apr 2017 17:11:02 +0100
References: <149343666210.3040.17095874197515065064@ietfa.amsl.com>
Cc: tsvwg@ietf.org
To: "Black, David" 
From: Bob Briscoe 
Message-ID: <1b492efc-3d31-c16a-b024-d3008e012783@bobbriscoe.net>
Date: Sun, 30 Apr 2017 17:11:01 +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: <149343666210.3040.17095874197515065064@ietfa.amsl.com>
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: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-02.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Apr 2017 16:13:23 -0000

David,

Thanks for all the work you're putting into this draft to enable these 
experiments.
I can confirm that I've checked over the draft again, especially the new 
edits, and they are all fine.

Cheers



Bob


On 29/04/17 04:31, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group of the IETF.
>
>          Title           : Explicit Congestion Notification (ECN) Experimentation
>          Author          : David Black
> 	Filename        : draft-ietf-tsvwg-ecn-experimentation-02.txt
> 	Pages           : 18
> 	Date            : 2017-04-28
>
> Abstract:
>     This memo updates RFC 3168, which specifies Explicit Congestion
>     Notification (ECN) as a replacement for packet drops as indicators of
>     network congestion.  It relaxes restrictions in RFC 3168 that would
>     otherwise hinder experimentation towards benefits beyond just removal
>     of loss.  This memo summarizes the anticipated areas of
>     experimentation and updates RFC 3168 to enable experimentation in
>     these areas.  An Experimental RFC is required to take advantage of
>     any of these enabling updates.  In addition, this memo makes related
>     updates to the ECN specifications for RTP in RFC 6679 and for DCCP in
>     RFC 4341, RFC 4342 and RFC 5622.  This memo also records the
>     conclusion of the ECN Nonce experiment in RFC 3540, and provides the
>     rationale for reclassification of RFC 3540 as Historic; this
>     reclassification enables new experimental use of the ECT(1)
>     codepoint.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-02
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimentation-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-experimentation-02
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>

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